JJUG CCC 2025 Spring に参加しました。
イベントの概要
JJUG CCCは、例年2回、春と秋に開催する日本最大のJavaコミュニティイベントです。
Java関連の技術や事例に関する良質なセッションが行われ、また異なる分野で活躍するJava技術者が一堂に会する場ともなっています。
みんなでワイワイJavaについて語り合いませんか？
会場はベルサール新宿グランド コンファレンスセンターです。
今回は現地開催のみで、オンライン配信・アーカイブ配信はありません。2025 Springのセッションを聴講できるのは現地に来た人だけ！みなさん新宿に集まりましょう！
引用：
イベント参加の背景
セッション
1. ユニットテスト基礎講座
メモ
生成AIでも単体テストを書いてくれる。ただ、丸投げはできない。
・理由１
AIは確率的にもっともらしいものは出力してくれる。
ただ、雑な指示ででてくるユニットテストは平均点以下。人間が指示しないといけない。
・理由２
生成AIは間違える。
人間がテストの戦略を立てて評価しないといけない。
雰囲気で任せてはいけない。
■パート１：ユニットテストの基礎概念
従来のテストピラミッド。
ユニットテストと統合テストの境界は曖昧。
なので、GoogleではSmall、Medium、Largeで分けている。
ユニットテストの定義が大事。古典学派。
・１単位の振る舞いを検証
・実行時間が短い
・他のテストケースから隔離された状態で実行される
主要な目的。
・期待通りに動作することを検証。
・退行を防ぐ（回帰テスト）
・ドキュメンテーション※テストコードという実例を通して仕様を理解できる。
質の良いテストが必要。
テストコードは散らかりやすい。
プロダクションコードの数倍の規模になる。意識的にきれいに保つ。
質の良いテストとは？テストコードのSOS。
構造化されている。
整理されている。
自己文書化されている。
■パート２：テスト対象の振る舞いの識別
一単位のふるまいとは？
トランザクションスクリプトはユニットテストに不向き。振る舞いが大きすぎる。
Divide And Concur。分割して統治せよ。
振る舞いを分割する。分けること自体が設計行為。
関心を分離する。小さく分割することで、因子数が少なくなる。
結果、テスト条件も減る。
■パート３：質の良いコードを書くためには
・構造化されていること
パッケージ構造。水平分割（技術観点）ではなく、垂直分割（業務観点）でパッケージを設計する。
テストケースの階層化。多階層にしても良い。テストランナーの結果も見やすくなる。
・整備されていること
テストケースを体系的に分類することで見通しを良くする。観点抜け漏れ確認、網羅性確認できる。
コメントでテスト設計の根拠を残すことも重要。
パラメータ化テストを利用することで、冗長化を排除してすっきりできる。
テスト名称は日本語でテスト条件と期待する振る舞いを明示する。
可読性を考慮する。AAA、Given-When-Then。
大きな振る舞い（アプリケーションサービス）に対するテストの実現方法。
単独でテストしない。集合体としてテストする。
テスト戦略次第だが、基本的な代表的なパターンとエッジケースをテストすれば充分と考えることができる。
モックはなるべく使わないことを考える。外部との契約として観察可能な振る舞いに限りモックで検証してOK。
観察できる副作用か、その副作用を無くせないかを考える。
■まとめ
ユニットテスト。１単位の振る舞いに対する検証。
振る舞いを識別、分割をして設計を行う。
テストコードを通して設計の筋の良さを確認できる。
テスト容易性。重要。
テストコードを書きやすい＋テスト設計をしやすい。
テストコードを重要な資産として扱う。
■Q&A
・質問
既に動いているシステムでユニットテストを導入するときどこから手をつける？
・答え
全部網羅的に作るのは工数がかかる。
対象を絞る。重要機能、変更頻度に絞って検討をする。
感想
セッション中のツイートノルマは無事達成しました。（フォロワー10件）
以下、今回のセッションで特に大きかった気付きです。
- ユニットテストのドキュメンテーションの扱い
ユニットテストも作られ方の保証ではなく、ふるまいを保証するという方針が順守されることで、ドキュメンテーションとしての価値もあがりそうだと思いました。 - テストコードが散らかる件
テストコードはプロダクションコードと違い、ユーザー要求を直接反映したものではないため、余計に散らかりそう。
なんだったら、確認する人も意識をしないと少なくなりそう。
なんだったら、中途半端な状態でも目的に対してグリーンになればそのままになりそう。
改めて、ユニットテストについて復習することができました。
週明け現場のアウトプットチャンネルに展開したいです。
2. クレディセゾンの内製開発事例:ユーザー部門と共にSMS送信システムを開発した話
メモ
クレディセゾン。ペイメント、ファイナンス、グローバル。
エンタープライズ開発センター。4年間で17名⇒86名。
内製開発とは。なぜ重要か。
内製開発とは、社員自身がシステム開発に関するすべてを行うこと。
システム開発にはモード１，２がある。
１：ウォーターフォール的、２：アジャイル的。
プロジェクトの性質に合わせて、１と２の割合を変えて内製開発を行っている。
新規開発、既存システムのモダナイズ。
新規はモード２の割合が多め。既存はモード１の割合が多め。
他システム連携は相手に合わせてモード１にする必要がある。
インフォメーションセンターのお悩み。
インフォメーションセンターのPOと開発リーダーで開発を進めていった。
初回ミーティングで要件がほぼ決まっていた。アーキテクチャをざっくり決めていった。
平均顧客対応時間、マーケティング効果向上した。
主な成功要因。ユーザー部門から要望がしっかり出た。他部署調整もしっかりしてくれた。
リリース後２年しているが当初想定していなかった利用用途も含めSNS利用が拡大している。
やりがい。
要件定義から運用まですべて自分たちでできる。
ユーザーから直接フィードバックが貰える。
大切なこと。要望の背景まで聞く。
要望は向こうがこちらに分かりやすく纏めてくれている。
言語化されていない背景も含めて理解をする。
効かれたことは即答する。それによって信頼を獲得する。
大変だったこと。
隠れた要望の表面化。最初から聞いていたつもりが漏れていた。
要望の拡大。必要な時期、業務内容聞いて調整した。
アーキテクト・マネジメント兼務。頑張って解決。
内製開発楽しい。
全部やれる。ユーザーとコミュニケーションできる。
プログラミングでの問題解決を実感。
感想
クレディセゾンさんの内製開発のお話にいつも刺激を頂いています。
要件について背景まで聞くことは直近でも実感するところが多かったです。
3. 事業戦略を理解してソフトウェアを設計する
メモ
最近は実装者としてのソフトウェア開発からは離れている。
大きな泥団子退治のアドバイザ、エンジニア育成支援に向き合っている。
事業戦略を理解して設計しているエンジニア、理解しないで設計しているエンジニア。
どちらが良い設計ができるか？
良い設計とは。変更が楽で安全。
悪い設計とは。変更が厄介で危険。大きな泥団子。
大きな泥団子が生まれる３つのシナリオ。
①卓越した設計でスタート
②最少の設計でスタート
③小さな泥団子でスタート
追加変更時に何を考えないといけないか。何を判断して行動するかが重要。
大きな泥団子の原因。
・関心毎が混在。
・断片化。情報が散らばっている。
・重複。同じことがあちこちに書かれている。
混在⇒分離、断片⇒集約、重複⇒一元化することで大きな泥団子を解消する。
この行動に伴う選択肢に対する判断について、事業戦略の理解が重要となる。
事業活動とソフトウェアシステムの一体化。
あらゆる業務がデジタル化している。
エンジニアの事業理解を通した判断により、直接的に事業価値を生み出している。
エンジニアの設計に使える時間は限られている。
あらゆる場所に丁寧にやるのは費用対効果が悪い。
優先順位を決めて取り組む必要がある。変更が楽で安全になるところに力を入れる。
優先順位の見極めはドメイン駆動設計が具体的なアプローチになる。
中核の業務領域を対象とする。競合他社との差別化×業務ロジックの複雑さ。
競争優位に関わる部分は柔軟に対応できる状態とする。
事業戦略をどうやって理解するか。
経営学、経営戦略での原典はマイケル・Ｅ・ポーターの『競争優位の差別化』。
事業目標、競争要因、事業化戦略の５つの側面。
事業目標の理解。
利益確保。売上-費用。高業績をいかに持続されるかの工夫が事業戦略。
ソフトウェアシステムを構築し運用する理由。
競争要因の理解。
既存企業同士の競争。
買い手、サプライヤーの交渉力。新規参加者、代替品・サービスの脅威。
差別化戦略の５つの側面を理解して設計する。
特徴のある価値提案。提供の仕方の独自性。排他的な選択。戦略に適合。戦略の継続。
差別化のためにソフトウェアを分離、集約、一元化する。
差別化戦略の実行とソフトウェアの実装。
差別化戦略を具体化したビジネスルールが重要になる。
ビジネスルールを具体化した業務ロジックが重要になる。
業務ロジックの断面だけでは、差別化戦略が見えない。
『ドメイン駆動設計をはじめよう』
事業活動とソフトウェアを一緒に発展させていくための方法が纏められている。
異なる知見を持ち寄って、協働して共創する。
感想
「業務ロジックの断面だけでは、差別化戦略が見えない」について。
いかに暗黙的な「私考える人、あなた作る人」の役割を切り崩していくかもあると思いました。
「異なる知見を持ち寄って、協働して共創」していける場を醸成していきたいです。
ポーターのエッセンシャル版は積んで久しいので早く消化したい…！！
4. エンジニアリングでビジネスを加速する。モデル駆動開発という選択肢
メモ
なぜ今「モデル駆動開発」なのか。
DX時代、ビジネスと開発の断絶が現場の大きな課題となっている。
モデル駆動開発は変化に強い現場を作る鍵となる。
ドキュメントの形骸化。
実装に伴う変換が実装とリンクしなくなっていく。
仕様変更が実装者に伝わらない。
モデルが重要となる。
システムで実現すべき業務や機能、構造や振る舞いを抽象化し、明確に表現することによって、それを整理・構造化する。
まずはユースケース洗い出し。
アクター。シチュエーション。実ユースケースの詳細。
メリットと本質。
要件変更や追加に強い構造となる。
関係者全員で同じ絵を見て議論することができる。
モデルを中心した議論をすることで、設計・実装への素早い変更が可能。影響箇所が明確になる。
システムとビジネスをつなぐ生命線となる。
実装の詳細は後から考える。
「何を実現したいのか」の目的から考える。
依存性逆転の原則（DIP）を使う。具体ではなく、より抽象に依存する。
ビジネス上の仕様変更時には、ビジネスルール層のみを着目すれば良い。
大切にしたいことはモデル。ArchUnitによる設計ルール自動化できる。
パッケージを細かく分けることを大事にする。
手続き的から振る舞い的な設計にする。設計段階からどのモデルの振る舞いかを定義する。
コードが生きたドキュメントとなる。
ユニットテストがモデル・実装のずれを即時に検知が可能となる。
前回の資料：
感想
ドキュメントの話からモデルの重要性まで。
事業要求のスピードの変化や、ソフトウェアに求められる寿命が明らかになったことで、従来の開発スタイルでは持続可能性の面で問題があり、その解消方法としてモデル駆動設計を捉えなおすことができました。
事業や業務、ユーザー操作みたいなプロダクトにとって重要なのに、開発チームとの距離が生まれがちな要素に対しての取り組みついて、いくつか武器を持っていたい。
モデルはソフトウェアの構造と似た形で当事者間での共有の認知を醸成するのに役立ちそう。
5. 「イベントストーミングから始めるドメイン駆動設計 ～ 概念モデリングと生成AIで加速するシステム開発」
メモ
セッションの目的・背景。
エンジニアリングも事業の意識が重要。公開情報から知識を得た方が良い。
モデリングを現実扱いやすくする手法。
エンジニアが事業活動を公開情報から生成AIからコスパよく分析する。
モデリングの意義。視点の移動。具体⇔抽象。動的⇔静的。
モデリングの本質的な価値。
多角的な視点でドメインを捉えて、理解を深め、より良いソフトウェア設計に繋げる。
結果、DDD。
ドメイン駆動設計の基本的な考え方とメリット。
考え：ドメイン中心。ドメインモデル。ユビキタス言語。境界付けられたコンテキスト。関心の分離。共創と進化。
メリット：複雑性への対応。共通理解。保守性と拡張性。ビジネスアジリティ。価値への集中。
ただ、ハードルが高い。効果を得るまでの道のりが険しい。
複雑なものは複雑。捨てていかなきゃいけない。
共通理解。なかなか分かり合えない。通じなさ具合は絶望的にもなる。
抽象的なものを自分事として捉えられるまでは年数がかかる。
価値への集中。誰が判断するのか？
ブロッカーはあげたらあげるだけよい。言語化できたら扱える。
真のブロッカー。
複雑なものから不要なものを取り除く。
業務エキスパートと事業活動を肴にワイワイ。（開発だけでの事前演習も吉）
簡単なことから価値は出ない。
量的なブロッカー。
重要な領域なのに、触りたくない状態。
ただ、それはエンジニアとしての責務を果たせていない状態。
大変なものをなるべく簡単にやっつけるには？
モデリング。素振り。
シニア・ジュニア間でも同じことは言える。
ジュニアをAIに置き換えても同じことは言える。
OJTで頑張るは限界がある。新規参画者にフレンドリーな情報が必要。
参考：
目的意識を持つ。
何がしたいかに沿って注力する。
少ないコストで高い効果が得られるようにする。
構造化プロセスは設計プロセスと一緒。
モデリングやエンジニアリングに過剰なコストがかからないようにする。
領域を特定し、分析をする。
イベントストーミング。
参考：
ビッグピクチャー。ざっくりプロセスにし、注力すべき業務領域の検討をつける。
コンテキストマップ。業務領域間の責務の分離を考える。
プロセスモデリング。需要予測の中で何がおきているかを推論モデルで分析。
粒度を指定するためには、ビジネスプロセスモデルのレイヤで粒度を指定。
構造化モデリング。
こうした取り組みを基にワイワイ作り上げていく。
作り上げていったものをもとに話ができる状態となる。
感想
事業領域について開発者で想定していくためのプラクティス。
たとえ的から外れても会話ができる状態にすることが、開発者がビジネスに対して頭を働かせるうえでも、ビジネスの領域に開発者が会話していける状態を作る上でも重要だと思いました。
開発メンバーで合宿とかしてわいわいやると楽しそうだと思いました。
そして、その温度で事業領域に切り込みに行きたい。
6. 変化に強いテーブル設計の勘所
メモ
テーブル設計はまだまだAIには代替されない。
設計のサポートはしてくれるが、設計は自分で解決するしかない。
アプリケーションよりDBの方が寿命が長い。だからDBが今熱い。
データベースは変化に弱い。
DELETEやUPDATEはデータが変化する。commitされたデータは戻せない。
カラム追加時、過去のデータに対する変更が必要。
一度作ったテーブルやレコードを消して良いか分からない。
サービスが成長するとデータベースも肥大化する。
結果、ALTERするとロックでサービスが死ぬ。
特定のカラムを確認するif分の列挙がつらい。
SELECTするまで結果が分からない。テーブル変更恐い。
ビジネスは常に変化する。結果、仕様変更は常にある。
機能開発のためのテーブル変更がビジネス側に不要な制約を生み出す。
本来我々が求める姿ではない。
初期設計で健全な状態が保てていても、
技術面に特化した追加仕様によって壊れることがある。
アプリケーションよりDBの方が
そうした根拠は誰にも引き継がず、よくわからない仕様だけが残る。
参考：
だからこそ、アプリケーション側でロジックを持つことが重要。
DBには状態を持たせない。事実のみを保持する。
そのためにも正規化をする。
正規化のコツ。
事実だけを保持する。重複が無い。不整合が無い。nullが無い。
4つ以上のINDEXが必要な場合は、テーブル設計を見直す。責務が多そう。
参考：
情報と事実は違う。（SQLアンチパターン）
生年月日は事実。年齢はそのタイミングの情報。
情報の方は変更できるようにする。
Small is Beautiful。単一責任の原則。
参考：
DBでいうと、１テーブル１責務。
SimpleとEasyは違う。構造が難しいと知識が無いから難しいは違う。
HardとEasyは知識の差。SimpleとHardは複雑性の問題。
SimpleとEasyは両立する。
テーブル増えても元が難しいから。分けていけば分かりやすくなる（シンプル）。
テーブルがSimpleだと変化に強くなる。
単一責務だと他に影響を与えずに変化に対応できるようになる。
参考：
Easyではなく、Simpleを目指す。
AIでのテーブル設計。
LLMは単語に対してありそうな回答をしているだけ。
サンプル例から作り始める。事実と情報の切り分けもできない。
大きな単位で任せるのは悪手。
捨てる前提のプロトタイプなら使えるが、捨てられないプロトタイプは往々にしてある。
AIはシングルループ学習。
結果から行動を直す。元の前提（プロンプト）に対しては疑えない。
人間が対応する必要がある。前提をみなすことは人がやる。
要求の変更は人にしかできない。
データモデリングは人がやって、モデリングのサポートでAIを活用する。
AIの得意なことをやらせる。
MDからER図やDDLを生成する。DDLからのテストデータ作成。
DDLから想定されるユースケース作成。レビュー（PKあるか？タイポないか？）。
jsonやcsvから必要なエンティティを取り出す。
データモデリングのスキルは寿命が長いし、複利で効く能力。
しばらくAIには代替されない。人間が仕様を考えていくことが大事。
おすすめ本：
7月発行予定の新刊『SQLアンチパターン 第2版 ―データベースプログラミングで陥りがちな失敗とその対策』の情報をAmazonおよび楽天ブックスで公開開始しました！https://t.co/WB7OMstnWYhttps://t.co/hDX8HtueJu
— O'Reilly Japan (@oreilly_japan) 2025年4月26日
感想
RDBがアプリケーションと身近にあるので責務をいまいち混在しがちですが、改めて一緒くたに考えてはいけないと感じました。
アプリが無くなるのとデータが無くなるのとでは全く違う。もっと意識的に分離して扱った方が良いのかも知れない。
そのうえで、データベースについての知識は今後も基礎教養として重要となるイメージができました。学ぶ。
ブース
ウェルスナビさんで頂いたキーホルダーとエス・エム・エスさんで頂いた缶バッチがかなり嬉しいです。ありがとうございます。
ビズリーチさんのブースではプロダクト成長のためにアップデートしたいこととして、
エンジニアと事業領域や実ユーザーの間にある壁？溝？をなんとかしたいというお話をさせて頂いていました。
チームでの「目指したいもの」に対するなんとなくの共通理解や、スプリントを進めるにあたっての協議はできてきている感じはあるのですが、作ったものからのフィードバックがまだよくわかっておらず。
そして、だからこそか、要求や要件のレイヤに対しての主体性がまだ不十分だとも思っています。
そうしたお話をさせて頂いており、ビズリーチさんでの取り組みなどもお聞きできて嬉しかったです。
Folioさんでお聞きした生成AIでの取り組みのお話も興味深かったし、LINEヤフーさんでのJavaに対する取り組みも興味深かったです。
どこのブースでの会話でも生成AIについてがまず最初に話題にあがるようになったイメージがあります。
その他
今日聞きたくて聞けなかったセッションの登壇資料も既に公開されていてありがたいです。
廊下にて成瀬さんにいつも娘とともにコドモンにお世話になっていることご挨拶できて良かったです。
まとめ
今回、JJUG３回目の参加でしたが、朝一から最後までの参加は初めてでした。
一日を通して学びの多い１日となりました。
特に、意図して選んだこともありますが、いかに事業の変遷に対してソフトウェアが適用させるかといった話が多かった気がします。
大きく括ってJavaの関心事のひとつとしても整理できそうで興味深いです。
学び多い濃厚な１日をありがとうございました！
