アジャイル同人誌 Ultimate Agile Stories Iteration 4 寄稿原稿

1. 1
1
うまくいくチケット駆動開発 - リーンとリファクタリング -
株式会社 SRA 阪井誠 (@sakaba37)
0．はじめに
チケット駆動開発はとても便利な開発法です。チームでの情報共有が可能で、
これからの課題や現在の進捗、過去の経緯などをITS（課題管理システム）/ BTS
（障害管理システム）で共有することができます。ソフトウェア開発はチームに
よる協調作業なので、情報共有が容易になることでコミュニケーションが活発に
なり、知恵を出し合い、協力して開発することが可能です。
開発に関わる多くの人がその効果を実感している反面、管理的な目的で導入さ
れるとうまくいかないという声も聞きます。そのような不幸が起きるのは、プロ
セスを変更する際に必要な基本的な考慮が欠けているからです。本稿ではリーン
ソフトウェア開発（以下リーン）とリファクタリングを参考に、チケット駆動開
発をうまく導入するにはどうすれば良いかを解説します。
1．チケット駆動開発がうまくいかない理由
チケット駆動開発でうまくいかない典型的な例は、手段が目的化した場合です。
チケット駆動開発は導入できたものの、義務的な作業の負担が増えただけで改善
になっていないからです。
チケット駆動開発を導入すると様々な情報が電子化されますので、検索が容
易になるはずです。しかし、検索が容易になるようなデータ構造やクエリが用意
されていないと、負担が増えるだけでチケット駆動開発の効果は得られません。
このような問題は、必ずしも負担を増やそうとして失敗したのではなく、「よか
れ」と思ってチケット駆動開発が導入された場合もありますので注意が必要です。
負担が増えた理由を考えると、無駄な作業があること、チケット駆動開発の導
入で結果的に効率的でない作業を増やしてしまうこと、無駄ではないけれどもま
だ必要でないタイミングで 作業 してしまうこと、で生じます。説明するプロセ
スの構築法は、このような失敗をなくすことができます。

2. 2
2
2．リーンとリファクタリング
ここで示すチケット駆動開発導入時の基本的な考え方には、リーンの考え方を
ベースにリファクタリングの考え方も参考にしています。
リーンではタスクチケットに相当するカンバンというゴールに応じて開発する
ことで、無駄をなくします。この考え方を用いて無駄な作業をなくし、さらに合
理的で効率的なプロセスに再構成（リファクタリング）します。そして、いつま
でに決定すべきか、という最終決定時点を考慮して、無駄が生じる場合には決定
を遅らせます。その際には、WIP（work in process:仕掛品、同時に実行するカン
バンの数）を制限して効率的なプロセスを実現します。
無駄のないプロセスの実現には、プロセスもプログラミングするものだと考え
ると理解しやすいでしょう。ソフトウェア開発と同じように、必要な要求を優先
順位付けし、構造を意識して、段階的に全体を作り上げます。求められていない
ものまで作ることや、複雑な構造を避けて、シンプルで無駄のないプロセスを構
成します。
2.1 ゴールに応じた作業
プロセスの無駄をなくすには、全ての作業のゴールを明確にすることです。な
ぜその作業が必要なのか、説明できるようにします。作業の目的や成果物の利用
方法が説明できない場合は、プロセスの定義から外してその作業を実施しません。
アジャイル開発のYAGNI（You ain't gonna need it）、スクラムのバックログ、BDD
（behavior driven development）の考え方と同じです。必要になるまでその作業
をしないことで、無駄をなくします。
無駄な作業は、ドキュメンテーション、中でもメトリクスなどのエビデンス
（証拠）に多く存在します。形式的なチェックやデータ収集だけを目的としたメ
トリクス収集はどうしても義務的になりがちです。必要な情報ならなるべく簡便
にした上で、フィードバックすると開発者も協力的になるでしょう。ドキュメン

3. 3
3
トの記載やメトリクスと障害の関係を示すことで、プロセスが改善されるからで
す。
すべての作業にゴールがあるなら、合理的なプロセスです。読まれないドキ
ュメントはなく、改善に使われないメトリクスはないはずです。それが開発者に
とって必要な作業なら、より積極的に、より正確に実施されるでしょう。
2.2 効率的なプロセスにリファクタリングする
プロセスが合理的であっても効率的であるとは限りません。特に既存のプロセ
スをベースにチケット駆動開発を導入した場合、重複している作業や効率的でな
い作業もあるでしょう。そのような時は作業を、間引く、まとめる、再構成する、
などプロセスのリファクタリングをします。
(1) 間引く（差し替える）
作業が重複する場合の解決法の一つは、 間引くことです。ITS / BTSのチケッ
トで障害管理を始めたなら、二重管理は無駄ですので、 入力項目を工夫する、テ
ンプレートを用意する、記入ルールを決める、などして、既存の帳票管理はなる
べく減らし、従来の作業と差し替えると効率的でしょう。
作業が多すぎる場合に、もっとも簡単な解決策は間引くことです。作業そのも
ので間引く対象を検討するのではなく、作業のゴールについて優先順位を考える
と、より重要な作業を見極めることができます。
(2) まとめる
重複する作業を効率化するもう一つの方法はまとめることです。似ているけれ
ども微妙に違う作業は、まとめると効率化できる場合があります。例えば、チケ
ットに緊急度（サービスや他の作業の継続性に与える度合いなど）と重要度（障
害による被害の度合いなど）のようなフィールドがあったなら、一定のルールを
決めて優先度とする事を検討します。入力作業や実施する際の判断を効率化でき
るでしょう。

4. 4
4
作業をまとめる場合も、それぞれのゴールが何であるか、なぜ必要なのか、を
考えます。上述の緊急度と重要度の場合も、障害の対応作業のｶﾝﾘ効率化が目的な
らまとめることが可能ですが、インシデント管理をしている場合など、緊急度と
重要度はまとめられないかもしれません。そのような場合は、別々の項目のまま
残すか、他の項目に記入するようにするか、の判断が必要になります。
(3) 再構成する
一見重複する作業であっても、ゴールを見極めると、間引く、まとめる、とい
う変更が単純にできない場合があります。その際には類似の作業や関連する作業
と共に再構成します。もし、データモデリングでいうところの推移従属な情報、
つまり、ある情報から変換で得られるような情報があれば、ツールやプラグイン
の変換機構を利用すると作業を効率化できます。ITSのタスクチケットとガントチ
ャートの関係がそれに当たります。
しかし、この場合にも例外があります。工事進行基準を採用している場合など
では、チケットは現場の刻々と変化する予定をリアルタイムに示しすぎて、報告
の度に複雑な再計算をさせられてしまうかもしれません。このような場合は、そ
れぞれの特性を考慮して切り分け直します。つまり、チケットは現場の予定、工
事進行基準の計画は管理用の予定として用いて、現場の計画変更は許されている
範囲では管理用の計画を変更しないようにします。それぞれを使い分けることで、
作業をシンプルに効率的にできます。
2.3 決定を遅らせる
合理的で効率的な作業が明確になれば、それぞれの時間軸を考えます。無駄が
生じないようにするには、リーンソフトウェア開発の「決定を遅らせる」という
原則を用います。作業ごとにいつまでに決定しないといけないか「最終決定時点」
を検討し、後ろから計画を立てます。その際に同時実行する作業の数（WIP）が
一定の範囲に収まるようにします。

5. 5
5
たとえば、ウォーターフォール開発では上流の作業が多く、なかなか実装に入
れないので、実装上の問題よる手戻りが多いという問題を考えます。この解決策
の一つは、上流でプロトタイピングを行ってドキュメントに記載する内容の決定
を遅らせることです。その際には、作業効率が落ちないようにWIPを考慮するほ
か、他の作業に影響を与えてしまう最終決定時点を意識して計画します。
このようなプロトタイピングはあらかじめ計画できることも多いですが、設計
中にミドルウェアがバージョンアップされて、不明な点や不安に思う点が出てく
ることもあるでしょう。チケット駆動開発はこのような想定外の事象が発生した
場合に効果的です。必要になった検証作業のチケットを起票し、WIPと最終決定
時点を考慮して計画を変更します。
このようにWIPと最終決定時点を考慮することで、決定を遅らせた計画が可能
になります。時間軸の方向に効果的に作業が配置され、必要なものは必要な時に、
ジャストインタイムに作業できるようになります。
3．うまくいくチケット駆動開発に向けて
チケット駆動開発を導入する際には単に作業を増やすだけでなく、プロセスを
きちんと見直さなければうまくいきません。プロセスと聞くと減らすことのでき
ない管理的なものをイメージされるかもしれません。しかし、プロセスをプログ
ラミングするものと考えれば、プログラムと同じように設計が重要あることがわ
かっていただけるでしょう。重要なポイントもプログラムと似ています。
 スクラムやBDDでは必要とされる作業しかしない。バックログや振る舞い
の定義（ゴール）に基づいて開発する
 作業の重複やWIPを大きくしてしまう非効率な匂いのする場合は、作業をリ
ファクタリングする
 あらかじめ決めすぎない。最終決定時点を考慮して必要な時に必要な作業
をする。スパイクのように試験的に実施し、確認してから作り込む
 プロセスの利用者（実施者）の意見を参考に新しいプロセスへと、繰り返
し改善していく

6. 6
6
プログラムと大きく違うのは、シンプルにするだけでなく、WIPを意識して、
プロセスを重くしないことです。業務に合わせたQCD（品質、コスト、生産性）
のバランスを取ることが求められます。
4．おわりに
チケット駆動開発の導入には、ツールの導入とプロセスのプログラミング（再
構築）が必要です。ツールのデータを移行するだけでなく、既存のプロセスから
チケット駆動開発を導入したプロセスへの再構築が必要です。新しい作業を追加
するだけでは、負担が増えてどんどん重いプロセスになるからです。
チケット駆動開発がうまくいかない典型的なパターンは、手段の目的化です。
開発をより良くするという本来の目的を見失ってはいけません。継続的にプロセ
スを見直してより良いプロセスをプログラミングすれば、きっとうまくいくでし
ょう。
しかし、プログラミングと同じように基本的な技術がなければ、苦労ばかりで
なかなかゴールにたどり着けません。本稿では、リーンとリファクタリングを参
考に、基本となる考え方を解説しました。より良いチケット駆動開発の実践に少
しでもお役に立てれば幸いです。