過去のプロジェクトを振り返ってみると、当初の仮説を超えてクライアントになるほどと言ってもらえるレベルの提案までを引き出せたケース、当初の仮説の正しさが確認できたというレベルの提案にとどまってしまったケースなど、実に様々なケースが存在します。
後者の場合でも「立案した仮説が正しかったのだ」と考えれば一概に悪いこととはいえませんが、「この提案がベストだったのだろうか」という意識はやはり前者よりも強く残ってしまいます。
今では、『前提条件を疑う』という作業を行うことができた場合には、少しでも前者に近い、仮説を超えた、より高いレベルの提案を引き出すことができるのではないかという気がしていますが、今回はこのポイントに気づくきっかけとなったケースの話です。
■ ケース概要
1. 課題が明確になっており、その課題の解決策を提案して欲しい
2. 目標は明確になっているが問題点がよくわからないので、問題点の抽出から課題の設定、さらにその課題の解決策までを提案して欲しい
コンサルティング業務の依頼には大きく分けて上記2つのケースがありますが、今回のケースは「業務の効率化のためにインフラとしてのシステムを整備したのだが、なかなか効率的にならないので何とかして欲しい」「課題はシステムへのデータ入力が進んでいないことだ」「データ入力を推進するためにはどうしたらよいかを提案して欲しい」という1の方での依頼でした。
■ ケースの進行
当該部署のメンバーを中心に、その部署に対する社内、および社外の関係者まで対象者を拡げたインタビュー調査を軸に業務は進みましたが、私たちの視点は当初から一貫して「どの段階でデータ入力が止まっているのか」「その阻害要因は何か」「どうしたら阻害要因がなくなるのか」というものでした。
インタビューを通じて、「データの入力という手間をかけても“効率化”という成果が実感できていない」「現場ではむしろデータを入力するという手間が増えただけという印象を持っており、負担感が増大している」というような状況が把握できました。
ここからは【実行戦略】の策定になります。「どうしたら現場の負担感が減らせるか」「データ入力を推進するためには何が必要か」というポイントの検討を重ねながら、整備すべき業務プロセスや必要な仕組みなど、より具体的な改善アクションまでのプランニングを行い、クライアントへの提案準備を進めました。
■ ところが……
通常のケースでは、策定した実行戦略の妥当性の検証を最後に行います。
“妥当性の検証”というのは私たちが策定したプランやアクションが実行に移され、それぞれのフェーズでの目的が達成された場合に最終的な目的は達成可能かどうかという視点からアクションと成果を積み上げていく作業になります。今回も報告会まで残すところあと数日という時点で妥当性の検証を行いましたが、どうも違和感が拭い去れません。
具体的なアクションは省略しますが、改善に向けた大まかな流れは現時点では以下のようになっています。
ケースの概要の部分ですでにお気づきの方もいるのではないかと思いますが、これではクライアントの最終的な目的（業務の効率化）を達成するのは難しそうです。
（つづく）
（この記事は2008年8月1日に初掲載されたものです。）
