top of page

Chapter 3　起票ルール

― 件名で行動を即決させる運用設計

運用フェーズで最も多い停滞要因は、
起票が「相談」になってしまうことです。

​

起票した瞬間に次の行動が決まらず、

  • 誰が判断するのか分からない

  • 何をすればよいか分からない

  • 結局、確認と相談が発生する

この状態が続くと、
判断待ちが常態化し、運用は確実に止まります。

​

本 Chapter では、
起票した瞬間に行動が決まる件名設計を中心に、
判断待ちを発生させない起票ルールを整理します。

3-1. 起票が「相談」になると、運用は止まる

次のような件名は、一見すると丁寧ですが、
運用を確実に止めます。

  • 確認お願いします

  • 対応について相談

  • 不具合かもしれません

  • 仕様について

​​

これらの件名には、

  • 課題の種別

  • 判断の要否

  • 緊急度

  • 次の行動

が含まれていません。

​

そのため、
読む側が判断を引き取る構造になってしまいます。

3-2. 起票とは「判断を投げる行為」である

本運用において、起票とは、

  • 相談すること

  • 情報共有すること

ではありません。

​

判断を確定させる、または判断を求める行為です。

​

起票時点で、

  • どの種類の判断か

  • 誰が判断すべきか

  • 何を決めたいのか

が分かる必要があります。

3-3. 件名は「判断トリガー」である

件名は、単なるタイトルではありません。
判断を即座に引き起こすトリガーです。

​

件名を見た瞬間に、

  • 状況が分かる

  • 種別が分かる

  • 次の行動が分かる

状態を作ることが目的です。

3-4. 件名で明示すべき4つの種別

本運用では、件名に以下のいずれかを必ず含めます。

​

【障害】

  • すでに発生している問題

  • 影響範囲と緊急度が判断対象

 

【課題】

  • 既知の問題や改善対象

  • 対応方針の判断が必要

 

【要望】

  • 新たな要請や改善提案

  • 対応可否の判断が必要

 

【仕様漏れ】

  • 定義不足・前提漏れ

  • 認識合わせと修正判断が必要

​​

この分類だけで、
判断の種類が即座に分かるようになります。

3-5. 件名フォーマット例

件名は、次の形式を基本とします。

  • 【障害】◯◯機能でエラー発生／暫定対応要

  • 【課題】◯◯処理の性能改善方針決定

  • 【要望】◯◯機能追加の可否判断

  • 【仕様漏れ】◯◯条件未定義の確認

 

件名を読んだ瞬間に、

  • 何が起きているか

  • 判断が必要か

  • 次に何をするか

が分かることが重要です。

3-6. 件名が正しいと、本文は短くてよい

件名が適切であれば、

  • 本文は事実の補足

  • 判断に必要な情報の整理

だけで十分です。

​

逆に、件名が曖昧な場合、
本文をどれだけ丁寧に書いても、
判断待ちは解消されません。

3-7. 起票ルールが守られると起きる変化

この起票ルールが守られると、

  • 確認コメントが減る

  • 判断の引き取り先が明確になる

  • 行動がすぐに始まる

  • 運用が滞留しなくなる

という変化が起きます。

​

これは意識改革の成果ではなく、
件名設計という構造の成果です。

​まとめ

起票で最も重要なのは、
「丁寧さ」でも「情報量」でもありません。

​

件名で判断を即決させることです。

  • 起票は相談にしない

  • 件名で判断を示す

  • 行動を迷わせない

このルールを徹底することで、
運用は自然に回り始めます。

◀ 前章：Chapter 2｜課題粒度と責任単位の定義

 

▶ 次章：Chapter 4｜Backlogテンプレート設計｜会話を不要にする運用構造

bottom of page