考える前に「問い」を立てることで、エンジニアの仕事の質が変わると気づいた話

結論から言うと、考える前に「問い」を立てることで、エンジニアの仕事の質が変わると気づいた話——最初は半信半疑だったが、試してみると仕事の質そのものが変わることに気づいた。スキルより習慣の設計が先に来る。この記事では、具体的な方法と、実践してから変わったことを正直に話す。

「なぜ自分のコードレビューは指摘が多いのか」「なぜ設計の議論でうまく話せないのか」「なぜ技術書を読んでいるのに仕事に活きないのか」。入社4年目まで、これらの問いに答えられないまま仕事を続けていた。そして気づいたのは、答えを探す前に「問いの立て方」が間違っていたということだ。

安宅和人の「イシューからはじめよ」を読んで、仕事の成果は「どれだけ多く考えるか」ではなく「どれだけ良い問いを立てるか」で決まることを知った。問いの質が低ければ、いくら考えても的外れな答えを量産するだけだ。「問いを立てる」というステップを意識するようになってから、仕事の進め方が根本から変わった。

しかし問いを立てることは、それだけでは仕事を速くしない。立てた問いに対してすぐに考え始める力が必要だ。そこで役立つのが、赤羽雄二の「ゼロ秒思考」だ。A4の紙に問いと答えを1分で書くというシンプルな訓練が、思考のスピードと明確さを同時に鍛えていく。問いを立て、即座に考える。この2つの習慣を組み合わせることで、エンジニアとしての仕事の質が変わった。

問いを立てる力は「天性のセンス」ではない。正しい方法を知り、繰り返し練習すれば誰でも習得できる技術だ。この記事では、イシューからはじめよとゼロ秒思考が教える「問いの立て方と思考の高速化」の実践方法を解説する。

イシューからはじめよも、ゼロ秒思考も、Audibleで通勤中に聴けるビジネス書だ。問いの立て方という「考える技術の基礎」を移動中に学び、翌日の仕事で即実践する。そのサイクルが、エンジニアとしての思考の質を底上げしていく。

※ 30日間の無料体験。いつでも解約可能。

「問い」の質が仕事の質を決める。その理由をエンジニア目線で考える

多くのエンジニアは「答えを出すこと」に意識を集中させる。コードを書く、バグを直す、設計を決める。しかし、答えの質は問いの質によって上限が決まる。「どうすれば動くか」という問いに答えるコードと、「どうすれば保守しやすく、拡張性が高く、パフォーマンスが安定するか」という問いに答えるコードは、根本的に質が違う。問いが浅ければ、答えも浅くなる。

安宅和人はコンサルタントとして、また学者として長年「問いの立て方」を研究してきた。彼が「イシューからはじめよ」で強調するのは「解く前に問いを選ぶ」という順序だ。解くべき問い（イシュー）を正しく選べれば、解くための労力は大幅に減る。逆に、イシューが間違っていれば、どれだけ懸命に働いても成果は出ない。エンジニアの文脈で言えば「正しい問題を正しく解く」ことの重要性だ。

問いを立てることがなぜ難しいのか。それは「問いを立てること自体にも思考コストがかかる」からだ。日常の仕事では、次々とタスクが降ってくる。それを「とにかく終わらせること」に意識が向くと、「これは本当に解くべき問題か」という立ち止まりが失われる。手を動かす前に5分考えることで、2時間の無駄を防げるケースが頻繁にある。この「立ち止まりの5分」が習慣になることが、問いを立てる力の出発点だ。

問いの質が低いと起きること

問いの質が低い状態でエンジニアが仕事をすると、典型的な問題が発生する。まず「実装したが要件がずれていた」という手戻りだ。「この機能をどう実装するか」という問いだけを持って実装を始め、完成後に「そもそもこの機能は本当に必要だったのか」という問いが抜けていたことに気づく。問いの順序が逆になっていたために、正しく動くが不要なコードが生まれる。

次に「コードレビューで根本的な指摘が入る」という問題だ。実装の詳細に集中するあまり、「この設計が適切かどうか」という上位の問いを飛ばしていると、レビュアーから「そもそもこのアプローチは」という指摘が入り、大きな書き直しが発生する。問いの階層を意識することで、実装前に設計レベルの問いを先に解くことができる。

三つ目は「会議で議論が噛み合わない」という問題だ。チームメンバーが異なるイシューを前提に話しているとき、議論は平行線になる。「どの実装方法が正しいか」を話したい人と「そもそもこの機能が必要か」を話したい人が同じテーブルにいると、議論の生産性は極めて低くなる。問いを揃えることが、会議の生産性を上げる最初のステップになる。

エンジニアに「問いを立てる」習慣が少ない理由

エンジニアの教育は「問題を解く」訓練が中心だ。アルゴリズム問題、コーディングテスト、バグ修正。いずれも「問いは与えられ、答えを出す」という構造になっている。この訓練が積み重なると「問いは外から来るもの」という前提が無意識に形成され、「自分で問いを立てる」という思考習慣が育ちにくくなる。

また、スピードを重視する開発文化も問いの立て方を阻害する要因になる。アジャイル開発のスプリントでは「とにかく動くものを作る」というプレッシャーがかかりやすい。その環境では「立ち止まって問いを吟味する」行為が「仕事が遅い」と評価されるリスクを感じることがある。しかし実際には、問いを吟味することが最もスピードを上げる行為だ。正しいイシューに集中することで、無駄な実装が消え、手戻りが減る。

• 問いは与えられるという訓練の積み重ね：自分で問いを立てる習慣が育ちにくい
• スピード重視の文化：立ち止まる行為が遅さと誤解される
• 実装への早期没入：手を動かすことに安心感があり、考える前に始めてしまう
• 問いの立て方を学ぶ機会がない：技術書は答えを教えるが問いの立て方は教えない

イシューからはじめよが教える、「解く前に問いを選ぶ」という仕事術

安宅和人の「イシューからはじめよ」は、マッキンゼー、ヤフージャパン、慶應義塾大学という三つのフィールドで磨かれた思考法をまとめた一冊だ。核心にある考え方はシンプルで、「問題を解くより先に、解くべき問題を選ぶことに時間を使え」ということだ。どれだけ速く正確に問題を解いても、解くべきでない問題を解いていれば成果は生まれない。

安宅氏が定義する「良いイシュー」は3つの条件を持つ。第一に「本質的な選択肢を含んでいる」こと。「AとBどちらが正しいか」という形の問いに、答えることで状況が変わる選択肢があることだ。第二に「深い仮説がある」こと。問いに対する答えの見通しが立っており、その仮説を検証するための方向性があることだ。第三に「答えることで前進できる」こと。解いても状況が変わらない問いは、いくら解いても価値が生まれない。

エンジニアの仕事にイシューの概念を当てはめると、例えばパフォーマンス改善の場面では「どのクエリを最適化するか」の前に「そもそもどのページのパフォーマンスが最もユーザー体験に影響しているか」というイシューを立てることになる。このイシューが正しく立てられれば、最適化する対象が絞られ、小さな努力で大きな成果が得られる。

この本はAudible（オーディブル）で聴くこともできます。 今なら1冊無料でお試し →

「犬の道」を避ける

安宅氏が「犬の道」と呼ぶのは、イシューを吟味せずに大量の作業を続ける働き方だ。「とにかく頑張れば何かいいことが起きる」という発想で、手を動かし続けることが美徳だと思い込んでいる状態だ。犬の道を歩み続けると、消耗するが成果は出ない。仕事量は多いのに、評価につながるアウトプットが生まれないという状況がこれに当たる。

犬の道を抜け出すために必要なのは「生産性と価値を切り離す」視点だ。多くの作業をこなすことが生産性の高さだという思い込みを手放し、「価値のある問いに集中すること」が本当の生産性だと認識する。エンジニアで言えば、Jiraのチケットを消化することではなく、最もユーザーに価値をもたらす問題を正しく解くことが、高い評価につながる仕事だ。

仮説を持ってから問いを立てる

安宅氏がすすめる問いの立て方は「仮説駆動」だ。問いを立てる前に「答えはこうではないか」という仮説を持つことで、問いが具体的になる。例えば「なぜこのサービスのCVRが低いのか」という問いより「スマートフォンでの表示崩れがCVR低下の主因ではないか」という仮説を持った上で「この仮説は正しいか」という問いを立てると、調査の方向性が明確になり、検証が速くなる。仮説がない問いは、広大な海に網を投げるようなものだ。

ゼロ秒思考で「立てた問いに即座に答える」力を鍛える

問いを立てることができても、それに対して思考が展開できなければ仕事は進まない。赤羽雄二の「ゼロ秒思考」は、問いに対して「即座に、具体的に、明確に」考える力を鍛えるための習慣を提案している。方法はシンプルで、A4の紙にタイトル（問い）を書き、1分以内に答えを3〜5個書き出すというものだ。これを毎日10枚続けることで、思考のスピードと深さが同時に鍛えられる。

なぜA4の紙なのか。赤羽氏は「頭の中だけで考えると思考が堂々巡りをする」という観察から、外部化することの重要性を説いている。頭の中で考えると、同じ思考が繰り返されたり、論点がぼやけたりしやすい。紙に書くことで思考が固定され、次の思考に進みやすくなる。書き出した答えを見て「それは本当か」と自問することで、思考が深まっていく。

ゼロ秒思考とイシューからはじめよの組み合わせが強力な理由は、「問いを選ぶ力」と「問いに答える力」を両方鍛えられるからだ。イシューからはじめよで「解くべき問いを選ぶ」視点を学び、ゼロ秒思考で「選んだ問いに即座に考えを展開する」訓練を積む。この2つが揃ったとき、思考の質とスピードが同時に上がり、仕事の成果に直結する変化が現れる。

この本はAudible（オーディブル）で聴くこともできます。 今なら1冊無料でお試し →

A4メモをエンジニアの仕事に組み込む方法

ゼロ秒思考のA4メモをエンジニアの日常に組み込むシーンとして最も効果的なのが、「仕事の前の3分間」だ。朝、コードを書き始める前に、その日の最重要タスクを問いの形に変換してA4に書く。「今日の認証機能実装で最もリスクのある部分はどこか」「このAPIの設計で見落としている観点は何か」という問いを立て、1分で答えを書き出す。この3分が、作業の質を上げる「設計図」になる。

コードレビューでも有効だ。レビュー対象のコードを見る前に「このPRで確認すべき最重要の観点は何か」をA4に書く。セキュリティ、パフォーマンス、可読性、テスト網羅性など、自分が確認すべき問いを先に言語化することで、レビューの漏れが減り、コメントの質が上がる。問いを先に立てることが、レビュアーとしての視点の質を高める。

思考の「堂々巡り」を断ち切る問いの立て方

「どうしよう」「うまくいかない」という漠然とした状態のとき、思考は堂々巡りに陥りやすい。このとき有効なのが、感情的な言葉を「問いの形」に変換することだ。「どうしよう」を「今の状況で最も優先すべき選択肢は何か」に変換する。「うまくいかない」を「何がうまくいっていないのか、最大の障害は何か」に変換する。問いが明確になることで、考えるべき方向が定まり、思考の堂々巡りが止まる。

問いを立てる習慣が変える、エンジニアの仕事の具体例

問いを立てることが習慣になると、仕事の様々な場面で具体的な変化が現れる。ここではエンジニアが日常的に直面するシーンにおいて、問いを立てることでどう変わるかを具体的に説明する。

コードレビューで問いを立てる

「このコードは正しいか」という問いでレビューするレビュアーと、「このコードが本番で問題を起こす可能性があるとすれば、どのようなシナリオか」という問いでレビューするレビュアーでは、指摘の質が根本的に異なる。後者の問いを持つレビュアーは、エッジケースの漏れ、スケーラビリティの問題、セキュリティの盲点を見つけやすい。レビューを始める前の2分間、「今回のPRで最も重要な確認観点は何か」を3つ書き出す習慣が、レビューの質を上げる。

設計の議論で問いを揃える

チームの設計議論がうまく進まないとき、多くの場合は「議論の前提となるイシューがチームで揃っていない」ことが原因だ。ある人は「どの技術スタックを選ぶか」を議論したいのに、別の人は「そもそもこの機能が必要かどうか」という前段のイシューを解決していない。議論を始める前に「今日の議論で解くべき問いは何か」をホワイトボードに書くことで、全員が同じイシューに向かって考え始められる。

設計議論で問いを立てる際の実践的な方法は、「今日の議論が終わったときに何が決まっていれば成功か」を最初に確認することだ。「認証方式をJWTとセッションのどちらにするかが決まること」という具体的なゴールが設定されると、議論の範囲が自然に絞られ、生産性が上がる。

キャリアの選択で問いを立てる

「次に何をすべきか分からない」というキャリアの迷いも、問いの立て方で整理できる。「自分のキャリアはどうすべきか」という広すぎる問いを、「3年後に最もやりがいを感じている状態はどんな状態か」「そのためにこの1年で習得すべきスキルは何か」という具体的な問いに分解する。ゼロ秒思考のA4メモで各問いに答えを書き出すことで、漠然とした不安が、具体的な行動計画に変わっていく。

• コードレビュー：レビュー前に「最重要確認観点3つ」を書き出す
• 設計議論：議論の前に「今日決めるべき問いは何か」をチームで揃える
• バグ調査：「このバグの本当の原因は何か」をA4に展開してから調査を始める
• 1on1の準備：「この1on1で解決すべき最大の問いは何か」を事前に言語化する
• キャリア設計：大きな問いを小さな問いに分解してA4メモで答えを展開する

問いを立てる習慣を身につける、5つの実践ステップ

問いを立てる習慣は、意識するだけでは身につかない。具体的な実践の場と繰り返しが必要だ。以下の5ステップを順番に取り入れることで、問いを立てることが無意識に行われるようになる。一度にすべてを始めようとせず、1週間に1ステップずつ取り組むことをすすめる。

ステップ1：毎朝「今日のイシュー」を1つ書く

毎朝仕事を始める前に、「今日の仕事で最も重要な問いは何か」を1つだけ書き出す。多くの問いを書こうとすると負担になるため、1つに絞る。「今日のスプリントで最もリスクのあるタスクは何か」「今日の設計レビューで最も吟味すべき観点は何か」という形で、具体的な問いの形にする。この習慣が、1日の仕事の優先順位を自然に整理する効果を生む。

この「今日のイシュー」をSlackのステータスや付箋に書いておくと、作業中に迷ったときに立ち返れる。「今日はこの問いを解くことが最重要だ」という基準が見えていると、割り込み依頼が来たときに「これは今日のイシューに関係するか」という判断も速くなる。問いが仕事の羅針盤になる。

ステップ2：ゼロ秒思考を毎朝5枚から始める

ゼロ秒思考の本来の実践は毎日10枚だが、最初は5枚から始める。A4の紙（またはメモアプリ）に、思いついた問いをタイトルに書き、1分以内に答えを3〜5個書き出す。朝の10〜15分を使うだけで、問いに即座に答える思考回路が少しずつ形成されていく。重要なのは質より継続だ。最初は答えが薄くても、続けることで答えの密度が上がる。

ゼロ秒思考のA4メモのテーマとして、エンジニアに特に有効なものを挙げると「今日のコードで最も迷っている判断は何か」「チームとのコミュニケーションで改善したい点は何か」「今週の技術的な成長につながった出来事は何か」などだ。仕事の問いを日々書き続けることで、問いを立てる感覚が日常に馴染んでいく。

ステップ3：会議の前に「この会議で解くべき問い」を書く

会議に参加する前の3分間で、「この会議が終わったときに何が決まっていれば成功か」を具体的に書き出す。この問いを持って会議に入ることで、議論が脱線したときに「今日の問いに戻りましょう」という方向修正ができる。また、議論の内容がこの問いに関係するかを常に意識できるため、会議中の発言の質が上がる。

ファシリテーターの役割がある場合は、会議の冒頭にこの問いをチームと共有する。「今日の会議で解くべき問いは〇〇です。この問いに答えることを目標に進めましょう」という宣言が、会議全体のイシューを揃える効果を生む。会議のゴールが明確なほど、参加者の発言が的を射たものになる。

ステップ4：コードレビュー前に「確認すべき問い3つ」を書く

コードレビューを始める前に、「このPRで確認すべき最重要の観点は何か」を3つ書き出す。バグの可能性、パフォーマンスへの影響、セキュリティ上の懸念、可読性、テストの網羅性などから、このPRに最も関連する観点を3つ選ぶ。問いを先に立てることで、コードを見るときの視点が定まり、漏れのあるレビューを防ぐ。

ステップ5：週次レビューで「今週立てた最良の問い」を記録する

毎週の振り返り時間に、「今週立てた問いの中で、最も仕事の質を上げた問いはどれか」を記録する。自分が立てた問いをメタ認知することで、良い問いのパターンが見えてくる。「具体的なシナリオを含む問いは答えが出やすい」「〇〇の観点から考えると視野が広がる」というパターンが積み重なると、問いの立て方そのものが洗練されていく。

この記録は3ヶ月続けると、自分の思考の特性（得意な問いの立て方と苦手な観点）が見えてくる。苦手な観点を意識的に補うことで、問いの質がさらに上がる。問いを立てる力は、反省と記録の積み重ねで育つ技術だ。一朝一夕では身につかないが、確実に成長できる。

よくある質問

まとめ：問いの質を上げることが、エンジニアとしての仕事の質を上げる

仕事の成果は「どれだけ働くか」ではなく「どれだけ良い問いを立てるか」で決まる。イシューからはじめよが教える「解く前に問いを選ぶ」という原則は、エンジニアの仕事における手戻りを減らし、最も価値ある問題に集中する力を与えてくれる。良い問いを立てることが、少ない努力で大きな成果を生む設計図になる。

ゼロ秒思考が鍛える「問いに即座に答える力」は、設計議論、コードレビュー、キャリアの選択、あらゆる場面での思考の速さと明確さを高める。A4のメモを毎日書き続けるだけで、思考の堂々巡りが減り、問いへの答えが素早く明確に出てくるようになる。この2冊の組み合わせが、問いを立てる力と考える力を同時に育てる。

イシューからはじめよも、ゼロ秒思考も、Audibleで通勤中に聴ける。繰り返し聴くことで思考の習慣が日常に染み込み、意識しなくても問いを立てるエンジニアになっていく。問いの質が変わることで、同じ時間でより深い仕事が生まれる。仕事の質を根本から変えたいエンジニアにとって、この2冊は最もコスパの高い投資になる。

※ 30日間の無料体験。いつでも解約可能。