親和図法の問題点は「上位の概念化が難しい」の一点に集約されます。(略) これは「勝手に言葉を作らない」ことで解決可能です。下手に概念化しようとするから難しいのであって、下位のデータの言葉をそのまま借りてくればいいわけです。
これは字面だけ見ると筋悪に見える。
- 発想を妨げないようにハードルを下げることに注力している手法なのに「禁止ルール」を導入することでハードルを上げている
- 「最初に思いついて付箋に書いたもの」からのサンプリングに限定することで、あとから思いついたことの採用を妨げる
でもこのブログ記事の続きの部分を読むと、前半部から受ける印象と逆:
なんだそれ、ぜんぜん抽象化できてないじゃないか、と思われるかもしれませんが、プロダクト/サービス開発は（民俗学などとは違って）データの分析そのものに意味があるのではなく、分析を通じて新しい価値を生み出すことに意味があるわけですから、データの言葉を切り刻んでガチャガチャ組み合わせ、そこから新しい物語を生み出すことができれば、別に抽象化しなくてもOKなのです。 この部分の「新しい物語を生み出すこと」が大事なのであって「抽象化」は必要ではないという考えには賛成。「新しい物語を生み出すこと」を「勝手に言葉を作らない」ルールでやるのはハードル上げてるのでは。
「新しい物語を生み出すこと」が大事であるなら、そもそもここが間違いなのでは。
親和図法の問題点は「上位の概念化が難しい」の一点に集約されます。 この「上位の概念化」と「抽象化」が同じ意味なのか違う意味なのか。 同じ意味なのだとすれば「必要でないことをやろうとして難しいと言っている」状況だし、違う意味なのだとすれば「上位の概念化」と「抽象化」というよくわからない言葉を出して説明しているあたりに話者の理解の混乱があるように見える。
僕はこのプロセスを表現するのにKJ法の「表札作り」という言葉を採用していて「このグループの内容を説明する表札をつけてください」っていう指導の仕方をする。で、表札作りのスキルがまだ身についてない人は、当然「表札を作ってください」と言っても作れないので「説明してください」と言って口頭で言わせて、それを付箋にすることをアシストしている。これは「この付箋たちがここにいる理由のストーリー」を生み出している。
エンジニアの知的生産術の「グループ編成には発想の転換が必要」加筆案に実例を書いた。
私はそれぞれのグループについて「このグループはどのようなグループなのか？」を質問して解説を聞きました。解説が長ったらしい場合には「一言で言うと？」と聞いて短くし、解説が一単語の場合には「もう一言補うと？」と聞いて長くし、表札を作る過程を支援しました。 これがうまくいかない、つまりグループを簡単に説明できない場合は、そもそも元のグループが適切ではないので分解して配置し直すべきだと思う。川喜田二郎もうまく説明できるか検証しろと言っている。
発想法 p.74
かなり集まったあたりで、そのなかの1チームの紙片群を手にとってよくみる… よく読む… 「なぜ自分はここに五枚の紙片を集めたのか」ということを理性的に反問する。… たまには、一ヵ所に集めていた間違いに気づくことがある。… たいがいは「なぜこの五枚をそこに集めなければならないか」という理由を、その五枚の紙片の内容がわれわれに語りかけてくるのである。