いわゆるJTCなどと呼ばれる会社のITは今なおウォーターフォール型の開発プロセスが主流であり、正義である。
ウォーターフォール型の開発モデルは、ソフトウェア開発プロセスが一連の連続した段階（要件定義、設計、実装、テスト、デプロイ、保守）で構成されており、各段階が完了するまで次の段階に進まないという線形的な進行を特徴としている。
本記事ではウォーターフォール型の開発モデルのメリット、デメリット、そしてなぜ現在決別しなければならないかについて私の持論を述べたい。
ウォーターフォール型開発モデルのメリット
ウォーターフォール型の開発モデルには一般的に次のようなメリットがあると考えられる。
1.管理の容易さ:
a. シンプルなプロセス: 線形で一方向に進むプロセスが管理や進行を容易にする。
b. 事前計画の重視: 開発期間やコストの見積もりが容易になり、プロジェクト管理がしやすくなる。
2.成果物とドキュメンテーション:
a. 明確な成果物: 各フェーズで明確な成果物が定義され、進捗状況を容易に把握できる。
b. ドキュメンテーションの重視: プロジェクト情報が整理されやすく、知識の引き継ぎが容易になる。
3.開発チームの効率:
a. 各段階の専門性: 各フェーズが独立しているため、チームメンバーは自分の専門分野に集中できる。
b. 責任範囲の明確化: 各フェーズの成果物や役割が明確になるため、責任範囲がはっきりする。
4.過去の成功事例:
a. 工業分野での成功: 過去の工業分野や建設業界でのプロジェクト管理手法として成功を収めていた。
b. 伝統的な手法: 長年にわたって実績があり、組織やチームがその方法に慣れ親しんでいたため、採用されやすかった。
一般的に言われているウォーターフォール型の開発モデルの現状
一方で、現在において、ウォーターフォール型の開発モデルは、従来の利点にもかかわらず、その存在感が薄れている状況にある。その理由は、ソフトウェア開発の環境が急速に変化し、新たな開発手法が台頭してきたことによる。特にアジャイル開発やスクラムといった手法は、短期的なイテレーションを重視し、顧客との密なコミュニケーションを取り入れた開発が可能である。これにより、顧客の要求に迅速に対応し、開発プロセス全体の効率化が図られる。
しかし、ウォーターフォール型の開発モデルが完全に廃れたわけではない。一部のプロジェクトや業界においては、要件が明確で変更が少なく、計画性が重視されるケースが存在する。このような状況では、ウォーターフォール型の開発モデルが適切な選択肢となることがある。また、従来のウォーターフォール型の開発モデルにアジャイルな要素を取り入れることで、ウォーターフォール型の開発モデルも変化に対応できるよう進化している。
このような状況で、ウォーターフォール型の開発モデルは、その独自の利点を生かして適切な状況で活用されることがあり、その一方で、アジャイルな手法に取って代わられるケースも増えている。
開発手法を選択する際には、プロジェクトの性質や要件に応じて、最適な手法を選択することが重要である。
等と言う事が言われており、ウォーターフォール型の開発モデルがまるで適している場面が存在するかのように語られている場面を目にすることがある。
しかし、適材適所、場面に応じてウォーターフォール型の開発プロセスを使うという事が本当に可能なのか
このような疑問を投げかけておいて、恐縮だが、可能か不可能か？という問いであれば可能である。ただしそれは、人間の想像・想定出来る事の中に不可能性が証明できる事などほとんどないというのと、ほとんど同じ意味である。
私の持論では、現在のIT環境において業務利用を前提とした予算数千万以上のある程度の規模のシステム開発プロジェクトにおいて、ウォーターフォールモデルで大成功を収める事は、既にほとんど不可能であり、今後よりその傾向は強くなっていくであろうという事だ。
ウォーターフォール型の開発プロセスでプロジェクト成功が殆ど不可能なシンプルな理由
ウォーターフォール型の開発プロセスのデメリットとしてよく語られる事として変更への耐性が低いという話がある。これは正しいが、ウォーターフォール型の開発プロセスでプロジェクト成功が困難な理由は少し異なると考えている。
変更への耐性が低いというのが理由であれば確かに、要件定義をしっかりやったり、要件変更が発生しにくい様なプロジェクトでは今後もウォーターフォール型の開発プロセスが適している場面が存在するという事になる。
だが、私の考えるウォーターフォール型の開発プロセスによる成功が不可能である、又はそうなりつつあるというのは、もっとシンプルな理由である。
それは一言で言えば時代の変化、ソフトウェア開発の置かれた環境の変化である。
その環境の変化の結果、現代のソフトウェア開発は優秀なPMやSEが予測できるボリュームをはるかに超えてしまっているのだ。
それはどの様な変化か？
1.過去のシステム開発
ウォーターフォール型の開発プロセスが通用していた時代のソフトウェア開発というのは、一人のエンジニアが数か月かけて1万行のコーディングを行う。極論すればそんな規模の物であった。
故にウォーターフォール型のプロセスで全ての要件を定義し、プロジェクトの落としどころを見通し、計画を立案し、計画通りに進める、という事が優秀なエンジニア・プロジェクトマネージャーには可能であった。
2.現代のシステム開発
しかし現代のソフトウェア開発のいうのは全く違う。例えばWEBのクライアントサイドの開発で新人プログラマが、
<script type="text/javascript" src="js/jquery-X.X.X.min.js"></script>
などと1行やっただけで凡そ1万行のコードが裏で動くことになる。実際のプロジェクトではほかにも幾つもライブラリが使われる事が通例であろうし、パッケージ開発であればそのパッケージはそれこそ膨大な行数のソースコードで構成されている。
昨今流行のローコード開発等になれば尚のことである。
1つのプロジェクトにおいて、1人の技術者が適正にコントロールできるプログラムのステップ数はおおよそ1万行と言われる。過去のシステム開発においてはそれの範囲を把握していれば、ウォーターフォール型のプロジェクトに必要な見通し、計画立案が出来た。
しかし、現代のソフトウェア開発は先ほどの例の通り、1行の裏に数万行のロジックが隠されているのが通例である。
当然ながらライブラリをIncludeしたからと言ってすべての機能をシステムからコールするわけではないし、共通的なライブラリを使う事でバグを作り込みにくくなるというメリットはある。パッケージもローコード開発ツールもこなれた部品を使ってバグが減る可能性もあろう。
ただし当たり前だがLibraryもパッケージのソースも、開発したいシステム専用に作成されたものではない以上、想定外の動作をしたり、開発元では想定外の使い方をしてしまう可能性が出てくる。
これらをすべて把握、管理、予測することなど誰にも不可能である事はもはや自明である。
つまるところ、現代のソフトウェア開発というのは、ウォーターフォール型の開発プロセスが成り立っていた時代と違って、どんなに優秀なPMやSEであっても全容を把握し、結末を予測し、全体の計画を立てる事の出来たボリュームを遥に超えてしまっているのが、通例であるという事である。
結論
故に、ウォーターフォール型のシステム開発プロセスで開発プロジェクトに挑む事はもはや”無理ゲー”と言える時代が到来しており、今後もどんどんそのような傾向は強くなるばかりであるという事である。
にもかかわらず、現場では相変わらずウォーターフォール型の開発プロセスを前提に予算を確保させ、プロジェクトを実行させ、自明の炎上・失敗の責任を問い、原因と対策を立案し、不可能な開発プロセスを見直すことなく、
- 要件定義のできる人材を育成しよう
- テスト工程の品質を向上させよう
- スキルの底上げ、人材育成
等と言う聞き飽きた施策が強要され、疲弊していくという儀式が繰り返されている。
なぜこのような事が繰り返されるのか、それはコードも書いた事のないど素人がマネジメントとして君臨している、技術者軽視の末路である。
0 件のコメント:
コメントを投稿