サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン
以下、３部作の２本目です。
前回と今回のシリーズはカテゴリ プロジェクトマネジメント論にまとめてます。
単一の開発手法の限界からハイブリッド方式へ
前回、各開発手法は失敗プロジェクトの反省から、それぞれ本質となる改善要素を持つことを示しました。
アジャイル開発であれば、フォーカス分割。
これらは排反する概念ではなく、それぞれの利点を活かしてプロジェクト運営を行うことが、より効率的なプロジェクト運営につながると考えられます。
とはいえ、ハイブリッドとなると組み合わせが無限に考えられます。
そこで、幾つか見た成功例を元に、マネジメント・デザインパターンを提唱したいと思います。
マネジメント・デザインパターンとは、要はソフトウェアデザインパターンと同様に、プロジェクトマネジメントにおける開発手法の適応例を蓄積、再利用可能な形に標準化しようというオッサンなりの試みです。
ちなみに、オッサン一人で勝手に言ってる造語。。。
GoF（Gang of Four）ならぬOoO（Ossann of One）ですね。
プロジェクトの適正に合わせて、ハイブリッド開発手法を上手く選択することで、プロジェクトマネジメント効率を高めることが期待できると思います。
以下、いくつかの事例をご紹介したいと思います。
マネジメント・デザインパターン事例集
ウォーターフォールベースのスクラム／ウォーター・スクラム・フォール
WFの要件定義とシステムテスト・リリースだけ残し、開発をアジャイル（スクラムなど）でおこなうことで生産性を高めたデザインパターンです。スパイラルモデルに近く、SIerなどで導入しやすということで最近注目のデザインパターンです。
以下の本が有名。
- 作者: 英繁雄,奈加健次,平岡嗣晃,前川祐介,長瀬嘉秀,関西電力株式会社協力
- 出版社/メーカー: リックテレコム
- 発売日: 2013/10/05
- メディア: 単行本
- この商品を含むブログ (1件) を見る
特徴
- 上流設計の形式知化により、アジャイルでは苦手なフォーカス分割の困難な大規模基幹システムでも対応できるようになる。（基本設計段階ではフォーカス分割できなくても、詳細設計レベルからは分割するのは容易）
- 開発プロセスにアジャイルを採用しており、漸進的な開発を行うことで障害や設計修正などへの対処が早い
- アジャイルの暗黙知を使ったチームマネジメントを利用することで、詳細設計レベルのドキュメント類の軽減化ができるため、作業量の削減により生産性向上が図れる
得意案件
- 大規模システム構築で一括納入が必要となるようなクリティカルな案件。
リーン開発のフォーカス管理を利用したウォーターフォール／リーン・ウォーターフォール
オッサンが一番好きなデザインパターンです。
要求仕様をリーン開発と同様に分解、優先度付けを行い、優先度の高いものからWFで開発を行うことで柔軟性を高めたデザインパターンです。
開発部分を五月雨式WFなどと併用して更に速度を上げることもあります。
特徴
- アジャイルのフォーカス分割を利用することで、要件変更に対して柔軟に対応できる
- 開発プロセスが形式知化されているため、ベンダロックインを防ぎ、メンバーの急な増減や遠距離開発に対応することができる
- アジャイルよりは遅いものの、開発フォーカスが分割されているため、高速な初期リリースが行える。
得意案件
- 小規模多数型の、案件変更の多いシステム構築。特に細かい業務要件が入り組んだシステム開発向き。
複雑なシステムを分解／スクラム＆ウォーターフォール
最初の要件定義だけを行い、要件のウチ変更の多い部分と変更の少ない部分を分け、それぞれを平行して開発するデザインパターンです。
WEBと基幹システムのような形質が違うシステムが混在しているような場面で効果を発揮します。
※ただ、大体の場合は契約を分けることが多いので適応例は少ないですね。。。
特徴
- WF、アジャイルそれぞれの長所を活かすことができる
- フォーカス分割できない業務が混ざっていた場合でも対応可能
- システム全面刷新など、巨大な案件でも対応可能
得意案件
- ECと実店舗業務システムの改修、アプリケーションとインフラのような性質の異なるシステム要件が混在した案件
オマケ）期間短縮を目指した改良型ウォーターフォール／パラレル・ウォーターフォール
WFとアジャイルのハイブリッドではなく、WF単体の組み合わせです。前回、五月雨式WFを説明いたしましたので、オマケで。
ベースはWFですが、中間の開発～テスト工程を分割可能な機能単位などに分解し、並列開発を行うデザインパターンです。純WFよりも、開発工程をパラレルにした分だけ開発期間短縮を行えることがポイントです。
特徴
- 大規模な案件の最終リリースまでのスピードが速い
- 障害などの機能設計ミスに対して比較的強い。要件変更には弱い
- プロジェクトマネージャに対する負荷がとことん大きい(このため、プロジェクトマネジメントをチーム制で行うこともある)
得意案件
- 大規模請負案件でよく使われる
他にもいろいろありますが、今日はこんなところまで。
ちなみに、ネーミングは最初のウォーター・スクラム・フォール以外はオッサンの命名なので悪しからず。
まとめ
まあ、いろいろとマネジメント・デザインパターンを列挙してみました。
このように、単一、複数の開発技手法を複合させることで、多種多様なプロジェクトに柔軟に対応できるようになります。
アジャイルでは苦手と言われる請負契約や、オフシェア開発に対応できるようになったりしますし、WFでは苦手と呼ばれる要件変更や短期リリースにも自然と対応できるようになります。
また、WF単体でも、五月雨式WFやパラレル・WFのように、時代に合わせて姿形を変えて最適化を目指してます。
よく、WFは過去のもの。これからはアジャイル開発を覚えれば良い！なんていう声があります。
ただ、それはアジャイル開発を銀の弾丸として期待しすぎじゃないかなって思います。
種々の開発手法の持つ本質を理解し、得意苦手を補完できるよう複数の手法を組み合わせ最適なデザインパターンを作り出すことこそが、優れたプロマネの資質なんじゃあないかなって思います。
次回、 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ
以上
