責任だけ増える中堅へ──燃え尽きないためのスコープ設計
気づけば、責任だけが増えていく。
メンバーは増えないのに、期待は増える。納期は短くなるのに、品質は落とせない。仕様は揺れるのに、説明責任はこっちに寄ってくる。
「自分が頑張れば何とかなる」
その姿勢で何年もやってきた人ほど、ある日ふっと心が折れる。燃え尽きるのは、根性が足りないからじゃない。むしろ逆で、責任感が強いから起きる。
燃え尽きないために必要なのは、休み方の工夫だけじゃない。
現場を壊す前に、スコープを設計すること。今日はそれを、実務で使える形に落として書く。
なぜ中堅ほど燃え尽きるのか
燃え尽きる中堅には、共通の構造がある。
「期待値」が増える（頼られる、任される、相談される）
「権限」は増えない（人員・予算・意思決定権がない）
「範囲」が曖昧な仕事が増える（隙間・穴埋め・火消し）
「断るコスト」が上がる（断ると信頼が落ちそうに見える）
この状態で頑張り続けると、どこかで破綻する。
だから必要なのは、仕事量の削減より先に、仕事の境界を作ることだ。
ここからが本題。
スコープ設計とは何か（定義）
スコープ設計は、単に「範囲を決める」ことじゃない。
燃え尽きないためのスコープ設計は、次の5つをセットで整えることだ。
目的（ゴール）：何のためにやるのか
範囲（In/Out）：どこまでやって、どこからやらないのか
品質（Quality）：何を守り、どこは妥協できるのか
制約（Constraint）：納期・人員・技術・運用の現実
責任分界（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業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
いいなと思ったら応援しよう！
よろしければ応援お願いします！ いただいたチップはクリエイターとしての活動費に使わせていただきます！ 