文＝井上　実

Text by Minoru Inoue

外資系ＥＲＰベンダー 勤務。IT戦略、情報化企画、BSC（バランス・スコア・カード）導入、BPR（ビジネス・プロセス・リエンジニアリング）などに関するコンサルティングを担当。中小企業診断士、ITコーディネータ。４９歳。

コンサルタントの使い方を提言する

　最近、『日経コンピュータ』でもたびたび取り上げられているように、コンサルタントに対する批判が目立つ。コンサルタントの一人として非常に残念に思う。

　ここではコンサルタント側の事情を説明しながら、ユーザーのとるべき対策をまとめてみた。下記の提言は当たり前のようにみえるが、実際に順守するのは難しい。今後コンサルタントとユーザーと共同でうまい着地点を作らねばならないと考えている。なお、ここでは筆者の本業である情報化企画のコンサルティングを中心に述べる。

�@依頼内容と期待する成果物を明確に

　コンサルタントに仕事を頼むときは、何が成果物で、それが次の段階でどう有効活用されるのかを明確にした上で、依頼すべきである。不明確では期待した成果が得られないのは当然だ。

　ただしコンサルタントとしては、必要な情報をユーザーから得ることができず、予定した成果物を作成できない事態になるのを恐れる。そのため事前には具体的な成果物の内容を提示できず、成果物である企画書の目次程度しか保証できないケースが多い。ただ目次だけでも規定しておけば、期待はずれになる可能性は低くなる。

�A成果物に対して料金を設定する

　コンサルタントに支払う料金は成果物に対する価格でなければならない。時間に基づく料金体系である限り、質の高いコンサルティングを短期間で提供するインセンティブはコンサルタントに働かない。無駄な時間と人数が消費され、質は向上しない可能性が高い。

�B企画・開発の丸投げはするな

　企画段階であれ開発段階であれ、コンサルタントに丸投げしてはならない。コンサルタントは内部の業務改革の指示はできない。社内の歴史的な経緯や現場の詳細を把握するのも困難だ。ユーザー自身がイニシアティブを取ってコンサルタントと一緒に作業しなければならない。時間がなく一緒に作業できない場合は、レビューをユーザーの責任で実施し、納得できない部分は修正させていく必要がある。

�C企画担当者を開発にも加わらせる

　ときどきユーザーの現場担当者から、企画段階の成果物が開発段階で有効に使えなかったという苦情や悩みを聞く。企画を担当したコンサルタントとしても誠に残念だが、開発メンバーに加わっていないために手出しができない。

　なかには、開発担当ベンダーがユーザーのためではなく、自分のやりやすいように企画内容を解釈してしまうこともあるようだ。このようなことが起きないように、できるだけ企画にかかわったコンサルタントを開発段階にも残してほしい。もともと企画書だけでは、検討した内容や結論に至った経緯を開発担当者に十分に伝えることはできない。やはり、文章にはできない思いや考えがコンサルタントの頭の中にはある。この暗黙知を開発担当者と共有するには、コンサルタントが開発にも参加する必要がある。

　あるいはユーザーは開発見積りを取る段階で企画段階の成果物を見せ、その内容に基づいた開発を依頼すべきだ。もちろん、企画書を開示するときには、機密保持契約を締結することを忘れてはならない。