批判されるのはベンダだけ？
「ITゼネコン」という言葉がIT業界周辺で一般的になって久しい。そもそも、電気通信関係の発注で一大発注者であった電電公社（当時）の機器やメンテナンスを受注するいわゆる「電電ファミリー」を構成した諸企業群にこの源流は求められるが、ITゼネコンという言葉自体が登場したのはここ数年のことで、インフラ構築からコンピュータ機器の設置、納入後の運用メンテナンスに至るまでを一括受注して利益を得ている大規模なITベンダ、例えばNTTデータや日立、NEC、富士通などの大手ITベンダを一般的に指して呼称される。この言葉は必ずしも良い意味で使われているわけではなく、電子政府関連などの公共事業の受注で莫大な利益を上げていることや（実際、大手ベンダ10グループで中央省庁の電子政府関連案件の8割を受注している。後述の岸本氏資料を参照）、すべて自社内で構築するのではなく、数多くの下請け、孫請け企業を使ってシステムを構築している姿が建設業界のゼネコンと似ていることなどが、ITゼネコンという名前で批判的な文脈で語られる理由なのだろう。
しかし、一般的にITゼネコンと聞いて想像されるのはそのような大手コンピュータ企業であるかもしれないが、実は問題はそこだけではない。実は、コンピュータシステムを導入して経営改善を図ることを目的に、コンサルタントを民間企業に送り込み、ERPなどの業務パッケージを導入を図っているコンサルティングファームについても、この種の批判があることはあまり知られていない。
コンサルティングファームに対する批判
コンサルティングファームはコンサルタントがクライアント企業の戦略について考えるだけではなく、実際にコンサルタントが企業の中に入り込んで業務プロセスを学びつつ、ERP業務パッケージなどを使って業務効率を向上するというシステム系の分野が、売り上げの多くを占めている。それゆえに、コンサルティングファームに所属するコンサルタントの中には実はシステムエンジニアという人も多い。これに対して、高額なコンサルタント料を払う割には、成果物である報告書・改善のためのシステム要求定義書や、作り込んだアプリケーションがコンサルタント料に見合わないものである、という不満が各所で聞かれる。もちろん業務改革の成功例も枚挙に暇がないことは事実であるのだが、そのような不満が存在することは政府調達とはまた違った意味で、民間企業におけるIT投資が適切に行われているか、効率を上げているのかという問題提起に繋がってくる。
1年ほど前と、かなり古い話になるが、日経BPのITProのコラム「記者の眼」で大反響を呼んだ記事があった。日経ビステックの谷島編集委員が執筆した一連のシリーズで、焦点は「業務改革とシステム構築をするときに,業務要件の分析と整理をだれがどのようにいくらくらいかけてやるべきか」という点で、具体的にはコンサルティングファームが携わったのにうまくシステムが稼働していない例、コンサルティングファームから上がってきた成果物が期待通りでなかった事例などを取り上げたものだ。
- 記者の眼：『動かないコンピュータ』とコンサルタントの関係(2002年10月31日)
- 記者の眼：読者96人の意見に答える――「動かないコンピュータとコンサルタント」問題について(1)|(2)|(3)|(4)|(5)|(6)|(7)(2003年1月27日)
- 情識・常識:絵だけでシステムは作れない(2003年1月30日)
- 記者の眼：再取材！「絵を描くコンサルタント」は実話(2003年2月10日)
この記事は大きな反響を呼び、谷島記者は100通以上にものぼった読者からの反応に対して丁寧に応えることになったのだが、この一連のシリーズは、読者から指摘されたように、議論の精緻さという点では疑問が残る点もあったとはいえ、コンサルタントの質の低さがプロジェクトの失敗の要因となっているということについて、基本的に間違った事は指摘していない。成果物が業務改革に直接役立たないバインダだったり、プレゼンテーションソフトウェアの出力の紙束だった、と嘘のような話が続くが、高額なコンサルタント料を支払う発注側企業にしてみれば、笑うに笑えないだろう。往々にして、業務改革を狙った全社的な大規模なシステム開発には億単位の費用（大規模な場合、数十億円）が投入されることもあるのだから。
発注者側に問題はないのか
しかし、コンサルタント（あるいは、大手ベンダの担当者）を非難することは簡単だが、それは問題を矮小化する。本来大規模なIT投資プロジェクトは丸投げではなく、発注者側も積極的にコミットしていく性質の業務であるからだ。また、コンサルタントには極めて優秀な人も大勢居る。彼らが作成したバインダにしても要求定義書にしても、良くできてはいるが結果的に活用されない場合もある。すなわち、このような問題が引き起こされる背景には、発注者側の問題も無視し得ないのである。
例えば、谷島編集委員のコラムや寄せられた意見を見ると、丸投げで業者任せという発注者側の責任が指摘されている。政府調達の例でよく指摘されるが、発注者側が作成する仕様書のレベルが低い場合や、仕様書をコンサルタントに作らせる場合にしても、なにをIT投資によって実現したいのか伝えられない情報システム部門の能力不足などである。つまり、発注者側の意図が曖昧なので、作業を行うコンサルタント側も手探りになってしまうのだ。
谷島編集委員も「そもそも業務改革をし,それに必要な情報システムを作るという大仕事を赤の他人であるコンサルタントだけでできるはずがない。自社の社員とコンサルタント,自社のシステムを熟知しているインテグレータらが一緒になって汗を流すべき仕事である。」と指摘しているが、丸投げ、業者任せというのは悪い結果しか産み出さない。
丸投げをするのは楽だ。しかし、そこにはお金を支出する際の責任という認識が抜け落ちている。担当者が支出するお金は政府調達なら国民の血税、民間企業でも、投資家が投じたお金、あるいは社内で努力して稼いだ資金ということになる。莫大なお金をかけたプロジェクトを執行する立場にある情報システム部門、ひいては経営者はその大切なお金を使っているという自覚を持たなければならない。
言い換えれば、適正なIT投資を実現していくためには、受注者のみならず、発注者側もきちんとした知識を持ち、きちんとした仕様書を書き、実行状況を監理でき、アウトプットを評価できる、賢い発注者の存在が不可欠なのである。また、経営トップから情報システム部門に至るまで、発注者側が、開発サイドから上がってきた指摘をきちんとフィードバックできるのかという、発注側企業内におけるIT投資の位置付け、重要性の認識という点も重要であろう。（この点については、経済産業省商務情報政策局情報経済課がまとめた「情報技術と経営戦略会議」の報告書(PDF:168KB)で、具体例を挙げて分析されている。）
一昨年開催したシンポジウム「誰のための電子政府？」の第二セッションでも、岸本周平RIETIコンサルティングフェローが「発注者側が騙されているのが悪い」と喝破していたが、岸本氏資料（PDF:578KB）まさしく、ベンダやコンサルタントに「騙され」ないように、詳細かつ厳しい要求をしていくことが、無駄なコストを削減し、駄目なコンサルタントを駆逐し、ひいてはIT業界全体の質を高めることになるのだ。
（※ただし、下請け・孫請けに依存する業界構造が変わらないことには...という指摘もできるであろう。この部分については今回のテーマからずれてしまうので、次の機会に論じることにしたい）
発注者側も「賢く」なるために：Enterprise Architectureの導入
このようなIT企業の業務に関わる具体的な基準の標準化に対するニーズに応える形で、経済産業省の情報ユニットではここ数年、ITに関わる人材の能力標準（ITスキルスタンダード）や、政府調達に係る基本的な設計・監理プロセス手順（エンタープライズ・アーキテクチャ）ガイドラインの策定、あるいは中小企業がITを経営に導入する際に助けとなる専門家（ITコーディネータ）の育成・斡旋、事例紹介などの事業を推進している。
これらはいずれも、発注者側・受注者側双方に対して、ITに関しての技術評価の体系、IT投資に当たっての知識、システム構築・運営に関わる標準的な取り組みの手順を提供するもので、これまで漠然とした形、各ベンダ間でバラバラの形で捉えられてきたIT関連業務について、一定の評価基準を示すものとして高く評価できる。
- EA策定ガイドラインVer.1.1
- ITスキル標準センターの設立及び研修ロードマップの公表等について
- 戦略的情報化投資活性化事業(ITSSP事業）
例えばITスキル標準ではIT業務に関わる人材の具体的な能力をエントリーレベルからハイレベルまでの7段階に分け、プロジェクト・マネジメントやコンサルタント、セールス、ソフトウェア開発、オペレーション等の職種毎に必要なスキルを分類している。（ITスキル標準フレームワーク(PDF)）具体的には、各々のレベル別に必要とされる能力を列挙しその達成度に応じて、ITスキルを評価する手法を取っている。（分野別スキル標準）例えば、システムオペレーションの「レベル5」では、責任性（ユーザと合意したサービスレベル(SLA)の達成等）・複雑性（運用システムの複雑性（マルチプラットフォーム、マルチベンダ、高可用性）等）・サイズ（管理する要員数がピーク時10人以上、または年間契約金額1億円以上等）・タスク特性（後進育成、社内のコミュニティ活動、社内の論文・技術レポートの執筆等のプロフェッショナルとしての顕著な貢献/実績等）の要件が規定されている。
これにより、従来定義することが難しく、能力評価が曖昧になりがちであった、システム管理・運用におけるスキルについての標準が広まることになる。つまり、受注者・発注者に限らず、ある程度の知識や経験を持った人材が適材適所に配置されることや、スキルに対しての適切な評価が行われるといった効果が期待できる。
政府調達の指標として来年度から全府・省庁で導入される予定のエンタープライズ・アーキテクチャ(業務・システム最適化計画。以下EAと略)も、容易に民間企業に置いても導入が可能な設計となっている。おそらく、本コラムで取り上げた、コンサルタンティングファームと発注者側の認識のズレ、あるいは「使えないバインダ」、「プレゼンテーションソフトの出力紙束」という問題に対して最も根本的な解決を図るのが、このEAである。
これはIT投資を通じて業務改善を行う際の設計・管理手法を定めたものであり、具体的には業務の分析フェーズ、組織の現状把握のフェーズ、最適化設計のフェーズ、最適化設計を実現するための具体的なステップの作成という4段階になっており、開発・監理の様々な段階で、このEAのモデルが共通認識として開発に携わる企業・ベンダ等に採用されることで、開発業務の円滑化・質の高いシステム調達を実現しようと言うものである。
EAが登場してきた背景には、是までのシステム開発において往々にして見られた、業務プロセスやデータの分析を行わずにシステム要件を策定してしまうという「中抜け」型の開発プロセスに対しての反省がある。そのため、EAにおいては、設計監理の手順と必要なプロセス、制作される成果物の種類を厳しく定義し、方法論を共通化することで、ベンダの枠を超えて調達側がきちんとプロジェクトを監理できるような工夫が凝らされている。
- EA策定ガイドラインver1.1 報告書概要（PDF:661KB)
- EAについて－導入編(PDF:575KB)
- EAについて－体制論編(PDF:353KB)
- EAについて－方法論編(PDF:1,073KB)
このように、政府もIT投資における効率性の向上のための具体的な取り組みを始めてきている。「ITゼネコン」とか、「コンサルが使えない」と、ただ単に批判する段階を超えて、IT投資をより質の高いものにしていくためにどのような事が出来るのかを議論し、具体的な行動に移していく段階に到達しつつあると言えよう。
EAに代表されるような標準的なプロセス手順が政府調達の現場のみならず、民間企業においても一般化し、さらにITスキル標準のような基準で担当者のスキルと業務が明確に判断されるようになれば、谷島編集委員が1年前に嘆いたような状況は、すこしずつ改善されていくのではないだろうか。EAの中身やスキル標準の条件などについては異論があり得るが、少なくとも、ほとんど明確な基準がない現状から見れば、遥かに進歩している。また、今回策定されたのはEAの策定ガイドラインであり、「バージョン1.1」と銘打たれているようにまだ改良される余地は残っている。このガイドラインを元に、官民双方で活発な議論が行われ、より実行力のあるEAが普及していくことを期待したい。
This work is licensed under a Creative Commons License.
