![見出し画像](https://assets.st-note.com/production/uploads/images/30499585/rectangle_large_type_2_e2bdb75c430fa270c351b0166bca2cfa.jpg?width=1200)
思考を構造化するために②:先々を考えて、使えるカタマリを探す
前回は、思考の構造化のためのファーストステップとして、「問題を洗い出す」という部分について解説しました。
今回は「問題を切り分ける」という部分について考えてみましょう。
ーーー
有料note(100円)ですが、最後まで無料でお読みいただけます。ご購入いただくと、僕のnoteがプレミアムにアップグレードされ、予約投稿が可能になり、定期更新が捗ります。
ーーー
「分類する」とはちょっと違う
切り分ける、と似た概念として、分類する、というものがあります。
分類は、前回ご紹介したようにフレームワークとかを使ってグルーピングすれば、ある意味では「綺麗に分類された状態」になります。
ただ、これだと、構造的に物事を捉えるという話とは少しズレが生じます。このあたりは、僕もまだうまく言語化しきれていないのですが「分類・整理する」というのは、単に、ラベリングしたりグルーピングしたりする行動なんですよね。
切り分けは、もう少し、意図や意思が入ります。何を言っているのかと言うと「解決しやすそうなカタマリ」「一括りにしておいた方が取り扱いやすいカタマリ」にする必要があるんですよ。
僕が、最初にこのズレに気付いたのは、某コンサルファーム在籍時の海外研修で、外国人のメンバーと一緒にグループワークをしたときでした。
テーマは忘れましたが、とりあえず、何かの事業に関して、イシューツリーを書いて、それに対して解決方針を導き出す、という、まぁ、わりとオーソドックスなロジカルシンキングトレーニングです。
が、外国人のメンバーと、全く話が合わない。なんて言うんですかね。出てくるイシューの粒度がバラバラなんですよね。で、中には、そんなのイシューとして取り上げて、細かく掘り下げても、解決策なんて出てこないじゃん、みたいなものが山ほど含まれている。
僕ともう一人の(彼は超優秀でした)日本人で、これは違うだろう、と困り果てつつ、拙い英語(もう一人の彼の英語はまっとうでした)を駆使しながら何とか認識をすり合わせようとトライしたものの、まったく話が通じず途方にくれていたんですが、その謎は昼食後に解けました。
昼食後、午前中に書きだされた(僕らからすると)ぐっちゃぐちゃのイシューツリーに対して、ソリューションを出してシナリオを定義しましょう、という段になったわけですが、その団になると、彼らは「これは関係ない」「これは優先度低い」「これは難しいから忘れる」と、ばっさばさと目の前に書かれたイシューを切り捨てていったんですよ。
いや。ビビりました。まぢかよ、と。「そのイシューツリーにはゴールイメージが無いだろ!」という僕らの認識は合っていたんです。単に、「彼らはゴールイメージなんてものは必要ない」と思ってたわけです。そりゃ話が合うわけがない。
この話からの学びとしては「ゴールイメージが無くても、問題が解決できればいいんだよ」、、、となってもよさそうなものですが、そんなことにはなりません。無理。絶対無理。あいつらと一緒に議論できる気がしない。欧米人とはソリが合わん
僕たちは、それは美しくない、と思うのです。誰かと議論し、認識を合わせて、納得感を醸成していくことは、極めて大切です。
そのためには「なんとなく分類されている」ということではなく、「意味のあるカタマリに切り分けられている」といことが重要なポイントになります。
扱いやすい=次のステップで使いやすい
シュッとした見た目の欧米人コンサルタントへの怨嗟の気持ちがあふれ出て、前段が長くなりましたが、僕が言いたいのは「次の作業や、次の次の作業を見据えましょう」ってことです。
上述の例だと、後で解決策を導き出していくわけですから、解決策をイメージした状態でイシューを整理すべきなんです。
こういう場合、論点となる要素としては「洗いだされた問題」「本質的な課題」「課題に対する解決策」の3種類があるはずなんです。
先ほどの、欧米コンサルタントは「問題」を列挙してイシューツリーを組み立てたんですよ。で、いきなり「実施可能な解決策」「効果のありそうな解決策」を当て込み始めた。
僕ら(=僕ともう一人の日本人コンサルタント)は、「問題」の裏側に潜む「課題」をイメージしてイシューツリーを考えてたんですよ。なぜなら、次のステップで「解決策」を考える際には、「問題」ではなく「課題」を解決することを重視するはずだからです。
もちろん、それが唯一無二の正解だというつもりはありません。が、少なくとも、日本企業で事業開発・運営に携わっている方達との議論においては、僕たちのやり方の方がフィットします。同じベクトルで議論を行うことが可能となり、納得感をもって結論までたどり着けます。
解決につながるカタマリを見つけよう
話がふわふわしすぎてますよね。そろそろ、具体例を挙げてお話しましょう。
例えば、zoomのセキュリティ問題が発覚し、利用禁止にすべきじゃないか、というお話が盛り上がったことがありましたよね。あの時、僕が最初に思ったのは「取り扱う情報の ”秘密度合い” の切り分けを行うべき」でした。
僕の中では「ガチ秘密、秘密、できれば隠したい、最悪漏れてもいいか、公知の情報」の5段階くらいに分けるべき、と思っていました。
いわゆる機密情報と呼ばれるものは、ガチ秘密、でしょう。役職ごとの人員数や拠点別の人員数などは、秘密、か、できれば隠したい、のあたり。社内の組織図とか部署名とかは、できれば隠したい、か、最悪漏れてもいいか、あたりでしょうね。会社の住所・電話番号は公知情報です。
今回の話だと、web会議で、どのレベルの話をしているのかによって、zoomを使ってよいかどうかを変えればよいはずなんですよ。
で、まぁ、多くの場合、せいぜい「できれば隠したい」くらいまでの情報で会議って行われてるんですよね。本当に漏れたら困るような内容が、どの程度あるのか?という話がもやもやしたまま「zoomは危ないから禁止」とかって話になりがちです。
そうすると「セキュアな方に寄せる方が良い」ということで、zoomは危ないから全面禁止となる。不便だ。作業効率落ちる。でもルールだから仕方ない。というお話になる。こういうのが嫌いなんですよ。
まず、最初に「適切な打ち手に繋がりそうな単位で、取り扱う情報を切り分ける」ということを行うべきです。全面禁止もオールオッケーも芸が無い。イチゼロでいいなら猿でも決められます。灰色のグラデーションの、どこに線を引くのかが知性の見せどころです。
※当たり前ですが、そもそも「zoomがどの程度危険なのか」によって、どこまではzoomがOKで、どこからがNGなのか、も変わります。
別々のものを、安易に混ぜない
切り分けられないまま、議論が進むものは世の中にたくさんあります。思いつくままに上げてみましょうか。
■ PMの仕事とPMOの仕事
■ 基幹系業務と情報系業務の切り分け(システムは分かれてると思いますが、業務を混ぜちゃってるケースは多いです)
■ アイデアと要件
■ 社会人常識の話と、クライアントフェーシング上の心得
■ 利用シーン と 機能説明
■ 便益 と 機能
こういうのって、しれっとまぜこぜのままで、”タスクリスト” とか ”改善施策” とか ”機能要望” とかいうタイトルのリストになってるんですよ。で、「んじゃ、あとよろしく」って渡される。
アホかと。
明らかに別のものを、同じカゴに入れてはいけません。渡された方は混乱します。
意識して、目的に沿う形で切り分けましょう。完璧じゃなくてもいいです。ただ、トライしましょう。
お客さんも混ぜてきます。上司も混ぜてきます。部下も混ぜてきます。そういうものです。歴戦の欧米人コンサルタント*でさえ混ぜてくるんですから、仕方ないんです。
仕方ないからこそ、僕たちが防波堤になりましょう。議論の海が大荒れになり、甚大な被害を引き起こすのを防ぐんです。
*:ちなみに、各チームに、それなりにえらい人も混ぜ込まれた「疑似プロジェクトチーム」形式でのグループワークだったんで、ホワイトボードの前に立ってたのはアメリカ人のシニアマネジャー級だったことを付記しておきます。
大前提は「しっかりと問題が洗いだされている」こと
しかしながら、今回述べている切り分けの話は、大前提として「問題の洗い出しが完璧だ」という状態になっていないと成立しません。
そういう意味では、例の欧米人コンサルタントたちは「洗い出す部分」に注力していたとも言えます。そして、限られた時間内で、スキルレベルもバラバラな疑似的な部下たちを束ねて結論を導き出すという目的においては、件のシニアマネジャーは「自分の中で落としどころがあれば、好き勝手語らせておいて、最後はまとめちゃえばいいや」という気持ちだったのかもしれません。(それに、所詮はトレーニング、だしね)
そんなわけで、10年どころじゃないくらい過去の自分の視野の狭さを反省したりもするわけですが、それはそれとして、しっかりと問題を洗い出し、それを上手に切り分けて、構造的に物事を把握することに、注力していきましょう。
構造的に整理すれば、誰かと会話や議論をする際に、ミスコミュニケーションが格段に減り、結論に素早くたどりつくと共に、その納得性は格段に向上します。ぜひ、お試しあれ。
ここから先は
¥ 100
いただいたサポートは、このnoteで紹介する書籍の購入に使わせていただきます。