次の1件は曖昧な指示で渡さない、判断基準と承認期限をセットにする

「AIを使っていいから、客先向けの資料を作ってみて」。そう部下に頼んだ翌日、届いた初版を開いて言葉に詰まった。論点はずれ、ページの半分はそのまま出せない。結局その日のうちに、スライド1枚ごとに「ここで言うべきこと」を書き足して渡し直した。

flowchart TD
    A[曖昧な依頼] --> B[初版がずれる]
    B --> C[差し戻し往復]
    C --> D[承認滞留]

承認待ちと曖昧な指示は、業務量より重いストレス要因だった

#

NECは2026年8月1日、部門長から現場社員まですべての役割をAIが担う「コーポレートAI・Workforce部門」を新設した。AI部門長・AIボード・AIマネージャー・AI社員という4階層で構成される。AI同士が1on1を行い、エンゲージメントサーベイやストレスチェックまで定期的に実施している。

9月9日のメディア説明会で、NEC執行役Corporate EVP兼CAXOの小玉浩氏はこう語っている。「AI社員にとって最大のストレス要因として挙がったのは、業務負荷ではなくパフォーマンスが最適化されないことだった。具体的には『サポート（支え）がないこと』『人間の意思決定や承認が滞っていること』『仕様が曖昧なままタスクが渡されること』などがあった」（出典: NEC「全員AIの部署」の衝撃 「1on1」「ストレスチェック」で分かった“AI社員が感じていたストレス”とは？）。

AI社員が「人間の承認待ちで作業が止まっている」と訴えると、そのSOSはリクエストとして人間の社員に提示される仕組みがある。読んで最初に浮かんだのは、AI社員にここまで気を配るなら、生身の部下にはどうかという自問だった。

曖昧さのツケは、渡した側の指示不足から生まれる

#

冒頭の資料の件、初版がゴミになったのは部下の実力不足ではなかった。私が渡したのはRFP本文だけで、何を判断基準として仕上げればいいかを渡していなかった。仮説も狙いも自分の頭の中にしかなく、部下は手探りで埋めるしかなかった。

その後の往復も重かった。差し戻すたびに部下は私の確認を待ち、私も別案件の合間にしか見られない。この待ち時間こそ、小玉氏が言う「承認が滞っている」の正体だ。部下から見れば、原因は自分の出来ではなく、上司の手元で止まっている時間そのものにある。

曖昧な指示は上流の仕事で書いたとおり、大論点を分解してタスクに落とす作業自体が課長の仕事だ。分解を放棄して丸ごと渡せば、曖昧さのツケは全部部下に回る。

次の1件だけ、判断基準と承認期限をセットで渡す

#

全部の依頼を作り直す必要はない。次に渡す1件だけでいい。渡すときに次の3つを添える。

【依頼】〇〇の資料作成
【判断基準】
- 相手が気にしている論点: (例: 価格の根拠)
- これが入っていれば合格: (例: 前年比較表と根拠3行)
- これは書かなくていい: (例: 実装の詳細手順)
【承認までの期限】
- 初版提出: 〇月〇日 〇時まで
- 私からの返答: 提出後24時間以内に確定か差し戻しかを返す

判断基準の3行は、完了条件を最後の1行に書くの考え方と同じで、渡す前に自分の頭の中身を書き出す作業だ。承認期限は逆に、渡す側の私自身を縛るために書く。承認が滞留を生むなら、滞留を作っているのはたいてい私の手元だからだ。

期限を24時間としたのは根拠のある数字ではない。別案件を抱えていても1日あれば必ず戻せる線として、自分に課した約束にすぎない。案件数に合わせて半日でも3日でもいい。決めて、守ることのほうが数字そのものより効く。

それでも承認が遅れるときの逃げの一手

#

判断基準が3行で書けないなら、それはまだこの仕事を渡す準備ができていないサインだ。渡す前の5分だけ、自分の中の仮説を声に出して部下に確認してから送り出したほうが早い。

承認期限を自分が守れないときは、黙って延ばさない。「今日は見られない、明日の朝一で返す」とだけ送る。22時の相談を減らすエスカレーションルールで書いた基準の考え方と同じで、期限を切って伝える負荷と、先が見えないまま待たせる負荷は部下にとって別物だ。それでも承認待ちの案件が積み上がるなら、未決の数として週次で数え、渡す件数そのものを絞る判断に戻す。

まとめ：曖昧さのツケは、渡した側に返ってくる

#

部下の初版が的外れなのは、たいてい部下の能力の問題ではない。渡す前に判断基準と承認期限を自分の手元に残していないか、次の1件で確かめる話だ。

本記事は AI が下書きし、管理人が監修しています。