FDEとKJ法｜現場の断片を構造に変える手順と、AIと分担する境界

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

FDE実践シリーズの4本目です。ここまでの3本で、聞く、見る、いるという三つの技術を書きました。どれも、現場から断片を集める技術です。集めた断片は、逐語録の束、五列の観察記録、三層のノートという形で手元に残ります。1週間で数百の断片になります。

問題は、この断片がそのままでは実装に使えないことです。どれを最初に作るのか。どれがこの会社だけの話で、どれが他社にもある型なのか。断片を眺めていても答えは出ません。断片を構造に変える工程が要ります。当社のエンジニアがこの工程で使っているのが、文化人類学者の川喜田二郎が野外調査のために作ったKJ法の考え方です。この記事では、その手順を現場のメモを材料にして書き、AIに任せる工程と人が残す工程の境界、そして受託の要件整理との違いを扱います。自社のチームが現場の断片をどこまで構造にできているかを先に確かめたい方は、AIリテラシー診断を使ってください。

KJ法とは何か。野外調査から生まれた「断片から立ち上げる」方法

KJ法は、川喜田二郎がヒマラヤやネパールでの野外調査で集めた膨大な断片をまとめるために作った方法で、1967年に中公新書から出た『発想法』で広く知られるようになりました¹。名前は考案者の頭文字から来ています。株式会社川喜田研究所の登録商標で、正式な研修とセミナーは同社が行っています²。この記事で書くのは、その考え方に学んで当社のエンジニアが現場で使っている実務であって、同社の研修の代わりではありません。方法の本質を学びたい方は、原典と同社の研修にあたってください。

方法の骨格は、私の言葉で言えば四つの工程です。集めた断片を一枚一句でカードに書く。カードを広げ、内容が近いものを寄せて小さな束を作り、束に一行の名前をつける。束同士の関係を、空間に配置して線や矢印で図にする。最後に、図を文章にして人に伝えられる形にする。川喜田自身は晩年のインタビューで、この方法の核心を、あらかじめ持っている枠に断片を仕分けるのではなく、断片の側から語らせることにあると述べています³。

ここが、他の整理法との違いです。多くの整理は、先に枠を作ります。「課題」「要望」「制約」という見出しを立て、断片をそこに入れる。これは速いのですが、枠に入らない断片が捨てられます。KJ法の考え方では、枠を先に作りません。断片を眺め、近いものを寄せ、寄った後で名前をつけます。だから、想定していなかった枠が生まれます。FDEにとって価値があるのは、この想定していなかった枠です。想定していた枠は、会議室でも作れます。

この方法は品質管理の分野にも取り入れられ、新QC七つ道具の一つ「親和図法」として知られています。英語圏ではアフィニティ・ダイアグラムと呼ばれ、ユーザー調査の実務で、インタビューの断片を構造にする定番の方法になっています⁴。名前は違いますが、断片から立ち上げるという考え方は同じです。

FDEの金曜日。一週間の断片を四つの工程で構造にする

当社のエンジニアが現場でこの方法を使うのは、金曜の午後です。月曜から木曜に集めた断片を、翌週に何を作るかの判断に変える時間です。手順を、材料と一緒に書きます。

材料は三つです。1本目の記事で書いたインタビューの逐語録、2本目の観察の五列の記録、3本目のエスノグラフィーの三層のノート。合わせて、1週間でおよそ数百の断片になります。

第一の工程は、一枚一句のカード作りです。逐語録から、担当者の発言を一つの内容につき一枚に切り出します。「承認は課長がします」「でも急ぎのときは係長が押します」は、二枚です。観察記録からは、五列目の違和感を一枚ずつ起こします。「説明では課長承認だが、画面には係長の名前」。ノートからは、「普通は」「うちでは」の後に来た言葉を起こします。カードには、誰が、いつ、どの場面で、という出所を小さく添えます。後で「この束は営業だけの話か、全社の話か」を確かめるためです。

第二の工程は、似たもの集めです。カードを広げ、内容が近いものを寄せます。ここで大事なのは、寄せる基準を「語」ではなく「意味」にすることです。「承認」という語が入っているカードを集めると、押印の話と画面操作の話が混ざります。逆に、「係長が押す」と「課長は細部を見ない」は語が違いますが、意味は近いのです。この近さは、現場にいた人にしか分かりません。束は小さく作ります。二枚から五枚で、十枚を超えたら分けます。そして束に一行の名前をつけます。名前は要約ではなく、束が語っていることです。「承認の実態は、係長の判断と課長の押印の二段になっている」。

第三の工程は、図解です。束を机の上に配置し、関係を線で結びます。原因と結果、対立、前後。「承認が二段になっている」という束と、「急ぎの案件は紙で回る」という束の間に線が引けたら、それは「画面の承認フローが急ぎに対応していないから、紙が残っている」という構造です。この構造が見えた瞬間に、翌週に作るものが決まります。画面の承認を直すのではなく、急ぎのときの経路を画面に作ることです。

第四の工程は、文章化です。図を、担当者と自社のチームに伝えられる文章にします。当社では、これを二種類書きます。一つは担当者向けで、「来週、急ぎ案件の承認経路を画面に作ります。理由は、いまの紙の経路が係長判断を前提にしているからです」という一段落。もう一つは自社向けで、「急ぎ案件の別経路は、この会社だけの枝か、他社にもある型か」という判断を書きます。この二つ目が、FDEにとってのKJ法の出口です。

型か枝か。束の名前を製品に返す

ここで、FDEがこの方法を使う目的を、はっきりさせておきます。断片を整理するためではありません。整理は手段で、目的は、束の名前を「この会社だけの枝」と「他社にもある型」に分け、型を製品に返すことです。

Palantirで8年間FDEを務めた人物は、FDEの仕事を、目の前の問題を解くことで、一般化は製品チームの仕事だと書いています⁵。当社は小さな会社なので、この二つを同じエンジニアがやります。そのとき、一般化の判断をどこでやるかが問題になります。断片のままでは判断できません。束の名前になって初めて、「これは他社でも見た」と言えます。「承認が二段になっている」は、私たちが複数の会社で見た型です。だから製品側では、承認の段数と、段ごとの判断者を設定できるようにします。「急ぎ案件は紙で回る」も型です。「その紙を経理の田中さんが預かる」は枝です。枝は記録して、製品には入れません。

a16zは2026年1月の論考で、FDEの型を見分けるテストの一つに、カスタマイズに「No」と言えるかを挙げています⁶。「No」と言うには根拠が要ります。根拠は、束の名前です。「これは御社だけの枝なので、製品には入れません。代わりに設定で吸収します」と言えるのは、金曜に束を作り、名前をつけ、型と枝に分けたからです。断片のまま持ち帰ると、全部作るか、全部断るかしかできません。

そして、この判断は週次でやります。月に一度まとめてやると、束が大きくなりすぎて、型と枝の境目が見えなくなります。週に一度、数百の断片を数十の束にし、束の名前を数個の型と数個の枝に分ける。この繰り返しが、現場の学びを製品に返す還流の中身です。

受託の要件整理との違い

受託開発にも、ヒアリングの結果を整理する工程はあります。要件一覧を作り、優先度をつけ、見積に入れます。動作だけ見ると、断片を整理する点は同じです。違いを表にします。

観点	受託の要件整理	FDEの構造化
枠	先に作る（機能一覧、課題一覧）	断片から立ち上げる
単位	要件（機能の単位）	束の名前（現場の実態の単位）
判断	優先度と見積	型か枝か
出口	要件定義書、契約	翌週に作るものと、製品に返す型
頻度	要件定義フェーズで一度	毎週

いちばん大きな違いは、枠を先に作るかどうかです。受託の要件整理は、機能一覧という枠を先に作り、ヒアリングの断片をそこに仕分けます。仕分けられない断片は落ちます。「急ぎのときは係長が押す」は、機能一覧のどこにも入らないので、要件定義書には残りません。そして本番で、急ぎの案件が画面で止まります。

FDEの構造化は、枠を作らずに断片から束を立ち上げるので、「急ぎのときは係長が押す」が束になり、名前がつき、翌週に作るものになります。受託で落ちる断片が、FDEでは最初に作るものになります。この逆転が、断片から立ち上げる方法を使う理由です。

もう一つの違いは、出口です。受託の要件整理の出口は要件定義書と契約で、そこで確定します。FDEの構造化の出口は翌週に作るものと製品に返す型で、毎週更新されます。確定しないことを不安に思う方もいると思いますが、現場の実態は毎週変わるので、毎週更新されるほうが実態に近いと私は考えています。

AIに任せる工程と、人が残す工程

四つの工程のうち、当社がAIに任せているのは、第一の工程の大半と、第二の工程の前半です。

第一のカード作りは、逐語録と観察記録をAIに読ませ、一つの内容につき一枚に切り出させています。数百の断片を人が切り出すと半日かかりますが、機械なら数分です。出所を添える作業も、逐語録に話者と時刻が残っていれば機械ができます。ただし、切り出しの粒度は人が確かめます。AIは「承認は課長がします。でも急ぎのときは係長が押します」を一枚にしがちです。二枚に分けるかどうかは、後の束の作り方を変えるので、人が見ます。

第二の似たもの集めの前半、つまり仮の並べ替えは、AIにやらせます。意味の近さで仮に寄せた状態を作ってもらい、そこから人が動かします。ここで毎回起きることが二つあります。AIは語が同じものを寄せ、語が違って意味が近いものを離します。「係長が押す」と「課長は細部を見ない」は離れた場所にあります。人がそれを寄せます。もう一つ、AIは束に名前をつけたがりますが、その名前は要約になります。「承認プロセスに関する発言」。これは名前ではありません。束が語っていることを一行にするのは、人の仕事として残しています。

第三の図解と第四の文章化は、人がやります。束と束の間に線を引けるかどうかは、その線が現場で本当につながっているかを知っている人にしか判断できません。AIに図を描かせると、きれいな図ができますが、線の根拠が現場ではなく語の近さになります。

川喜田は、断片の側から語らせることが核心だと述べました³。AIは断片を速く並べますが、断片に語らせているわけではありません。語らせるのは、断片を集めたときにそこにいた人です。当社がこの境界を守っているのは、方法への敬意というより、境界を越えたときに翌週作るものを間違えた経験があるからです。

当社の実践と限界

正直に書きます。この方法は時間がかかります。金曜の午後がまるごと消えます。エンジニアからすれば、その時間でコードが書けます。それでも続けているのは、金曜に束を作らずに月曜にコードを書くと、書いたものの半分が枝だったと水曜に分かるからです。金曜の半日が、翌週の一日半を守っています。

限界も書きます。この方法は、集めた断片の質を超えられません。インタビューが誘導質問だらけなら、束は誘導された答えの束になります。観察が一日だけなら、束は一日の話になります。だから、1本目から3本目の技術が先にあります。それから、束の名前は、つけた人の目の高さに左右されます。同じ断片から、経営の高さで名前をつけると「業務プロセスの非効率」になり、現場の高さでつけると「係長が押す」になります。FDEが翌週に作るのは後者なので、名前は現場の高さでつけます。経営向けの言葉は、文章化のときに別に書きます。

最後に、名前について。KJ法は川喜田研究所の登録商標で、当社は同社の認定を受けているわけではありません。当社がやっているのは、『発想法』の考え方に学んだカードによる構造化で、正式な研修は同社が行っています。方法の本質を学びたい方は、原典と同社の研修にあたることをお勧めします。私たちが書けるのは、それを現場の実装にどう接続したかまでです。

まとめ

現場で集めた断片は、そのままでは実装に使えません。断片を構造に変える方法として、川喜田二郎が野外調査のために作ったKJ法の考え方を使います。一枚一句のカード作り、意味の近さで寄せる似たもの集め、束の関係を線で結ぶ図解、担当者と自社に向けた文章化の四工程です。枠を先に作らず、断片の側から立ち上げるので、想定していなかった枠が生まれます。

FDEがこの方法を使う目的は、束の名前を「この会社だけの枝」と「他社にもある型」に分け、型を製品に返すことです。受託の要件整理で落ちる断片が、FDEでは最初に作るものになります。AIにはカード作りと仮の並べ替えを任せ、束の名前と図解は人が残します。

現場の断片を構造に変えられるエンジニアのチームを作りたい方、あるいは自社の現場の断片を製品に変える相手を探している方は、WARPのプログラムをご覧いただくか、個別相談でお話ししましょう。次の記事では、断片を集める新しい方法として、現場のビデオ撮影とAI分析を扱います。

Footnotes

1. 川喜田二郎『発想法 改版 創造性開発のために』中公新書（初版1967年、改版2017年）。中央公論新社の書籍ページ ↩

2. KJ法 株式会社川喜田研究所。「KJ法®は、株式会社川喜田研究所の登録商標です」の表示と、セミナー・研修の案内は同サイトによる ↩

3. 「KJ法の原点と核心を語る 川喜田二郎さんインタビュー」『質的心理学研究』第2号（2003年）。J-STAGE。断片の側から語らせるという趣旨の発言は同インタビューによる（筆者の要約） ↩ ↩²

4. Affinity Diagramming for Collaboratively Sorting UX Findings and Design Ideas（Nielsen Norman Group） ↩

5. Reflections on Palantir（Nabeel S. Qureshi、2024年10月15日） ↩

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