「禅とオートバイ修理技術」をプログラマが読んだ
「禅とオートバイ修理技術」これら2つの間にどのように関係があるのかまるで見当が付かず、タイトルだけ聞くとキワモノのようだがWikipediaによるとアメリカでは一番良く売れた哲学書とされている。
海外のエンジニアのブログを読み漁っていた時にオススメされていたのでKindleで買って読んだのだが想像以上に良かったのでメモを残したい。と言ってもwikipediaで説明されている内容を改めて説明しても面白くないのでソフトウェアエンジニアとして響いた部分を引用して僕の感じた事を書き連ねていく。
大都市の重工業地帯に一歩でも足を踏み入れてみれば、そこにはその全てが存在している。テクノロジーである。正面には有刺鉄線を施した高い塀が立ちはだかり、門は常に閉ざされ、「立入禁止」の札が掛かっている。そしてその向こうの薄汚れた大気の中には、金属や煉瓦で造られた醜い建物が立っている。その目的は不明であり、またそこに君臨しているのが誰なのかも分からない。何のために、なぜそこにあるのかは、雲を掴むようでまったく釈然としない。そこの住人であったはずの私たちは、高い塀を前にして、日々わけの分からぬ疎外感にうちひしがれているのだ。
これはバイク乗りでありながらバイクの構造の詳細に頑なに立ち入ろうとしない友人たちの心象風景を表わした節である。技術が分からぬものは、頭が悪いのではなくて複雑かつ意味不明な佇まいのテクノロジーという巨大建造物を前に何から理解したらいいかも分からずに疎外感に苦しんでいるのである。プログラマたる僕はもちろんそれを尻目にズンズンと複雑な工場の中に足を踏み入れ…ていると言いたい所だが、こういう「テクノロジー疎外感にうちひしがれる経験」はプログラマーなら誰もが持っているのである。日頃書いているプログラミング言語やそのライブラリは庭のように闊歩できるが、例えばその言語の実装やランタイムまで日常的に踏み入るのは一部であり、更にそういう人の中でもOSやCPUのレベルまで踏み入るのは少数である。Linuxのソースコードは2000万行を超え、データベースの実装やその背景となる理論は日々研究され、クラウドのネットワーク基盤を理解する為に必要な知識は膨れ上がっていき、機械学習は専門家ですら口々にわからないと言い続けている。その中の何らかの領域に詳しくてもそれ以外の事については学ぶ気すら起きないという心理障壁は何も特殊なものではなく自分の才能の無さや頭の悪さの証拠でもない。コンピュータ・サイエンスのすべての分野に精通という一時期流行ったフレーズはそういう心理障壁の低さを表す事だろうとは思うが、そういう人であっても例えば車のエンジンルームの中とかロケットを構成するすべての部品とか工作機械の構造だとかあらゆる物に興味を持って深堀りしていくには人生はあまりにも短すぎる。
実際ぼくが仕事で触っているコードは巨大過ぎて途中から脳が理解を拒みだしてしまうのだが、そういう時は見知らぬ工場地帯にいる心象風景を思い描き深呼吸するともう少し頑張って理解しようという気が湧いてくる。いや、もちろん効かない時も多々あるが…。ともかく、こういった疎外感を克服していくことは誰にだっていつかどこかで必要になる。恥じること無く少しずつでも学んでいこう。
システムだからといって、工場を破壊したり、政府に反抗したり、オートバイの修理を避けたりするのは、原因ではなく、結果を攻撃することになる。結果だけを攻撃している限り、変革は不可能である。本当のシステムは、私たちの体系的思考そのもの――合理性――によって構築されたものである。だから工場を破壊しても、それを生み出した合理性が残っている限り、その合理性が再び別の工場を築き上げるだろう。革命に拠って政治体制を覆しても、それを生み出した体系的思考パターンが無傷のまま残っていれば、必ずそれに次ぐ体制が生まれてくる。今日ではシステムに関する議論が甚だ多い反面、それについて真の理解を持っている人はほとんどいない。
システムとは複数の要素が絡み合ってできているより大きな仕組みであり、目に見える結果を出すがそれが意に沿っているとは限らない。意に沿わない結果を攻撃してもまず思う通りにはならず、問題を解決するためには結局システムの深くまで入り込みどうしてこうなったのかという原因から理解するしかない。表層的な解決策では変革には至らない。オートバイにも政府にも通用する普遍的原理である。
バッテリーの具合を調べるために、ホーンを鳴らして確かめようとするオートバイの修理工は、正式とは言えないが、実際科学的な実験を行っていると言える。すなわち生じた問題点をもとに、一つの仮説をテストしているのである。
プログラミングは理性を持って行う必要があるが、その理性の最たる点は何かと言うと科学的な実験である。試験管やビーカーを並べてカラフルな薬品を混ぜ合わせて爆発して髪の毛をチリチリにするばかりが実験ではない。プログラミングは実際のところ、科学的な実験の繰り返しである。printfデバッグは最も原始的なデバッグ手法であると同時に、プリミティブな実験そのものだ。世の中にはデバッガや解析ツールがたくさんあるが、それらを使いこなさなくてもモニタの前で地道に仮説構築とその検証を繰り返す理性こそが重要である。眼の前の現象を説明しうる仮説を考えそれを検証可能かつ容易に実現可能な実験を設計しprintfを足しコンパイルして実行する。
肉体労働は、修理のなかではごく一部の小さな問題にすぎない。この作業で最も優位を占めているのは、注意深い観察と正確な思考なのである。
キャリアの長いプログラマはその経験によって仮説の精度が高まっていくが、そうでなくても頭の良いプログラマは「仮説を検証可能かつ容易に実現可能な実験を設計」する力が高い。仮説も実験の設計もどちらもシステムに関する深い理解が必要である。
科学的な方法を用いる真の目的は、間違った考え方をしていないかどうか確かめることなのである。一介の修理工にしても、科学者や技術者にしても、みずから招いた不注意が原因で、誰しもその判断に思い悩んだことがあるはずである。
科学の実験の文法に沿った緻密な仮説と実験のサイクルは仕事を着実に前に進める為に回される。僕は見当違いなところをprintfして時間を潰した事は数知れず、大抵は不注意でそもそもの仮説が大いに間違っていた。そこら中にprintfを入れて動作を確認すれば科学実験なのではない、だがデバッグ出力と再実行を繰り返すうちに今回の実行は何を期待したものなのか忘れてしまう事すらある。検証すべき仮説を思い描き、現在自分がとっている手段がそれを検証する確実な方法であるかを自問自答するその積み重ねの中にこそ科学的な実験はある。
行き詰まりは、何事に置いてもその本質を理解する上での先達である。だから決して避けてはならない。技術的な仕事においても同じことが言える。行き詰まりを無心に受け止めることが《クオリティ》を理解する鍵なのだ。
バイクの修理だって行き詰まる。最初のネジを回そうとした途端にネジ山を潰すことだってあるし、手持ちの工具で潰れたネジ山に対処できそうも無いことだってある。しかし冷静にネジという部品とその役割について理解を重ねていけば回すばかりでない解決策が出てくることもある。思い通りに行かない事が日常なのは僕が無能だからではなく、それこそが技術的な仕事の重要な一端だからである。仕事でコードを書いていても目の前の問題に対してどう解決したらいいか分からず途方に暮れる事は珍しくもないが、避けずに観察と思考を巡らせて行き詰まりを受け止める事によって良い仕事ができる。焦ってはいけない。
そのような人は、退屈な仕事――遅かれ早かれ、誰しも退屈になるような仕事――を引き受けて行き詰まったとしても、そのときはそれも単なる一つの楽しみとして、随意、《クオリティ》に基づいた密かな探求を続ける。こうしてついには自分の仕事を一つの技芸にまで高めてしまう。
伝統工芸品だって初めから伝統工芸品として開発されたわけではない。そもそも量産される民生品があり、それを作る職人がおり、その一部の職人の中で地道な探求が行われた果てに高いクオリティが生まれる。クラフトマンシップの極みである。プログラマーだって日々の地道な探求の果てが技芸として認められない道理はない。
自己賛美を最終目標として、どんなに努力精進を続けても、それは必ず悲劇に終わるものである。
なぜなら自身が賛美に値するかを自問し評価する行為が自我に囚われており、ノイズとして悪影響を与えるからである。
「目標を意識せずにひたすら登っている人が、最も高いところにいる」というクロムウェルの言葉があるが、彼の心境はまさにこうであった。
（中略）
経験のない者には、自我にとらわれた登山も、我を捨て去った献身的な登山も同じように見えるかもしれない。どちらも一歩一歩足を踏みしめ、同じ割合で息を吸っては吐いていく。疲れたら休み、休んではまた歩き出す。だが、そこには実に大きな隔たりがある。
目標地点への到達や自分の虚栄心を満たす事を目的とした行動は「ここではない所」を原理的に求め続ける事になるため構造上そもそも満ち足りる事がない。必要なのは献身的な登山、つまるところ没頭して無我のうちに探求を続ける事こそが高みに至る道であり、その道の中に居続ける事こそが「求めるもの」であると確信する事である。そうして満ち足りた心で我が道を登り続けられる事自体を楽しみとする。そうありたいものである。
