問題解決のフレームワーク

私はエンジニア兼DXコンサルとして現在働いていまして、エンジニアとコンサルとで頭の動かし方がだいぶ違うなと感じていました。このままでは両者の溝は深まるばかりだと思い、コンサルが使うフレームワークの中でも汎用的な「問題解決のフレームワーク」について、エンジニア向けに社内で勉強会をしました。
概略を図にすると以下のような感じです。このフレームワークを理解すれば、正しい質問ができるようになります。この記事では、問題を解決するための正しい質問とは何なのかについてまとめました。おかしな点がありましたらコメントいただければ幸いです。

よくある間違い

「どう」ありき

フレームワークを見るとわかりますが、「どう問題を解くか？」という質問は１番最後の段階でします。
DXでよくある間違いが、まず「どうするか？」を考えてITツールなどの方法を導入しようとすることです。「どうするか？」は具体的な方法を決めるための質問です。その前に決めないといけない抽象的なことがたくさんあるのに、具体的な方法に目を向ける人があまりに多いです。DXのような複雑な問題解決では「どう」ではうまくいかないことが多いです。なぜなら、有効な方法はその前の質問（なに　どこ　なぜ）によって決まるからです。「なぜ」がわかれば「どう」はほぼ自動的に決まります。「なぜ」に対して答えや推測が出ないうちに具体的な「どう」には進むのは得策ではありません。
個人的な悩みであっても同様で、「あのときどうすれば良かったんだろう？」と考えても有効打にならないことがほとんどです。問題解決のためにまず考えたほうが良いのは、もっとフレームワークの前の段階（なに？どこ？なぜ？）になります。これは未来についても同様です。「今後どうすれば良いのだろう？」と考えるのなら、それ以上に「そもそもなにが問題？」「どこを改善すれば良い？」「なぜそれが問題なのか？」も考えたほうが効率が良いです。

正しいとも間違いとも言えない質問

「なぜ」

私の観測上エンジニアで最も多いのが「なぜ」から質問を始めるパターンです。たとえば、バグが出たら「なぜバグが起きたのだろう？」と考えます。「なぜ」は問題を深堀りします。汎用的で、いろいろな問題に使うことができる便利な質問です。しかし、問題にはまって抜け出せなくなる可能性があるため、自戒の念を込めて、この質問から始めるのは「正しいとも間違いとも言えない」とさせていただきます。より経験を積んだエンジニアなら、「どこ」から始めるパターンが出てくるはずです。
「なぜ」がどうしてそんなに信用ならないか、不思議に思われた方もいるかもしれません。そういった人は誰かに「なぜ？」と問うたときを思い出してみてください。それぞれが理由を話してくれたと思いますが、「本当にそうなのかな？」と思ったことがあるはずです。「なぜ」によって因果関係を話すことはできても、そうやすやすと真実が見つかるものではありません。そういった背景があるため、「なぜ」を早いうちから使うのはあまり良いとは言えないと思います。

正しい質問

「どこ」

エンジニアがおそらく1番良く使う質問は「問題はどこ？」です。エンジニアに降りてくる問題は、「問題はなに？」がすでにわかっていることが多いからです。ただし、自分１人で解決できる問題ではない場合は「なに」から始めるのが良いです。「問題はどこ？」は問題の切り分けとも言います。バグが出たら「どこからバグが出たのだろう？」と考えます。この質問はもともと場所を探すためのものなので、広範囲を探すのに適しています。たとえば、フロントエンドとバックエンドの切り分けや、コードレベルの切り分けをするのに使います。
「どこ」は「なぜ」をより早く解くための準備のようなものです。「なぜ」単体では何度も問題を深堀りしなければ解決できない可能性がありますが、「どこ」と組み合わせることで問題の深堀りを最小限に留めることができます。

「なに」

最も問題を広くとらえることができる質問は「なにが問題？」です。「なに」によってそれまで正体不明だった問題を言葉でとらえることができます。たとえば、子どもが泣いていたとして、痛がっているそぶりがなければ、かける言葉は「どこか痛いの？」でも「なぜ泣いているの？」でもなく、「なにかあったの？」だと思います。そういった質問をすることで、より広く問題をとらえることができます。
DXでは「なに」だと抽象的すぎる場合がほとんどなので、問題を「現状と目的の差」と捉え、「現状はなに？」と「目的はなに？」に質問を切り分けます。たとえば、目的が「事業を30年後もやっていけるようにする」で、現状が「事業の未来がどうなっているのか、10年後はわからない」だとします。その場合、「問題はなに？」の答えは、端的には「事業の安定性が乏しいこと」になります。
自分１人では解決できないような問題の場合、こういった質問をしなければ解決できないことがほとんどです。目的や現状を調べる際には5Wを意識するとヌケモレが減るのでオススメです。たとえば、「業務を改善したい」という抽象的な目的に対しては、以下のような質問をすることで具体的な目的に変換できます。

「なぜ業務を改善したいのか」…背景
「なんの（どの）業務を改善したいのか」…業務の種類分け
「その業務のどこを改善したいのか」…特定の業務のプロセス分割
「だれがその業務を改善するのか」…プロジェクトチーム
「いつまでにその業務を改善したいのか」…期限

人に質問する場合

自分自身に質問する場合、上記のようなやり方でOKですが、人に質問する場合、「なぜそれが問題なのですか？」などと質問すると角が立つおそれがあります。なので、以下の例のように疑問形を依頼形に変換するように心がけたほうが良いです。

「目的はなんですか？」→「目的(もしくは背景)を教えていただけないでしょうか？」
「なぜそれが問題なのですか？」→「考えられる原因を教えていただけないでしょうか？」

質問のユースケース

上司に「簡単な社内用のアプリを作ってください」と言われたとき。
→
自分１人だけの問題ではないので、背景（目的）を聞くほうがより良いです。作る前は簡単なアプリだと思っていても実際に作り始めると想像以上に複雑だったと気づくことがあります。そうなると要件定義からやり直さなければいけませんが、目的を押さえなければ要件定義はできません。

本番環境で画面が真っ白になったとき。
→
「どこ」で問題が起きたのかを考えましょう。バックエンドなのか、フロントエンドなのか。あるいはもっと広く、自社なのか、他社なのか考える必要が出てくるかもしれません。

バグが起きたコードの位置を特定したとき。
→
「どこ」についてはコードの位置のほかに、通信プロセス上の「どこ」や画面上の「どこ」も含みます。すべての「どこ」に答えられる状況になれば、「なぜ」が解きやすくなります。「どこ」を調べるには、分析ツールを何個か持っておくと良いと思います。たとえば、Web開発ならブラウザの開発者ツールが役に立ちます。ライブラリに分析ツールが付属していることもあるので、そちらを調べてみるのも良いです。

問題はわかっているけれど、どう調べれば良いのかよくわからないとき。
→
「どこ」に問題があるのかを探しましょう。たとえば、ライブラリAとライブラリBの単体での使い方はわかっているけれど、AとBを組み合わせるときのやり方がわからないのかもしれません。そういったときは組み合わせている例を調べるのがより良いです。ChatGPTに聞いてもいいですし、まれなケースなら社内のコードやGitHubのpublicなコードに例があるかもしれません。あるいは、もっと知らない場合もありえます。ライブラリAの使い方は知っているけれど、Bは知らないのかもしれません。その場合はまずBの使い方から調べてみましょう。
いずれにしてもエンジニアリングの知識は階層構造になっていて、自分ではどこが欠けているのか認識できないときにどう調べればいいかわからない状態になります。意外と基礎的なことがわからなかったりしますが、足りないピースがどこにあるのか認識できれば、調べることができるようになります。どこが欠けているのかさえわからない場合は、チャットAIに下記のようなプロンプトを投げてみて、周辺知識を自分がどこまで理解しているのかチェックしてみましょう。

〇〇がわからないのですが、学習のイシューツリーをMECEで書いてもらえますか？

最後に

ざっくりと問題解決のフレームワークについて述べました。勉強会では抽象的すぎていまいち伝わっていないようでしたが、具体的な仕事を通じて学んでいってもらえたらうれしいです。引き続き職場での布教に努めたいと思います。
フレームワークはあくまでこの通りにやれば失敗が少なくなるものであり、成功を保証するものではありません。特にDXとなると、問題解決というよりは変革に近いもので、関係各位の熱意が必要不可欠です。今後もそういった方々のお手伝いができれば幸いです。