はじめに
こんにちは、データ・AIシステム本部 検索基盤部 検索基盤ブロックの吉永です。
ZOZOは2026年5月30日（土）に東京・新宿のベルサール新宿グランドで開催された「JJUG CCC 2026 Spring」にブーススポンサーとして協賛しました。JJUGは、日本におけるJava技術の向上・発展と一層の普及・活性化を目指して設立された、ボランティアメンバーで運営される日本のJavaユーザーコミュニティです。CCCは、JJUGが主催する「Javaに閉じず」「技術に閉じず」オープンソースを中心とする様々なコミュニティから参加者を募って、コミュニティを横断した「クロスコミュニティなカンファレンス」です。
ZOZOTOWNでは、検索、カート決済、ショップ直送、基幹システムなど、多くの領域でJavaを使用しています。私たちが日々使っている技術を支えてくれているコミュニティへ貢献したいという思いから、昨年秋に引き続き今回も協賛しました。
本記事では、ZOZOのエンジニアが気になったセッションの紹介と、ZOZOブースの様子をお伝えします。
目次
Javaエンジニアが気になったセッションの紹介
ZOZOのJavaエンジニアが気になったセッションをいくつか紹介します。
普通のFeature Flag実践入門
ZOZOMO部OMOブロックの木目沢です。irofさん（@irof）の『普通のFeature Flag実践入門』を紹介します。
Feature Flagについて体系的にまとまった情報があまりなく、非常に役に立つセッションでした。自チームの現状を振り返ると、Feature Flagの利用は散発的でした。導入後の撤去漏れや、AWS AppConfigにおける「インフラ側の管理とコード側の管理を同時に意識しなければならない」という運用コストが課題となっていました。ここ最近は後方互換を保てるリリースだったり、先行リリースしても問題ない状況だったのでFeature Flagをそれほど使わずに済んでいましたが、常にそうした条件が揃うとは限りません。そういう意味でも、今後は積極的に活用していきたいと考えていたので、体系的に説明いただいた今回のセッションは大変貴重でした。
「デプロイとリリースを分離することで、誰が嬉しいのか」という問いが良かったです。その恩恵を受けるのはエンジニアではなくビジネスサイドであるという視点は、改めて重要な示唆を与えてくれるものでした。生成AIの活用によって開発速度が向上しても、リリースプロセスが重ければ効果はあまりありません。自チームはスクラムを採用していますが、スクラムにおいてもスプリントを通じてリリース可能なインクリメントを作り上げることが前提であり、そのリリース自体が重いというのはいい傾向ではありません。
実装面では、Feature Flagの設計におけるON/OFFの制御方針、if/elseの構造、else節の要否といった意思決定が大事であること、撤去が極めて重要であることも改めて確認しました。ログ・監視・マイグレーションとの整合性など、運用上の注意点も網羅されており、実践に直結するセッションでした。
AI時代のソフトウェア設計の学び方
引き続き木目沢が、増田さん（@masuda220）の『AI時代のソフトウェア設計の学び方』を紹介します。
正解のあるなしではなく、増田さんの考えという前提ではありましたが、自分の仕事の範囲における解釈でもやはり「小さな設計の反復×人の活動支援」が今のところ合っていると感じています。コンテキストの制限やLost in the Middleの現象も避けられない現状を見ると、小さな設計の反復をやっていくほうが良いというのが現時点での自分の理解です。
同様に、「ソフトウェア開発」は「事業開発」と「組織開発」と強く結びついているということもすんなり入ってきました。むしろ生成AIで実装は速くできるようになったので、開発者も事業開発や組織開発といった領域に足を踏み入れる余裕が持てるようになったのではないでしょうか？OMOブロックでも去年からビジネス部門と開発部門が一緒になって仕事をすることを始めています。ビジネス部門と一緒にソフトウェア開発をするのはとても良い体験です。
ソフトウェア開発の根底原則は「事業目的の適合性」と「変更容易性」です。特に「ソフトウェア設計のあらゆる原則とパターンは、この変更容易性の原則の特殊化」という言葉には納得しかありません。
気になるのは、生成AIでこのあたりが変わっていくのか、つまり生成AIが読めればなんでもいいのではないでしょうかという論調も囁かれたりします。少なくとも生成AIは「人の活動支援」というスタンスでいるうちは「変更容易性」の原則は変わらないでしょう。私のケースですが、生成AIが変更容易性の高いコードを書くように色々な設計原則をSkillで伝えているのもそういうことかと思います。
「事業目的の適合性」「変更容易性」を学ぶための初級編として「区分」に注目するのは面白いと思いました。思い返せば、売上に直結するような変更をするのに大体「◯◯区分」に手が入っていました。新しいプラン、プランの内容の変更、ルールの追加や変更などですね。
最後に印象的だったのが、内容はあくまで増田さん自身の考えであると繰り返しおっしゃっていたことです。他にも多くの考え方があると承知した上での内容でした（そのとおりの言葉ではないですが、ニュアンスは合っているかと思います）。そもそも生成AIの時代はかつてなく不確実性が高く、1つの答えが存在するはずもありません。そういう意味でも、今の時代は「人と人との相互作用」がより大事なフェーズではないでしょうか。生成AIがこんなに発展しているのに人が大事とはまた面白い時代ですよね。
不変条件と整合性境界ービジネスが決める設計判断と実現パターン
商品基盤部1ブロックの井草です。nrsさん（@nrslib）の『不変条件と整合性境界ービジネスが決める設計判断と実現パターン』を紹介します。
スピーカーのnrsさんも仰っていましたが、朝一から頭をフル回転させるセッションでした。今回のテーマは「不変条件（Invariant）」と「整合性境界（Consistency Boundary）」です。私自身、オブジェクト指向設計に慣れていることもあり、設計を考えるときは「どのオブジェクトをまとめるか」「どこで集約を切るか」から考え始めることが少なくありません。しかし、このセッションで特に印象的だった考え方があります。
「不変条件が先、集約が後」
です。まず考えるべきなのは、システムが守るべきビジネス上のルールです。そして、そのルールが「一瞬たりとも破ってはいけない真の不変条件」なのか、「最終的に整合していればよい遅延可能な不変条件」なのかを見極めることが重要だと説明されていました。
例えば、二重引き落としや二重予約のように、一度破られると後から補償できないルールは即時整合性が必要です。一方で、後から整合性を回復できるものは、プロセスによる結果整合性という選択肢もあります。
なぜこの見極めが重要なのか。それは、すべてを即時整合性で守ろうとすると、トランザクションや集約が肥大化し、システムの変更や分割が難しくなるからです。マイクロサービス化や分散システムを多く扱う今においては、次の問いを持つことが大切です。
「そのルールは本当に遅延を許容できないのか？」
設計者として、この問いを意識することの重要性を感じました。集約から考えがちな自分にとっても、「まず守るべきルールを見つける」という視点は非常に学びの大きいセッションでした。
アンカンファレンス（2）「テーマ：AI×レビュー」
ECプラットフォーム部マイクロサービス戦略ブロックの半澤です。アンカンファレンスの第二部に参加しました。テーマは「AIが生成したコードを全部見るのか」「レビューする手間は増えていないか」で、Javaチャンピオンの谷本さんの進行のもと、ディスカッションが行われました。生成AIを活用した開発が身近になりつつある今、多くのエンジニアにとって関心の高いテーマではないでしょうか。
今回のアンカンファレンスでは、さまざまな観点から意見が交わされました。AIが生成したコードの確認はもちろん、レビューの認知負荷やコードレビューと品質保証の関係、テストや設計で何を担保するのかといった幅広い話題に及びました。
話題の中で興味深かったのは、AIによってコードを書く時間とレビューする時間のバランスが変わってきているという観点です。AIがコード生成を担う場面が増えると、コードを書く時間は短くなります。一方で生成されたコードを確認する作業が連続しやすくなり、レビューの負荷が大きく感じられるのではないか、という話がありました。その負荷を下げる工夫として、コードだけを見るのではなく確認しやすい形を整える方法が挙がりました。AIや自動化を活用して変更内容の可視化・スクリーンショット・テストコード・補助的なドキュメントを用意するのがその例です。
また、コードレビューだけで品質を保証できるのか、という話題も印象に残りました。レビューでソースコードをすべて確認することだけが品質保証ではなく、テストや設計段階での確認など、複数の仕組みを組み合わせて品質を支える必要があります。一方で、レビューによって見つけられる問題があることも確かです。
レビューで何を見るかも、考え方はさまざまです。細かな実装の書き方すべてを見るというより、リスクが高そうな箇所や、自分が実装するとしても迷いそうな箇所を重点的に見るという考え方があります。たとえば次のような観点は、人間が注意して見る価値があります。データの処理方式、アーキテクチャによって影響が大きく変わる部分、テストでは見つけにくい同時処理や状態管理の問題、後から変更しやすい構造になっているかなどです。AIが生成したコードであっても、人間が書いたコードであっても、こうした観点自体は大きく変わらないのだと感じました。
一方で、AIの生成するコードには、生成させた本人も意図を説明しづらい処理が混入することもあります。なぜその実装になっているのか、不要な処理ではないのか、後から変更しやすい構造になっているのか。そうした点を確認するには、単にコードを眺めるだけでなく、テストケースや設計の意図、変更の影響範囲も含めて見ていく必要があります。
品質に対する考え方は、システムの特性によっても変わります。利用者が限られたシステムで、非常に低い確率でしか発生しない不具合であれば、完全に防ぐために大きなコストをかけるよりも、発生時の対応も含めて合理的に判断する方がよいケースもあります。求められる品質水準は、システムの用途や利用規模、影響範囲によって変わるという点も、アンカンファレンスの中で印象に残った話題でした。
私が普段携わっているZOZOTOWNは、多くのユーザーや取引先に関わるサービスです。そのため、一見すると小さな不具合であっても、実際にはユーザー体験や業務に少なからず影響を与えることがあります。
もちろん、あらゆるケースを事前に防ぎきることはできません。しかし、開発工程が後半に進むほど修正コストが大きくなりやすいため、レビューやテストで気づける問題については、できるだけ早い段階で見つけ、未然に防ぎたいと感じています。そして、そのエラーの先には、実際にサービスを利用するユーザーがいます。また、不具合が発生した際には、その対応にあたる営業やカスタマーサポートなどの仲間もいます。小さく見える不具合であっても、そうした対応が積み重なることで、サービスやチームへの信頼に影響するかもしれません。
だからこそ、合理的な判断は大切にしながらも、ユーザーに届けるものに対してできる限り誠実に向き合いたいと思います。今回のアンカンファレンスを通じて、コードレビューを品質保証における重要な工程の1つとして捉える自分の考えを、改めて認識しました。
AIが書いたかどうかにかかわらず、エンジニアとしても、自分たちが届けるものに責任を持つ姿勢は変わりません。AI生成コードとの向き合い方を通じて、自分たちのレビュー観や品質への向き合い方を見直す、有意義なアンカンファレンスでした。
Javaコミュニティの関心の変遷を可視化する：JJUG CCC発表データから見る変化と不変
引き続き半澤が、Ayana Murakamiさんの『Javaコミュニティの関心の変遷を可視化する：JJUG CCC発表データから見る変化と不変』について紹介します。
Murakamiさんは、大学院で情報可視化を専攻していた「可視化オタク」として、遡れる限りの過去のJJUG CCCの発表データを分析されていました。松尾芭蕉の言葉として知られる「不易流行」を軸に、変わらず語られ続けているテーマと、時代に応じて関心が高まっているテーマを、テキスト分析と可視化によって読み解く内容でした。
まず、「変わらないもの」として挙げられていたのは、DBやテーブル設計に関するトピックです。業務の現場で複雑な要件をどのようにテーブル設計へ落とし込むのか、変化に強く柔軟な設計をどう実現するのかといったテーマは、継続して高い関心を集めていました。また、ファイルやクラスといったトピックからは、業務システムの設計だけでなく、Javaそのものの仕組みや内部構造への関心も根強くあるようです。前者は現場での永遠のテーマであり、後者はJJUG CCCでこそ聞きたいテーマでもあります。もし同時間帯に両テーマのセッションがあった場合、どちらを聴講するか迷ってしまいそうです。
次に、関心の高さに周期性があるトピックとして、Spring Bootのアップデートや周辺技術も紹介されていました。Spring BootのメジャーアップデートやJava LTSのリリースに連動するという分析は、自分の経験からも納得感がありました。
「変わるもの」としては、GraalVM / Native Image、Gradle / Maven、コミュニティといった、過去により強く関心を集めていたトピックが取り上げられていました。これらは廃れたというより、現在も議論され続けているテーマです。特にコミュニティに関する発表では、キャリアに関する話題も多かったとのことで、技術だけでなくエンジニアとしてどう成長していくかも、JJUG CCCで語られてきた大切なテーマなのだと感じました。周囲にも「JJUGに育てられた」と感じている人がいますし、自分自身もその一人です。技術的な学びだけでなく、エンジニアとしての視野を広げ、自分の歩み方を考えるきっかけを得られることも、JJUG CCCの大きな魅力だと感じています。
近年関心が高まっているトピックとして、2023年以降ではAIやLLMが挙げられていました。JJUG CCCでは生産性向上や効率化、エンタープライズ領域でのAI・LLM活用が多く語られています。一方、海外のJavaカンファレンスではAIをどうサービスに組み込むかという観点の議論が多いという比較も印象的でした。
JJUG CCCには、コンピュータサイエンスや設計の基礎のように長く大切にされてきた「不易」と、AIやLLMのように時代とともに関心が高まる「流行」の両方があります。Murakamiさんは、その根底にはJavaを使って安定したサービスを届けたいという思いがあると述べられていました。基礎的な知識や新しい技術の両方に触れられる場として、JJUG CCCの魅力を改めて感じるセッションでした。
ZOZOブース 「ソウゾウのナナメウエ × Java」
今回のZOZOブースのテーマは「ソウゾウのナナメウエ × Java」。
お題として「あなたのソウゾウのナナメウエなJava体験を教えて」を掲げ、来場者の皆さんに体験談を付箋に書いてパネルに貼っていただく企画を実施しました。”ソウゾウのナナメウエ”はZOZOのカルチャーです。ZOZOらしくJavaコミュニティを盛り上げたいという思いからこのテーマを企画しました。やらかし談、ドハマりしたバグ、救われた話など、ジャンルを問わずJavaにまつわるエピソードを募ったところ、約70件の体験談が集まりました。
参加してくださった方には、JJUG CCC限定の「Duke×箱猫マックスステッカー」をプレゼントしました。
集まった体験談
集まった付箋を分類すると、以下のような5つのトピックに分かれました。
| トピック | 件数 |
|---|---|
| バージョン・言語仕様 | 19件 |
| Spring・フレームワーク | 14件 |
| コミュニティ・その他 | 14件 |
| JVM・ビルド・運用 | 13件 |
| AI・他言語・開発スタイル | 11件 |
注目のトピックをいくつか紹介します。なお、付箋に書かれた体験談は、参加者の皆さんの表現を活かすため原文のまま掲載しています。
バージョン・言語仕様 関連
新機能への歓迎と現場の苦労がリアルに表れていました。「recordクラス誕生！」「Virtual Threadはいいぞ」という新機能への期待の声がある一方、「Java 8→21移行中！」という苦労話も。「Springバージョン上げたいけどJavaバージョン上げられない…」「JavaのVerupするしないで顧客ともめがち…」という現場の率直な声も並びました。「まだJava 8（担当）」という付箋には、多くの参加者が共感していた様子でした。
AI 関連
今年ならではの傾向が出ていました。「AIが書いてくれるのでJavaを書けない」「AIでGradleの使い方を忘れた」「AIネイティブすぎてJavaが読めない」という声が集まりました。「コードのライセンスの問題でAIが使えなかった」という実務的な課題まで登場し、AIに任せる快適さと任せすぎることへの不安が同居しています。エンジニアコミュニティとして今まさに向き合っているテーマだと感じました。
”沼”系の苦労話
「Eclipseでの環境構築で6営業日溶かした（泣）」「GCチューニングで全部止めた」「ビルド時間にコーヒーのめる」「カレンダーの月が0始まり…」など、思わず笑いを誘うエピソードが並びました。苦労話もユーモアに包んで共有されているのが、JJUGコミュニティらしい温かい雰囲気でした。
今回のお題を通じて、バージョン移行の苦労やAI時代の新しい戸惑いといった技術的なリアルはもちろん、まさに”ナナメウエ”な体験まで、Javaエンジニアのリアルな声が集まりました。苦労話ややらかし談を楽しく共有できる。そんなオープンで温かい雰囲気こそが、JJUGコミュニティの魅力だと改めて感じました！
ご参加いただいた皆さん、ありがとうございました！
まとめ
ブースやセッションで交流してくださった皆さん、本当にありがとうございました。これからも一緒に楽しみながらコミュニティを盛り上げていけたら嬉しいです。次のJJUG CCCでもぜひお会いしましょう！
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
