僕自身はざっくりしたクライアントの要求を明確で具体的な要求に落とし込んで、こちらがどんな解決策を提示する必要があるかをリストアップするところがメインの仕事だったりするのであんまり困ることはないですが、まわりを見てるとそういう場合にどうしたらよいかわからず悩んでしまうことはよくあるみたいです。まぁ、だからこそ、僕の役割があるんですけど。
でも、そうはいっても身体は１つなので、ざっくりした要求に対する適切な解決策を見出すための基本的な方法についてまとめてみます。
ざっくりした要求に適切な解決策を見出せない理由
ざっくりした要求に適切な解決策を見出せない主要な理由を3つあげるとしたらこうです。
- 問題の一部しか明示されておらず、全体の構造が見えなくて何が問題なのかを把握できていない
- 解決策に関する知識が不足していて、問題解決に必要な要素がリストアップできず、そのため最終的な解決案にまでたどりつけない
- 問題とその解決策の関係性がよく理解できていない
ようするに問題と解決策の構造化がうまくできずに「わからない」という状態に陥ってしまってるんです。
なので、この構造化ができるようにならないと、ざっくりした問題に対する解決策の提示っていうのはできるようにならないわけです。
問題を構造化する
クライアントがざっくりしか要求しないのは、なにもめんどくさがってそうしてるわけじゃない場合がほとんどです。要求がざっくりしている理由としては、クライアント自身が問題の構造をきちんと認識できていないか、クライアント自身にとってはその問題が存在することが当たり前すぎて明示できない場合があると思います。なので、問題の一部しか明示されておらず、全体の構造が見えず問題の構造が把握できない場合は、明示されていない問題を見えるようにすることが重要です。
まず１つやるべきことはクライアントのビジネスを理解することです。クライアント自身にとっては当たり前すぎて言及できない問題はこれで発見できることが多いです。空気の薄い高地に暮らす人にとっては当たり前の酸素の薄さも、部外者である僕らがいけばすぐにそれと気づくようなものです。それにはクライアントの環境を知ることが大事です。
クライアントの環境を知るには、いくつか使えるフレームワークがあります。
- 3C分析（Customer、Company、Competitor）
- 5 forces model（1.業界への新規参入業者の脅威、2.業界への代替製品の脅威、3.供給業者や仕入先との交渉力、4.買い手や顧客との交渉力、5)既存業者間の自社との競合）
- SWOT分析
- バリューチェーンによるビジネスモデルの把握
など。
こうしたフレームワークを使ってクライアントのビジネスとそのビジネス環境を知ることで、一部しか見えなかった問題のほかにも問題点が見えてくるようになります。また、その過程でクライアントに質問を行う中でクライアント自身がこれまで気づかなかった問題点を発見することもあるでしょう。
そのような形で問題の構造を把握することがまず第一歩です。
解決策をリストアップ～構造化する
どういうわけか、世の中、自分のできることは知ってるけど、自分のまわりができることを意外に知らない人が多いです。よく知らないけど、なんとなく知っているというレベルですらなく、ほんとに自分のまわりの同僚がどんなことができるのかをわかっていない人が多かったりします。自分の会社のサービスを知らなかったり、自社のものではなくても自分が関わる仕事の周辺のサービスを理解できていないと、問題点がはっきり明示できてる場合でもそれをどう解決していいかの答えが出せません。
これははっきりいって単なる勉強不足です。
自分の仕事だけにしか興味をもたず、その周辺のサービスを見ようとしないために、より統合的な解決策を提案できないというのは怠惰や無関心がもたらすものという以外に言葉がありません。
それでは確かに「ざっくりした要求に適切な解決策を見出す」ことはできないでしょうし、要求が明確な場合ですら適切な解決策を見出せないことが非常に多くなるでしょう。
なぜなら、それだけ視野が狭く、それゆえに価値が低いということですから。
自分たちの価値を高めるためには、自分たちの仕事をどう定義するかを市場のニーズからきちんと考えなくてはいけないのだと思います。自分がいまやってる仕事からあいまいに決めちゃうんじゃなくて。
そういうことにならないためにも自分が関わる仕事（作業ではなくて）の周辺のサービスのことは社内外含めてちゃんと知っておいたほうがいいと思います。調べようと思えば、そんなのいくらでも調べようがありますからね。
問題点に対して適切な解決策を提案できない
3つ目の問題はかなり実践的な問題です。問題の構造化はできた。解決策のリストアップ、構造化もできた。しかし、その両者を現実に結びつける際には、数多くの制約事項が存在するはずです。納期、コストをはじめ、人的問題、物理的な環境やリソースの問題など。
これらの制約事項に対し、どの問題を優先的にとらえ、またコストや納期の面からどの解決策を優先し、そこからもれたものに関しては次期フェーズ以降でどのような対策をとっていくのかをデザインするのは結構、経験もいるし、そのプランをFIXするための交渉力も必要となってきます。
ほんとにこの部分はむずかしくて僕自身も常にうまくやれるとは限りません。
ここは本当に実践的なスキルが要求されるところですが、1.や2.の部分の構造化がある程度はっきり明示できていれば、すこしはこのプロセスもラクにはなります。
一番ややこしいのはお金や時間より人ですので、ここをうまく押さえるのが重要だなといつも感じます。
だいたい、こんなようなことができるようになれば、クライアントのざっくりした要求に対しても適切な解決策を見出すことができるようになると思います。
結局、きちんと情報を構造化して、それを具体的な実行案へとデザインしていくわけです。これもある種の情報デザインだと僕は思っています。
関連エントリー
この記事へのコメント