[#TiDD] アダプタブルな開発を実現するチケット駆動の3要素

批判の多いウォーターフォール開発ですが、チケット駆動開発をうまく導入するとより柔軟で安定したプロセスを実現できます。従来法では難しいアダプタブル(柔軟)な開発が可能になります。

１．従来型開発開発の課題

従来型開発は以下のような理由で変化にへの対応力が弱くなっていました。

ウォーターフォール型

リリースが1度しかなく、仕様変更があると手戻り作業が発生します。全体の計画を見直すことになるので、混乱が生じ易くなります。残業や増員でカバーできない場合は、リリースを延期することになります。

単純作業をうまく切り出せない場合は増員は逆効果になります。かえって混乱を増すだけで、費用の増加やリリースの遅延を招きます。

文書による情報共有

文書による情報共有は組織的な管理には便利なものです。しかし、仕様変更などをきっかけにした遅延が発生した際に行われる管理強化によって負担が増加して、生産性の低下を招いてしまうことがあります。

このように負担が増えても管理強化をせざるを得ないのは、文書による情報共有の場合、開発作業と独立した作業なので強制や支援が容易、伝搬が遅いので後手後手の対応になっていたものを取り返さないといけないこと、文書化の際に知らず知らず、あるいは、意図的に情報の改ざんが行われるのでより詳しく聞かないといけない、からです。

トップダウン文化

コンウェイの法則（リンク先はWikipedia）に従って、トップダウンに開発を進めると、組織もトップダウンになり、メンバーはコマンドコントロールによってのみ作業し、受け身になってしまいます。

受け身になると自発的に情報発信しなくなり、課題を見つけても情報共有せず、解決法の提案もしなくなります。また、プロジェクトが危うくなるに従って守りに入るようになり、担当が不明確な作業が宙に浮く様になります。あらかじめ全てを決めないと回らないので、変化に短期間で対応できなくなります。

２．チケット駆動によるアダプタブルな開発

チケット駆動開発を導入する際に、上にあげた問題を意識して改善するなら、プロジェクトは変化に対応可能になり、アダプタブルな開発が実現できます。

プロセス

あらかじめ仕様変更作業を計画に含める、五月雨ウォータフォール型開発をするなど、リリースを複数にします。いずれも請負開発で可能ですが、発注側・請負側の合意が必要になります。

チケット駆動開発で用いるITSでは、複数リリースが支援されています。要件や作業記載したチケットをリリース（マイルストーン/バージョン）ごとに管理することができます。

見える化

チケット化によって、ゴールとそれにいたる作業や課題を明確にします。ステークフォルダー全員でチケットを共有することで、問題が見える化されます。

開発の起点がチケットになりますので、情報作成の負担が少なく、リアルタイムの情報で、齟齬やごまかしの少ない生データを共有できます。

自律的

プロジェクトのメンバーが守りに入る理由の一つは、プロジェクトの全体の状況がわからないからです。プロジェクトを失敗させたいと思っていなくも、全貌がわからないのでは手の出しようがありません。どうしようもないので、ついつい「危なそうだから休めるうちに休もう」と考えてしまいます。

このような状況を改善するには、課題・障害・作業と言った状況を共有し、協力を促すことで大幅に改善されます。自分の作業が終わったからと帰っていたメンバーが、協力し、チケットを介してシャイなメンバーが活躍しだします。

３．ソフトウェアプロセスとしての視点

ソフトウェアプロセスもソフトウェアであると考えると、これらはプロセスプログラミングの問題だとわかります。

アーキテクチャの視点

プロジェクト全体を大きなシステムにすることが実現を困難にしていました。段階的なトランザクションや優先度の視点を持ち、期限付きのジョブキューを詰まらせない様に考えるとうまくいきます。

実装の視点

変化に対応し易いようにオブジェクト指向の考え方を取り入れます。前の記事で仕様変更の影響が複数の工程にまたがるのは構造化設計になっているからです。

データ構造の視点

データ(情報)量が一定以上になると、ファイル共有では不整合を起こさない様にするだけでも大変です。集中型データベースを導入し、トリガー(メールなどの通知)を使って効率的な処理を実現します。集中が難しければ(サブプロジェクトなどで)分散・連携します。

４．まとめ

このように、現状に問題意識を持ってチケット駆動開発を導入すれば、プロジェクトの問題を解決できます。ここではプロジェクトをアダプタブルな開発を実現する３要素について説明しました。

大切なのは問題を見極めることです。ここに挙げた要素はアジャイル開発をヒントにしたものですが、複数リリースをうまく制御するには単純なタスクカードでは難しいでしょう(リーンかんばんなら可能かもしれません)。

アダプタブルというのはアジャイル開発のなめの候補であったアダプティブを参考にしました。問題を見極めて工夫を継続することで、よりよい開発が実現できるでしょう。