プログラマの思索

アダプタブルWFや補完チケット方式について、考えたことをラフなメモ書き。

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

ソフトウェア開発の匠（3）：「現状のソフトウェア開発は間違っていないか？」（プロセス編） (3/3) - ＠IT

ソフトウェア開発の匠（4）：アジャイル開発と反復開発の落とし穴 (2/3) - ＠IT

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

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

【1】普通のSIなら、社内標準プロセスとしてWF型開発がガッチリ決まっており、アジャイル開発を取り入れる雰囲気すら無いだろう。
しかし、アジャイル開発のプラクティスは部分的に取り入れることはできるし、その効果を上げることもできる。

同様に、チケット駆動開発をWF型開発に部分的に導入して、チケット駆動の良さを実感したい、という思いもあるだろう。
チケット管理は障害管理の一つの手法と思えば、そんなに大層な問題ではないからだ。

【2】では、WF型開発のどこにチケット駆動を取り入れると成功する確率が高いのか？

その問題を問うた時、「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOLの記事がすごく参考になる。

(引用開始)
私がウォーターフォール開発での(チケット駆動開発の)適用として取り組んだものには大きく2つある。
（1）ウォーターフォール開発でも内部にある小さな開発サイクルでの適用　
と、
（2）プログラム改訂に関係するタスク以外のタスクや情報のチケット管理
である。
(引用終了)

【3】WF型開発プロセス内部にある小さな開発サイクルでの適用　

一つは、プログラム修正、自動テスト、自動ビルド、リリースに至るまでの小さな作業を繰り返し行う時に使う。
例えば、障害修正など。
これは、テスト工程などの下流工程で有効なことは既に知られている。

【3-1】一方、WF型開発なのでリリースは最後の1回だけだが、内部プロセスでは開始～終了のサイクルを持つものがある。
例えば、「要求の検証」「アーキテクチャの検証」「テスト工程の分割・反復」などの開発サイクルにTiDDを適用する。

つまり、ソフトウェア開発の匠（3）：「現状のソフトウェア開発は間違っていないか？」（プロセス編） (3/3) - ＠ITで語られている「ウォーターフォール開発には裏プロセスが存在する」のことだ。

裏プロセスとは、社内標準のWF型開発に即していない「要求の検証」「アーキテクチャの検証」「テスト工程の分割・反復」があげられる。
プロジェクトリーダーは、裏プロセスを故意に作らないと、プロジェクトが成功する確率が高くならないからだ。
リスクヘッジするために、裏プロセスを幾つか作り、リスクを分散する。

でも、裏プロセスは社内標準でないから、リーダーは故意に表面化させない。
裏プロセスを出してしまうと、社内標準の逸脱に見えてしまい、品質保証部から指摘を受けるからだ。

だから、裏プロセスが見える化されない限り、プロセス改善は進まない。
裏プロセスのノウハウが共有されないのだ。

【3-2】また、「組織パターン」の「最高傑作の欠点」でも裏プロセスの指摘がある。
いわく。
こういった裏プロセスは、実は、プロジェクトリーダーも開発者も認識している。
しかし、プロジェクトリーダーは社内標準のWF型開発に則しているように振る舞うために、裏プロセスを表に出さず、あたかも一つの標準プロセスとして忠実になろうとする。
そこに矛盾が生じている、と。

【3-3】チケット駆動開発の利点は、社内標準になっていない裏プロセスを見える化し、そのような裏プロセスのタスクをチケットで一元管理できる点だ。

裏プロセスは社内標準の成果物テンプレートやプロセステンプレートがないので、ノウハウがなく、適当に運営してしまいやすい。
でも、少なくとも作業を洗い出せるならば、チケットで全てのタスクを表現できるし、進捗管理もでき、作業履歴を追跡することもできる。

すなわち、チケット駆動開発は、社内標準から漏れた例外プロセスや裏プロセスを実装することに向いている。

【4】プログラム修正以外のタスクや情報のチケット管理

WBSからこぼれ落ちた情報を記録するためにチケット駆動開発を適用する。
例えば、設計工程での設計書のレビュー、開発工程のコードレビュー、各工程での課題やQAの記録など。

最終版の設計書だけでは、その仕様に至った経緯や要件の変更履歴が分かりにくい。
そのためだけに、変更履歴の資料を作っても、設計書が変われば、2種類の資料を修正する手間がかかる。
また、オフショアやニアショアなど、地理的に離れたチームとの開発では、QAのやり取りをしながらアウトプットのプログラムを作りこんでいく事が多いから、その経緯や履歴を残っているとすごく助かる。

こういう状況では、補完型チケット駆動開発が威力を発揮する。
すなわち、設計・開発・テストの各工程でこぼれ落ちた課題管理、残作業の管理、レビューの管理、障害管理などでチケット駆動開発を適用することで、チケットに全ての記録が集約される。
チケットの内容はいくらでも全文検索できるから、後から変更理由の経緯を追跡することができる。

特に、運用保守で本番ソースを修正する時、汚いパッチの意図を確認しておくのは重要だ。

【5】以上のように考えると、WF型開発にチケット駆動開発を適用する対象としては、下記があげられる。

(1)標準プロセスから外れた裏プロセスや例外プロセス
(2)WBSから漏れた残タスク・課題・レビューなどの管理

この事実を見ると、チケット駆動開発は例外的・突発的・変更が多いタスク管理に向いていることが分かる。

また、チケット管理を運用すると、いろんな効果が出てくる。
開発のリズム、見える化、バージョン単位の反復・漸進型開発、メンバーの自律化、開発ペースの安定など。

それらの効果は、WF型開発の弱点というよりも、チケット駆動開発を適用したから出てくるものであり、チケット駆動開発の運用ルールとして強制すべきほどではない気がする。
チケット管理を運用していく上で、現場ごとにその効果が色々見えてくると思うからだ。

そんなことを思うと、ソフトウェア開発ではプロセス標準という考え方は適用しにくいように思う。
むしろ例外や裏に隠れてしまったプロセスの方がすごく多い。
それらをいかに制御して、ソフトウェアをリリースしていくか。

まずは試してみて、実践知を貯めていきながら、製品を作り上げていくという適応型開発に、チケット駆動開発も当てはまりやすい性質があるのだろうと思う。