「マインドマップ」とは何か。

トポロジー的には、単なる木構造である。プログラマーにはおなじみで、毎日のように扱っているあれである。これがいかに有効なフレームワークであるかは、言うまでもない。あなたの頭が知らなくても、手足が知っているはずだ。

しかし、見た目はだいぶ違う。どれだけ違うかを、「hobo-多読多評- 小飼弾の「仕組み」進化論」から引用させていただくことにしよう。まずは、そのままの木構造。

小飼弾の「仕組み」進化論
　　仕事となる
　　　　人間しかできない仕事があるか
　　　　　　IT機器で人が追いやられる
　　　　　　機器にも置き換えられる
　　　　　　→仕組みを作る人にならないと
　　　　仕組みを作る人に価値が出る
　　　　　　今存在する仕組み以外の仕組み
　　　　　　■仮説→検証→アクションは必要
　　　　　　よりすぐれた仕組みを求めている
　　　　本当の２０％ルール
　　　　　　既存の仕組みの利用２０％
　　　　　　残りの８０％を新しい仕組み作りに
　　　　　　そのためには
　　　　　　　　現行の仕組みの見直しが必要
　　　　　　　　ブラッシュアップ方法
　　　　　　　　　　会社が生き残るためん利益を計算
　　　　　　　　　　自分の仕事の役割
　　　　　　　　　　利益の根拠の時間数
　　　　　　　　　　目的：自分の仕事の価値を見直す
　　　　　　　　　　→新しいことに対する挑戦の時間
　　仕組みの仕組み
　　　　見えないテコ＝公式は存在する
　　　　　　公式を共有することで効率が上がる
　　　　　　公式＝マニュアルの共有
　　　　　　　　目的
　　　　　　　　　　個人の既存の判断結果の再考を減らす
　　　　　　　　　　→能力のフル活用
　　　　仕組み三原則
　　　　　　人間に危害を加えない
　　　　　　人間に重複する
　　　　　　自己を守る力を持つ
　　　　　　　　仕組みにリスク回避能力を持たすべき
　　　　　　■→仕組みを自動で作る仕組みはないか
　　　　　　　　■人を育てることかな？
　　仕組みを作り直す
　　　　内訳
　　　　　　設計
　　　　　　　　心
　　　　　　実装
　　　　　　　　体
　　　　　　実際に行動してこそ価値がある
　　　　PGに習う
　　　　　　三大美徳
　　　　　　　　怠慢
　　　　　　　　　　作業の重複を嫌がる
　　　　　　　　　　　　DRY
　　　　　　　　短気
　　　　　　　　　　今後起こりえることに備える
　　　　　　　　　　要望に柔軟に対応できる状態にしておく
　　　　　　　　傲慢
　　　　　　　　　　メンテナンスの容易さ
　　　　　　　　　　　　仕組みに責任を持つ
　　　　　　仕組みを分解
　　　　　　　　生成物、入力物単位で仕組みを切る
　　　　　　　　モジュール化
　　　　無駄な仕事を見直す
　　　　　　無駄な繰り返し
　　　　　　記録の再利用
　　　　　　車輪の発明を防ぐ
　　　　　　　　すでに機能が存在するかを確認する
　　　　　　チェックする
　　　　　　　　作った仕組みの価値を・・
　　仕組みを使う
　　　　使い続けるには
　　　　　　PDCAの流れが必要
　　　　　　　　定期的なチェックが必須
　　　　　　　　さらに
　　　　　　　　　　あと何回で元を取れるかも計算
　　　　　　　　　　減価償却を考慮に入れる
　　　　使わない仕組み
　　　　　　リスクに備えた仕組み
　　　　　　安全確保する仕組み
　　　　　　　　テストを重ねる
　　　　　　　　次の設計に生かす
　　　　　　　　構成要素を減らす
　　仕組みを合わせる
　　　　つなぎ方
　　　　　　並列
　　　　　　　　遊びがある、すぐに壊れない
　　　　　　　　ベクトルを合わせる
　　　　　　　　成果物の価値を見せる
　　　　　　　　　　次工程を提示する
　　　　　　直列
　　　　　　　　効率はいい、無駄がない
　　　　　　　　つなげるところを探す
　　　　　　　　　　インプット、アウトプットを的確に
　　　　　　　　　　同時にボトルネックの分析に
　　　　日報で共有
　　　　　　TODO
　　　　　　予定、実績を
　　　　ボトルネックが生じる
　　　　　　仕組みの組み合わせで発生
　　　　　　誰もが並列をできるような状態を目指す
　　　　　　→能力を充実させる
　　　　　　限界を共有する
　　　　　　　　わざと壊れるシステム
　　　　　　自働化
　　　　　　　　勝手に働くことには価値は多い
　　　　　　　　最初から最後まで実施できることが大事
　　　　ラベリング
　　　　　　識別を正確にできる状態にしておく
　　　　インプットの枠を合わせる
　　　　　　最適なものしか入らないようにする
　　　　　　インプットに合わせてI/Fを設計する
　　　　問題の考え方
　　　　　　対策が浮かばない時
　　　　　　　　自分のレイヤーを上げてみる
　　　　モックアップ
　　　　　　目的
　　　　　　　　コミュニケーションコストの削減
　　　　　　ビジュアルに訴えた中間生成物
　　　　　　　　容易な
　　仕組みと生物
　　　　生物は３８億年仕組みを続けている
　　　　学ぶこと
　　　　　　最適である必要はない
　　　　　　　　必要以上ではない最適でOK
　　　　　　確定的な継続ではNG
　　　　　　「最適でなくても十分であればいい」
　　　　　　　　生物の基本思想
　　　　　　仕組みを記憶する
　　　　　　　　言語化できない技術も対象
　　　　　　　　残す技術、仕組みを準備するべき
　　　　　　　　失敗した事実も記録になる
　　　　　　　　電子情報を利用するとき
　　　　　　　　　　全文検索できる文脈を入れる
　　　　　　速やかな判断
　　　　　　　　PDCAの短いサイクル
　　　　　　突然変異
　　　　　　　　許容すること
　　　　　　　　ブレスト
　　　　　　　　　　どんなアイデアも認める
　　　　ブルーオーシャンの見つけ方
　　　　　　今いる場所がどこなのか
　　　　　　どこに赤い海があるのか
　　　　　　　　その隙間を狙う
　　　　準備
　　　　　　物事、思考を設計しておく
　　　　　　仕掛品
　　　　　　　　あと、どこまでも設計しておいてチャンスを待つ
　　仕組みの未来
　　　　リソース効率
　　　　　　リソースの集中が正確にできているか
　　　　　　生産に集中ではなく、効率を上げる作業に集中できているか
　　　　　　使えるものをベストで使えているかを考える必要がある
　　　　仕事以外の必要
　　　　　　迷走することで新しい発見がある
　　META
　　　　出版社
　　　　　　日本実業出版社
　　　　著者
　　　　　　小飼弾

次に、「マインドマップ」

どちらが書きやすく、そしてどちらが見やすいかはまさに一目瞭然だ。「マインドマップ」とは、より自然に描け、そして自然に見える木構造」以外の何者でもない。そしてそれこそが、「マインドマップ」がマインドをマップできない一番の理由なのである。

木構造は、発散(diverge)はしても収束(converge)はしない。ジャンプとループが存在しないのだ。それでは、マインドにならない。少なくとも私のマインドには。

発散に限っていっても、「マインドマップ」でマップできる分岐深さは浅すぎる。A0版などを使っても、せいぜい二桁だろう。ところが、ちょっとした思索でも三桁ぐらいは平気で行ってしまう。だから「マインドマップ」にそれを転記しようとすると、あらかじめ思索を収束し、不要な枝を刈っておかなければ(prune)ならない。これでは本末転倒なのではないか。

僕にとって、小飼弾さん最大の魅力は「飛躍」にあります。実は、彼ほどロジカルに物事を思考できる人も少ないのですが、彼の思考が常識と照らしてあまりに斬新すぎて、それが僕のような凡人には「飛躍」と映るのです。

「マインドマップ」は、その「結果」をまとめることは出来るけれど、その「過程」を追うことはできないのだ。線を書き足せば「合流」(merge)もサポートすることは出来るけれども、出来上がった「マインドマップ」はスパゲッティにしか見えないだろう。

「マインドマップ」の問題は、フローチャートが抱えている問題に通じる。一言で言えば、表現力が乏しすぎるのだ。しかし、表現力を補おうとすると今度は視認性が失われる。これもまたフローチャートの問題に通じる。

誤解してほしくないのだが、私は木構造の表現法としての「マインドマップ」を非常に高く買っている。本の目次など、「マインドマップ」化で恩恵を受けそうな分野は実に多そうだ。もしそれが「連想木」(association tree)とかだったら、多分ほめるだけで済んでいただろう。問題は、それに「マインドマップ」ということにある。看板に偽りありもいいところではないか。それともトニー・ブザンのマインドはこの程度だったとでも言うのだろうか。

Dan the Unmappable Mind