JavaScriptフレームワーク「カンナエ」：設計思想と実践

プロジェクトが始動した当時、JavaScriptはまだWebデザイナーの領域とされており、社内にはフレームワーク設計やコンポーネントアーキテクチャに関する技術的コンセンサスは一切存在していませんでした。
使用が決定されていたのはjQuery程度であり、リッチクライアント化が必要なプロジェクト規模に対して、設計上の準備は極めて不十分でした。

このような状況を危惧した私は、将来的な保守性と実装効率を見据えた独自JavaScriptフレームワークの構築を単独で発想し、その概要を社内に提案。
幸運にも、理解と共感を持って協力してくれるエンジニアが一名現れ、2人で実装を推進することができました。

このフレームワークは後年、私が古代ローマの戦術を描いた書籍『ローマ人の物語』を読み返す中で、
「あの時に考えた構成はカンナエの会戦に似ている」と感じたことから、「カンナエ」と名付けました。
つまり、実装が先、命名はその翌年という流れです。

フレームワーク設計：人材構成と戦術的時系列

当時、JavaScriptはWebデザイナーの作業領域と見なされており、エンジニアが本格的に実装を担当しているケースはほとんどありませんでした。
そのため、JavaScriptに習熟し、フレームワークを構築できる技術者の確保は、まるで生粋の騎馬民族であるヌミディア騎兵を集めるような難易度でした。

一方で、PHPエンジニア（API開発者）は市場に一定数存在し、実際にプロジェクトにもすでに複数名が就業していました。
新たに獲得するのは困難でしたが、JavaScriptに比べれば比較的雇用が可能な“傭兵的歩兵戦力”であると位置づけることができました。

こうした人材構成を前提に、以下のような“戦術的配置”を考案しました：

  • PHPエンジニア（API開発者）を前線の弓形配置として活用。リクエスト処理とJSON生成を担当。
  • 私と協力エンジニアはJavaScript側で独自コンポーネントを開発。全体を外側から“包囲殲滅”する形でUI・UXを制御。
  • Webデザイナーから納品されるHTML/CSSに極力手を加えず、再利用を前提とする構成。

このように、時間の経過とともに完成度を増して全体を支配する構造は、
まさにハンニバルが用いたカンナエの包囲戦術そのものです。

実装と技術内容

API設計

  • リクエストに応じてSQLを発行し、結果を { カラム名: 値 } のJSONで返却。

DOMバインディング（JavaScript）

  • JSONのキー名と一致するID属性を持つHTMLタグを取得し、要素タイプに応じて適切な値を自動設定。

画面入力の送信

  • 入力値もIDをキーにしたJSONに自動変換してPOST送信。JSの個別実装を排除。

メリットと運用効果

  • デザイン変更時、JavaScriptもAPIも修正不要。
  • Webデザイナーが構築したHTML/CSS/画像をそのまま使い、IDを合わせるだけでデータ連携が成立。
  • JavaScriptによる再実装不要の量産体制。
  • ページを量産しても、PHPとHTML、CSSだけで機能実装が可能に。JSはフレームワークによって抽象化され、現場エンジニアの属人性を回避。

この「カンナエ」は、当時の技術環境・人材構成・納期制約に対して戦略的に設計された現場対応型フレームワークでありながら、
同時に後年見返すことで気づいた戦術的・思想的な一貫性が非常に印象深いプロジェクトでした。