「仕事領域の侵食」と「リーダーシップ」の境界線

yatta47
·
公開:2025/11/24

私は仕事で何か事象が発生したとき、自然とやるべきことをピックアップしてしまう。そして、自分だけでは完結しないものは先に相手に投げて調整する。これが私の仕事のやり方だ。

でも最近、ふと気づいた。「これ、大量にあるな」と。そして、ふっと頭によぎった。

「私は仕事領域を侵食しているのだろうか?」

侵食とリーダーシップは紙一重

冷静に考えると、私がやっていることは「全体設計+初動のプロジェクトマネジメント」だった。

  • 事象を見て、必要なタスクを分解する

  • 依存関係を見て、自分だけで完結しないものを先に投げる

リーダー/PM寄りの動きをしている

でも、問題はそこじゃない。

侵食かどうかは、「やっている行動」ではなく「スタンス」と「線引き」で決まる。

侵食になりやすいパターン

振り返ると、自分にも当てはまる部分があった。

  1. タスクの「What」だけでなく「How」まで決めて、ほぼ指示になっている

    「Aさん、これお願い」ではなく、「この手順で、こう設定して、いつまでにここまでやって」まで決めてしまう

  2. 各チームの責任範囲を確認しないまま、自分がハブになっている

    誰がオーナーか曖昧なまま、とりあえず全部自分起点で投げる。結局、自分が全部管理する羽目になる

  3. 恒常的な運用タスクまで自分起点のまま

    本来そのチームが回すべきルーチンまで、なんとなく自分が頼られ続ける

  4. 上司・チームと役割の定義をすり合わせていない

    組織上は「エンジニア」なのに、実態は「全体のPM」みたいな動きになっている

これが積み重なると、周りからは「なんかあの人がいつも仕切ってる」「気づいたら仕事を取られている」という印象になる。

そして自分は「なんで全部俺が段取りしなきゃいけないんだ」と疲弊する。

リーダーシップに変えるための3つの転換

同じ動きでも、やり方次第で「侵食」ではなく「リーダーシップ」に変えられる。

まず「オーナー」を明確にする

事象が発生してタスクを洗い出したら、いきなり自分起点で投げるのではなく、こう考える。

  • これは誰の領域か

  • 自分はオーナーなのか、サポートなのか

「このインシデントの全体オーナーはAチームであるべきだな。自分はインフラ視点での技術支援と、論点整理まで」と決める。

「タスクをやる人」ではなく「構造を可視化する人」に寄せる

私の強みは「やらなきゃいけないことを自然とピックアップできること」だ。これは「タスク実行者」より「設計者・ファシリテーター」の才能に近い。

だから、タスクを全部自分のToDoに入れるのではなく、タスク一覧+オーナー候補を整理して、しかるべき人にボールを渡す役割にシフトする。

こう伝える:「今回の事象で必要なことをざっと整理しました。オーナーは◯◯チームだと思うので、タスク候補と優先度だけ共有します。実行のオーナーは◯◯さんにお願いしてもいいですか。自分は△△の部分でサポートに回ります。」

こうすると、侵食ではなく「全体を見てくれてる」「やりやすくしてくれてる」になる。

なかなか難しいときがあるんですけどね。本当はアプリケーション側で考えてもらいたいのに、全く考えないから指摘せざるを得ないというかなんというか。

着手前に3つの問いを立てる

何かタスクを拾ったとき、心の中でこれをチェックする。

  1. 自分がやる必然性はあるか?(役割・スキル・責任の観点)

  2. 自分がやることで、誰かの成長機会や本来の責任を奪っていないか?

  3. これが恒常運用になったとき、その面倒まで見る覚悟が自分にあるか?

2つ以上「No」なら、自分が実務をやるのではなく「設計・可視化・相談」までに留める。

長期的なリスクを直視する

私のスタイルは、短期的には「優秀な消防士・なんでも屋」として評価される。

でも長期的には:

  • 自分に仕事が集中する

  • 周りが「考えなくてもなんとかなる環境」になる

  • 自分がいないと回らない組織を作ってしまう

特に3番目がやばい。「育成の面ではいいけれど、このままだといなくなったら何もできない人が出てきちゃいそうだね」と言われたこともある。

「なんで俺だけ」は自己犠牲感が出始めている証拠なので、その辺をちゃんと組織の問題として取り扱って、健全な仕事ができるように進めていこうと思い振り返ってみました。