受託開発を行う場合、大抵は、最終顧客と呼ばれる「顧客」と、 SIerと呼ばれる「発注元」と実際にプログラミングを行う「下請け会社」に分かれることが多い。 下請け会社は、「協力会社」と呼ばれることが常なのだが、ここでは「下請け」ということにしておく。 何故か？は、この記事を読めばわかる、と思う。
　たとえば、顧客が何か社内システムを作ろう、と思い立ったとしよう。SIer＝発注元に営業を受け、 「こんなシステムを作りませんか？」という形で製品の売り込み、そして製品のカスタマイズ、という パターンもあるが、製品カスタマイズの場合は、SIer とその子会社で閉じてしまう「製品開発」に あたるので、もう少し広いパイを狙って「受託開発」というパターンを考えてみる。
　そういったばあい、顧客はSIerに社内の状況を説明する。SIerはITコンサルタント的な役割で 顧客の既存の業務を理解し、業務フローを描き、どの業務をIT化するのかを検討するのである。 もっとも、多くは「どの業務をIT化するか？」の検討は成されずに、「まるごとIT化」してしまうことが 多いので、SIer の提案は大規模システムになってしまうことが多い。
　例えば、「まるごとIT化」してしまった場合、基本ベースは SIer の持つ製品を組み込む場合も あるだろうが、全体的には規模も大きいし「一品物」でもあるので、大量のプログラマを集めて シコシコてプログラミングしていく必要がある。この場合、SIer が抱える「単価の高い SE」よりも 「単価の安いプログラマ」を雇い入れることで、差額を SIer が儲ける仕組みになっている。
　SIer の社員は基本的に給料が高いので「単価が高い」。そういう場合は、「単価の安い」下請けの ソフトウェア会社からプログラマを調達する。これが「下請け」の存在意義である。
　ここでは、基本的な概念として、

• 「顧客」＝「お金を出す人」、「システムを使う人」、「システムは作れない人」
• 「SIer（発注元）」＝「お金を貰う人」、「システムを想像（創造）する人」
• 「下請け」＝「お金を貰う人」、「システムを作る人」

というヒエラルキーがある。資本社会である以上「お金」のやり取りが主体になるので、
「顧客」＞「SIer（発注元）」＞「下請け」
の順番に力関係が成り立つのである。

　さて、お金は「顧客」から「下請け」へと流れる。中間に「SIer（発注元）」が噛んでいるのは、 流通業の問屋に近いものがある。勿論、問屋は「中間搾取＝リベート」を取っているだけではないが、 貿易会社のように大量投資とモノを右から左へ流すことによって、企業が成り立っていると いっても過言ではあるまい。通常、SIer が持つ「企画力」を下請けが持たないために、SIer の 存在意義がある、と言われているが、「企画力」＝「営業力」ということを考えると、最近の 流行である「モノづくり」とは随分離れた能力であることが想像できるだろう。 高校生の株投資入門に近いものがある。
　「顧客」は基本的に「システムを作る能力」はない。あるいのは、かの会社を世の中に売り出す 能力である。販売力だったり製造力だったりするわけだが、たとえばトヨタとかホンダのような会社では、 「製品を作って売る」ことを主体としている。製品を作る工場を持ち、製品を売る販売力を持っている。 そのどちらが欠けても会社としては成り立たない。
　このような顧客が、不得手とするITシステム（社内システム）を組もうとしたときは、かの会社の 能力は直接には役に立たない。自分たちの業務を改善しようといろいろとアイデアが出てくるだろうが、 実際にシステムの要求が満たせるようなシステムを構築できない。構築できたとしても、専門のIT企業に 及ばないのが常だ。それこそがIT企業の存在理由なのだから。
　対して、「下請け」会社はソフトウェアを作る能力を持つ。これは、顧客が製品を作る能力があると 同じように、下請け会社はソフトウェアとい「製品」を作る能力がある、ということだ。 もちろん、「製品」とはいえ、一般的に売り出されるようなパッケージ製品でもなく、特定のシステムを 形作るような製品ではないかもしれないが、町工場で一品モノを作るような職人的な技術を「下請け」会社は 持っているのである。
　しかし、それらの製品を最終的な「顧客」に売れるわけではない。例えば、車の部品を下町の工場が 請け負っている場合、部品＝工場の製品ではあるけれど、車のオーナーに対して直接売り込むわけではない。 一旦、車会社が部品を買い取り、新たに製品を形作り、最終的な顧客へ販売していくのである。 そういう形で見ると、ソフトウェア会社＝下請けは、SIer＝発注元に対して、一旦、製品を納品してい、 SIer が新しく製品を組み立て最終顧客に売り込んでいる、という図式を想像するかもしれないが、 分かっての通り、ソフトウェアの製品は「コンポーネント」に分かれていない限り、そういうことはできない。 下請けの作成した「製品」は、そのまま「顧客」の目に触れることになるのである。
　というと、中間層にあたる SIer は何をしているのか？という疑問が働いてくる。 実は SIer は、大企業という名＝ブランドをバックにして、顧客に営業を行い、 下請けに発注をする、下請けが作った製品を顧客に横流しにする、という 問屋的な役割＝流通企業に近い能力が求められるのである。大抵の SIer は製品を持つ。 しかし、製品以外の分野では、営業力＝販売能力に優れている、といっても過言ではないだろう。

　実は、SIer は大企業な故にブランド力を持つのだが、社会的な影響力も強い。 だから、みずほ銀行の例のように、プロジェクトが失敗すると、新聞沙汰になり SIer の名前が 出てしまう。ただし、SIer にとって販売経路は確立していることが多いので、販売力に対しての 影響は小さいのだが、株価に影響してくる。株価は「期待感」に支えられているので、株価を下げない ためには、新聞沙汰のようなメディアに失敗を報じられないように策するのが有効である。
　そこで、SIer の仕事は、顧客に対して「納期遅延をしない」という目的を達そうと頑張る。 もちろん、納入後の品質が悪ければ「顧客」からクレームを負いかねないのだが、何故か リリース時期が第一になってくる。
　例えば、顧客が更なる顧客＝一般客になんらかのサービスをしようと考える。たとえば、 コンビニエンスストアで、Ｘシステムを導入して一般客にサービスをする、というアイデアを 出したとする。顧客は、SIer にＸシステムを構築してくれるように発注する。Ｘシステムは、 顧客自体の競争力をアップする必要もあり、新聞やプレスリリース、雑誌などのメディアを通して、 発表を行うわけだ。新製品発売とか、この秋の新サービス、というのがこれにあたる。
　プレスリリースをしてしまうと、「納期」は死守するべきものとなる。何故ならば、 「納期」をずらすということは、顧客のプレスリリースに影響を与えるということになるためで、 顧客の顔を潰す＝顧客の顧客に対して影響を与える、というひどく影響の広い範囲を 想定してしまう。このために、SIer＝発注元は、下請け会社の尻を叩き「納期遅延」のないように 監視する。本当は、トラブルが起こったときのほうが問題だ、ということは誰でも分かっている （のだろう）が、「納期」が優先していしまうのはこのためだ。デマルコ氏の言う「計測できるものが 第一に優先される」ということで、「測れるもの」＝「スケジュール」に対して、第一優先権が 与えられてしまう。
　こうなることによって、SIer＝発注元は、トラブルを起こさないという品質に対して 非常に鈍感になる。さらに、プログラム自体は「下請け」に発注してしまっているので、 プログラムそのものの品質を測ることが出来にくくなる。計測できるものは、

• ステップ数
• レビュー回数
• バグ数
• スケジュール遅延

程度の間接的なもので、「プログラムそのものが仕様を満たしているか？」あるいは 「プログラムの能力が運用に耐えられるものか？」という本質的な品質に対しては、 無知になってしまうことが多い。そもそもが、先の理由により、プログラミングという能力に対して、 SIer は下請け会社よりも劣ってしまうことが多いので、「国民の能力以上の政治家は生まれない」の 喩えの通り、SIer の能力よりも上のソフトウェアは生まれはしない。
　なので、SIer は「プロジェクト管理」に精を出す。あるいは「上流工程」に精を出すのである。 お金ヒエラルキーから「SIer（発注元）」＞「下請け会社」という関係から抜け出せないので、 SIer＝上流工程、下請け＝下流工程、というヒエラルキーになることが多い。SIer にとっては、 プログラミング能力は「卒業」すべきもので、管理能力やアーキテクトのような抽象的な能力、 顧客へのコンサルタント能力を重視する傾向にある。 このために、上流／下流という工程分けがあり、この工程にフィードバックがないことが多い。
　SIer 単独で作成する「製品」では、フィードバックのある工程になっているのだろうが、 下請けに出すと何故かフィードバックを持たない工程になる。 つまりは、管理のし易い「ウォーターフォール」を好み、その管理が SIer の仕事と勘違いしてしまう。

　一般的にプログラマの単価は低い。SIer 自身が持つシニア SE よりも、プログラマの単価は ３分の１にしかならないことがある。生活費の安い中国ならいざ知らず、同じ日本に住んでいるのだから、 単価が３分の１というのは、イコール貧富の差？と思う諸氏もいる（かも？）しれないが、 まあ、そのあたりは何らか操作が合って、それほど低くはなっていない。 しかし、下請け、孫請けと、ソフトウェア業界も零細会社が多いので階層化しているので、 下請けになればなるほどマージンを取られているのは確かなことだ。
　これがイコール「プログラマの価値」である。
　最近は「上級プログラマ」という形で、管理者ではないキャリアが求められているのも、 基本的にプログラマが底辺である、という意識があるから、と言えよう。
　いわば町工場の職人を考えてみると分かる。若いうちは旋盤工として、正しい製品を作ることに 日々を費やしていくわけだが、能力がある段階に達すると、旋盤の新しい使い方を覚える。 新しい使い方により新しい製品にタッチできる。製品の精度があがる。創造性を埋め込める。 製品を作るスピードがアップする。など年を経るごとに旋盤工として「職人」力がアップしていく わけである。
　勿論、弟子を持てば教える能力、グループをまとめる能力、顧客と交渉する能力、販売する能力、 営業する能力、など経験を生かしながら生活力を付けていくことにあなる。
　基本的に日本経済＝資本経済は成長企業体なので、会社を大きくしていくことが第一目標になる。 このときに、「プログラマの価値」は、単純にプログラムが書ける、という程度のものではない。 町工場の職人と同様に、教える、グループで活動する、創造性を勝ち得る、精度を上げる、などの プログラム＝製品以外の分野をアップしていくことが求められる。
　これが今までは「管理職」というひとつの道しかなかったのだが、最近は「上級プログラマ」という 専門力（ネットワーク、アーキテクト、データベーススペシャリストなど）を発揮できるようになって いるのだが、ここに大きな壁がある。「SIer（発注元）」と「下請け会社」という壁は、 下請け会社に優秀なプログラマがいることを許さない構造になっている。 「発注する」つまり「仕様」を発注する場合に、要件定義を行う仕事は SIer にあり、普通は下請け会社にはない。 プログラムの品質を確認するのは建前的に SIer であり、下請けは保障できない（尤も、SIer 自体に品質を チェックする能力を持たないので、下請けが品質を保持するしかない）。
　このような壁のために、下請けのプログラマは、SIer＝発注元の SE に立場的に太刀打ちできない。 つまりは、発注元の SE の能力にプロジェクト全体の能力が抑え込まれてしまうわけである。

　打開策はあるのか？と問われれば、現状の構造では「無い」と答えるしかない。
　下請け会社で辛くなってしまったプログラマはキャリア＆給料を求めて、SIer に転職するだろうし、 顧客はシステム能力の低い SIer に悩まされ続けるだろう。下請け会社では、小さなサイクルで、 プログラマ→管理職（マネージャ）を繰り返すのみで、脱却できない。できるとすれば、 下請け会社自身が SIer と変身して、下請け会社を使う、という泥沼構造に陥るだけである。
　現場が疲弊するので、能力向上のためのフィードバックはない。国内競争ではそれでもいいかも しれないが、国際競争力は落ちる一方である。下請け会社を単価の安い中国やインドに求めたとしても、 SIer 自身のシステム化能力が低ければ、国内の下請け会社に「丸投げ」をしているのと変わりない。 国内需要を減らしてしまう分だけ状況は悪くなると言ってもいい。
　しかし、私的に言えば、こういった構造を変えることによって、打開ができると思う。
　SIer は、本来の仕事である「下請け会社の取りまとめ」を行う。つまり、ブランド力や企業力を生かした 貿易産業のように、

• 顧客のニーズを把握する
• 製品の品質を確保する
• 製品の納期を調節する

という具合に、要求定義、アーキテクト、上級プログラマというような「単価の高い」職種を廃してしまい、 企画力とバックグラウンドに徹するのである。製品は確保するのだろうから、プログラミング能力は保持できる だろうが、下請け会社のプロのプログラマほどではない。なので、上流工程も下請け会社と協力して 行う。そのために下請け会社も上流工程の能力が必要になる。

• システムの全体を把握し抽象化する能力
• UML/XMLなどのオブジェクト指向／標準言語の能力
• 最終顧客をシステム化する創造力

これにプログラミング能力（いわゆる製品を作る能力）を加えて、一人前のプログラマとして 成り立つと思われる。一般的に、「職人気質」というものは、プログラミングのみの能力に長けている という形で、フリープログラマ的な見方をされることが多いが、本来「職人」に必要なのは 「弟子」であり弟子を育てる能力である、伝播する能力なので、閉じたプログラミング能力では 半人前としか言えない。
　受託開発型のプロジェクトが危ういのは、この部分がきちんと押さえられていないためだろう。