【ITニュース解説】Pourquoi ton code prépare un futur qui n'arrivera jamais (YAGNI)

システム開発の世界には「YAGNI」という言葉がある。これは「You Aren't Gonna Need It」の略で、「それは必要ないだろう」という意味を持つ。この原則は、今すぐ必要ではない機能は、たとえ将来的に必要になる可能性があったとしても、現時点では作らないという考え方を推奨している。開発者が陥りがちな「将来のために」という名目での過剰な開発が、実際にはプロジェクトに大きな負担をかけることを警告しているのだ。

ある開発者が自身の経験を通じて、YAGNI原則の重要性を解説している。彼は自身の請求書作成アプリケーションを例に、YAGNI原則に反した開発の経緯と、それがどのような結果を招いたかを語っている。当初、彼はフリーランスとしてパリで活動しており、請求書はユーロで作成するだけで十分だった。しかし、彼は「もし将来、ロンドンやアメリカ、日本にクライアントができたらどうしよう？」という漠然とした不安から、多通貨対応（リアルタイム為替レートの取得）、4カ国語対応、さらには3種類の会計ソフトウェアへのエクスポート機能まで、様々な「将来の機能」を先回りして実装してしまった。

結果として、これらの「将来の機能」は、6週間が経過しても一度も使われることはなかった。それどころか、為替レートを取得するために利用していた外部APIの利用規約が変更されたことで、ある日突然、アプリの請求書ページがクラッシュするというトラブルが発生した。使われることのない機能のために、余計なメンテナンスコストや予期せぬバグのリスクを抱え込むことになったのだ。これは、存在しない架空の顧客のためにコードを書き、その結果、実際のユーザー（この場合は開発者自身）がその代償を払うという「クリスタルボール症候群」と呼ばれる状態である。

彼が書いた「不要なコード」は多岐にわたる。例えば、クウェート・ディナールのように小数点以下3桁を扱う通貨に対応するため、通貨コード、シンボル、小数点以下の桁数、ロケールを管理するデータベーステーブルを作成した。また、外部APIからリアルタイムで為替レートを取得し、それをキャッシュするサービスも実装した。このサービスはAPIキーの管理が必要となり、後に問題の原因となった。多言語対応についても、開発者自身がフランス語話者であるにも関わらず、フランス語、英語、スペイン語、ドイツ語の4言語分の翻訳ファイルを用意した。特にドイツ語のファイルはオンライン翻訳ツールで作成されただけで、一度も内容が確認されることはなかった。さらに、会計エクスポート機能では、3種類の会計ソフトに対応するため、共通のインターフェースを定義し、それぞれのエクスポート機能を実装しようとしたが、そのうちの1つは「TODO（要実装）」のコメントが書かれたまま放置されていた。

これらの機能は、合計で約400行ものコードを占めていた。これらのコードは、外部APIへの依存、環境変数の追加、新しいテキスト要素が追加されるたびに4回翻訳する手間、テスト時に為替レートAPIを模擬する仕組み（モック）が必要になるなど、開発やメンテナンスにおいて重い負担となっていた。

この経験から、開発者はYAGNI原則に基づき、アプリケーションを簡潔な状態へと改善することを決意した。まず、通貨管理のデータベーステーブル、為替レート取得サービス、会計エクスポート機能、そして使われない多言語ファイルをすべて削除した。これは「git rm」コマンドでコードを削除する、非常に気持ちの良い作業だったと述べている。

通貨の表示については、JavaScriptに標準で備わっているIntl.NumberFormatという機能を使うことで、わずか3行のヘルパー関数に集約した。これにより、ユーロの金額をフランス語の正しい形式で表示できるようになった。金額のデータ自体は、後から変更が難しい「セント単位の整数」で保存するという、堅実な設計は維持された。アプリケーション内のテキストは、フランス語で直接テンプレートに記述するように変更された。会計エクスポート機能は、本当に必要になったときに、その時に会計担当者が求める形式（例えばCSV）で作成することにした。彼は、これならばたった15分程度の作業で済むと見積もっている。

このようなリファクタリングの結果、約400行のコードが削減され、外部APIへの依存がなくなり、為替レートの取得を待つ必要がなくなったことで、請求書ページの読み込み速度も向上した。使われない複雑なコードを抱え込むことによるリスクや負担から解放され、アプリケーションはよりシンプルで堅牢なものとなった。

ただし、YAGNI原則は「未来を無視しろ」とか「いい加減なコードを書け」という意味ではないことに注意が必要だ。YAGNIには二つの重要なニュアンスがある。

一つ目は、「元に戻すのが難しい決定」については、最初にしっかりと考えるべきだという点である。例えば、データベースのスキーマ（設計）、認証の仕組み、そして金額を浮動小数点数ではなくセント単位の整数で保存するといった基盤部分の設計は、一度決めてしまうと後から変更するのが非常に困難である。これらは「もしもの時の機能」ではなく、システムの土台となる部分であるため、YAGNIの対象外であり、初期段階で慎重に検討するべき項目だ。YAGNIは機能に対して適用される原則であり、コードの品質を犠牲にするものではない。

二つ目は、YAGNIがDRY（Don't Repeat Yourself：コードの重複を避ける）原則と組み合わせることで真価を発揮するという点である。コードがシンプルで重複がなければ、将来新しい機能が必要になったとしても、変更が非常に容易になる。例えば、通貨のフォーマット処理がアプリケーションのどこか一箇所に集約されていれば、新しい通貨を追加する際も、その一箇所を変更するだけで済む。このように、未来を過度に予測して複雑なコードを書くのではなく、変化に迅速に対応できるような柔軟なコードを書くことが、YAGNI原則の本質的な意味である。

そして、この話には皮肉な結末がある。開発者が多通貨や多言語といった「将来のニーズ」を予測し、そのためにコードを書いたが、それらは決して現実のニーズとはならなかった。しかし、フランスでは後に「電子請求書」制度が義務化されることになった。これは、彼が当初作ったどの会計エクスポート機能でも対応できない、真に必要となる「未来の機能」だったのだ。この事例は、未来のニーズを正確に予測することがいかに難しく、無駄が多い作業であるかを雄弁に物語っている。未来を予測するのではなく、変化に柔軟に対応できるシンプルなシステムを構築することが、システムエンジニアにとって非常に重要な姿勢である。