チケット駆動開発の大切なこと- コミュニケーションの視点から -

チケット駆動開発の知っておくべき大切な事 - コミュニケーションの視点から -

株式会社SRA 阪井誠

自己紹介 • 阪井誠（さかば、Twitter: @sakaba37）

• ソフトウェアプロセス、チケット駆動開発(ＴｉＤＤ)、アジャイルに興味を持つ「プロセスプログラマー」

• 現場からコンサル・研究まで、論文、書籍、雑誌など

2

レビュー

NEW

NEW

NEW リーン開発の現場

カンバンによる大規模プロジェクトの運営

NEW

チケット駆動開発関連の業務経験

• チケット駆動開発によるソフトウェア開発

– 請負開発での社内利用（事例1）

– SESでの客先利用

• チケット駆動開発導入支援（コンサル）

– ツール導入支援

– ワークフロー定義支援（レビュー、提案）（事例2）

• チケットシステムの社内導入

– PC資産管理への応用*

– Wikiによる情報共有 *日経SYSTEMS 2013年9月号「こうすれば必ず成功！Redmine導入の勘所」

[#47Redmine]ユーザコミュニティが盛り上がってきた - 第５回品川Redmine – http://sakaba.cocolog-nifty.com/sakaba/2013/06/47redmine---red.html

3

背景：コミュニケーション • 「コミュニケーション，またその結果としての組織*」は古くからソフトウェア開発の課題

http://www.projectcartoon.com/gallery/ University of London Computer Center Newsletter, No.53, March 1973 (Pre- 1970 cartoon; origin unknown) *F. P. Brooks, Jr., ソフトウェア開発の神話,1975,

4

組織

チーム

組織内のコミュニケーション

– 様々な人がコミュニケーションする

– それぞれの立場（ロール）で行動する

– 想定外のコミュニケーションがあると混乱する

5

コミュニケーションの課題 • 発信者、受信者、情報に問題が発生する

6

発信受信

情報

言わない

遠慮、抑圧、従順、人ごと、プライド

放置失念、不明確、優先度、無責任

溜まる忙しい、大量

抜け・漏れ聞いていない、

聞く気がない、うっかり、

チェックの仕組みがない

質の低下伝聞、簡略化、

偏り

紛失・変化

流動的、あいまい知らない、

知ってるつもり、気付かない

本日のゴール：コミュニケーションの課題と対策

7

課題ツール現場の自律性適切な管理

発信言わない遠慮抑圧、従順、人ごと、プライド

（従順）

放置失念、優先度無責任不明確、

受信溜まる忙しい、大量（忙しい）（大量）

抜け・漏れ聞いていない、うっかり

聞く気がない、チェックの仕組みがない

情報質の低下伝聞簡略化偏り

紛失・変化知らない流動的、気付かない

あいまい、知ってるつもり

対策

グループ作業支援可視化備忘録

自律的組織自由な運用知識共創(黒板)

ワークフロー棚卸し繰り返し

目次 • 背景：コミュニケーション

• 組織内のコミュニケーション • コミュニケーションの課題

• コンテキスト – パラダイムシフト – 日本のソフトウェア管理・開発のブーム

• チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援

• コミュニケーションの改善 – ツールによる対策 – 現場の自律性による対策 – 管理による対策

• 事例 – 現場の自律によるリスク低減（文教パッケージのカスタマイズ） – 効果的なコミュニケーション（オフショア開発の支援）

• まとめ

8

見積もりのばらつき

時間

パラダイムシフト

• 期間が短くばらつきが大きくなった

不確実性コーンの変化

ソフトウェア業界のパラダイムシフト • 1990年代に始まった • ネオダマという標語によってソフトウェアハウスはＳＩｅｒに変わった

• 技術者の守備範囲はソフトからシステムになり、ビジネスに広がりつつある

• 多機能ソフトの開発が容易になり、自由度が増した反面、リスクが増えた

• 要求の不安定性*（流動的、詳細を知らない、知っているつもりのこと）が増えた

• 不安定性への対応には、計画駆動の伽藍方式だけでなく、バザール方式**の知識共創が必要になってきている

*W. S. ハンフリー，ソフトウェアプロセス成熟度の改善，1989. **E. S. Raymond，伽藍とバザール， http://cruel.org/freeware/cathedral.html

10

日本のソフトウェア産業の特徴

• 既存業務の置き換えが多く、細かな要望が多い

– 新規ビジネスが少ない。リプレスは一括（バグまで同じに、）

• DOAの普及によるオブジェクト指向普及の遅れ*

– アジャイル開発向きでない組織構造 (「善は急げ」より「急がば回れ」）

• WFが基本、ビジネス変化への対応力が低い

– 1990年代のRADのスキップにより、ビジネス価値、プロトタイピング、マルチリリースへの対応が遅れた

• アジャイル開発は、ゲームやWebサービスなど、新規ビジネスに多い

*児玉，UMLモデリングの本質第2版

11

日本のソフトウェア管理・開発のブーム

求められるもの

• ビジネスへの変化への対応（ボトムアップな自律性） • 組織とチームの全体最適（組織内での情報共有）

12

組織的管理プロジェクト管理現場の自律性

1980s 成果物標準化メトリクス QCサークル

1990s CMM/CMMI ISO9000

PMBOK (TSP)

(People CMM) (PSP)

2000s (アジャイルと規律)

XP、ファシリテーション (他のアジャイル開発)

2010s (ISO/IEC29110) スクラム

リーンチケット駆動開発

従来企業

全体コミュニケーション

新規ビジネス

チーム内コミュニケーション

具体的な課題 • プロセス改善がレベル3（定義されたプロセス）で止まり、チームの自律性が低い – チームの能力が生かせていない

– 情報共有に基づく、チームの自律的な行動が必要

• アジャイル開発が組織的に可視化されていない – チームの個別性が高く、複数プロジェクトを一貫して管理することが困難

– 電子化された情報の可視化が必要

＝＞チケット駆動開発で改善が可能なコミュニケーションの問題

13

統率の

とれた

組

織

の

特

性

自律的

小変更量大

チケット駆動開発による開発法の拡張

アダプタブル

ウォーターフォール

アジャイル開発

ウォーター

フォール型開発

TiDD

TiDD

TiDD

アジャイル

チケット駆動開発

適切な管理

現場の自律性

ツール

コミュニケーションの課題をチケット駆動開発で解決する







• まとめ

15

ＴｉＤＤのはじまり

• masuidrive的プロジェクトの方針(2007) http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/

• まちゅ, 「もうひとつのTDD」, ITpro Challenge のライトニングトーク http://www.machu.jp/diary/20070907.html#p01

• Ｓｈｉｂｕｙａ.Ｔｒａｃキックオフ

• XPJUG関西 TiDD勉強会発足 (2008)

• 「Redmineによるタスクマネジメント実践技法」(2010)

• RxTstudy、Ｓｈｉｎａｇａｗａ.Ｒｅｄｍｉｎｅ(2011)

• 「チケット駆動開発」(2012)

：

16

Ｔｒａｃブーム

チケット駆動開発誕生


• ＩＴＳ（ＢＴＳ）のチケットで障害、課題、タスクを管理して個人のタスクとプロジェクトを管理する

• 構成管理、Ｗｉｋｉ、継続的統合などツールをチケットに連携させて自動化する

• プロジェクトの情報をチケットに関連付けて管理することで、コミュニケーションを支援する

現場による、現場のための改善活動

プロジェクト関心事の電子化によるコミュニケーション支援

17

バージョン管理とチケット（仕様変更）

18

仕様変更

タスク１

タスク2

新規追加更新更新タグ

競合チェックアウトアップデート

解決

関連タスクトレーサビリティ

バージョン管理とチケット（バグ）

19

バグ

更新

更新

ブランチ

ツール連携

20

ＩＴＳ

バージョン管理

ツール

コメント

作業内容、担当者、

ステータス、進捗

開始、終了 refs #チケット番号

fixes #チケット番号

チケットによる管理

チケットシステム（ITS）

親チケット障害・課題・タスク

継続チケット

関連チケット

プロジェクト

ステータス

種類とロール毎のワークフロー

レポート、カスタムクエリ、

ロードマップ、ガントチャート等で参照できる

22

チケット一覧(例：Redmine)

SQiP2009発表資料より ©小川明彦, 阪井誠

23

ワークフロー設定(例：Redmine)

ユーザ権限と

チケット種類の単位で

ステータスの現在・移行先を指定する

ソフトウェア開発のワークフローは

BTSのワークフロー機能で

制御できる

ステータスの移行先

現在のステータ

ス

SQiP2009発表資料より ©小川明彦, 阪井誠

ツール連携とチケット

リビジョンリビジョンリビジョンリビジョン


CIツールチケットシステム（ITS）

親プロジェクト

親タスク／ストーリー

タスク

継続タスク

関連タスク Wiki

プロジェクト

ステータス

チケットの種類とロール毎のワークフロー

参照

実行結果

チケット参照

連携

参照

連携

構成管理、Ｗｉｋｉ、ＣＩツールなどをチケットに連携

チケットによるコミュニケーションの支援

リビジョンリビジョンリビジョンリビジョン


CIツールチケットシステム（ITS）

親プロジェクト

親タスク／ストーリー

タスク

継続タスク

関連タスク Wiki

プロジェクト

ステータス

チケットの種類とロール毎のワークフロー

参照

実行結果

チケット参照

連携

参照

連携

議論や更新を

メール、RSS、

プラグインで

通知できる







• まとめ

26

統率の

とれた

組

織

の

特

性

自律的

小変更量大

ツールによる対策


ウォーター


TiDD

TiDD

TiDD

ツール

（コミュニケーション改善パターン）

アダプタブル


アジャイル


組織パターン*

• ロールが安定していることを利用

• コンテキストと経験的な解決法をまとめた

• スクラムにも影響を与えた

28

組織チーム

・門番

・プロダクトの

主導者

・防火壁

・プライベートな

パージョニング

・スタンドアップ

ミーティング

・スケジュールを

小分けにする

・ワークキュー

・聴衆の参加 * James O. Coplien他，組織パターン，2013．

単一障害点の可能性

情報が古い部分的

気付を共有したい

スケールしたい

「かや」集合性（集合体ならでは全体的性質）は「かや」のようなもの

• 人は生まれながらに重層的な「かや」に属している • 全てが「かや」に規定されるのではなく、自由と主体性ももち、その合力で「かや」が変化する

• 何かを行動に移すとき、実は「かや」の行動の一部を演じている*

＝＞「かや」はグループ内のコミュニケーションの基盤

29

組織チーム

＊杉万，「グループダイナミックス入門」， p.30，世界思想社，2013．

ステークフォルダー

コミュニケーションの改善

• 集合性（かや）の概念でコミュニケーションを見直す

• チケットシステムは「かや」を実現するグループウェア • 個人・グループ間のコミュニケーションを支援する

• グループ・ロールにワークフローの権限を設定する

30

組織チーム

マネージャSEPG、SQA

リーダー

（SQA）

PO、SM

開発者

ステークフォルダー情報共有（参照）

開発情報更新

確認

プロセス改善

チケット

成果物

コミュニケーション改善パターンツールで「かや」を実現して、パターンを追加する

• 聴衆(ステークホルダー)に、チケットシステムや途中の成果物を公開することで、組織的な協調を可能にする「聴衆への可視化」

• 「備忘録」、「自己管理」として開発者自身の役に立てる

• 「棚卸し」により、放置を防ぐ

• 「黒板モデル」の知識共創のしくみ

31

組織チーム

聴衆への可視化 (複数の責務が関与する)

進捗、メトリクス、

トレーサビリティ

・門番

・プロダクトの主導者・防火壁

・プライベートな

パージョニング

・スタンドアップ

ミーティング

・スケジュールを

小分けにする

・ワークキュー

・聴衆の参加

備忘録

自己管理棚卸し

黒板

モデル

統率の

とれた

組

織

の

特

性

自律的

小変更量大

現場の自律性による対策

アダプタブル



ウォーター


TiDD

TiDD

TiDD

アジャイル


現場の自律性（サーバントリーダーシップ）

リーダーシップ

リーダーシップは国により異なるが* 、自律支援の視点で見ると共通

• 目標達成リーダーシップ – 日本では「部下が最大限に働くことを要求」

• 人間関係円滑化リーダーシップ – 日本では「個人的な問題にも気を使う」

• 良きリーダー – 日米では、上記2種類のリーダシップが必要

＊杉万，「グループダイナミックス入門」，pp.111-114，世界思想社，2013．

33

リーダーシップ

リーダーシップは国により異なるが* 、自律支援の視点で見ると共通

• 目標達成リーダーシップ – 日本では「部下が最大限に働くことを要求」 – アメリカでは「契約を順守することを要求」

• 人間関係円滑化リーダーシップ – 日本では「個人的な問題にも気を使う」 – アメリカでは「上司が首を突っ込んではいけない」

• 良きリーダー – 日米では、上記2種類のリーダシップが必要 – 中国では「徳（仁徳）のリーダーシップが必要」

＊杉万，「グループダイナミックス入門」，pp.111-114，世界思想社，2013．

34

ゴールを示して、能力を最大限に発揮させる

細かなことは言わないで、気を使う

責任を持つ親分肌

自律を支援するリーダーシップ

• サーバントリーダーシップ

– コマンドコントロールをやめ、メンバーが能力を生かせるように支援する

• マクロマネジメント

– マイクロマネジメントをすると依存するようになり、自律性が失われる

• 濡れぞうきんはしぼらない

– 本田宗一郎氏がＩＩＪ鈴木幸一社長(当時）に送った言葉

– ガチガチの管理からは柔軟な発想は生まれない

35

サーバントリーダーシップのイメージ

36

• ゴールを見失わないように自律的チームを支える

コマンドコントロールサーバントリーダーシップ

サーバントリーダーシップ

37

W・ハンフリー「TSP ガイドブック：リーダー編」, 2007.

– 「自律的なチーム」を構築

– 「その最大限の能力を最大限発揮できるようメンバーを動機付け、コーチし、後押しする」

– 「フィードバックとコミュニケーション」

– 「動的な負荷調整」

– 「管理することとリードすることは違います」

– 「人はリードされたいけれども管理されたくはない」

– 「リーダーは部下を動機付け」るなど、「下からリード」して「ゴールを達成」する

デブサミ運営事務局、100 人のプロが選んだソフトウェア開発の名著君のために選んだ 1 冊, pp.20-21.

「リーダーに求められる大切なこと」 http://www.slideshare.net/MakotoSAKAI/ss-16581244

統率の

とれた

組

織

の

特

性

自律的

小変更量大

適切な管理による対策

アダプタブル



ウォーター


TiDD

TiDD

TiDD

アジャイル


適切な管理（刺身モデル、

ワークフロー、チケット管理）

39

繰り返しと確認 - 刺身モデル -

• オリジナルスクラムの作業プロセス

• 各工程が重層的になっており、同じメンバーが作業することで、暗黙知の共有を図っている

AgileJapan2010 基調講演：

野中郁次郎先生による「実践知のリーダシップ～スクラムと知の場作り」

複数リリース、五月雨発注などで、変更リスクにも対応できる*

* [#TiDD] アジャイル風開発ラフシミュレーション（ソフトウェアさかば）

http://sakaba.cocolog-nifty.com/sakaba/2013/03/tidd-14ae.html

（適切な）ワークフローによる管理

• 有効な場合 • 権限による違いを厳密にしたい

• 責任者を明確にしたい

• 必ずチェックする場合

• 問題点

• ボトルネックになりやすい

• 間違いの修正ができなくなる場合がある

• 運用の工夫 • 契約やお金に関することはワークフローにする

• それ以外は厳密にしないで、運用ルールにする

40

チケットの管理 - 放置されるチケット -

• チケットがルーチンワークでないと登録を忘れがち • メリットと必然、チケットへの依存、リズム

• 他のチケットがないときにチェックを忘れて実施漏れ • 粒度の大きいチケットの後で発生

• 粒度が小さいとリズムが生まれて、発生しにくい

• 棚卸のバランス • 防げるが自主性も大切！「チケット見てる？」

• クローズしにくいもの (担当がない、チェックリスト的) • 課題、リスクに多い。棚卸し、 Wikiを利用する

• 気が付かないことはチケットにできない • 可視化（黒板モデルによる知識共創）

• 自由な雰囲気、経験者への依頼、情報収集が有効

41







• まとめ

42

ＴｉＤＤの事例

43

現場の自律によるリスク低減

チケット駆動開発の事例１

TiDDによる自律とリスク低減の実現

• 開発時の履歴をその後の開発につなげます • 開発者の気付きをチケットに記録します • 協調作業を支援してプロジェクトを活性化します

44

ハーケン(釘) カラビナ(止め具) ザイル(ロープ)

事例１の概要 • 文教パッケージのカスタマイズ(最大8人x1年)

o 短納期＆仕様の決定遅れ・変更

o スキルは高いが経験者が少ない(リーダは途中交代)

o オープンフレームワークの初めての組み合わせ（サブシステム、ミドルウェアのバージョン）

o 義務感と不安、重苦しい雰囲気、閉塞感、、、

o 守りに入るので、コミュニケーションが悪い

システムテストの時期になると、計画外の環境構築やリリース準備作業が明らかになった（環境に関連するバグも、、、）

⇒ そうだ！チケット駆動開発をしよう！

45

オープンなフレームワークの苦しみ

長所 • 同じようなコードが減る • 個別の業務要件に対する固有の開発だけでよい

短所 • お約束が多い複雑な作業で、気が抜けない • 工夫できる余地が少ない • 少人数で大規模なシステムが作れてしまう • セキュリティ対策で実行環境の構成は日々変化

⇒ 煩雑なのに情報が少ない、、、大変！ 46

TiDDの実施方式

• アダプタブルウォーターフォール(補完型ＴｉＤＤ）

• WBSと併用（と言っても更新作業は全てチケットあり）

• オープンな運用

• だれでもチケットが作成できる

• システムテスト以降

• システム全体

• メンバー全員

• trac（単独）・・・ SRA共通開発環境（trac,subversion,mailmanの仮想環境）

チケット駆動開発の導入

• 宣言と実行

「バグだけではなく、ソースを触るときや、WBSにない作業をするときは、チケットを登録してください！」

• 環境の準備

o レポート(チケットの一覧)の作成

bugのみ、 taskのみ、その他、など

o 権限の追加

tracの権限の設定が堅かったので、チケットを修正できるように

全ての権限を与えた（リスクを考慮して設定してください)

• 教育 • パッケージチームとのＱＡの経験はあった

48

ハーケン(釘)

カラビナ(止め具)

ザイル(ロープ)

結果

• チケットの数(BUG以外) o システムテスト：３１

o 本番環境構築：４２

データの準備、環境準備、BUG関連で増えた作業、細かな仕様変更など、手順書にない1回だけの作業

• 作業漏れ減少！納期までに作業が完了！

(知らないこと、気付かないことはできませんでした、、、orz)

それ以外にも、メンバーに変化が、、、

49

目が輝いた！サブリーダ(クラス)なのに遠慮をしていたメンバーが、生き生きしだした

• 「チケットを切ってもいいですか？」

⇒ 義務的な作業からの解放

• 「チケットを切っておかないと忘れてしまう！」

⇒ すぐに使いこなしていた

• 「ちゃんとクローズしてね」

⇒ 他の人に指導をしていた！

• 「残っているチケットが多くてわかりにくいから整理しますね」

⇒ 今後のことも考えている

事例１のまとめ

• システムテスト以降にTiDDを導入

• 備忘録のつもりで気づいたことをチケット化した

• 手順はＷｉｋｉにまとめた

• 計画外の作業を管理できた

• 作業を見える化することでコミュニケーションが向上した

• メンバーが前向きになり、プロジェクトが元気になった

51

事例１からの学び

• 新しい環境、実装方法、アプリケーションに挑戦するには、以下の点を考慮しないといけない

–気づいたことが共有されること

–少ない経験が蓄積されること

–蓄積した経験が生かせること

サーバーントリーダーシップを意識したチケット駆動開発の運用方法が必要

52

テーラリング１：

気づいたことが共有されること

• チケットが容易に起票できるようにする – 起票の権限をメンバーに与える

– ワークフローの制限を少なくする

• チケットの種類や属性を増やしすぎない –考えなくて良い様にする

–記入項目を減らす

• リアルタイムに共有してモチベーションを高める – メール、RSS、Eclipseとの連携

– コミュニケーションのタイムラグ減ると利用が増える

53

テーラリング２：

少ない経験が蓄積されること

• チケット駆動を習慣づける –基本的な教育

– メリットを感じさせる

–備忘録としての利用

• 利用に向けた支援 – カスタムレポートの用意など環境整備

–アドバイスのための棚卸し

–ルールの整備 (“No Ticket, No, Commit!!”をどこまで守るか、など)

54

ハーケン(釘) カラビナ(止め具) ザイル(ロープ)

テーラリング３：

蓄積した経験が生かされること

• 経験の種類に応じて整理する – 一度だけの作業はチケットを起票する – 手順やチェックリストはＷｉｋｉにまとめる

• 書きっぱなしのチケットを防ぐ – 完了条件を明確にする – 適切な棚卸しをする

• 発想力・提案力の向上 – 棚卸しの頻度を増やしすぎない – 自律的なチーム

55

ＴｉＤＤの事例

56

効果的なコミュニケーション

チケット駆動開発の事例２

事例２：オフショアでの利用

• コミュニケーションが問題になりやすい –状況が見えない

–履歴を確認したい場面が多い

–ボトルネックが発生しやすい

• 複数拠点 –プロトコルに制約

– メールは使いにくい

57

メールではうまくいかない

–情報の所在（ありか） • 個人的な分類・管理（本人以外は検索できない）

• MLサーバーで管理（分類がないので検索が困難）

• クローズドな情報(関係者が限定される)

–情報の関連付け • ソースとのリンクが困難（更新と理由）

• Wikiなどにまとめても、メールと関連付けにくい

–情報の内容 • 承認ワークフローがなく、ステータスがわからない

• 検索のキーがない

58

=> チケットシステムを導入

ワークフローの検討

• メールを原則禁止、チケットを利用

–質疑応答や議論の経緯を残す

– カスタムクエリで状況を容易に確認できるようにした

• チケットは基本的に発注側の責任者が閉じる

–ボトルネックになるが、最終確認ができる

–チケットの種類を工夫して作業を効率化

• 無駄に厳密にしない –ボールの持ち主は、ステータスでなく担当者（同じかや）

–担当がいなくても情報共有、更新ができる

59

事例２の結果

• メールとファイル共有による開発が一変

–履歴の検索が容易になった

– ファイル共有によるロックの問題が解消

–安全に修正作業ができる

=> 「もっと早く使っておけばよかった！」

60







• まとめ

61

統率の

とれた

組

織

の

特

性

自律的

小変更量大

まとめ

アダプタブル



ウォーター


TiDD

TiDD

TiDD

アジャイル


適切な管理（刺身モデル、

ワークフロー、チケット管理）

現場の自律性（サーバントリーダーシップ）

ツール

（コミュニケーション改善パターン）

コミュニケーション課題と対策

63

課題ツール現場の自律性適切な管理

発信言わない遠慮抑圧、従順、人ごと、プライド

（従順）

放置失念、優先度無責任不明確、

受信溜まる忙しい、大量（忙しい）（大量）

抜け・漏れ聞いていない、うっかり

聞く気がない、チェックの仕組みがない

情報質の低下伝聞簡略化偏り

紛失・変化知らない流動的、気付かない

あいまい、知ってるつもり

対策

グループ作業支援可視化備忘録

自律的組織自由な運用知識共創(黒板)

ワークフロー棚卸し繰り返し

おわりに

• ソフトウェア開発の最も大きな課題の一つはコミュニケーション

• チケット駆動開発 – プロジェクトの情報を集中管理 – 気づきや経験を蓄積して活用 – 自動化やコミュニケーションの支援ができる

• チケット駆動開発はコミュニケーションを改善する – ツールによるコミュニケーションの効率化 – 自律的なチーム作り – 適切な管理

=> ぜひ皆さんも活用してください

64

チケット駆動開発の

知っておくべき大切な事

- コミュニケーションノ視点から -

おわり

チケット駆動開発の大切なこと- コミュニケーションの視点から -

Technology