エンジニアの仕事とは、問題の発見・定義・解決の繰り返しなのかもしれません。

読者の皆さんにも以下のような要望を依頼者からもらうことはないでしょうか？

コンテンツをさらに増やしつつ、表示スピードも向上させたい
新しい技術も導入させつつ、依頼した開発も早くやってほしい
売り上げ管理を見える化して、さらに高速にPDCAを回せる仕組みを作りたい
売り上げに繋がるユーザーにだけサービスを訴求したい

これらの問題を闇雲に解決していたら、時間がいくらあってもたりません。

良い問題を設定しない限り、何度解決しても、いいアウトプットにはなりません。

そこらへんのことは著書「ISSUEからはじめよ」に書いてあります。

例えば、Webサービスという商品を開発（保守・運用）していても、それを使うユーザーの課題の本質理解が無いかぎり、解決策のほとんどは無駄、徒労に終わってしまいます（もちろん、本質をついて当たるケースもあります）。

それは非常にもったいないですね。。書籍「ISSUEからはじめよ」にて、安宅氏が言う「犬の道を通るな」ってやつですね。

なので、この著書（ライトのやつ）を通じて、「いい問題設定とはなにか」を学ぶことにしました。

（余談ですが、問題解決の本はとっても多いのに対して、問題発見の本ってとっても少ないですよね。。）

良い問題発見の思考法として参考になったものを実例を含めて以下に紹介します。（翻訳がわかりにくいと感じたので、意訳してます。）

学びになったのは以下の4点

そもそも問題とは何か？を知ること
誰かの解決方法を鵜呑みにして開発するな
問題を解決する前に考えること（方法論）
最適な問題発見に終わりはない（思考に終わりはない）

紹介していきます。

そもそも問題とは何か？を知ること

「問題とは、望まれた事柄と認識された事柄の間の相違である」

（P.15）

ちなみに原本では

A problem is a difference between things as desired and things as perceived

とありました、要は

目標（理想）と現実の差異（ギャップが課題・問題）ってやつですね。

ってことは、理想そのものを変えてしまえば、問題は問題でなくなるってことです。

例えば、表示速度の遅いページがあるとします。エンジニアは技術を駆使してそれを早くするとします。

でもこれって、見方を変えて処理に時間がかかってもいいと考えたらどうでしょうか？

例えば、行列ができるラーメン屋。並んで食べるまでに30分かかるとしたら、商品がユーザーに届くまでのパフォーマンスは最悪ではないでしょうか？

でも、人気は絶えないラーメンはありますよね？

つまり、理想って「多少待っても得たい！と思えるほどの商品（コンテンツ）にする！」に変えれば表示スピードは問題でなくなる、と言うことです。

極論だけど、多くのWebサービスに言えることだと思っています。

誰かの解決方法を鵜呑みにして開発するな

日本語版だと、P36の部分です。

Don’t take their solution method for a problem definition

意訳：誰かの解決方法をそのまま鵜呑みにするな。

これは、僕も未熟なのでよくやってしまいます。

実例よりも、「顧客が本当に必要だったもの」の例が最適ではないでしょうか。

問題を解決する前に考えること（方法論）

正しい問題を設定できれば解決することはそれほど難しくはないそうです。

（本書で言われる、以下から推論するに）

問題を認識することが一番難しい

(P.53)

正しい問題を設定するために、以下の方法論を試すことは大事だそうです。

誰の問題か？（P.83）
- 本当に、自分や、自分のチームがとくべき問題か
なぜこの問題が起きたのか（P.104）
自分の第一印象は無視するな（P.46）
- 生物学専攻だったので、この手の話は「DNAの2重らせん構造の発見エピソード」の方が好例ではないでしょうか？
  - ワトソンの直感を、クリックが理論でモデルを構築したあの話です。

なるほど、とは思ったものの、自分の経験則にまだ無いので、腹落ちはしてません。

最適な問題発見に終わりはない（思考に終わりはない）

齊藤先生ではありませんが、要は思考中毒になれ！と言うことですね。

どう言うことかと言うと、以下

Each solution is the source of the next problem

意訳：ある解決策は別の問題を生む（P.65）からですね。

飛沫感染を恐れて、マスクしたらメイク落ちやすくなった。的なやつです。

エンジニアとして例えるなら、新技術を導入して解決される問題もあれば、新たに生まれる問題も必ずあると言うことでしょうか。

また、なぜ、最適な問題発見に終わりはないかと言うと、「究極の解答」は存在しないかららしいです。（P.46）

Web業界でもテスト駆動開発（TDD）がスタンダードですが、プログラムの正しさを検証する方法としてのテストコードが最適解では無いと言えるでしょう。

もし仮に、エディタが超優秀になってコードの矛盾点に全て気づければTDDスタンダードな状況も変わってくると思います。

（ましなテストコード書いてから言えよ。と、突っ込まれそう）

最後にまとめ

The really important thing in dealing with problems is to know that the question is never answered, but that it doesn’t matter, as long as you keep asking

意訳：大事なことは、課題解決に終わりなし。と知ることです。なので、思考中毒になりましょう！と言うことですね。

ありがとうございました！