「JJUG CCC 2026 Spring」に参加してきました

2026/5/30
https://ccc2026spring.java-users.jp/

RestTemplate非推奨化に備えよう！RestClient入門、そしてリニューアルされたSpring Retryでリトライして、WireMockでテストする。

Masatoshi Tadaさん(クレディセゾン)
https://www.docswell.com/s/MasatoshiTada/K1QXMG-restclient-retry-wiremock

RestTemplateは
- Spring7.1で非推奨化
- Spring8.0で削除
  - 意外と早く来るかも
- RestClientが後継
- SpringRetryとも組み合わせられる
RestClient
- RestClientBuilderで作る
- prototypeスコープでDIされる
- application.ymlでのタイムアウトの設定を忘れずに
- HTTPメソッドが違っても全部同じように書けるようになった
- HTTPステータスが400/500系なら例外が投げられる
  - defaultStatusHandler() で挙動をカスタマイズできる
- RestClientException が親でそこから詳細な例外がたくさんある
  - 各HTTPステータスごとの例外とかも
- ClientHttpRequestFactory
  - 5種類実装がある
  - 基本はjdkでいい
  - 依存ライブラリに勝手に変えられないように明示した方がいい
SpringRetry
- ネットワーク越しでのアクセスはさまざまな理由でタイムアウトが起きる
  - クラウドで瞬間的なネットワーク不調
  - オートスケールのタイミング
- SpringFramework本体に入ることになった
  - 独立してた頃と使い方がちょっと変わったから注意
- リトライ方法
  - Retrytemplate
    - ラムダ式を使って書く
    - リトライ間隔/回数などを定義
    - リトライ対象外の例外の指定
    - RetryListenerで失敗時の処理や回数上限到達時の処理
  - AOP
    - 割り込み処理でリトライ
    - Beanにしか使えない
    - RetryListenerを使えない
    - @Retryable
- リトライで考えること
  - そもそもリトライで解決する可能性があることなのか
  - 呼び出し元をどれだけ待たせられるか
  - リトライして問題がない処理か
    - 冪等でない場合はIdempotency-Keyに一意な値を入れて同一リクエストか判断してもらう
WireMock
- テスト用モックサーバー
  - MockRestServiceServer
    - Spring謹製
    - サーバーが起動するわけではない
    - 公式でもこれは古いやつと書かれてる
  - WireMock
    - OSS
  - MockServer
    - OSS
    - 開発が止まってたが最近動き出した
- WireMockの設定
  - http2を有効にしてるとなぜか一部テストが落ちる
  - @ExtendWith だとなぜか一部テストが落ちる
  - このURLにアクセスされたらこのデータを返すって感じで書く
    - 異常時も同じ感じで
    - リトライのテストは何回目はこれを返すって感じにできる

変化に強いテストを育てる、Spring Bootのレイヤー設計

Takeshi Miyajimaさん(株式会社サンアーチ)
https://www.docswell.com/s/tmiya-tech/53JENE-2026-05-30-095125

変化に弱いテスト
- 信頼性が低い
  - テストは通ってるのに動かない
  - 成功失敗が不安定
- 保守コストが高い
  - 機能変更のたびに大量に修正が必要
  - 仕様は変わってないのにテストが壊れる
- フィードバックが遅い
  - 実行が遅い
  - エラーの原因がわからない
プロダクトコードの質とテストコードの質
- 良い設計が良いテストコードにつながる
- 責務の混在をしないで分離する
外部接続の分離
- 外部との接続やフレームワーク依存を薄く分離
  - Controllerはサービスを呼ぶだけ
  - RepositoryをシンプルなデータIOに特化
- 純粋で複雑なロジックを厚くテスト
  - SpringTestに依存しないテストは速い
レイヤー内の分離
- 外部接続を分離して残ったアプリケーションレイヤーが大きくなる
  - 変化に強い構造で責務ごとに分ける
- 判断と処理の分離
  - ValueObjectにロジックを寄せる
- 処理フローと実処理の分離
  - 分岐と処理が分かれるとテストケースが掛け算から足し算に
- 構築と実行の分離
  - 重点してテストが書けるのでテストバリエーションを増やしやすい
  - 境界が安定するまではテストはあえて分離しない作戦もあり
参照系の分離
- 参照と更新で同じモデルを使うと相互に影響し合ってしまう
- 参照と更新では同じ概念でも要件や重視することが違う
  - UIのためとデータのため
- いわゆるCQRS
- 分離するところしないところの見極めも必要
  - シンプルなところまで引きづられると複雑さが増してしまう
- 参照系のみGraphQLを使うという選択も

肥大化するレガシーコードに立ち向かうためのインターフェース分離と依存の逆転

Hirokuni Maetaさん(サイボウズ)

長年の開発で読みづらく変えづらくなったコード
- 巨大なクラス
- 役割が不明なクラス
- 難解なデータ構造
- プロパティが多く用途がわからない
- 依存が多すぎる
Kintoneのデータは木構造で持っている
- 拡張性などのために
- 単純に値を取得/更新するのが難しい
プロパティが多く用途が分かりづらい
- 特化したプロパティが汎用的なクラスにいたり
依存が多い
- 避けられない面もある
- 修正の影響範囲が広すぎる

チーム全員で実施できるプロジェクトに集中するためのゴール設定を磨くスキル

小泉岳人さん(ニッセイ情報テクノロジー)
https://www.docswell.com/s/Insurtech-lab/ZQ297X-2026-05-30-100023

ゴール設定
- プロジェクトでどんな価値を目指すのか
なぜゴールが必要か
- AIで速くつくれるようになったから目指す状態を合わせないと
- 期待が多様な中で人によって考える良いを揃えたい
- 変化が全体のなかで優先することややめることを判断したい
どんなゴールがいいか
- 誰かが決めたじゃなくて皆で決める
- やることを並べるだけでなく何が嬉しいか分かる
時間軸
- 長期: ビジョン
- 中期: 3か月程度
- 短期: 数日〜数週(スプリントゴール)
ゴールの作り方
- 1. ステークホルダーごとのありたい状態を想像する
  2. 長期中期短期の情報を事前に見ておくといい
  3. ビジョンやマスタースケジュールなど
- 1. キーワードをつなげてストーリーに
  2. 物語にして違和感を話していく
  3. 生成AIが物語化してくれる
- 1. リスクや好機を共有する
  2. セイルボート
- 1. やることやらないこと
  2. やりたいことを大量にあげる
  3. やりたい/まあやりたい/やらないにマッピング
- 1. GoalとJoyに分けて書く
  2. 達成したいことと喜んでいる状態
  3. やることだけに偏りがちなところを状態も考えられる
  4. SMART/ALIVE/FOCUS
- 1. ゴールをこまめに確認する
  2. 達成できそうか
  3. モヤモヤする点はないか

大規模なメトリクス収集の仕組みをアーキテクチャ変更して得た学び

Masanori Taniさん(サイボウズ)
https://www.docswell.com/s/uta8a/KJW81E-2026-05-30-jjug-spring-2026

kintoneのユーザ向けダッシュボード
- リクエスト数やレスポンスタイム
- ETLアーキテクチャに近い構成
- リアルタイムで1分単位とかで
一部提供開始期
- 実データでの検証
- 顧客からのフィードバック
- API Gateway - Lambda - Kinesis - EventBridge - Timestream
- メトリクスはFilterしてMicrometerで値を持ちそれを定期取得
一般提供期
- メモリ増大問題/レイテンシへの影響/Filterでとれる情報の制約
- 単にログを出力するだけの設計に変更
- Flient Bit - Kinesis - Firehose - S3 - Glue - OpenSearch
- AWSに寄った

AI時代の開発こそ標準化を武器に！ — 方式・プロセス・プラットフォームの標準化

Shun Watanabeさん(野村総合研究所)
https://speakerdeck.com/s27watanabe/jjug-ccc-2026-spring-aishi-dai-nokai-fa-kosobiao-zhun-hua-wowu-qi-ni-fang-shi-purosesupuratutohuomunobiao-zhun-hua

開発方式の標準化
- ガイドライン
  - 手順や方式の説明
- ライブラリ
  - ガイドの方式を実現するための部品
- サンプル/テンプレート
  - 動くアプリとしての実装例
- 課題感
  - ベースとなるフレームワークの知識はないと使えない
  - 学習コストが課題
- AI活用
  - AIを活用した開発のベースラインとなることを目指す
- AIも活用できる仕組み
  - MCPサーバー
  - 情報量の最適化し余計な情報を除外
- AI駆動開発のためのテンプレート
  - AI向けの情報を含めたテンプレート
  - skillsやrulesなど
  - 設計/開発/テストの各フェーズの分
開発プロセスの標準化
- 工程ごとのAI活用方針
- AI駆動開発のスタイル
- 開発プロセスに対応するテンプレート
開発プラットフォームの標準化
- AIエージェントの標準化
  - ClaudeCodeのエンタープライズ
- LLM基盤
  - 社内ネットワークに閉じる基盤の構築