責任だけ増える中堅へ──燃え尽きないためのスコープ設計

気づけば、責任だけが増えていく。
メンバーは増えないのに、期待は増える。納期は短くなるのに、品質は落とせない。仕様は揺れるのに、説明責任はこっちに寄ってくる。

「自分が頑張れば何とかなる」
その姿勢で何年もやってきた人ほど、ある日ふっと心が折れる。燃え尽きるのは、根性が足りないからじゃない。むしろ逆で、責任感が強いから起きる。

燃え尽きないために必要なのは、休み方の工夫だけじゃない。
現場を壊す前に、スコープを設計すること。今日はそれを、実務で使える形に落として書く。

なぜ中堅ほど燃え尽きるのか

燃え尽きる中堅には、共通の構造がある。

• 「期待値」が増える（頼られる、任される、相談される）

• 「権限」は増えない（人員・予算・意思決定権がない）

• 「範囲」が曖昧な仕事が増える（隙間・穴埋め・火消し）

• 「断るコスト」が上がる（断ると信頼が落ちそうに見える）

この状態で頑張り続けると、どこかで破綻する。
だから必要なのは、仕事量の削減より先に、仕事の境界を作ることだ。

ここからが本題。

スコープ設計とは何か（定義）

スコープ設計は、単に「範囲を決める」ことじゃない。
燃え尽きないためのスコープ設計は、次の5つをセットで整えることだ。

1. 目的（ゴール）：何のためにやるのか

2. 範囲（In/Out）：どこまでやって、どこからやらないのか

3. 品質（Quality）：何を守り、どこは妥協できるのか

4. 制約（Constraint）：納期・人員・技術・運用の現実

5. 責任分界（RACI/境界）：誰が決め、誰が実行し、誰が承認するのか

この5つのうち、どれかが曖昧だと、仕事は際限なく増える。
中堅が燃え尽きるのは、能力の問題ではなく、この設計が抜けた状態で「全部抱える」からだ。

まず知っておくべき、スコープが壊れる瞬間（典型パターン）

パターン1：「ついでに」が積み上がる

「それもお願い」
「ついでにこれも」
「ついでに会議出て」

ついでに、は“追加スコープ”だ。
小さいからこそ危険で、積み上がると爆発する。

パターン2：「品質」の定義がない

「とにかく急いで」
「でも品質は落とさないで」

この矛盾を飲むと、燃え尽きる。
品質が定義されていないと、最悪ケースを想定して守りに入り、工数が膨らみ続ける。

パターン3：「誰が決めるか」が曖昧

決裁者が不在のまま、現場が進める。
後から偉い人の一言で覆る。
この往復運動が、一番心を削る。

燃え尽きないためのスコープ設計：実務で使える7つの型

1) 「目的」を1行で固定する（ブレ防止）

会話が増えるほど、目的はズレる。
だから最初に、目的を1行で固定する。

例：

• 「障害を減らす」では弱い

• 「問い合わせ起因の障害を減らし、夜間対応を月◯回→◯回にする」まで落とす

目的が固定されると、余計な要求を断る根拠になる。
断るときに必要なのは“勇気”じゃなく「根拠」だ。

2) In/Outを明文化する（言った言わないを消す）

燃え尽きる人は、頭の中で境界を引いている。
でも境界は、文書にして初めて境界になる。

最低限でいい。

• In（やる）：A、B、C

• Out（やらない）：D、E、F

• Outだけど将来候補：G（次フェーズ）

ここで重要なのは「Outを書くこと」。
Outを書けない現場は、スコープが無限になる。

3) 変更要求の「入口」を1つにする（スコープの治安維持）

仕様変更が悪いわけじゃない。
悪いのは、変更が無秩序に入ってくることだ。

• 変更要求はチケットに集約

• 影響範囲（工数/リスク/納期影響）を添付

• 優先度を決める会議体を固定（週1でもいい）

この「入口設計」がないと、あなたの脳が入口になる。
それが燃え尽きの始まり。

4) トレードオフ表を持つ（断るための武器）

中堅が抱え込みやすいのは、「全部やる」以外の提示ができないからだ。
そこで使うのがトレードオフ表。

• スコープ増 → 納期延長 or 人員増 or 品質リスク受容

• 納期固定 → スコープ削減 or 品質定義変更

• 品質固定 → 納期延長 or 人員増

これを「表」として出すと、会話が急に大人になる。
感情論が減り、意思決定に寄る。中堅の負担が軽くなる。

5) 品質を3段階に分ける（守る場所を明確に）

品質を「全部100点」で守ろうとすると、燃え尽きる。
だから品質を3段階に分ける。

例：

• Must：事故ると致命傷（セキュリティ、データ整合性、監査要件）

• Should：守りたい（UX、性能、運用性）

• Could：余裕があれば（微改善、追加ログ、細かなリファクタ）

Must/Should/Couldを先に決めると、優先順位が作れる。
優先順位が作れると、スコープが暴れない。

6) RACIで責任分界を置く（責任の吸い込みを止める）

中堅は、責任を吸い込みやすいポジションにいる。
だから責任分界を、最低限RACIで書く。

• Responsible（実行責任）：誰がやる

• Accountable（最終責任）：誰が決める

• Consulted（相談）：誰に聞く

• Informed（共有）：誰に知らせる

燃え尽きる現場は、Accountableが空席か、全部あなたになっている。
ここを直さない限り、スコープ設計は完成しない。

7) 「終わりの条件」を決める（延命を止める）

終わりがない仕事は、必ず燃える。

• Doneの定義（受入条件）

• 例外処理の扱い（どこまで対応するか）

• 既知の不具合は次に送るルール

• 撤退条件（この前提が崩れたら見直し）

終わりを決めるのは、冷たい判断じゃない。
チームを守る判断だ。

それでも断れない人へ：断るのではなく「設計に戻す」

ここが一番大事なところ。
燃え尽きやすい中堅は、断ることに罪悪感を持つ。真面目だから。

でも、断らなくていい。
やることは、設計に戻すだけ。

• 「目的に照らすと、これは優先度どうしますか？」

• 「追加すると納期か品質に影響します。どっちを動かしますか？」

• 「In/Out更新しますね。次フェーズでいいですか？」

• 「意思決定者は誰ですか？承認を取りに行きます」

この言葉は、相手を否定していない。
仕事を前に進めるための、正しい会話だ。

あなたが守るべきは、相手の機嫌じゃなく、プロジェクトの整合性とあなた自身の持続性だ。

最後に：責任が増えること自体は悪くない

責任が増えるのは、期待されている証拠でもある。
ただし、スコープ設計なしに責任を引き受けると、燃え尽きる。

燃え尽きない人は、才能があるのではなく、境界を作っている。
目的を固定し、In/Outを明文化し、変更の入口を作り、トレードオフで会話し、品質を段階化し、責任分界を置き、終わりを決める。

もし今日から1つだけやるなら、どれがいいだろう。
あなたの現場で一番最初に整えるべき境界は、どこにある？

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
気に入って頂けたらマガジンのフォローもよろしくお願いします！