Digital Heroes: Guide to IT World

多重下請けプロジェクトで見えた、“開発ではない仕事”の正体 うわっ、リーダーってこんなに“作業”しているのか――そう思った瞬間があった。 金融機関のシステム開発プロジェクト。 社内フレームワークを適用した、約1年の開発案件だった。 Webとバッチ。 ベンダーは2社。 さらにテスト工程から、中国系ベンダーも入ってくる。 ここまでは、よくある大規模開発の話だ。 しかし構造を少し見ると、別の姿が見えてくる。     多段ベンダー構造という現実 一次受けは我々。 開発ベンダーは二次受け。 だが、その内部には三次受け、四次受けが存在していた。 つまり、 非常に多段の構造 になっている。 当然、それぞれの層に リーダー がいる。 では、この多くのリーダーたちは 何をしているのだろうか。 コードを書いているのだろうか。 実際の仕事は「調整」だった 実際には違った。 確かに半分は開発をしている。 しかし、それ以上に時間を使っていたのは 管理と調整 だった。 誰がいつ入るのか。 人数は足りるのか。 席はあるのか。 パソコンは足りているのか。 開発スキルは十分なのか。 そんな人員調整をひたすら行う。 さらに、 3カ月のテスト見積もり。 見積もり根拠の説明。 その後の交渉。 そして契約。 夜には、関係を作るための飲み会。 気づけば 開発よりも、はるかに多くの作業をしている。 見えてきた構造 ここで一つの疑問が浮かぶ。 リーダーとは 開発者なのだろうか。 それとも プロジェクトを成立させる調整役なのだろうか。 構造再定義 少し構造で整理してみたい。 表面の問題 リーダーの仕事が多すぎる。 しかし本質は違う。 本質的ボトルネック 多重下請け構造では 開発よりも 組織間調整コスト が増える。 つまり リーダーの仕事は 開発ではなく 関係の調整 になっていく。 リーダーの本当の役割 ここでリーダーを再定義すると リーダーとは 複雑な構造を動かす存在 なのだ。 異なる会社。 異なる契約。 異なる文化。 これらをつなぎ プロジェクトを前に進める。 そのため リーダーの仕事は コードを書くことではなく 制御できない要素を扱うこと ...