アイディアとインスピレーション

アイディアを出すのは難しいと考えている人がいるが、アイディアを作りだすのは極めて簡単だ。
アイディアは、知識を組み合わせて、新しい知識を作り出す作業に他ならない。
だから、自分の知っていることをありったけ思い出して、組み合わせていけば、20や50のアイディアは簡単に作り出すことができる。
これをホワイトボードなどを使って、複数の他人と一緒にするのが、ブレインストーム会議である。
これは結構楽しい。
もし楽しくないのなら、やり方が間違っている。アイディアを出すのは、知的好奇心を高める楽しい作業である。

　ところで、アイディアとインスピレーションは、どこが違うのだろうか。
アイディアは知識の組合わせといったが、インスピレーションとて全く同じである。唯一違うのは、そのスピードである。
インスピレーションは、瞬時に産み出されたアイディアで、人間の潜在能力の一種で無意識を利用している。
しかも、ゆっくりと考え出されたアイディアよりも断然面白い。
インスピレーションは、まるで自分でないものが答えを与えてくれたので、神の啓示とか言ったりする。
神が人間を創って、この能力を与えてくれたのだから、合っているけど。考え出したのはあくまでも本人である。
この潜在能力は、誰にでもある。
例えば、料理屋を一瞥しただけで、美味しそうな料理が出てくるかを見極めたり、
初めて会った人の第一印象で、その人の性格や能力などを判断することが普通にできる
(しかも結構合っていたりする)。

インスピレーションを発揮するには、どうするかと言うと、難しく考えずに、自分に静かに聞くだけである。
後は、自分の潜在能力が答えを見つけ出してくれる。こういう能力をさえ否定しなければ良い。
難しく考えないことである。

最後に、デジタル全盛の時代になっても、本はアイディアの元である。本は、沢山読む方が良い。

仕事を速くする

　仕事を速くするには、できるだけ、仕事の内容を細かい単位に分割すると良い。
後10分しかないから、できないとか、明日やろうと考えるのではなく、
10分で終わる単位の仕事にしておけば、空いた時間も無駄にならない。
こうすれば自然と仕事が速くなる。
TOC理論というのがある。Total of Constraintsの略で、制約理論などとも言われている。
つまり、ボトルネックがあれば全体の動作がそれに制約されて遅くなるという意味である。

例えば、工場のラインで、１個生産するのに、A工程で1時間、B工程で2時間、C工程で30分かかるのなら、
普通なら、1個生産するのに3時間30分かかる訳だ。
もし、A工程、B工程、C工程を並列化したとしても、それでも2時間は必ずかかるということである。
当たり前。このB工程がボトルネックである。
もしB工程を細分化して45分時間でできるようにすると、今度はA工程の1時間がボトルネックとなる。

ボトルネックを解消するには、工程を可能な限り小さい単位にバラバラに分解して、
ボトルネックが小さくなるように工夫すれば生産性が向上するのである。
そして生産性があがれば、無駄な在庫が減り、生産性は上がり、工場はつぶれなくて済んだという話が、
「The Goal」(イスラエル人物理学者　エリヤフ・ゴールドラット博士著)という本に書いてある。

SE・プログラマの年齢限界

誰が言ったか、脳細胞は生まれてから減り続けて行く一方で、SEやプログラマは30歳が限界とか。
私が思うに30歳で限界なのではなく、30歳で勉強することを止めるから、限界が出現するのであって、
絶え間ぬ努力をすれば(才能なんかもあるだろうが)、年齢限界を突破するには難しくないだろうと思う。
そもそも、SEやプログラマがドロップアウトするタイミングは、年齢よりも、
新たな技術の波が来て、それを習得できない人が消えていっている感じである。
最初に触れた技術は、覚えることが出来ても、2つ目の新たな技術が習得できない人が多い。
それは何故か多くの人が、２つ目の新たな技術を、全く新たなものとして覚えようとしているために思える。
こうなると、記憶量は単純に2倍になる。
運よく、２つ目が習得できた、としても３つ目の時には脳がパンクして挫折するかも知れない。
これは、勉強や理解の仕方が間違っているように思う。
新たなことをそのまま覚えるのではなく、その技術のバックグラウンドをしっかり理解することが先である。
まずは、基礎技術を理解するのだ。
基礎技術は10年経ても、20年経ても変わらないものである。
応用技術は、基礎技術にプラスアルファして、作られるものである。
基礎技術を理解していると、応用技術の理解もできるようになる。
しかも、新たに覚えることは少ないので、習得が早くなるし、応用も利く。

それに、基礎技術といっても、難しい専門書を読み解く必要はない。
一番簡単な方法は、コンピュータの歴史を知ることである。

わずか数十年の革新的な技術変化も、元をたどれば１つの技術にまでさかのぼることができる。
それを理解して、もう一度歴史を読み進めていけば良い。

原因不明のバグの探し方

どこかでエラーが混入して、プログラムが正しく動かない、なんてことは良くある。
プログラムはかなりの量になるため、最初から順番に調べていくのは、かない骨が折れそうだ・・・。
がするしかない。という様な悲惨な状況になる場合もある。今日も徹夜か、ハァ～てな状態である。
この時には、最初から探してはいけない。
プログラムのモジュール単位に分けて、半分ずつテストをするのである。
そして、半分の内、動かない方のモジュールをさらに半分に分けてテスト。
この操作を繰り返して、特定のモジュールを探し出し、モジュール内のソースコードを半分ずつに分けてテストを繰り返す。
短時間で、原因のある場所にたどり着く。
この方法は、プログラミングではバイナリーツリー・サーチというごく一般的な方法である。
これを応用しない手はない。

もし、SubVersionなどでソースを管理していた場合には、もっと簡単。
元に戻したソースをビルドして、動くことを確認したのなら、WinMergeやDiffなどでフォルダ毎比較。
違っているソースを比較すれば、もっと早く原因が分かる。

経験上、原因不明のバグは、だいたい一晩で安易にで作ったコピペ・コードの書き直し間違えとかじゃないでしょうか(^^;)

変なプログラマーの作り方 #12に参加してみた

　WEBの世界は、知っているか、知らないかで、見えているものが違う世界。
より知っていることで、ハックの楽しみは倍増し、ゲームの世界感という箱庭ではなく、
一時として同じ姿をしていない現実仮想の庭で、怒濤のように情報が吐き出され、
流れて消えていく中に、人類の知性が<集結>される。
　自分の知性の拡張し、楽しさがフィードバックできれば、無限大の面白さがある。
なんて詩的に夢想しつつ、話を聞かせて頂きました。

若い聡明な皆さんと楽しく会話ができて楽しかったです。
「巨人の肩に乗っかる」金言。「マウスは膝の上で使う」確かに姿勢が楽(笑)