アカウント名:
パスワード:
ほぼ予定通りに比較的大きな規模のウォーターフォール型プロジェクトが終了した（とされた）例をいくつか見ていますが、下記のような流れでした。
BI～BDはエンジニアの埒外で実施され、基本的に過去の例の焼き直しに最低限の追加だけで要件が詰められていない。FDはさすがに上級エンジニアが作成に参加しているが、不完全なBDを元にしているのでそれに従えばゴールだとは誰も思っていないが口には出さない。DDは下請けが納入ドキュメントを作成する（でっち上げる）作業であって製造のための詳細設計ではない。Mの段階でも下請けは出来上がるものは見えていないが単体・総合試験項目は決められるので、それを通すことだけを目的に製造する。UT、SIは淡々と進めるが、往々にしてこのあたりで客先との会議でBI・BDの不備がいくつか発見（！）されて仕様が追加されるが、残業でなんとかする。PT、RTの段階でBD・BI不備が致命的であることが客先との共通認識となり、（末端の人間にとっては）予定通りに緊急事態に陥る。
ここで大規模プロジェクトが違うのは、まがりなりにもそれなりに能力が高い人間が揃っていること、有害なまでに縦に長い組織になっているが他業務兼任者が少ない、つまりマンパワーに質量ともに潜在的な余裕があるところと末端のメンバーの責任感（というか耐久力というか、とにかく逃げないこと）です。
この後どうなるかというと客先担当者から末端の製造担当、試験担当、文書作成担当まで現場に横並びになり、ウォーターフォール開発がライン生産方式に変貌します。1日にウォーターフォールを何回転もさせる状況はむしろアジャイルなんじゃないかと思いますが。
もちろんこれを休日返上、現場に缶詰めで実行したとしても全てが解決するはずもないのですが、交渉によってひとまず客先の受入れ判定をパスできる要件を最低限に引き下げ、優先度が低い開発未完了項目は本番障害として管理され、運用維持として再編された開発チームが引き続き開発を行うということで納められます。
これで業務としてのプロジェクトが利益を生んだとしても、ウォーターフォール開発の実践例としては最低の部類だと思います。プロジェクト管理としては失敗だらけで、それを末端の個人の努力、しかも原動力は金銭的なインセンティブや忠誠心などといったものではなく、失敗を受け入れない文化と硬直した雇用市場からくる強迫観念といったネガティブな動機で解決した例でしかないからです。
ただ、こういった展開が期待できるのはある程度の能力、社会的地位、収入がある20代後半の日本人を相手にした場合で、徐々に通用しない場面が増えてきています。これからは恵まれた環境の大企業でもプロジェクト管理を本当にすることが必要となり、管理技術の水準も高める必要性が増してくると思います。
通常は中小企業よりも大企業の方が先進的な技術、手法の研究や導入に熱心なのですが、日本のIT企業においては逆に大企業こそ旧来の日本の商慣習に則ったビジネスを展開しているのがおもしろいと思います。
なんで＞同じようなことは、すでに80年代から言われているのですが、一向に改善しないところを見るとという認識から
＞日本的ウォーターフォールは、ある程度、洗練され機能していると見た方がいいのかもしれませんね。という結論が導かれる？
年金問題とか少子高齢化とか天下りとか、一向に改善されないけど、それのどこが洗練されているんだい？
元コメント投稿者です。興味を持たれたようですので、なぜそのような旧態然とした仕組みが生き延びているかについて自分の考えを捕捉します。
まず認識の問題としてわたしは80年代当時と同じものが今も現実として展開していると捉え、その事実が今後も安定的であるとは思わない方がいいと考えています。同じIT系大企業でもビジネスの対象、規模、速度は違っていますし、商品としてのITシステムの構成要素、成り立ちも大きく変わっています。
プロジェクトの管理手法というものはビジネス全体を満足させるための手段で、組織の上部、ビジネスの構造の高い次元か
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
日本的ウォーターフォール開発の実際 (スコア:2, 興味深い)
ほぼ予定通りに比較的大きな規模のウォーターフォール型プロジェクトが終了した（とされた）例をいくつか見ていますが、下記のような流れでした。
BI～BDはエンジニアの埒外で実施され、基本的に過去の例の焼き直しに最低限の追加だけで要件が詰められていない。
FDはさすがに上級エンジニアが作成に参加しているが、不完全なBDを元にしているのでそれに従えばゴールだとは誰も思っていないが口には出さない。
DDは下請けが納入ドキュメントを作成する（でっち上げる）作業であって製造のための詳細設計ではない。
Mの段階でも下請けは出来上がるものは見えていないが単体・総合試験項目は決められるので、それを通すことだけを目的に製造する。
UT、SIは淡々と進めるが、往々にしてこのあたりで客先との会議でBI・BDの不備がいくつか発見（！）されて仕様が追加されるが、残業でなんとかする。
PT、RTの段階でBD・BI不備が致命的であることが客先との共通認識となり、（末端の人間にとっては）予定通りに緊急事態に陥る。
ここで大規模プロジェクトが違うのは、まがりなりにもそれなりに能力が高い人間が揃っていること、有害なまでに縦に長い組織になっているが他業務兼任者が少ない、つまりマンパワーに質量ともに潜在的な余裕があるところと末端のメンバーの責任感（というか耐久力というか、とにかく逃げないこと）です。
この後どうなるかというと客先担当者から末端の製造担当、試験担当、文書作成担当まで現場に横並びになり、ウォーターフォール開発がライン生産方式に変貌します。1日にウォーターフォールを何回転もさせる状況はむしろアジャイルなんじゃないかと思いますが。
もちろんこれを休日返上、現場に缶詰めで実行したとしても全てが解決するはずもないのですが、交渉によってひとまず客先の受入れ判定をパスできる要件を最低限に引き下げ、優先度が低い開発未完了項目は本番障害として管理され、運用維持として再編された開発チームが引き続き開発を行うということで納められます。
これで業務としてのプロジェクトが利益を生んだとしても、ウォーターフォール開発の実践例としては最低の部類だと思います。プロジェクト管理としては失敗だらけで、それを末端の個人の努力、しかも原動力は金銭的なインセンティブや忠誠心などといったものではなく、失敗を受け入れない文化と硬直した雇用市場からくる強迫観念といったネガティブな動機で解決した例でしかないからです。
ただ、こういった展開が期待できるのはある程度の能力、社会的地位、収入がある20代後半の日本人を相手にした場合で、徐々に通用しない場面が増えてきています。これからは恵まれた環境の大企業でもプロジェクト管理を本当にすることが必要となり、管理技術の水準も高める必要性が増してくると思います。
通常は中小企業よりも大企業の方が先進的な技術、手法の研究や導入に熱心なのですが、日本のIT企業においては逆に大企業こそ旧来の日本の商慣習に則ったビジネスを展開しているのがおもしろいと思います。
Re: (スコア:0)
日本的ウォーターフォールは、ある程度、洗練され機能していると見た方がいいのかもしれませんね。
当時も、今の方法は新人類には通用しないだろう的なことが言われていました。
新人類も今じゃ40代後半？
Re: (スコア:0)
なんで
＞同じようなことは、すでに80年代から言われているのですが、一向に改善しないところを見ると
という認識から
＞日本的ウォーターフォールは、ある程度、洗練され機能していると見た方がいいのかもしれませんね。
という結論が導かれる？
年金問題とか少子高齢化とか天下りとか、一向に改善されないけど、
それのどこが洗練されているんだい？
Re: (スコア:0)
持ちこたえられる落としどころが見つかれば、それはほぼ現実的にはベストな解答。
天下りとか年金とかも、まだまだ改善の余地はあるとは言え、
20年前と比べるとずいぶん洗練されてきているのはわかるだろ？
Re: (スコア:0)
元コメント投稿者です。
興味を持たれたようですので、なぜそのような旧態然とした仕組みが生き延びているかについて自分の考えを捕捉します。
まず認識の問題としてわたしは80年代当時と同じものが今も現実として展開していると捉え、その事実が今後も安定的であるとは思わない方がいいと考えています。同じIT系大企業でもビジネスの対象、規模、速度は違っていますし、商品としてのITシステムの構成要素、成り立ちも大きく変わっています。
プロジェクトの管理手法というものはビジネス全体を満足させるための手段で、組織の上部、ビジネスの構造の高い次元か
Re: (スコア:0)
「ドタバタ喜劇」的仕事のやり方は、全然変わっていない。
だから「今が変化点」かというと、ちょっと違う気がする。かといって昔に変化点があったとも思わない。
おっしゃる通り、IT産業がジリ貧な市場であることは確かで、産業自体のしぼむ速度が「ドタバタ喜劇」で
致命的失敗が目に見えるようになるよりも早いと思います。
きちんとしたプロジェクト管理は今後ますます必要ですが、しぼむ速度としぼんだ先を見据えられないと、
過大な管理システムばかりが残りそう。