マネジメントが苦手な人へ──人を動かす前に整える設計図

マネジメントって、苦手だと思う。
人に頼むのが怖い。指摘も苦手。強く言えない。かといって放置すると、締切だけが近づいていく。

特に、ITの現場で30代〜40代前半になると、こういう場面が増える。
自分で手を動かせば速いのに、リードやPMっぽい立場になると「人が動かない」問題に直面する。
しかも厄介なのは、頑張れば頑張るほど自分が疲れていくことだ。

ここで最初に言う。
マネジメントが苦手なのは、人格の問題じゃない。
多くの場合、「人を動かす前に整える設計」が抜けているだけだ。

人が動かないとき、原因は大きく2つに分かれる。

• 相手が動きたくない（動けない事情がある）

• そもそも動ける設計になっていない

そして、現場で起きているのはたいてい後者。
つまり、あなたが悪いわけじゃない。設計が足りないだけだ。

この記事では、マネジメントが得意ではない人でも再現できるように、
「人を動かす前に整える設計図」を、実務の手順として書く。

まず確認：マネジメントは「人を動かす技術」ではない

多くの人が、マネジメントをこう誤解している。

• 指示を出して動かす

• モチベーションを上げる

• 叱る、褒める、育てる

• リーダーシップで引っ張る

もちろん要素としてはある。
でも、これを「最初に」やろうとすると、苦手な人ほど詰む。

なぜなら、そこは「対人スキルの強さ」が出る領域だから。
苦手な人がいきなりそこに行くと、疲れるし、空回りする。

マネジメントの本質は、人の努力を成果に変換する仕組みを作ること。
つまり、設計の仕事だ。

• 何をやるか

• どこまでやるか

• いつまでにやるか

• どう判断するか

• 誰が責任を持つか

• 何が詰まりポイントか

• 詰まったらどうするか

ここが整っていれば、人は驚くほど動く。
逆に、ここが曖昧なら、どれだけ優しく声をかけても進まない。

人を動かす前に整える設計図：5枚で足りる

僕は、マネジメントが苦手な人ほど、設計図を「少ない枚数」で持つべきだと思っている。
増やすと運用できない。形骸化して逆にしんどくなる。

必要なのは、5枚だけ。

1. ゴール（成功条件）

2. 役割（責任と権限）

3. 進め方（意思決定とコミュニケーション）

4. 見える化（進捗ではなく兆候）

5. 詰まりの扱い（リスクとエスカレーション）

順番にいく。

① ゴール：成功条件を「1文＋3つ」に落とす

人が動かない最大の理由は、サボりでもやる気でもない。
「何を目指せばいいかが曖昧」だからだ。

まず、成功条件を短く固定する。
おすすめはこの形。

• 1文：この取り組みで達成したい状態

• 3つ：その状態を示す指標（または完了条件）

例（システム改修の小プロジェクトなら）

• 1文：問い合わせ対応にかかる時間を減らし、運用を安定させる

• 3つ：

  • 重大障害を月0件にする

  • 問い合わせ一次回答までの時間を平均30%短縮

  • 手順書を更新し、新メンバーが1日で対応できる状態にする

ここで重要なのは「作業」ではなく「状態」で書くこと。
タスクを並べると、人は言われたことをやるだけになり、状況変化に弱くなる。

② 役割：RACIで「責任の穴」を潰す

マネジメントが苦手な人ほど、実は優しすぎる。
曖昧なままお願いして、相手が困っても強く言えず、最後に自分が巻き取る。

これを止めるのが役割設計。
難しくしない。RACIで十分。

• R：実行責任（やる人）

• A：説明責任（決める人・最終責任）

• C：相談（意見を聞く人）

• I：共有（知らせる人）

ポイントは、Aを必ず一人にすること。
Aが複数になると、誰も決めない地獄が始まる。

そしてもう一つ。
役割設計は「人を縛るため」ではなく、「迷いを減らすため」にやる。

迷いが減ると、人は動ける。

③ 進め方：会議ではなく「意思決定の流れ」を決める

人が動かない現場は、会議は多いのに決まらない。
決まらないから、各自が勝手に進めて、最後に崩れる。

だから決めるのは、会議体ではなく意思決定の流れ。

最小構成はこれ。

• 週1：意思決定の場（30分）

• 日次：同期（10分）

• 随時：詰まり共有（チャット）

意思決定の場で扱うのは、3つだけ。

1. 今日決めたい論点

2. 選択肢（A/B/C）

3. 決定と次アクション（誰がいつまでに）

これを毎回同じ型で回す。
マネジメントが得意な人はカリスマで回す。
苦手な人は型で回せばいい。

④ 見える化：進捗ではなく「兆候」を追う

進捗管理って、実は人を動かしにくい。
「遅れてる」「まだ終わってない」が続くと、人は守りに入って黙る。

動く現場は、進捗より兆候を見ている。

兆候とは、「このままだとヤバい」を早く検知するサイン。

例えばITプロジェクトなら、こういうもの。

• 仕様の未確定が残っている

• 外部依存（待ち）が増えている

• レビュー差し戻しが増えている

• テストで同種の不具合が続く

• 残業が増え、報告が短くなる（心理的余裕が消える）

これらを、赤黄緑で簡単に見える化する。
「遅れてる？」ではなく、「危ない兆候ある？」に問いを変える。

これだけで、報告の空気が変わる。
責める会話から、守る会話に変わる。

⑤ 詰まりの扱い：エスカレーションを「許可」する

マネジメントが苦手な人ほど、詰まりを一人で抱える。
「自分が解決しないといけない」と思う。
でも、そこで詰む。

人を動かす前に必要なのは、詰まりを上げる“許可”だ。

具体的には、こう宣言する。

• 24時間止まったら相談していい

• 48時間止まったらエスカレーションしていい

• 詰まり共有は評価を下げない

• 早く詰まりを出した人を褒める

これ、精神論じゃなく運用ルール。
これがあると、詰まりが早く見える。
見えれば、手が打てる。結果、炎上が減る。

ここまで整うと「人を動かす」がいらなくなる

ここまで読むと、こう思うかもしれない。
結局、マネジメントって仕組みづくりで、対人スキルは不要なの？

違う。
対人スキルは必要。でも、順番がある。

設計が整っていない状態で対人スキルを要求すると、苦手な人ほど燃える。
設計が整っていれば、対人スキルの負荷は下がる。
そして、必要な会話が少なくなる。

マネジメントが得意な人は、会話で整える。
苦手な人は、設計で整えてから会話する。
どちらでも成果は出せる。

明日から使える「整える設計図」チェックリスト

最後に、現場でそのまま使えるように、チェックリストにする。
全部やらなくていい。弱いところから一つだけ入れる。

• 成功条件が1文で言える

• 完了条件（Done）が3つある

• A（最終責任者）が一人に決まっている

• 週1で意思決定の場がある

• 論点→選択肢→決定→次アクションの型がある

• 進捗ではなく兆候（赤黄緑）を見ている

• 詰まりの相談ルール（24h/48h）がある

• 詰まり共有が評価を下げないと明言している

これが整ってくると、あなたは「人を動かす人」ではなく、
「人が動ける状態を作る人」になる。

そして、そのほうが長く戦える。
30代〜40代のキャリアは、短距離走じゃなく持久戦だから。

最後に、問いを置く。
あなたのチームで今いちばん整っていないのは、5枚の設計図のうちどれだろう？

次に読む：

はじめての方へ：

マガジンの紹介：

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