担当者なのに係長級の仕事が来る理由
会社で働いていると、たまにこういう違和感があります。
「自分は担当者のはずなのに、やっている仕事は係長級では？」 「既存業務を処理しているだけではなく、未定義の仕事を要件定義している」 「関係者調整、役割分担、進行管理、改善提案までやっている」 「でも評価や権限は担当者のまま」
これは単なる気のせいではありません。
多くの場合、職位と業務内容がズレる背景には、 職位・権限・評価・実作業のレイヤーが一致していない という構造があります。
この記事では、なぜ担当者に係長級・課長補佐級の仕事が流れてくるのかを整理します。
本来、職位ごとに仕事のレイヤーは違う
本来の役割をざっくり分けると、以下のようになります。
| 職位 | 本来の役割 |
|---|---|
| 担当者 | 決まった業務を正確に処理する |
| リーダー | 既存業務を改善し、周囲を少し巻き込む |
| 係長 | 未定義の課題を実行可能な形に落とし、関係者を動かす |
| 課長・課長補佐 | 部としての方向性、優先順位、体制、責任範囲を決める |
もちろん会社によって呼び方は違います。
ただ、一般的には、 決まった仕事を処理することと、 未定義の仕事を定義して人を動かすことは、別レイヤーの仕事です。
たとえば、単に動画を撮るだけなら担当者の作業かもしれません。
しかし、以下までやっているなら話が変わります。
- 目的を整理する
- 誰向けの成果物か決める
- 構成を考える
- 必要な素材を洗い出す
- 誰に何を任せるか決める
- 関係者へ協力依頼する
- 撮影・編集・確認の流れを作る
- 短期間でMVPを作る
- 反省会や改善につなげる
これは単なる作業ではありません。
未定義業務の要件定義とPMです。
つまり、担当者という肩書きでも、実際には係長級の仕事をしている可能性があります。
職位と業務内容がズレる理由1：職務定義が曖昧
一番大きい理由は、会社が職務を明確に定義していないことです。
「担当者はここまで」 「リーダーはここから」 「係長は何を担う」 「新規施策の責任者は誰」 「判断者は誰」 「成果はどの等級に紐づくのか」
この境界が曖昧だと、仕事は自然と「できる人」に流れます。
その結果、
- 肩書きは担当者
- 権限も担当者
- 給与も担当者
- でも仕事の中身は係長級
というズレが起きます。
これは、個人の能力が高いからこそ起きることもあります。
しかし、能力が高いことと、上位職務を無償で吸収してよいことは別です。
職位と業務内容がズレる理由2：上司が目的だけ持っていて、要件定義できない
上司が方向性だけを持っているケースもあります。
たとえば、
「動画教材を作りたい」 「教育をよくしたい」 「標準化したい」 「今までにない取り組みをしたい」 「部として改善したい」
という目的はある。
しかし、それを実際に進めるためには、さらに分解が必要です。
- 誰向けか
- 何を伝えるのか
- どの形式にするのか
- どこまでを初回MVPにするのか
- 誰に何を任せるのか
- どの順番で進めるのか
- 何をもって完成とするのか
- どう評価・改善するのか
ここまで落とせないと、現場は動きません。
そして、その分解を担当者がやっている場合、実態としては担当者がPMをしています。
上司が「やりたいこと」を出し、担当者が「実行可能な形」に落としている。
この時点で、担当者はただの作業者ではなく、 未定義業務を定義する役割を担っています。
職位と業務内容がズレる理由3：「実力があれば早く上がれる」の実力定義が曖昧
「実力が高ければ早く昇格できる」
この考え方自体は悪くありません。
むしろ、年功だけでなく実力を見る制度は、うまく運用されれば健全です。
問題は、 その“実力”が何を指すのか明確でないことです。
制度文には「実力」「主体性」「改善力」「新しいことへの挑戦」などと書かれていても、現場での解釈が曖昧だと、評価は所属長の主観に寄ります。
すると、こうなります。
制度上は、 「実力があれば早く上がれる」
でも現場では、 「私はこう思う」 「まだ足りない気がする」 「もっと主体性がほしい」 「頑張っている感じが見えない」 「これは担当者としてやっただけ」
という後出し評価が起きます。
これが、いわゆる 所属長の感度ガチャ です。
感度の高い上司なら、未定義業務の要件定義やPMを「上位等級の行動」と見ます。
しかし感度の低い上司だと、単に「動画を作った」「資料を作った」「早く終わらせた」としか見ない可能性があります。
職位と業務内容がズレる理由4：評価制度がアセスメント風でも、運用が紙回収になっている
会社によっては、報告制度や改善活動を「アセスメントで見る」と言うことがあります。
本来、アセスメントで見るなら、以下を確認する必要があります。
- 何を目的にしたか
- どんな課題を見つけたか
- どう考えたか
- どんな改善をしたか
- 関係者をどう巻き込んだか
- どんな成果が出たか
- 次にどう活かすか
- 上位等級の行動に該当するか
しかし実際の運用が、
- 紙を提出する
- 完了報告だけする
- フィードバックがない
- 所属長によって見方が違う
- 部署によって扱いが違う
という状態なら、それはアセスメントではありません。
アセスメント風・紙回収制度です。
この状態では、同じ成果を出しても、部署や所属長によって評価が大きく変わります。
つまり、評価制度があるように見えても、実態は 所属長の感度依存 になっています。
職位と業務内容がズレる理由5：できる人税が発生する
仕事が速く、構造化でき、曖昧なものを形にできる人には、仕事が集まりやすくなります。
理由は単純です。
周囲から見ると、
「あの人ならできそう」 「あの人に聞けば進みそう」 「あの人なら形にしてくれそう」 「あの人は説明もできるし、人も動かせる」
となるからです。
しかし、ここには大きな誤解があります。
速くできることと、軽い仕事であることは違います。
たとえば、ある人が1週間で新規事業のMVPを作ったとします。
それを見て、周囲が 「1週間でできたなら簡単なんだね」 と考えるのは誤りです。
実際には、
- 課題発見
- 要件定義
- UI設計
- 出力形式の設計
- 課金導線
- API原価
- セキュリティ
- 不正利用対策
- LP
- SEO
- 運用
- 実装指示
- 監査
まで考えているかもしれません。
これは軽い仕事ではありません。
その人の変換速度が高いから短期間で形になっているだけです。
この違いを評価側が見落とすと、できる人ほど損をします。
これが、できる人税です。
職位と業務内容がズレる理由6：上位業務を担当者にロンダリングしている
担当者に係長級の仕事が来る構造を、少し強めに言うなら、 上位業務ロンダリングです。
本来なら係長や課長が担うべき仕事を、正式な役割・権限・評価を渡さないまま、担当者の仕事として流している状態です。
たとえば、
- 新規施策の立ち上げ
- 未定義業務の整理
- 目的設定
- 要件定義
- 関係者調整
- 役割分担
- 進行管理
- 成果物の品質管理
- 部門標準化への展開
これらは、単なる担当者作業ではありません。
にもかかわらず、
「担当としてやってね」 「主体性を出してね」 「改善してね」 「でも権限・評価・給与は担当者ね」
となると、職位と業務内容は不一致になります。
具体例：動画教材制作は「撮影」ではなく、未定義業務のPM
動画教材を作る仕事を例にします。
単にカメラを回すだけなら、作業です。
しかし実際には、
- 何を伝える動画にするか
- 誰向けにするか
- どういう構成にするか
- 説明者と聞き手をどう配置するか
- 新人にどこを任せるか
- 関係者へどう協力依頼するか
- どこまでを初回完成とするか
- 反省会で何を確認するか
- 今後どう教育・標準化へつなげるか
まで設計しているなら、それはPMです。
さらに、短期間でMVPを作り、反省会できる完成度まで持っていったなら、これは明らかに改善推進です。
表面的な成果物は「3分の動画」かもしれません。
しかし職務レベルで見ると、 前例のない教育施策を要件定義し、関係者を巻き込み、短期間でMVP化した という実績です。
これは、担当者の単純作業ではありません。
具体例：標準書アプリは「アプリ作成」ではなく、新規事業立ち上げ
標準書アプリのようなものも、単に「アプリを作った」と見ると価値を見誤ります。
実際には、
- 現場の標準書作成が面倒
- 口頭説明が消える
- 教育が属人化する
- 作業説明が整理されない
- 新人教育に時間がかかる
という課題を見つけています。
そこから、
- 音声入力
- テキスト入力
- AIによる整理
- 標準書出力
- DOCX / PPTX / XLSX / TXT / Markdown
- 質問候補
- 説明漏れチェック
- 課金導線
- API原価
- 無料枠
- 不正利用対策
- セキュリティ
- ログ
- LP
- SEO
- 多言語展開
まで考えているなら、それは単なるアプリ作成ではありません。
業務改善をSaaS化する新規事業立ち上げです。
しかも、それを帰宅後や土日などの短い時間で進めているなら、スピード自体が大きな強みです。
ただし、ここでも注意が必要です。
早くできると、周囲は軽く見ます。
でも実際には、 普通の人がPCを買う、開発環境を整える、APIを使う、GitHubを触る、エラーを読む、公開する、課金を考える という時点で止まることも多いです。
その壁をまとめて突破しているなら、軽い仕事ではありません。
なぜ本人は苦しくなるのか
職位と業務内容がズレると、本人は苦しくなります。
理由は明確です。
- 上位業務をしているのに、権限がない
- 判断責任はあるのに、決定権がない
- 成果は求められるのに、評価に反映されるか不明
- 失敗したら本人責任になりやすい
- 成功しても「担当として頑張った」で終わる可能性がある
- 仕事が速いほど、さらに仕事が集まる
- 成果物だけ見られて、設計・調整・要件定義の価値が見えない
この状態では、違和感が出て当然です。
本人の認知が歪んでいるのではなく、 役割・権限・評価・責任の対応関係が歪んでいる 可能性があります。
どう対策するか：成果物ではなく、職務レベルで記録する
この構造で重要なのは、成果物だけを記録しないことです。
たとえば、
「動画を作った」 「アプリを作った」 「資料を作った」
だけでは弱いです。
評価者によっては、ただの作業に見えてしまいます。
そうではなく、職務レベルで記録します。
悪い書き方
動画を作成した。 標準書アプリを作成した。 資料をまとめた。
強い書き方
前例のない動画教材制作について、目的整理・構成設計・役割分担・関係者調整・撮影進行・MVP作成まで主導した。部門の教育・標準化に向けた新規施策として、短期間で反省会可能な完成度まで推進した。
標準書アプリの場合
現場の標準書作成・教育属人化という課題をもとに、音声・テキスト入力からAIで標準書を生成し、DOCX/PPTX/XLSX/TXT/Markdownで出力できるWebサービス案を設計した。課金、API原価、不正利用、セキュリティ、LP、SEO、運用まで含めてMVP化を進めた。
このように書くと、単なる成果物ではなく、 目的整理・要件定義・PM・改善推進・新規施策立ち上げ として見えます。
会社に伝えるなら、怒りではなく定義で話す
この話を会社に伝える場合、怒りだけで言うと損をします。
「これ係長の仕事ですよね？」 「なんで担当にやらせるんですか？」 と正面から言うと、相手が防御的になる可能性があります。
代わりに、こう言う方が強いです。
今回の取り組みは、既存業務の処理ではなく、前例のない新規施策について、目的整理・要件定義・役割分担・関係者調整・MVP作成まで担ったものです。担当業務の範囲を超えて、係長相当の改善推進・PM要素があると考えています。
ポイントは、 気持ちではなく、職務定義に接続することです。
「頑張った」ではなく、 「この行動は上位等級のどの定義に該当するのか」 で話します。
これにより、所属長の主観だけに飲まれにくくなります。
この構造に名前をつける
反芻しやすい違和感には、名前をつけると扱いやすくなります。
担当者名義の係長級PM案件
肩書きは担当者だが、実態としては係長級の未定義業務・PMを担っている状態。
所属長感度ガチャ型評価
同じ成果でも、所属長が職務レベルを見抜けるかどうかで評価が変わる状態。
アセスメント風・紙回収制度
制度上は成長や実力を見ると言いながら、実態は提出・完了確認だけで、フィードバックや評価接続が弱い状態。
上位業務ロンダリング
本来は上位職が担うべき仕事を、正式な権限・評価を渡さず、担当者業務として流す状態。
できる人税
できる人が速く形にするほど、仕事が軽く見られ、さらに未定義業務が集まる状態。
まとめ：職位と業務内容の不一致は、個人の違和感ではなく構造問題
担当者なのに係長級の仕事が来るのは、本人の思い込みとは限りません。
多くの場合、背景には以下の構造があります。
- 職務定義が曖昧
- 上司が要件定義できない
- 「実力」の定義が主観的
- 所属長ごとに評価感度が違う
- アセスメント制度が形骸化している
- できる人に未定義業務が集まる
- 上位業務が担当者にロンダリングされる
- 成果物だけ見られて、設計・調整・PMの価値が見えない
だからこそ、対策はシンプルです。
成果物ではなく、職務レベルで記録すること。
「動画を作った」ではなく、 「前例のない教育施策を要件定義し、関係者を巻き込み、MVP化した」
「アプリを作った」ではなく、 「現場課題をAI SaaSとして設計し、課金・運用・セキュリティまで含めて事業化を進めた」
このように、自分の仕事を正しいレイヤーで言語化する必要があります。
職位と業務内容がズレていると感じたら、まずは怒る前に、 自分が担っている仕事のレイヤーを分解する ことが重要です。
担当者作業なのか。 改善推進なのか。 未定義業務のPMなのか。 部門施策の立ち上げなのか。 新規事業開発なのか。
ここを切り分けると、違和感の正体が見えてきます。
そして、もし実態が上位職務であるなら、 それは軽い仕事ではありません。
速くできたから軽いのではなく、能力が高いから速く形になっただけです。
その価値には、ちゃんと名前と値札をつけていいのです。