構造的思考はソリューションの積み木ではない(多分)という話

最近、「一点突破型の成果の出し方は、構造的思考ではたどり着けない成果の出し方なのではないか」という記事が出ていました。なるほどそうだなと思う反面、議論がソリューションに閉じているようにも思われました。そこで、経営に限らず課題解決一般についてのアプローチの仕方について述べつつ、「問題の構造化」について説明してみたいと思います。

良い戦略と忘れられがちな問題の構造化

とある目標を達成しようと考えるとき、多くの方法論が存在します。いわゆるフレームワークと呼ばれるものをあげるだけでも、5 forces, 4P, リーンキャンバス、ビジネスモデルキャンバス、PMBOK、BABOK、スクラムなど数え始めれば枚挙に暇はありません[入山, 2019, PMI  2021]。

色々な方法論があるときにどのように問題にアプローチすべきなのでしょうか。例えば、戦略論と経営理論の世界的権威であるリチャードらは、良い戦略の特徴を下記のように述べています[リチャード, 2012]。

良い戦略は、十分な根拠に立脚したしっかりした基本構造を持っており、一貫した行動に直結する。この基本構造を「カーネル（核）」と呼ぶ（中略）
カーネルは、次の3つの要素から構成される。
1. 診断 -- 状況を診断し、取り組むべき課題を見極める。良い診断は死活的に重要な問題点を選り分け、複雑に絡み合った状況を明快に解きほぐす。
2.基本方針-- 診断で見つかった課題にどう取り組むか、大きな方向性と総合的な方針を示す
3. 行動 -- ここで行動と呼ぶのは、基本方針を実行するために設計された一貫性のある一連の行動のことである。すべての行動をコーディネートして方針を実行する。

この診断から始めるという形式は多くの方法論で支持されており、イシュードリブン[安宅 2010]などでも採用されている考え方です。

一方で、「唯一の道具がハンマーだと、全てが釘に見える」という寓話があります[マズロー 1966]。認知バイアスの一種で、馴染みのある方法論を過信してしまい、どんな問題に対しても同じ道具を使ってしまうため、最適な道具の選択になっていないことがあるということを表現しています。私も昔はエンジニアだったので何となく分かるのですが、自分の得意な方法、自分のよく知っている方法で何でも作りたくなってしまうものです。

しかし、こうした認知バイアスに基づいて意思決定をすると、解くべき問題を間違ってしまったり、問題を解くことができなかったりしてしまいます。ハンマーでぶっ叩いて圧着したところで溶接の変わりにはならないわけです（分かりづらい例・・・）。

構造的思考から見たアート経営の課題感

柴田さんの考えによると、構造的思考とは目的までの積み上げ方を事前に考える方法論であるとし下図のような表現をしています[柴田 2022]。個人的感想なのであまり一般化できるものではないかもしれませんが、こういう話を見たときの第一印象は「問題を構造化できていない」です。

もう少し「構造化できていない」を掘り下げて考えてみましょう。ぱっと思い浮かべるのは下記です。

• ソリューションの積み上げになっていて、解くべき問題が明確ではない。

• 一見すると目的を達成していそうに見えるが、十分なソリューションが充てられているかがわからない（後々問題を起こしそうに見える）

• 問題の構造を共通認識できておらず、組織的な力を借りづらい状態であるように見える

特に問題なのは2点目、3点目かと思います。2点目は「できていたはずなのに、リリース寸前に問題が発覚しプロジェクトストップ」ということが置きます。「そんなことなかなかないだろう」ってお思いかもしれませんが、僕はしょっちゅう見てます（問題があるところにしか呼ばれないので宿命的によく見てしまう・・・・）。最近あった例だと、外注丸投げで構築してしまったので本当に正しいのかがよくわからず検収できないだとか、リリース後の運用が未定で運用体制が拡充するまでリリースが止まるとか、そういう小さいレベルから、リリースしようとしたら監督官庁に怒られて頓挫まで様々です。

3点目は即座に問題にはなりませんが、永遠にやめられない社長が爆誕します。社長にしか見えない問題があり、それを社長のアート力で解決してしまうので、周囲の人間との共同作業が非常に困難ですし、結果的に社長が指示しないと周りが動けなくなるので自主的な行動を期待することができなくなります。おそらく上場くらいはできると思うのですが、どこかで企業の成長が頭打ちになります。

3点目はもしかすると周囲のステークホルダーの説得にも支障をきたす可能性があります。人をみて投資するタイプのVCから調達することは可能でしょうが、一定程度の時価総額（たとえば3000億円とか）を超え始めるとそれ相応のイクイティ・ストーリーが求められます。時価総額が増して公共性が高まるほどに、アートでは済まない世界がやってきます。

診断を通して問題の構造化

では具体的に問題の構造化とはどうするのでしょうか。僕は3ヶ月くらでぱぱっとできるんですが、できないひとは1年かかっても全くできないので非常にアート度が高いのかなと最近思っています。

実例をベースに個人的にどうしているかを解説しようかなと思います。基本的に内容は案件マターなので全部ぼやかしています。

こちらはとある案件で「問題がなにかもよくわからんのでどうにかして」（意訳）と言われた際に、組織問題を分析して問題を構造化しソリューションを提案したケースです。

とりあえず、診断をして問題を明らかにしないことには始まりません。ザーッとヒアリングして100件くらいコメントを集めます。中身は意見・感想・事実などがまんべんなく混ざるのですが、できるだけ事実を集めます。ヒアリングの仕方の詳細は今回触れませんが、だいたい「そう感じたきっかけは何でしたか」「それによってどういった影響がありましたか」を地道に聞き続けます。割とこのヒアリングもアートな感じはあります。

で、いきなりですがこんな感じに集約します。図の見方としては、ヒアリング結果から見えた問題を左側に記載、その問題を引き起こしていると考えられる共通課題の仮説を中央に、それをどういう姿に持っていくべきかを右側に書いています。

これによって、主要だと思われる問題の合意、その根本的な課題、それをどう対処すべきかの3点をステークホルダーと合意します。本当に問題はすべて網羅されているか、何をスコープアウトしたのか、本当に課題を解決すると問題が解決するのか、あるべき姿のイメージはあっているか、こうしたところを議論して問題と課題仮説を合意します。

こうすると、右のあるべき姿が実現すれば、真ん中の課題は解決し、左側の問題も解決していく・・・という構造が出来上がります。この問題・課題仮説の構造が肝なんですね。

ここで一つポイントは、まったくもってソリューションの話はまだしていません。どういう問題があって、なにが根本課題なのか、なにを目指すべきなのか、そうした話だけをしています。純粋に問題だけを見つめて、どうとくかは考えない。まずは問題の診断だけをする。こういう「ネガティブ・ケイパビリティ」がここでは求められています。

ソリューションは構造化された問題に枠組みとして充てる

ここでようやく初めて問題をどう解くのか、ソリューションの話をします。柴田さんの記事[柴田 2022]では、解くべき問題や課題とソリューションを区別せずに論じていますが、解くべき問題を過不足なく考えるためにはまず問題を構造化することが何よりも先決です。

ソリューションは前段でまとめた「あるべき姿」を目指すためにどういう順序で何をするのかという形でまとめます。明確に期間を書いていないですが概ね1年がかりで実行するようなイメージになっています。

このソリューションは時間が立つにつれてどんどん変化します。というのは、ソリューションを実行するうちに新しい知見を得られたことで問題の解像度が上がったり、新しいソリューションの知見が得られたり、ソリューションの実施難易度が変化することがあるからです。

柴田さんの記事[柴田 2022]でいうと積み木がこれに当たるのかなと思います。どういう順序でどうゴールに積み上げていくのか。それは最後の最後に考えることなんですよね。しかも、このソリューションは「予定は未定」です。こうつなげていけばできそうだよね？という仮説に過ぎません。しかも、中身についてもかっちりは決めません。枠組みとして「こういうアウトプットがあれば前進するよね」という話を書くだけで、具体的なやり方については言及しません。ここでもネガティブ・ケイパビリティが活躍します。

構造的思考の利点①：全体像仮説を共有することができる

ここに至るまで誰が何をどうするかの具体を全く考えないできました。ソリューションも期待アウトプットのみで、具体的なアクションは不明です。一方で、問題を解決するまでに必要な手順についてはみんなが共通理解し合意できる形になりました。これが利点の①です。

こうした全体像があれば、今我々がどこにいて何をなすべきなのかについて知ることができます。ステークホルダーがいれば彼らに状況を説明することもできます。今後の動き方の具体はよくわかりませんが、方針や今の立ち位置については見えることでしょう。

構造的思考の利点②：協力を得ることができる

一人の力では大きな問題の全体像を知ることは非常に困難です。なので、まずそもそも論、複数人の問題認識を揃える必要があります。この協力は必要です。

次に、複数人の知恵を借りることができます。どんなにバカバカしいと思えるアイディアであってもインパクトのある結果をもたらすケースはまぁまぁあります。問題の根本課題の仮説の妥当性について複数人で議論することは、問題を多面的に捉えることができ、あるべき姿の精度を高めます。

そして、ソリューション。もし、あるべき姿の合意が得られれば、ソリューションについてみんなの協力を得ることができます。ほしいアウトプットの精度が上がるほどにみんなの自主的な活動を期待することもできます。

このように、多くの人の協力を得る上で構造的思考は必須です。

構造的思考の利点③：迷子になりにくくなる

一定規模以上になると何がどう変わったかを知ることは非常に困難になります。企業活動というのは変化し続ける迷路の中でゴールを探すような活動なので、一人の視点で全体像を把握することは困難です。

こうしたときに、構造化された問題・実施するソリューションの予実・その差分がわかると非常に見通しが良くなります。多くの人からフィードバックをもらい構造化した問題・ソリューションに反映することで、戦略の全体地図の現状を知ることができます。

この全体地図が明らかになることで、個々人は確信を持って次の一手を打てるようになっていくし、メンバーの自発的な活動を促すことも可能になります。

仮説構築と合意形成があっても一点突破はできる

ソリューションと課題・問題を混ぜて論じると非常にややこしくなるんですが、問題だけの構造化というのは結構あっさりできます。構造化したところで仮説でしかないのでそういう割り切りのもとで走れるかというのが唯一のネックです。

具体を決めずに仮説ベースだけで全体を一気に構築できるか、個人的にはここがネガティブ・ケイパビリティの真骨頂なのかなというふうに考えています。ソリューションがわからなくとも、何が問題か何が問題かもわからないのかといったレベルの問題は全部書き出せるわけです。走りながら、問題の構造の精度を上げ、ソリューションの精度を上げ、実行結果からフィードバックする。これを繰り返すためにも構造化は必須です。

もちろん、初手は全く何も知識がないだろうから「何が問題かを明らかにする」問題くらいしか書けることがないでしょうけども、走るごとに問題の解像度は上がっていくはずです。問題の解像度が十分に上がったところから順番にソリューションと具体アクションを手当すればよいのです。

このように構造的な問題の把握と合意形成、一点突破は全部両立させることができます。Leanの言っていることも結局これですよね。

トップの一点突破は必ずしも良いことではない

なにしろトップしかできないのがネックです。誰の理解も協力も必要としませんが、誰の理解も協力も得られません。トップの限界が組織の限界になってしまい、超人的個人を仮定しないといけなくなります。

議論の解像度を意識してみませんか

これ結構できない人多いんでおそらく用意ではないんでしょうけども、問題とソリューションは分けて論じないとだいたい会話が成立しません。ぼくも、エンジニア的立場で行くと「え、それどうすんの？」って言いたくなるんですが、ソリューションはそれを話すべき場で話するのが良いでしょう。

一方で、問題の方も同じ解像度で話しなければなりません。全体像を話ししているのか、個別の具体問題について話ししているのかでは全く解像度が変わります。中計のはなししているのに来月の話ししたところで会話は成立しないでしょう。

経営者の一点突破は時として重要ではあります。なによりもスピードが出ることが一番のメリットです。しかし、そればかりではいつまでも周りに指示し続ける状況が続いてしまいます。

一方で、トップと話するときにはどうでしょう。全体像の仮説はぶっちゃけ誰でも建てることが可能です。なので、トップが説明してくれないなら書いちゃえば良くないですか？僕はいろんな会社の話を知っているのでなんとなく直感でピャッとかけるので結構アートな領域である点は否めないですが、そこそこ合理的思考があれば誰でも書けるものです。このときに個別具体の話はおいておいて、ざっと全体像を1枚に収まる程度の範囲に書いてしまうのがコツです。それ以上は細かいので話ししても多分刺さりません。

話の解像度を意識して会話してみませんか？