裏プロセスは並行プロセス

萩本さんの記事を読んだ感想をメモ。

【元ネタ】
「現状のソフトウェア開発は間違っていないか？」（プロセス編） － ＠IT自分戦略研究所

【1】大規模プロジェクトほど、WF(ウォーターフォール型プロセス)になりやすい。
膨大で複雑な仕様を開発するには、工程ごとに仕様の大枠を決めて、後戻りしないように確定しないと、開発速度は上がらない。

しかし、SW開発には、仕様変更が付き物。
更に、バージョンアップしながらユーザビリティを上げていく戦略が多い。
だから、WFでは、手戻り作業ばかりやって、結合テストで火を噴くパターンが多い。

大規模プロジェクトで一番嫌なのは、イテレーションと言う概念が無いこと。
WFはリリースが最後の１回だけ。

最後にリリースするまで、どう動くのか分からない。
イテレーションと言う開発のリズムが無いから、最後にリリースするまで、延々と残業や休日出勤が続く。
そしてリリース後も、顧客の苦情や膨大なバグが押し寄せて、ひたすら延々とバグ潰し。
ワンパターンすぎる。

【2】大規模プロジェクトの開発プロセスの特徴は、並行プロセスだ。
つまり、サブシステム毎に開発チームがあり、それらのチームが並行作業で設計して開発していく。

当然、最初は、サブシステムの連携の仕様が曖昧で、設計時には全てを突き止められない。
全てのチームが実装し終わって、統合して初めて、こういう風に動くんだ、と気付いて、パッチを当てていく。
しかし普通は、ビックバン統合になっているから、膨大なバグを潰して品質を確保するのが非常に難しい。

上記の記事に出てくる裏プロセスも、実は並行開発。
WF型開発を表で実行しながら、裏では、要件やアーキテクチャの検証をやっている。
つまり、裏プロセスで、設計や開発のリスクを早めに感知して、早期に是正対策を採っている。
WFが抱えるリスクを裏プロセスが吸収しているのだ。

上記の記事の指摘のように、これは反復開発ではない。
つまり、イテレーションと言う概念が存在しない。

XPが言うイテレーションの定義ははっきりしている。
計画→設計→実装→テスト→リリースの一連のサイクルのこと。
つまり、受入テストをクリアしないイテレーションはありえない。
そんなシステムは品質がボロボロで、顧客が使える代物ではない。

並行プロセスでは、マイルストーン時に、複数の開発チームの設計が終わっているだけ、単体テストまで終わっただけ、などのように各工程が完了しただけ。
リリース可能な動くモジュールができているわけではない。
これは、少なくともXPが言うイテレーションではない。

本当は、機能１を稼動するイテレーションの後に、機能２を作り始めたい。
そうすれば、まず機能１が動くシステムがあるから、開発者も顧客もイメージが湧く。

開発者は、少しずつ動かしながら、機能追加していくので、リスクが少ない。
顧客は、動かしながら、予期しない操作で欠陥を見つけたり、改善して欲しい機能をフィードバックする。
つまり、イテレーションを繰り返していくうちに、少しずつ機能もユーザビリティも向上していく。
例えば、オープンソースのツール群はこのような開発スタイルが多く、バージョンが上がるたびに機能が洗練されていく。

大規模プロジェクトでアジャイル開発を選択できない最大の理由は、機能分割するモデリング力が足りないからではないか、と推測している。
イテレーション毎にリリースしていくには、膨大で複雑な業務を、イテレーションが定める期間内かつリリースできる単位に機能分割して仕様へ落とさなければならない。
そこまで辿り着けないからではないか？

XPを代表とするアジャイル開発は、その概念が広く知られてきたとはいえ、運用のハードルはまだまだ高い。
アジャイル開発を実践し、運用して根付かせるには、何が必要か？
もっと考える必要がある。