はじめに
エディタを開いたまま、手が止まっていた。
コードは書ける。バグも直せる。それなのに、何かが足りない気がする。毎日キーボードを叩いて、レビューを通して、デプロイして。それでいいのか、と聞かれると困る。いいのだと思う。たぶん。ただ、いいのだと言い切れる自信がない。
そんな時期に、勉強会で誰かが一冊の本を勧めてくれた。顔も名前も、もう思い出せない。『禅とオートバイ修理技術』。禅とオートバイ。エンジニアの自分に何の関係があるのか分からなかった。分からなかったが、勧められた本を買うのは好きだったので、その場で購入した。積読になった。
読み始めたのは、それから何ヶ月も経ってからだ。不思議と心に残った。技術と向き合うこと。品質を追求すること。理性と感性の葛藤。オートバイの修理を通じて語られる哲学は、自分がプログラミングで感じていた言語化できない何かと重なった。
以来、行き詰まるたびにこの本を開いている。そのたびに、違う箇所が響く。最初は理解できなかった部分が、経験を積むにつれて腑に落ちていく。本自体が変わっているわけではない。変わっているのは、たぶん自分の方だ。
実はこの文章も、5年前に書き始めて完成できずに放置していたものだ。今回改めて書き直してみると、当時とは違う視点でこの本を読んでいることに気づいた。5年前の自分が何を考えていたのか、もう分からない。分からないが、今の自分とは違う誰かだったのだと思う。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
古典的な思考とロマン的な思考
本書の主人公は、物語の冒頭では古典的な（理性を重んじる）立場にいる。ロマン的な（情緒を重んじる）友人たちに対して、無理解で批判的な態度を取る。オートバイの構造を理解しようとしない友人を見下し、技術への無知を軽蔑する。メンテナンスを他人任せにする友人に苛立ち、「なぜ自分で理解しようとしないのか」と内心で批判する。
読んでいて、胸が痛くなった。これは過去の私そのものだった。
「なぜコードの仕組みを理解しようとしないんだ」と、フレームワークの内部実装に興味を示さない同僚を見下していた。「とりあえず動けばいい」という態度が理解できなかった。技術の背後にある原理を知ろうとしない人々を、内心で「浅い」と批判していた。
なぜ私はそうなったのか。たぶん、仕事がそういう仕事だからだ。コードは動くか動かないか。テストは通るか通らないか。バグは再現するかしないか。白黒はっきりする世界で、毎日を過ごしている。「正解がある」問題を解くことに最適化されていく。その結果、「正解がない」問題に直面した時、論理以外の武器を持っていないことに気づく。私だけの問題ではない。この仕事を続けていると、そうなりやすいのだと思う。
私にとって、コードの構造を理解することこそが美しく、アルゴリズムの優雅さこそが感動的だった。でも、多くの人にとっては違う。彼らは技術を道具として使い、その先にある価値創造に集中していた。技術の詳細に囚われず、より大きな視点で物事を見ていた。
古典的な視点からは、ロマン的な人々は「表面的」に見える。でもロマン的な視点からは、古典的な人々は「冷たく」「機械的」に見える。どちらも一面的な見方でしかない。
以前、私は「正義のエンジニアという幻想」について考えたことがある。技術的に正しいことを追求し、それ以外を否定する。「媚びない」と言いながら、実際はただ無礼なだけ。技術的正しさを盾に、人間関係の機微を「非論理的」と切り捨てる。本書の主人公の初期の姿と重なった。
しかし物語が進むにつれ、主人公の本当の目的が明らかになる。彼は実は中道を目指していた。古典的な立場とロマン的な立場を《クオリティ》という概念で統一しようとしていたのだ。分析と直感、構造と体験、理性と感性。どちらかを選ぶ必要はない。両方を使えばいい。——と書いて、立ち止まる。本当にそう簡単だろうか。実際には、理性と感性が衝突する瞬間は毎日ある。統合なんて大げさなものではなく、ただ揺れ続けているだけかもしれない。
クオリティという統合点
パーシグは「クオリティ」という概念を追求した。クオリティは定義できない。定義した瞬間、逃げていく。でも、確かにそこにある。
誰もが「良いコード」と「悪いコード」の違いを感じることができる。しかし、その「良さ」を完全に言語化しようとすると、何か本質的なものが抜け落ちてしまう。
「可読性が高い」「保守しやすい」「パフォーマンスが良い」――これらは確かに重要な要素だが、それだけでは説明しきれない「何か」がある。
この逆説的な性質は、グッドハートの法則やキャンベルの法則を思い起こさせる。「測定されるものは改善される。測定基準となったものは、良い測定基準ではなくなる」――クオリティを定量化しようとした瞬間、それは本来のクオリティから離れていく。
コードカバレッジ100%を目指したら、意味のないテストが増えた。cyclomatic complexityを下げようとしたら、かえって読みにくいコードになった。メトリクスは重要だが、メトリクスがすべてではない。数値化された瞬間、クオリティは形骸化する。
優れたコードを見た瞬間の「これだ」という感覚。それは論理的分析より先に来る。でも、単なる感情でもない。理性と感性が融合した瞬間に現れる何か。
具体例を挙げよう。ある日、オープンソースのコードを読んでいて息を呑んだことがある。複雑な問題を、驚くほどシンプルに解決していた。無駄が一切なく、それでいて拡張性も担保されている。「美しい」としか言いようがなかった。後から分析すれば、SOLID原則に従っているとか、デザインパターンが適切に使われているとか説明できる。でも、最初に感じたのは、理屈を超えた「美」だった。
古代ギリシアでは、これを「アレテー」と呼んだ。「それそのものが持つポテンシャルを最大限発揮している状態」。馬には馬のアレテーがあり、ナイフにはナイフのアレテーがある。コードで言えば、その、コードやシステムが解決すべき問題に対して、最も自然で、最も美しく、最も効果的な形で存在している状態。
過不足がない。シンプルだが単純ではない。複雑な問題を複雑に解くのではなく、本質を見抜いて エレガント に解く。それがコードのアレテー、つまりクオリティだ。
理性だけでは到達できない。感性だけでも到達できない。両方が必要だ。論理的な正しさと、直感的な美しさ。分析と統合。部分と全体。これらが調和した時、初めてクオリティが現れる。
——と書いて、少し立ち止まる。「理性と感性の調和」なんて言葉にすると、すべてが解決したように見える。でも実際には、調和なんてものは一瞬で崩れる。締め切り前の焦り、チームの摩擦、技術的負債の山。そういう現実の中で、調和を保ち続けることは難しい。私も何度も崩れている。
物語の転換
ここまで、パーシグが追求した「クオリティ」という概念について述べてきた。では、この概念はどのようにして生まれたのか。物語の中で、主人公がクオリティに辿り着くまでの過程を見てみよう。
物語の終盤、主人公は古典的な立場への疑問を深めていく。科学的方法は使い続けるが、科学万能主義には批判的になる。むしろロマン的な立場に理解を示し始める。
きっかけは、科学的方法の限界に直面したことだった。オートバイの不調の原因を論理的に分析し、仮説を立て、一つずつ検証していく。しかし、問題は解決しない。考えられる原因をすべて潰しても、バイクは不調のまま。そして気づく――仮説は無限に作れることに。
「一定の現象を説明しうる合理的な仮説の数は無限にある」
仮説は無限に作れる。でも、選べるのは一つだけだ。この気づきが、主人公を変えた。科学は仮説を検証する方法は教えてくれるが、どの仮説を選ぶべきかは教えてくれない。無限の可能性の中から、どうやって「これだ」という一つを選ぶのか。絶対的な真理など存在しない。だとしたら、何を基準に選択すればいいのか？
答えは「クオリティ」だった。論理的な正しさだけでなく、その状況における「良さ」を感じ取る能力。理性と感性を統合した判断。優れた整備士は、エンジン音を聞いただけで不調の原因を言い当てる。それは論理的推論の結果ではない。経験と直感が導く「これしかない」という確信。
主人公は理解する。友人たちがオートバイの仕組みを知ろうとしないのは、怠惰ではなく、別の関わり方を選んでいるからだ。彼らにとってバイクは、風を感じ、自由を味わう道具。内部構造など知らなくても、その本質的な価値は変わらない。
古典的でもロマン的でもなく、その両方を包含する視点。それこそが、パーシグが追い求めていたものだった。
無限の仮説とプログラミング
無限の仮説の中から一つを選ぶ。この問題は、オートバイ修理だけの話ではない。プログラミングでも同じことが起きる。一つの問題を解決する方法は無数にある。
私も経験がある。新規プロジェクトのアーキテクチャを決める時、本を読めば読むほど迷走した。『クリーンアーキテクチャ』は「ビジネスロジックを中心に」と説く。『マイクロサービスパターン』は「サービスの分割を」と勧める。『レガシーコード改善ガイド』は「まずテストから」と主張する。どれも正しい。でも、どれも部分的だ。
ある時、気づいた。これらの本は地図のようなものだ。山頂への道は無数にあり、どの道も「正しい」。でも、今の自分たちのチームが、この天候で、この装備で登るべき道は一つ。その判断は、地図だけでは下せない。
だから必要なのは、理論を超えた何か。コンテキストを読み取り、チームの状況を感じ取り、ユーザーの気持ちを想像する。スタートアップなら速度を、エンタープライズなら堅牢性を、でもそれも一概には言えない。チームの経験、プロダクトの成熟度、市場の要求、技術的負債の現状――すべてを総合的に「感じ取って」判断する。
論理と感性を統合した判断。それは経験を積むことでしか身につかない。でも、それこそがシニアエンジニアの真の価値なのかもしれない。無限の選択肢の中から、「今、ここで、このチームが選ぶべき道」を見出す能力。それもまた、クオリティの一つの形だ。
主客の融合
オートバイのメンテナンス中、固着したネジと格闘する場面がある。パーシグはこう語る。
「修理工とオートバイは永遠に別個の存在ではない。二元的な考え方をすることで、修理工とオートバイとの間に存在する分離できない関係、つまり仕事に専心する職人気質といったものが失われてしまう」
プログラミングも同じだ。私たちはコードを「書く」のではない。システムと対話し、問題空間と解決空間を行き来しながら、共に答えを見つけていく。
フロー状態に入った時、キーボードは手の延長になり、思考は直接コードになる。変数名を考える必要もない。自然と適切な名前が浮かぶ。この時、プログラマーとコードの境界は消える。理性も感性も超えた、純粋な創造の瞬間。
最近流行りのAIによるコード生成では、この感覚は得られない。プロンプトを書いて、生成されたコードをレビューして、修正を指示する。それは便利だし、効率的かもしれない。でも、そこには主客の分離がある。私とコード、指示する者と実行する者という二元的な関係。
私がAIにコードを生成させる時と、自分で書く時の違いを観察してみた。AIが生成したコードは「正しい」ことが多い。でも、それを採用するかどうかは、私が「判断」している。その判断は、論理だけでは説明できない。「なんか違う」という感覚。書いている最中に「あ、この設計だと後で困るな」と気づく瞬間は、自分で書いている時にしか起きない。AIが代替するのは「生成」であって、「判断」ではない。少なくとも今は。これが5年後も同じかは分からないが、今の私はそう感じている。
心の静寂
主客の融合を実現するには、ある条件が必要だ。パーシグはこう語る。
「バイクの修理に取り組むときに心がけるべきことは、自他の分離をしないような心の落ち着きを養うことである。心の落ち着きは正しい価値を生み、正しい価値は正しい思念を生む」
デバッグで行き詰まった時、論理的分析だけでは見えないものがある。深呼吸して、システムの「気配」を感じる。ログを機械的に読むのではなく、パターンを「感じ取る」。正常時と異常時の「違和感」を察知する。
これは非科学的なことではない。むしろ、科学と直感を統合した、より高次の認識方法だ。将棋の棋士が盤面を「読む」ように、経験豊富なエンジニアはシステムを「読む」。それは論理的分析と直感的理解が融合した、独特の認識方法だ。
逆に、心が乱れているとどうなるか。ある時、夜中2時に焦ってデプロイしたコードを、翌朝見直したことがある。ロジック自体は正しかった。でも、変数名が雑で、コメントがなく、エラーメッセージが「Something went wrong」だった。焦りは「動けばいい」という判断を生む。余裕は「次に読む人のため」という判断を生む。「落ち着け」という話ではない。心の状態によって、見えるものと見落とすものが変わる、ということだ。
ガンプション・トラップ
パーシグが作った「ガンプション・トラップ」という概念は、創造的な活動における意欲や熱意（ガンプション）を奪う罠のことだ。
理性の側には、完璧な設計への固執という罠がある。「もっとエレガントな解法があるはずだ」という思いに囚われて、永遠にリファクタリングを続ける。より良い抽象化を求めるあまり、実装が進まない。分析に分析を重ね、結局は麻痺状態に陥る。
一方、感性の側にも危険が潜んでいる。「なんとなくXXが好き」「とにかくYYに慣れている」という理由だけで技術選定をする。最初の直感に囚われて、他の可能性を検討しない。「このコードは美しい」という感覚に酔いしれて、実用性を忘れる。
特に「価値観の硬直」の話が印象的だった。南インドの猿の罠――ココナッツの中の米を握った猿は、手を離せば自由になれるのに、米を手放せない。
私たちも同じだ。「これがベストプラクティスだから」と言いながら、実は状況が変わっていることに気づかない。逆に、「自分のやり方」に固執して、明らかに優れた新しい手法を拒絶する。
私の場合、四半期ごとに「今やっていることで、3ヶ月前には正しかったが今は怪しいもの」をリストアップしている。最初は何も出てこない。でも、一週間くらい意識していると、「あれ、これ惰性で続けてるな」というものが見えてくる。答えは自分の中にある。問いを立てないだけだ。
テクノロジーとの関係性
ガンプション・トラップは、技術との関わり方の問題でもある。パーシグはこう指摘する。
「真の醜さの原因は、テクノロジーを生み出す人々と、彼らが生み出す物との関係のなかに横たわっている」
パーシグはこの言葉で、技術そのものが問題なのではなく、私たちと技術の関係が問題だと指摘する。オートバイを恐れる友人も、オートバイに依存する主人公も、どちらも不健全な関係だった。
技術を理性的に分析するだけでも、感情的に拒絶するだけでもダメだ。技術は使うものではない。共に在るものだ。対話し、感じ取り、理解し、共に成長する。
新しいフレームワークを学ぶ時、ドキュメントを読むだけでは不十分。実際に触って、感触を確かめ、「このフレームワークが望んでいること」を感じ取る。作者の思想、コミュニティの文化、設計の美学。技術の向こう側にある「人間」を理解する。
技術は道具以上の存在になりうる。それは私たちの思考を拡張し、新しい可能性を開く。でも同時に、技術に振り回されることもある。流行に飛びつき、本質を見失い、手段が目的化する。パーシグが言うように、技術との健全な関係を築くには、クオリティを中心に据える必要がある。
行き詰まりの価値
プログラミングには様々な行き詰まりがある。どんな設計にすべきか何日も悩む。アーキテクチャの方向性で迷い続ける。技術選定で延々と議論する。実装方法が思いつかない。エラーの原因が分からない。これらはすべて、私たちが日常的に経験する行き詰まりだ。
パーシグも、オートバイの不調だけでなく、人生の様々な場面で行き詰まりと向き合った。大学での哲学的探求、クオリティの定義、東洋と西洋の思想の統合。どれも簡単には答えが出ない問題だった。しかし、その行き詰まりこそが、彼を深い洞察へと導いた。
行き詰まりは、今使っている思考法の限界を示すサインだ。論理だけで解決しようとしているなら、直感を使ってみる。感覚だけで進めているなら、分析的に考えてみる。視点を変え、アプローチを変え、時には問題そのものを問い直す必要がある。
最高のブレイクスルーは、理性と感性が統合された瞬間に起きる。散歩中に突然解決策が浮かぶのは、論理的思考が一旦止まり、無意識の直感が働くからだ。しかし、その直感は、それまでの論理的分析があってこそ生まれる。苦闘は無駄ではない。それは答えを「熟成」させる時間なのだ。
最近では、生成AIに問題を投げれば、すぐに答えが返ってくる。確かに便利だ。でも、そこには何かが欠けている。パーシグがオートバイと格闘しながら得た洞察、その苦闘の中で培われた理解の深さ。それは、答えを与えられることでは決して得られない。自分で考え、悩み、試行錯誤することで初めて、問題の本質が見えてくる。技術への理解が深まり、思考が鍛えられ、判断力が養われる。
だから行き詰まりを恐れる必要はない。行き詰まりは、答えが近いことのサインだ。大切なのは、行き詰まりと向き合う姿勢。焦らず、諦めず、クオリティを追求し続けること。その先に必ず何かが見えてくる。
中道への道
行き詰まりを乗り越えた先に何があるのか。物語を通じて、主人公は変化していく。最初は理性の側に偏り、ロマン的なものを軽視していた。しかし、理性の限界を知り、感性の価値を認識し、最終的には両者を統合する道を見出す。
この変化は緩やかで、時に後退しながら進む。物語には、主人公のかつての人格「パイドロス」が登場する。クオリティを追求するあまり精神を病んだ過去の自分だ。主人公は何度もこの過去と向き合い、その度に少しずつ理解を深めていく。完全な統合ではなく、絶え間ない調整のプロセスとして。
私も似た道を歩んでいる。
最初は、論理と理性こそがすべてだと思っていた。設計パターンを暗記し、アルゴリズムを学び、ベストプラクティスを追求した。コードレビューでは「なぜこう書いたのか」を論理的に説明できることが最重要だと信じていた。感覚的な判断は「プロらしくない」と切り捨てていた。
転機は、あるシニアエンジニアとのペアプログラミングだった。彼は設計を決める時、まず黙って考え、そして「これが気持ちいい」と言った。最初は戸惑った。でも、その設計は確かに優れていた。後から理由を分析すると論理的にも正しかったが、彼は直感が先行していた。
今では分かる。優れたコードには、論理を超えた「何か」がある。それは説明できないけれど、確実に感じることができる。コードを読んだ瞬間の「あ、これは違う」という違和感。リファクタリング後の「これだ」という確信。これらは理性的分析の前に訪れる。
でも、だからといって直感だけに頼るわけではない。感じた「何か」を論理的に検証し、言語化する努力も続ける。理性と感性は敵ではない。パートナーだ。
中道とは、真ん中に立ち止まることではない。両極を知り、状況に応じて自在に行き来すること。時には徹底的に論理的に、時には大胆に直感的に。そして多くの場合は、その両方を同時に働かせながら。
この「何か」を追求することこそが、本当のプログラミングなのかもしれない。「良いものを作りたい」と言うのは簡単だ。難しいのは、「良い」の定義が人によって、状況によって、時期によって変わることだ。スタートアップ初期の「良い」は「動く」かもしれない。でも3年後の「良い」は「保守できる」かもしれない。同じプロダクトでも、定義は変わる。大切なのは「今、このチームにとっての良い」を言語化し続けることだ。その言語化の中で、理性と感性が調和していく。
おわりに
この文章を書き終えようとしている。
書いている間も、自分がクオリティを追求できているのか分からなかった。5年前に下書きを放置したのも、たぶんそういうことだ。書けない理由があったわけではない。書かなかっただけだ。
パーシグは「クオリティ」を追求するあまり精神を病んだ。最終的には息子との旅を通じて、理性と感性を統合する道を見つけた。見つけた、と書いてあるが、本当に見つかったのかは分からない。たぶん、見つかったと思いたかっただけかもしれない。
この本を読んで10年以上経つ。エンジニアリングへの向き合い方は、変わった気がする。
昔は「正しいコード」を書くことばかり考えていた。設計パターンに当てはめ、メトリクスを改善し、ベストプラクティスを守る。それが良いエンジニアだと思っていた。今は違う。チームの状況、プロダクトの段階、ユーザーのニーズ。すべてを考慮して「今ここで最適な選択」をすることが大切だと理解している。理解しているが、できているかどうかは別の話だ。
コードレビューの姿勢も変わった。以前は「なぜこう書いたのか」を論理的に説明することを求めていた。今は「どう感じた？」と聞くようにしている。論理的説明を求めるのではなく、直感を言語化する機会を作る。すると、レビュイーも「実は、ここに違和感があって」と本音を話し始める。クオリティは、対話の中から生まれることもある。
『禅とオートバイ修理技術』はエンジニアリングの教科書ではない。でも、どんな技術書より深い。技術の「向き合い方」を教えてくれる。
技術は進化し続ける。新しいフレームワーク、新しいパラダイム、新しいツール。AIも出てきた。でも、「良いものを作りたい」という気持ちと、そのための試行錯誤は変わらない。変わらないと思いたい。
クオリティは定義できない。でも、追求することはできる。できる、と思いたい。答えは出ていない。出ていないまま、また読み返すのだろう。5年後にまた下書きを開いて、今の自分とは違う誰かが、違うことを考えているのかもしれない。それでいいのだと思う。
ただ、残念なことに、この本は現在電子書籍でしか読めない。紙の本はプレミアがついている。Kindleで読むのも悪くないが、何度も読み返したくなる本は、やっぱり紙で持っていたい。ページに付箋を貼ったり、大事な箇所に線を引いたり、表紙が擦り切れるまで読み込みたい。そういう本なのだと思う。
早川書房の方がもし読んでいたら、紙の本での復刊を検討してもらえないだろうか。ハードカバーでも文庫でも、とにかく紙で読めるようにしてほしい。デスクの横に置いて、手が止まった時に開く。そういう本になる気がする。
