Xで、「工程をやたら分けるから、それしかできないエンジニアが生まれる」「エンジニアは全部経験できる会社に行くべき」という主張がある一方で、「大規模開発では工程分割は不可避」「海外の巨大テックは日本式の工程分割をしていないだけで、役割分担はしている」といった論争を見かけました。
https://x.com/i/status/2004156853446758480
個人的には、
・案件規模（小規模／大規模）
・受託／プロダクト
・立ち上がりフェーズか、スケールフェーズか
を分けずに語られているのが混乱の原因に見えます。
みなさんは、開発における「工程分け」についてどう考えますか？
確かに。議論の前提を揃えてないからそうなる気がする。
アメリカのソフトウエア会社でも受託開発だったらウォーターフォールみたいな開発手法だし国柄の問題よりもビジネスモデルの違いが大きいんじゃないかな
同意です。結局、工程の是非や国柄ではなく、受託かプロダクトか、変更頻度や不確実性といった前提次第ですよね。前提を揃えないと議論が噛み合わなくなると思います。
ビジネスモデルに応じて開発のやり方変えましょうでおしまいな気がします。
例えば年に1回リリースするビジネスと、週に2-3回リリースするビジネスは同じやり方にならないと思うので。
WFきっちりやるとそれなりにお金かかるのでそれでもペイする領域じゃないと使えないねというのは思いますが。
ウォーターフォールは、1960年代の軍事・宇宙分野の、要件が事前にほぼ確定しており、変更コストが極端に高いソフトウェア開発を説明するために整理された考え方ですよね。
その前提が崩れる、アジリティ前提のプロダクト・サービス開発にそのまま当てはめると噛み合わなくなるのは自然だと思います。
基幹システムをアジャイルチックにできるならやってほしい。
やってほしいというか、まずやる計画を日本企業の役員に承認させることができる人を見てみたい。
たぶん、ウォーターフォール否定派はそういうビジネスや政治、予算の取り方の視点が欠けてる技術に自信ニキな気がする。
フェーズというよりも、不確実性がどのくらい高い領域かによってどこまで詳細に設計するかが変わります。
この不確実性は主に目的不確実性と手法不確実性の2つに分けられます。
スタートアップがやるようなビジネスでは、本当にそれが売れるのか・スケールするのかという目的不確実性が高く、それに対して実装したことがある人が少ないという手法不確実性も高いことが多いです。
よってスタートアップでは、網羅性を重視するWBSベースのWFはROIが悪くなり、自然とアジャイルが適するようになります。
一方、すでに競合が複数いて売れる・スケールすることや市場の獲り方も明確で、作り方もある程度解像度が高いプロダクトでは、札束で叩けば勝てるのでどちらかというとWFに近くなります。
不確実性の高低で適切な手法のグラデーションが変わるということですね。
このあたりはエンジニアリングマネジメントの領域ですね。
