はじめに
2026年5月30日に開催された、日本最大のJavaコミュニティイベント「JJUG CCC 2026 Spring」に、アットウェアからメンバー6名が参加してきました！
JJUG CCC は、日本Javaユーザーグループ（JJUG）が春と秋の年2回開催しているカンファレンスで、Javaを軸にしつつ、設計・開発プロセス・CI/CDなどソフトウェア開発全般の幅広いテーマのセッションが揃う、Javaエンジニアのお祭りのようなイベントです。
今回の全体的な印象として、タイトルに「AI」と謳っていないセッションでも、当たり前のようにAIを活用した事例が盛り込まれており、「AIを活用した開発」がすっかり開発現場に浸透したことを実感する1日でした。
この記事では、参加したメンバーそれぞれが特に印象に残ったセッションを持ち寄り、感想とあわせて紹介します。当日の熱気が少しでも伝われば嬉しいです。
AI 時代のソフトウェア設計の学び方
スピーカー：増田 亨さん
資料：Speaker Deck
AI開発が加速する中で、ソフトウェア設計の考え方そのものがどう変わっていくのかを捉えたい、という動機で聴講したセッションです。
設計の方向性として「大きな事前設計」ではなく「小さな設計の反復＋人の活動支援」を軸に据えること、そして事業開発・ソフトウェア開発・組織開発は一体で相互作用するという前提が示されました。ソフトウェア設計の根本原則は「事業目的適合性」と「変更容易性」の2軸であり、特に「区分がらみのコード」の変更容易性改善が、事業とコードのつながりを掴む近道になるとのこと。学び方としては、OADIループ（観察→評価→設計→実装）を回しながら体験的・実践的に学ぶことが推奨され、『リファクタリング』で練習し、『マイケル・ポーターの競争戦略』で視野を広げる、という具体的な指針も紹介されました。
「観察・評価」の意義を再認識しました。AIが生成する成果物、AIの設計能力、ハーネスによる精度を効果的に観察・評価する必要があると考えています。チームとAIが協働する開発においては、スループットと精度のバランスを取りながら意思決定を重ね、観察・評価を機能させることに難しさを感じています。実践的なプラクティスを確立したいです。
また、事業目的に立脚した意思決定能力が不可欠だと感じています。その強化のためにも、視野を広げ視点を増やしたいです。AIによってそれらしい解が手軽に得られるからこそ、自分の幅を狭めない学習姿勢が重要だと考えています。
（Fumitaka Yokoyama / バックエンドエンジニア、Java歴4年）
スパゲッティコードの次はカッペリーニコード？ ― AI時代に問われる設計責任 ―
スピーカー：森本 真司さん
参考記事：スパゲッティコードの次は「カッペリーニコード」？ AI時代に問われる設計責任（GMO-PG Tech Blog）
AIを使ったコーディングで似たような経験があり、課題感としてちょうど悩んでいたテーマだったことから聴講したセッションです。
AIにコードを書かせると小さいクラスが量産され、ロジックが点在しやすい――AIはコード全体を俯瞰できないため、場当たり的な「とりあえず動くコード」を生成する傾向がある、という問題提起から始まるセッションでした。対策として、パッケージ構造などの設計のガードレールを事前に決めることが重要であり、ArchUnit や JDepend といった構造の制約ツールも選択肢として有効とのこと。設計の全体構造を決めるのはあくまでエンジニアの役割であり、AIが設計上の判断をうまく行えるようにするには、モジュール構造だけでなく、単一責務の原則・テストしやすい構成・依存方向の強制といった設計観点そのものをAIに伝える仕組みが必要だと語られました。
セッションを聞きながら、自分も同様の経験があることを思い出しました。AIは既存のコードをざっくりとしか理解していないため、設計の意図を汲んだコードを書くのが苦手だと感じています。
この課題への打ち手として、常に最新のシンボル一覧を取得できる仕組みや、JavaDocをベクトル検索できる環境があると、AIが全体を理解しやすくなるのではないかとも感じています。また、シニアエンジニアが設計判断に至る思考回路そのものをプロンプトとしてAIに与えることで、経験の浅いメンバーが「AIがそう言っているから」という判断に依存してしまうリスクを減らせるのではないかとも思いました。設計のガードレールをチームの資産として整備していくことを、今後の課題として取り組んでいきたいです。
（mno007 / Java歴 9年くらい）
JavaDoc 再入門 ― AI時代のドキュメント戦略 ―
スピーカー：なぎせゆうきさん
資料：Speaker Deck
AI云々以前に「JavaDocになっていないJavaDoc」を見かけることがあり、タイトル通りの再入門と、今後JavaDocまわりを改善するためのインプットを期待して聴講したセッションです。
キーポイントは3つ。まず「誰のための何のドキュメントか」――コードを読み解かなくてもわかるように、守るべき条件と保証される出力を書くこと（Design by Contract）。次に「ドメイン固有情報の補完」――AIは「一般的」なケースで補おうとするため、ドメイン固有の情報は知らないということ。そして、今はJavaDocをMarkdown形式で書けるようになっている、という点です。
JavaDocそのものに関しては、再入門のタイトル通りの内容でした。しかし、これができていないのが実情だと思います。とくに既存プログラムは暗黙的知識の上に組まれていることが多いです。そういった知識をAIに対して明示することが必要なのは、同意する点でした。
（M.Kikuchi / プログラマ、エンジニア。Java歴 10年、他過去に C#・C++・Python・React・ユーザビリティ）
AIだと陥りがちなJakarta EE最新技術への移行時の落とし穴とその解決策
スピーカー：長尾 貴浩さん
資料：Speaker Deck
古い Java EE のシステムをAIで移行するという、今後案件として増えそうなテーマに惹かれて聴講したセッションです。
Java EE 5 Platform から Jakarta EE 11 Platform への移行を題材に、SOAPなWebサービスからRESTful Webサービスへの移行と、EJBからCDIへの移行という2つのケースが取り上げられました。移行ツールには「ルールベース」と「機械学習ベース」の2種類があり、機械学習ベースは文脈を理解できるため柔軟に対応できる一方、出力が非決定的になるため期待通りにならないケースがある、という整理が示されます。その課題に対して複数エージェントモデルを活用したテスト移行を試みており、うまくいかないケースの発見方法と、それに対処するためにAIへの入力として何を渡したか、が具体的に語られました。
「こういうの！こういうのが聞きたかった！」というのが率直な感想です。
AIを活用したモダナイゼーションの話は増えてきましたが、「うまくいきました」で終わるものが多い印象でした。このセッションは、うまくいかなかったケースにきちんと向き合い、それに対してAIへの入力をどう工夫したかまで踏み込んでいたのが非常に良かったです。
複数エージェントモデルを使ってテスト移行するアプローチは、実際の現場でも使えそうなイメージが持てました。世の中には古い Java EE ベースのシステムはまだあるはずで、「移行したいけど手が出しにくい」という状態のものが対象として考えられそうです。今回のアプローチを参考に、まずは小さい範囲で試してみたいと思っています。
（Tetsuji ITAGAKI / Java歴 20年、なんでもエンジニア）
Gradle×GitHub ActionsでCI時間を約50%短縮 ─ ジョブ分割の設計と落とし穴
スピーカー：冨澤 宝斗さん
資料：Speaker Deck
CI/CDジョブの改善は業務上どうしても後回しにされがちな問題であり、ジョブの効率化にどう対応したのかが気になって聴講したセッションです。
生成AIの登場やメンバーの増員により実装が高速化してくると、CI待ち時間が開発サイクルのボトルネックになり、高速な開発やプロダクト検証を止める要因となる――だからこそCIの実行時間削減が必要である、という問題意識が示されました。具体的には、ジョブの分割・並列化によって効率よくジョブを実行させ、さらにリントジョブ時に取得するgit履歴を「すべて」から「作業ブランチを切り出したコミットから直近50件」に変更することで、実行時間を短縮したとのこと。ジョブ分割は「分けて終わり」ではなく、最適化の判断基準として、設定は「選定条件」で、ジョブの依存は「データ」で見直すことが大事、というのがポイントです。
CI/CDジョブの修正は、他の開発作業と比較するとユーザーの目に届かず、直接システムへ影響を与えるものではないため、一度動いてしまえば必要でない限り修正をしない、ということが経験としてあります。だからこそ、なぜ必要か・どのように考えるべきか・どう対応すると良いかまで具体的に話を聞くことができて嬉しく、大変興味深い内容でした。
特に「なぜ必要か」の部分は、プロダクトオーナーなどステークホルダーへの説明として利用できる内容だったため、ぜひ自分の関わるプロジェクトの説明でも参考にしたいと感じました。
（i-itagaki / Java歴 5年。最近は TypeScript、Python がメイン）
チーム全員で実施できるプロジェクトに集中するためのゴール設定を磨くスキル
スピーカー：小泉 岳人さん
資料：Docswell
技術の話だけでなく、チームづくりに踏み込んだテーマにも関心があって聴講したセッションです。
ゴール設定が弱いと、人によって期待がバラバラになり、ズレたものがAIで早く増殖し、タスク消化が目的化してしまう――という、AI時代ならではの問題提起から始まります。その上で、ゴール設定はチーム全員で取り組むスキルとして習得できるものであり、ゴール設定をストーリーにして違和感やモヤモヤについて話し合い、何度も確認しながら育てていくことが大事だと語られました。
ゴール設定において「やらないことを決めるのが一番大変」という点は共感を覚えました。Nice to have なものは無数にある中で、何をやらないかが明確になっていないと、結局は各自がやりたい・やれることだけをやってしまい、チームとしての力が発散して良い結果に結びつかない、ということはよくあるように思います。
キーワードだけで終わらせるのではなく、それらをつなげてストーリーにして違和感を話し合うというのは、全員がゴールを自分ごとにするために有用なプロセスだと感じました。そのストーリーをAIに作らせれば全員が忖度なくディスれる、というのは、ゴール設定に限らずさまざまな場面でチームの本音を引き出すのに使えるテクニックだと思いました。（そんな技を使わなくても率直に語り合えるチームでありたいですが）
（田代 泰介 / Java歴 20年）
まとめ
ソフトウェア設計、AIとの協働、ドキュメント戦略、レガシーシステムのモダナイゼーション、CI/CD、そしてチームのゴール設定と、6名それぞれがまったく違う切り口のセッションを持ち帰ってきましたが、並べてみると「AIと協働する時代に、人間のエンジニアは何を担うべきか」という共通のテーマが浮かび上がってくるのが面白いところです。
こうしたカンファレンスに参加すると、日々の業務だけでは得られない刺激や、他社の現場のリアルな知見に触れることができます。今回持ち帰った学びは社内でも共有し、今後の開発に活かしていきたいと思います。
次回の JJUG CCC 2026 Fall は 2026年11月28日 に開催予定です。アットウェアはこれからも、技術コミュニティへの参加と学びの共有を続けていきます！