[#TiDD] チケット駆動開発の落とし穴 - ベカラズとベシ -

BTS/ITSのチケットを利用して、プロジェクトのアジリティを高めることができるチケット駆動開発。チケット駆動開発らしいツールの使い方を理解した上で、プロジェクトの問題を見極めることができたなら、大きな効果が得られるでしょう。

しかし、そんなチケット駆動開発には、ついついはまりがちな落とし穴が存在します。ここでは、落とし穴にはまらない様に、してはいけないこと(ベカラズ)とすべきこと(ベシ)をまとめました。

1. ツールの導入が目的ではいけない

手段の目的化と言いますが、プロジェクトの問題をチケット駆動開発で解決する手段としてツールを導入することが、いつしか目的になってしまいがちです。Redmineやtracを導入しても、運用を考えて使いこなして、プロジェクトの基盤として根付かなければ意味がありません。以下の視点を持ち、チケット駆動開発らしくツールを使いこなしましょう。

ツールを活かして楽をする
よりシンプルな方向性は「ツールを活かして楽をする」ことです。開発現場の負担が減って余裕ができると、より柔軟な発想が可能になり、積極的にプロジェクトに参画できる様になるでしょう。

読み手のための記録
言われたからやるという義務的な記録や、これぐらいわかって当たり前、といった記録は役に立ちません。読み手の期待する者は何か、自分が読み手なら何を書いておいてほしいか、相手をを思い、コミュニケーションすることが、。

情報を活用する
チケットの情報を埋もれさせてはいけません。わからない情報では活用できませんが、チケットが活用されないならわからない情報が記録されてしまいます。思い出せない時や確信が持てない時は積極的にチケットを確認しましょう。チケットを活用すれば、どのような書き方が必要かも自ずとわかるでしょう。

2. 仕組みづくりにはまってはいけない

プロセスプログラミングは楽しいものです。ツールを使って効率化に成功すると、どんどんツール化を進めていけば、どんどんうまくいくような錯覚をしてしまいます。しかし、ツールの導入は新たなルールを生み出します。このため、チケット駆動開発の仕組みづくりをやり過ぎると、作業がおざなりになって、形式的な対応やいい加減な対応がはびこる様になり、やがて破綻するでしょう。自動化したのに仕事が増えるということは許されないでしょう。仕組みづくりの際は、以下のような点に注意してください。

問題を見極めてピンポイントで攻める
ソフトウェア開発の問題は様々です。人の話を聞くと同じような問題があると勘違いして、試してみたくなる者です。しかし、表面的な問題ではなく、最も重大な問題を見極めて、その解決を図りましょう。

完璧を求めると、柔軟性がなくなる
訓練すれば人間はミスをしない。なんてことはありません。人間である限り失敗をします。また、今は完璧だとしても、次のプロジェクトのメンバー、顧客、業務でも大丈夫だとは限りません。基本の仕組みをシンプルに作り上げ、プロジェクトに合わせてプロセスを適切にテーラリングすることが望まれます。

固いプロセスには、義務的、非効率、破綻が待っている
物事にはアソビが必要です。アソビは無駄ではありません。ホッとする瞬間に良いアイデアが浮かびます。仕組みに追いかけられて神経をすり減らしてはいけません。一度に全体を直すのではなく、協力しながら徐々に仕組みを作り上げたなら、より良い仕組みになるでしょう。

3. ツールを過信しない

ソフトウェアを開発するのは人間です。ツールによって様々な自動化が行われても、人間が関与しなければソフトウェアはできないのです。しかし、チケット駆動開発によって多くの情報が可視化されると、うまくコントロールできる様に思いがちです。しかし、基本は何も変わりません。

ツールは道具
チケット駆動開発によるプロセス改善は、問題を解決できる様にプロジェクトの文化を変える事が目的です。ツールはその道具であり、きっかけにすぎません。

できる人だと勘違いしてはいけない
ツールの支援があると、ミスが減り、作業効率が上がります。しかし、それは限定された作業です。ツールで支援されない作業は、今まで通りなのです。

理解が進むことはあるが、強制ギブスではない
ツールによって制約を与えることができますが、人間の失敗や怠惰は防げません。ツールを活かすも殺すも利用者次第なのです。ツールの支援をどのように活かせば良いか、そのことを正しく理解して積極的に取り組める環境づくりが必要です。

4. リーダーだけでは何もできない

チケット駆動開発はこっそりと始めることができますが、プロジェクトのメンバーの協力が必要になります。また、継続して実施する場合や、組織内に広めるには上司のコミットメントが必要になります。メンバーと上司の協力が必要です。

メンバーの能力を最大限に発揮する
メンバーは交換可能な道具ではありません。彼/彼女らはソフトウェア開発の主人公なのです。リーダーが頑張っても大したことはできません。みんなで問題意識を共有して、アイデアを出し合い、力を合わすことができれば、世界が変わります。そのためには、命令や注意をするのではなく、公平な作業分担や情報提供の環境を整えましょう。それは、上に立ち管理するのではなく、快適に働ける様に奉仕することです。

上司のコミットメントを得る
チーム内でチケット駆動開発を導入するにも上司の許可が必要ですが、サーバーを用意して他のチームに展開するには、上司のコミットメントが書かせません。チケット駆動開発がなぜ必要なのか、きちんと説明できないといけません。

5. まとめ

チケット駆動開発の落とし穴の説明をして、どのような視点が必要であるかを説明しました。簡単にまとめると、以下の４点になります。

• BTS/ITSの活用が基本
• 規律よりも柔軟性が勝る
• 的確にツールを使う
• 協調できる組織作り

このような観点でチケット駆動開発を始めるなら、書籍「チケット駆動開発」がきっとお役に立つでしょう。