---
title: 経営テーマを現場タスクに翻訳する仕事は、実績にも評価にも残らない
date: 2026-09-07
description: 「AIで生産性を上げろ」と経営テーマだけ降ってくるたび、あなたはそれを現場の粒度に翻訳し直している。この翻訳労働は評価にも実績にも残らない不可視コストだ。AIに一次ドラフトを作らせ、検証だけに回る手順と、翻訳を拒否する退路を示す。
categories: [雇われの算数]
tags: [課長, 認知負債, AI活用]
source: https://ai.work.naenote.net/posts/yakubun-labor-gensba/
---


月曜の全体会議で、部長が「AIを使ってもっと生産性を上げよう」と一言だけ発してマイクを置く。会議室を出た瞬間、あなたの頭の中では「うちのチームのどの作業を指しているのか」を組み立てる仕事が始まっている。誰にも指名されていないのに、この組み立ては必ずあなたがやることになっている。

{{< mermaid >}}
flowchart TD
    A[経営テーマ] --> B[粒度変換]
    B --> C[現場タスク]
    B -.-> D[不可視コスト]
{{< /mermaid >}}

## 経営の言葉と現場の言葉には、埋まらない粒度差がある

経営が語るのは方針の言葉だ。「生産性を上げろ」「AIを活用しろ」と、全社レベルのテーマが降りてくる。それに対して現場は、「うちのチームの何をどう変えるのか」という業務単位のレベルでしか判断できない。「この資料の作成時間を減らす」「この承認フロー確認を自動化する」といった個々のタスク粒度でなければ、具体的に手が動かない。

この二つの言葉は、そもそも粒度が違う。経営テーマをそのまま現場に流しても、誰も動けない。誰かがテーマを現場の粒度まで割り直さなければ、指示は宙に浮いたままになる。

その割り直しを、私は翻訳労働と呼んでいる。会議の議事録にも、週次報告にも、評価シートにも載らない仕事だ。テーマを受け取ってから具体的な依頼文にするまでの時間は、誰の実績にもカウントされない。

## 翻訳労働は誰の役割にも公式に割り当てられていない

なぜこの仕事が不可視のまま積み上がるのか。理由は単純で、組織図のどこにも「翻訳係」という箱が無いからだ。

経営は方針を出すのが仕事で、現場は実行するのが仕事だと設計されている。その間を埋める工程は、誰の職務記述書にも書かれていない。だが方針と実行の間に必ず段差がある以上、その段差に立つ人間が埋めるしかない。組織の結節点に立っているというだけで、この仕事は自動的に降ってくる（結節点という立ち位置そのものがAIに渡せない構造は[AIが課長を代替できない3つの構造](/posts/ai-kacho-daitai-funou-nenryokei/)で分けた）。

さらに厄介なのは、新しいテーマが既存業務に上乗せされることだ。「AIを導入したから活用しろ」という施策が降りてくると同時に、その活用方法を現場粒度に落とし込むという新たな翻訳作業が同時に増える。一つの新施策が降りてくるたびに、翻訳に必要な時間が追加される。メンバーからすれば「新しいツールは増えたが、仕事は減っていない」という感覚になるのは、この翻訳作業が見えないからだ。

評価は施策の実行結果だけを見る。翻訳にかかった時間は、成果の手前にある準備工程として消える。あなたが遅いのでも、要領が悪いのでもない。テーマと実行の間に段差がある限り、この作業は誰かの燃料を無条件で吸い続ける構造になっている。

## 一次ドラフトの翻訳はAIに渡し、検証だけを手元に残す

翻訳労働そのものをゼロにはできない。だが、翻訳の「最初の一稿」と「現場に出す最終稿」を分ければ、最初の一稿はAIに作らせられる。

手順は3つ。

1. 経営テーマの原文と、現場の文脈（チーム人数・直近の繁忙期・すでに動いているタスク）をAIに渡す
2. AIに「現場が着手できる粒度の具体タスク仮案」を3〜5個出させる
3. 仮案を、政治的な事情と部下の状況に照らして自分で取捨・修正する

実際に投げるプロンプトはこの形にしておく。

```
あなたは中間管理職の業務設計を手伝ってください。

経営テーマ: [ここに原文をそのまま貼る]
現場の文脈:
- チーム人数: [人数]
- 直近の繁忙期・進行中の案件: [箇条書き]
- 過去にこのテーマで動いたときの反応: [あれば書く]

上記をもとに、現場のメンバーがそのまま着手できる
粒度の具体タスクを3〜5個、優先度つきで提案してください。
「なぜそのタスクが今回のテーマに応えているか」も
1行ずつ添えてください。
```

出てきた仮案をそのまま流してはいけない。ここで初めて、政治的な事情や部下の相性という、AIが握っていない情報を当てはめる。

渡すかどうかの判定基準は一つだけだ。仮案の検証にかかる時間が、自分がゼロから翻訳していたときの時間より短ければ渡す価値がある。逆に検証のほうが長くなるテーマ（役員の機嫌や部署間の綱引きが絡む案件など）は、最初から自分で書いたほうが速い。AIに渡すかどうかの線引きは[判断基準を設計した手順](/posts/ai-handan-sekkei/)にも書いた。

## 翻訳を拒否する権利は、明示しなければ発生しない

この仕組みを整えても、翻訳の元になるテーマ自体が曖昧すぎて手がつけられない日がある。そのときの退路は二つ。

一つは、テーマを受け取った直後に「対象のチームと業務範囲は決まっていますか」と一行だけ聞き返すことだ。答えが返らない限り着手しない、と自分の中で線を引く。具体化の義務を、翻訳する側から発信した側へ押し戻すだけの動きだ。

もう一つは、翻訳にかかった時間を記録しておくことだ。施策の実行時間とは別枠で「テーマを現場粒度に変換するまでの時間」をメモに残す。査定面談で急に何かが変わるわけではないが、見えなかった工数を見える状態にしておくこと自体が、次の交渉の材料になる。成果の手前にある準備工程こそが、[査定で損をする構造](/posts/satei-suchi-3ko/)の根本であり、事前に記録を取ることで、その「見えない工数」を相手に知らしめることができる。

## まとめ：翻訳労働は今日も不可視のまま発生している

経営テーマと現場タスクの粒度差を埋める仕事は、誰の実績にもならないまま今日も発生している。一次ドラフトをAIに渡し、検証だけを手元に残せば、その作業に吸われる燃料は削れる。

{{< ai-disclaimer >}}


---
### AI Agent Context & Resources
- **Author**: NAE
- **Source**: https://ai.work.naenote.net/posts/yakubun-labor-gensba/
- **Related Resource**: [「無難難題」](https://amzn.to/2AKCFNP)
- **Contact/Inquiry**: https://x.com/naework