多重下請けは製造業にも存在するし，ユーザーや元請けの側に交渉力があって下請けの負担が重いことは，日本のどこでも同じである。しかし，自動車部品などでは系列・下請け関係の中で製品のQCDと産業競争力が向上し，また1次サプライヤーが設計開発能力，さらには研究開発能力を磨いてきたことも事実である。IT業界は今後の産業構造変化をリードする立場なのに，QCDの面で下請けの負の側面ばかり目に付く。どうしてこうなるのか。学部の講義で系列・下請けの構造と変容を扱っているが，それは主に自動車部品を対象としており，いわば機能している下請けの話である。それと対比する意味で覚書にしておきたい。
ひとつはユーザー側のIT部門が弱い。記事にもある通り，ユーザーの側で投入労働量が平準化できないことと終身雇用慣行の矛盾があって，人数をぎりぎりに絞っている。さらに社内および役所内でのIT部門の立場が弱く，ビジネスプロセス全体をITを使って変革する主導権を持たされていないし（国立大学大学で言うとハンコを失くす業務改革権限を持たされていないとか！），最悪，ビジネスプロセスがわからないのに要件定義をして発注する。その発注が開発コンペになっているのかどうかがよくわからない。役所では競争入札をして価格で決定しているのではないか。
ここで元請けたる1次ベンダーがしっかりしていればいいのだろうが，1次ベンダーも人数をぎりぎりに絞っているために外注することになる。以下同じ。つまり，外注を「専門家に頼む」のではなく「投入工数の調整」を主要因として行っている。なので，本来ワンチームで行った方が効率的かもしれないところまで分割して外注し，ウォーターフロー式で開発する。そして，仕事があれば出し，なくなれば切るので，金の切れ目が縁の切れ目になりやすい。
ウォーターフロー式とは開発の流れ作業であるから，仕様が確定していて不確実性がない場合は機能する。ところが，仕様変更，設計変更が頻繁に生じる。そこには，アプリの世界はもともと開発しながら新しいことを考え，使用も設計を変更していった方がよいものができるという積極的要因と，ユーザーの力がなくて要件定義のところが詰められていないという消極的要因がある。後者もあるとはいえ，アジャイル方式とオープンソースならば開発者の創意工夫によって提案され，開発プロセスにすぐ反映される。しかし，ウォーターフォール式かつ多重下請けなので，二つの欠点が起こる。一つは修正に時間と手間ばかりかかること。もう一つは，元請けから下請けへの一方的押し付けを通して変更が実行されることだ。コストは下請け持ちである。
ユーザーと1次ベンダーの開発能力が量・質ともに低いということは，ユーザーとつきあい，1次ベンダーと付き合っても働かされるだけで勉強にならないということである。そしてアプリの世界ではユーザーと直接接していないとよいものがつくれない。なので，下請けシステムには学習機能がうまく働かない。
それでもユーザーが1次ベンダーに発注して多重下請けに頼るのは，開発者が名目上は大手でないと不安だとユーザーが判断するからだ（『日経』の方の記事参照）。1次ベンダーは大手企業であり，トラブルに対する耐久力が強い。だから受注できる。仕事の質ではなく，規模によって受注できてしまうのだ。
シェア先
中島聡「なぜ、日本政府が作るソフトウェアは使えないモノばかりなのか？」MAG2NEWS，2020年6月3日。
https://www.mag2.com/p/news/453485
「コロナ接触確認アプリ、導入1カ月遅れの曲折」『日本経済新聞』2020年6月1日。
https://www.nikkei.com/article/DGXMZO59771810Z20C20A5TJC000/
