建設業界やSI業界で多重下請け構造に伴う弊害がよく議論されています。何層にも下請けに発注していくうちに各階層で中抜きがされて、顧客が一次請けの業者に支払ったお金のごくごく一部しか実際に働く社員に支払われていないのではないかという議論です。
そんな中、Twitter（今はX?）を見ているとこちらのツイートが人気になっていました。噂されている多重下請けの一般的なイメージと実態は大きく異なることを判りやすく図示したものです。
この右の絵、実態をよく現していると思います。SI業界では単なる丸投げ、中間搾取などできるはずもなく、出来上がってくる製品の製造における進捗状況や品質状況を常に確認しながら、状況に応じて対策を講じていかなければなりません。
システムインテグレーションの実態
もし、SI業界がマニュアル化された世界でマニュアルに従って作業をすれば質の良いプログラムが大量生産できる状態まで成熟していれば、こんな苦労をすることもありません。しかし、実態は仕様書が曖昧だったり、ミドルソフトの予期せぬ動作（バグ）に悩まされたり、必要な性能が出なかったり、顧客からの仕様変更要求に振り回されたり、まるで積み木を積み上げている最中に下の積み木を抜いたり加えたりして、全体のバランスを整え直すようなことが常に繰り返されています。
フロントエンドの開発は仕様変更を是として、小規模精鋭のチームで短期開発を繰り返しながら前に突き進んでいく方法もありますが、何千人月、何万人月もの工数が必要な基幹系システムの大きな更改などでは、アジャイル開発が向かない部位（ウォーターフォール開発）が大多数になります。
最も工数がかかる製造工程の改善
多重下請構造を無くすためには、第一歩として要件定義からサービス開始の一連の工程の中で、最も工数が多くかかる製造工程の自動化•省力化（ノーコード、ローコード）が必要だと以前から言われています。IT業界では一連の技術開発が進んでいますが、まだデファクトスタンダードとなるような決め手には欠けている状況なので、更なる技術開発が必要です。
段階開発化
製造工程のピークがおさえられたとしても、大規模な開発で設計工程や試験工程を自社要員および一次請けの会社だけで対応するのは困難なことが大多数です。
この場合、システムを複数の部位に分割して、複数社に分割発注する方法が頭に浮かびますが、そのためには発注者側に複数会社のプロジェクトマネジメントをする技術が必要になります。公共調達の場合は、顧客側でリスク費（予備費）を持つことが難しいので、調達の仕組みの見直しも必要です。
一気にとても大きな開発を進めるのでは無く、段階化して、発注者側も受託者側も無理な体制をしく必要がないプランにするべきです。
例えば、ハードの寿命に伴いハード更改をするときに、ついでに多くの機能改善や機能追加をしたくなることがありますが、第一段階目はハード更改のみ、第二段階で機能追加と段取りを組んで進めた方がプロジェクトの成功確率は上がります。
発注者側責任の明確化
一方で発注者側についても、「アーキテクチャを最新の技術に置き換えてもらって、構造をシンプルにして、機能は現行と同等に動作してくれれば良いから」といった曖昧なオーダーを無くさなければいけません。
特に機能については、現行踏襲という一言では無く、要件定義から設計内容までを顧客側でもレビューを通して保証しなければなりません。実態は顧客側で十分な体制を取ることができず、十分なレビューや仕様の決定ができず、結合試験あたりで問題が噴出して前に進めなくなってしまったプロジェクトをよく見ます。
多重下請の解決に向けて
「多重下請は良くない、だからやめよう」という単純な問題として片付けずに、SI業界自体としても、また発注者としても、全体で解決の道を探る必要がある課題です。
コメント