ウォーターフォール開発とアジャイルの本質
以下、３部作の１本目です。
度々話題なる開発手法、ウォーターフォール開発（以下WF）とアジャイル。
それぞれの違いってなんだろうと思い、ちょっと本質について普段考えていることをまとめてみました。
ウォーターフォール開発の本質とはなにか？
システム開発を行った方なら一度は耳にすることがあるWF。
各開発工程を順序良くこなしていく開発手法となります。
イメージにすると以下のとおり。
さて、WFのよく言われる特徴を以下眺めてみたいと思います。
最初に一括して要件定義を行うので、仕様変更に弱い
No。一括して要件定義を行うこと自体は、要件定義のやり方の問題です。一括して大きな要件定義を行うことがリスクであれば、分割受注を行えばよいだけです。仕様にリスクがあると判断できる場合、気の利いたシステム屋であれば、五月雨式WFを行います。
上記のように、対応範囲を絞った小規模のWFを並列開発する方式です。初期リリースで絞りきれなかった要件を２段階目、３段階目で拾うようにします。WFのリスク分散を行う手法として昔から使われる手法です。
※WFをベースにスパイラルモデル風味を加味した様な形になってますが、完全反復型ではなく、平行開発型であることがほとんどです。
手戻りによる再作業の工数が大きい
これもNo。設計のコアとなる部分で再作業が発生したら、WFだろうがアジャイルだろうが、修正は大変です。リスクを減らすのであれば、前述した五月雨式WFでコアな部分から開発すればOK。軽微な手戻りであれば、別に工数をかけずに修正できるのはWFも同一です。
※V字モデルに代表されるように、WFでは後工程のテストを念頭に開発を行っているため、実は手戻りを行うことは前提としてます。手戻りをどう対処するか、については開発手法の問題ではなく、リスク管理の世界の話です。
ドキュメントを大量生産する
これは部分的にはYesです。不必要なドキュメントは作らない、と言った点はアジャイルと同じですが、概してWFではアジャイルよりドキュメントが多くなります。これは、工程が明確に分かれているWFでは、開発工程間の情報の伝達を往々ドキュメントに頼るからです。
オッサンは、これをWFが形式知の作成を行うことで、開発体制と開発工程を管理する手法だから、と考えてます。
つまり、何を作るべきかと言った頭の中のアイデアを、ドキュメントなどにより形式知として発露し、次の工程に引き渡す。次の工程では前の工程から引き渡された形式知を使い、目標達成に必要な形式知を追加して次の工程に渡す。これの繰り返しによりソフトウェアを作り上げる開発手法となるわけです。
WFの本質とは
WFの中心にあるもの、それは「今作りたいシステムの形式知化」です。何を作りたいのか明確にすれば作れるだろう、という意思を感じます。
WFではドキュメントを作ります。だから、工程ごとの切り分けができます。開発メンバーの入れ替えにも強いです。請負や納品にも対応できます。
反面、形式化のためのコストが大きいです。ある程度全体像を見渡せるスキルのある人がいないと、ごちゃごちゃのドキュメントなどが作られたりしたら、とたんに形式知のメンテナンスコストが跳ね上がり、所謂WFの問題点と呼ばれる事象が発生することとなるわけです。
アジャイルの本質とは
WFばっかり考えていたら、時間がなくなってしまいました。。。
なんだかオマケみたいになってしまいましたが、アジャイルについても同様に本質を考えてみたいと思います。
で、こちらは答えから書いてしまいますが、オッサンの考えるにアジャイルの本質は「フォーカス管理の最適化」にあると思います。
ナンノコッチャって感じですが、要は、リーン開発手法がアジャイルの中心にあるものってイメージです。
スクラムなどは、リーン開発手法の実現方法になると考えてます。
よく言われる通り、アジャイルでは変化に強いと言われてます。要件を小さく分割し、反復期間を通じてソフトウェアを成長させていくモデルだからです。
アジャイルでは、一つ一つの開発工程自体はWFに比べて非常に小さくなります。
WFでは開発プロセスを形式知化することで開発工程を制御しようとしてましたが、アジャイルでは暗黙知でも十分に対応できるサイズで開発ができます。
このため、WFの様な工程の分離が不要で、設計→開発→テストをシームレスに対処できるようになります。
結果、暗黙知をもつメンバーを如何に活かすか、という観点が重視されるようになり、スクラムなど各種手法が生きてくるようになります。
てなわけで、オッサンはアジャイルの本質はなにか、と聞かれたらリーン開発手法に代表される最小限、優先付けによる開発タスクの細分化により開発フォーカスを制御して、各メンバーが最も開発に適した形にする開発手法です、と答えるようにしてます。
まとめ
WFとアジャイルについて、本質を考えてみましたが、これって所謂失敗プロジェクトのアンチテーゼになっていると思います。
プロジェクトが失敗する原因は数多ありますが、「皆の知識を見える化すればプロジェクトを成功できる」という考え方がWFであり、「できるところから少しずつ作ればプロジェクトを成功できる」という考え方がアジャイルです。
失敗プロジェクトとWF、アジャイルをそれぞれ特徴ごとにマッピングすると以下の様な図になります。
プロジェクトが失敗する条件から、一段階ずつ改善したのが純粋なWFとアジャイルであれば、更にもう一步踏み込み、WFとアジャイルの良いとこだけを抽出した開発手法を考えられます。
次は、WFとアジャイルをハイブリッドさせたハイブリッド開発手法について、考えてみようかと思います。
次回、
サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ
に続きます。
以上
