（1999-8-7 一部訂正）
２０年間で得たものは
ソフト業界に「派遣」という形が入って、約２０年が経ちます。それまでは、客先で作業をすることはあっても、個別の案件ごとに契約が行われていました。ソフトウェアの開発案件が増え、ソフト技術者の確保という問題もあって、「派遣」という形態が認められたのですが、あれから２０年たって、ソフトハウス（ソフト会社）は何を得たのでしょうか。
派遣が、単なる「人手」の調達に使われて来なかっただろうか。設計は客先のＳＥが担当し、派遣のエンジニア（？）はその実装だけを受け持つ、という形になっているのをしばしば見かけます。それでも、「そこ」に仕事があることから、ソフトハウスは「そこ」に甘んじて来はしなかっただろうか。「そこ」なら、高い技術力は必要とされないため、ソフトハウスとしても、投資コストを掛けないですぐに売り上げに貢献してもらえる。その後は、毎月確実に「派遣料」が上がってきます。とにかく、どこかに「はめ込めば」売上につながる。そんな甘えはなかっただろうか。
受け入れる側も、ソフトハウスから派遣されるエンジニアに、最初から高い技術を期待していない。いや、そういうものだと思い込まされてきたのかもしれない。社員として抱えることで固定費になってしまうのを避けることに重きが置かれてきたのではないだろうか。結局、お互いに「低いレベル」で安定してしまったのではないか。単に、コストに合わない作業を外部に出しただけではないだろうか。
採算性の悪化？
だが、２０年という時間は、状況を変えるのには十分です。たとえば、ソフトハウスの従業員の平均年齢が上がっているのではないだろうか。技術が勝負のソフトハウスとはいっても、その内実は、年功賃金が前提となっているところが少なくありません。派遣先からは「年功」などは考慮されることはないため、コスト体質が悪くなっているものと思われます。その「部分」を実装してくれる人であれば良いのですから、それが若い人であろうと、年配の人であろうと、支払う料金は同じです。それに、そこで求められているレベルでは、どのような人を回すかは、ソフトハウスの都合であって、発注元の要求ではないわけですから。
もちろん、特別なスキルが必要な案件であれば、それにかなう人を指定することになりますので、それなりの料金がかかります。でも、そのような特別な要求が無いかぎり、料金は上がりません。それでなければ、ソフトハウスに委託する意味はありません。でも、その分、ソフトハウスの経営は厳しくなるはずです。
そこで考えつくのが、部分のための「派遣」から全体の「請け負い」へのシフトです。いつまでも「人工」で請け負っていては給料が払えないため、まとめて請け負う方向に動こうとしています。まとめて請け負うことで、金額もまとまったものになります。それをどのようにして対応するかは、ソフトハウスの「自由」です。要は、要求を満たせばいいわけですから、社内で、うまくやりくりすれば、採算性は上がることが期待できます。もちろん、それには条件があります。それでも、今まで「派遣」でやって来た分野であったり製品であるということで、簡単にできると思われているようです。
部分を集めても全体にはならない
言い換えれば、単に部分を請け負うのではなく、付加価値を付けようというわけです。この考え方は正しいし、時代の方向とも合っています。問題は、部分を請け負うことと全体を請け負うことの「差」です。
確かに、何年かそのシステムに携わったことで、どのコンポーネント（タスクと言い換えてもよい）でどのような機能がカバーされているか、そのコンポーネントと交信するコンポーネントはどれか、この機能の一部を変更するには、どのコンポーネントを修正すればいいのか、といったことは分かっているでしょう。もし、そのシステムのほとんどのコンポーネント、あるいは主要なコンポーネントを、そのソフトハウスの人たちが受け持ってきたとしたら、今度は、システム全体を請け負えると考えるのは無理もありません。いや、これまでのように「保守開発」であるのならまるごと対応できるかもしれません。でも。システムのアーキテクチャを再構成するとなると、そうはいきません。
ところが、ＣＰＵを取り換えたり、ＲＴＯＳを導入したり、これまでのパフォーマンスを飛躍的に向上させるためにアーキテクチャを再構成する必要があるというときに限って、それまで出入りしていたソフトハウスに「丸ごと」委託することがあります。一般に発注側にも、再構築の自信があるわけではありません。だから、ついそのような機会に「全体」を委託したくなるのでしょう。ソフトハウスの方も、チャンスなわけです。それに、これまでず〜っと担当してきたという気持ちもあるでしょうし、実際に同じ人が担当することによって、安心と自負も生まれるのでしょう。
ところが、ここに「合成の誤謬」という落とし穴があるのです。部分をつなぎあわせても全体にはならないのです。すでにアーキテクチャが確定したあとのコンポーネントを設計し実装するスキルと、全体のアーキテクチャを策定（設計）するスキルとでは、まるで違うのです。この問題は、組み込みシステムの世界で、初めてＲＴＯＳを導入するという時に必ず遭遇する問題です。システム全体のアーキテクチャが全く違うのです。そこで求められるのは、全体を見渡したうえでの分析能力です。優れたアナリストは、全体を表現し、全体の動きを把握するために、いろんな「表現」を用います。そのような表現のほとんどは、アーキテクチャが確定したあとのコンポーネントの設計や実装の作業において作られることはありません。もちろん、一部の表現はそこでも有用なのですが、それが無ければ実装作業ができないわけではありません。これは、そこで求められているスキルが異なることを意味しています。
もう一つの問題は「スケジュール管理」あるいは「プロジェクト管理」にあります。顧客から、このコンポーネントの実装をいつまでに仕上げて欲しいといわれて取り掛かるのと、このコンポーネントの実装に何日かかるか見積もって計画を立てるるのとでは、必要とするスキルは違うのです。ましてや、プロジェクト自体を納期通りに仕上げるには、全体としてどのような工程が必要で（本当は“全体からみてそこにどのような工程が有効で”と云いたいのですが―脚注）、その工程の中で、どのような「ステップ」が必要かを見極めるスキルが必要で、個々のコンポーネントを期限付きで請け負うの時のスキルとは違うのです。
しかも、これらのスキルは、「部分」の請け負いを長くやっていれば“自然に”身に付くものでもありません。求められるスキルの違いを認識し、その気になって手に入れようとしないかぎり、手に入らないものです。組織が、その習得を必須を考えるなら、個人に対してそれなりの支援をすべきでしょう。
２１世紀、もはや「部分」の請け負いに活路を見いだせなくなったソフトハウスは、全体の請け負いの向かう前に、このスキルが手に入っていることを確認する必要があります。そうでなければ、折角に請け負ったものの、見事に失敗することになります。そして２１世紀は、この１回の失敗が、発注側にとっても致命的なダメージを負う可能性があるのです。９０年代の「失敗」とは違うことに気づいていなければなりません。
――――――
「必要な工程」というときは、どちらかというと「前から」工程を考えているときです。それに対して「有効な工程」というときは、むしろ「後ろから」顧客の要求を満たすために必要かつ有効な工程を見つけるという発想です。「前から」はコストの積み上げ式の発想に近く、特徴としては、何年経っても工程を変化される力が働きません。これに対して「後ろから」考えるのは、販売価格を最初に決めて、それを実現するための方法を考える発想と同じです。工程もそこで作られる成果物も有効性の範囲内で変化します。