1. 形式の存続性に無頓着であるというリスク
私は昭和に生まれ、時代は平成、令和へと移り変わりました。和暦は日本独自の文化ですが、システム設計の観点では「100年以内に必ず終わりが来る」ことが確定している単位です。それにもかかわらず、なぜ公文書やウェブシステムに和暦を使い続けるのでしょうか。
例えば、1月を「睦月」と呼んで実務を行う人は現代にはいません。基本は世界標準である西暦を使い、和暦は補足として扱う。将来の改修リスクが予見できているのであれば、最初から持続性の高い「標準」を選択すべきではないでしょうか。
2. 変動を予測しない設計の代償
かつて消費税が3%だった時代が長く続きました。しかし、税率が固定されると誰が保証したでしょうか。5%への引き継ぎの際、多くの現場でシステム改修が間に合わず、猶予期間を求めるなど混乱を極めました。
その後、税率は8%、10%と変化しました。最初から「数字は変わるもの」という前提に立っていれば、これほどのコストと労力を費やす必要はなかったはずです。リスクを予見しながら、それを無視して設計する危うさを私たちは再認識すべきです。
3. 繰り返される「時間」の問題
プログラムの世界でも、私たちは苦い経験を重ねてきました。1900年代が永遠に続くと思い込んだ「2000年問題」。そして、32ビットコンピュータの限界により、2038年1月19日にシステムがオーバーフローする「2038年問題」。
当時のリソースの少なさゆえの制約だったとはいえ、時間という絶対的な概念に対して、あまりに近視眼的な実装がなされてきた事実は否定できません。
4. 過去の経験はなぜ活かされないのか？
昨今の「モダンJSフレームワーク」を巡る状況も、本質的には同じだとは思いませんか。
かつて一世を風靡したCoffeeScriptは姿を消し、jQueryですら「過去の遺物」になりつつあります。また、CSSを拡張するSass (SCSS) も同様です。かつては必須のツールでしたが、今や変数(CSS Variables)やネスト(CSS Nesting)といった機能はブラウザの標準仕様として取り込まれました。つまり、特定のツールを使わなくとも「標準機能で事足りる」時代になったのです。
流行を追い、特定のツールに依存して構築されたシステムは、そのツールが誰にも相手にされなくなったとき、どうメンテナンスするのでしょうか。それが数年後の「負債」になることは、歴史を見れば明らかなはずです。
5. 「最新」という錯覚がもたらす盲点
新しい仕組みが登場すると、あたかも過去のものを全て改良した優れたものであるかのように錯覚してしまいます。
確かに普及する技術には理由がありますが、次にまた新しいものが出たとき、あなたは再び乗り換えるのでしょうか。その時、過去に作ったシステムは置き去りにされるのですか。
6. まとめ：標準技術こそが唯一の防波堤
新興のフレームワークやライブラリには、前述の「和暦」や「消費税」と同じ性質のリスクが常に潜んでいます。
標準化されているJavaScript (ECMAScript) やHTML、CSS、そしてPHPなどの高性能化に伴い、これら新興ツールがいずれ陳腐化することは既に分かっています。
特に無名なライブラリや、メジャーアップデートで仕様が激変するツールは危険です。採用したばかりなのに寿命は1年しかない。これこそ予見できない側の落ち度と言わざるを得ません。
これを「老害の意見」と呼ぶ人もいるでしょう。しかし、過去の事例があまりに多すぎるのです。生成AI(LLM) の時代になり、開発サイクルがさらに加速する今、このリスクを肌で感じないでしょうか。
