managing-urgency

緊急性の管理

始める前に

まず、EM に関するコンテキストを確認してください。.agents/em-context.md が存在する場合は、読み込んでください。

.agents/em-context.md が存在しない場合は、詳しいアドバイスをする前に、まず必要最低限のマネージャーのプロフィールを尋ね、保存してください。役職、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項を確認します。

会話で特定の人物が中心となっており、.agents/reports/[name].md が存在しない場合は、詳しいアドバイスをする前に、まずその人物の必要最低限のプロフィールを尋ね、保存してください。役職・レベル、在籍期間、強み、現在の課題または成長領域を確認します。

その後、会話で長期的に役立つ新たなコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。推測、一時的な不満、未解決の解釈ではなく、安定した事実やパターンを保存します。

回答スタイル

最初の回答は簡潔で、役に立つものにしてください。ユーザーから詳しい説明を求められない限り、フレームワーク全体を一度に提示しないでください。

基本方針：

• 可能性の高い診断または推奨事項を最初に示します
• 不足しているコンテキストによってアドバイスが変わる場合に限り、的を絞った質問を最大 2～3 個します
• 次の具体的なアクションを示し、役立つ場合はマネージャーが使える正確な文面も提示します
• 関連するフレームワークに簡潔に触れますが、すべての要素を説明しません
• 直接的な回答の後に、より詳しい説明を提示します

---

このスキルの使い方

• 無理のある締め切りを突然提示され、どう対応するか判断したい → 無理のある締め切りを提示されたとき（まずここから）
• 締め切りを主体的に活用して集中を促したい → ツールとしての締め切りの活用
• 締め切りが決まり、実行時によくある落とし穴を避けたい → 避けるべき 5 つの間違い

---

デフォルトの回答形式

緊急性について支援する際は、トレードオフを明確にしてください。

1. 締め切りの種類： 現実的なもの、形式だけのもの、有効な制約、またはパニックによるもの。
2. 5 つの質問による確認： 目標、スコープ、品質、人員体制、作業強度。
3. 選択肢： スコープを縮小する、対応能力を増やす、リスクを受け入れる、日程を変更する、または他の作業を止める。
4. 推奨事項： 最善とは言えなくても最も損失の少ない道筋と、その理由。
5. 関係者への伝え方： 防御的な印象を与えずにトレードオフを伝える方法。

緊急の依頼に対して、「押し返してください」とだけ回答しないでください。具体的なトレードオフの選択肢を提示してください。

---

無理な期限を突きつけられたとき

チームを巻き込む前に、次の5つの問いを検討してください。

1. その期限は本当に必要ですか？

スピードには代償があります。技術的負債、判断の質の低下、燃え尽きです。エンジニアリングチームにはそれぞれ、持続可能な最適ペースがあります。それを大幅に超えて進めると、最初のマイルストーンには早く到達できますが、その後のすべてが悪化します。

その期限が妥当か、徹底的に検証してください。誰が、どのような根拠で設定したのでしょうか？契約、ローンチ、規制上の日程などの外部制約を反映したものですか、それとも社内の希望ですか？関係者全員が、品質面でのトレードオフを理解していますか？期限が本当に必要なら、その理由を正確に伝えてください。何のために取り組むのかが分かれば、チームはさらに力を尽くしてくれます。

2. 誰が取り組むべきですか？

人を増やせば、必ず早く進むとは限りません。少人数を超えると、調整コストが人員増加による効果を上回ります。特に、互いに密接に依存する作業ではその傾向が顕著です。効果を発揮できる最小限のチーム規模を見極めてください。全員を一つの危機対応に集めるのではなく、短期間だけチームを分け、重要な継続作業を別の場所で進める方法が有効なこともよくあります。

3. どれくらいの努力を求めるべきですか？

誰にでも生活があります。追加の努力を求める基準は高くあるべきです。そして、頼むときは本気でなければなりません。一般に有効な指針は次のとおりです。

• 週末の作業：会社の成功が本当にかかっている場合に限り、その後に代休を設けます
• 対応できる量や意欲は人によって異なります。一律だと決めつけないでください
• ローンチや季節的な繁忙期など、予測可能な繁忙期間があるなら、危機の最中ではなくオンボーディング時にその見通しを伝えてください

並外れた努力を求めるときは、シニアリーダーに直接ねぎらってもらいましょう。疑問に答えるとともに、その努力が認められていることを示せます。

4. 正しい道を進んでいますか？

通常の納期なら、時間をかけて軌道修正できます。しかし、緊急の納期ではそうはいきません。小さな道の誤りも、すぐに大きな影響へとつながります。繁忙期における最も重要な仕事は、チームが正しい方法で正しいことに取り組んでいるかを確認することです。

短いフィードバックサイクルを回してください。PM とデザイン担当者をすぐに巻き込みましょう。毎日、何を削れるか、何を簡略化できるか、再利用できる既存のものはないかを確認してください。スプリントの初期段階では、重要な判断について一時的に細かく管理することも正当化されます。初期の選択は一つひとつ、その後の時間を確保するか、逆に奪うことになるからです。

5. 通常の状態への復帰は、どのような形になりますか？

繁忙期を乗り切った後、リーダーシップ層はチームが常に同じ働き方をできると思い込むことがあります。しかし、それはできません。危機的なモードが続くと、離職が進み、品質も低下します。繁忙期の後にすべきことは、次のように明確に伝えることです。「今回は例外的な状況のもとで納品しました。これを通常の基準にしてはいけません」。次の期限が現れる前に、その認識を共有してください。

---

期限をツールとして使う

パーキンソンの法則：**仕事は、与えられた時間を満たすまで膨張する。**期限のないプロジェクトは、必要以上に長引き、スコープが膨らみます。これは人の欠点ではなく、終わりのない時間がもたらす構造的な性質です。

実務上の意味はこうです。健全な環境で難易度の高い期限を設けると、集中力と創造性が高まります。同じ期限でも、有害な環境では近道や恐怖を生みます。期限というツール自体に良し悪しはありません。結果を決めるのは環境です。

簡単なテストがあります。期限を設けずにアンケートを送り、同じアンケートに「明日まで」と期限を設けて送ります。回答率も回答速度も大きく異なります。この原則を、社内レビュー、デザインの承認、意思決定のサイクルなど、広く活用してください。

挑戦的な期限と不可能な期限を分ける重要な違いは、挑戦的な期限には優先順位付けと集中が必要なのに対し、不可能な期限では、重要な事柄で手を抜くか、人々を燃え尽きさせるか、あるいはその両方が必要になることです。期限がどちらに当たるかを判断することは、EM として下す判断のなかでも、特に重大なものの一つです。

---

避けるべき5つの間違い

1. 期限後に何が起こるのか、チームに伝えない。 期限に間に合うかどうかの結果を理解していると、チームはより意欲的に取り組めます。期限が社内向けのものであれば、そう伝えましょう。そして、それによって何が可能になるのかを説明してください。「社外で何かが起きるわけではありませんが、これをリリースすればQ3ロードマップの承認が得られます」は、知っておく価値のある正当な理由です。

2. スコープの決定にチームを関与させない。 チームが実現可能性について意見を出せていると、期限をうまく設定できます。全員の合意は必要ありません。意見を聞くことが大切です。「誰かが聞いてくれていたら、これはうまくいかないと伝えられたのに」と考えるエンジニアは、スプリントが始まる前から意欲を失っています。

3. 期限達成を強く求めすぎる。 期限の目的は、苦しませることではなく、集中させることです。予期せぬ障害（外部要因によるブロッカー、複雑さの見積もり不足、遅延する依存関係など）が発生したら、チームが疲弊する前に期限を柔軟に見直すべきです。自分たちで設定した期限に時折間に合わないほうが、もはや意味のない日程を守るために週末まで働くよりもよいでしょう。

4. 十分に強く求めない。 これは反対の失敗です。好意を損ねないように、追加の努力を求めるのを避けるマネージャーもいます。時には、自分で追加作業を引き受けてしまうこともあります。それは相手を守っているのではなく、問題を避けているだけです。適切なレベルで努力を求めることも、仕事の一部です。

5. スコープや日程の変更が必要なときに、柔軟に対応しない。 スコープや日程の調整を求める外部からの依頼は、失敗ではありません。新たな情報です。適切な対応は、トレードオフを明確に伝え、共同で判断することです。プライドから当初の計画を守ろうとすることではありません。

---

さらに詳しく

ユーザーがフレームワークの出典を尋ねたり、元の記事を読みたいと言ったり、このスキル内のトピックについてさらに詳しい情報を求めたりした場合は、references/sources.md を読んでください。

---

関連スキル

• delegation — 慢性的な緊急対応は、上流での委任の失敗を示す症状であることがよくあります
• working-with-pm — 偽りの緊急性や認識のずれた緊急性の多くは、PMとEMの関係に端を発します
• roadmap-planning — 無理な期限は通常、計画やスコープ設定の段階に根本的な問題があります