最初の質問に答えるな
(lalitm.com)- パフォーマンスデバッグツールでは、奇妙なリクエストにはすぐ答えるよりも背景を尋ねるべきであり、そうすることでユーザーの実際の問題とツールの抜け穴が見えてくる
- これは単なる XY問題 への対応を超え、誤った質問が出てきた混乱そのものを出発点にして、ユーザーと製品の双方への理解を深められる
- Perfettoであらゆるメトリクス計算にtraceを使うやり方は、可能ではあっても 非効率 であり、専用のメトリクス収集システムのほうが適している場合がある
- trace分割の依頼のように、表面的な答えと実際の必要が異なるときは、periodic trace snapshots のような既存機能のほうがより良い道筋になることがある
- 製品変更は、繰り返し現れるニーズが十分に明らかになってから決めるほうがよく、性急な機能追加は大きな 技術的負債 につながりうる
最初の質問にすぐ答えない理由
- Perfettoのような パフォーマンスデバッグツール で、ユーザーが「Perfetto traceを複数ファイルにどう分割するのか？」のような奇妙に見える質問をしたときは、すぐに方法を示すのではなく、「なぜそんなに大きなtraceを収集することになったのか？」を先に尋ねるべき
- このアプローチは、単なる XY問題 の解決より一歩先に進む
- ユーザーの質問を「本当の意図」に置き換えて答えて終わるのではなく、誤った質問が出てきた 混乱そのもの を対話の出発点にする
- ユーザーはツールについてよりよいメンタルモデルを得られ、ツールを作った側は製品がどこで混乱を生んでいるのかをより鮮明に把握できる
- 対話の終わりに、製品自体を変えるべきだという結論に至ることもある
- これはエンジニア向けツールを作る人に特に直接的に当てはまるやり方
- コンシューマー向け製品やB2Bサービスにはそこまで直接移せないかもしれないが、基本的なアプローチはなお有用でありうる
リクエストを診断する方法
- すべての質問に深い対話が必要なわけではない
- ドキュメントを示せば済む単純で反復的な質問は、ここでの議論の対象ではない
- 興味深いのは、最初のリクエストだけでは文脈が足りず、質問自体がいつもと違って見える場合
- 奇妙な質問 では、次の基準でずれを探す
- 以前に見たことがある質問かを確認し、なければ珍しい依頼としてペースを落とす
- ほかの質問と比べて妥当かを見て、そうでなければその下により一般的な質問があるかを探す
- ツールの構造に合った依頼か、ユーザーが知らないうちにアーキテクチャと格闘していないかを確認する
- ずれを見つけたら、欠けている文脈が明らかになるよう質問する
- 即答できる答えはXだが、理由Yによってかなり奇妙な依頼に見えるので、もっと広い問題を教えてほしい、という形で対話を始める
- その後の進み方は、ユーザーが考えをどれだけうまく伝えられるかで変わる
- 対話は通常、次の3つの結論のいずれかに至る
- ユーザーがツールの 哲学 を見落としている
- 正しい道筋が製品内にあるが見つけにくい
- 製品自体を変える必要がある
ツールの哲学を見落としている場合
- ユーザーは、欲しいものや解決しようとしている問題を正確に分かっていない状態でツールを探すことがよくある
- これはユーザーを批判する意図ではない
- チームは限られた時間とリソースの中で問題を解こうとし、進展がないと新しいデバッグツールを探す
- ツールが望んでいる機能のかなりの部分を提供していても、「こう動くはずだ」というユーザーのモデルと合わなければ機能要求につながる
- Perfettoでよくある例は、traceをすべてのメトリクス計算の万能解のように見るケース
- Perfetto traceは、特定の時間区間にデバイスが何をしていたかを非常に詳しく記録する
- traceからメトリクスを計算できるため、ユーザーはフレームレートやアプリのメモリ使用量のような値もすべてtraceから計算しようとする
- 原理的には、どんなメトリクスでもtraceから計算可能
- しかし、traceですべてのメトリクスを計算するやり方は 非効率
- traceは収集と処理のコストが高い
- 単一の数値だけが必要でも、システム全体のデータを収集することになる
- 専用のメトリクス収集システムなら同じことをはるかに効率よく処理できる
- ツールには設計哲学があり、ユーザーは目先の問題に集中するあまりそれを見落としがち
- Perfettoの使い方を教えるだけでなく、パフォーマンスエンジニアリングそのものへの向き合い方を教えることが重要
- 起動時間、フレームドロップ、メモリ、電力のようなテーマをどう考え、どう扱うかを伝える必要がある
- 正常時と問題発生時の両方で、どのツールをどう使うかを理解できるようにしなければならない
正しい道筋が隠れている場合
- ユーザーが問題自体は理解していても、既存ツールをどう組み合わせればよいか分からない場合もある
- ツールは意図的に強力に作られており、別チームが機能全体の範囲をすべて理解しているとは限らない
- 実際に欲しいものを把握すると、別目的で作られた機能がユーザーの必要を満たすことは多い
- trace分割 の依頼が代表例
- ユーザーは、長いtraceの中に関心区間があり、それを切り出したいと言う
- 理由は、パフォーマンスや可視化を容易にするため
- しかしこの場合、そもそも長いtraceを収集しないやり方のほうが適しているかもしれない
- Perfettoにはすでに periodic trace snapshots がある
- 1つの長い記録ではなく、短い記録を繰り返し残す機能
- 長いtraceを収集してから分割する必要そのものをなくしてくれる
- ユーザーが尋ねた答えと、実際に必要な答えは異なることがある
- 「それこそまさに必要だった」という反応は、ユーザーが考えた依頼ではなく、実際の必要を見つけ出せたというサイン
製品を変えるべき場合
- ある種の応答は、製品の大きな変化につながる新たなニーズを明らかにする
- こうしたケースは厄介
- 依頼が新しくても、依頼者が本当に何を必要としているのかを明確に言語化できないことがある
- 基盤ソフトウェアで誤った決定を下すコストは大きい
- だからこそ、実際に不足が痛みとして現れるまで作らないほうを好む
- 複数のチームが同じ必要を語り始めると、その頃には本当に作る価値のある核が見えやすい
- 1回の依頼だけでこの核を見つけるのは非常に難しいため、待つことは強力
- Perfettoの 一時的なUIカスタマイズ は誤った決定の例
- 人々はワークフローに合わせてUIをハックしたがり、それが難しいと繰り返し不満を述べていた
- これを許可した途端、膨大な技術的負債が生まれた
- 新機能は追加されるたびに既存の全機能と相互作用しなければならず、全体構造は急速に拡張不能になった
- きちんとしたplugin APIを設計してこの問題から抜け出すまでに約1年かかった
- 実際の必要は、「すべてのユーザーに影響を与えずに、チームやユースケースに合わせてUIを個別化する方法」だった
- この必要は最初から明確に表現されていたわけではない
- リクエストの流れの中でこれを早期に捉える責任は、製品を作る側にあった
- Perfetto traceを「merge」できるようにした機能は、うまく対処した例
- 人々は繰り返し要求していたが、すぐには実装しなかった
- 回避策を案内し、観察を続ける姿勢を保った
- 正しく実装するには作業量が大きく、しかも誤って作りやすい機能だと分かっていた
- 問題空間を十分に理解したあと、昨年、保守可能な形で実装した
重要な教訓
- 最初の質問は、実際の質問ではないことが多い
- 答える前に、なぜその質問をするのかを尋ねるべき
- 場合によっては、ユーザーはツールをどう使うべきかを学ぶ
- 場合によっては、製品内の正しい道筋が隠れていることが明らかになる
- 場合によっては、まだ作る価値のあるものはないという結論に達する
- 場合によっては、次の大きな機能を二度手間ではなく一度で正しく作る準備が整う
- 単純だが見落とされやすい手法
- すばやく対応しなければならないという圧力は常にある
- 速い返答は毎回生産的に感じられる
- それでも一歩引いてみれば、ほとんどの場合、双方が最初より多くのものを得られる
1件のコメント
Lobste.rsの意見
投稿者はこの文章がXY問題よりはるかに先へ進んでいると言っているが、むしろ XY問題 をどう扱うかを興味深い洞察とともに詳しく説明した文章に見える
質問をXY問題としてフレーミングすると、XY問題らしく見える質問に答えるときに人々が使う、逆効果なヒューリスティックへと戻ってしまいがちだ
助言を求めようとして、周囲の人たちに自分がXY問題を抱えていると決めつけられ、自分の書いたことをちゃんと読んでくれる人にたどり着くまで延々と説明し続けなければならなかったことが数え切れないほどある。プログラミング文化におけるXY問題への対応は 補正が行き過ぎた状態 だと感じていて、この文章はその過剰補正への反論のように読める
質問者が自分よりずっと知らないように感じても、スピードを落としてパターンマッチングしない姿勢が重要だ。そもそもXY問題である可能性が圧倒的に高いわけでもないし、仮にそうだとしても、そうでないかのように扱ったほうがよいこともある
いい文章だった。質問された内容をもっと単純な質問に置き換えて、そちらに答えてしまわないよう気をつけるべきだ、という同じコインの裏面のような話を思い出した
たとえば「アムステルダムとサンフランシスコの距離はどれくらいですか？」という質問に、「飛行機で12時間かかります」と答えるようなものだ
質問は 距離 についてだったが、距離を知るのは難しく、飛行時間のほうがより思いつきやすいため、回答者がより簡単な質問に置き換えて答えてしまったわけだ
こういうことはかなりよく見かけるし、特に質問者と回答者のあいだに 権力距離 があるときにより起こりやすいように思う
いくつかの理由からシステムのモダナイゼーション中に ingressルーター に404ページを追加したところ、問題が起きた。ある開発者が以前の404の挙動に戻してほしいと言ってきたのだが、以前のページにはナビゲーションバーとメニューがあったからだった
さらに問い詰めると、一部の顧客設定ではログイン時に必ず404が出ており、顧客は以前の404ページを通じて実際に行くべき場所へ移動していたことが分かった
こういう瞬間のためにlolcryが発明されたんだ 🤣😭
@lalitm、この問題はインターネットより古く、すでに名前もある。つまり 要求分析 だ
Ed Yourdonらは、ユーザーが得ようとしている結果である プロセス と、その結果を得る方法である手順を区別していた。たとえば顧客に注文が発送されたと知らせるのはプロセスであり、その情報をメールで送るのは手順だ
システム利用者は解決策をそのシステムの機能のように考えがちだ。プログラマーも例外ではなく、そのため「XでYを解く」という変形が多い。アナリストの仕事は特定の実装形態から要求を抽出することであり、エンジニアとしてはその後ろにある解決策を実装すればよい
少し前に、syslog(3) が詰まってイベントがログから消えることがあるのでロギングをもっと速くしよう、という議論に参加した。しかし本当の問題はロギングを速くすることではなかった。ユーザーはより高速なロギングを求めているのではなく、問題を解決したいのだ。必要な情報を提供することがプロセスであり、すべてをログに書くのはその方法のひとつにすぎない
YourdonはCASEツールを擁護した人のひとりだった。経営陣が品質と生産性を測定できていれば成功したのかもしれないが、それはまた別の日の愚痴だ
「間違った質問を生んだその混乱自体が機会だ」と言うが、その分野の第一人者でない限り、どの質問が 間違っている のかを最初から判断するのはかなり難しい
実際には答えるべきだ
貴重な精神的資源を守る門番役をしているのでなければ、即興劇の戦術のように「はい、そして…」で進めばよい。もちろん、望む結果に到達する別の方法があるかもしれないと付け加えればいい
行き詰まりをほぐすためにひとつの戦略だけを使うのではなく、可能な戦略をすべて使うほうがよい