 |
曖昧なインターフェイス |
建設産業における生産システムとはどのようなものでしょうか。建設産業はプロジェクト・オリエンテッドで生産活動がなされます。つまり、プロジェクトが始まると発注者、設計者、施工者など様々な関係者が寄り集まって、一つの組織体をつくって動き始めるのです。しかも、そうしたプロジェクトはそれぞれ独立性が高いものになっています。例えばあるゼネコンは同時に複数のプロジェクトを抱えているわけですが、ＡプロジェクトとＢプロジェクトは相互にあまり関係がなく、個々のプロジェクトが独立しています。また、生産組織はプロジェクトごとに離合集散をします。プロジェクトが始まると発注者が設計者を選び、ゼネコンを選びます。ゼネコンはサブコンを選んで組織ができ、その組織がプロジェクトを遂行するわけです。しかし、プロジェクトが終わったら、基本的にその組織はなくなってしまいます。
建設産業における生産システムでは、サプライチェーンが弱いという特徴もあります。例えば自動車産業であれば、サプライチェーンの頂点になっている企業が、「ＣＡＤはこれを使いなさい」というように、彼らに協力している会社群を率いて仕事を行います。ところが建設業界では、大手５社のシェアも全体から見ればわずかなものです。しかも、ゼネコンは協力業者会を持っていますが、その組織率はかなり低いものとなっています。したがって、一定の連携を保った会社とだけ仕事をすることは不可能に近いのです。
また、「クルーは可換性あり」というのも大きな特徴です。建設プロジェクトが始まると、例えば設計者なら設計事務所もあるし、コンサルもあって、ここでなければいけないということはあまりありません。建築なら設計施工ということがあって、ゼネコンの設計部門が設計してゼネコン自身が施工するということもあります。つまり、ゼネコンから見ると、建設プロジェクトにおいてそれを執行する組織が会社の内外に存在するために、それぞれの機能を果たすクルーは非常に可換性が高いのです。
建設の生産システムは図−１のように、それぞれの会社というピースが機能を分担して、その間を情報が流れて物ができると表せます。そして、ピースの間は非常に隙間が空いていて、少々のデコボコがあってもちゃんとはまってしまいます。しかし、それは同時に効率が悪いということでもあります。
例えば、設計事務所やコンサルが書く設計図書だけでは、基本的には施工ができません。設計者と打ち合わせながら施工図を起こすことになります。建築についても、専門工事業者が施工図を書いてきますが、設計図書はかなり曖昧にできていて、設計者と打ち合わせながら決めていく部分が大きくなっています。それは土木でも同じです。我々の業界には「これだけの誤差は許すよ」という公差の概念がありません。つまり、建設業界の生産システムにおいてはプロセス間のインターフェースが曖昧なのです。
 |
|
図−1
|
|
特定の企業を超えるシステム |
建設プロジェクトの担い手としての企業は様々です。例えば、ゼネコンの企業ＸはプロジェクトＡ、Ｂ、Ｃ、Ｄというように様々なプロジェクトを抱えています。そして、各プロジェクトに関わる企業は様々で、同じ企業Ｘが関与しているプロジェクトでも構成する企業の組み合わせはそれぞれ違います。ここで重要なのはプロジェクトＡはプロジェクトが存続している限りは、一種の会社＝バーチャルカンパニーのように機能しているということです。
そうした組織でＩＴ化を進めようとすると、企業ＸでいくらＩＴ化を進めても限界があります。なぜなら、建設現場で働くゼネコンＸの職員はほんのわずかで、組織全体の能率アップにはつながりにくいからです。また、規模の大きな専門工事業者や設備業者などもＩＴ化を進めていますが、それはその会社の能率アップにはなっても、プロジェクト全体の能率向上にはつながりにくいわけです（図−２）。
建設プロジェクトを構成する企業の数が多いため、必然的に各企業の寄与率は低くなります。したがって、特定の企業のみがシステムを進化させても、全体の生産性にはあまり寄与しません。生産プロセスの効率を上げるには、プロジェクト全体を構成する企業間をつなぐバーチャルカンパニーとしてのシステムが必要になります。
また、一つの企業だけでいくら頑張っても、製造業のように自らの企業群や協力会社を率いて別次元の生産システムをつくって、他と差別化して競争に勝つことは建設業界においては非常に難しいと考えられます。なぜなら、専門工事業者がある特定のプロジェクトでシステム化されたデータをもらっても、他のプロジェクトの大半が従来通りの紙の図面だとすると、今までのやり方をそのまま温存せざるを得ないからです。そうすると、全体で見ればコストが下がらないことになります。我々の業態はそれぞれ専門があって、補い合いながら全体を成し遂げるので支配力は非常に低いものになっています。そのため、ある特定のシステムをつくることが非常に難しいのです。
 |
|
図−2
|
|
企業を超えていくルールづくり |
インターネットのおかげでネットワークの準備は整いましたが、企業を超えて行こうとすると、データの中身が標準化されていない限りは受け取れません。そうした中で、ＣＡＬＳ／ＥＣやＣＩ−ＮＥＴは、会社を超えていくシステムを構築する一つのきっかけになるのではないかと考えます。
図−３はブリューゲルが描いた「バベルの塔」です。「バベルの塔」は、神様が不遜な民を懲らしめるために、皆の言葉をわからなくしたという話ですが、情報の世界で会社を超えようとすると、まだこれと同じ状況ではないでしょうか。実際のデータの中身は会社ごとに方言を持っていて、会社を超えるのは非常に難しいと思います。
 |
|
図−3
|
|
CALS／ECの果たすべき役割とは |
そのような中で、ＣＡＬＳ／ＥＣの果たすべき役割は、基本的にはある標準で納品をさせたり、ある標準に準拠して入札をするということです。標準には、つくられても使われないものがたくさんあります。しかし、使われない標準ではどうしようもありません。その点、流通業界におけるＪＡＮコードは一種の会社を超えた標準で、これが機能し始めたおかげでスーパーのレジがどれだけ楽になったことか。ＪＡＮコードは、まさに会社を超えた標準が威力を発揮している好例であり、同様にＣＡＬＳ／ＥＣも使われる標準でなければいけないのです。
ただし、サプライチェーンの途中に位置する者がいくら標準が大事だとわかっていても、全体に号令をかけて使わせられるかというとそれは無理です。自分の組織だけでは身動きできません。したがって、標準を使ってもらうためには、強力な動機付けが必要であり、サプライチェーンの頂点に立つ者の自覚とリーダーシップが必要になります。ＣＡＬＳ／ＥＣのように国土交通省が声をかけない限り、全体は動きようがないと私は思います。
また、ＣＡＬＳ／ＥＣでは、標準を含むルールづくりだけでなく、システムの運用、定着のために膨大な労力が必要になります。技術レベルとそれに関わる関係者の数との関係を図−４に示しました。在来のシステムは皆が慣れているので関係者の数は多いわけです。情報システムのレベルを上げる場合、たとえそれが高度なものであっても関係者が少なければ、システムの運用定着は難しくありません。しかし、ＣＡＬＳ／ＥＣは国土交通省の施策ですから、ある限られたところでしか使えないものは、とても施策として打ち出せません。そうするとどうしても関係組織や関係者の数は多くなります。そうなると情報システムのレベルをそれほど上げなくても運用は大変になりますが、同時にそれがうまくいったら効果も非常に大きいわけです。
このように重要な役割を持つＣＡＬＳ／ＥＣですが、現在は電子納品や電子入札といった限られたところにのみ使われています。しかし、本当はそれだけが目的ではないと私は思います。例えば、電子納品といっても、完成した図書を渡すだけなら当事者にとってほとんどメリットはありません。本来は完成したものを納品するのではなくて、実際の生産プロセスの中で、情報がやり取りできて、効率化できることが必要だと思います。
入札においても、入札をして契約となって、契約データがお互いに残って、今度はその契約から見積依頼ができるというように、サプライチェーンの中をデータが流れていけば、それぞれの関係者がメリットを享受できるようになるはずです。
 |
|
図−4
|
