ケンブリッジ語録#38 「答えるべき問」を設定せよ
僕が勤めるコンサルティング会社、ケンブリッジには、厳しいプロジェクトの現場で生まれてきた「語録」がある。
今回はこれ。
「答えるべき問」を設定せよ
僕らは普段変革プロジェクトをお手伝いしている。
変革プロジェクトは本当にやることが多い。全部やろうと思うと全く時間が足りない。優先順位をつけて効率よく、無駄がないようにタスクを進めないといけないのだが、これが難しい。
- 何を調査するのか
- どこまで厳密に調査するのか
- どんな分析をするのか
- 何が示唆として出せれば良いのか
- どこまで現場の意見を聞けば良いのか
- 施策の勝算はどこまで見極めるのか
- 現場への説明はどこまでやるのか
- 社長やステークホルダーに何をどこまで説明するのか
- こっちのタスクと、あっちのタスクどっちを優先させるべきなのか
- どこまでやったら調査完了といえるのか
- ・・・
どうすれば上手く判断できるのだろうか？これに悩んでいた頃、当時のプロジェクトのリーダーにこう言われた。
「結局さ、"答えるべき問"に答えを出すのが俺たちの仕事なんだよ」
プレゼンでも、討議でも、資料作りでも、分析でも、提案でも、プロジェクトでもなんでもそうなのだが、相手が抱くであろう素朴な疑問を考えて、それに答えられるように仕事をすればいい。という事だった。
「それが最も無駄がなく仕事するコツだよ。求める答えを出すために、最低限のことだけをやればよくなるだろう？無駄にやり過ぎることもなくなる。問に答えが出せるなら、それでいいんだから」とリーダーは説明してくれた。
・・・例えば、「PJのキックオフ」なら、参加者はどんなことを疑問に思うかな？
- 結局、前回のPJと何が違うの？
- 結局、3月末にどんな状態になっていればいいの？
- で、俺たち何すりゃいいの？
・・・だとすると、これに答えられるようにキックオフの準備をすべきだな。
例えば、「課題分析の報告」なら、社長はこんなことを疑問に思うだろうか？
- 結局、売上が1.5倍になったらウチのシステムは耐えられるの？
- 結局、うちのシステムの状態はいいの？悪いの？
- 結局、最も解決すべき問題はなんなの？
- で、なんでこんな状態になってるの？どうして改善できなかったの？
・・・だとすると、これに答えられるように分析を進めるべきだな。
という感じだ。プロジェクトではしょっちゅうこれを考えている。例えば、あるITPlanningのプロジェクトで書き出した「答えるべき問」はこんな感じ。社長への報告を意識して、社長が知りたいであろうことを想像して書き出している。
これが、「答えるべき問」と言っているものである。
ポイントは、
相手が抱きそうな素朴な疑問を思い描くこと
結局、何が知りたいんだろうか？
結局、何がわかれば良いんだろうか？
を考えること。
たまに、「相手が考えていることなどわかりません」という若手がいるが、もし相手が知りたいことが何か考えられないなら、非常にリスキーな状態であると自覚した方がいい。結局、プロジェクトだろうが、小さなタスクだろうが、全部に適用できる考え方だと思う。
コンサルタントIさんのコメント
今回の語録で思い出したのが、
PMの桑原さんが「振り返り」と称して、日報に問いを書きまくってたこと。
- 合宿が失敗するとしたら？
- ケンブリッジが最大の価値を出すためには何が足りてない？
- 根っこの課題は何だ？
とか、
問いは全部で30個くらいあった気がする。
正直、初めて見た時は「なんじゃこりゃ」と思ったけど、
あの問は「答えるべき問」だったんだなと思いました。
コンサルタント谷澤さんのコメント
これ、新宿のPJで実感しました。
社長報告に向けて、白川さんが10個くらいの本質的な問いを設定し、それに答えるための調査＆まとめ方をしました。
- 今までいくらかかったの？
- 続けた場合、中止した場合いくらかかるの？
- システムの品質はいいの？
- 結局このPJ続けたほうがいいの？止めたほうがいいの？
- ・・・
今振り返ると、調査対象が圧倒的に多い状況で、よくあそこまでFACT込みで整理できたなぁという感じです。答えるべき問があったらできたんだと思うのです。
「明確にこの問いに答えるために～な調査をして～にまとめる」というのが最初から見えていれば、当然効率的に進められます。この進め方を見て、上流フェーズの進め方が分かった気がします。
余談だが、ここで登場する白川は、オルタナティブブログで「プロジェクトマジック」の記事を書いている白川である。彼の記事は独特の切り口で面白い。
