[#TiDD] ビジョンとコミットメントがチケット駆動開発を成功させる

Redmineを導入すれば問題は解決するのでしょうか？それだけではうまくいきません。では、チケット駆動開発を導入すれば良いのでしょうか？それだけでもうまくいきません。ビジョンとコミットメントがチケット駆動開発を成功させるのです！

うまくいく場合もある

いやいや、Redmineを入れるだけ、チケット駆動開発を導入するだけでうまくいく場合もあるでしょう。それは現状の問題が共通認識になっていて、ツール以外の問題やタスク管理以外の問題がない場合です。

たとえば、すでにアジャイル開発をしていて、拠点が分かれたのでタスクボードの代わりにRedmineを導入する場合など。あるいは、障害管理がうまくまわっている組織が新しい分野にチャレンジする場合に、気付いたことを効率よく共有できる様に補完型チケット駆動開発を導入する。といった場合です。

このように問題点が明確な場合は、チーム全体がチケットを中心にまわり、チケットで情報共有が進み、作業が効率化されます。

うなくいかない場合

反対にうまくいかない場合は以下のような状況がある様です。

• 協力してくれない。チケットを行進してくれない。遅い
• チケットと現状に差がある、適当。ごまかす
• 期待した成果が出ない。勉強不足で効率が悪い

その背景には以下の問題が考えられます。

(1) 問題が共有されていない
そもそも何のためにRedmineやチケット駆動開発を導入するのか、目的がわかっていないのではないでしょうか。それがなぜ必要かもわからず、作業の負担増え、ただただやらされ感を感じさせているのではないでしょうか？

(2) 重要性が理解されていない
トレーサビリティやコミュニケーションの向上、あるいはデータ収集の効率化といった目的が共有されていても、その効果をフィードバックしていないなら徐々にいい加減になるでしょう。重要性を理解してもらうには、その効果を示す必要があります。

(3) 導入の段取りが悪い
ツールを導入する場合は新しい作業が負担にならない様に、レクチャーや指導が必要です。理解のないままに、いきなり高度な実施方法は負担が大きくなります。まずは障害管理から初めて、開発の道具になってからタスクの管理をはじめると良いでしょう。

違いはビジョンとコミットメント

コマンドコントロールにしろ、支援型のリーダーシップにしろ、新しい環境を導入する際にやらないといけないことは変わりません。それは、どのような改善がもたらされるか、ビジョンを示すことです。

状況によって、始まりは指示なのかお願いなのかわかりません。しかし、長く継続させるには、そのビジョンは理想のままではなく、結果で示さないといけません。

開発者が効果を実感できるか、明確なフィードバックがなければ、それは余分な作業が増えただけです。

フィードバックは定量的でなくても構いません。「障害対応が早くなったような気がする」「管理作業が楽になった」という感想が聞ければ、それは無駄な作業ではなくなります。前向きな協力が得られるかも知れません。

そして、何よりもコミットメントを得る事が大切です。やらされ感だけの作業は、いい加減になりがちです。

無理な導入は行わず、必要な教育を実施した上で、開発者にメリットのあるところから段階的に実施します。そして、その後も支援や適切なフィードバックを行いましょう。

まとめ

Redmineやチケット駆動開発に限らず、これまでのプロセスを変更する際にはリーダーシップが求められます。それが如何に大切なことであるかビジョンを示し、理解を得ないといけません。

それはソフトウェアを作る場合と同じです。はじめに必要な勉強をした上で、必要に応じて修正やフィードバックを行いながら、より良いプロセスを作り上げていきます。

ゴールの達成にはリーダーは余計なプライドを捨て、チームに期待して、何でもしないといけません。チームを支援することが、リーダーの仕事をセクシーにするのです。

参考：

[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -

ピグマリオン効果とリーダーシップとリーダーの心理 - マンガで分かる心療内科14 -

リーダーはショットガン・アクションでボトルネックをなくせ！ - マンガで分かる心療内科14 その2 -

求められるリーダー像と羊飼い型リーダーシップ - 「リーダーシップ3.0」の咀嚼 -

支援者としてのリーダー - 「リーダーシップ3.0」を読んで -

チームを守り育てる - セクシーな中間管理職 -