[#TiDD] ウォーターフォール型開発をアダプタブルにする３＋１

開発全体を複数の工程に分けて段階的に開発するウォーターフォール型(WF)開発は、そう名付けられた時から多くの問題点が指摘されてきました。しかし、大規模な開発や平行開発などでは計画性が求められる事、監査の観点や人材の有効活用の観点などから、いまだに多くのWF開発が行われています。

しかし技術の進歩が早くなるに従って、従来通りの開発方法ではメリットよりもデメリットが多くなってきました。それはWF開発が必要でなければアジャイル開発で解決できるかも知れませんが、上に挙げた理由でWF開発を続けるのであれば、何らかの対策が必要になります。

以下に挙げた方法はWF開発をアダプタブルにするものです。すでに実践されている方も多いと思いますが、アダプタブルにするという視点で整理してみました。

マルチリリース

WF開発の最も大きな問題はリリースが1度だけである事です。UI/UXやシステムの性能など実装しないとわかりにくいものを、たった1度のリリースで完成させる事は困難です。正式なリリースでなくても、最終リリースまでに動作を確認すれば、よりよくすることが可能でしょう。

マルチリリースの方法も効果も様々ですが、以下に示す様にWF開発よりも明らかに変化に対応できる様になります。

• [#TiDD]ウォータースクラムフォールよりも五月雨WFの方が変化に強い！(かも)
• [#TiDD] アジャイル風開発ラフシミュレーション

リスクベース

ソフトウェア開発の難しくて面白いところは、作業の進め方でリスクが変わることです。作業を分解して段階的に開発するだけではうまくいきません。

各作業に隠れているリスクを分析して、以下に示す様に、作業の順序を変更する、リスクを低減する作業を組み込む、などして開発のリスクを低減します。

• リスクベース私論 - リーンソフトウェア開発とプロダクトラインから考える -
• 実装優先時の考慮点 その１ - プロトタイピングとスパイクソリューション -

補完型チケット駆動開発

社会情勢によって仕様変更されることや、平行開発されているシステムとの擦り合わせの結果としてインタフェースを変更する事もあるでしょう。このような変更が無秩序に発生すると、現在の作業が混乱するだけでなく、変更作業にも漏れが発生しやすく、プロジェクトは収拾がつかなくなってしまいます。

補完型チケット駆動開発は、当初のスコープからこぼれ落ちた作業をチケット化しますので、このような変化をリアルタイムに情報共有できます。また、チケットは類似のプロジェクトでも利用可能ですので、苦労した経験が蓄積されます。

• [#TiDD] 補完型チケット駆動開発で外乱に強い組織を作る
• [#TiDD] キャズムを超えつつある!? チケット駆動開発 - デブサミ2013発表を終えて -

サーバントリーダーシップ

WF開発でこぼれ落ちる水滴は、上に挙げたように、実現方法、環境、ドメインのリスクが顕在化したものです。問題の発見が遅れれば被害は大きくなりますので、いかに早く気付けるかが、プロジェクトの成功要因です。

どんなに優れたリーダーであっても、全ての方面に詳しいわけでなく、経験にも偏りがあるでしょう。サーバントリーダーシップによるチームづくりをすれば、知恵を出し合うことが可能になるでしょう。

• アジャイル開発への壁は価値観の壁
• サーバントリーダーシップで「和」（ハーモニー）を実現する
• クリティカルチェーンの定義から小規模プロジェクトの難しさを考える

今年で最後といわれているUAS 5にはこれらをアジャイル開発の考え方と絡めて書いてみようかと思っております。

今年はこのほかにも、ソフトウェアシンポジウム(SS2015)では補完型チケット駆動開発の経験論文とワーキンググループをする予定ですし、 ソフトウェア品質シンポジウム(SQiP2015)ではあきぴーさんとチケット駆動開発のチュートリアルを予定しています。これらの発表の機会を利用して、皆さんと意見交換させていただきたいと思っています。