[#TiDD] チケット駆動開発で考慮すべきバランスと視点
RedmineやTracなど、チケットシステムを導入して、プロセスを改善する際にはバランスと改善の視点が重要です。チケットシステムは様々な利用方法がありますので、思いつきで導入すると特定の問題は解決できても、使いづらいものになるからです。
1. バランス
バランスを取るべきものには以下の3つがあります。
- パラダイムシフト・効率化
- 暗黙知・形式知
- ツールによる自動化・ 人中心の支援
これらを順に説明しましょう。
1.1 パラダイムシフト・効率化
改善の方法にはto beからはじめる方法と、as isからはじめる方法があります。to beとはあるべき姿のことで、理想に向けて大きく舵を取る方法です。as isとはありのままの姿のことで、現状をモデル化してそこに現れる問題点を解決していく方法です。完全型チケット駆動開発はto be、 アダプタブル・ウォーターフォールなどの補完型チケット駆動開発はas isと言えるでしょう。
改善する際に大切なのは、それが パラダイムシフトなのか、効率化であるかを考える事です。パラダイムシフトとは考え方を大きく変えるもので、一つずつでないと実施できません。一方の効率化は作業者の負担を減らす目的で行うものですので、全体の一貫性や連携が考慮されていれば、複数の改善も可能です。
ここで気をつけないといけないのは、完全型であっても複数の効率化ができますが、補完型であったとしてもそれがパラダイムシフトであれば一つ一つ導入しなければいけないと言う事です。たとえば、サーバントリーダーシップを実践して自律的な組織を実現して、難局を乗り切る事が目標なら、それだけに集中してパラダイムシフトを成功させないといけません。成功しなければ改善ではありませんし、成功体験がなければ組織は変われません。
1.2 暗黙知・形式知
チケットは文字や関連で表されたものですので、形式知です。暗黙知の交換(共同化)をどのように補ってバランスを取るかを考えないといけません。
アジャイル開発でタスクボードなどの貼りものを用いる場合は、貼りものの前での雑談やペアプログラミングなど、暗黙知を交換する場がありますので、朝会や振り返りなど、形式知に(表出化)する場を用意して、暗黙知と形式知のバランスを取る必要があります。
これに対して、チケット駆動開発では形式知を扱いますので、暗黙知を交換する場を積極的に作って、暗黙知と形式知のバランスを取らないといけません。一般に朝会では、実績、予定、課題を話し、課題には深入りせず、全体を15分以内で終える様にすべきだと言われます。しかし、チケット駆動開発ではすでに形式知(チケット)化された進捗の確認を中心にするのではなく、これからの見込みの共有や、 課題に対する共通認識を持つ様にするなど、うまく形式知化されていない知識(暗黙知)を引き出す様にした方が良いでしょう。
1.3 ツールによる自動化・ 人中心の支援
アジャイルの「ライトウィング」と「レフトウィング」(An Agile Way)と呼ばれている考え方のバランスを取ります。ツールによる自動化などで環境を整えて業務を効率化する「ライトウィング」は、ついついツール中心の発想になりがちで、手段と目的が入れ替わる事も多い様です。トヨタ生産方式(TPS)では、自働化と呼んで、異常が生じた際には人間がラインを止められる仕組みが入れられていました。プロセス改善においても、おかしいと感じた場合はその流れを止められないといけないと思います。
一方、「レフトウィング」のように人が能力を最大限に発揮できる様にチーム作りをすると、ツールを使えば簡潔な環境が容易に実現できる場合でも、必要以上に作業時間を使ってしまう可能性があります。改善はトータルで人が楽になる事が目標です。人が高度な仕事をって能力を発揮できるにはどの様にすれば良いか、ムダな単純作業や間違えやすい複雑な作業を見極めてバランスよく自動化しないといけないでしょう。
2. 視点
チケット駆動で業務を改善する場合に、必要な視点には以下の3つがあります。
- 平準化とリズム
- 能力発揮:負担軽減・情報共有
- ジャストインタイム
これらは1のバランスを考える際の優先順位や、問題を見つけ出す際にも役立つでしょう。
2.1 平準化とリズム
平準化とは、負荷の大きな作業を見つけて改善します。一時的に増える作業を減らせば、ムダな配員が要らなくなり、 効率的な情報共有がおこなえるようになります。
また、安定した作業の繰り返しは作業のリズムを生みますので、習熟や効率が向上します。また、繰り返し可能なプロセスは改善が容易になります。
チケット駆動開発は、朝会で課題の議論も行う事が多いので、ふりかえりの効果が得られます。タイムボックス管理でない場合でも、改善のタイミングになりえるのです。
2.2 能力発揮
改善が能力の発揮につながるかどうかの視点です。負担の軽減して、より高度な作業にあたれる様にします。たとえば、間違えやすい作業に権限やワークフローによる制約を与えて、信頼性を高めたり、安心感を得ます。また、チケットや履歴を用いて、時間を超えた情報共有や助け合いを支援などもこれにあたります。
この際に忘れていけないのは、完璧を目指すのではなく、ムダを生まないことです。信頼性を高めようと確認のステータスをむやみに増やすと、作業にボトルネックが生じます。負担にならない程度の運用で実現できる事を、厳密なワークフローで実現する事は、ムダな場合が多いでしょう。
2.3 ジャストインタイム
リアルタイムなだけではありませんし、インタイムでもありません。
情報は、必要な時になければいけませんが、不要な時にあってもいけません。情報があると管理対象が増えますので、レポートで一覧する際にムダな作業が生じます。
必要な情報はリアルタイムに参照でき、不要な場合には参照しなくて良い仕組みを目指す視点が必要になります。
3.【告知】東京と大阪のRedmineの勉強会
ここにあげた内容と社内業務の事例を 6/29 のshinagawa.redmineで基調講演する予定です。関西の方はRxTstudyに参加します。ぜひ、勉強会でお会いしましょう。
3.1 shinagawa.redmine勉強会(6/29)
第5回 shinagawa.redmine勉強会
フリーのプロジェクト管理ツール Redmine について語り合いましょう!
3.2 第8回RxTstudy(6/22)
第8回RxTstudy
Redmineやタスク管理を考える勉強会@大阪
« [#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん@SEA関西 - | トップページ | [#TiDD] チケット駆動開発の「ライトウィング」と「レフトウィング」 »
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
« [#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん@SEA関西 - | トップページ | [#TiDD] チケット駆動開発の「ライトウィング」と「レフトウィング」 »
コメント