【東工大生×Webサービス開発者】のブログ

Webサービスを個人開発しました。大学生活と良質しながら、開発や運営のなかで、記事にしたいものを発信します。

【考える技術・書く技術】を読んで、研究に役立てたい大学生の書評④

本編は【問題解決の技術】パートです。

 

 

8.問題を定義する

問題解決の基本的なフロー

まずは、問題解決(自分は単一の解がない状況に対して、同アプローチするか、だと思っている)の全体的な流れを説明したい。

 

文書を書くときに限らず、この点をフローに常に従って問題に取り組む習慣をつけることで、効率的に問題に取り組むことが出来るだろう。

導入

問題解決にあたり、聞き手に対して●●を改善すべきだ!、とアドバイスしても納得は出来ない。

まずは、相手と自分の情報格差をなくす、言い換えると前提を共有する必要がある。

さらに、その前提から共通の疑問点を導き出すことで、初めてその解として、●●を改善すべきだ!、と言えるのである。

 

この導入部は、前回述べた現状-複雑化-疑問の流れにのっとればいい。

既にまとめている内容であるので、深くは突っ込まないようにする。

 

現状と理想の定義

次に、今の現状/理想を定義する。

ここでいう現状は、その通り【現在置かれている、何か問題が起こっている状況】である。

前述の複雑化によって想起される疑問、問題とリンクしていることがMustである。

 

次に理想を定義する。

この理想とは、現在の問題を解決してどうなっていたいか、である。

言い換えると、現状の問題を解決した先にあるゴールである。

 

この2つは、言葉の意味をただ説明しただけなので、あまり参考にならないかもしれない。

 

問題定義

最後に、R1-R2の構造のどこに問題があるかを定義する。

これは前述のプロセスを経れば、自然と想起される。

 

たとえば、

・R1-R2の間が分からない(どうすればR2にいけるか)

・R2が分からない(何を目標にすればいいのか)

・R1が分からない(現状分析が出来ていない)

・解決策はいくつかあるが、失敗した(なぜ失敗したのか)

といったものである。

 

このように問題をしっかりセットしたうえで、本論のTop-Messageとして議論を展開すればいい。

 

 

 

 最後に、この一連の考え方についての例を示す。

ちょうど今、サイゼリヤでこの記事を書いているので、なんとなくこの店舗について思った課題感を勝手に書かせてもらう。

 

このサイゼリヤA店は一般的なサイゼリヤと同じく毎日営業をしていて、ランチ・ディナータイムの客数は70人程度であろう。入学時からではあるが、この店舗の人手不足やスタッフへの教育不足は客である僕にも散見できるレベルであった。

しかしここ最近、このサイゼリヤの人員不足が急激に加速しているように感じる。具体的には、従来はすぐに来た料理が来ない/走ってオーダーを取りに行く従業員の方/会計時の致命的なミスが多くみられるようになった。

人員不足と前述の問題が関係しているとして、どのようにすれば人員不足を解消できるのであろうか。

 

現状: 十分に活躍できるバイトが5人程度足りていない

理想: 現状の人員不足を解消し、各シフトを5名程度で回す。

 

問題の構造としては、R1を正しく認識しており、R2も定義できているので、あとは解決策がないということになる。

つまり、この文章の問題定義としては【どうすればバイトを雇い、人員不足を解消できるのか】である。

 

ここまでくれば、あとは前述のピラミッド方式でこの問題に取り組めばいい。

 

以上、8章のまとめとしては【どこに問題があるのか定義せよ】ということである。

 

 

 

9.問題分析を構造化する

調査から始まる問題解決は愚行である

この本に限らず’イシューから始めよ'でも紹介した通り、何か問題を解決しようとしたときに、まずリサーチから入ることは愚行である。

これは、以下の理由の通り、時間がかかりすぎて非効率だからだ。

・仮説なきリサーチは何を調べたいのか、が明らかにならない

・いきなり膨大な情報を集めることは時間的/労力的に無謀

・イエスかノーか分からない

・そもそも何をもって根拠とするのかを決めていないと終わりがない

 

とはいえ、教育に恵まれた超天才でもない限り、【リサーチから始める癖】が我々には根付いている。これには最大限の注意をしなければならない。

思考のクセ、をつけることが出来るかどうかが大事であるように感じる。

 

仮説設計のための構造化分析手法

ここではリサーチ前の仮説をどう定めればいいのか、ということについて考える。

これにはフレームワークやプロセス図を用いた、問題の構造化といった手法が推奨されている。問題を全体的に眺めることでMECEに考えたり、ボトルネックを推定することが比較的容易になるからだ。

以下では、様々な構造化の手法を紹介する。

 

プロセス図

これは、カスタマージャーニーやサプライチェーン等、初めから終わりまでの全体の流れを図式化するということである。

AIDMAなどは、これの典型例である。

 

因数分解手法

これは、大きな要素を細かく細かく区切っていく手法である。

例えば、

・純利益 = 売上 - コスト

・売り上げ = 客数 × 単価

・単価 = テイクアウト + 店内

というように、どんどん細かくしていく手法である。

 

これは突き詰めていくと、トーナメント票の様な状態になる。

 

以上の2つが、大きな構造化の手法であるように感じる。

正直、後者についてはさらに膨大なフレームワークがあるのだが、ここでは自分の役に立たないので割愛する。

 

課題深堀のためのロジック・ツリー

構造化ののち【ここがボトルネックだ!】というようなポイントを見つけたならば、さらにその仮説をシャープにする必要がある。

具体的には、リサーチでイエス/ノーに絞れるだけの粒度の仮説にする必要がある。

 

そこで有用な手段が、Whyを追求するロジックツリーである。

例えば、サイゼリヤの人員不足について解消する方法を検討したとして、オーダーから料理を配膳するまでのプロセス図を眺めていると、どうもキッチンの料理を作る段階にボトルネックがあり、キッチンを増やせばいいのでは、という仮説が生まれたとしよう。

もっともらしい仮説は生まれたが、まだリサーチできるレベルには落とし込めていない。

そこで、Whyのロジックツリーを作るわけだ。

サイゼリヤのオーダー解消のためにはキッチンを多く採用すべきだ

理由1:料理に対するオーダーが渋滞しているため

理由2:キッチンには十分な空きスペースがあるため

 

これなら、仮説の検討は十分にできる。

 

以上が問題解決に対する一連のプロセスである。

まず、全体を構造化してMECEに眺める、その中からボトルネックでありそうな部分を決める(この決定の精度は知識に依存するはず)

次に、その仮説をロジックツリーで深堀する。

最後に仮説の検討を行う。

 

 

以上が問題解決のパートである。

正直、イシューから始めよに似ていたので、そこまで詳しくは書かなかった。

 

自分にとって大事であるのは、この思考のクセをつけることができるかどうかである。

 

 

本記事は以上となります。

長文をお読みいただき、ありがとうございます。