別記事で、コンサルタントは「ロジックと数字」で語るという話をしたんだけども。
今回は、具体的な手法について説明するよ。
具体的な手法とは、ロジックツリーという手法だよ。
ロジカルな問題解決スキルを身に着けるメリット
まず、手法に行く前に、問題解決の概要を説明しよう。
コンサルタントに限らず、ビジネスマンは抽象度を上げれば、何かの問題を解決していて、それを「仕事」と呼んでいるだけなんだ。
で、その仕事＝問題解決に最重要なスキルの１つは、ロジカルな問題解決スキルってこと。
ロジカルな問題解決のスキルを身につけることには以下の４つの意義があるよ。
- 一生使えるスキルである: ロジックツリーや問題解決手法は、時代に左右されない不変的なスキルだよ。
一度学んで身につければ、一生つかえるのがいいところだよね。 - 全体を俯瞰できるようになる: ロジックツリーを使うと、問題の全体像が見えやすくなるよ。
問題を構造化し、各要素の位置関係を視覚化することで、重要な話題を見極めることができる。
問題が解決できないのは、問題の全体像が見えてないのが原因だからね。 - 「捨てる」能力が身につく: 現代は情報が多すぎて、選択肢の多さにみんな疲れてしまっているんだ。
ロジックツリーを使って可視化した後で、さらに重要度を判断する。
これで、不要な部分を捨て、重要な部分に集中することができる（２：８の法則）。
重要度が低い部分を明確に捨てることで効率的に仕事を進めることができるよ。 - 意思決定のスピードが上がる: 各要素の重要度を判断し、捨てることができると、意思決定が迅速になるね。
ノイズに惑わされず、的確な判断ができるため、仕事全体の質も向上する。
ちなみに「３」の選択肢の多さに疲れているというのはAmazonPrimeVideoなどのサブスクの仕組みからも理解できる。
ユーザには1つ1つの映像作品を吟味する時間がないから、アマプラで流行っている、おすすめ「してくる」ビデオを倍速で見て、一過性の「消費」をする。
おすすめしてくる作品が「世間的に」「間違いない作品」だと無意識に思っている。
世間的に正しいからといって、自分にとって正しいはずもないんだけど、それすら気づく時間がなくなるくらい、情報（映像作品）が押し寄せる。
でも、それを「消費する」ことをやって「しまっているし」、結果的に正しいことに「してしまっている」
映像作品を見ること１つとっても、自分で考えてないし、考える時間もない。
・・・ないというか自分でなくしてるんだけど。
このようにアマプラ１つとっても「選択肢に疲れてしまっている」「自分で選択してない」事がわかると思う。
スキル：ロジックツリーを使う場面
問題解決においては、様々なツールがあるけども、ここではロジックツリーを取り上げるよ。
また、ロジックツリーがITプロジェクトでどう使われるのか？についても触れておくね。
- 意思決定プロセスで使う: ロジックツリーは意思決定のプロセスを整理するために使用される。
たとえば、新しくITシステムを開発する際には、現状の業務ニーズ、他社とのプロセス比較・分析、今後の業務の在り方などの要素を考慮し、システム化の可否を判断するためのロジックツリーを作成する。 - トラブルシューティング: 技術的な問題のトラブルシューティングにおいて、ロジックツリーを使う。
例えば、開発中のシステムの障害（問題）を解決するために、問題の発生源を特定するための質問やチェックポイントを段階的に整理したロジックツリーを作成します。 - プロジェクト管理: ITプロジェクトの進行管理やリスク分析においても、ロジックツリーを使う。
プロジェクトの目標やタスクを階層的に整理し、依存関係やリスクの要素を明確にする。
これにより、プロジェクトの進行状況を把握し、3か月先に発生する可能性がある問題を先回りしてつぶしていける。
これらは一部の例だけど、ロジックツリーはITプロジェクトはもちろん、問題解決のさまざまな領域で有用なんだ。
例えば人生の、人間関係の問題解決にもつかえるんだ。
問題を整理し、ステップごとに分解することで、効率的かつシステマティックな問題解決ができるから、ロジックツリーは有用なんだよね。
ロジックツリーの作り方
ロジックツリーは基本的に次の手順で作っていく。
- 問題を項目（小さな要素）に分解する。
- 各項目について分析や数値評価を行う。
- 各項目の重要度を評価する。
- 重要な項目にフォーカスして行動計画を立てる。
このようなロジックツリーの考え方は、さまざまな本で説明されているから、コンサルティング会社に入らなくても、学生時代から学ぶことができるんだよね。
できるし、今はどうかわからないけど、私がコンサル会社に入社したころは、あまりに当たり前のことなのか、中途入社だからなのか、問題解決に関する研修もありませんでした。
だけど、今ではいくらでもネットや本で独学できるから問題ない。
ちなみに最後におすすめの書籍を説明するね。
ロジックツリーの具体例
実際のコンサルティングの現場でも、このようなベーシックな方法論を使って問題解決が行われているね。
コンサルティングの現場の例だとちょっとわかりにくいかもしれないから、「自宅でインターネットが使えない」問題を身近な例として、ロジックツリーの使い方を説明するよ。
例：あるインターネットプロバイダーのサポート部門では、顧客からのトラブル報告に対応するためにロジックツリーを使用している。
以下が具体例だ。
目的: 顧客のトラブルを迅速かつ正確に解決したい。
※補足 ロジックツリーを作成する目的を明確にする。目的が決まらないと何も決まらないからね。
０．主要な要素の特定: 顧客からの報告によくある問題の例を列挙する。
例えば、インターネット接続の問題、ソフトウェアのエラーメッセージ、ハードウェアの故障などなど。
- 階層構造の作成: 最上位の階層には、トラブルの種類やカテゴリを設定する。
下位の階層には、より具体的な問題・症状や解決手順が配置する。 - 条件とルートの追加: 各カテゴリに対して、問題を特定する条件を設定し、それに対応するルート（要素間のつながり）を作成する。
たとえば、「インターネットが不通の問題」には、ルートAとルートBがある。
ルートAは「モデムの再起動」という手順につながっていて、ルートBは「Wifiルーターの設定確認」という手順につながるって感じ。 - ツリーの展開: 各ルートに対してさらに詳細な手順を追加していくよ。
たとえば、ルートAの「モデムの再起動」の下位に、手順として「電源をオフにし、数秒待ってから再びオンにする」を追記する。 - ツリーの確認と改善: ツリー全体を確認し、必要な手順や条件が漏れていないか、論理的に整合しているかを確認する。
必要に応じて、ツリーを改善して洗練させる。
こんな感じでロジックツリーを使用することで、サポート部門は顧客のトラブルに効率的かつ統一したアプローチで対応することができる。
また、ロジックツリーに存在しない、新たな顧客の情報を入手したらツリーを更新し、より詳細な手順や幅広い解決策を追加することができるよ。
以上、ネット接続会社の例を挙げながら、ロジックツリーの具体的な手順を説明したよ。
要は、大きな問題を小さな部分に分解し、それぞれについて分析し、重要な項目を見極めてアクションに落とし込むという手順がロジックツリーということだね。
ロジックツリーの理解を深めたい
ロジックツリーに限らず、問題解決に関する知識は、本がたくさん出ているので、20冊くらい読んでみれば、本質を理解できると思います。
いやいや、20冊も読めない、時間がないという方には、様々な本の中から、個人的なおすすめを２つ紹介するよ。
するけど、1冊や2冊読んで理解したとは思わないことね。
ロジックツリーに限らず、問題解決のスキル自体、あくまで実践する過程で身につくものなので、とにかく1個でも使って試行錯誤する。
この点について、忘れないようにしてね。
それでは1冊目、「問題解決プロフェッショナル: 「思考と技術」 斎藤嘉則」だね。
古典的な1冊ですが、正直これ読んでおけば十分な感はあるね。
古典ゆえに若干小難しいところがあるかもだけど、買っておいて損はない1冊といえるね。
次に、1冊目がちょっと難しそう、読みにくそうと感じる方にはこちらがおすすめ。
「考える力をつける3つの道具」岸良裕司。
子供でも使える問題解決法の解説書だから、読みやすいはずだよ。
これはパッと見、こども向けなんだけど、子供でも誰でもロジックツリーは使えるし、問題解決できることがよくわかる本。
つまり、単純に知っているか、知っていないかだけの話なので、ぜひこの機会に「知って」ほしいと思うね。
ロジックツリーについてなら「ブランチ」のセクションだけでも読んでもらいたいね。
知識は使って初めて知識となる
で、知識として「知った」あと、どうするかといえば、もちろん実践だね。
ロジックツリーは小学生でも作ることは作れる。
だけど、ロジックが正しいか？は抽象度の高い原理原則を理解してる指導者からのフィードバックが必要だよ。
抽象度の高い原理原則を理解していないと、局所的には筋が通っているようでも、全体として間違っているロジックツリーが出来上がってしまうリスクが高いからね。
ちなみに、日本企業の賃金が３０年上がらないのは、ビジネス上、部分的なロジックの筋は通っているけど、全体最適の視点が欠落しているから。
つまり、OCであるオペレーションのロジックは間違ってないけど、SPである戦略がそもそも間違っているとか、ナイとかね。
さらにはフィードバックをする人がいない（いても煙たがられる、オレ流で自由にやりたい）から、ロジックツリーも作らないってこと。
でもね、他人のフィードバックがイヤってことは、自分の世界は広がらないということ。
フィードバックを自分の批判と受け取るか、そういう意見もあるんだなぁと興味深く受け取るかだけなんだけどさ。
まぁ、フィードバックできる視座が高い人が職場にいないから、職場フィードバックを求めないってのもあるけど。
今は、インターネットを使ってフィードバックできる人を探せるからね。
ちなみにSPは高抽象度、高い視座から見ないとわからないし、見えている人を見つけるのが難しい。
仮に「見えている」人がいて、こうだとロジックツリーを作っても、「見えていない人が多数」なので、民主主義＝多数決で負けるという構造があるよね。
そもそも、大体自分が正しいと思い込みがちだから、そんなフィードバックは的外れとか思われたりもする。
とはいえ、ロジックツリーを実践は大事だよ。
実践においては、自分で書きだすだけでも自分の考えが整理されるからいいんだけど、できれば、視点・視座の高い人からのフィードバックを受けると良いね。
特に新人の頃は、上司のフィードバックをどんどん受けると良い。
ロジックツリーそれ自体を作るスキルも大事だけど、ロジックツリーに限らず「フィードバックの受け方のスキル」の方が重要だったりするからね。
フィードバックの受け方が上達すれば、ロジックツリーを作るスキルは加速的に上がるから。
ロジックツリーそれ自体の知識を深めることに固執せず、実践に重きを置くようにしていこう。
では、今日はここまで。
お疲れ様でした。