Skip to content
Published on

コンテキストを理解しようとする質問 — 仕事の背景を掘る人

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに: 同じ仕事、違う結果

二人に同じ仕事を任せます。「決済ページにクーポン入力欄を追加してください」。一人はきれいに欄を追加します。もう一人は仕事を始める前に尋ねます。「このクーポン機能はどのキャンペーンのためですか。マーケティングの日程は決まっていますか。クーポンの種類は一つですか、複数ですか」。

数日後に結果を見ると、最初の人は欄を一つ作り、二人目はまもなく入ってくる多様なクーポン政策まで考慮した構造を作っていました。違いは能力ではなく、コンテキスト(context)を掘り下げた深さから生まれました。

仕事の背景を掘る人は、表面の要求を越えてその仕事がなぜ存在するのかを見ます。この記事はその「コンテキストを理解しようとする態度」を具体的な質問と実践で解きほぐします。

表面の要求 vs 本当の問題

すべての要求には二つの層があります。表面に現れた**要求(request)と、その下に敷かれた本当の問題(real problem)**です。コンテキストを理解するとは、この二つの層を行き来して本当の問題を見つけ出すことです。

表面の要求:  「エクセルのダウンロードボタンを追加してください」
              |
      (なぜ? どんな状況で?)
              v
本当の問題:  「チームリーダーが毎週、数値を手で報告書に書き写すのに
            金曜ごとに2時間使っている」

→ より良い解決策: ダウンロードではなく
   自動で報告書の形式に合わせてメール送信

表面だけ見る人はボタンを作り、本当の問題を見た人は毎週2時間をなくします。どちらも「仕事をした」と言えますが、生んだ価値は比較になりません。

要求を処理する人と問題を解決する人の違いは、コンテキストを尋ねるか尋ねないかで分かれます。

ビジネスの文脈を理解する

技術的な仕事ですら、結局はビジネスのある目標のために存在します。コンテキストを理解する人は、自分の仕事がその大きな絵のどこに収まるかを見ます。

ビジネスの文脈をつかむのに有用な質問です。

[バリューチェーンを尋ねる]
「この機能は結局、会社のどの指標を動かしますか
 (売上、ユーザー維持、コスト削減など)」

[ユーザーを尋ねる]
「これを実際に使う人は誰で、
 彼らが今抱える不便は何ですか」

[時点を尋ねる]
「なぜ今この仕事をするのですか。
 もっと急ぐ別の仕事はありませんか」

同じコードを書いても「この決済機能が新規登録の転換率のためのもの」と知っている人は、決済失敗時のユーザー体験により気を配ります。コンテキストを知らなければ、機能は動いても目的は外れることがあります。

ビジネスの文脈を知らないまま働くと、技術的には素晴らしいが誰も必要としない成果物が出ることもあります。精巧に作った機能がリリース後一度も使われないことは、思ったより頻繁にあります。

利害関係者と制約をつかむ

すべての仕事には、その仕事に影響を与えたり受けたりする人々、すなわち**利害関係者(stakeholder)がいます。そして仕事を取り巻く制約(constraint)**があります。この二つを知らずに始めると、作り終えた後に「これはセキュリティチームの検討が必要なのですが」といった言葉を聞くことになります。

利害関係者を素早く整理する表です。

利害関係者確認すべき質問
依頼者本当に望む結果は何か
最終ユーザー実際にどう使うのか
隣接チーム誰の仕事と噛み合うのか
意思決定者最終承認は誰がするのか
運用・サポートリリース後に誰が管理するのか

制約をつかむことも同じく重要です。制約はしばしば最初の説明から抜けますが、結果を左右します。

[よく隠れている制約]
- 締切: 「実は来週のイベントまでに必ず必要です」
- 予算: 「追加費用のかかる外部サービスは使えません」
- 規定: 「個人情報が含まれると法務検討が必須です」
- 互換性: 「旧型ブラウザも対応しなければなりません」
- 人員: 「これは私一人で保守しなければなりません」

制約を早く知れば、その中で最善の解決策を設計できます。遅く知れば、作り終えたものを作り直すことになります。

「なぜ今これを?」と尋ねる

コンテキストの質問の中で最も強力な一言は「なぜ今これをするのですか」です。この質問はいくつもの層の情報を一度に引き出します。緊急性、優先順位、そしてしばしば隠れていた本当の動機までです。

「なぜ今これを?」が引き出すもの:

- 緊急性: 今やらなければ何が起きるのか
- 優先順位: 他の仕事よりなぜこれが先か
- トリガー: 何がこの依頼を引き起こしたか
   (顧客の抗議? 競合の発売? 内部の事故?)

たとえば突然「ログイン画面を再デザインしよう」という依頼が来たとします。「なぜ今ですか」と尋ねれば、「最近、新規登録のうち30%がログイン段階で離脱するというデータが出た」という本当の背景が明らかになることがあります。この背景を知れば、単なる見た目の改善ではなく、離脱地点を減らす方向に仕事の焦点が定まります。

もちろんこの質問はトーンが重要です。「なぜわざわざ今ですか」のように聞こえると反発を招きます。「この仕事の背景を理解すればもっと良く作れそうなので」という意図を一緒に伝えれば、協力的な対話になります。

コンテキストなき実行の浪費

コンテキストを飛ばしてすぐ実行に入るのは速く見えますが、実際には最も遅い道であることが多いです。浪費はたいてい三つの形で現れます。

浪費1: 作り直し

コンテキストを知らず誤った方向で完成させた後、最初から作り直す場合です。かけた時間がまるごと消えるだけでなく、士気も共に下がります。

浪費2: 過剰または過小

本当に必要な規模を知らずに作ると、必要以上に複雑にしたり(過剰)、肝心の核心機能を抜かしたり(過小)します。どちらも高くつく失敗です。

浪費3: 間違った人のための解決策

実際のユーザーが誰かを知らずに作ると、作った人には便利だが本当のユーザーには不便な結果が出ます。

コンテキストなき実行の典型的な流れ:

要求を受ける → すぐ実行 → 完成 → 「これではない」 → 再作業
   (このサイクルが二、三度繰り返されると
    最初に5分尋ねればよかったのに、数日を失う)

コンテキストを集める方法

コンテキストは一度の質問で完成しません。複数の出所から少しずつ集めて絵を完成させる過程です。

[人から]
- 依頼者に意図と背景を尋ねる
- 以前に似た仕事をした人から経緯を聞く
- 実際のユーザーに直接不便を聞く

[記録から]
- 関連文書、過去の議事録、課題トラッカーを読む
- 過去の決定の理由が残っている場所を探す
- データ/ログで実際の使用パターンを確認する

[観察から]
- ユーザーが実際にどう使うか横で見る
- 現在の方式の不便を自分で体験してみる

良い順序はたいてい「記録を先に読み、残った空欄を人に尋ねる」ことです。文書にすべてあることを人に尋ねれば時間を奪うことになりますが、文書にない意図と文脈は人に尋ねてこそ分かります。

事例: 新人とシニアの違い

同じ課題を受けた新人とシニアのアプローチを比べると、コンテキストの力が明確になります。

課題: 「検索機能が遅いという不満があります。速くしてください」

[新人のアプローチ]
すぐコードを開いてクエリの最適化を始める。
インデックスを追加しキャッシュを付ける。
→ 検索は少し速くなったが不満は続いた。

[シニアのアプローチ]
まず尋ねる:
 「どのユーザーが遅いと言っていますか」
 「どんな検索語で遅いですか」
 「遅いとは何秒くらいを指しますか」
 「全体が遅いですか、特定の状況だけ遅いですか」
→ 実は特定の大口顧客のデータ量が多く
   その顧客の検索だけが遅かった。
   全体の最適化ではなく、その一ケースだけ解決すればよかった。

新人の能力が足りないのではありません。シニアは経験を通じて「実行前にコンテキストをつかむことが結局より速い」ことを体得しているだけです。この違いは生まれつきではなく、習慣として育てられます。

ただしバランスは必要です。コンテキストの収集が果てしない分析麻痺につながってはいけません。十分なコンテキストを集めたと判断したら実行へ移るべきです。コンテキストの理解はより良い実行のためのものであり、実行を先延ばしにする言い訳ではありません。

コンテキストの三つの層

コンテキストは一つの塊ではなく、いくつもの層からなります。各層を意識すると、何をさらに尋ねるべきかが明確になります。

[表面層] — 何を (What)
   依頼された具体的な成果物。「クーポン入力欄の追加」

[機能層] — どのように (How)
   それがどう動作すべきか。「複数のクーポン政策に対応」

[目的層] — なぜ (Why)
   究極的になぜ必要か。「再購入率を高めるキャンペーン」

ほとんどの人は表面層だけ見て仕事を始めます。仕事が得意な人は目的層まで降りて見ます。目的層を知れば、表面の要求が変わっても揺らがず本当の目標へ進めます。たとえば「クーポン欄を外してほしい」という正反対の要求が来ても、目的が「再購入率の向上」だと知っていれば、より良い代案を提示できます。

三つの層をすべて確認する簡単な質問の束です。

「何を作ればよいですか」(表面)
「それはどのように動作すべきですか」(機能)
「これで結局何を成し遂げたいですか」(目的)

暗黙のコンテキスト: 語られないこと

最も扱いにくいコンテキストは、誰も教えてくれないコンテキストです。組織には「皆が当然知っている」と仮定され明示されない規則、歴史、政治的力学があります。新人がよくつまずく地点がまさにここです。

[よくある暗黙のコンテキストの例]
- 「その機能は以前試して大きく失敗した」
- 「この領域はAチームの縄張りなので先に相談すべき」
- 「顧客Bのためにこの制約は絶対に変えられない」
- 「このコードはまもなく廃棄予定なので触ってはいけない」

こうしたコンテキストは文書にほとんどありません。だから尋ねねばなりません。特に新しい環境に入ったときは、こう尋ねるとよいでしょう。

「私の知らない経緯がありそうですが、
 この仕事に関して前もって知っておくべき背景はありますか」
「以前に似た試みはありましたか。あったならどうなりましたか」

暗黙のコンテキストを速く吸収する人は同じ失敗を繰り返さず、地雷原を避けて通ります。これは賢さの問題ではなく、謙虚に尋ねる態度の問題です。

コンテキスト質問を投げるタイミング

良いコンテキスト質問もタイミングが外れると効果が落ちます。早すぎて一度にあふれさせると相手が負担に感じ、遅すぎて尋ねるとすでに誤った方向に仕事が進んだ後です。

[最も良いタイミング]
- 仕事を受けた直後、手をつける前(方向設定)
- 最初の小さな成果物を見せるとき(早期検証)
- 重要な分岐点に達したとき(再確認)

[避けるタイミング]
- 作り終えた直後(すでに遅い)
- 相手が明らかに忙しい危機の瞬間(例外: 危機そのものに関する質問)

特に効果的なのは早期検証です。完璧に作り終えてから見せる代わりに、粗くても速く作って「この方向で合っていますか」と早く確認することです。このときズレが見つかれば損失は小さいです。コンテキスト質問は最初の一度で終わるのではなく、仕事が進む間にいくつかの点検地点で繰り返されるべきです。

方向確認 → 小さく作る → 「これで合っていますか」 → 補完 → 小さく作る → ...
   (この短いループが大きなズレを前もって防ぐ)

コンテキストを文書に残す

コンテキストをうまく収集することと同じくらい重要なのが、それを残すことです。苦労して把握した背景が一人の頭の中だけにあれば、次の人は同じ発掘作業を最初からやり直さねばなりません。良いチームはコンテキストを文書に残し、資産として蓄積します。

特にある決定を下すとき「なぜこう決めたのか」を一緒に記録すれば、未来の同僚が同じ論争を繰り返しません。

[決定記録に残すとよいこと]
- 背景: どんな問題を解こうとしたか
- 検討した代替案: どんな選択肢があったか
- 決定: 何を選んだか
- 理由: なぜそれを選んだか
- 制約: どんな限界の中で決めたか

こうした記録が積み重なれば、新しく加わった人も文書だけでコンテキストの相当部分を吸収できます。「なぜ私たちはこんな奇妙な方式を使っているのか」という質問の答えが記録に残っていれば、無知から来る誤った改善の試みを防げます。

コンテキストを残すことは、未来の自分と同僚への贈り物です。今5分かけて決定の背景を書いておけば、数か月後に誰かの一日を節約できます。

コンテキスト理解の成熟度の段階

コンテキストを扱う能力は一度に完成せず、段階的に育ちます。自分が今どの段階にいるか分かれば、次の成長の方向が見えます。

[段階1: 言われたとおり]
要求をそのまま実行する。コンテキストを尋ねない。

[段階2: 表面の質問]
曖昧な部分を尋ね始める。しかし表面の要求にとどまる。

[段階3: 意図の把握]
要求の裏の本当の問題を尋ねる。より良い代案を提示する。

[段階4: コンテキストの定義]
与えられたコンテキストを越え、自ら問題を定義しコンテキストを作る。

段階1から段階2へ行くのは比較的簡単です。知らないことを尋ね始めればよいのです。本当の飛躍は段階2から段階3へです。表面を越えて意図を見ようとする意識的な努力が必要です。そして段階4はシニアとリーダーの領域です。ここでは誰かがコンテキストを与えてくれるのを待たず、曖昧な状況で自ら「今、本当に重要な問題は何か」を定義します。

段階受ける質問投げる質問
段階1「終わった?」(質問なし)
段階2「これ合ってる?」「これはどうやるのですか」
段階3「なぜこれがより良い?」「これで何を成し遂げようとするのですか」
段階4「次に何をすべき?」「私たちが今解くべき本当の問題は?」

重要なのは、段階が能力の優劣ではなく経験と態度の蓄積だという点です。誰もがコンテキストを尋ねる小さな習慣から始めて、上の段階へ上っていけます。

事例: コンテキストが結果をひっくり返した瞬間

小さな逸話でコンテキストの力を締めくくります。あるチームが「検索結果をもっと速く見せてほしい」という依頼を受けました。表面だけ見れば性能最適化の課題でした。

[表面アプローチ]
「検索速度を0.5秒縮めよう」
→ エンジニアが数日インフラを手直し。
→ 実際に0.4秒速くなった。だがユーザー満足度はそのまま。

[コンテキストアプローチ]
まず尋ねる:
 「ユーザーが『遅い』と感じる本当の瞬間はいつか」
 「遅いのが問題か、待つ間の空白画面が問題か」
→ 調査の結果、実際の速度より『何も見えない空白画面』が
   もどかしさの原因だった。
→ ローディング中に骨格画面(スケルトン)を見せると
   体感速度が大きく改善し満足度が上がった。

ここで驚くべき点は、コンテキストアプローチがむしろより少ないコストでより大きな効果を出したことです。インフラを数日かけて作り直す代わりに、本当の問題を把握して小さな画面変更一つで解決しました。コンテキストの理解は単に仕事を慎重にするだけでなく、時にはるかに効率的な近道を見つけてくれます。

これがコンテキスト質問の本当の価値です。「何をもっと速く作るか」ではなく「本当の問題は何か」を尋ねれば、ときには作らなくてよい道まで見えます。最も速いコードは書かなくてよいコードです。

コンテキスト収集の罠とバランス

コンテキストを強調すると、反対方向の罠に陥ることがあります。バランスのため押さえておきます。

[罠1: 分析麻痺]
完璧なコンテキストを待って永遠に始められない。
→ 解決: 「今知っていることでひとまず小さく始め」
       やりながらコンテキストを補う。

[罠2: 過度な質問公害]
些細なことまで全部尋ね、相手を疲れさせる。
→ 解決: 文書で分かることは先に探し、
       本当に人だけが知ることだけ尋ねる。

[罠3: コンテキストの言い訳]
「コンテキストを知らないからできない」と実行を先延ばし。
→ 解決: 知らないままでも合理的な仮定を立て
       「こう仮定して進めます」と知らせる。

コンテキストの理解はより良い実行のための道具であり、実行の代わりではありません。十分に分かったら動かねばなりません。完璧なコンテキストは存在せず、仕事をしながら埋まる部分が常にあります。核心は「致命的な空欄」だけ前もって埋め、残りは実行しながら学ぶことです。

おわりに: 背景を掘る人が信頼を得る

コンテキストを掘り下げる人は、最初は仕事が遅く見えます。質問が多く、すぐ手を動かさないからです。しかし時間が経つと評判が分かれます。「あの人は言われたことだけやるのではなく本当の問題を見る」という信頼が積み上がります。そしてこの信頼は、より重要で曖昧な仕事、つまり自らコンテキストを定義しなければならない仕事を任される通路になります。

結局、コンテキストを理解しようとする質問は、仕事を上手にこなす技術であると同時に、より大きな仕事を任される成長のはしごです。次に仕事を受けたら、手を動かす前に一度尋ねてみてください。「この仕事はなぜ存在するのだろう」。

実践チェックリスト

[ ] 表面の要求の裏にある本当の問題を探す。
[ ] この仕事がどのビジネス指標を動かすか尋ねる。
[ ] 実際の最終ユーザーが誰か確認する。
[ ] 利害関係者のリストを素早く整理する。
[ ] 隠れた制約(締切/予算/規定)を前もって掘り出す。
[ ] 「なぜ今これを?」を協力的なトーンで尋ねる。
[ ] 記録を先に読み、残った空欄だけ人に尋ねる。
[ ] 可能ならユーザーが使う様子を直接観察する。
[ ] 十分なコンテキストを集めたら分析麻痺なく実行する。

参考資料

Discuss on Twitter • View on GitHub