なぜSIerは下請会社から人をかき集めないとソフトウェア開発できないのか？

2022年4月3日 13:59

どうも、エンジニアのgamiです。

最近、IT業界の外で働く人から「なぜ日本のSIerは多重下請け構造型の組織体制で開発プロジェクトを進めるのか？」という主旨の質問をされました。

確かに、業界の外から見れば「なぜわざわざ色んな会社から人を集めてシステム開発をしなければならないのか？」と疑問を持つのは当然です。日本の行政機関や大企業の業務オペレーションを担う根幹のシステムのほとんどは、NTTデータや富士通やNECといったSIerを頂点とする多重下請け構造型組織によって開発されてきました。

僕は新卒で入社した富士通に1.5年間しか在籍していませんでした。その割にはSIerの問題やその中で働くエンジニアのキャリアについてやたら発信していた時期があり、ブログに「1.5年しかいなかったのにSIerを語るな」というお叱りのはてなブックマークコメントを貰ったこともありました。

今さらSIer界隈について語りたい欲求も無かったのですが、改めて業界外の人から質問をされたことで、改めて自分の言葉で考え直したい気持ちが出てきました。僕は一時期ポッドキャストを趣味でやっていて、累計50人以上はSIer界隈出身のエンジニアをゲストに読んで当時の仕事の話を聞いてきました。また富士通を辞めてから、IT業界でもまた別の界隈で5年以上働いてきました。そんな僕だからこそ、大手SIerによる大規模システム開発を客観的かつ対比的に語れることもあるでしょう。

SIerについて語れることは色々とあるのですが、今回は当初の質問にある「SIerによる大規模システム開発で多重下請け構造が発生するのはなぜか？」という点に絞って書きたいと思います。

多重下請け構造とは、あえて悪く言えば「どこの誰かわからない人をかき集めて数十〜数百人規模の開発プロジェクトを回すこと」を意味します。このような開発の進め方は、ソフトウェア開発のトレンドとしても、その中で働く個人の働き方としても、あまり推奨されるべきものではありません。そんな評判の悪いやり方をなぜ脱却できないのか、その謎に自分なりの答えを出してみます。

多重下請け構造の不自然さ

SIerと呼ばれる類のIT企業は、主にクライアントとなる企業や団体からの発注を受けてITシステムを構築します。代表的な業務の流れは、次の通りです。

営業やSEがクライアントの課題を元にシステム開発の提案を行う
クライアントから発注を受けて、開発プロジェクトが開始される
数ヶ月〜数年かけてシステムが開発・検証される
システムが納品され、実際に稼働する
その後、バグ修正や仕様変更などを含む保守が続く

多重下請け構造が問題になるのは、主に3番の「開発・検証」フェーズです。

システムの発注を直接受けた富士通などの「一次請け」企業の立場で考えてみましょう。規模の大きいシステム刷新になると、100人以上の開発者がプロジェクトに関わることもあります。一方で、システム開発の発注先はコンペで決められることもあり、確実に自社に発注がもらえるかは発注が決まるまでわかりません。短期間で自社の正社員を一気に100人採用するようなことは一般的に難しく、仮にできたとしてもプロジェクトの解散とともに大量の余剰人員を抱えるリスクがあります。

そこで、その100人の人員を確保するために、二次請けとなるA社から40人、B社から30人、C社から30人といったように人を出してもらいます。もちろん、「一気に社員を増やすのはリスクがある」という事情はA社も同様です。A社はさらに三次請けのAA社から15人、AB社から15人、AC社から10人と人を出してもらいます。プロジェクトに必要な人員を確保できるまでこれが続くことで、多重下請け構造が完成します。

ITゼネコンの多重下請け構造( http://www.dream-think.com/data/c090.htm )

僕が富士通のオフィスで働き始めたときも、フロアで働く人の中で富士通の正社員は2〜3割しかいないと聞かされ、非常に驚いたことを覚えています。その他のメンバーは、パートナー企業と呼ばれるいわゆる下請け企業の社員の方々でした。

面白いことに、多重下請け構造の中では「プロジェクトメンバーの誰がどこの会社の人なのかパッと見ではよくわからない」という事態が起きます。たとえば二次請け会社の名刺を持っているメンバーであっても、本当の所属は三次請けや四次請けの会社だったりします。こうして様々な会社のメンバーがモザイク状に混ざった形で、プロジェクトチームは組成されます。

一般に、一次請けに近い立場でシステムの要件定義や設計を行う企業をSIer（システムインテグレーター）、下請けの立場でエンジニアを派遣する企業をSES（システムエンジニアリングサービス）企業と呼びます。

SESは雑に言えば「人を集めてきてどこかの開発プロジェクトに潜り込ませることに成功すればお金が入り続ける」というビジネスモデルです。起業するのに元手があまり要らないこともあって、IT投資の伸びとともにSES企業は市場に乱立しました。中にはエンジニアリングの経験や適性が無い人を雇い、経歴を盛って派遣するような悪質業者もいたようです。

これまで僕が話を聞いたエンジニアの中には、最大「七次請け」まで経験したことがある方がいました。こうした多重下請け構造を基盤とする開発プロジェクトでは、全ての下請け企業やプロジェクトメンバーの実態を正確に把握することが難しくなります。その結果、スキルや職業倫理が想定以上に低いメンバーが紛れ込みやすく、ただでさえ難易度の高い大規模システム開発の舵取りをいっそう難しくします。

※ ちなみにここまでSESのことを「派遣」と表現してますが、「SES契約は業務委託契約であって派遣契約ではないが実態は労働者派遣の形態を取っていることがあり法的に問題視されがち」という話があったりもします。闇が深い。

なぜSIerによるソフトウェア開発だけが多重下請けを生むか？

ここまでで、短期間のみ大量の人員を揃える必要がある大規模システム開発プロジェクトにとっては多重下請け構造にも一定の合理性があることがわかりました。一方で、Googleで「多重下請け問題」などと検索すればすぐにわかるように、多重下請け構造が一因となって発生している問題は様々あります。たとえばシステムの品質や開発者個人のキャリアに関する問題です。

ここで重要なのは、ソフトウェア開発を行う全ての企業で多重下請け構造が問題となっているわけではないということです。たとえばGoogleやAmazonなどに代表される米国のBig Techや日本のメガベンチャーなどでも十分に「大規模」といえるソフトウェア開発をしていますが、多重下請け構造が問題になっているという話はあまり聞いたことがありません。また、僕が今いるSaaS業界でもSIerが得意とする「業務システム」開発に近いことをしていますが、基本的には自社エンジニアのみで開発をしているケースが多いです。

なぜソフトウェア開発を担う企業の中でもSIerだけが多重下請け構造などという不自然な形態を取っているのでしょうか？

さて、下の図はSaaSスタートアップによる自社プロダクト開発とSIerが受注したクライアント企業向けシステム受託開発とを比較したイメージ図です。横軸はプロジェクト開始からの経過月数を、縦軸はその月に稼働したエンジニアの人数を表しています。

両者ともプロジェクト開始後3ヶ月でシステムをリリースしており、全10ヶ月で投じた工数の量は同じです。しかし、その配分は大きく異なっています。

SaaS内製開発では少ないメンバーでリリースまでの開発をしてから、徐々にエンジニアの数を増やしています。ここまで採用ペースが緩やかであれば、エンジニア採用市場から然るべき採用選考フローを踏んで、しっかり見極めをした上で優秀なメンバーを選んで採用することができます。また、必要なエンジニアの数がガクッと落ちるということも無いので、正社員で採用しても人員が余ってしまうということがありません。SaaSに限らず、自社内製開発をしている昨今のソフトウェア企業でも同様のやり方を取るケースが多いでしょう。

他方、SIerによる開発プロジェクトの方はより極端な配分になっています。プロジェクト開始時から大量の人員が必要なので様々な会社から人を一気にかき集める必要があります。また、リリース後はエンジニアの必要数がガクッと落ちるため全ての人員を正社員で抱えることも難しく、人数合わせの雑な採用になりがちです。こうした人材調達のニーズに、多重下請け構造がマッチしたというわけです。

この「最初にガッと作ってリリースしたら解散する」というSIer的なプロジェクト管理のやり方が、多重下請け構造につながっていると言えます。

ちなみに、もっと話を広げればSIのビジネスモデルでは開発業務における生産性向上やシステムの品質向上に対するインセンティブが働きにくいといった事情が多重下請け構造から脱却できない理由につながっていたりします。また、長期目線で人材の育成ができないので、プロジェクトメンバーのスキルが上がりにくいという問題もあります。これらも重要な論点ですが、長くなるのでまたの機会に譲ります。

一気に大きくリリースするか、徐々に小さくリリースするか

上記の図で見たようなペース配分の違いが生まれるのは、そもそものソフトウェア開発に対する考え方に違いがあるからです。

SIerによる一般的な大規模システム開発プロジェクトでは、ソフトウェアのことをビルなどの建築物と同じように捉えています。ビルを建てるとき、普通はビルが完成する前にリソース投下量が最大になります。建てた後のメンテナンスも多少は必要でしょうが、建てる最中に比べれば必要な人員はきっと数十〜数百分の一で済むはずです。もしソフトウェア開発でも事情が同じであれば、まさに「ITゼネコン」と呼ばれるような建設業界のやり方を模した多重下請け構造にも妥当性があります。

一方、ビルの建設とは違ってソフトウェア開発プロジェクトでは「何をどのように作ればいいのか」の正解が最初からわかることはほとんどありません。むしろ重要なのは初期バージョンをリリースした後であり、実際の使われ方や環境の変化に応じて常にソフトウェアを作り変えるのが重要になります。別の視点で見ればソフトウェアはまさに「ソフト」なものであり、ビルとは違って後からでも柔軟に仕様や構造を変更することができます。ソフトウェアの強みを最大限に活かすなら、一気に大きくリリースするよりも、最初にプロトタイプやMVP（Minimum Viable Product）を開発した上でそれを徐々に良くしていくようなアプローチの方が有利になることが多いです。

ちなみに、こうした考え方の違いはソフトウェア開発界隈では「ウォーターフォール型開発 v.s. アジャイル型開発」という対立で表現されることが多いです。アジャイル開発について調べてみると、多重下請け構造を生み出したソフトウェア開発との違いがよくわかります。

もちろん、これまで続けてきたSIer的なシステム開発のやり方をいきなりガラッと変えることは難しいでしょう。特にSIerのビジネスモデルは受託開発であり、クライアントの考え方が変わらないと仕事の進め方を変えにくいという事情もあります。しかし、システム開発にまつわる多くの問題を解決するために長期的に進むべきは、「玉石混交の人員をかき集めてガッと一気に作ってリリースしたら解散する」ような道ではなく、長期目線で継続性のある良いチームが少しずつソフトウェアを作り変えていくようなアプローチであると信じています。