チケット駆動開発の適用範囲part4～ウォーターフォール型開発への部分適用の注意点

以前のJSOLさんのTiDDの運用事例の記事を読み直してみて、自分の理解不足の面があったのでメモ。
ラフなメモ書き。

【元ネタ】
「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL

[#TiDD] チケット駆動でAdaptable Waterfall開発！: ソフトウェアさかば

チケット駆動開発の適用範囲: プログラマの思索

チケット駆動開発の戦略: プログラマの思索

裏プロセスは並行プロセス: プログラマの思索

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

繰り返し開発の罠: プログラマの思索

段階リリースとアジャイルリリーストレイン: プログラマの思索

WF型開発におけるプロマネのテクニック: プログラマの思索

僕は、チケット駆動開発をアジャイル開発へいかに適用するか、という問題意識しなかったので、従来型の開発やWF型開発への適用はあまり考えていなかった。
上記の記事を読むと、WF型開発に特有の課題に対して、チケット駆動開発をどのようように適用したら効果的なのか、という点をよく研究されているという印象を持った。

「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOLの記事では、主に二つの課題、（1）ウォーターフォール開発でも内部にある小さな開発サイクルでの適用と、（2）プログラム改訂に関係するタスク以外のタスクや情報のチケット管理に適用した話が載っている。

(1)が意味することは、WF型開発でも短期間の開発サイクルの作業が存在しており、その作業にチケット駆動開発を適用しようとすること。
実際、要件定義、設計、実装、単体テストという工程が終わった後、ビッグバン結合で初めて大きな問題が次々に判明し、障害という名の元で短い開発サイクルの作業が生まれる。
その作業は障害管理に過ぎないけれども、障害をチケットに起票するのが起点となり、修正、レビュー、テスト、自動テスト、ビルド、リリースという一連の流れが全てチケットに作業履歴として残る。
だから、チケットにすべての情報が集約されるので、関係者同士の情報共有が楽になるし、SVNやGitなどの構成管理やJenkinsのようなビルド管理とRedmineを連携すれば、より強力に早く開発できる。

また、(2)では、設計書のレビューなどもチケットに作業履歴を残すことで、レビューの品質をあげようとする目的が示されている。

だが、(1)(2)の本当の問題点は、要件定義や設計、開発、テストの各工程で、一連の短い開発サイクルという裏プロセスが存在することにある。
WF型開発の定義では、前工程が完全に終了して次の工程に成果物が渡るので、手戻り作業や反復作業は基本ありえない。
しかし、実際の現場では、そんな綺麗事で開発できるわけがないし、リスクが高い。
だから、経験のあるプロマネは、裏プロセスという技を取る。

萩本さんの記事「「現状のソフトウェア開発は間違っていないか？」（プロセス編） － ＠IT自分戦略研究所」に書かれているけれど、要件定義・設計などの各工程で、PDCAサイクルを裏で回してリスクヘッジしているが、表に出さないようにプロセスを回す。

特に上流工程のPDCAサイクルは、実験的なアプリを作って画面イメージをすりあわせるプロトタイプという手法をよく取るがそれに当たる。
だが、プロトタイプはあくまでも暫定的なアプリのため、開発工程では結局一から作り直す場合も多い。
つまり、アジャイル開発における小規模リリースとは性質が全く違う。

そういう要件の検証、アーキテクチャ検証をあらかじめ実施するプロセスがあるのだが、教科書通りのWF型開発ではその認識が漏れていて、各プロジェクト独自のプロセスになりがち。
その裏プロセスを表に出すと、特に大手SIが自社で定めている開発標準とずれてしまうため、表に出さないようにわざわざする場合も多い。
だから、裏プロセスと呼ばれるわけだ。

また、別の手段として、段階リリースという方法もよく取る。
段階リリースとは、WF型開発において、サブシステム単位に複数回のWF型開発を回すこと。
大規模システムですべての機能を設計した後に開発して結合テストを実施するのはとても危険なので、意味のある業務の単位でシステムを分割し、その単位で段階的にリリースしていくプロセスを指す。
ビッグバン結合というリスクを回避するために、システムのサイズを小さくしてテストしてリリースするわけだ。

その意味ではアジャイル開発のイテレーションやスプリントの概念に似ているけれども、性質は全く違う。
イテレーションは2～4週間の定期的な開発サイクルであり、段階リリースではリリースサイクルは1ヶ月の時もあれば3ヶ月の時もあり不定期だ。
更に、イテレーション期間中は計画の変更は現状に合わせて行われるし、設計・開発・テストは並行して作業するのに対し、段階リリースの期間中はミニWF型開発なので、設計・開発・テストの工程の順に進んでいく。
だから段階リリースと言っても、結局はWF型開発であるからには最後のリリースにしわ寄せが来る。

そういう弱点がWF型開発には根本的にあるけれども、チケット駆動開発の恩恵は確かにある。
@sakaba37さんは、AdaptableWFと呼んで、WF型開発への部分適用でも十分な効果があると言われている。
とはいえ、WF型開発への適用は、WF型開発の特徴から来る根本的な問題をよく考えてみることが大事なように思う。