プライムビーピーは、実務からアプローチする業務改善、システム開発を実践するソリューションプロバイダーです。

建設実務の視点

Aspect of construction businnes

PrimeBP

5.建設会社におけるIT導入の課題

 建設業におけるIT導入も多岐に亘るようになり、多くの業務情報及び業務 処理が電子化されている。技術計算やCAD、会計業務などの基幹系業務は勿論、 情報系と称されるグループウエアの導入も規模を問わず当たり前となりつつある。 IT化しやすい特定の業務に従事する人だけではなく、ITと建設会社の社員と の付き合いは既に長く、そして広範囲となっている。

 一方、こうしたIT化が浸透しつつある状況にも係わらず、未だ推進における トラブルは尽きない。コストアップは当たり前、当初費用の3倍にもなったとの 話も聞く。新システムの構築に幾度もトライして纏まり切らずにいる会社もある。 システム仕様が収まらず二転三転する話はこと欠かない。それも計画済みとする のが常識となりつつある。

 確かに建設業の業務知識を欠いたシステム技術者が多いことは大きな課題の ひとつだ。会計伝票一枚書いたことのない技術者の設計したシステムの運用が覚 束ないのは当たり前と言える。そこでパッケージシステムをベースに寄せ集め、 建設業務或いは個々の企業特有のシステム機能に修正、付加するイージーオーダー のような取組みも多く行われる。しかしてなかなか体にフィットせず、掛かる 手間が変わらないのが現実だ。例えば建設業会計という仕組みは制度会計と一体 となって体系化されており、そのため一から建設業の会計システムを設計する 場合には、言わば制度会計の体系の中へ組み込んだ会計組織としてデザインする。 従って一般化させた制度会計のパッケージシステムとはどうしても親和性が低く なってしまう。一事が万事、建設業務の全てにそうした深みがある。

 いずれにしても建設業の特異性に対してIT業界における対応が充分とは言え ないが、はたして建設業サイドには問題はないのだろうか。多くのトラブルにお いて、システムベンダーの力不足ばかりが問われるが、そこには過分にスケープ ゴートとされている点も見過ごすわけにはいかない。必要なのは問題解決であり、 責任追及ではない。IT化の推進はシステムベンダーと導入企業との信頼関係に 根ざしたパートナーシップによって始めて実現する共同作業だからだ。目にあま るベンダーも確かに多いが、建設会社が毅然とした対応を怠るために締まりのな いプロジェクト運営にしてしまっていることも多い。常にバランス感覚と成熟を 意識することが第一に求められる。

 IT化は、特に基幹系の大規模なシステム開発の場合には、推進のプロジェク ト体制も規模が大きくなり、当然その活動期間も長い。プロジェクトが一つの 目標実現に向かうのは建設事業もIT化も変わるものではない。

 そこで、IT導入で重要な導入企業側の要件とその裏腹にある課題を、 COMPUTERのスペルになぞって捉えてみた。

 CはCommunicationである。情報化推進のプロジェクト内がシス テムベンダーを含めて一体感を持つためには良好なコミュニケーションは当然と 言える。システムベンダーとIT化の原価企画を一緒にできるぐらいの協調が 図れるのが理想だ。更にプロジェクトの外、つまり関連部門や現場、当然経営者 とも適切なコミュニケーションを維持することが大切となる。社内が遠巻きに プロジェクト運営を眺めているような推進であっては、成功は覚束ない。常に オープンに情報を開示し、積極的なコミュニケーションを図ることで信頼関係が 構築され、プロジェクトへのシンパシー、協力が生まれる。こうした努力なくし てプロジェクトへの社内の信頼感、システム化によるBPRへの心情的な抵抗を 和らげることはできない。ともすると前方位のコミュニケーションは建設業に とって苦手な分野だが、円滑なプロジェクト運営には不可欠な要素と言える。

 IT化推進で一番重要であるにも関わらず不明瞭であることの多いのが Objective(目標)かもしれない。業務生産性の向上、間接業務の自動 化とコストダウン、ペーパーレス化に高度な情報活用の実現、云々云々、耳障り のよい目標が列挙される。こうした蓋然的な目標設定によりUpset(目的と 手段の混同)が生じてしまう。つまりIT化自体が目的化してしまい、実現すべ き本来の目標が見失われていく。目標の基本はできる限り定量化されなければな らない。例えば「ペーパーレス」を挙げるのであれば(それ自体が最終の目標と は思えないが)、少なくともシステムから定型的にアウトプットするレポートを 法定帳簿と主要な管理帳票のうち数種類に限ってしまうぐらいの数値設定を期待 したい。IT化推進はITを活用した目標の実現の場であり、IT化自体ではない。

 目標を実現するシステムの構築を行う上で重要な設計のプロセスが Requirement(業務要件定義)である。業務として必要な要件を機能、 情報、フロー等の面から定義づけていく。この作業が正に業務改善であり、新しい ビジネスプロセスと仕事の仕方をデザインする。しっかりとした業務知識及び業務 の関連に対する理解を前提とするため、導入企業の重要な役目だ。この業務デザイン 如何が後のシステム化のための作業を定義付けるため、システム仕様が固まらない 多くのトラブルがこの作業に起因する。仕事の精度が要求されるのだ。

 IT化推進のプロジェクト運営では、当然そのManagement(マネジメント)力 によるところが大きい。プロジェクト運営の大きなテーマがTime(スケジュール管理) と先に挙げたCommunicationに裏つけられた交渉力にあることは建設に おける現場運営と変わらない。ステコン(ステアリングコミッティー/経営トップ を長とする情報化推進委員会)と称するプロジェクトの上位に位置する意思決定組 織を設置するケースは多い。外資系企業に習った組織運営だが、はたして日本の組織 風土に馴染んでいるのだろうか。屋上奥を重ねるだけならやめた方がよい。プロジェ クトリーダーの仕事は汗をかくこと。大人の差配も必要だ。役員室を走り回る熱い Energy(成功へのエネルギー)は欠かせない、何よりプロジェクトメンバーに 伝播する。

 職業人として、組織人として、IT化推進のプロジェクトに配置され、会社の全般 を見渡す機会を得られる方々の数は決して多いわけではない。数少ないチャンス、 粗末にしてはいけない。会社というのは広く深い存在、丁寧に、そして大胆に関わる のが基本。組織をいじり、仕組みをいじる恍惚と不安と。辛い仕事だからこそ Pleasureが基本姿勢。

 COMPUTERが揃うことがIT化かもしれない。


2003年8月26日(火) 掲載
日刊建設工業新聞コラム「所論/諸論」より(1年間連載したものに一部加筆訂正)


[戻る]

Copyright (C) PrimeBP All rights reserved