XY問題を超えて：最初の質問に答えない技術の芸術
ユーザーが技術的な質問をしたとき、ほとんどのエンジニアの本能的な反応は、できるだけ効率的な答えを提供することです。リクエストを解くべきパズルとみなし、ユーザーが X を欲しがっているので X への道筋を示します。しかし、他のエンジニア向けに複雑なツールを構築している人にとって、この即応性は開発者とユーザーの両方にとって機会損失になることがあります。
Perfetto（パフォーマンスデバッグツール）の開発において、Lalit Maganti は「最初のバージョンの質問には答えない」という「黄金律」を提案しています。これは「XY問題」（ユーザーが実際の問題 X ではなく、試みた解決策 Y について質問する）を回避する単純な練習のように聞こえるかもしれませんが、実際にはそれ以上のことを行います。ユーザーの混乱を障壁としてではなく、製品のメンタルモデルやアーキテクチャを洗練させる貴重な入口として扱うのです。
Ask の診断
すべての質問が深掘りを必要とするわけではありません。日常的なリクエストや単純なドキュメントの欠落は、直接リンクを示し、簡単なお礼で済ませるのが最適です。「答えない」戦略は、質問が「変」だと感じられる場合に限定されます。つまり、一般的でない、典型的な使用法と比べて不合理に思える、あるいはツールの根本的なアーキテクチャに反しているように見える質問です。
質問が深い会話に値するかどうかを判断するために、Maganti は次のチェックリストを頭に入れています：
- これは一般的か？ 頻繁に出るリクエストであれば、標準的な回答がすでに存在する可能性が高いです。そうでなければ、調査すべき異常です。
- 妥当な質問か？ リクエストが場違いに感じられる場合、背後にもっと「普通」の質問が隠れていることが多いです。
- ツールの形に合っているか？ ユーザーがツールに本来意図されていないことを強制しようとしていませんか？
不一致が見つかったら、文脈を失わずに欠けている情報を引き出すことが目標です。すぐに答えを提供しつつ、前提に疑問を投げかけます："さて、あなたの直接的な質問への答えは X ですが、Y という理由でかなり奇妙な要求です。解決しようとしているより広い問題についてもう少し教えていただけますか？"
ユーザーが哲学を見落としているとき
多くの場合、ユーザーはツールがどうあるべきかという先入観でアプローチし、設計哲学を理解しようとしません。Perfetto の場合、ユーザーはトレースをすべての指標の「聖杯」とみなし、フレームレートやメモリ使用量の算出に利用しようとします。技術的には可能ですが、トレースは取得・処理にコストがかかり、専用の指標収集システムに比べて非効率です。
深く掘り下げることで、開発者は単なるテクニカルサポート担当からドメインの教師へと変わります。たとえば、ユーザーが「大きな Perfetto トレースを複数のファイルに分割したい」と質問したとき、根底にあるニーズは「長時間録画の中で特定の期間だけを可視化したい」ことが多いです。この本質を見抜いた Maganti は、最初から巨大なトレースを作らずに済む「定期的なトレーススナップショット」機能を提案しました。
ユーザーの摩擦を製品進化に活かす
ユーザーの「変」な質問が実際に製品のギャップを露呈したとき、課題は 何を作るか を決めることにシフトします。基盤ソフトウェアに誤った機能を追加すると、技術的負債が膨らむリスクが高まります。
Maganti は Perfetto プロジェクトから二つの対照的な例を共有しています：
- 間違った道：ユーザーが UI のハックが難しいと不満を訴えたため、チームは臨時の UI カスタマイズ機能を実装しました。その結果、すべての新機能が既存のカスタマイズと相互作用しなければならず、膨大な技術負債が発生しました。実際のニーズが パーソナライズ であることが明確になるまで、適切なプラグイン API を構築するのに 1 年かかりました。
- 正しい道：ユーザーは常にトレースの「マージ」機能を求めていましたが、チームはすぐに実装せず、回避策を提示しながら問題領域を観察し続けました。この忍耐により、要件を完全に理解した上で保守しやすい形で機能を実装できました。
緊張関係：サポート vs. 高慢さ
このアプローチには批判もあります。経験豊富なユーザーが「自分の欲しいものははっきりしている」のに、余計な質問を投げかけられると苛立たれることがあります。また、Stack Overflow で見られる「答える前に三つの質問に答えよ」というような高圧的な文化と似ていると指摘されることもあります。
高慢に見えないようにするには、高い共感力とドメイン知識 が必要です。情報を隠すことが目的ではなく、協働的な発見を促すことが目的です。コミュニティでの議論でも指摘されているように、この手法の成功は以下の要素に依存します：
- まず答えを提供する：文脈を求める前に、直接的な質問への答えを必ず最初に示す。
- 聴衆を判断する：寛大に対応する。ユーザーが明らかに専門家であれば、哲学的な掘り下げは大幅に減ります。
- ユーザーに譲る：ユーザーが反論した場合、開発者はユーザーの状況判断に従うべきです。
結論
即座に反応しようとする衝動から一歩引くことで、開発者は日常的なサポートチケットを製品インサイトへと変換できます。"なぜ" を先に問うことで、エンジニアはユーザーの症状だけでなく、ツールの哲学と製品の長期的な存続性を向上させることができます。