開発者だけでは世界は動かない——200人プロジェクトで見えた“不都合な真実”

うわっ…コードを書けるだけでは、巨大プロジェクトは1ミリも前に進まない！

■7年目、200人の渦の中へ

あの時、私はエンジニア7年目。200人を超える巨大プロジェクトの「構成管理担当」を任された。CobolからJavaへの大規模な移行。会社としても勝負の案件だった。周囲からは「Javaの専門家」として見られていたが、正直に言えば、それは半分正しく、半分誤解だった。

 
 

なぜなら、私は前のプロジェクトで社内フレームワーク「Justware」の導入サポートをしていた。その経験が評価され、この現場に呼ばれただけだったからだ。だが現場に入れば、そんな事情は関係ない。「Javaといえば構成管理が肝」——その期待のもと、私は中心に立たされた。

■構成管理という“見えない支配”

構成管理とは何か？それは単なるバージョン管理ではない。
誰が、どのルールで、どのパッケージを使い、どうやって統合するか——プロジェクトの秩序そのものだ。

200人の開発者がそれぞれにコードを書く。その全てを束ね、「最新版」を定義する。そしてその先にいるのは、環境エンジニアだ。彼らがデプロイし、システムは初めて動く。

つまり、構成管理は“開発の終点”ではなく、“運用の入口”でもある。ここを間違えれば、全てが崩れる。

■しかし、現実はそんなに甘くない

問題はすぐに表面化した。
「このライブラリを使いたい」
「そのルールは非効率だ」
「なぜこの命名規則なのか」

200人いれば、200通りの正義がある。ルールを決めることは、誰かの自由を制限することでもある。議論は常に衝突を伴った。

ここで気づいたのは、「技術的に正しいこと」と「プロジェクトが進むこと」は別物だという現実だった。

正論だけでは、人は動かない。

■開発者の先にいる“もう一つの主役”

さらに重要なのは、開発者の先にいる存在だ。
環境エンジニア、そして本番環境を支える対顧客チーム。彼らはシステムの提案を行いながら、運用も担う。

いわゆる「System Engineer」と一括りにされるが、その実態は千差万別だ。コードを書く者、環境を整える者、顧客と向き合う者。それぞれが異なる価値を持ち、異なる責任を背負っている。

にもかかわらず、開発者中心の議論が支配すると、彼らの視点は後回しにされる。結果、動かないシステムが生まれる。

■では、プロジェクトを動かすのは誰か

結論はシンプルだが、受け入れにくい。
プロジェクトは「開発者」だけでは動かない。

むしろ、ルールを設計し、利害を調整し、全体をつなぐ存在——つまり“構造をデザインする人間”がいなければ、どれだけ優秀なエンジニアがいても崩壊する。

これはエンジニアにとって耳の痛い話だ。
「技術力があれば勝てる」という幻想を壊すからだ。

■ビジネスへの示唆

この経験から得た教訓は明確だ。
DXも同じである。ツールやAIを導入しても、それだけでは何も変わらない。重要なのは、それをどう使い、どう全体を設計するかだ。

組織もプロジェクトも、「人の集合体」ではなく「構造の集合体」である。

そして、その構造を誰が握るのか。
そこにこそ、勝敗の分岐点がある。

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