コンサルタントはなぜ批判されるのか
井上 実
コンピュータ専門雑誌の記事の中で、情報化企画を行うコンサルタントに対する批判が目につく。同じ仕事で生きているものの一人として、その内容は誤りだとは言わない。しかし、起きている現象だけを捉えた批判はゴシップ記事としての価値しかなく、コンサルタント自身やこれを利用するユーザ企業にとって、何ら価値がない。
ここでは、取り上げられているコンサルタント批判の本質を明らかにし、その原因を追求したうえで、ユーザ企業がコンサルタントを活用する場合の留意点およびコンサルティング業界の取り組むべき課題を述べることにする。
１．情報化企画コンサルタントに対する批判
「動かないコンピュータとコンサルタントの関係」や「絵だけでシステムは作れない」などで取り上げられている情報化企画フェーズを担当するコンサルタントに対する批判は次のようなものである。
（１）数億円支払ったが使われないバインダー
情報化企画作業をコンサルタントに依頼し数億円支払ってできあがった企画書がバインダーで10冊くらいになった。しかし、その内容はユーザが理解できる内容ではなく、また、導入する予定のERPの提供するビジネスプロセスともかけ離れていたため、使い道がなくなってしまった。
（２）使えないソフトの推薦
情報化企画作業をコンサルタントに依頼したところ、結論として、海外を含めた全社にSCMソフトを導入すべしということになり、ソフト購入契約を行った。しかし、導入作業を進めていくと組織体制や運営体制の見直しなどが必要であり、一筋縄では行かないことがわかり一部の部門に導入しただけで全社導入は頓挫した。
（３）絵だけが成果物
情報化企画をコンサルタントに依頼し、できあがった新ビジネスプロセスはプレゼンテーション・ソフトで書かれた概略図だけで、システム開発・導入に必要な機能要件定義が書かれたものではなかった。
２．批判の本質
この批判の本質はどこにあるのだろうか？現象面にとらわれることなく、何が問題なのかを整理してみる。
（１）開発につながらない情報化企画の成果物
いずれのケースも、情報化企画で作成した成果物が、次のフェーズであるシステム開発・導入作業で有効に使うことができなかったということを問題として取り上げている。数億円支払って完成した企画書も、絵で書かれた新ビジネスプロセスも開発・導入作業の中で使用することができなかったことが問題なのである。
このように次のフェーズにつながらないものを作成したコンサルタントは何をしていたのかというのが批判の本質の一つである。
（２）期待と成果物と料金のアンバランス
もう一つの批判の本質は、情報化企画を担当するコンサルタントに「支払った料金」と、「できあがった成果物」と、「依頼した時の期待」とのアンバランスである。
３つのいずれのケースも、コンサルタントに依頼した情報化企画作業に関してユーザが抱いていた期待を満たすことができないレベルの成果物であった。そして、その結果、支払った料金が妥当だったのかと疑問を持つことになる。支払った料金が高額であったとしても、期待した以上の内容の成果が得られれば、料金の妥当性に対する疑問は生まれない。
ここであげた批判の本質に対し、なぜ、そのようなことが発生してしまうのか、その原因を探ってみることにする。
３．なぜ情報化企画の成果物が開発につながらないのか。
情報化企画の成果物が、次のフェーズであるシステム開発・導入作業になぜ有効に使われないということが起きてしまうのか。その原因としては、次の三つが考えられる。
（１）開発担当者の企画フェーズに対する期待との乖離
次フェーズを担当する開発担当者が、情報化企画フェーズで作成してくるであろうと期待しているものと、実際の成果物が乖離しているがために、開発に有効に使用できないということが原因の一つとして考えられる。
開発担当者が期待している詳細度と企画フェーズで作成した成果物の詳細度が合わないことが、根本的な原因である。開発担当者は機能要件の詳細まで定義されているものが得られるという期待に対して、システム機能全体図しか企画フェーズで作成しなかった場合などがあてはまる。
外部に開発を依頼するケースでは、企画フェーズ開始時に開発担当者は決まっておらず、企画でどの程度の詳細レベルまで記述するかを事前に両者で相談することはできない。そのため、このような齟齬が生まれることが多い。
（２）ユーザが企画内容を理解していない
企画フェーズ開始時に開発担当者が決まっていなくても、ユーザが企画の内容を理解していれば、企画書の文書から読み取りにくい部分を補完して開発担当者に説明することができ、企画書は開発・導入フェーズで有効に使用することができるはずである。
ところが、ユーザが内容を理解せずに、開発担当者に企画書を渡すため、企画書が開発段階で有効に活用されなくてなってしまうのである。
（３）企画にかかわったコンサルタントが開発に加わらない
企画フェーズ開始時に開発担当者が決定していないため、企画フェーズにおける成果物の詳細度に関して事前に相談できず、ユーザが企画内容を理解していないのであれば、企画作業を行ったコンサルタントに開発担当者が適宜質問をして内容を理解していくしかない。
しかし、多くの場合、企画フェーズを担当したコンサルタントは、開発フェーズに継続してかかわることは費用がかさむことからユーザに望まれず、開発担当者からも、自分自身のやり方でシステム構築プロジェクトを進めたいという気持ちから望まれない。そのため、企画終了した時点でコンサルタントはお役御免になり、企画内容は開発担当者に十分に理解されることなく捨て去られる。
４．なぜ期待と成果物と料金のバランスがとれないのか。
もう一つの批判の本質である期待と成果物と料金のバランスが、なぜとられないのか。その原因としては、次の三つが考えられる。
（１）不明確な期待
情報化企画作業に対する期待が不明確なため、依頼したユーザ側の期待と依頼されたコンサルタントとの間で、作業内容の不整合が発生する。依頼したユーザは何が作られるかを知らずに夢のようなぼんやりとした期待だけで企画作業をコンサルタントに依頼する。コンサルタントは、いままで経験してきた企業と同じような内容で企画作業をすればよいと思い込み、十分な説明をせずに受注し作業を開始してしまう。
結果として、できあがったものがユーザの期待に合致しない。
（２）不明確な成果物
期待と同様に、企画作業の成果物を事前に明確に決めずに、コンサルタントに依頼すると、ユーザおよびコンサルタントは成果物の内容に関して、それぞれの持つ成果物に対するイメージを一致させることなく、企画作業を進めてしまい、結果としてできあがったものの内容がユーザが持つイメージと異なるために、不満となる。
（３）消費時間に基づく料金
コンサルタントの料金は、担当するコンサルタントのグレードに基づいた時間単価（人日単価、人月単価）に、コンサルタントがユーザの作業で費やした時間（日数、月数）を乗ずることにより算定される。成果物の価値に対する料金ではなく、あくまで、サービスを提供した時間が料金のベースである。
そのため、成果物の価値と見合わない料金が請求される可能性があり、成果物や期待とのアンマッチを発生させる原因となる。
５．情報化企画コンサルタントを有効に活用するためには
これらの原因を解消し、情報化企画コンサルタントを有効に活用するためには、どのようにすればよいのだろうか？活用方法のポイントとして次の五点
をあげることができる。
（１）依頼内容、期待する成果物を明確にする。
情報化企画をコンサルタントに依頼する場合には、何が成果物としてできあがり、それがどのように次のフェーズで有効に活用されるのかを明確にした上で、依頼する必要がある。何を頼むにしても、依頼内容を明確にせずに依頼すれば期待した成果が得られないのは当然である。
しかし、コンサルタントとしては、ユーザの状況によっては情報不足のために予定した成果物が作成できない可能性もある。そのため、あまり具体的な成果物内容を提示することはできず、成果物である企画書の目次程度しか保証できないケースが多い。しかし、目次だけでも成果物を規定しておけば、期待はずれになる可能性を低くすることができる。
また、いままでやってきた情報化企画の成果物を見たいというユーザの要望が出されることが多くあるが、コンサルタントには守秘義務がありそれはできない。自社の経営戦略に沿った情報化企画書が他社に開示されて喜ぶ企業はないことは、理解できるであろう。
（２）成果物に対する料金を設定する。
コンサルタントに支払う料金は成果物に対する価格でなければならない。消費した時間に基づく料金を設定している限り、コンサルティングの質は向上せず、無駄な時間と人数が消費される可能性が高い。
質の高いコンサルティングを提供し、短期間で作業を行おうというインセンティブは消費時間に基づく料金体系である限りコンサルタントには働かない。
もちろん、見積りはあくまで前提条件に基づくものであるため、前提条件がユーザ企業の事情により変更された場合には、再見積りや追加料金支払いが行われなければならない。
（３）企画・開発の丸投げをしない。
企画フェーズであれ、開発フェーズであれ、外部の人間に丸投げすることは避けなければならない。経営に効果のある情報システムを構築することを、外部の人間にすべてをまかせ、内部の人間が何も知らないですむものではない。
各フェーズの作業はユーザ自身がイニシアティブを持って外部の人間と一緒に行われなければならない。マンパワーをさくことが難しく一緒に作業できない場合であっても、内容に関するレビューはユーザの責任で行い、納得できない部分は修正させていく必要がある。
（４）企画にかかわったコンサルタントを開発フェーズでもプロジェクトに加わらせる。
企画にかかわったコンサルタントは、開発フェーズにも残ってもらう必要がある。企画書という形式知化した内容だけでは、企画フェーズで検討した内容や結論に至った経緯を十分に伝えることはなかなかできない。やはり、文章にはできない想いや考えがコンサルタントの頭の中にはある。これを引き出して、企画フェーズの内容をもれなく開発担当者に伝えていくには、開発フェーズにおいて一緒に作業を行う必要がある。企画を担当したコンサルタントの暗黙知を開発担当者と共有化するためには、コンサルタントに開発フェーズに残ってもらわなければならない。
（５）開発担当者に企画内容の詳細度を事前に開示した後、開発作業に関する提案をさせる。
企画フェーズを開始する時点では、開発担当者が決まっていないことが多い。そのため、企画フェーズを始める前に、開発担当者と企画フェーズを担当するコンサルタントが企画フェーズの成果物に関して打ち合わせを事前にすることは難しい。
このような状況の中で、開発担当者に企画フェーズの成果物が使い物にならないと言わせないためには、開発見積りを取る段階で企画フェーズの成果物を見せ、これに基づいて開発を行うことを前提とした見積りを依頼すればよい。そのときに、企画フェーズの成果物は使い物にならないというところには発注しなければよいだけである。
もちろん、企画書を開示するときには、機密保持契約を締結することを忘れずに。
６．求められる情報化企画の標準化
現状における情報化企画コンサルタントを有効に活用する方法は前述したとおりだが、対処療法であり根本的解決にはならない。根本的な解決は、情報化企画の成果物を標準化することである。標準化すれば、ユーザや開発担当者とコンサルタントの思い違いが発生しなくなる。標準化すれば、コンサルタントの質を客観的に評価することも可能になり、質に伴う料金を支払う（得る）こともできる。
建築物の設計図の書き方は世界的に標準化されているのに、情報システム構築の設計図はいっこうに標準化されないのはなぜだろうか？ユーザを含めた情報システムにかかわるものが力を合わせて、標準化に取り組むことがいま求められている。