課題を構造化する
こんにちは。出戻りガツオです。
久しぶりのアウトプット。コンサルタントとして日々奮闘しています。
今回は仕事の中で、クライアントの「課題を構造化する」を整理していこうと思います。
クライアントが抱える課題を解決するためには、
そもそも何に困っているのか、原因を構造的に把握することから始めます。
現場担当者の声を「具体的・抽象的」に理解することが、はじめの一歩です。
課題は一回聞いただけでは、根幹的な部分というものは見えてきません。
だいたい「あるある」のコトバを聞いて終わりです。
数回のヒアリングで、課題の真因が把握できれば苦労しません。
真因は細部に宿ります。
ヒアリングという対話の場は、何時間も設けられるものではありません。
そして現場担当者も貴重な時間を割いて、内容を説明してくださいます。
ヒアリングに時間を割きすぎて負担になることは本末転倒です。
こうした時間的な制約があるなかで解決策を考えるために、
クライアントと課題の理解を共有するため、「構造化」をすることが、課題解決の第一歩になります。
そもそもこの問題は、どうして起こっているの？どうすべきなの？という部分を洗い出していくことで、この「構造化」が達成されるといえるでしょう。
Example – メールで集めている申請情報の取りまとめに苦労している
業務改善のあるあるのテーマとして挙がるものをピックアップしてみました。
情報収集の媒体として、「メール」という手段は、あらゆる現場で採用されているかと思います。
便利なツールである一方で、メールは自由度が高すぎるという課題があります。
これに対し、「自由度が高すぎる媒体をやめて、フォームを設けよう」という考えは、誰でも思いつく手段です。
ここで思考を止めることは、課題の真因を止める要因になります。
なぜそれができないのか、多角的な視点で把握しなければ、クライアントにとって価値のあるアイディアにコミットできると言い難いでしょう。
頭にパっと思いついたアイディアにとらわれず、フレッシュな視点で課題を言語化することからはじめていきます。
まずは箇条書き
課題を構造化してとらえる最初の手段は箇条書きです。
箇条書きは、階層（レベル）があり、インデントによって（ざっくりいうと何か、細かい視点でいうとなにか）という抽象と具体を行き来する書き方になります。
・を用いて、箇条書きは書いていきますが、必ずインデントを活用して書いていきましょう。
スペースでインデントを設けるのではなく、Tabやスタイルを適切に使い、書いていくことが美しさにもつながります。
細かい部分に脱線してしまいましたが、「メールで集めている申請情報の取りまとめに苦労している」というケースを考えていきましょう。
ケースを考えるのは、ChatGPTにお願いしてみます。
コンサルタント：
「今日はお時間をいただき、ありがとうございます。お聞きしたいのですが、現在メールで収集している申請情報について、どのような点で具体的に苦労されていますか？」
クライアント：
「メールで申請書や必要な書類を受け取るのですが、その量が多く、一つ一つ開いて内容を確認し、整理するのが非常に時間がかかります。また、申請ごとに必要な書類が異なるため、漏れがないかのチェックも大変です。」
コンサルタント：
「理解しました。そのプロセスで、申請の種類をどのように識別していますか？また、受け取った申請情報をどのように管理しているのでしょうか？」
クライアント：
「申請の種類はメールの件名や本文で識別しています。受け取った情報は、フォルダ分けしてメールボックス内で管理しているのですが、これがまた大変でして…。」
コンサルタント：
「なるほど、非常に手間がかかっているようですね。申請の処理において、最も時間がかかる作業や最も効率化したい部分はどこに感じていますか？」クライアント：
「申請書類を一つ一つ手作業で確認し、必要な情報を抜き出してまとめる作業ですね。特に、情報がメール本文に直接書かれている場合と添付ファイルにある場合が混在していて、その整理が大変です。」
ほんとにあるあるですね（苦笑）
一旦ここまでの内容を構造化してみたいと思います。
構造化する
■ メールで集めている申請情報の取りまとめに苦労している
申請の量が多い
申請の種類が複数存在する
申請の種別は、件名と本文で区分けする
申請情報は一元化されていない
メール本文に書かれている場合と添付ファイルにある場合と混在
この整理はChatGPTではなく、私によるものです。
GPTにそれ以上やってもらうと、答えまで出てきてしまいそうですが、
自分が腹落ちさせた構造化ではないと、説明ができないため、徹底的に自分で構造化を実施します。
手段ベースで考えない
内容があるあるなので、「フォーム設ければいいのでは！」と手段から考えがちです。しかし手段から考えることは、アイディアを柔軟に考える原因になります。
例えば「フォームを設ける」前提で物事を考えてしまうと、「1. 申請の量が多い」、ここをどうするか、という部分に焦点が当たってしまい、ほかのポイントに対する考察が硬直化してしまいます。
構造化した課題を一つ一つ分析する
構造化した内容は、最下層レベルで何故そのようになるのか、すべて理由を明確にすることが良いです。
例えば「1. 申請の量が多い」は、そもそも何故多いのか？という原因を分析すると、「特定の属性の情報を運用に合わせて、個別に申請している」という、運用の課題が見えてくるかもしれません。
「2 - 1. 申請の種別は、件名と本文で区分けする」についても、「アナウンスして運用を統一すればいいのでは？」という思考に走り勝ちですが、今までできなかった理由があるから現在に至っています。
「運用変更のアナウンスを実施する」といっても、申請をしてもらう方の立場が様々になると運用を徹底していただくことも、人間的な衝突や難しさが生じたりするものです。
「3 - 1.メール本文に書かれている場合と添付ファイルにある場合と混在」こちらも上記と同様です。
「申請の種別が異なり、それに応じて添付ファイルの必要・不要が分かれている」
「運用を統一するための負担が大きい」
という課題が見えてくる可能性があります。
この部分を明確化しないことには、アイディアを考える材料が足りません。
ぼやけている課題をクリアにする
課題を構造化して分析することで、「何を理解する必要があるのか」という部分を明確にします。
次のステップは、この部分をクリアにすることです。
ここでそれぞれの課題に対し、「何故そうなるのか？」というオープンクエスチョンで突撃することは悪手です。
自分なりの仮説、「このような原因があるから解決にいたっていない」をもつことで、相手方が言語化しづらい場合に、「こういう課題を想定したのですが、いかがでしょうか？」といった、より具体的な深堀を実施することができます。
クライアントに言語化してもらうよう努力することも、コンサルタントの立場として必須事項でしょう。
高いフィーを払い、支援を通じた変革を期待されています。
他責になるのではなく、仮説を徹底的に考え、どんな状況でも課題の解決に向き合うオーナーシップが最も大切な姿勢と言えるでしょう。
ふりかえり
あらためて書き出してみると、基本的なことを抜けもれなく実直にやっていくことが、非常に大切だな、と自分自身感じます。
基礎をおろそかにすると予想外の手戻りが発生し、自分の首を絞めます。
自分で書いていて耳が痛いですが、誠実に細かいことをやっていくことが、課題解決の第一歩と言えますね。
そんな学びが多い毎日です。そんな学びの多い毎日を過ごす私と一緒に働いてみませんか！？
告知
とある日本のベンチャーコンサルティングファームでMicrosoft 365活用支援を実施するコンサルタントを募集しています！
Microsoft 365支援のみならず、ほかのサービスの活用支援など取り扱うDXコンサルティングを担う企業なので、Microsoft 365にとどまらず、ほかの製品のコンサルティングにチャレンジしてみたいかたも、ぜひ興味を持っていただければと思います。
私が主に来ていただきたい人材は、Microsoft 365支援に挑戦したい方です。
コンサルティング経験豊富な方であれば、それに見合うポジションもございますし、未経験でこれから挑戦したいという方も大歓迎です！
詳しい話を聞いてみたい方は、ぜひ出戻りガツオまでお声がけください！！
本の宣伝
今回は「具体と抽象」「仮説検証」というキーワードに触れました。
こういった内容は、どのような立場のビジネスパーソンにとって活きるスキルです。
下記の本がお勧めですので、ぜひ読んでみてください！
この記事が気に入ったらサポートをしてみませんか？