下界から天界へ：レガシーコードとの再会から見えた技術の進化

1. プロローグ：レガシーコードへの激怒

「ふざけるなああああああああああああああああああ！！！！」

他人が作ったウェブシステムのレガシーコードと格闘しながら、 思わず魂の叫びが漏れました。 AJAXでHTMLを直接返し、インラインJavaScriptだらけの実装。 MVCモデルを完全に無視し、保守性を考慮していない、まるで「動けばいい」だけのコード。

そんな激怒の後、ふと不安が襲いました。

「もしかして…私も似たようなことをしていたのでは？」

2. 経験者としての振り返り

私の技術的なバックグラウンドは、1980年代後半から進化を続けてきました：

• 1980年代後半～1990年代半ば：Unix、C言語、X-Window
• 1990年代半ば～2000年代後半：WindowsとVisual C++
• 1999年～2000年代半ば：HTML、PHP4、SQL
• 2010年前後：XcodeとObjective C++

2021年、10年のブランクを経てWordPressのテーマ開発に携わった際、私のWebフロントエンド開発の知識は限定的でした。 当時の開発環境はDreamweaverとEclipse、そして秀丸エディタ。 PHP4の時代で止まっており、JavaScriptについてはインラインスクリプトしか知りませんでした。

この技術的ギャップを認識していたため、発注元にWordPress開発の実績があるエンジニアの支援を要請しましたが、配属されたエンジニアは技術的な問題解決に消極的で、結果として自分で調べながら進めていくことになりました。

3. 設計への執着：若き日の教訓

私が設計を重視するようになったのは、アルバイト時代からからの大規模システム開発での経験からです。 実装の前には必ず設計書のレビューがあり、数年の経験を経て要件定義まで任されるようになりました。

OOP（オブジェクト指向プログラミング）の設計手法であるOOM（Object-Oriented Modeling）を独学で学び、これは後にUML（Unified Modeling Language）へと発展していく流れの中にありました。

近年では、PlantUMLやMermaidのようなテキストベースのUML作成ツールにより、Markdownでドキュメントとダイアグラムを一元管理できるようになり、設計書の作成と管理がより効率的になっています。

4. 現代の課題：失われゆく設計力

しかし、日本国内で現在の開発現場を見渡すと、強い危機感を覚えます。 多くの若手プログラマーがエンジニアリングの基礎を理解していません。 さらに深刻なのは、SEと呼ばれる人々の状況です。 PMBOKのような管理手法は習得していても、 プログラミングの経験やエンジニアリングの知識が著しく不足している 「管理者SE」が主流となっています。

プロジェクトマネジメントの知識と技術的な理解の間にある大きなギャップに、 私は驚愕を覚えました。 表面的なプロジェクト管理はできても、システムの技術的な要件を理解し、 適切な設計判断を下すことができない。これは単なるスキルの問題ではなく、 エンジニアリングの本質的な理解が失われつつある証左なのではないでしょうか。

5. WordPressの実装を振り返る

私のWordPress実装は、確かにAJAXでHTMLを返すという点では、あのレガシーコードと似ていました。 しかし、アプローチは大きく異なっていました。

WordPressのショートコードを理解する過程で、「動的なコンポーネント」の必要性に気づき、「Webフック」という仕組みを取り入れました。 これは、大規模システム開発で培った「再利用可能なコンポーネント」という考え方の実践でした。

WordPressのWebフックとAJAXは密接に関連しています。 Webフックがイベントドリブンな拡張ポイントを提供し、AJAXがそのフックを通じて非同期データ更新を実現します。 この組み合わせにより、ページ全体をリロードすることなく、必要な部分だけを動的に更新できる仕組みを構築しました。 これがまさに動的なショートコードと考えたのです。

実装には、以下の要素が不可欠でした：

1. APIの明確な仕様書

   • 自分以外の人が使えるように
   • 将来の保守を考慮して
   • 再利用を前提とした設計

2. 一貫した構造

   • HTMLの構造を明確に定義
   • クラス名の命名規則の統一
   • コンポーネントの責任範囲の明確化

具体的な実装例：

// コンポーネントとしてのショートコード定義
[user_review_list]

// 動的データ取得のためのWebフック
add_action('wp_ajax_user_review_list', 'handle_user_review_list');

この実装アプローチの妥当性について、AIに検証を依頼しました：

この検証結果からも、フレームワークの機能を適切に使用し、セキュリティと保守性を考慮した設計であることが確認できました。

6. 新技術との出会い

3年が経ち、WordPressのお守りに疲れ果てた私は、新しい技術への扉を開くことにしました。サイバー攻撃への対応、バージョンアップの互換性問題、開発陣の内紛による混乱など、様々な課題に直面していました。

PythonでのAIモデル開発に加え、Astro、Cloudflare、Node.js、TypeScriptと次々に新しい技術に触れる機会を得ました。この探求をLLMが大きく後押ししてくれ、現在はRemixへの挑戦も視野に入れています。

7. 普遍の真理を見つめて

新しい技術との出会いは、同時に古い教訓の価値を再確認する機会となりました。

• TypeScriptの型システムは、かつて設計書で定義していたインターフェースの重要性を体現
• Astroのコンポーネント分割は、WordPressで試みていた再利用可能なコンポーネントの考え方をより自然に実現

しかし、これらは単なるツールに過ぎません。 新旧の技術を問わず、重要なのは設計から始めるという姿勢です。 レガシーコードとの格闘から、私は改めてこの真理に気づきました。

• システムを俯瞰的に見る目
• 再利用性を意識した設計
• 明確な仕様の定義と文書化
• 一貫性のある実装規則

これらは、実装に取り掛かる前に必ず行うべきことです。 時代が変わっても、技術が進化しても、この順序は変えてはいけません。

30年以上のキャリアを通じて、私が最も確信を持って言える真理は、 「システムは設計なくして始めてはならない」ということです。 それは怒りと向き合った一人のエンジニアが、レガシーコードから再確認した、貴重な教訓なのです。