「ゼネコン」といえば、これまで大手建設業の代名詞として使われてきました。もっともバブルがはじけ、公共工事が減ったり、頼みの資金源の金融機関の方が引き締めにかかったため、めっきり旗色が悪くなっています。中には、「借金チャラ」で何とか両足で立っているような「ゼネコン」もあり、最近では、時代の変化の象徴として使われているようなところもあります。
このゼネコンというのは、ビルなどの建築に関するすべての業務を「一括して受注」し、自分は主に設計と監督（だけ）を請け負い、実際の現場での建築業務は適当に分割して下請け業者に割り振るという方法で売り上げを伸ばしてきました。発注する側も、１社に全部任せるということで、煩わしさが無いし、発注先は大手の“しっかりした”企業なので、途中でトラブルがあって工事が止まるような心配をしないですむ、といった「安心感」があったわけです。ゼネコン側も、それを“売り”にして勢力を伸ばしてきました。
実はこれと同じ構図が、ソフトの分野にも存在します。大手のソフト会社が受注した案件が、実際にはほとんど丸ごと下請けに発注することが少なくありません。形の上では、「下請けの作業を管理」していることになっていますが、ソフトの開発作業の工程は、建築の世界ほどには標準化されていません。いや、ほとんど「工程」や「ステップ」なんて考えは無いに等しいといってもよいでしょう。見掛け上は存在していても、作業内容や着手条件や完成条件などが定義されていないでしょう。当然、そのような状況でまともな「下請け管理」なんてできる状態ではありません。
特に、案件によっては３次下請けまであることも珍しくなく、たとえ元請けに有能なマネージャーが居ても、そこまで元請けの管理が及ぶことは不可能に近いといっても過言ではないでしょう。そのうえ、現実には、そのような“できる”マネージャー自体が非常に少ないのです。そこで行われていることは、ほとんどが「（日本的な）管理」になっていることは想像に難くありません。しかも、仕事を発注する側が、仕事を回してもらう側を管理するのですから、適切な管理手法（技術）を持たないかぎり、上がってくる報告は、「予定通りに進んでいます」「ちょっと遅れ気味ですが、来週中にはばん回します」といったものになってしまいます。
実際、「特に問題はありませんよね」と云われたら、下請けの責任者は「はい、別に問題は生じていません」と答えてしまう。いや、この質問ではそう答えざるを得ないでしょう。そして、いったん、現実と違ってこのような応対がなされたなら、その後は、今更「ちょっと・・・」とは言えなくなります。結局、最後になって問題が吹き出すまで、「異常なし」あるいはそれに近い報告が続くのです。
最初に下請け業者との進捗状況の確認で、どのような応対がなされるか、いやどのような応対を引き出すかで、その後のプロジェクトの進行が決まってしまうといっても過言ではありません。適切なプリジェクト管理の技術を持っていないと、こうして最初から失敗してしまうことになります。
２０００年対応
このソフト業界でのゼネコンスタイルは、２０００年問題の対応にも存在している可能性があります。発注者は、安心感もあって大手のソフト会社に発注する傾向が高いのですが、実際に、大手でもそこまで対応できるわけではありません。また、その他のソフト会社も、この仕事は時限的案件であることもあって、当ての無い営業活動を展開するよりは、最初から大手との競争を避け、大手の下請けに回った方が効率がいいというこもとあります。こうして、大手のソフト会社と、その下で仕事が回ってくるのを待つという棲み分けが成立します。
これ自体は別に悪いことではありません。だが問題は、仕事を予定通りに仕上げることができるかどうかです。必要な個所を適切に直しきれたかどうか、どうやって判断するかです。いやそれよりも、本当に予定通りに作業が進んでいるでしょうか。
今まで、顧客の求める要求を適切に分析し、希望通りに仕上げてきたソフト会社が、日本にどれだけあったでしょうか。過去の発注状況で、そのような対応ができたソフト会社に遭遇したでしょうか。後になって、仕様の追加や変更が頻発しなかったでしょうか。しかも最初の要求には含まれない仕様だから「追加」になるとかならないとかでもめたのではなかったでしょうか。それでもなんとかお互いに歩み寄るものの、当初の納期は外れたのではなかったのですか。
その原因は何か。分析技術や見積もり技術などの不足もありますが、一言で云ってしまえばプロジェクトを“マネージメント”する能力の不足です。見積もりに裏付けられたまともなスケジュールが書けない。あるいは、そこに示されたスケジュールがでたらめであることを見抜けない。要求分析のあり方や要求管理を知らない。ＰＥＲＴ図も知らないし、プロセスを定義することもできない。ましてやリスク管理など別の世界。一体、これで予定通りに作業が終わる方が不思議です。
確かに２０００年問題は、一般の案件とはいくらか性質が違います。その対応が、このような性質の影響をすべて受けないにしても、だからといって、「現有する」マネージメント能力で予定通りに作業が進むとは思えないのです。２次３次の下請けの作業の状況が、元請けの方でどこまで把握されているか。そのことがリスク管理の対象として適切にマネージメントされているでしょうか。おそらく（間に合わないという）問題として吹き出した時点で慌てるのではないでしょうか。
残念ながら、ソフトウェアは、多くの場合、建築と違って誰の目にも進捗状況が明らかになるようには進められてはいません。それだけに「プロジェクト管理」に関する技術や能力が求められるのです。ゼネコンスタイルがすべて悪いのではありませんが、適切な技術を伴わない状況では、結果的に日本のソフト業界の地盤沈下を促進する危険があります。しかも、「大手」ということでの安易な発注スタイルが、ソフト・ゼネコンやそれに付随する問題の発生に拍車をかける可能性があります。
重複計上
ゼネコン・スタイルで、もう一つ問題なのは、統計上、ソフト業界の売り上げがダブル・カウントされることです。下請けに発注される分も、いったん自社の「売り上げ」として計上されます。もともと１億円の案件でも、１次下請けに８０００万円で発注し、さらにそこから２次下請けに４０００万円で発注したとすれば、各社の「売り上げ」を合計すると２億２０００万円になります。でも各社の手元に残ったのは、合計で１億円なのです。ここから、給料などの経費が支払われます。
もちろん、この仕組みは、すべての製品に存在します。たとえば、自動車でも製品の売り上げの中に、部品の売り上げが含まれます。パソコンもテレビもそうです。でも、統計上は、「自動車の売り上げ」や「テレビの売り上げ」と「自動車部品」や「電子部品」という別の業種として集計されます。これに対して、ソフトの下請けの場合は、同じ業種のなかで売り上げが集計されますので、実態とかけ離れた統計が出てしまいます。しかも、どの程度重複しているのか分かりません。統計数字を見るかぎりでは、「一人前に育った」として見えるかも知れません。
その意味では、建築業界でも、同じようにダブル・カウントされていたものと思われます。
ソフトウェアも、近い将来、製品売上と部品売上というように、業界が別れるかもしれませんが、今のような「ゼネコン・スタイル」が続く間は、業界の実態を正しくつかむ方法はないかも知れません。
発注側の変化
今、建築業界は変わりつつあるようです。今までのように、とにかくまとめて１社に発注するというやり方ではなく、自前で内容を分析し、必要に応じて発注者自身が直接（かっての下請け）業者に発注する形に変わってきています。そのために、それまでゼネコンで下請け管理をしていた人を引き抜きにかかっているのです。マンション会社やリース会社、石油の販売会社などが、ゼネコンから有能な管理者を数人引き抜き、それによって、これまでのように一括してゼネコンに発注する必要がなくなったわけです。コストも２〜３割削減できると云われています。実際の作業をしている業者（かっての下請け業者）の手取りは同じですので、この差額は、これまでゼネコンが管理費として取っていた分です。
これは、発注者が力をつけたということです。ソフトウェアの世界も、早くこのような状態に移行する必要があります。発注者自らが、数社の下請け（外注）業者に適切な案件を発注し、その進捗を管理する能力を身に付ければ、ソフト・ゼネコンも成立しなくなります。もっとも、建築と違って、ソフト・ゼネコンに下請け管理に長けた人がどれだけいるか怪しいところですが、発注側が必要な能力を手に入れれば、この問題は防げるはずです。最も、２０００年問題には間に合いませんが。
昨今、「プロセス」に関する文献が盛んに出版されています。またインターネットを通じて、プロセスに関する研究成果などを容易に手に入れることができるようになりました。これらの研究成果の多くは、プロジェクトの管理技法に大きな影響を与えるものです。プロセスの確立は、プロジェクト管理（プロジェクト・マネージメント）にとって、まさに出発点でもあるのです。これが明確になることで、見積もりやスケジュール管理などの問題も解決しやすくなります。また、作業の標準化にも大きな影響を与えるでしょう。
つまり、これから「プロセス」の研究や取り組みが進むことで、プロジェクト管理に長けた人が増えてくる可能性があるのです。いや、市場はそのような人を求めているのです。そして、そのとき、今のような単に案件を丸投げするような「ソフト・ゼネコン」は消滅していることでしょう。