FDEの観察法｜シャドーイングと文脈的質問法で「説明されない手順」を拾う

こんにちは、株式会社TIMEWELLの濱本です。

FDE実践シリーズの2本目です。前回のインタビュースキルの記事で、私は「インタビューは観察の前座だ」と書きました。今回はその本番、観察の話をします。

現場に入って聞くだけで済むなら、エンジニアが工場や事務所に座り続ける必要はありません。座り続ける理由は、聞いても出てこないものがあるからです。担当者が毎日やっているのに、聞かれると思い出せない手順。それは付箋に書かれた例外ルールであり、Excelの隠し列であり、システムに入力する前に電話で確認する一手間です。この記事では、そうした「説明されない手順」を拾うための観察法を、当社のエンジニアが現場で使っている順に書きます。自社のチームが現場をどこまで見られているかを先に確かめたい方は、AIリテラシー診断を使ってください。

聞くだけでは半分。観察が拾う「説明されなかった手順」

なぜ聞くだけでは足りないのか。理由は、人が自分の行動を正確に語れないからです。これは担当者の怠慢ではなく、記憶の性質です。ユーザー調査の実務では、フィールドで実際の行動を見ることの価値が繰り返し説かれていて、人が語る行動と実際の行動はしばしばずれる、というのがその根拠になっています¹。

Palantirで8年間FDEを務めた人物は、この職種の根本にある考えを「文脈こそが希少だ」という一言で表しています。顧客の現場に行くことで、要件の一覧という平たい形ではなく、その人たちがどう働いているかという暗黙知を取りに行く、と²。彼が最初に配属された航空機メーカーでは、1年間工場に通い、週4日を製造の現場で過ごしたと書いています。エンジニアが1年間工場にいた理由は、聞くためではなく、見るためです。

もっと古い例もあります。トヨタ生産方式を作った大野耐一氏は、工場の床にチョークで円を描き、管理者をその中に立たせて、何時間も作業を見させたと伝えられています。「何が見えたか」と問い、見えていなければ「もっと見ろ」と言った、という話です³。当社のエンジニアは、現場でチョークの円を描きはしませんが、やっていることは同じです。作業者の斜め後ろに座り、口を挟まず、同じ作業を何度も見ます。

観察で拾えるものを、私は四つに分けています。手順の順番、手順の間の待ちと移動、手順の外にある確認、そして手順を飛ばす判断です。インタビューで出てくるのは最初の一つだけで、残りの三つは見ないと分かりません。

観察法は3つ。シャドーイング、文脈的質問法、思考発話

観察法と一口に言っても、やり方によって拾えるものが違います。当社が使い分けている3つを表にします。

方法	やること	拾えるもの	使う時期
シャドーイング	担当者の後ろについて回り、口を挟まずに一日を見る	業務の全体像、移動と待ち、説明に出ない確認	初日
コンテクスチュアル・インクワイアリー（文脈的質問法）	作業の場に同席し、作業を見ながらその場で質問する	手順の理由、判断の基準、例外の扱い	2日目以降
思考発話	作業しながら考えていることを声に出してもらう	画面のどこを見て何を迷っているか	動くものを置いた後

シャドーイングは、文字どおり影のように後ろをついて回る方法です。初日に使います。目的は地図を作ることで、口を挟みません。担当者が席を立って隣の課に行くなら一緒に行きます。電話をかけるなら、電話の後に「いまのは何の確認でしたか」と一言だけ聞き、それ以上は掘りません。掘るのは2日目からです。シャドーイングで大事なのは、移動と待ちを記録することです。「承認待ちで20分」「印刷した紙を持って別のフロアへ」。この時間は、担当者の説明には出てきません。本人にとっては仕事のうちに入っていないからです。しかし、FDEが最初に作るべきものは、たいていこの時間の中にあります。

コンテクスチュアル・インクワイアリーは、日本語にすれば文脈的質問法で、ユーザー調査の手法として体系化されています。特徴は、作業の場に行き、作業しているところを見ながら、その場で質問することです。よく師匠と弟子の関係にたとえられます。弟子は師匠の仕事を横で見ながら、「いまなぜそうしたんですか」と聞く。師匠は仕事を止めずに答える。この関係を作ると、担当者は「教える側」になり、あるべき手順ではなく実際の手順を見せてくれます⁴。当社のエンジニアが2日目以降に使うのはこの方法で、前回の記事で書いた深掘りインタビューを、会議室ではなく作業の場でやる、と考えてもらえばよいと思います。

思考発話は、作業しながら考えていることを声に出してもらう方法で、ユーザビリティ調査の基本手法として知られています⁵。FDEの現場では、動くものを置いた後に使います。「この画面を使って、いつもの作業をやってみてください。思ったことをそのまま声に出してください」。担当者が画面のどこで止まり、何を探し、どこで「あれ」と言うかが分かります。前回書いた検証インタビューの「何が違いますか」を、言葉ではなく動作で取る方法です。

3つに共通するのは、会議室ではなく作業の場で行うことと、担当者の時間を長くは取らないことです。シャドーイングは担当者の時間をほぼ使いません。文脈的質問法は作業の合間の数十秒を積み重ねます。思考発話は10分あれば足ります。前回書いたとおり、現場の担当者に60分はありません。

FDEの観察は「作るための観察」。受託の現状調査との違い

ここで、受託開発との違いをはっきりさせておきます。受託開発にも現状調査（As-Is分析）はあります。業務フロー図を描き、課題を一覧にし、提案書にまとめます。動作だけ見ると観察と同じです。違うのは、観察した後に何をするかです。

観点	受託開発の現状調査	FDEの観察
目的	提案と見積の根拠を作る	翌日に置く「動くもの」を決める
成果物	業務フロー図、課題一覧、提案書	例外ノートと、動くものの次の版
期間	調査フェーズとして区切り、終わったら設計へ	実装と並行して続き、終わらない
観察した例外の扱い	要件として合意し、見積に入れる	その場で作り、型なら製品へ、枝なら枝として管理する
観察する人	調査担当（多くは実装しない）	実装するエンジニア本人

受託の現状調査は、後の工程のために行います。だから調査担当と実装担当が分かれていても成り立ちます。FDEの観察は、翌日に置くものを決めるために行います。だから見る人と作る人は同じ人でなければなりません。金曜に観察で見つけた「承認待ちの20分」を、月曜に動くものにして担当者の前に置く。この往復ができるのは、観察したエンジニアがそのまま作るからです。a16zは2026年1月の論考で、FDEの型を見分けるテストとして「成熟した顧客で工数が減っているか」を挙げていますが⁶、観察が実装に直結していれば、同じ型の観察は次の顧客では要らなくなります。次の顧客では、製品がすでにその手順を知っているからです。

もう一つの違いは、観察した例外をどう扱うかです。受託なら、例外は要件として合意し、見積に入れ、契約で固定します。FDEでは、例外はその場で作ります。そして週に一度、この例外がこの会社だけの枝か、他社にもある型かを分けます。型なら製品の標準機能に返し、枝なら枝として記録します。Palantirの元FDEは、FDEの仕事を「その問題を解くことで、一般化は気にしない。一般化は製品チームの仕事だ」と書いていますが²、当社は小さな会社なので、観察したエンジニアが製品も書きます。分ける判断を、同じ人が週次でやる形です。

現場での手順。座る場所、見るもの、書くもの

具体的に書きます。当社のエンジニアが現場で観察するときの手順です。

座る場所は、担当者の斜め後ろです。真後ろは圧迫感があり、隣は画面が見えません。斜め後ろなら、画面と手元の紙と表情が同時に見えます。初日にまず頼むのは、「いつもの作業を、いつもどおりやっているところを横で見せてください」の一言です。見せてもらう前に、評価に来たのではなく学びに来たこと、見たことは動くものにして返すことを、本人に伝えます。

見るものは、画面、手、紙、移動の四つです。画面はどのシステムのどの画面か、切り替えの順番、コピーして貼る動作。手はキーボードとマウス以外に何を触っているか、電卓、付箋、印刷物。紙は机の上と引き出しの中にある帳票と、そこに書き込まれたメモ。移動は席を立つ理由と行き先です。この四つのうち、インタビューで出てくるのは画面の一部だけです。

書くものは、時刻、動作、画面、発話、違和感の五列です。時刻は分単位で、待ちと移動の長さが後で分かるようにします。動作は「承認画面を開く」のように動詞で書きます。画面はシステム名と画面名。発話は担当者が口にした言葉をそのまま。そして違和感の列には、「説明では課長承認と言っていたが係長の名前が入っている」のように、聞いた話と見たものの差を書きます。この五列目が、翌日に作るものの候補です。前回の記事で「研修では身につかなかった」と書いた、ずれに気づく目は、この列を毎日書くことで育ちました。

観察で困るのは、見られていると人の動きが変わることです。ホーソン効果と呼ばれる現象で、その実在と大きさについては研究でも議論が続いていますが、観察されることで行動が変わりうること自体は、調査の設計で考慮すべきとされています⁷。当社の対処は三つです。初日に評価ではないと伝えること。同じ作業を別の日にもう一度見ること。そして、観察の結果を翌日には動くものにして本人に返すことです。三つ目がいちばん効きます。自分の仕事が動くものに変わるのを見ると、担当者は見せるための仕事ではなく、本当の仕事を見せてくれるようになります。

口を挟むかどうかは、方法で決めます。シャドーイングでは挟みません。文脈的質問法では挟みます。ただし、作業を止めさせてはいけません。質問は作業の切れ目に短く、「いまの確認は誰にでしたか」で終わり、答えが長くなりそうなら「後で聞かせてください」と切ります。休憩時間と昼食は、観察ではなく雑談の時間にします。雑談で出てくる「実はあの帳票、誰も見てないんですよ」は、どの観察法でも拾えません。

現場でよく見る4つの型

守秘の関係で個別の案件は書けませんが、当社のエンジニアが現場で繰り返し見てきた型を、一般化して四つ挙げます。どれも、担当者へのインタビューでは出てこず、観察で初めて見つかったものです。

一つ目は、二重入力です。基幹システムに入力した内容を、別のExcelにもう一度入力しています。理由を聞くと、Excelのほうが集計しやすいから、あるいは以前のシステムのときからの習慣だから、と返ってきます。本人はこれを「仕事」と思っていないので、説明には出てきません。

二つ目は、入力前の確認です。システムに入れる前に、隣の席か電話で確認しています。確認の相手が休みだと、その日は入力が止まります。この確認の中身が、システムに書かれていない判断基準です。

三つ目は、印刷して運ぶ動作です。画面で完結するはずの承認が、紙に印刷され、別のフロアに運ばれ、押印されて戻ってきます。承認画面はあるのに、使われていません。理由を聞くと、承認者が画面を見ないから、と返ってきます。

四つ目は、飛ばす判断です。手順書には確認の工程があるのに、慣れた担当者はそこを飛ばしています。飛ばしても問題が起きないことを本人が経験で知っているからです。この判断は、手順書にもマニュアルにも書かれていませんが、その人が休むと新人が守って時間がかかります。

四つに共通するのは、担当者にとって当たり前すぎて言葉にならないことです。そして、FDEが最初に作るべきものは、たいていこの四つのどれかにあります。二重入力をなくす、確認の基準を画面に出す、承認者が見る場所に承認を置く、飛ばしてよい条件を明示する。どれも大きな機能ではありませんが、担当者の一日を変えます。

当社の実践と限界。観察は時間がかかる

正直に書きます。観察は時間がかかります。シャドーイングは一日、文脈的質問法は数日、同じ作業を二度見るならさらに数日です。エンジニアの時間を現場で使うことには、抵抗があって当然です。動くものを作りたいエンジニアにとって、何も作らずに座っている一日は長く感じます。それでも当社が続けているのは、観察の一日が、その後の手戻りの一週間を消すからです。見ずに作ったものは、担当者の前に置いた瞬間に「うちの現場では使えない」と言われます。見てから作ったものは、「ここが違う」で済みます。

限界もあります。観察できるのは、観察した日の、観察した人の仕事だけです。月末だけ起きる処理、年に一度の締め、その人が休んだ日の代替手順は、見られません。だから観察と前回のインタビューは組み合わせます。見た手順について「これは毎日ですか、月末は違いますか」と聞き、見られない手順は出来事として聞きます。

守秘と同意も限界です。観察は、担当者の仕事ぶりを見ることなので、本人と上長の了解が要ります。当社は初回の打ち合わせで、誰の作業を、いつ、何のために見るか、記録をどう扱うかを決めてから現場に入ります。記録に個人の評価につながる内容を書かないこと、記録は動くものを作るためにだけ使うことを、先に約束します。この約束が、次の記事で扱うビデオ撮影とAI分析では、さらに重くなります。

まとめ

インタビューで聞けるのは、現場の仕事の半分です。残りの半分は、担当者が説明できない手順の中にあり、見るしかありません。観察法は3つ。初日はシャドーイングで地図を作り、2日目以降は文脈的質問法で理由と基準を掘り、動くものを置いた後は思考発話で動作を取ります。座る場所は斜め後ろ、見るものは画面と手と紙と移動、書くものは時刻と動作と画面と発話と違和感の五列です。

FDEの観察が受託の現状調査と違うのは、見た人がそのまま作ることです。金曜に見つけた「承認待ちの20分」を月曜に動くものにする。この往復があるから、観察は調査フェーズではなく、実装の一部になります。

現場を見る目をエンジニアのチームにつけたい方、あるいは自社の現場にFDEを受け入れる準備をしたい方は、WARPのプログラムをご覧いただくか、個別相談でお話ししましょう。次の記事では、観察をさらに長く、深くする方法として、ビジネス・エスノグラフィーを扱います。

Footnotes

1. Field Studies（Nielsen Norman Group）。実際の環境で行動を観察することの価値と、自己申告と実際の行動のずれについては同記事による ↩

2. Reflections on Palantir（Nabeel S. Qureshi、2024年10月15日）。「context is that which is scarce」、航空機メーカーの工場で1年間週4日を過ごした記述、FDEと製品チームの分業は同稿による（筆者訳） ↩ ↩²

3. Taiichi Ohno's Chalk Circle（AllAboutLean.com、Christoph Roser）。チョークの円の逸話は元トヨタ関係者の証言として伝えられているもので、同記事による ↩

4. Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context（Nielsen Norman Group）。師匠と弟子の関係になぞらえる説明は同記事による ↩

5. Thinking Aloud: The #1 Usability Tool（Nielsen Norman Group） ↩

6. The Palantirization of everything（Marc Andrusko、a16z、2026年1月16日） ↩

7. McCambridge, J., Witton, J., & Elbourne, D. R. (2014). Systematic review of the Hawthorne effect: New concepts are needed to study research participation effects. Journal of Clinical Epidemiology, 67(3), 267–277. PubMed ↩