山人黒バリ （ さんじんくろばり ） を知っていますか?

ピンと来た方は 35才以上だと思います。
昔、少年マガジンに連載されていた 『釣りキチ三平』 に出てきた、毛鉤釣りの名人 ・ 毛バリ山人 （ けばりさんじん ） が、 長年の研究の末に到達した、究極の毛鉤です。

毛バリ山人は、その前、本物の羽虫と見まがうほどの、飛翔 ・ 沈翔 （ ひしょう ・ ちんしょう ） という傑作を残しています。

飛翔・沈翔 飛翔 ・ 沈翔。 こんな感じ。

　それにしてもヘタクソな絵だな。
　ホントはもっとカッコいい。
　矢口高雄先生、ごめんなさい。

その見事さに感激した主人公、釣りキチ三平が訪ねていくと、山人はもう開発思想が変わっていて、 黒一色で、羽根や尾といった装飾の一切ないミニマムな毛鉤 ・ 山人黒バリ を作り上げていました。

山人黒バリ 山人黒バリ。 こんな感じ。

　いよいよ描いてて悲しくなってきた．．．

何故か?
山人は、長年の釣り人生の中で、毛鉤釣りの真髄は、釣り人のテクニックだと悟ります。 毛鉤の力で魚をだますのではなく、毛鉤を操る釣り人の腕がすべてだということです。
そこに辿り着いたとき、かつての傑作　飛翔 ・ 沈翔 には、問題があった。 せっかく食いついた魚の鼻づらが、羽根や尾に当たって毛鉤をはじいてしまい、釣り逃すことがあったのです。 そして、一切の装飾を排した究極の毛鉤 ・ 山人黒バリ が生まれたのです。

ここには、道具というものへの深い洞察があると思います。

同じような感覚を、以前よく見ていた Ｆ１グランプリ で感じたことがありました。
あれは、事故で亡くなった アイルトン・セナ が、最後にフルシーズン戦った年だと思います。 愛するホンダエンジンの撤退により、セナは、ホンダＶ１２より、 はるかにパワーの劣るフォードＶ８エンジンのマシンに乗っていました。 でも、この年、セナはたしか５勝もしたのです。

印象的だったのは、何レースか続けて、セナが１～２周目にゴボウ抜きするのです。 エンジンが非力だから、予選の順位は低いのですが、そこから、３台も５台も抜いてしまう。 集中力のなせるワザかなあ、と思っていたら、あるとき、最後の周でマシンが止まっちゃった。ガス欠でした。
当時は途中給油がなくて、たぶんセナはゴールできるぎりぎりの量を計算して、ガソリンを積んでいたのでしょう。 Ｖ８エンジンは自身が軽く、燃費もいい。加えて、ぎりぎりの量しか積まないから、他のマシンよりかなり車重が軽かった。 それが、スタート直後のゴボウ抜きの秘密に見えました。
凄いドライバーです。

フォードＶ８は非力で、エンジンの力で勝たせてくれはしない。 でもクセがなく扱いやすくて、きっとセナには、手の中でどうとでも遊べたのではないでしょうか。

PlanningFlow（以下 Pf） の 絵のパレット のおかげで、Adobe Illustrator を間近で見る機会が増えました。 本職のグラフィックデザイナーさんは、手が止まらないですね。
なぜ、手が止まらないのか?
もちろん、マウスやキーボードの扱いが上手いこともあります。 ソフトを毎日のように使っていて、機能を習熟していることもあります。 でも、それだけなら手は止まるはず。
手が止まらないのは、イマジネーションが速いからです。

描きたい絵をどんどん思い浮かべられること。
それと、一度描いた絵のどこを変えたらいいか （例えば、この曲線をもう少し膨らまそうとか） イメージできること。 これは、絵のイメージが先に来ているようにも見えるし、 「ここをいじれば印象が変わるはず」 と勘が働いて、先に手が動いているようにも見える。 イマジネーションと勘の速さ。

イマジネーションは、いわゆる絵心というやつで、天性かも知れない。 でも、あの 「ここをいじってみよう」 の勘は、後天的なものじゃないかと思う。 Illustrator を使う日々の中で身に付けたんじゃないかと思います。
僕と同世代だから、少なくとも２０代半ばまでは、コンピューターを使わないグラフィックデザインをしていたはずです。 コンピューター以前は、あれこれ試してみる、ダメだったら戻してみる、なんてことはできない。 紙に描くのですから、集中してイメージして、一発で完成形を出すスタイルだったはずです。

別の人ですが、やはり同年代のグラフィックデザイナーさんと話していたとき、 いわゆる ”三種の神器”（ Illustrator, PhotoShop, QuarkXpress ） をびゅんびゅん使うのに、「こんなもの嫌い」 という。 「なんで?」 と問うと、「私たちが苦労したことが、あっという間にできるから」（あははは。気持ちはわかる）。
でも、あれらをびゅんびゅん使えるように、誰もがなれるとは思いにくい。 Illustrator は、絵心や 「ここを」 の勘がある人にはパワーを与えてくれるけど、それがない者には敷居が高い。 「プロ向け」 のひと言で済ますこともできるけど、言い方を変えれば、人間の能力差を浮き彫りにするソフトです。 修行して絵心と勘を鍛えてきた者だけには、優しく微笑んでくれる。

反対に、能力差を埋めるソフトもあります。 90年代はパソコンが大衆化した時代で、ソフトもそのトレンドが求められました。

　何の知識も要りません。　誰にでも、簡単に、（そこそこ） 美しいものが作れます。
　ウィザードを多数用意、100種類のテンプレート、プロが描いた素材をなんと 3000点標準添付．．．

こちらは、Illustrator とは逆。 ユーザーに絵心や勘がないことを前提に作られているわけです。
あの手のソフトをびゅんびゅん使う人は身近にいないので、わからないのですが、 やっぱり、ああいうソフトも使っているうちに、絵心が鍛えられることがあるのでしょうか。 絵心というとちょっと変ですが、パターン学習というか、暑中見舞いや年賀状を何度も作っているうちに、 レイアウトのイメージ、欲しい挿絵のイメージが、ぱっぱっと浮かぶようになるとか。

＋　＋　＋　＋　＋

これは言うのを控えていたのですが、TreeMemo（以下、Tm） も、実は能力差を浮き彫りにするソフトです。
文字を入力するだけなので、Illustrator ほど敷居は高くありません。 また、いわゆる 一般向け／プロ向け の分類では、一般向けということになるでしょう。 でも、あることができるかできないかで、ソフトの効果はまるで違ってきます。

　思考が速いこと
　単語と短文でポンポン発想すること
　物事の大小／主従／因果 といった関係を、階層構造に素早く整理すること

これが今できている人は Tm にすぐ反応するでしょう。 その人が Tm を手にしたら、すごい威力を発揮するはずです。 逆に、この感覚がないと、文章をツリーに整理して１ファイルにまとめて．．．　その程度の便利さで終わると思います。
Illustrator は敷居が高いけど、敷居の姿は見えやすい。 Tm は文字の入力だけだし、操作は簡単なので、すぐそれなりに使えるのですが、 本当に全開で使うには、人間の側が問われます。
そして、そのことが見えにくいのです。

親のひいき目で言うと、そこに Tm の ”不遇” があります。
もちろん、製品としては、まだまだいろいろ至らない。
でも、あれの抱える一番の問題は、感性のギャップです。

”書類を作る”　という作業スタイルは昔からあった。ワープロはごく自然に受け入れられます。
”文章メモを作る”　という作業スタイルも、やってる人はけっこう居た。 付箋紙ソフトや、メモをツリー状に整理するソフトも、違和感はないはずです。
でも、”単語と短文を階層化して、高速に思考する”　なんて、誰も言わなかったと思います。 その良さを体感している者、信じている者も、ほとんど居ない。

単語と短文の高速思考や、そうやって （スタイルを変えてでも） ダイナミックに頭脳労働の効率向上に挑もうとする感性が、 今の世の中でメジャーになるなどとは思っちゃいません。けど、少数派にはなれると思っていました。
でもそれは勘違い。マイナーどころか、カルトでしかない。
数万は反応するだろうと踏んでいたが、反応したのは数千だった。
すぐ気に入ってべた褒めしてくれる人も多いのですが、おおかたは感覚が通じない。 ソフトライブラリも、マスコミも、直販をかけた企業も、出展したソフトのコンクールもそうです。　参っちゃいましたよ。

雑誌の掲載でほんの数回ですか。作業スタイルの違いについて書いてくれたことがあったかな。 それと、企業直販については、もう少し事情が複雑かも知れない。
”Office 以外はＮＯ” の意思統一があったのかも知れないし、 デモを見た人は感応しても、その人が、他の社員が感応するか自信が持てず、ブレーキを踏んだのかも知れない。 もしかしたら、これを野放しにしたら、Word とは別のインフォーマルな情報の流れができてしまうと見抜いて、 警戒したのかも知れない。

僕ら自身にも、問題がなかったとは言えません。
Tm の使い方や効果はひと言では語れない。だからポイントを絞り込まなかったところはある。
そもそも、最初の頃は、見ればわかるだろうと思っていたのです。ここまで明快な言葉を練り上げなかった。 ツリー図と文章という、一見外観の似たソフトは多いのですが、それらとの違いも、使えばわかるだろうと思っていた。 感覚のギャップが問題だとわかってからも、ついこないだまで Tm の紹介文とかを誤解されやすい表現のまま放置してきた。 責任あると思います。

今回（Tm4.9） は開き直って、まるでビジネス本のような紹介文に変えました。
ソフトの作者としては、もう少し奥ゆかしくしていたかったのですが、誤解されたまま終わりそうな雰囲気です。 なりふり構っちゃいられない。 反応はどうなるでしょうか。

あと一つ、やらなきゃいけないことは、これを海外に出すことでしょう。
この感覚や作業スタイルを、世界の人たちに問うてみなければ。
欧米だったらどうかなと思いますし、発展途上国も面白いかも知れない。 やたらと書類を作る文化に染まっていない人たちのほうが、可能性があるかな、なんて思ったりもします。
かつて Tm を、中古再生パソコンにプリインストールして販売しようとした人がいて、 そのとき Tm は 486 の CPU （覚えてます?） のマシンでも動いた。 最新機種が揃っていなくても問題ないし、結果はわかりませんが、やってみたいです。

あの感性が理解されるようになったら、と考えていたので、これまで Tm のバージョンアップは控えていたのですが、 再開します。
5 ではツリーの基本部分にメスを入れようと思っています。 表示の見やすさとか、文字のウィンドウ内への収め方とか、もう一度操作性についても。 そういう基本部分から、改めて強化する予定です。

＋　＋　＋　＋　＋

もし、Tm がなくなったら、indysoft の仕事は止まりますね。
あれを使わない日はないし、代わりはありません。
ちなみに Pf がなくなったら、かなり嫌ですけど、止まることはないです。
indysoft では、Pf はそれほど頻繁には使われていません。

たぶん、それはフローチャートというものの性格です。
フローって、伝えるための道具でしょう。
もう少し言えば、”会話や文章では正確な伝達が危ない事柄を、伝えるための道具” だと思います。 （複雑な事柄を思考するための道具でもあるのですが、そこまで複雑な事柄がいつもいつもあるわけじゃないです。）

さて、”正確な伝達が危ない” 理由は、 伝えようとする事柄自体が、複雑だ ・ 初めてだ ・ 微妙でイメージしにくい、といった、事柄自体の問題もあれば、 伝える相手との、基礎知識 ・ 感覚 ・ 意識 のギャップが大きい、といった、人間の側の問題もあります。

indysoft でフローがあまり使われないのは、メンバーがツーカーだからです。 職種も年齢も近いし、合宿とかでさんざん話してイメージも共有してる。
もし、会社のように、年齢も知識も意識もばらばらのチームであれば、 また、別部署や業者の人と協力したり、お客さんとのやり取りが頻繁ならば、フローが必要な場面は、ぐっと増えるでしょう。 僕がそういう会社のチームリーダーであれば、フローはばんばん描き、描かせます。

indysoft でも、思考フローはみんな時々使っています。
僕は計画や問題分析に使うし、僕も含めて皆、プログラムの特殊ロジックを考えて記録を残すときなんかは、使います。
RichTextFormat の構文解析とか、記号的なプログラムの場合、いくらソースコードにコメント書いても、 わけわかんないでしょう?　そういうときはフローです。

あまり伝達フローを使わないから、面白い効果もあります。
みな中堅だから、プロジェクトの先々を読んで仕事してるので、いわゆる管理はする必要がないのですが、 時折、「あ。読みが狂ってんな」　「イメージ合ってないのに、合ってるつもりになってんな」 と感じることがあります。
そういうとき、フローを使います。　「段取りはこうだよ！　わかってる?」

普段使わないで、いざというとき使う。
不思議なもので、それを繰り返すうちに、僕がフローを使うだけで、チームに緊張が走るようになりました（笑）

情報の伝達ってものは、正確に行える限り、なるべく手間をかけないほうがいい。
アイコンタクトやジェスチャーで伝わりゃ理想だし、話して伝わりゃ楽。 indysoft は Tm があるから、チーム内では書類は絶対使わないけど、Tm や、手書きのポンチ絵で伝わるなら、 それもかなり楽です。 フローは描くのに時間がかかるし、メンバーがツーカーなら、なるべく使わないほうが理想と思います。

ただ、人は易きに流れがちです。　理想と手抜きは紙一重。
ぜんぜんツーカーじゃないのに、甘く判断して手間を惜しむと、あとで痛いしっぺ返しを喰うので、要注意ですが。

＋　＋　＋　＋　＋

仕様書というものがあります。
システムエンジニア時代は、それが仕事の中心だったし、今でもよく書かれていますが、 長いあいだ Tm を使っていると、仕様書の内容が少し変化してくるのです。面白いですよ。

仕様書の第一の目的は、最終仕様の記録です。
ただ、企業システムやパッケージソフトのように、息の長いものの場合、最終仕様と同様に、 途中で検討されて廃案になった Ａ案、Ｂ案、などの記録も、とても大切だったりする。
どんな案があり、なぜ採用されなかったのか。

システム全体のレベルでは、分析報告書とか提案書とかで、Ａ案、Ｂ案、や検討内容も書いてある場合も多い。
でも、Ａ案、Ｂ案、てやつは、細かいところでも起きる。
デザイナーやプログラマーの個人作業の中でも、日々起きている。
それらをドキュメントで残せ、と言っても、なかなか書類で残すヒマはない。
でも、Tm を使うと、皆、（全部ではないけれど） かなり書き残すようになりました。

単語 ・ 短文で、ぱぱっと書く。
気が向けば、文章メモを添付する。
さらに、必要あれば、（Pf でぱぱっと） フロー描いて、リンクしておく。
文章に凝る必要なんてまったくないです。あとで検索して、記憶を蘇らすヒントになればいいわけですから。 書くのに時間はかからない。

すると、書くのです。
開発なんて、いつも忙しいものと相場が決まってる。
だから、ちょっとでも手間だったら書かない。　「廃案だろ。いいさ。」
でも、数十秒、数分で書けるとなると、書くのです。

Tm の場合、あとでゼロからドキュメントするのではなく、思考過程から使っていくから、余計手間を感じない。 Ａ案、Ｂ案．．． と、Tm にメモっておいて、最終仕様がＡ案に決まったら、
Ａ案の下の階層には、採用理由をメモる。
他の案の下の階層には、却下の理由をメモる。
で、すぐ次の作業に取り掛かる。　このリズムです。

手元には、開発日誌 兼 検討書 兼 仕様書　が残っています。

＋　＋　＋　＋　＋

人間が居て、道具があります。
仕事は、人間と道具の協同作業の成果です。
道具は人間が作るのですが、道具が人間に働きかけて、人間を変化させていくこともあります。

かつて、システムエンジニアの大先輩が、開発ツールというものに関して、 （両手の手のひらを胸の前で合わせ、ゆらゆら左右に振りながら） 「こう。ゆや～ん、ゆよ～ん、と、作業理論や人間との接点が揺れながら、形作られていくんだよねえ」 と言いました。
いい言葉だなあと思ったけど、あの頃はまだ駆け出しで、意味を体でわかってはいなかった。

開発ツールをちゃんと作ろうとすると、作業設計から入ってトップダウンでやります。
作業理論を固めて、ツールの姿を描く。　人間がどうしたいか探って、ツールの姿を描く。
もちろんそれが正解なのですが、それだけで終わりじゃないよと。
道具を使ったときの微妙な感触や、使い込んだとき人間の側に起きる変化まで、なかなかトップダウンでは設計し切れない。

深いじゃないですか?
だから、道具作りはやめらんない。

indysoft.jp 主宰
びーどろ