図で感覚的に理解するウォーターフォール開発手法、インクリメンタル開発手法とアジャイル開発手法
システム開発手法はいろいろと存在するのはビジネスニーズに合わせて実現する為の手段として必要だからであって、システムエンジニアの開発者側の好き嫌いではないことはすでにご理解のとおりですね。
このエントリでは、実際のシステム開発では「機能の開発をシーケンスではやらないよ」とかあるでしょうがそういった工夫は一切を棚に上げています。だってそういった工夫をしなければならない理由は多すぎますから。
ある時期にシステムがビジネスの一部として利用が必要であるとき、その当初のスコープを図にすると下図のようになりますよ。
ウォーターフォール開発手法
当初のスコープの範囲
図のAはビジネス要件すべてが当初のスコープになっていることを図示しています。ですから、３×３×３の枡合わせて２７つの枡を最初から作ることになるんですね。大変そうです。
システムの利用可能時期
システムが利用できる時期は、２７個の枡が揃ったタイミングになります。
利用できるシステムの機能数
ご安心ください。システムの利用開始可能なタイミングからすべての２７の機能が利用可能です。
メリット
全体の世界観が当初から描けます。だって、全体がスコープですから。ある意味、この業務に対する最適化されたシステムが実現できます。
デメリット
２７個の枡が出来上がるまで「ハウス！」と待て状態です。待つことができればデメリットにはなりません。
プロジェクトマネージャ
調整がお仕事です。はい。スコープが広い、時間軸が長いが特徴のプロジェクトですから、要素が多い。それだけリスクが発現する可能せいも高いのです。常にリリース時期までを見通す意識が必要です。
インクリメンタル開発手法
当初のスコープの範囲
図のBは、３層の一番下の１層を指していますから、図の枡の全体のうち、1/3のみの枡分の機能を実現することになりますね。残りの部分については３層目の実現後に検討することになるでしょう。
システムの利用可能時期
システムが利用できる時期は、９つの枡が完成した時期から利用できますよ。ウォーターフォールに比べたら早いですね。比率でいえば1/3の期間で利用できるわけです。
利用できるシステムの機能数
Bでは、全体の1/3の業務が当初のスコープになりますから、システム化対象となる業務も1/3になります。その他は引き続き人力で対応してください。
メリット
感覚的ですが1/3の機能を実現すると6割くらいの業務をカバーできているはずです。もうちょっとかもしれません。とにかく、そのくらいの感覚です。このスコープをもうひとつ実現するとほぼ業務をカバーできます。ただし、痒いところには手が届かないシステムです。割り切って使うことが前提です。
デメリット
層を追加するときに先に作る１層目の層を設計する際に、２７個の枡を想定したグランドデザインが描けるか、というところです。描くことができなければ大手術をするかスクラップアンドビルドになります。いわゆる共通基盤や機能のインタフェースを設計できていないとつらたんですね。
プロジェクトマネージャ
規模的にプレイングマネージャになる可能性もあります。そうした際にマネージャとしての仕事を忘れないようにしないとプロジェクトは破綻しますので。
アジャイル開発手法
当初のスコープの範囲
層の位置は見易さの為だと思ってください。いずれにしろ、２７個の枡のうち３つだけを作るのが当初のスコープになりますね。２７個の枡のうち、３つを選ぶのも大変そうですけど上手に選べるかな。
システムの利用可能時期
インクリメンタル開発と比較すると1/3です。ウォーターフォール開発と比べると1/9です。当たり前ですが、それは早い開発期間になるわけです。
利用できるシステムの機能数
ウォーターフォール開発と比較するると利用できる機能は1/9ですね。ビジネスニーズとしてこの３機能から必要だ！となれば、ビジネスに対する貢献するタイミングも早いことがわかります。
メリット
もう、すぐに使える！でしょう。当初スコープを決めている時点で部分機能開発ですから、割り切っているので。
デメリット
２７個の枡の全体を考えたアーキテクチャーを描けるかってところでしょうか。時間の制約としてのプレッシャは短気ですから心理的に一番強いですし、個別最適化となっても仕方がないかと。
プロジェクトマネージャ
アジャイル開発だとプロジェクトマネージャは置かないのですけど。それって全員がプロジェクトマネージャを兼ねられるスキルが必要ってことですよね。スクラムだったら、全員とはチームメンバとスクラムマスターですが。
共通してあること
どのシステム開発手法でも共通にあるのは、プロジェクトマネジメントを管理するという観点です。これはビジネスニーズとしてあるわけで、システム開発手法だけではシステム開発は成り立ちませんので。
必要ないというなら、なぜ、ビジネスニーズに合わせた高速開発が必要だというのか答えられなければいけません。何においても、すべてはビジネスサイドからの要求です。ビジネスニーズとしてシステム化を実現する必要があるなら、それを実現できているかというマネジメントのニーズがあるのは当然のことです。
