Ultimate Agile Stories Iteration 5への寄稿

1. 1
1
アジャイル開発に学んだアダプタブルウォーターフォール開発
阪井 誠
はじめに
Ultimate Agile Stories Iteration 5が最終回とのことなので、アジャ
イル開発の考え方がウオーターフォール型(WF)開発に活かせることを書
いてみたいと思います。
アジャイル開発とは何だったかを考えると、WF開発、より正確に表現す
るならWF開発をベースにしたプロセス監査の仕組みに対するアンチテー
ゼであったと思います。これはアジャイルソフトウェア開発宣言を読んで
みるとよくわかります。変化への対応、動くソフトウェア、顧客との協調、
個人と対話（順番を入れ替えています）を強調するだけでなく、その妨げ
になる可能性のあるものと対比して表現されています。
つまり、計画に従うこと、包括的なドキュメント、契約交渉、プロセス
やツール（同上）は大切だけど、それだけじゃうまくいかないよね。とい
っています。そして12の原則で彼らが実施している方法論を集約していま
す。つまり、価値観を実現する良さそうな方法を示しているだけなので、
価値観を実現する方法であれば特に実現方法を問う必要はないように思
います（実際にWFと呼ばれているプロジェクトよりもFDDの方がよりトッ
プダウンだったりします）。
そこで、WF開発をどうすればアジャイル開発のように変化に対応できる
ようになるかを考えて「アダプタブルウォータフォール開発」と名付けま
したました。
ウォーターフォール型開発をアダプタブルにする３＋１
開発全体を複数の工程に分けて段階的に開発するWF開発は、そう名付け
られた時から多くの問題点が指摘されてきました。しかし、大規模な開発
や平行開発などでは計画性が求められる事、監査の観点や人材の有効活用
の観点、などからいまだに多くのWF開発が行われています。

2. 2
2
いまだにWF開発がおこなわれているものの、技術の進歩が早くなるに従
って、従来通りの開発方法ではメリットよりもデメリットが多くなってき
ました。WF開発が必要でなければアジャイル開発で解決できるかも知れま
せんが、上に挙げた理由でWF開発を続けるのであれば、何らかの対策が必
要になります。
以下に挙げた方法はWF開発をアダプタブルにするものです。すでに実践
されている方も多いと思いますが、アダプタブルにするという視点で整理
してみました。特に意識したわけではなかったのですが、それぞれアジャ
イルソフトウェア開発宣言の価値観に対応しています。WF開発の問題点を
意識すると同じような問題に集約されるのでしょう。
マルチリリース
WF開発の最も大きな問題はリリースが1度だけである事です。UI/UXやシ
ステムの性能など実装しないとわかりにくいものを、たった1度のリリー
スで完成させる事は困難です。正式なリリースでなくても、最終リリース
までに動作を確認すれば、よりよくすることが可能でしょう。
マルチリリースの方法も効果も様々ですが、一度だけリリースする場合
よりも明らかに変化に対応できる様になります。これは、アジャイルソフ
トウェア開発宣言にある「変化への対応」を実現するものになります。可
能ならリリース間隔をそろえましょう。開発にリズムが出てくるので、開
発からリリースまでの作業が効率的になるでしょう。
計画に従うことは大切ですが、リリースすることで得られる学ぶ機会を
捨てる必要はありません。複数回のリリースによって学習しながら開発を
進めると良いでしょう。
リスクベース
ソフトウェア開発の難しくて面白いところは、作業の進め方でリスクが
変わることです。作業を分解して段階的に開発するだけではうまくいきま
せん。

3. 3
3
各作業に隠れているリスクを分析して、作業の順序を変更する、リスク
を低減する作業を組み込む、などして開発のリスクを低減します。たとえ
ば、ほかの部分に影響を与えるものは先に開発する、ほかの部分に影響を
受けるものは詳細に決めてしまわない、といった視点で開発順序を決めま
す。また、技術的な課題のあるものにはスパイク(調査や試作)、全てを作
ってからレビューやテストをせず、先行して部分的に確認します。
これは「動くソフトウェア」を実現する大切なポイントです。先に包括
的なドキュメントを書いたのでは、手戻りが増えて上手くいきません。
補完型チケット駆動開発
社会情勢によって仕様変更されることや、平行開発されているシステム
との擦り合わせの結果としてインタフェースを変更する事もあるでしょ
う。このような変更が無秩序に発生すると、現在の作業が混乱するだけで
なく、変更作業にも漏れが発生しやすく、プロジェクトは収拾がつかなく
なってしまいます。
補完型チケット駆動開発は、当初のスコープからこぼれ落ちた作業をチ
ケット化しますので、このような変化をリアルタイムに情報共有できます。
また、チケットは類似のプロジェクトでも利用可能ですので、苦労した経
験が蓄積されます。

4. 4
4
より良いソフトウェアを実現するには、契約範囲かどうかを交渉するよ
りも「顧客との協調」が必要です。変化をうまく抱擁する方法として、補
完型チケット駆動開発は効果的です。
サーバントリーダーシップ
WF開発でこぼれ落ちる水滴は、上に挙げたように、実現方法、環境、ド
メインのリスクが顕在化したものです。問題の発見が遅れれば被害は大き
くなりますので、いかに早く気付けるかが、プロジェクトの成功要因です。
しかし、どんなに優れたリーダーであっても、全ての方面に詳しいわけ
でなく、経験にも偏りがあるでしょう。トップダウンのリーダーシップで
はなく、メンバーの能力を最大限に発揮するサーバントリーダーシップに
よるチームづくりをすれば、知恵を出し合うことが可能になるでしょう。
ソフトウェアはチームで作るものです。プロセスを守ることやツールを
使うことで品質底上げや生産性を高めることが可能かもしれません。しか
し、「個人と対話」することを重視して経験や様々な気づきを共有できた
なら、リーダー一人で頑張るよりもきっとうまくいくでしょう。
まとめ
アジャイルソフトウェア開発宣言の価値観を実現する方法であれば特
に実現方法を問う必要はないと考えて、WF開発をどうすればアジャイル開
発のように変化に対応できるようになるかを整理しました。
「アダプタブルウォータフォール開発」は補完型チケット駆動開発をベ
ースに、それまで行ってきたプロジェクトの進め方を加えたものです。も
ともとアジャイルソフトウェア開発宣言を意識したものではありません
でしたが、WF開発の問題点をつぶしていくことで、ちょうど対応するよう
に整理することができました。
この背景にはアジャイルソフトウェア開発宣言に書いてあることが当
たり前のものであることもありますが、筆者が宣言を読んだことをきっか
けにWF開発を見直したことが大きいと思います。ソフトウェア開発にとっ

5. 5
5
て何が大切か、その当り前のことをアジャイルソフトウェア開発宣言は明
確にしてくれたのです。
同じことはチケット駆動開発にもいえます。チケット駆動開発はITSの
チケットをタスク管理に用いたものですが、その背景にはソフトウェア開
発に必要な、見える化、実装の重視、経験の蓄積、コミュニケーション、
現場での改善、といった要素が含まれています。そのような価値観を持っ
ているからこそ、プロジェクトをうまく回せるのだと思います。
アジャイル開発やチケット駆動開発の登場によって、ソフトウェア開発
に必要な価値観が明らかになりました。それぞれをどのように実現するか
は、私たち開発者に任されています。
参考：
・「アジャイルソフトウェア開発宣言」（Kent Beckほか）
http://agilemanifesto.org/iso/ja/
・「チケット駆動開発」（小川 明彦 (著), 阪井 誠 (著)）翔泳社
・[#TiDD] ウォーターフォール型開発をアダプタブルにする３＋１
http://sakaba.cocolog-nifty.com/sakaba/2015/05/tidd-1e66.html