受託開発とは、ITベンダーが顧客である企業からソフトウェア開発の依頼を受け、事前に決められた仕様、費用、納期通りにソフトウェアを納品することです。
受託開発の受注金額は、数百万～数億円にも上ります。一方で、参入障壁となるものはありません。人さえいれば、ビジネスを始められます。
■受託開発のビジネスモデル
受託開発は、「利ザヤ」ビジネスです。受注金額よりも低い金額で仕事をしてくれるITベンダーを探し、発注を横流しすれば、その差額を利益として受け取ることができます。いわゆる、元請けから下請けへ再発注をする中抜きと言われるものです。その利ザヤが取得できる間は、再発注が繰り返されることができます。結果、最終的に手を動かすITベンダーに渡る金額は、大きく減額されてしまいます。
このビジネスモデルは、物流のサプライチェーンのように、ITベンダーのポジションを固定化させてしまいます。下請けは、ずっと下請けのままということです。少なくとも、黙っていても仕事が流れてくるので、積極的には、下請けのITベンダーもいまのポジションを変えようとは考えません。
このようなIT業界の生態系は、Unix/Linux、Windowsなどの汎用OSが普及した1990年代に確立しました。いまでは、個人事業のフリーランスも増え、下請け分業構造の裾野が大きく広がっています。
■元請けがやる仕事
元請けのITベンダーがやっている仕事は、「プロジェクトマネジメント」という名のもので行われる管理業務です。管理対象は、下請けのITベンダーであり、管理すべき項目は、QCDと呼ばれる以下の３つです。
１）品質（Quality）
作業の区切りである工程毎に成果物のレビューを実施します。成果物とは、設計資料とテスト結果です。
レビューに本当に意味があるのは、少なくとも、レビューをする側とレビューをされる側の両者のスキルが均衡していることです。しかし、通常、元請けとITベンダーとのスキルにはギャップがあり過ぎて、深く踏み込んだ指摘は不可能です。そうなると、何の指摘もなく、ただ淡々と資料をめくるだけで終わるか、重箱の隅をつつくような表面的で些細な指摘だけが繰り出されるかのいずれかになります。
２）費用（Cost）
費用とは、以下の式で表される工数で管理されます。工数とは、人日あるいは人月という単位で表され、ITエンジニアの労働量のことです。
工数 ＝ 期間 × 人数
たとえば、一人日というのは、一人のITエンジニアが一日働いたときの労働量です。（一日何時間働くかは、ITベンダー毎に異なります。通常、一日８時間労働として考えますが、残業込みで、一日９時間や１０時間労働として勘案するITベンダーもいます）
工数をコスト（費用）に変換するには、工数にITベンダー毎の人月単価をかければいいだけです。
コスト（費用） ＝ 工数（人月） × 人月単価
ITエンジニアが働けば、その分、時間を消費することになります。この消費状況をソフトウェア開発が完成するまで、細かく神経質に確認していきます。
工数は、ソフトウェア開発にとって、特に使える費用が最初から決まっている受託開発にとって、”命の水”です。工数が尽きると、作業が停止します。その前に、完成させなければなりません。
そのため、下請けのITベンダーへの圧力も大きく、たとえば、本来は有償の仕様変更で処理すべきことを、無償のバグとして処理させるように仕向けることもあります。
３）納期（Delivery）
最終的な納期を守るには、開発途中の遅延の発生をつぶしていくことが必要です。ソフトウェア開発は、「はじまった瞬間から遅延が始まる」と言われるほど、「遅延」に悩まされ続けることになります。
特に、受託開発では、納期は絶対であり、延期されることはあり得ません。それは、ビジネスとして契約で決められたことだからです。
そのため、一日だけの遅延だとしても、見過ごすことはできません。遅延をつぶすため、ITベンダーへの遅延解消のための対策を即座に実施することを指示します。これを、繰り返し、繰り返し実施することで、納期を確保していきます。
この他に、元請けが実施していることは、「顧客対応」です。顧客からの質疑、依頼などに対応していきます。ただし、その役割は、仲介役として、それらをITベンダへ投げて結果をもらい、返答することが主となります。
■下請けがやる仕事
下請けは、ITエンジニアという文字通りITリソースを所有する「人材プール」の役割を担っています。必要なスキルを持った人材を、必要な時に、必要な人数だけ提供します。ただし、提供できる時期は、人材の作業状況によります。そのため、元請けが策定するスケジュールは、下請けからの人材調達時期に依存します。
下請けが実施する作業は、ソフトウェア開発の実務です。ソフトウェアの仕様策定、設計、プログラミング、テストまで、スキルが必要となるほぼすべての作業を請け負います。したがって、技術的なノウハウはすべて、下請けのITベンダーにいるITエンジニアに蓄積されることになります。
これは、同じ顧客からの仕事をこなすためには、元請けは、同じ下請けに頼らざるを得ないという強固な取引関係をつくることができます。そうなると、下請けは、営業する必要はなく、元請けから仕事の依頼を待てばいいということになります。
元請けは、下請けにとって、営業部隊と見なすことができます。顧客対応という面倒な仕事をせずとも、技術的な仕事に集中できる環境に居続けることができるのです。
■受託開発の手法「ウォータフォール開発」
受託開発は、費用と納期が契約として決められます。途中で変更されることはありません。したがって、開発手法もどんな案件であっても同じ手順で行えて、管理しやすいものである必要があります。それに最もマッチしたものが「ウォータフォール開発」です。
ウォータフォール開発は、水が流れ落ちるように、仕様策定、設計、製造、テストの順に上流工程から下流工程へと作業を一方通行で進める開発方法です。工程が下流にいくほど、必要なITエンジニアも増えていきます。手戻りがなく、実施すべき工程が最初から決まっています。
元請けが主導するウォーターフォール開発は、やるべき作業と管理すべき項目が異常なほどきめ細やかに決められています。いわゆるマイクロマネジメントが実施できるように、社内の開発標準としてマニュアル化されています。スキルや知識などなくとも誰でも実施できるといっても過言ではありません。
「だれが・何を・いつまでに」「どれくらいの量を・いくらで」やれるのかえわかれば、プロジェクトを支配できる仕組みに仕立て上げられ、完成され尽くされれいると言っていいでしょう。
■受託開発ビジネスの暗黒面
ソフトウェア開発の成功率は、30％程度と言われます。決して、リスクが低い仕事とは言えません。したがって、受託開発もリスクの高いビジネスと言えます。
リスクの高いビジネスには、問題がつきものです。受託開発ビジネスにも以下のような問題があります。
１）丸投げ横行
長年、ITは、ビジネスにおいて主役ではなく、ビジネスをやる上で仕方なく必要とされるモノと認識されてきました。少なくとも、日本ではそうです。
そのため、顧客側は、積極的にITを学び、自社の業務を革新するための人材を育てることはしません。
顧客にとって、ITは、”ITベンダーにおまかせ”、「丸投げ」が前提となります。ソフトウェアなんて、「ある程度の金さえ出せばすぐにできる」と思い込んでいるため、費用と納期は、実際とは大きくかけ離れています。
元請けは、どうにか顧客に対して費用については合意を得られても、納期については譲らない顧客が多く、理不尽な短い納期が決められてしまうことも多くあります。このような場合、元請けは、金額が満たされるのであればビジネスとしては成立するので、仕方なく受注することになります。
このしわ寄せは、下請けにきます。下請けの負荷を上げ、ITエンジニアの長時間労働という「頑張り」で補うことが日常となっています。
２）隷属化するITエンジニア
このような状況において、元請けだけでなく、下請けのITエンジニアは、QCDに隷属化します。QCDを確保するため、幾度も理不尽な要求が繰り返され、反論することも許されず、心身に鞭を打ちながら無心で目の前の受託開発に没入していかざるを得ない環境に置かれます。
受託開発で生きるITエンジニアにとって、考えることよりも決まった作業をミスなく、効率的に進めることが優先されます。ITエンジニアは、ある特定の作業者として秀でることになりますが、どんどん「考える力＝創造力」が失われていきます。これが長く続くと、下請け根性が染みつき、いまの状況から抜け出すスキルも気力も削られていきます。
さらに、ITエンジニアを不幸にするのは「人月単価」です。
人月を分解すると、「時給」となります。牛丼チェーンも時給ですが、経営者は、決められた時間内でできるだけ仕事を詰め込もうと考えるのが当然です。同じように、下請けのITエンジニアも、仕事が否応なしに詰め込まれます。
仕事は、できる人に仕事は集中します。スキルが高いITエンジニアほど、仕事量が増えますが、人月単価が決まっている以上、報酬が増えることはありません。
つまり、「やった者負け」の悪循環に陥っています。こうなると、スキルアップやキャリアアップのモチベーションが湧くどころが、次第にそがれていきます。
このような状況にあっても、転職などの流動化が進まないのは、「他のITベンダーに転職しても状況は同じ」であることを認識しているからです。それならば、過去のスキルが使える今の会社のほうがマシだと考え、現状に甘んじることになります。
３）元請けの空洞化とソフトウェア資産の搾取
元請けにいるITエンジニアには、技術的なスキルが蓄積されることはなく、下請けのITエンジニアがいないと、ソフトウェア開発の実務ができません。
些細な作業をするにしても、下請けを頼ります。顧客対応にしても、技術的な質疑は、下請けに流すだけです。
ただ、受託開発において、ソフトウェアの資産は、元請けがもっています。下請けが作成する仕様書、設計書、テスト仕様などのドキュメント、ソースコードなどの著作権は、契約によって、元請けに譲渡されることになります。元請けは、実務もできず、ノウハウもないにも関わらずモノを保有することになります。
一方で、下請けは、一切のソフトウェア資産が蓄積できないまま、ただひたすら労働し、その対価を受け取るだけの「日銭稼ぎ」に明け暮れます。これが、受託開発ビジネスが「労働集約型」と言われる所以であり、ITエンジニアを「ソフトウェア労働者」と呼ぶ理由です。
これは、受託開発の大きな矛盾と言えます。
