問いの設計力：曖昧な課題を解ける形に変換するエンジニアの思考技術
概要¶
「問いの設計」とは、曖昧な課題を目的・制約・前提に分解し、何を明らかにすれば意思決定できるかを定める力。良い問いは仮説と検証方法を伴い、解法に飛びつく前に問題の輪郭を整える。エンジニアリング以外でも生きるスキルとして4冊の本を紹介。
詳細¶
「問いの設計」とは¶
nwiizo の定義:
「問いの設計とは、曖昧な課題を目的・制約・前提に分け、
何を明らかにすれば意思決定できるかを定める力です。
良い問いは仮説と検証方法を伴い、
解法に飛びつく前に問題の輪郭を整え、
複雑さを扱える形へ変換します。
そのため、エンジニアリング以外の場面でも生きます。」
なぜエンジニアに「問いの設計力」が必要か¶
よくある失敗パターン:
「〇〇機能を作ってほしい」という依頼
→ すぐに実装を始める
→ 完成したが「これじゃない」と言われる
→ 手戻り発生
問いの設計ができる人:
「なぜこの機能が必要なのか？」
「誰のどんな問題を解くのか？」
「成功の定義は何か？」
「やらない場合のコストは？」
→ 本当に解くべき問題を特定してから実装する
問いを設計する3つの要素¶
1. 目的：何のためか¶
曖昧な問い: 「パフォーマンスを改善したい」
目的を明確にした問い:
「DAU 10万人のユーザーが使うAPIで、
P99 レスポンスタイムを現在の 800ms から 200ms 以下にしたい。
理由はユーザーの離脱率が高く、計測の結果レスポンスと相関があるから」
2. 制約：何はできないか¶
「時間・予算・技術・人員の制約」を明確にする
制約なしの問い: 「最高のシステムを作りたい」
制約あり: 「3ヶ月・2人のチームで、既存のRailsアプリに手を加えずに改善する」
→ 制約があることで「解き方の空間」が絞られる
3. 前提：何を仮定しているか¶
前提を明示しないと:
開発者「スマホから使うものとして設計しました」
PM「PCからも使えないといけないのに」
→ 前提のすれ違いで設計が全て崩れる
前提の確認リスト:
・誰が使うか（ユーザー属性）
・どの環境で使うか（デバイス・ネットワーク）
・どのくらいの頻度で使うか（トラフィック規模）
・いつまでに必要か（タイムライン）
「仮説と検証」の問いの立て方¶
悪い問いの立て方:
「なぜこのバグが起きているのか？（答えが見つかるまでデバッグ）」
良い問いの立て方:
「仮説1: DBの接続プールが枯渇している（確認方法: メトリクスを見る）」
「仮説2: N+1クエリが発生している（確認方法: スロークエリログ）」
「仮説3: 特定のユーザーのリクエストが重い（確認方法: ログでユーザーID絞り込み）」
→ 最も可能性が高い仮説から検証する
関連書籍（nwiizo 推薦4冊）¶
- 「新 問いかけの作法」 - 良い問いを立てるための実践的な方法論
- 「問いのデザイン: 創造的対話のファシリテーション」 - チームで問いを共有するための技術
- 「仮説行動――マップ・ループ・リープで学びを最大化し、大胆な未来を実現する」 - 仮説を行動に変える思考法
- 「仮説思考 BCG流 問題発見・解決の発想法」 - BCG式の問題発見・仮説構築フレームワーク
システムデザイン面接での応用¶
面接でよく見られる失敗:
「URLショートナーを設計してください」
→ すぐにアーキテクチャを描き始める
問いの設計ができる候補者:
「DAUはどの程度ですか？」
「読み書きの比率は？」
「URLの有効期限は必要ですか？」
「分析機能（クリック数など）は必要ですか？」
→ 要件を明確にしてから設計する
= 面接で高い評価を得る行動
なぜ重要か / いつ使うか¶
- 「何を作ればいいかわからない」という状況に陥ったとき
- チームで議論が発散してまとまらないとき
- システムデザイン面接の要件定義フェーズ
- 技術的負債の原因を遡るとき（問いが曖昧だったことが多い）