「問題を理解する」とは何か ~「いかにして問題をとくか」をいかにして応用するか~
1. 導入と自己紹介
こんにちは!株式会社タイミーでフロントエンジニアをしている林です。
入社してそろそろ2ヶ月くらい経ちます。ここまで雑談はほぼBLEACHネタ一本で攻めてきました。流石に飽きられそうなので別の切り口を考えます。
皆さんは常日頃何かしらの問題解決をしていることと思います。どのような目的でどのような機能を追加するか、機能を実現するためにどのように実装すれば良いか。これらは広く言うと全て「問題を解決している」と言えるかと思います。 では、皆さんは日々の問題を正しく理解してますか?
問題を解決する前に問題を理解する必要がある、というのは当たり前のように感じられるかもしれません。では、「問題の理解の仕方」を理解していますか?
今回は皆さんに「問題の理解の仕方」を理解していただくべく、私の好きな本をご紹介したいと思います。「いかにして問題をとくか」(G.ポリア著)と言う本です。
この本の紹介については、丸善出版のページで紹介されている内容が端的で良いので引用します。
本書は「問題解決」という非常に抽象的なテーマを数学を題材にしながら学べる教科書のようなものであり、多くの人の業務に活きる学びを得られる本だと思います。
先ほどの「問題の理解の仕方」というのは本書で語られるテーマのほんの一部ですが、今回は本書をご紹介しつつ、「問題理解への理解」を少しでも深めていただければと思います。
まずは本書全体のテーマについて見ていきましょう。
2. 「いかにして問題をとくか」
全体を通じて本書の主張は非常にシンプルです。ここで説かれるのは以下の質問に対する解答です。
私は学生の時からエンジニアとして働く今に至るまで、このような疑問を何度も感じてきました。
おそらくこれを読む皆さんも近い疑問を感じたことがあるのではないでしょうか。
この疑問への答えとして本書で著者が提示するのが以下の4ステップです。
問題を理解すること
計画をたてること
計画を実行すること
振り返ってみること
本書の中ではさらに詳しくそれぞれの項目を分解しています。例えば、本書では、「問題を理解すること」をさらに4つのステップに分解しています。
未知のものは何か。与えられているもの(データ)は何か。条件は何か。
条件を満足させうるか。条件は未知のものを定めるのに十分であるか。または不十分であるか。または余剰であるか。または矛盾しているか。
図を書け。適切な記号を導入せよ。
条件の各部を分離せよ。それをかき表すことができるか。
この調子で分割された全15の項目を指して本書では「リスト」と呼びます。このリストは本書の中で一番重要な主張であり、問題解決の際に追うべき(もしくは無意識に追っている)流れそのものと言っても決して大げさではないと思っています。。
(本書は数学を題材にしているので数学チックな用語や記述があり取っ付きづらい印象はあるかもしれません。この本は全体的にこんな感じですが、読んでいるとすぐに慣れます。)
次の章では、プロダクト開発の現場で実際にありそうなケースについて話しながら、本書での「問題理解への理解」の方法に触れていきます。
3. 問題理解のためのプロセスを理解する
例えば、あなたのチームでこんな話が上がったとします。
本書にならって数学っぽく書いてみると、
のような感じでしょうか。
こんな問題を、あなたはどう理解するでしょうか。この章ではこれを問題文として、この問題を「理解する」手順を一緒に追っていきたいと思います。
👾「未知のもの」
先ほど言及したリストを再び見返してみましょう。先ほど出したリストの1番は次のようなものでした。
ということで、「未知のもの」「与えられているもの(データ)」「条件」を確認していきます。
「未知のもの」とはつまり、これから自分が出すべき答えがどんなものなのか、ということです。
では今回の「未知のもの」はなんでしょう。今回のケースでは「定着率を向上する新しい取り組みx」です。
さらに具体的に、新しい取り組みとは一体どのようなものでしょうか。アプリの新機能開発や既知の不具合改修というのはまず思いつくところでしょうか。もしかしたらそれよりも新規流入ユーザーへのキャンペーンを打つことだったり、新規ユーザー向けにコンテンツを整備することかもしれません。
実際にはチームの持つ能力や機能によって手段が制限されることも多いです。
もちろん自分の専門分野であるからこそ出せる解決策というものも多く、そこにこだわることは悪くありません。ただ、そこに囚われすぎず問題解決の手段としては自分たちの専門分野以外も選ぶことができるということは意識しておくと良いでしょう。
では「未知のもの」についての理解が深まったところで、「与えられているデータ」と「条件」について確認していきます。
📚「データ」
データに関しては、数学の問題では基本的に必要なものは全て問題文の中にあります。
一方でプロダクト開発のような実際の問題では当然ですが待っているだけでは誰もデータを与えてくれません。ここは日頃どのようなデータを集めているかという話も重要になってきます。
今回の問題では、前提となる「新規定着率」は必ず必要になりそうです(これがなければそもそも問題が解決できたのかの判別もできません)。
また、新規定着率だけではなく、「新規定着率に関係のある(ありそうな)データ」についても確認しておきたくなるでしょう。例えばファーストビューでのコンテンツ数と定着率の関係やページの読み込み速度との関係など、定着率に関係する要素と言ってもさまざまなものが考えられます。それ以外にも、もし定着率に関係しそうな既知の不具合があればそれについての知識(影響を受ける人の数や属性など)も必要になるかもしれません。
全てのデータが手元にあれば話は早いのですが現実問題そうではないケースも多いです。必要に応じて追加で計測したり、ABテストのような手法でデータを集める必要もあります。
📐「条件」
条件についても同様で、実際の問題での条件は数学の問題よりもあいまいで複雑です。
条件の中でもっとも基本的なのは、そのプロダクトの持つブランドイメージのようなものやそもそも法律上の可能性など、プロダクト開発をする際には必ず考慮が必要になるようなものです。(*1)
より具体的な問題の条件について考えることは問題解決の取り掛かりになります。対応のスケジュール感や対応に割ける人数、キャンペーンの金額感のような情報はその意味で重要な条件となるかも知れません。また、その取り組みが既存ユーザーに与える負の影響をどの程度許容するのか、というような観点も重要な条件となるでしょう。
先ほどのデータの項で「新規定着率に関係のある(ありそうな)データ」という話がありましたが、これらの値に相関関係があることがわかればそれは問題を解く上で最も重要な条件となるでしょう。
また実際に問題を解く上で、経験則が条件やデータのように扱われることがあるかも知れません。
上記のように細かくデータや条件を確認することは必ずしも経験則の存在と活用を否定するものではありません。実際に、次の「計画」の段階では「似た問題を知っているか」という問いが繰り返し問われます。経験則がありこれまでの知識を活用できるということは、問題解決においては最もうれしいケースです。
しかし、解いている最中で違和感が出てくることもあるかもしれません。経験則に対して他の客観的な根拠や条件と同じように扱うと、経験則が誤っている・古い場合に非常に遠回りをしてしまうことになります。経験則を条件やデータとして考える時には、それが経験則であるということを意識して進めると良いでしょう。
これらの「未知のもの」「データ」「条件」の3つを理解して初めて問題解決のスタートラインに立てました!おめでとうございます 🎉
この3要素を精度高く把握できていれば問題理解についてはほとんど問題ないと言えると思うのですが、問題を理解することに関するリストにはあと3つ質問が残っています。一つずつ見ていきましょう。
🤔仮説を立てる
(「何が」の部分がないので分かりにくいですが)条件を満足させうるか、というのは答えに対する仮説を立て、それが条件を満足させるか、と理解してもらって構いません。
今回で言うと、どのような取り組みであれば先ほどの条件を満たすか、という問いになります。
実際に仮説を立てて、条件を満足させるか検証を試みることで、条件に対して検証を試みることで、問題をさらに精度高く理解できることはもちろん、条件を満たす仮説を立てられればこの後のステップの「計画」にも良い影響を与えます。
ただし、ここで筋の良いと思える仮説を出せてもそれはあくまで仮説で、そこに固執してしまわないように注意が必要です。逆にここで有力な仮説が出せなかった場合、気にせず先に進んでしまって良いというのが本書の主張です。
と語られています。この段階ではこの問いはあくまで「問題の理解」のために向けられるもので、仮説を出して計画を進めるのは別の段階での作業となります。本書の中には問題に手も足も出なくなった時にやるべきこと(*2)も解説されているので、ここで良い仮説が出なくても問題はありません。
📺可視化
図や記号というのは数学の文脈がかなり強い話になりますのでここを意識しすぎる必要はないかもしれません。図はともかく記号を導入するという点が少しわかりづらいと思いますが、要は未知数や重要なものに対してxやyなど適切な名前をつけることで対象に意識を向けよう、という話です。
「図を書く」という点については実際の問題でも応用できる点があります。要は「見た方が理解が早い」ということです。
アプリケーションの現状のUI、特に問題に関係する部分を実際に改めて見てみる、複雑なコードの依存関係を図に起こしてみるような行いを通じて、さらに問題への理解を深めることができます。
🐝細分化
これは、問題の「未知のもの」「データ」「条件」を理解したが、まだ良い考えが浮かばないという時に思い出す問いです。
「条件の各部を分離する」とは主要な条件をさらに細かく把握するということを指します。先ほどの条件のところで、「新規定着率と相関のあるデータ」は重要な条件となり得るという話をしました。ここではさらに具体的に「新規定着率」と「ユーザーが最初に閲覧したページ」に相関があった、つまり、ページAを最初に閲覧したユーザーとページBを最初に閲覧したユーザーで定着率に有意な差があったという話をしましょう。
「条件の各部を分離する」ということは、それぞれのページAとページBについてさらに考察を深めるということです。クリエイティブに差があるのか表示速度に差があるのか、そもそも流入するユーザーのモチベーションが最初から違うのか。考えてみると色々な仮説が浮かぶことと思います。これらの仮説が実際に正しいのかはさておき、それらの仮説は問題解決の糸口になることがあります。
「書き表すことができるか」は先ほどの「図を書く」と同じことを細分化された条件それぞれに対して行うということです。可視化によってさらに理解を深めることができます。
以上が本書の示している「問題を理解する」方法です。
お察しの方もいるかもしれませんが、これはステップ1〜4を一つずつこなせば必ず問題理解が終わる、という類のものではありません。問題理解は、筋の良い仮説を発見して問題を解くための計画のステップに進むまで考え続ける必要があります。また問題を解く上で問題理解と計画を立てるプロセスは完全に分けられるものではなく、必要に応じて何度も行き来するものでもあります。
冒頭僕は
と書きましたが、ご多分に漏れず結局ここにも銀の弾丸なんていうものはなかったということがお分かりいただけたのではないかと思います。
4. 結論と本の推薦
この記事では本書で示されるリストに基づいて、問題を理解する方法についての説明を行いました。が、もちろん本書で語られることは「問題の解き方」の解説であり、「問題の理解」と言うテーマはそのうちのほんの一部でしかありません。
この記事について最初考えていた時は問題解決の前ステップを網羅することを考えていたのですが、文字数がとんでもないことになりそうで辛くなったので見送りました。
実際本書では今回説明した「問題を理解すること」に続いて「計画を立てる」「計画を実行する」「振り返る」という大きなテーマについて説明しながら、その中で「決定問題と証明問題」や「発見」「進歩の兆候」のような日常の問題解決で活かせたりそこまで活かせなかったりする(*3) tipsが多く含まれています。
これらのステップや本書のリストは基本的に問題に行き詰まった時や焦って視野が狭くなってしまった時に効果を発揮します。いつでも決まった網羅的な方法で考えることができるようになれば、どのような状態でも問題を前に進めるために、迷った時でも迷走し過ぎず、少しずつ前に進むことができるようになれるかと思います。
実は私もまだまだ迷ってばかりでこれを常に実践できているわけではないですが、これからも問題解決のより良い方法について考えられればと思います。
5. 宣伝のコーナー
タイミーでもビジョンの実現という最も大きな問題解決のために、日頃から大小様々な問題解決に取り組んでいます。ただ、僕たちが解くべき問題はまだまだ果てしなく存在します!
今タイミーのでどんな問題に取り組んでいるか、今入るとどんな問題に挑戦できるのか
気になった方はぜひこちらでお話ししましょう!
*1) これらを忘れて問題を解くことがいかにリスクが高いか、SNSで多くの炎上案件を見てきた皆さんならお分かりのことと思います。
*2) 個人的には本書の「発見学」から始まる発見についての章や「問題が解けなかったら」あたりが纏まっていて読みやすい印象です
*3) 本書はあくまで数学やりたい教師と生徒のための本なので、仕事やエンジニアリングに応用しようと思うと若干意訳や抽象化が必要に感じる部分もあります。が、そういった部分もシンプルに高校数学を思い出して懐かしい気持ちになれるのでおすすめです。
この記事が気に入ったらサポートをしてみませんか?