完璧が存在しない技術選定、だからこそ「後戻りできる余地」を設計に残す
川上氏によると、二つの具体例から得られた最大の学びは、「技術選定によって誰に、どのような影響が及ぶのかを明らかにすることが極めて重要」という点だ。
例えば、CDNのリバースプロキシを用いてネットワーク経路を変更するという選択一つを取っても、その影響範囲は広い。社内インフラや開発チーム、連携する他システムへの影響はもちろん、FQDNが変更される場合には、ユーザーが利用しているブックマークへの影響も発生する。加えて、ネットワーク経路が増えることで障害ポイントが増加するというリスクも無視できない。
一方で、この変更によって得られるメリットは明確だ。ページ単位での段階的移行が可能となり、デグレーションを抑制できる。結果としてクラウドリフトが進み、最終的には可用性の向上につながる。仮にネガティブな影響が想定される場合でも、FQDN変更に対するリダイレクト設定や、他チームへの事前の根回しといった対策を講じることで、リスクを現実的なレベルに抑えることができる。誰にどのような影響があるのかを事前に洗い出すことで、「何をすべきか」が具体的に見えてくるのだ。
Excelで管理されていたAPI仕様書を、OpenAPIとTypeScriptで刷新した例についても同様である。この取り組みによって、デグレーションの抑制やチーム間の透明性向上、型定義の二重管理の回避といった多くのメリットが得られた。一方で、新しい技術を導入する以上、学習コストが発生することも事実だ。この点について川上氏は、「開発チームが受け入れる覚悟が必要になる」と率直に語る。
こうした前提を踏まえ、川上氏が技術選定において重視しているのが「ウィークポイントベースで技術を選ぶ」という考え方だ。基幹システム刷新における技術選定には、大小さまざまなトレードオフが必ず伴う。刷新によって設計が変わり、開発体制が変わり、その変化を関係者に共有しなければならない場面も少なくない。その際、エンジニアには「なぜこの選択をしたのか」「どのような痛みが生じるのか」を説明する責任が生じる。川上氏は、そうした現実を踏まえた上で、「そもそも完璧な技術選定など存在しない」と説いた。
あらかじめ技術のウィークポイントを理解した上で選定し、「後戻りできる余地」を設計に残すことが、結果的にプロジェクト全体の痛みを軽減する。「選択が誤っていたときに、別の選択肢へ乗り換えられる余地があるかどうか」——その視点を持つことが、持続可能な刷新につながる。
その具体例として挙げられたのが、FQDNの扱いだ。現行システムでは、社内向けと社外向けでFQDNが分かれているものの、アプリケーションのソースコード自体は共通であり、同じコードを異なるFQDNでデプロイしていた。当初はネットワーク経路も含めてFQDNを統一する案が検討されたが、認証方式やユーザー影響を踏まえると、現時点では現実的ではないと判断された。
しかし、ミドルウェア層で柔軟なリバースプロキシ構成を採用していたことで、方針転換は容易だった。FQDNを分離したままでも動作するよう、短期間で構成を調整できたのだ。結果として、この変更は1週間程度で完了した。まさに、「間違えたときに引き返せる設計」が効いた格好だ。
セッションの締めくくりとして川上氏は、LIXIL見積システム刷新における技術的アプローチを振り返った。メーカー系企業でありながら、内製化やクラウド活用、モダンな開発手法に積極的に取り組んでいる点を紹介し、「LIXILがここまでやっているとは思わなかった、と感じてもらえたなら嬉しい」と語る。
刷新はまだ初期段階にあり、今後も継続して進めていく見込みだ。将来的には、生成AIを活用して現行コードと刷新後コードを比較し、ソースコードベースでのカバレッジ評価を行う構想もある。2025年7月時点で約85％の精度が出ており、これを90％以上に引き上げ、定量的に評価できる指標として確立したい考えだ。
川上氏の話から浮かび上がるのは、基幹システム刷新とは単なる技術更新ではなく、意思決定の積み重ねそのものだという事実である。影響範囲を見極め、弱点を理解し、後戻りできる余地を残す──その姿勢こそが、不確実性の高い刷新プロジェクトを前に進めるための、最も現実的なアプローチと言えるだろう。
