2018年、エンジニアの知的生産術を書いた時に「この知的生産術にKJ法みたいに名前をつけないの?」と聞かれた

  • 「名前はつけません」って言った
    • 執筆時点から名前をつけることを意図的に避けていた
  • なぜか
    • この原稿を書いていたのは2017年
      • 「紙の方法も有用だが、問題点がいくつもある、電子化が必要だ」と考えて書籍に書いた
      • デジタルのツールで僕が満足するものはまだなかった
      • 執筆が終わってからデジタルツールの開発に入った
    • 書いていた時点は「現時点の方法が完成版ではない」という気持ちがあったのだな、と振り返ってみて思う

2022年KJ法勉強会@ロフトワーク

  • 「我流を作っていきましょう」「我流の情報を交換していくといいですよ」って話をした

  • Q: 我流に名前をつけると流通・交換しやすかったりするかも?

  • という質問があって「その通りだ」と思った

  • なぜか

    • 組織内で共有するための共通言語を作ることにも意味がありますが、まずはその前段階として自分の手法にこっそりと個人的な名前をつけるといいかも(私的な言葉)

    • 名前のついていない概念は液体のようなもので、とらえどころなく、操作することが難しい

    • 概念に名前をつけることで、マグカップに入ったコーヒーのように、取っ手を持って操作することができるようになる(液体が容器に入っているメタファー)

    • 共通言語を作るよりも手前の段階としてまず自分の手法に個人的な名前をつける
    • それは名前のついていない概念よりも操作することが容易になる
    • 概念を名前につけることによってその概念が「液体が容器に入っている」みたいな感じに取っ手を持って操作することができる、扱える対象物に変わるんだよ
    • これはエンジニアの知的生産術 p.36 (Column) パターンに名前を付けることに書いた話
  • 2018年の判断と比較する

    • 「名前をつけて本に書く」は「世界で共有される共通言語」を作ることに相当する
    • 2018年の判断「名前をつける段階ではない」 は「共通言語化する段階ではない」
    • 前段階として「私的な名前」をつけることは有益

というわけで西尾の我流に仮の名前をつけてみた

発表ストーリー構築法

  • 文字通り発表ストーリーを作る時に使っている
  • KJ法とこざね法の混ざったような方法
  • 話の断片が付箋になっている
  • 関連する付箋、繋がって語られうる付箋が、近接して置かれたり、線で繋いだりされている
    • 「この順番で話そう」と確定したものは近接させてグループ化してひとかたまりで動かせるようにする
      • Kozanebaだと畳むこともできる
    • やっぱやめようと思ったらグループ解除すればいい
    • これはこざね法のホッチキス止めに似た行為
  • 大雑把に「左上がスタート、右下がゴール」という軸がある
    • 例えば
      • 自己紹介の付箋は左上に置かれる
      • 講義の後にグループワークがある場合グループワークの解説に向けた繋ぎは右下にくる
    • 残りの大部分の付箋は線で表現されたつながりによって配置が決まっていく
  • 最初は講演に入れようと思って書き出した付箋でも「これを入れてうまく繋がるストーリーにすることは無理」みたいなことが次第に見えてきて「これは今回は省こう」とか「ここだけで単体の記事にしよう」とかやる
  • 逆に「ここからここに行きたいけど話の飛躍が大きすぎる」という時には間をつなぐ付箋が追加される
  • ゼロから作る時には先に考える花火のような、テーマを中心とした発散的フェーズを挟むこともある
  • 真価を発揮するのは「そのままでは使えないが、関連したストーリーがある時」
    • 再利用できる:
      • 0から言語化しなくても既に書き出された素材がたくさんある
      • 元ストーリーの中での近接関係は、アウトプットのストーリーでも近接しうる関係
    • そのまま使えない時とは:
  • 実例

難解文章再構築法

  • 難解な文章を読む時に使っている
  • 難解な文章を単語に刻んで - 「この単語はここでも出てきた」 - 「この指示語はこの単語をさしてる」 - 「この単語はこの単語と対置されてる」
    • などを線で表現する
  • 難解な文章は、そもそも複雑なネットワーク状の知識をむりやり一次元の文章に落としてる
    • 指示語や同じ言葉の繰り返しを使って「リンク」を表現している
    • しかし読む人の脳のキャパシティをあふれてしまって「あ、この単語はさっき出てきたな、つまりこういう意味で使われてるのだな」と思い出すことができない
    • こうやってリンクが寸断されて元の形に戻らなくなっている
  • 脳のキャパシティが足りないのだから、脳の中で再構築しようとせず、画面上で再構築した方がいい
  • 実例

書籍再構築法

  • 分厚い本を読むときに使ってる
  • 目次や図のタイトルなどを付箋にする
    • それを構造化する
    • まずは目次のツリー構造という「著者が作った構造」が再現される
      • フィールドワークからのKJ法と違って、著者の中の知識構造を内面化することが目的なのでそれで良い
    • それから「ツリー構造を逸脱しているもの」に注目していく
      • 考える花火の「グループをまたぐ線」のようなもの
      • そういう形にしてまで書く必要があったということは、それは著者にとって大事な概念なのである
  • 実例
    • あんまり過程をまとめた記録がないかも

(仮)Kozaneba法

  • 上記の方法はユースケースで分かれていた
  • でももっと汎用的にやってることがあるよなとも思った
  • これをなんと呼ぶのかは悩ましいところ
  • その我流をやりやすくするためにKozanebaを開発してるわけなのだが、Kozaneba法と呼ぶのは違和感がある
    • どんな違和感?
      • Kozanebaは道具、方法論を「Kozaneba法」と呼ぶのは「万年筆法」「ポストイット法」と呼ぶようなもの
  • 良い名前は今は思いつかないけど、これはグループが明確になる前に表札をつけようとしてるようなものなので保留しておく
  • 手法
    • 箇条書きができるツールで書き出す
      • 僕はScrapboxを使ってるけど、それはすでにScrapboxを使ってるからで、Scrapboxであることが必須なわけではない
      • スマートフォンで書き出せればなんでもいい、単なるテキストエディタでもいい
        • なぜスマホ: しばしば散歩をしながら書き出してるから
      • 大きな区切りには空行を入れておく
    • Kozanebaにインポートする
      • Kozanebaは複数行に分かれたテキストをペーストすると各行1枚のこざねとしてインポートする
        • Miroでも似たようなことができるはず
      • 二次元配置ができるツールであることが重要
      • 書き出したタイミングで連続した行になっているこざねは基本的に連想で繋がっているわけなので配置としてもまずは近接でいい
      • 離れたところの間に関係がある場合に線を引く
        • 今のKozanebaは離れたものの間に線を引きにくいので一旦近づけて引くことになる
        • これは改善すべきだと思っていたけど、ワークを観察してたら遠く離れたものを遠く置いたまま線でつないで放置してしまう人が多かったので悩ましいところ
        • Kozanebaでは線が長くなると透明度が高くなるようにしてある
    • 花火の囲みに関して
      • 普段はあまり熱心にはやってない
        • 必要に応じてグループ化してる
        • グループタイトルは空のままだったり、適当につけたりする
        • 枚数が多くて畳むときには、畳まれてても中身がわかるようにタイトルをちゃんとつける
        • 重要なグループは大きくしておく
          • グループの中のこざねが大きい時には畳んだものも大きくなるようにしてある
      • Kozanebaには柔らかく囲う機能がないので花火をちゃんとやるのはやりにくい
        • 今回、事例として紹介する時にはスクショを撮って iPadのノートツール(Notability)で囲んだ
        • ノートツールは使い慣れてた画像の上に線が引けるならなんでもいい
          • GoodNotesとか