Copyright © LIXIL Corporation. All rights reserved. LIXIL基幹システム刷新に 立ち向かう技術的アプローチについて 株式会社LIXIL SoE DevOps. Digital アプリケーションエキスパート 川上月葉（karacoro / からころ） Developers Summit 2025 Summer 

2 株式会社LIXIL アプリケーションエキスパート 川上 月葉（karacoro / からころ） 自己紹介 アプリケーションエキスパートとして、 社内の基幹システム刷新のフロントエンドリーダーを務めており、 TSKaigi 2024 や、Vue Fes Japan 2024 で登壇するなど、 幅広く活動している。 

3 この発表で話すこと・話さないこと ● 話すこと ○ LIXILの基幹システム刷新における技術選定時に、 どのような経緯でどのような意思決定を行なったか ○ その結果、どのような技術選定を行なったか .etc ● 話さないこと ○ マネジメント関連の話 ○ 関係者とのコミュニケーションなどのソフトスキルの話 ○ 詳細設計の話（FEコンポーネント設計など） .etc 

4 アジェンダ ● 現行システムの背景と課題 ● 刷新体制について ○ アジャイル開発を通して不確実性を解消する ○ 段階的な刷新フェーズにより制約を乗り越える ● 具体的な話 ○ CDNのリバースプロキシを活用し段階的移行を実現する ○ API仕様書がない場合の OpenAPI によるAPI戦略 ● 技術選定による影響範囲を明らかにする重要性 ● おわりに 

5 LIXILの事業について ハウジングテクノロジー事業 ウォーターテクノロジー事業 INAX、GROHE、American Standardといったブランドを通じて、使いやすさと美しさを 追求したトイレ、お風呂、水栓、シャワーなどの水まわり製品と表現豊かなタイルを提供 しています。 TOSTEM、EXSIORといったブランドを通して、窓や玄関ドア、エクステリア製品など を提供しています。 リビング事業 キッチン、洗面化粧台、インテリア建材を軸に、LIXILの総合力を活かして、暮らしと空 間に調和する統合ソリューションを提供しています。 

6 デジタル部門の立ち位置について 研究 開発 製造 販売 研究戦略 研究開発 商品企画 商品開発 デザイン 生産管理 品質管理 生産技術 物流・購買 商品企画 商品開発 経理・財務 人事・総務 広報・宣伝 法務 デジタル マーケティング 知的財産 間接購買 

LIXILのアプリケーション開発について 思い浮かべてみてください 

LIXIL基幹システムの1つ 見積システムに関する話 

9 見積システムの概要図 エンドユーザー （お施主）さま コントラクターさま （工務店・ハウスメーカー） LIXIL ショールーム パートナーさま （流通店・代理店） LIXIL 営業・業務 

10 見積システムの概要図 エンドユーザー （お施主）さま コントラクターさま （工務店・ハウスメーカー） LIXIL ショールーム パートナーさま （流通店・代理店） LIXIL 営業・業務 見積を相互連携することで 業務を効率化していく 

11 現行の見積システムの課題 ● システム保守のベンダーへの依存度が高い ● 歴史的経緯によりベンダーから提供を受けた、 Javaベースの独自パッケージをカスタマイズして利用している ● パッケージを提供していただいたベンダーとは、 すでに契約を終えておりブラックボックス化したパッケージの 維持運用がすでに困難な状態となっている ● お客様の要望に柔軟に答えることができず、 顧客機会の損失をしてしまっている 

12 見積システム刷新時の課題と制約 ① ● 提供された独自パッケージへの依存状態からの脱却 ○ FE・BE含めた抜本的な刷新の必要性 ● オンプレサーバで稼働するアプリケーションのクラウド化 ○ 認証方式の課題 ○ オンプレとクラウド間の通信の課題 ○ 認可の課題 . etc ● 利用するユーザーさまへの影響を最小限に抑える ○ アプリケーションの振る舞いを変えない ○ カスタマーセンターへの影響を抑えるために 利用マニュアルを極力変えない .etc 

13 見積システム刷新時の課題と制約 ② ● 他システムとの複雑な依存関係の整理 ○ 数十種類もの他システムとの多種多様な連携機能を持つ ■ iframe・HALFT・FTP・SOAP ● CI/CD の抜本的な見直し ○ 顧客要望に柔軟に対応するためのCI/CDの構築 ○ リリースサイクルの改善 ● システムのハンドリングを社内メンバー主導で行える体制を構築 ○ 現行仕様を紐解き刷新後の設計に適切に反映する ○ ベンダーへの依存度を下げ、社内でハンドリングできるような 体制を整える 

え...課題と制約多すぎる？ 

15 どうやって課題と制約を解消する？ ● 課題はたくさんでてきた、しかし... ○ 課題自体の抽象度が高くどの課題がどのくらいで 終わるかの見通しが立たない ○ 制約が多く課題の優先度を付けづらい ○ システムの依存関係が複雑でどこから着手していけばいいのか... ○ データ構造をどこまでいじるべき...？ 　 アジャイル開発で解決する？ 

16 アジャイル開発は銀の弾丸ではない ● アジャイル開発を最大限に活用するために大事なこと ○ 不確実性の高い課題に対してタスク切る際に いくつかの段階に分ける（調査・評価・ヒアリング・開発. etc） ○ 短いスパンでタスクについての評価を行う ○ 明らかになった課題を明らかになったタイミングで起票する ○ タスクのゴールを起票時に明確にしておく 　 何よりも関係者間で 課題意識をすり合わせることが重要 

17 段階的な刷新フェーズにより制約を乗り越える ● 制約を紐解くために ○ 依存先を整理する ■ ステークホルダー/現行システム, 他システムなどの開発チーム ■ 現行システム/他システム/システム間連携 ○ 対応優先度と技術的な都合を加味して刷新段階を設ける ○ 刷新段階ごとの技術的な課題を列挙する ○ 技術的な課題に対して最適な技術的アプローチを勘案する ○ PoCを通して実際に適用可能かを確認する . etc 

18 ● 提供された独自パッケージへの依存状態から脱却 / クラウド化 ○ 依存先 ■ すべて ○ さらに依存先を小分けにするために技術的なアプローチによって 影響範囲を最小限に抑える ■ FE/BEそれぞれを別段階としたページ機能ごとの段階的な マイグレーションの必要性 ■ 段階的なマイグレーションを実現するためのCDN基盤の構築 ■ アーキテクチャの見直し ■ 認証基盤の見直し、認可制御の見直し .etc 段階的な刷新フェーズにより制約を乗り越える 

もう少し具体的な話をします 

20 ● 現行アプリケーションをページごとに刷新していくために 具体例: CDNのリバースプロキシで段階的移行を実現 Akamai CDN （+認証） ユーザー アクセス Google Cloud ロードバランサ +ミドルウェア （Nginx） Cloud Storage (刷新後FE) 現行BEサーバ Cloud Run functions (刷新後BE) オンプレサーバ 現行FEサーバ Shared VPC 

21 具体例: CDNのリバースプロキシで段階的移行を実現 ● 今回のポイント ○ 全社展開の技術基盤を極力利用する ■ 人的/学習コスト削減 ○ ロードバランサや認証を通す/通さない観点 ■ コスト（お金）の話 ■ 機密情報の話 ■ 可用性の話 ○ ネットワーク経路が実現可能か/目的にあっているか ■ Shared VPC を利用することでオンプレに接続 ■ Nginx（Cloud Run）のオンプレ環境へのリバプロで可能 

22 ● 現行のFEとBEは基本的に REST API に則って通信している ○ 各ページにどのような機能があるかやざっくりとしたレスポンスの仕様は Excelファイルで記述されている... ○ しかしページごとにFEを刷新する際には呼び出しているAPIの レスポンスデータなどのパターンなど詳細なAPI仕様は必須 ○ 今後のBE刷新で期待されている基幹システムのAPI社内標準化などを考える と視認性の高い仕様書の必要性が高まりそう 具体例: 現行のAPI仕様が詳細に書かれていない 　 刷新時に新たに 詳細なAPI仕様書を作成する 

23 ● 新たに作成するAPI仕様書基盤の選定 ○ Google スプレッドシート などの表管理ツールで管理するのは避けたい ○ 開発する上でフロントエンドから移行するということを考えると、 APIでやりとりする際の型定義がデグレーション頻度を下げるために必要 ○ API仕様を OpenAPI で管理することはよくあるけど、 その導入に本当にメリットはありそう？（維持運用面のコストなど踏まえ） ■ もう少し付加価値がほしい 具体例: 現行のAPI仕様が詳細に書かれていない 　 OpenAPI + TypeSpec を利用して インタフェースの型定義を自動生成しよう 

24 ● API仕様であるOpenAPIとTypeSpecを基にした型定義を生成する？ ○ OpenAPI とは ■ HTTP API のプログラミング言語に依存しないインタフェース を構築するためのフォーマット ■ OpenAPI に基づくツール群を Swagger と呼ぶ ○ TypeSpec とは ■ マイクロソフト製で、API仕様をTypeScriptライクに記述できる ■ OpenAPI のフォーマットにコンバートできる ■ TypeScriptの型定義にもコンバートできる ■ 生成AIの学習ケースに取り入れられやすいかも？ 具体例: OpenAPI + TypeSpecによる API仕様書の実現 

25 ● OpenAPI + TypeSpec を基にした型定義などの生成フロー 具体例: OpenAPI + TypeSpecによる API仕様書の実現 TypeSpec 定義 （.tsp） OpenAPI（.yaml） TypeScript 型定義（.ts） compile 静的HTML（API仕様書） 

26 ● TypeSpecで定義したAPI仕様は最終的に静的なHTMLで確認できる 具体例: OpenAPI + TypeSpecによる API仕様書 

27 ● 何が嬉しいか ○ ドキュメント管理（維持運用）の観点 ■ TypeSpecから出力されたOpenAPIによって型定義を生成するため、 開発フローとして仕様書の保守運用が仕組み化されることでAPI仕様 書の維持運用を開発者が継続的に意識できる ○ スキーマ駆動による開発体験向上の観点 ■ Open API から出力されたAPI仕様を静的な HTMLで確認することが できるので他サービスへAPIとして公開する時に利用できる ■ TypeSpecにより出力されたOpenAPIから型定義が出力できるため、 SpreadSheetで仕様書を作成する場合と比べて、仕様書と型定義の 二重管理を避けることができる 具体例: OpenAPI + TypeSpecによる API仕様書 

28 ● CDNのリバースプロキシによりネットワーク経路を変える ○ ❌ 社内インフラチーム / 連携している他システムへの影響 ○ ❌（FQDNの変更がある場合は）ユーザーのブックマークなど ○ ❌ 障害ポイントが増える ○ ✅ 段階的な移行が可能になり、デグレーションを抑制できる ○ ✅ 最終的に可用性を担保しやすくなる .etc ● 仕様書（Excel）を一部 OpenAPI + TypeSpec で刷新する ○ ✅ フロントエンドのデグレーション頻度を抑制しやすくなる ○ ✅ チーム間での透明性を担保しやすくなる ○ ✅ 型定義との二重定義を避けられる ○ ❌ 新しい技術であるため学習コストがかかる .etc 技術選定によってどういう影響があるかを明らかにする 

29 ● 刷新時の技術選定には大なり小なりトレードオフが存在する ○ エンジニアは痛み（弱み）に対して説明責任を果たす必要がある ○ 完璧な技術選定はできない ● ウィークポイントを知った上で技術選定に余白を残す ○ ウィークポイントに影響が及びやすい技術については、 技術選定をすぐに確定させず、間違えた選択だと気づいた時に 他の選択肢に乗り換えられるように設計する ウィークポイントベースで技術を選定する 

30 ウィークポイントを知った上で余白を残した事例 ● 現行システムのFQDNは社内・社外で分かれている ○ しかしアプリケーションのソースコードは同じ ○ ネットワーク経路を含め、FQDNを統一しようと試みたが、 認証の問題とユーザー影響の関係で現時点では どうしても難しいと判明した ● 検証の期間を多くとっていたので何度かの検証で適用前に発覚 ○ ミドルウェア（Nginx on Cloud Run）で柔軟なリバースプロキシ を実現していたことによって、FQDNを分離しても動作する ようにすぐ調整ができた 

31 おわりに ● LIXILの見積システム刷新の技術的なアプローチについて ○ LIXILの見積システム刷新の開発体制について ○ 具体例とともにどのような観点で どのような技術的なアプローチをとっているかの話 ○ メーカー系ながら様々な取り組みをしていること ● 今後の展開について ○ まだ刷新段階としてはかなり初期の方 ○ 生成AIを利用した現行と刷新後のソースコードを比較し、 ソースコードベースのカバレッジメトリクスの評価を実施 .etc 

No content