チケット駆動開発導入のヒント - 自律と規律 -

株式会社SRA 阪井 誠

自己紹介

2

阪井誠：さかば、@sakaba37、 ㈱SRA、博士（工学）

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

• 仕事とコミュニティに刺激を受ける：RxTstudy、SEA関西

レビュー 監訳

New：5/27 New： 6/22 New： 6/30

New： 8/14

チケット駆動開発

現場から始まったシンプルな情報共有が特徴

• ITS（Issue Tracking System）チケットを用いて、障害、課題、Q&Aのほか、タスクを管理する

• チケットを構成管理と双方向に関連付ける

– 修正に至る経緯を容易に知ること（トレース）ができる

– 一つの理由から生じた複数の更新を束ねることができる

• チケットを中心として、情報をリアルタイムに共有し、 プロジェクトを運営する

– 現在の状況を共有できる

– 今後のタスクを通してゴールを共有できる

3

チケット駆動開発による改善

4

事例の分類

5

As is To be 文化の徹底

目的 作業漏れ防止 トレーサビリティ 計画、保守性向上

チケットの利用法 備忘録・情報共有 進捗・状況管理 タイムボックス管理

ITSの経験 障害管理のみ チケット駆動開発 チケット駆動開発

6

As is To be 文化の徹底 目的 作業漏れ防止 トレーサビリティ 計画、保守性向上

チケットの利用法 備忘録・情報共有 進捗・状況管理 タイムボックス管理

チケットの経験 障害管理のみ チケット駆動開発 チケット駆動開発

モチベーション 向上 低下 変わらず

管理面の効果 中 大 中

コミュニケーション向上 大 中 中

強制 なし あり なし

負担感 小 大 なし

結果 作業量が明確でモチベーション向上

効果あり。要件チケットの負担大

管理が容易。必要な記録を自主的に実施

感想 危機感と目的意識から効果的だった

面倒。Redmineなど負担軽減が必要

報告が簡素化され 作業効率化

要望から実施

負担が少なく好評 管理的で負担が大きく感じられた

自主性に任せた

効果も高かった

目指すべきゴール

7

問題点を見極めるとうまくいく

管理的になり易い準備が重要

文化の醸成による改善

AsIsとToBeの視点によるチケット駆動開発の事例の考察 - 坂本記念WorkShop -

http://sakaba.cocolog-nifty.com/sakaba/2013/07/tidd-asistobe--.html

チケット駆動開発に関する相談

講演すると相談されることが少なくない

• 管理者「チケットを更新してくれない」

– 進捗の管理がしたいのに更新してくれない

– いくら言ってもなおらない

• 開発者「面倒くさい」

– スピード感がない、リズムが乱れる

– 良さがわからない

=> 安易に導入して、失敗している

8

9

多くはここで失敗している

プロセス改善になっていない

プロセス改善として考える

改善とは技術導入ではなく、その実施によってメリットを得ること。技術負債から技術資産への文化改革が必要

• P：収支計画を立てる（コンセンサスを得る） – 問題（技術負債）を明らかにする

– 実施方法（ルール）を決める

– 効果（収支あるいは利益）を示す

• D:改善策を運用する – 改善策を推進し、データ（資産）を収集する

• C:確認する – 計画をふりかえりって、効果（収支あるいは利益）を見える化する

• A：改善策を見直す – 次の改善策を作成する

＝＞利益は単純ではない

10

管理者の利益、開発者の利益

管理者と開発者の利益は必ずしも一致しない

• 管理が楽になる改善策は規律(ルール）に従わせないといけない場合が多い

– 開発者には負担になる場合が多い

– 習熟すると負担を感じなくなる

• 開発が楽になる改善策は自律的に実施できる

– 効果を示すだけで導入が進む

– 使い方を知らないと負担になる

11

ヒント：効果を知ること

ヒント：習熟すること

ヒント：使い方

ヒント：負担になる

導入のヒント１：負担を減らす

開発者の負担を増やさない

• ルールを明確にし、作業指示またはお願いする

– 常に確認できるようにWikiなどを用いる

– 自動化や集中処理で負担を軽減する

• 入力は必要で明確な項目に限定する

– 面倒に感じさせない

– テンプレートプラグインなどで、入力を容易にする

12

導入のヒント２：習熟を促す

継続的に実施されるような活動

• 指導

– 特に導入初期は細かにチェックして指導する

– 納得してもらえるように説明する

• フィードバック

– 導入による成果を見つけ出してフィードバックする

– 定量的でなくてもよいので、感謝・賞賛する

– ふりかえりも利用する

13

導入のヒント３：効果を伝える

効果を知ることから自律への道が始まる

• 問題点を共有する

– 同じ方向を向く

• 期待される効果を示す

– レクチャや個別指導などメンバーに応じて行う

• 工夫の受け入れ

– 改善のアイデアは積極的に取り入れる

14

導入のヒント４：MVP(Minimum Viable Product)

最小の負担で効果を得る

• スモールスタート

– 障害管理から始める

– No ticket, No commitのみ

• ありものでレクチャーする

– スライド

• はじめる! Redmine (2015) http://www.slideshare.net/g_maeda/redmine-2015-54346755

– 書籍

• Redmine 実践ガイド、Redmineによるタスクマネジメント実践技法、 Redmine超入門、入門Redmine、ほか

15

導入のヒント５：ピンチはチャンス

プロジェクトのピンチは導入のチャンス

• 危機感

– 現状の問題点を共有し、同じ方向を向く

• 不安感を感じている

– 情報共有、コミュニケーション、履歴の活用など、安心できる理由を説明する

• 閉塞感

– 協力すればより効率的になることを説明する

16

導入のヒント６：プロセスの特徴

プロセスを実行するのは人

• 学習する

– うまく指導すれば、効果的に経験を積める

• リズム

– 同じ作業を繰り返すとリズムが生まれ、負担が減る

• 文化

– 組織的な行動により、標準化されていく

17

未来へのヒント：ゴールは文化の徹底

プロセス改善はモデル重視と問題解決重視の間を行き来しながら改善の経験値が上がるといわれる

• モデル重視はTo beアプローチに相当する

– 形骸化の壁と認証の壁がある

• 問題解決重視はAs is アプローチに相当する

– 制度化の壁がある

＊乘松聡「問題解決重視とモデル重視 ～組織に合ったプロセス改善モードを探す」 ,ソフトウェアプロセス改善カンファレンス2004. http://www.jaspic.org/event/2004/SepgJapan/proceedings/4A2.pdf

18

まとめ

チケット駆動開発導入のヒントを示した

– チケット駆動開発はプロセス改善

– 現場の負担を減らす

– 習熟を促す

– 効果を伝える

– 効率的に導入する

– ピンチはチャンス

– プロセスを実行するのは人

=>改善する文化を育てよう

20

完

25

チケット駆動開発導入のヒント

- 自律と規律 -