アカウント名:
パスワード:
言ってることの大筋には同意するけど、ホウレンソウとかそういう言葉がそもそもダメなんだと思う。報連相ってお題目を掲げていればなんか密なコミュニケーションしているイメージは持つけど実際には何の価値もない情報の垂れ流しがほとんど。
大切なのはそういうコミュニケーションの「手段」の話じゃなくて何をコミュニケーションすべきかっていう「対象」の話。今回の件で言うと、客と営業で、何を共有できて何をできなかったか、どこに認識の不一致があったかとか中身の話をすべきなんだけどね、こう言ってもなかなか理解してくれないんだ。
うちの会社の人間もよくこういうトラブル起こすんだけどさ、上司部下ともに自分たちの何が悪いかわかってない。だいたい「ちゃんとお客さんとホウレンソウできてたのか」「毎週必ず報告あげてましたよ」とかそういう低いレベルで終わって良しとしている。
日経のアカウントないと読めないけど「ホウレンソウとか言ってるから行動が戦略じゃなくて戦術・手段レベルになってる」という指摘
http://www.nikkei.com/access/article/g=96959996889DE1EAE5E1E3E5E4E2E3E... [nikkei.com]
あともうすこし古いけどこちらにも「欧米の考え方」的トーンで似たようなことが書かれている
http://d.hatena.ne.jp/favre21/20080827 [hatena.ne.jp]
ホウレンソウそのものがNGとまでは思わないが，○○至上主義とか一点に囚われるとダメということですかね
柔軟なスケジュール対応はどんなプロジェクトにも必要だけどむしろ銀行のような社会的な基幹系は完璧なウォーターフォールにすべき中途半端に色気を出して仕様変更（未策定含め）出す/受け入れるから問題なだけ
プロジェクトが計画通りに行かないわけではなく、計画がプロジェクトに合ってない
報連相がどうとかの問題じゃないと思うな。日本のクソなシステム開発がいつものように失敗例を生み出しただけでしょ。
要件定義は発注側の責任でやらないとならないってのが国際標準だってのは結構前から言われているけど、未だ何も変わってないよね。CIOってのが何で必要なのか理解出来ない馬鹿経営者と、そいつらを説教できないSIerしかいない内は駄目なんでしょう。そんなことをしているうちに、日本はどんどん沈没してくのでしょうか。
ま、自分もそんなSIerの末端な訳ですが。
セールスフォースに頼めば、納期８分の１、開発費４分の１で出来た気がする
#日本ITのベンダーは高すぎる
ホントに依頼した事ありますか？
下手すると、LotusNotes以上に制限ありまくりで、何も出来ないという話すら聞いたことありますよ？
欧米では、経営スタイルをシステムにあわせるんじゃないですか？日本ぐらいでしょ、システムを経営スタイルに合わせるのは。
>欧米では、経営スタイルをシステムにあわせるんじゃないですか？
よく勘違いしている人がいますがそれは極論過ぎる間違いです。欧米でも経営スタイルをシステムに合わせることはしません。だってそれしちゃったら他社と同じになるだけでしょ？
欧米でも、守るところはきっちり守り内製しますし、攻めるところもきっちり攻めて内製します。ちなみにこれをやる開発者はたいていが正社員で雇用された人間です。
その上で、「守るところじゃないところ」「攻めるところじゃないところ」を出来合いのシステムに合わせるわけです。
紙の帳票は慣例として、それがそこにあるだけで証拠になることが実績によって証明されたもんだけれど、ソフト屋はどうやって保証してくれるだろうか？弁護士や税理士に頼んでそのコストを見積もらせるより、紙に同じように出力する仕様をソフト屋に見積もらせた方が安いなら、仕方ないだろう。
電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則http://law.e-gov.go.jp/htmldata/H10/H10F03401000043.html [e-gov.go.jp]
同様のものが、税務関連法だけでも、消費税法、所得税法、地方税法etc...と、それぞれの施行規則などによって規定されていて、さらに事業別にいくつも書面の保管方法についての規定がある。それらは、毎年更新される可能性がある。
仮に電子データと、あなたが考える合理的なインタフェースを用意したとして、税務調査のときに、税務署員にレクチャーできるか？そのとき自社が雇っている立ち会いの税理士に理解させて、対等な立場で証拠の正当性を説明させられるか？そんなことしらねって言っても現実には、そういうことが起こるし、そのときたまたまやってきた担当者を理解させることに失敗すれば、場合によっては訴訟を行わないと正当性を説得できないかもしれない。そのときには、正当性を実証するために人月コストが発生することになるだろうし、業務にも影響がある。
万が一にも正当性を証明することに失敗すれば、７年の税法上の時効に遡って課税されてしまうかもしれないし、２倍とか３倍の重加算なんてされれば、年間売り上げを超えるような追徴が発生するかもしれない。それをソフト屋が補償してくれるわけでではないよね。
そんなリスクをちゃんと予想して、必要なシステム要件をだしてくれて、しかも安かったら、そりゃぁお客さんは大喜びですよ。
な、、、なんでカラー！？
>電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則>http://law.e-gov.go.jp/htmldata/H10/H10F03401000043.html
第三条-5-四当該国税関係書類に係る電磁的記録の保存をする場所に当該電磁的記録の電子計算機処理の用に供することができる電子計算機、プログラム、映像面の最大径が三十五センチメートル以上のカラーディスプレイ及びカラープリンタ並びにこれらの操作説明書を備え付け、当該電磁的記録をカラーディスプレイの画面及び書面に、次のような状態で速やかに出力することができるようにしておくこと。イ 整然とした形式であること。ロ 当該国税関係書類と同程度に明りょうであること。ハ 拡大又は縮小して出力することが可能であること。ニ 国税庁長官が定めるところにより日本工業規格Ｚ八三〇五に規定する四ポイントの大きさの文字を認識することができること。
>同じ時間(お金)で品質の高いシステムが提供できるわけです客先が業務への影響範囲を検証するなら、当然客先の業務リソースが使われるんだから、「同じ金を払っている」という話にはなりません。客先負担を前提として、システムを提案するっていうなら、それを含めて最初に査定して契約しないといけないでしょう。仕事がすでにある、予算がきまってるという前提で、そこから相談して決める話ではないです。
あなたの言っていることは、300円でカツ丼を提供するという約束をしながら、300円で足りるように卵かタマネギかかつのどれを選ぶか考えましょうなんて言い始めるのと一緒だよ？客からしたら営業もSEも関係なく、おたくの会社と取引してるんだよね、いくら払ったらどれだけのものを実現するっていう契約をしているわけだよね。で、完成させることが債務になってるわけだよ予算が決まっているなんてのはあなたの会社の都合であって、お客さんにとっては関係のない話でしょう？
>＃そろそろ本気でウォーターフォールを何とかしないといけないと思う
現場で開発していないような人が声を大きくして批判するから、一般的によいイメージをもたれていないみたいですが、ウォーターフォールがよくないというのは、ただの都市伝説ですよ。
どんな開発でもふたを開ければウォーターフォール型をこなすことになりますし、*ちゃんと*手順を踏んでいれば通常失敗しません。
ウォーターフォールで失敗している例は、単純に見切りだけでどんどん先へ進むとか、コンサルが腐っていて決めるべきところを全然きめない、旗を振らないといった開発工程とはまったく関係ない要因が原因であることがほとんどです。(まぁこちらは個人的な経験談ですが)
あと、デスマの原因として営業さんのせいで本来は不必要な仕様書が納品に含まれていて工数がたりないとかはたまにありしたが。。。# 単金あげるためにいらん設計書をつくらせるのやめてほしい；；# 内部設計なんてソースあればいいじゃないか！
>ウォーターフォールで失敗している例は、>単純に見切りだけでどんどん先へ進むとか、>コンサルが腐っていて決めるべきところを全然きめない、旗を振らないといった>開発工程とはまったく関係ない要因が原因であることがほとんどです。
そういうのが常態化しているならウォーターフォールも不適なんだからなんとかしないと、という話でしょ。残念ですが、現実の問題を理想論の話にすり替えてウォーターフォールを擁護しているようにしか見えません。それって「常に下流が氏ね」でしかありませんしね。
やー、残念なことにそういう体質のところはウォーターフォールにしようがなんにしようがどーにもならんので、なんともなりません。元請が馬鹿なら下請けが全権奪取出来る開発システムでもあるのなら、話は別ですが。
>*ちゃんと*手順を踏んでいれば※ただし、ちゃんと手順を踏むところに限る
という事ですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
要するに、客と営業と実働部隊の間で所謂ホウレンソウができてない
IBMに対して支払い命令が出たのは、
システム発注 → 期限までに完成しなかった → IBMが悪い
という単純な理由だと思うけど、それじゃIBMがかわいそうだ
＃そろそろ本気でウォーターフォールを何とかしないといけないと思う
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:4, すばらしい洞察)
言ってることの大筋には同意するけど、
ホウレンソウとかそういう言葉がそもそもダメなんだと思う。
報連相ってお題目を掲げていればなんか密なコミュニケーションしているイメージは持つけど
実際には何の価値もない情報の垂れ流しがほとんど。
大切なのはそういうコミュニケーションの「手段」の話じゃなくて
何をコミュニケーションすべきかっていう「対象」の話。
今回の件で言うと、客と営業で、何を共有できて何をできなかったか、どこに認識の不一致があったかとか
中身の話をすべきなんだけどね、こう言ってもなかなか理解してくれないんだ。
うちの会社の人間もよくこういうトラブル起こすんだけどさ、
上司部下ともに自分たちの何が悪いかわかってない。
だいたい「ちゃんとお客さんとホウレンソウできてたのか」「毎週必ず報告あげてましたよ」とか
そういう低いレベルで終わって良しとしている。
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:3, 参考になる)
日経のアカウントないと読めないけど「ホウレンソウとか言ってるから行動が戦略じゃなくて戦術・手段レベルになってる」という指摘
http://www.nikkei.com/access/article/g=96959996889DE1EAE5E1E3E5E4E2E3E... [nikkei.com]
あともうすこし古いけどこちらにも「欧米の考え方」的トーンで似たようなことが書かれている
http://d.hatena.ne.jp/favre21/20080827 [hatena.ne.jp]
ホウレンソウそのものがNGとまでは思わないが，○○至上主義とか一点に囚われるとダメということですかね
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
実施は担当者の裁量でできるけど責任は上司にある
今回の問題は
それぞれが相手の立場を理解して話をすることができなくて、単なる要望の言い合いのようになったのだと思いますよ
幹部で話し合った結果がスルーされてるとかもひどい
問題の本質はコミュニケーションの破綻がどこで起こったかでしょう 悪い雰囲気作ってしまったヤツか話を巻き戻してまとめられなかったヤツか、そもそも意思疎通もできない連中から仕事受けてきたヤツか
銀行がどこまでニーズを明確にしていたかなんだろうけど、どうせ後々「役員がこう言うからこうしないと」とかのレベルの低い要求出していったんじゃないかと予想
どちらの会社も悪くて どちらの会社の社員も時間を無駄にして会社に損害を与てるのだから 逸失利益を請求するスルガの神経は理解に苦しみます
銀行以外でも嫌がるようなかなりキツいローンでも実行するような銀行だからどうせ金額ふっかけてる。
まだまだ金額吊り上げていくんでしょうね。
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
いや全くその通りで、何をどうしたいのか、そのために何が必要なのか、とかの
具体的なところが曖昧なまま納期が迫ってくるのがデスマーチなんだよね
確かに現場で「ホウレンソウ」とか言ってるオジサンは駄目だと思うｗ
＃SE上がりの管理者にマネージメントを理解しろとか無茶振りだとは思うけどね
経験的にIBMがチョンボをやらかしたと思う (スコア:1)
柔軟なスケジュール対応はどんなプロジェクトにも必要だけど
むしろ銀行のような社会的な基幹系は完璧なウォーターフォールにすべき
中途半端に色気を出して仕様変更（未策定含め）出す/受け入れるから問題なだけ
プロジェクトが計画通りに行かないわけではなく、計画がプロジェクトに合ってない
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
報連相がどうとかの問題じゃないと思うな。
日本のクソなシステム開発がいつものように失敗例を生み出しただけでしょ。
要件定義は発注側の責任でやらないとならないってのが国際標準だってのは
結構前から言われているけど、未だ何も変わってないよね。
CIOってのが何で必要なのか理解出来ない馬鹿経営者と、
そいつらを説教できないSIerしかいない内は駄目なんでしょう。
そんなことをしているうちに、日本はどんどん沈没してくのでしょうか。
ま、自分もそんなSIerの末端な訳ですが。
Re: (スコア:0)
セールスフォースに頼めば、納期８分の１、開発費４分の１で出来た気がする
#日本ITのベンダーは高すぎる
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
ホントに依頼した事ありますか？
下手すると、LotusNotes以上に制限ありまくりで、何も出来ないという話すら聞いたことありますよ？
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
Re: (スコア:0)
欧米では、経営スタイルをシステムにあわせるんじゃないですか？
日本ぐらいでしょ、システムを経営スタイルに合わせるのは。
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
>欧米では、経営スタイルをシステムにあわせるんじゃないですか？
よく勘違いしている人がいますがそれは極論過ぎる間違いです。
欧米でも経営スタイルをシステムに合わせることはしません。
だってそれしちゃったら他社と同じになるだけでしょ？
欧米でも、守るところはきっちり守り内製しますし、
攻めるところもきっちり攻めて内製します。
ちなみにこれをやる開発者はたいていが正社員で雇用された人間です。
その上で、「守るところじゃないところ」「攻めるところじゃないところ」を
出来合いのシステムに合わせるわけです。
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
日本のシステム発注は「細部」までシステムをあわせるじゃない
「紙の帳票とフォーマットを完全に一致させる」とか「電子帳票を自動印刷」するとか
狂気の要望に満ち溢れてるし
自分の経験だと「システム化」が「作業効率の向上」ではなくて「パソコンをつかうようにしただけ」って
要求があまりにも多すぎる気がするし、SEが業務効率の向上となるワークフローを提示しても、
多くの場合が「管理職」レベルの協議になった段階で「紙の業務」と一致している方に倒れる案件が多すぎる
その実態を考えれば日本は「紙の電子化がシステム化」ってパターンが支配的だし
それに比べれば欧米は「業務の効率を考えたシステム化」を行っていると思うよ
紙の帳票が重視される日本の企業って担当者にハンコ押させるもんね
管理職が管理してれば「ハンコ」って担当者の作業担保は不要だとおもうんだけど
担当者が紙にハンコを押す事を「エビデンス」と呼ぶアホさと非効率を是正出来ないと
業務の効率化もシステム化も無理だと思うんだな
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
紙の帳票は慣例として、それがそこにあるだけで証拠になることが実績によって証明されたもんだけれど、ソフト屋はどうやって保証してくれるだろうか？弁護士や税理士に頼んでそのコストを見積もらせるより、紙に同じように出力する仕様をソフト屋に見積もらせた方が安いなら、仕方ないだろう。
電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則
http://law.e-gov.go.jp/htmldata/H10/H10F03401000043.html [e-gov.go.jp]
同様のものが、税務関連法だけでも、消費税法、所得税法、地方税法etc...と、それぞれの施行規則などによって規定されていて、さらに事業別にいくつも書面の保管方法についての規定がある。それらは、毎年更新される可能性がある。
仮に電子データと、あなたが考える合理的なインタフェースを用意したとして、税務調査のときに、税務署員にレクチャーできるか？そのとき自社が雇っている立ち会いの税理士に理解させて、対等な立場で証拠の正当性を説明させられるか？そんなことしらねって言っても現実には、そういうことが起こるし、そのときたまたまやってきた担当者を理解させることに失敗すれば、場合によっては訴訟を行わないと正当性を説得できないかもしれない。そのときには、正当性を実証するために人月コストが発生することになるだろうし、業務にも影響がある。
万が一にも正当性を証明することに失敗すれば、７年の税法上の時効に遡って課税されてしまうかもしれないし、２倍とか３倍の重加算なんてされれば、年間売り上げを超えるような追徴が発生するかもしれない。それをソフト屋が補償してくれるわけでではないよね。
そんなリスクをちゃんと予想して、必要なシステム要件をだしてくれて、しかも安かったら、そりゃぁお客さんは大喜びですよ。
Re: (スコア:0)
な、、、なんでカラー！？
>電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則
>http://law.e-gov.go.jp/htmldata/H10/H10F03401000043.html
第三条-5-四
当該国税関係書類に係る電磁的記録の保存をする場所に当該電磁的記録の電子計算機処理の用に供することができる電子計算機、プログラム、映像面の最大径が三十五センチメートル以上のカラーディスプレイ及びカラープリンタ並びにこれらの操作説明書を備え付け、当該電磁的記録をカラーディスプレイの画面及び書面に、次のような状態で速やかに出力することができるようにしておくこと。
イ 整然とした形式であること。
ロ 当該国税関係書類と同程度に明りょうであること。
ハ 拡大又は縮小して出力することが可能であること。
ニ 国税庁長官が定めるところにより日本工業規格Ｚ八三〇五に規定する四ポイントの大きさの文字を認識することができること。
Re: (スコア:0)
Re: (スコア:0)
社内文書的な帳票までフォーマットも合わせてすべて同じで「システム化」しちゃって「特殊処理」の
塊になる案件が多いって話をしてるんですよ
「システム」に例外が無い方がコードも試験も効率化出来るんで、同じ時間(お金)で
品質の高いシステムが提供できるわけです
でも、業務としてどうしても外せなかったり、ワークフローの効率を考えると例外的な
「特殊処理」を業務に合わせて実装する必要性が出てくる(＝金のかかる部分が出てくる)
SEだってお客さんの予算に対して良いものを提供したい
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
>同じ時間(お金)で品質の高いシステムが提供できるわけです
客先が業務への影響範囲を検証するなら、当然客先の業務リソースが使われるんだから、「同じ金を払っている」という話にはなりません。
客先負担を前提として、システムを提案するっていうなら、それを含めて最初に査定して契約しないといけないでしょう。
仕事がすでにある、予算がきまってるという前提で、そこから相談して決める話ではないです。
Re: (スコア:0)
既に予算が決まってる案件の方が圧倒的に多いですね
予算は決まってるから機能の追加要望や特殊実装が必要な部分へのリソースは
本来増やせないはずですが、そこから要件定義に入ったりして、当たり前のように
機能は増えます
で、〆切と使えるマンパワーは変わりません(予算は決まってますからね)
だからソフト屋やSEって立場で出来ることは選択の提案になるんですよ
その辺を理解せずシステム化って案件で「俺は客だ。金払ってるのんだからシステム化で
要件定義からワークフロー改善とそのリスクヘッジまでまで全部お前らやれ」って
そんなやりかたしたら失敗するか、紙の計算機化しか成功しないパターンが
多くなるのは当然だと思いますね
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
あなたの言っていることは、300円でカツ丼を提供するという約束をしながら、300円で足りるように卵かタマネギかかつのどれを選ぶか考えましょうなんて言い始めるのと一緒だよ？
客からしたら営業もSEも関係なく、おたくの会社と取引してるんだよね、いくら払ったらどれだけのものを実現するっていう契約をしているわけだよね。で、完成させることが債務になってるわけだよ
予算が決まっているなんてのはあなたの会社の都合であって、お客さんにとっては関係のない話でしょう？
Re: (スコア:0)
>＃そろそろ本気でウォーターフォールを何とかしないといけないと思う
現場で開発していないような人が声を大きくして批判するから、一般的によいイメージをもたれていないみたいですが、
ウォーターフォールがよくないというのは、ただの都市伝説ですよ。
どんな開発でもふたを開ければウォーターフォール型をこなすことになりますし、
*ちゃんと*手順を踏んでいれば通常失敗しません。
ウォーターフォールで失敗している例は、単純に見切りだけでどんどん先へ進むとか、コンサルが腐っていて決めるべきところを全然きめない、旗を振らないといった開発工程とはまったく関係ない要因が原因であることがほとんどです。
(まぁこちらは個人的な経験談ですが)
あと、デスマの原因として
営業さんのせいで本来は不必要な仕様書が納品に含まれていて工数がたりないとかはたまにありしたが。。。
# 単金あげるためにいらん設計書をつくらせるのやめてほしい；；
# 内部設計なんてソースあればいいじゃないか！
Re: (スコア:0)
>ウォーターフォールで失敗している例は、
>単純に見切りだけでどんどん先へ進むとか、
>コンサルが腐っていて決めるべきところを全然きめない、旗を振らないといった
>開発工程とはまったく関係ない要因が原因であることがほとんどです。
そういうのが常態化しているならウォーターフォールも不適なんだからなんとかしないと、
という話でしょ。
残念ですが、現実の問題を理想論の話にすり替えてウォーターフォールを擁護しているようにしか見えません。
それって「常に下流が氏ね」でしかありませんしね。
Re: (スコア:0)
やー、残念なことにそういう体質のところはウォーターフォールにしようがなんにしようがどーにもならんので、なんともなりません。
元請が馬鹿なら下請けが全権奪取出来る開発システムでもあるのなら、話は別ですが。
Re: (スコア:0)
>*ちゃんと*手順を踏んでいれば
※ただし、ちゃんと手順を踏むところに限る
という事ですね。