Java複数アプリ開発の標準化戦略

JAVA複数アプリ開発の 標準化戦略 株式会社星野リゾート 情報システムグループ 藤井 崇介

藤井 崇介 星野リゾート 情報システムグループ シニア・アーキテクト @ZooBonta ・Webシステム関連の開発を10年間経験後、2018年に星野リゾートに入社 ・アジャイル開発を中心とした開発体制の内製化を主導し、 エンジニア組織の立ち上げを行った。 ・2022年〜2024年には、IPAのアジャイルWGとして、アジャイルの普及を行う ・現在は、社内の技術標準化チームを作り、複数プロジェクトの支援を行う D-Plus Osaka（開発生産性コミュニティ）の運営をやっています Hoshino Resorts Inc. https://d-plus.connpass.com/ 2

• https://d-plus.connpass.com/

経歴 1年目 Struts Seasor2 Java6 3年目 5年目 6年目 8年目 10年目 Struts2 Spring MVC Java6 SpringBoot Java7 18年目 SpringBoot Java21 色々ありながらも、18年間Javaをやっています Hoshino Resorts Inc. 3

概要 • 本日の内容 • 標準化に対するモチベーション 標準化の取り組み • 標準化と生成AI • • 本日話さないこと • フロントエンドの標準化 • インフラの標準化 Hoshino Resorts Inc. 4

標準化に対する モチベーション Hoshino Resorts Inc. 5

なぜ標準化をやるのか？ ◼ 設計・実装だけでも考えることはたくさん API設計 URL ログ テーブル設計 変数名 性能 ドメイン設計 データ構造 準正常系 処理ロジック 必須・任意 6

なぜ標準化をやるのか？ ◼ システムの保守・運用に対する悩み ◼ 日常的に30個くらいのリポジトリを見るので切り替えが大変 ◼ 画面、ログくらいしか手掛かりがないこともある ◼ 時間が勝負の時は、問題の箇所を効率的に調べたい ◼ 同じような処理があると、混乱する ◼ バージョンアップへの追従も必要となる kintoneの施設マスタ 7

なぜ標準化をやるのか？ ◼ 認知負荷を下げ、生産性を上げる 課題内在性負荷 課題外在性負荷 学習関連負荷 取り扱う課題が元から備えている 本質的負荷 取り扱う課題とは 直接関係ない負荷 課題を理解するために新しい情報 を既存の知識と結びつけ、脳内で 「スキーム」を構築する際に生じる、 学習にとって有益な認知負荷 属人化を減らしつつ、 関係ない負荷はできるだけ減らしたい 8

なぜ標準化をやるのか？ ◼ その他 ◼ 重複した開発や作業の削減（バージョンアップもここ） ◼ プロジェクト間のメンバーの流動性向上 9

標準化の取り組み Hoshino Resorts Inc. 10

進めた時の体制 ◼ 体制 ◼ 3〜4名くらいで専属チームを作った ◼ プラットフォームという位置付けにした ◼ プラットフォームをある程度作ったら、プロダクトに適用 外部から部分的に協力 横断チーム プロダク トーム 標準化 チーム ISBN-10: 4820729632 Hoshino Resorts Inc. 11

やっていること ◼ 言語・フレームワーク・ライブラリの統一 ◼ 言語：Java21 ◼ フレームワーク：SpringBoot ◼ ライブラリ：log4j2, commons-collections… ◼ データベース関連：PostgreSQL、Spring Data JDBC ◼ 共通化したいものの洗い出し ◼ OpenAPIやDBスキーマの生成方法・配置場所 ◼ 例外時のレスポンス ◼ Queueの使い方 ◼ ログの管理方法 Hoshino Resorts Inc. 12

やっていること ◼ Wikiでルールを記載 ◼ アーキテクチャ（モジュール構成・DDD・プロファイル） ◼ 命名規則 ◼ 時刻に関するルール（タイムゾーンの扱い、フロントとのやりとり） ◼ ログの考え方 ◼ DBに関するルール（シークレット管理、ID生成ルール、ORマッパーの使い方） ◼ マルチスレッドの方針 ◼ インフラ周り など・・・ Hoshino Resorts Inc. 13

共通実装 ライブラリ バージョン 使用するライブラリのバージョ ンをまとめて管理 このモジュールのバージョンを 上げると、まとめてあがる ログ ログ処理の共通仕様。 loggerへのアクセスを容易にする 例外 アプリケーションで利用する例 外オブジェクト アプリケーション Web共通 Webアプリケーションの共通仕様 ・ヘッダー情報 ・認証 ・エラー時のフォーマット AMQP kintone Hoshino Resorts Inc. 連携サービスのWrapperクラス ログやアクセスしやすいUtilityを 提供 14

共通実装 ◼ Github Packagesを使い提供 [pom.xml] <parent> <groupId>com.hoshinoresorts.app.core</groupId> <artifactId>spring-base</artifactId> <version>version.20251013</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>com.hoshinoresorts.app.core</groupId> <artifactId>web</artifactId> </dependency> </dependencies> Hoshino Resorts Inc. 15

共通実装例（例外の伝播） ◼ 例外の伝播 フォーマットが変わると、アプ リケーション毎に実装が必要 例外はアプリケーションと同様に 扱いたい { “message”: “エラー発生”, ”detail”: “存在しないコードを指定” 共通サービス１ } アプリケーション① BFF { “title”: “エラー発生”, ”description”: “存在しないコードを指定” 共通サービス２ } アプリケーション② BFF 共通サービス３ Hoshino Resorts Inc. 16

共通実装例（例外の伝播） ◼ 例外の伝播 [呼び出し元] [呼び出し先] try { hogehogeApi.fuga(); } catch(BussinessLogicExcetpion ex) { // 例外処理 } If (エラー発生) { throw new BussinessLogicException(CODE); } [RestTemplateConfig] [ExceptionHandler] @Bean @ExceptionHandler public RestTemplateBuilder restTemplateBuilder() @ResponseStatus(HttpStatus.CONFLICT) return config.errorHandler(new ResponseErrorHandler() { public ExceptionResponse exception(BusinessLogicException ex) { @Override return ExceptionResponse.of(ex); public void handleError(ClientHttpResponse response) } throws IOException { // Exceptionを生成して、throwする。 }} 17 Hoshino Resorts Inc.

その他 ◼ ビルド・デプロイ ◼ OpenAPIはDBスキーマの出力場所 ◼ テストの実行タイミング ◼ Jobの分け方（GithubActionsを使用） ◼ デプロイ方法 ◼ アプリケーション構成 ◼ サーバ（Amazon ECS） ◼ アプリケーション間通信 ◼ 認証・認可 Hoshino Resorts Inc. 18

標準化で気をつけていること 1. 世の中のベストプラクティスは積極的に取り入れる →多くの人が使うものは、良いものが多い 2. 一部の人の好みはあまり入れない →１人がプロダクトを触る期間は長くない 3. 試したいことがあれば、小さく試す。 Hoshino Resorts Inc. 19

標準化で難しいこと 1. 現実的にすべての規約に従ってはいない 1. プロダクトによって適用がまちまち →認知活動やレビューが必要 2. 標準化に課題がある場合もある →フォローアップの場を設けて取り組み中 2. 標準化を直す人が不足しがち →小さなタスクからまずは触ってもらう 3. コピーして作っているところは、標準化の変更の追従が大変 →生成AIに期待したいところだが、現状はチェックリスト運用 Hoshino Resorts Inc. 20

標準化と生成AI Hoshino Resorts Inc. 21

生成AIの開発での得意な領域 得意な領域 大量のデータを扱う処理 ❏ 反復的なタスクの自動化 ❏ パターンからの予測判断 ❏ 苦手な領域 データの量が少ない ❏ 複雑な文脈理解が必要 ❏ 学習データの質がバラバラ ❏ ⚫ データが少ないプロジェクトの初期段階は苦手 ⚫ プロダクトのアーキテクチャや作法はそろっている方が良い ⚫ 複雑な処理は精度が落ちる Hoshino Resorts Inc. 22

生成AIを使った開発 業務分析 仕様書 テンプレート 要件定義 ユースケース作成 ドメイン設計 API設計 データ設計 生成AI 規約 開発ルール 生成AI ユースケース作成 ドメイン設計 API設計 データ設計 ソースコード ユニットテスト テストケース Hoshino Resorts Inc. 23

生成AI時代における標準化の意義 ◼ 生成AIを効率的に活用するためのプラットフォーム ◼ テンプレートや規約、開発ルールが整っていることが、 安定したアウトプットにつながる ◼ 類似した機能や処理は、生成AIに任せられる ◼ 標準化できない領域にエンジニアの価値を発揮する ◼ ビッグデータを効率的に処理するアーキテクチャの検討 ◼ 高速なレスポンスが求められる処理のチューニング ◼ 生成AIの結果のレビュー Hoshino Resorts Inc. 24

生成AIのチューニング [ルール定義] [プロンプト] Hoshino Resorts Inc. 25

まとめ • 標準化に対するモチベーション • 認知負荷を下げて、悩みを減らす • 重複した機能開発を減らす • プロジェクト間のメンバーの流動性向上 • 標準化の取り組み • 標準化チームの体制 • 標準化でやっていること • 気をつけていることや難しいと感じていること • 標準化と生成AI • 標準化は生成AI活用のプラットフォーム • 標準化が難しい領域に専念することになる Hoshino Resorts Inc. 26

Hoshino Resorts Inc. https://hoshinoresorts.com/jp/recruit/mid-career/2992/ 27

• https://hoshinoresorts.com/jp/recruit/mid-career/2992/

ありがとうございました https://hoshinoresorts.com/jp/ Hoshino Resorts Inc. 28

• https://www.hoshinoresorts.com/