先月、コンポーネントライブラリに手を伸ばすべきか、それとも小さくてカスタムなものを作るべきかを決めるのに1週間かけました。よくある問題です。ふつうなら、その判断は午後のうちに下せる。時間コストをメンテナンス負債と天秤にかけ、UI上の摩擦ポイントを測り、取捨選択して、次に進む。
今回は先延ばししてしまいました。どちらの解決策も生成できないからではありません。優れたプロンプトがあれば、どちらの道でも1時間で進められます。コンポーネントライブラリは文書化されています。カスタムの構築も単純です。実際にコードを作り出すコストが、もはや制約にならなくなっていました。
先延ばししていたのは、私が実際に何を望んでいるのかを突き止める必要があったからです。何が速いかではない。依存関係が少ない方でもない。ソフトウェアに何をやらせたいのか、そしてそこに辿り着くために何をどれだけ差し出す覚悟があるのか。
それが今の「クラフト」です。コードではなく、意図。
実行がボトルネックでなくなったとき
長いあいだ「ソフトウェア・クラフツマンシップ」とは、きれいで、保守しやすく、読みやすく、上品なコードを書くことを意味していました。それは、雑にその場しのぎで出す人と、長く生き続けるコードを書く人の違いでした。ほかの人が引き継いでも、半年後にあなたの名前を呪いたくなるようなことがないコード。
それでも重要です。でも、もはやボトルネックではありません。
ボトルネックは、「何が存在する価値を持つのか」を決めることです。
コンポーネントライブラリの統合は40分で生成できます。カスタムのコンポーネントなら50分で生成できます。時間の差は今やノイズです。実際にあなたが時間を使うのは、カスタム版が継続的なメンテナンスに見合うのかどうか。ライブラリが、この問題に対して実際には間違ったメンタルモデルを押し付けてこないか。選び方を間違えると静かに壊れるのは何か。
これらはクラフツマンシップの問いではなく、意図に関する問いです。
私が学んでいた頃、良い開発者は「速さを保ちながら正しく、保守しやすいコードを書ける能力」によって際立っていました。それは本当に身につけるべきスキルでした。システム全体を頭の中で保持し、他の人が読んで修正できる形のコードへと翻訳する必要があったからです。いまもシステムの保持は必要ですが、翻訳は自動化されています。ボトルネックは上流へ移動しました。
今ではジュニア開発者でも、技術的に完璧なコードを生成できます。テストに通ります。スタイル規則に従います。あなたが求めたことを実行します。ですが、もし間違った問いを投げていたら、それは完璧に間違ったことをやってしまうのです。
自動化できないもの
私はコードレビューでそれを感じ取っています。技術的に非の打ち所がないPRが入ってくる。テストは通る。パターンは守られている。リンターが望むことはすべて満たしている。ですが、私は自分にこう問いかけてしまいます——なぜこのアプローチを選んだのですか？ 何かが壊れているからではありません。コードの中に、もはや推論が見えないからです。コードそのものが、難しい選択を重く背負うことがなくなっている。きれいすぎるのです。
不快な真実は、ときに正解が非効率であることがある、という点です。奇妙なこともあります。あるルールに違反することすらある。というのも、特定の制約を見つけて、それがこのケースではルールを不正にしていると分かったからです。そうした判断は、以前はコードの中に現れていました。誰が読んでも分かる形で、「誰かが考えていた」ことの証拠として。今はそれがありません。コードは完璧でありながら、同時に考えなしでもあり得るのです。
これは、ジュニア開発者に実際に学ばせるべきことを変えます。「きれいなコードを速く書く」ではありません。今それはコモディティ化しています。「自分自身のルールを破るべきときと、その理由を知る」。 「パターンが合わないときに気づけるほど、システムを深く理解する」。 「コードに答えさせる前に、正しい問いを立てる」。
また、自分の仕事で最適化すべきものも変わります。私は以前、コードを書く速度を上げようとしていました。コード速度が制約になっていた時代には、それが正しい目標でした。今は、問いを立てるのがうまくなることを目指しています。ファイルを開く前に思考実験を回すこと。正しい問題を、でたらめにではなく、間違った問題を優雅に解こうとしていないかに気づくこと。
もう機能しないもの
変なところですが、これはソフトウェアを良くするはずです。みんながタイピングに使う時間ではなく、考える時間を増やしているなら、悪い意思決定は減らせるはずです。けれど、そうなっているかは確信がありません。コードが安くなるほど、私たちはより多くのコードを生成します。存在する必要がないものをより多く作ります。作れるから、という理由でより多く出荷します。出荷の摩擦が、「やる価値はないかもしれない」という閾値を下回ってしまったからです。
以前は制約だったのは出荷までの時間、つまり出荷する前に本気で考えさせるものでした。それが解けてしまいました。今の制約は意図です。これは本当に重要だと、あなたは考えていますか？ 本当の問題を解決するから出荷しているのですか、それとも作るのが楽しかったから出荷しているだけですか？
これらは難しい問いです。見つけられるように待っている「正しい答え」がありません。あなたがやろうとしていることと、その理由について何かを知っている必要があります。そして、それを作っていく間ずっと、その意図をぶらさずに保つ必要があります。自分の注意の範囲について、規律が必要です。
それが今のクラフトです。コードの前に考えること。あなたが「できるから」作っていて「すべきだから」作っているのではないと気づける規律。
