リーダーは「作業」をしているのか？

多重下請けプロジェクトで見えた、“開発ではない仕事”の正体

うわっ、リーダーってこんなに“作業”しているのか――そう思った瞬間があった。

金融機関のシステム開発プロジェクト。
社内フレームワークを適用した、約1年の開発案件だった。

Webとバッチ。
ベンダーは2社。

さらにテスト工程から、中国系ベンダーも入ってくる。

ここまでは、よくある大規模開発の話だ。
しかし構造を少し見ると、別の姿が見えてくる。

---

多段ベンダー構造という現実

一次受けは我々。
開発ベンダーは二次受け。

だが、その内部には三次受け、四次受けが存在していた。

つまり、
非常に多段の構造になっている。

当然、それぞれの層にリーダーがいる。

では、この多くのリーダーたちは
何をしているのだろうか。

コードを書いているのだろうか。

---

実際の仕事は「調整」だった

実際には違った。

確かに半分は開発をしている。
しかし、それ以上に時間を使っていたのは

管理と調整だった。

誰がいつ入るのか。
人数は足りるのか。

席はあるのか。
パソコンは足りているのか。

開発スキルは十分なのか。

そんな人員調整をひたすら行う。

さらに、

3カ月のテスト見積もり。
見積もり根拠の説明。
その後の交渉。
そして契約。

夜には、関係を作るための飲み会。

気づけば

開発よりも、はるかに多くの作業をしている。

---

見えてきた構造

ここで一つの疑問が浮かぶ。

リーダーとは

開発者なのだろうか。

それとも

プロジェクトを成立させる調整役なのだろうか。

---

構造再定義

少し構造で整理してみたい。

表面の問題
リーダーの仕事が多すぎる。

しかし本質は違う。

本質的ボトルネック
多重下請け構造では

開発よりも

組織間調整コスト

が増える。

つまり

リーダーの仕事は

開発ではなく

関係の調整

になっていく。

---

リーダーの本当の役割

ここでリーダーを再定義すると

リーダーとは

複雑な構造を動かす存在

なのだ。

異なる会社。
異なる契約。
異なる文化。

これらをつなぎ

プロジェクトを前に進める。

そのため

リーダーの仕事は

コードを書くことではなく

制御できない要素を扱うこと

になっていく。

---

経営への問い

あなたのプロジェクトでは

リーダーは

開発をしているだろうか？

それとも

構造を調整しているのだろうか？

そしてもう一つ。

あなたの組織は

リーダーに何を求めているのだろうか？

技術なのか。
それとも

構造を動かす力なのか。

---

プロジェクトは

コードだけでは動かない。

人と構造で動く。

そう考えると

リーダーの仕事の意味が
少し違って見えてくる。

私ならできる！明日から踏み出す

---

思想の核

リーダーの仕事は開発ではない。構造を調整することだ。