プログラムを書いてデバッグしたとき、エラーが生じることがある。
イメージ通りの処理が実行されないときは、まず、値が、エラーの生じた箇所の手前の、どの処理まで、渡ってきているかどうかを調べる必要がある。値とは、変数に代入している値や、フォームから入力されたデータ、前のフォームから渡ってきたデータ、データベースから抽出したりバインドしたデータである。WindowsアプリケーションならMsgbox、WebアプリケーションならResponse.Writeを要所要所に埋め込み、どの行まで、どのような値が渡ってきているかどうかを確認する。
これでおおよその、要修正箇所の見当はつく。
しかし、ここぞと思った箇所を修正して、それでも動作しない場合がある。何度、同じ行を眺めても原因が分からない。そして、眺める時間が長くなればなるほど、その行に心がとらわれるようになる。
「おかしいな、このプロシジャの中が間違っているはずなのに」
エラーやバグの原因にアタリをつけることは大事だけれども、一度、とらわれた心を開放してみることも大事だ。
「きっと、この処理が原因だ」と、思い込むのではなく、その処理、その行から離れてみる。
わたしの20年来の愛読書、ヘッセ「シッダールタ」（高橋健二訳）に、こんな一節がある。生きていく上で、すべてに通じることである。
「さぐり求めると」とシッダールタは言った。「その人の目がさぐり求めるものだけを見る、ということになりやすい。また、その人は常に探り求めたものだけを考え、1つの目標を持ち、目標にとりつかれているので、何物をも見いだすことができず、何物をも心の中に受け入れることができない、ということになりやすい。さぐり求めるとは、目標を持つことである。これに反し、見いだすとは、自由であること、心を開いていること、目標を持たぬことである。」
わたしたちの脳は、どうやら、もとめると、もとめるものしか見えないように出来ているらしい。だから、一度、探り求めるのを中断してみることが、解決の早道なのだ。「あ、そうだった！とんでもないところを間違っているかもしれないぞ！」と気付くことができる。
これはエラーの解決だけに限らない。
目的の処理を、どうすれば実装できるか、どのように実装するのが一番よいか、を考えるときも、同様だ。プログラムに限らず、デザインや文章でも、同様である。煮詰まったら、一度、問題から離れてみることだ。
わたしの場合は、煮詰まらなくても、常に、可能な限り離れている。なので、結果的にこなしている仕事量の割には、パソコンに向かっている時間は少ない。
ゆったりと、ドリップで、コーヒーをわかしてみる。MTBで走る。風呂に入る。横になって呆けている。昔からである。わたしが本当に仕事をしているのは、パソコンの前に座っているときではなく、周りから見ると何をしているのか分からない、ムダな時間を使っているように見えるときである。パソコンの前に座っているときは、考えたことを、単に出力して定着させているに過ぎない。いま、もの凄いスピードで、この文章を打っているわけだけど、パソコンの前では何も考えていない。さきほど風呂に入っていたときに考えた文章をそのまま入力しているだけである。
煮詰まったら、真剣に考えるのではなく、ぼーっと考えてみる。解決策を求めるのではなく、解決策が、向こうからやって来るのを待ってみる（この「待つこと＝WARTEN」も重要である）。
デザイナの人は、集中力があるので、問題を解決しようとすると、心がとらわれた箇所から、抜け出せない、ハマリ型の人が多いかもしれない。だからこそ気をつけて、デザインのアイデアを考えるときと同じように、問題をとことん突き詰めてしまったら、一度離れて、逆に、これを高みから（＜サルトル）見下ろしてみるとよいかもしれない。そうすると、何か、解決策が見えてくるはずだ。
PROJECT KySSの相方も、一度心が一箇所にとらわれると、そこから動かなくなるタイプである。その反面、焦りんぼである。早く解決したい。かくして、わたしの作業場にインスタントメッセージが届く。メールやメッセンジャーでやりとりしてラチがあかなければ、わたしはノコノコ下の階へ降りていく。そして、一刻も早くVSのコードを見よと言う相方のペースに合わせるのではなく、ゆっくりとお茶を沸かすのである。たとえ午前をまわっていても（胃にはよくないと思うが）。
「もとめると、もとめるものしか見えないから。まっ、とにかく、お茶でも飲まへん？」
（2005年8月6日）
