[#TiDD] チケット駆動開発がもたらすプロセス その４：形式化

続きです。

チケット駆動開発によってプロセスは形式化されます。形式化されることで、作業の抜けが減少するほか、力関係が微妙な体制であってもプロジェクト運営が容易になります。

１．作業抜けの防止

チケットには、概要のほか、登録者、担当者、ステータス、マイルストーン、作業期間などの入力項目があります。組織によって必ずしもすべてが入力されるとは限りませんが、作業のさまざまな属性が記述されます。

チケットの登録やステータスの変更には、権限が必要です。アカウントのロール(役割)によって、できることが異なります。たとえば、チケットをクローズできる人が、リーダーだけであるなら、そのチケットはリーダーが確認した後にクローズされることになります。

このようにチケット駆動開発によって、作業の指示、担当者、確認が形式化されます。このことは、チケット駆動開発の特徴のひとつです。たとえば、リーダーとメンバーのありがちな会話を考えてみましょう。

「XXさん、この作業YYまでにできますか？」
「はい、できます」

これが確認であればよいですが、リーダーが指示のつもりならややこしいことになります。期限になってできていないこともありえます。もちろん、「では。お願いします」という一言があり、線表に記述して再配布していれば、問題はないのです。チケット駆動開発なら、そのような曖昧さが軽減します。また、何らかの齟齬によって、実施されなかった場合も、棚卸によって作業抜けを防止できます。

２．形式化による力関係の補正

プロジェクトの役割は、必ずしも技術力や年齢などによる人間関係と一致しません。配員時期、業務経験や発注・受注の関係で、別のプロジェクトではメンバーである人がサブリーダーになることもあります。

このような場合でも、サブリーダが調整上手だったり、メンバーが気を利かせたりしていれば問題ないでしょう。しかし、気の弱いサブリーダや、主張の多いメンバーだと、作業指示があいまいになったり、遅れがちになったりします。

このような場合にも、チケット駆動開発は有効です。

• 指示内容が形式化されて明確になる
• 指示系統が明確になる
• 上司による権威付けができる

からです。これは、コーチングの分類でいうアナライザ型の人に特に有効でしょう。

このように、チケットによるプロセスの形式化は、プロジェクトの運営を容易にします。

続きます。