Ultimate Agile Stories Iteration 3 投稿原稿

1. 1
1
アジャイルの夢を実現する – チケット駆動開発で考慮すべき点
阪井 誠(@sakaba37)
1. はじめに
21世紀の初め、私たちは夢を見ました！それは「アジャイル開発」です。重苦
しい開発標準に自由を奪われ、多くのドキュメンテーションに追われる中で、ソ
フトウェア開発を知的な作業として、合理的で無駄がないプロセスとして再定義
されていたからです。当時の私が心を惹かれたのは、以下のような特徴でした。
 先進的・自動化
 統合環境・テスト・ビルド・静的解析・etc.•
 協調的
 全員同席、タスクボード、コードの共同所有、計画ゲーム、朝会、ふ
りかえり
 安心
 短期リリース 、繰り返し、 テスト駆動開発、 ペアプログラミング、
常時結合
 無駄がない
 シ ンプルデザイン、リファクタリング、YAGNI、ユーザテスト
 柔軟な開発
 柔軟– イテレーティブ、インクリメンタル、タイムボックス管理
 人に優しい
 コーディン グ規約、適切なペース、メタファ
アジャイル開発という理想的なソフトウェア開発は、理想的であるがゆえに乗
り越えなければいけない多くの壁があり、ゲリラ的にはじめても組織の支援がな
ければ続かず、断念した方も少なくなかったようです。
近年になって、UXの向上や効率的な価値の提供、開発環境の変化への対応が必
要とされるWeb開発が増えてくるに従って、従来の一発勝負型の開発ではより良
いソフトウェアの開発は困難になり、アジャイル開発が行われることも増えてき
ました。

2. 2
2
しかし、顧客やスポンサーの合意を得てすでにアジャイル開発を実践している
組織はいまだ少数で、そこには乗り越えなければいけない多くの壁が存在します。
本稿では、チケット駆動開発によってアジャイル開発の夢を実現する方法を説明
します。特にその中でも、チケット駆動開発で考慮すべきポイントを、アジャイ
ル開発で用いられるタスクボードの特性を考察することで示したいと思います。
2. アジャイル開発への障壁
アジャイル開発への障壁として、契約、場所、開発標準、マインドなどがあると
考えられます。これらは必ずしも障壁ではないと考えています。
契約： アジャイル開発のもっとも高い壁は契約だというのは、多くの方が合意
されるでしょう。請負開発ではスコープを変更できないからです。しかし、リリ
ースや契約が1回に制約されるわけではないので、複数リリースや契約の分割、あ
らかじめ仕様変更の期間と工数を合意するなど、工夫する余地があるでしょう。
開発標準：ソフトウェア開発を重くする原因の一つですが、ソフトウェアを開
発しても必要なものがそろっていなければ納品できません。まずは、開発標準を
よく読みましょう。開発中に利用するドキュメントは積極的に、そうでないドキ
ュメントは、必要とされる時期までに最も効率の良い方法で作成します。メトリ
クスの集計もツールの利用や自動化によって、その負担を減らします。注意しな
いといけないのは、納品物件の内容についてきちんと合意しておくことです。全
体に手戻りが発生してしまうことや、想定が崩れてリポジトリから過去のバージ
ョンを取り出して再計測が必要になるといった可能性があるからです。
マインド：「アジャイルには二つあって一つはプラクティス、もう一つはマイ
ンドだ！」といわれる方もおられるぐらい、マインドはアジャイル開発の重要な
要素です。しかし、サーバントリーダーシップや自律的な組織、メンバーの能力
を最大限に発揮するという考え方は、従来法での開発となんら矛盾しないもので
す。また、顧客への価値の提供もビジネスを継続するには、当然必要とされるも
のです。あるべき姿を意識して、改善を心がけることで、前向きになり、少しず
つ実現できるでしょう。アジャイル開発に依存しない、そのようなマインドの実
現を目指したものがプロジェクトファシリテーションと言えますので、大いに参
考になるでしょう。

3. 3
3
場所：チームが集まれる場所や、タスクボードを置く場所がないというのは、
大きな問題です。タスクボード（かんばん）はプロジェクトファシリテーション
の道具の一つであり、アジャイルマインドの実現には欠かせないからです。単純
にタスクカードをITSのチケットに置き換えてもうまくいかないからです。では、
タスクボードについて、以降の章で考えてみましょう。
3. タスクボードの特性
アジャイル開発はタスクボードを中心に開発が進められます。一見、タスクの
状況を表示しているだけのように見えますので、それを単純にチケットに置き換
えるだけで良いように思えますが、それだけではとても危険です。きちんとタス
クボードの特性を知っておかないといけません。
プロジェクト計画のモデル：イテレーションの初めに、計画ゲームが行われ、
イテレーション中に実施する予定のタスクが決まります。イテレーションの初期
において、これらのタスクのカードが貼られたタスクボードは、タスクを示して
いるだけでなく、優先順位によって作業が計画されたプロセスのモデルと言うこ
とができます。
規律（ルール）による運用：タスクボードには規律が隠れています。あらかじ
め計画ミーティングでイテレーションの期間に開発できると合意されたタスクが
ToDoに置かれていること。開発者は作業を順にコミットして、タスクカードを
Doingに移して開発すること。作業の完了の定義を満たした場合、タスクカードを
Doneに移すこと。ユーザレビューと振り返りが終われば、タスクカードをはずし
てイテレーションを終了する。といったルールです。
コミュニケーションの場：アジャイル開発のコミュニケーションというと、朝
会とふりかえりを思い浮かべられると思います。ふりかえりは確かにイテレーシ
ョンの最後に行われるコミュニケーションの場です。一方の朝会は、状況と課題
の確認の場であって、個別の課題はアドホックな打ち合わせが行われます。
アジャイル開発においては、タスクボードの前がコミュニケーションの場です。
たまたま居合わせた開発者同士で自然と情報交換が始まることもありますし、タ
スクボードを見ながら朝会をすれば、より多くの情報交換ができるでしょう。

4. 4
4
4. チケット駆動開発で考慮すべきポイント
上記のようにタスクボードを見てくると、タスクボードをチケットに単純に置
き換えただけではうまくいかないことがわかって頂けるでしょう。そもそもチケ
ットとは何かから、チケット駆動開発で考慮すべきポイントを考えてみましょう。
プロセス関心事のモデル：タスクカードは言葉のとおりタスクをカードに記載
したもので、プロジェクトのタスクをモデル化したものでした。しかし、チケッ
トはタスクだけでなく、障害、課題、QAなどプロジェクトを進める上での関心事
をモデル化したものです（これをプロセス関心事と呼びます）。チケットには親
子・前後・関連の関係のあるチケットがあり、さらに議論やコメント、関連する
プロダクトの更新などの情報が紐づいています（図1)。
これは長所であるとともに短所です。様々なプロセス関心事を表現できるので
過去の履歴を見る際には便利な反面、タスクカードのように単純化されていない
ので記述が難しくなります。プロジェクトには様々な関心事がありますので、ど
のような構造でチケットを構成すれば、表現すべき関心事のアイデンティティ（同
一性）が維持できるかをきちんと考えて、シンプルに記載する必要があります。
リビジョンリビジョンリビジョンリビジョン
バージョン管理
CIツール チケットシステム（ITS）
親プロジェクト
親タスク／ストーリー
タスク（障害・課題・QA）
継続タスク
関連タスクWiki
プロジェクト
ステータス
チケットの種類とロール毎のワークフロー
参照
実行結果
チケット参照
連携
参照
連携
議論や更新を
メール、RSS、
プラグインで
通知できる
レポート、クエリ、
ロードマップ、ガント
チャート等で参照可
構成管理、Ｗｉｋｉ、
ＣＩツールなどを
チケットに連携
スプレッドシート 入出力
図１ チケットシステムの構造

5. 5
5
規律（ルール）による運用：チケットは複雑な情報を明示できるものですので、
より多くの規律を決めなければいけません。タスクボードで決められた内容のほ
か、チケットの種類、ロール、ステータスで定められるワークフローをどうする
か、あらかじめ決めておく必要があります。
また、チケットの属性（フィールド）は自由に増やせますので、表示可能な情
報は膨大なものになります。そこで、簡単に入力できるようにチケットの属性を
シンプルに維持することや不要な情報を見なくてよいようにレポート（クエリ）
を用意しておく必要もあります。
コミュニケーションの場：
チケット駆動開発で最も注意しなければいけないのは、コミュニケーションの
場を作ることです。タスクボードのように自然と人が集まる状況はありません。
また、チケットの一覧を常に確認するように習慣づけないと、見てもらえなくな
ります。
そこで、積極的に場を作ります。気軽に情報交換できるようにIP Messengerな
どのチャット可能なツールの導入や、朝会であえて技術的な課題も拾い上げてメ
ンバーで話し合う時間を作ることです。お菓子の時間もカジュアルな話をする時
間が生まれますので、有効な方法です。
また、チケット自体がコミュニケーションに使われるように、チケットの粒度
が大きくなりすぎないようにする、プロジェクトの情報はチケットシステムで集
中管理する、などチケットの一覧を常に確認するようにします。
5. 夢の実現に向けて
タスクボードの特性からチケット駆動開発で考慮すべきポイントを考察しまし
た。チケット駆動開発で用いるチケットシステム（ITS）は、プロセス関心事に対
する表現力が高く、表現すべきものは何か、規律、場、を決める必要がありまし
た。
チケット駆動開発には様々な実現方法があります。2章で示したようにアジャイ
ル開発の障壁を代替プラクティスで乗り越えれば、アジャイル開発に期待してい
たことが実現できますし、アジャイル開発の第1ステップとしても有効でしょう。
しかし、タスクボードとチケットシステムの仕組みは同じでも、必要なことが異

6. 6
6
なることを認識してください。まずは、チケットシステムでどんなことができる
のか、障害管理から始めるのもよいでしょう。
理想的なプロジェクトの実現は難しいものです。開発者はより良いプロジェク
トを求めて、理想的なプロジェクトを夢見がちです。しかし、その理想的なプロ
ジェクト（ToBe）に直接たどりつくには、大きな負担が伴います。まずは現状の
プロジェクト（AsIs）の問題点を見極めて、最も大きな問題を解決する方法を感
がるところから始めるのはどうでしょう。2割8割（パレート）の法則が成り立つ
なら、大きな効果が得られるはずです。
大切なのは夢をあきらめないことです。あきらめず、現状を受け入れて、問題
を少しずつ改善することが、理想への近道ではないでしょうか。
6. 参考資料
アジャイルの夢を現実に- プラクティス・プラクティス
http://www.slideshare.net/MakotoSAKAI/xp2013
『チェンジ！』の考え方〜マネしやんと〜
http://www.slideshare.net/MakotoSAKAI/ss-15005840