解く前に問いを疑えと気づいてから、エンジニアとしての仕事の質が変わった話

「それ、作る必要なかったかもしれない」という言葉を、レビューのあとに言われたことがある。実装に3日かけた機能だった。コードの品質は問題なかった。設計も悪くなかった。でも、その機能が解こうとしていた問いそのものがズレていた。

エンジニアになって数年が経つと、コードを書く速さは上がる。設計の引き出しも増える。技術的なキャッチアップのペースも変わってくる。ところが、ある時期から壁のようなものを感じるようになった。努力量は変わっていないのに、成果として評価されるものとそうでないものの差が開いていく感覚だ。積み上げてきたはずの経験が、思ったほど評価に結びついていないという感覚を持ったことがあるエンジニアは、少なくないはずだ。

そのとき、自分に足りなかったのは技術力ではなかった。「何を解くか」という問いの設定力、つまり問題定義の精度だった。どれだけ早く正確にコードを書いても、解く問いが間違っていれば結果は出ない。これはエンジニアだけに当てはまる話ではないが、特に技術職は「解くこと」に没頭しやすいぶん、この落とし穴にはまりやすい。コードを書くことへのコミットメントが強いほど、問いを疑わずに走り続けてしまう。

この記事では、問いを正しく設定する力をどう身につけるかについて、実際に変わったきっかけと、思考の質を上げてくれた4冊の本とともに紹介する。技術力と並行して磨いていくことで、エンジニアとしてのアウトプットの質は明確に変わると実感している。「解く前に問いを疑う」という習慣が、日常の仕事にどんな変化をもたらすのか、具体的なエピソードとともにお伝えする。

結論から言うと、エンジニアとしての仕事の質を上げるためには「解く前に、その問いは本当に解く価値があるのか」を問い直す習慣が必要だ。問題の定義精度が上がるだけで、無駄な作業は減り、評価されるアウトプットが増える。有効なのはイシュー思考と論点思考を組み合わせることで、さらに数値化と取捨選択の視点を加えると、日常の仕事の中で継続的に鍛えていくことができる。

エンジニアが「間違った問い」を解き続けてしまう理由

エンジニアという職業は「課題を解決する」ことを価値として評価される。コードを書き、テストを通し、動くものを作る。このサイクルが仕事の中心にあるため、自然と「問い」を設定する工程よりも「解く」工程のほうが時間と意識を占めやすい。

問題なのは、その問いが正しいと無意識に前提しているケースが多い点だ。要件定義書に書いてあるから正しい、上司がそう言ったから正しい、ユーザーから依頼があったから正しい。こうした思い込みのまま実装に入ると、技術的には完璧だが意味のないものが出来上がる。問いを疑わずに解き続けるとはどういうことか、具体的な例で考えてみたい。

あるプロジェクトで「ユーザーがボタンを押した後の確認画面を改善してほしい」という依頼を受けたことがある。UIの改善に2日ほどかけて実装したが、後にデータを見ると、そもそもボタン自体を押すユーザーが全体の5%以下だったことが分かった。確認画面の改善より、ボタンが押されない理由を探ることの方がずっと価値が高かった。これは技術力の問題ではなく、問いの設定の問題だ。

コードを書く前に立ち止まることが難しい理由

コードを書くという行為は、フロー状態に入りやすい。問題を論理的に分解し、それを実装に落とし込む工程は没頭しやすく、達成感もある。これ自体は悪いことではないのだが、問いの設定フェーズを省略してフロー状態に入ってしまうと、気づいたときには大量の「間違った方向への作業」が積み上がっている。

また、チームの文化によっては「すぐ動く」ことが美徳とされている場合もある。手を動かすことへの評価が高い環境では、立ち止まって考えること自体がサボっているように見えることもある。だが、問いを正しく設定するための10分は、間違った問いを解き続ける10時間を回避できる。問いを疑う時間を意識的に取るようになってから、「やっぱり方向を変えよう」という手戻りの回数が明確に減った。

Audibleを活用して通勤中に思考系の本を継続的に聴くようになってから、問いを立てるという行為への解像度が上がった。耳から入る情報は、デスクから離れた場所で無意識に反芻されやすい。コードを書く前に「これは本当に解くべきか」と立ち止まる習慣は、こうした地道なインプットの積み重ねで育っていく。

「要件通りに作った」のに評価されない現実

技術者のあいだでよく話題になるのが、「要件通りに作ったのに、ユーザーに使われない」という現象だ。これはUXの問題として語られることも多いが、根本をたどると「その要件は正しかったのか」という問いに行き着く。要件定義の段階で、誰かが「これを作れば問題が解決される」という仮説を立てていた。その仮説が正しければ、要件通りに作ることで価値が生まれる。だが仮説がズレていれば、要件通りに作っても価値は出ない。

エンジニアは要件を受け取ったあとで、その前提にある仮説を疑う目を持つことが重要だ。「この要件が正しいとすると、解決される問題は何か」を逆から辿る思考習慣が、問題定義力の第一歩になる。問いを逆算する習慣がつくと、ミーティングでの発言の質も変わる。「この機能を追加したいのですが、それによってどの課題が解決されますか？」という一言が、チーム全体の方向性をそろえるきっかけになる。

「要件通りに作ること」と「問題を解決すること」は別のことだ。この区別を理解しているかどうかで、エンジニアとしての評価は大きく変わる。この認識を持った上でコードを書き始めるだけで、仕事への向き合い方の解像度が変わってくる。

問いを正しく設定するとはどういうことか

「問いを正しく設定する」と言うのは簡単だが、実際に何をすればいいのかは分かりにくい。このセクションでは、問題定義力の核心にある二つの概念を整理する。どちらも実際の仕事に即適用できる考え方だ。

イシューとは何か

イシューとは、「今この局面で答えを出すべき問い」のことだ。安宅和人が「イシューからはじめよ」（英治出版、2010年）で提唱したこの概念は、「解くべき問いを間違えると、どれだけ努力しても成果は出ない」という主張の核にある。重要なのは、すべての問いがイシューではないという点だ。世の中には無数の問いが存在するが、その中でいま答えを出すことに価値がある問いは、ごく一部しかない。

安宅はイシューの判定基準として「a. 答えが出せる b. 答えが出る価値がある c. 自分たちが取り組む必要がある」の三点を挙げている。エンジニアの文脈でいうと、「このAPIのレスポンスタイムを50ms改善すべきか？」という問いが本当にイシューかどうかは、ユーザー体験に与える影響、現在の他の課題との優先度比較、実現のコストとのバランスなど複数の軸で判断する必要がある。問いを立てる前にその問いがイシューかを確認する習慣が、仕事の無駄を大幅に減らす。

「イシューからはじめよ」を最初に読んだとき、自分が日常でどれだけ「イシューでない問い」を一生懸命解いていたかに気づかされた。そしてその本の内容を繰り返し内省に使えるようになったのは、Audibleで聴き直せる環境があったからだ。通勤中に音声で繰り返し聴くことで、概念が日常の判断に結びつきやすくなる。一度読んで終わりにするには惜しい密度の本だ。

論点と作業点を混同しないために

「論点思考」（東洋経済新報社）を書いたBCG（ボストン コンサルティング グループ）の元代表、内田和成は「論点」と「作業点」を明確に区別している。論点とは解くべき本質的な問いであり、作業点とは実行すべき作業のことだ。エンジニアが日常でよく混同するのは、「タスクを潰すこと＝問題を解いていること」という錯覚だ。

チケット管理ツールのチケットを次々とクローズしていても、それが論点に対応していなければ、問題の解決には近づいていない。内田はBCGでのコンサルタント育成の現場から「問題を解く能力より、問題を設定する能力の方がはるかに重要」と言い切る。技術系の職種においても、この視点は等しく有効だ。コードを書く前に「今日のタスクは、どの論点に対応しているか」を問い直してみることから始められる。

「論点思考」はBCGが長年の現場で積み上げてきたフレームワークを惜しみなく公開している一冊だ。コンサルタント向けのように見えるが、エンジニアリングの現場にそのまま適用できる考え方が多い。Audibleでも配信されているので、設計や要件整理の前後に繰り返し聴くと、問いの設定に関する直感が変わってくる。

数値で問いを立て直す習慣

問いを正しく設定するためには、「なんとなく」という感覚を数値に変換する力が必要だ。「パフォーマンスが悪い」は問いにならないが、「P95レイテンシが200msを超えているページはどこか、その原因は何か」は問いになる。この変換が習慣になっているかどうかで、問いの精度は大きく変わる。

「なんとなく」から「どのくらい」へ

エンジニアのミーティングで「なんかユーザーの反応が鈍い気がする」という発言が出たとき、そこからすぐ改善策の議論に入ってしまうことがある。だが実際には、まず問いを数値で立て直す工程が必要だ。「どの指標が、いつと比べて、どのくらい変化しているか」という問いを立て、それに対するデータを集める。そこからはじめて、本当の問いが見えてくる。

識学を運営する安藤広大の「数値化の鬼」（ダイヤモンド社）は、この「なんとなくを数字にする」思考を組織と個人の仕事に応用する方法を説いている。安藤は「数字で考えないと、問題の所在が分からない」と述べており、この視点はエンジニアにも直接刺さる。コードや設計では数値的思考が得意なはずのエンジニアも、仕事の上流部分、つまり問いの設定や課題の優先順位付けになると、途端に感覚に頼ってしまうことは多い。「数値化の鬼」はそのギャップを埋めてくれる。

実際にこの本を読んでから、問いを立てる場面での言語化が変わった。「なんか重い」から「ページ読み込みに3秒以上かかるケースがどのくらいの頻度で発生しているか」へ。「バグが多い」から「直近1ヶ月でP1バグが何件発生し、そのうち何件が特定のモジュールに集中しているか」へ。問いが具体的になると、次のアクションも自然と明確になる。

数値化が優先順位を変える

数値で問いを立て直すと、優先順位が自動的に明確になってくる。「なんとなく大事そう」という感覚では、複数の課題が並立したときに判断できなくなる。「このバグを直すことでDAUが何%改善されると予測されるか」「このリファクタリングにかかるコストと、その後の開発速度向上の期待値はどう釣り合うか」といった問いを立てることで、優先順位の判断が定量的になる。

実際にこの習慣を意識し始めてから、「やった方がいい気がする」という感覚で積み上がっていた作業の山が整理されるようになった。数値化は、問いの質を上げるだけでなく、チームへの説明責任を果たすうえでも有効に機能する。「なぜこのタスクを優先するのか」を数字で語れるエンジニアは、チームの中での影響力が自然と上がっていく。

エッセンシャル思考が問いの取捨選択を変えた

問いを正しく設定し、数値で評価できるようになっても、まだ課題は残る。「解く価値のある問いが複数あったとき、どれを選ぶか」という取捨選択の問題だ。ここで効いてくるのがエッセンシャル思考の考え方だ。

全部やろうとするエンジニアの落とし穴

エンジニアは往々にして、改善できることに気づきやすい。セキュリティの脆弱性、パフォーマンスの改善余地、テストカバレッジの不足、技術的負債。どれも無視できない課題だ。だが、すべてに同時に取り組もうとすると、すべてが中途半端になる。問いを正しく設定する力を持っていても、解く問いを絞り込まなければ、力は分散する。

グレッグ・マキューンが「エッセンシャル思考」（かんき出版）で述べているのは、「より少なく、しかしより良く」という選択の哲学だ。本質的なこと（エッセンシャル）だけに集中し、それ以外を積極的に手放す。これは技術選定や設計方針だけでなく、「解く問いを絞り込む」という行為そのものにも適用できる。エンジニアとして成果を出し続けている人は、無意識に「解く問いを絞る」選択を継続していることが多い。

自分の経験を振り返ると、「全部やろうとしていた時期」と「絞り込んで集中していた時期」では、成果の量より質が明確に違った。全部やろうとしていたとき、どれも70%の完成度で止まっていた。絞り込んでからは、一つのことに100%の注意を向けられるようになった。

「解く価値のある問い」を選ぶ力

エッセンシャル思考の中心にある問いは「これは本当に必要か？」だ。問題定義の文脈でいえば、「この問いを今解くことは、最も重要なことか？」に翻訳できる。実際に仕事のなかでこの問いを持つようになって、自分でも驚くくらい「やらないこと」が増えた。ミーティングで提案されたタスクに「それは今解くべき問いか？」と問い返す習慣ができてから、チームの方向性のブレも減っていった。

「何をするか」より「何をしないか」を決めることのほうが、仕事の質を上げるうえで効いてくることがある。エッセンシャル思考はその判断基準を与えてくれる。Audibleで通勤中に繰り返し聴くと、日常の選択場面でこの問いが自然と浮かぶようになっていく。

問い方を変えたら、チームとの対話も変わった

問題定義力は、個人の思考を変えるだけでなく、チームとのコミュニケーションの質も変える。「何を解くか」を正しく設定できると、チームへの説明が変わり、議論の質が上がる。

設計レビューで「なぜその問いか」を語れるようになった

以前の設計レビューでは、「こういう実装にしました」という説明から始めることが多かった。レビュアーからの「なぜこの設計？」という問いに、明確な論点を返せないことがあった。実装の選択理由は語れても、「この問いを解くためにこの設計が最善」という論理の筋道が弱かったのだ。

問いを先に設定する習慣がついてからは、設計レビューの構成が変わった。「今回解きたい問いはこれで、そのためにこの設計を選んだ理由はこうだ」という順番で説明できるようになった。レビューの議論が「実装の細部」ではなく「問いと解法の整合性」に集中するようになり、レビュー時間も短くなった。

論点を先に共有することで、レビュアーと「同じ問いを見ている」状態でコードを読んでもらえる。コードの品質の前に、問いの品質が高いかどうかが評価される。この変化は、チームの技術的な議論全体の質を上げることにつながる。

1on1で「今一番重要な問い」を確認する習慣

上司や先輩との1on1でも、問いの設定力が効いてくる。「最近どう？」という漠然とした問いかけに対して、「今自分が取り組んでいる問いはこれで、そこに行き詰まっている」と論点を提示できると、1on1の時間がより価値のあるものになる。

逆に自分がメンバーのメンターになる立場になったとき、「何に詰まってる？」より「今解こうとしている問いは何か、その問いは本当に解くべきか？」という問いかけの方が、相手の思考を整理する手助けになることに気づいた。問いの品質を一緒に確認する1on1は、課題解決の速度を上げる。

問題定義力は、個人の生産性を上げるだけでなく、チーム全体の思考の質を引き上げる力を持っている。一人のエンジニアが問いを正しく設定することで、議論の解像度が上がり、チーム全体が同じ方向を向けるようになる。

問題定義力を日常的に鍛えるための3つの習慣

思考の枠組みを知っているだけでは不十分で、日常の仕事のなかで意識的に使い続けることで力になる。以下の3つの習慣を実践してみると、変化が出やすい。特別なツールがなくてもできる。メモ帳一枚あれば十分だ。

• 作業を始める前に「この問いは本当にイシューか」を問い直す：新しいタスクに入る前に30秒だけ立ち止まり、「この作業は、どの問いに答えるためのものか」を言語化する。それだけで、ズレた方向への作業を大幅に減らせる。最初は違和感があっても、2週間続けると自然な癖になる。
• 問いを必ず数値で言い直す：「使いにくい」「遅い」「バグが多い」という言葉を受け取ったとき、「どの指標が、どのくらい、どの状況で」という形で言い直す。感覚ではなく観測可能な形で問いを立てる習慣が、問題定義力の基盤になる。数値化できない問いは、まだ問いが曖昧なサインだと思うといい。
• 週に一度、「解いている問いのリスト」を見直す：現在進行中のタスクを並べ、それぞれが「どの論点」に対応しているかをマッピングする。論点に対応していないタスクは、優先順位を下げるか止める判断ができる。これをやると、自分がどこに時間を使っているかが可視化されて驚くことがある。

この3つは、続けることで徐々に「問いを疑う感覚」が体に馴染んでくる。最初は意識的にやっていたことが、いつの間にかコードを書く前の自然なルーティンになっていく。Audibleで問題定義や思考法の本を繰り返し聴きながら、日常の小さな場面でこの習慣を実践し続けることが、問題定義力を着実に高める道だ。

問いの質を上げてくれる4冊（Audible配信あり）

問題定義力と論点思考を鍛えるために実際に役立った4冊を紹介する。いずれもAudibleで配信されており、通勤中や作業のすき間時間に聴くことができる。

よくある質問

まとめ

エンジニアとして成長していく過程で、「技術力だけでは限界がある」と感じる瞬間が必ずやってくる。そのとき足りていないのは、多くの場合「問いを正しく設定する力」だ。どれだけ速く正確にコードを書けても、解く問いがズレていれば評価されない。逆に問いを正しく設定できれば、作業量が減っても成果は出る。問いの質が、仕事の質を決める。

この記事で紹介した考え方は、どれも特別な環境や資格がなくても今日から使えるものだ。まず「作業に入る前に問いを言語化する」という30秒の習慣から始めてみてほしい。最初は意識的にやっていたことが、繰り返すうちに自然な思考習慣になっていく。問いを疑うことは、ネガティブな批判ではなく、仕事の精度を上げるための建設的な思考だ。

今回紹介した4冊、「イシューからはじめよ」「論点思考」「数値化の鬼」「エッセンシャル思考」はいずれもAudibleで配信されている。通勤中や作業のすき間でこれらを繰り返し聴き続けることは、問いを疑う直感を育てる地道な方法として有効だ。概念を一度学んだだけでは定着しにくい。繰り返し聴いて、日常の判断に紐づけていくことで、問題定義力は少しずつ確実に磨かれていく。

「解く前に問いを疑う」。それだけで、エンジニアとしての仕事の質は確実に変わる。そして、チームとの対話も変わり、自分の成長の形も変わる。技術力と問題定義力の両輪が揃ったとき、エンジニアとしての影響力は一段階上がる。