システム開発におけるドメイン知識の分類
はじめに
「AIがコーディングをしてくれるこれからの時代、エンジニアにはドメイン知識がより重要になる」と言われることが増えました。
一方で、「ドメイン知識とは何か？」と聞かれると、意外と説明が難しい気がしています。
会計知識、労務知識、業界特有の業務フロー、自社独自の運用ルールなど、どれもドメイン知識と呼ばれます。しかし、その範囲が広いため、何を学ぶべきなのか整理しづらいことがあります。
そこでシステム開発におけるドメイン知識を「そのルールを誰が決めているのか」という観点で整理してみました。
1. 世界のルール
法律や制度など、外部によって定義されるルールです。
例:
- 法律
- 税制
- 会計基準
- 業界規制
- 公的制度
特徴:
- システムの外部に正解が存在する
- 自社の都合で変更できない
- 比較的安定している
例えば、会計ソフトを開発するなら会計基準を、人事労務システムを開発するなら労働関連法規を理解する必要があります。
2. 業界のルール
業界内で共有されている概念・用語・業務フローです。
例:
- EC: カート、注文、出荷、返品、SKU、在庫引当
- 飲食: 席、来店、予約台帳、コース予約、席回転
- 人事労務: 入社、退社、雇用契約、勤怠、打刻
特徴:
- 法律ほど厳密ではない
- 業界参加者の共通認識として存在する
- 時代とともに変化する
「その業界でシステムを作るなら当然知っている前提の知識」と考えるとわかりやすいです。
3. 企業のルール
企業独自のビジネスモデルや業務運用によって定義されるルールです。
例:
- 商品や顧客の定義
- 承認フロー
- 料金体系
- ポイント付与ルール
- 各種例外運用
特徴:
- 自社で決定・変更できる
- 他社との差別化要因になりやすい
- システム固有の複雑さを生みやすい
ドメイン知識は何から学ぶべきか
まず世界のルールがあり、その上に業界のルールがあり、さらにその上に企業固有のルールが存在します。
そのため、ドメインを理解する順序としては、
- 世界のルール
- 業界のルール
- 企業のルール
が自然に思えます
例えば会計システムであれば、会計基準を知らずに業界慣習を理解することは難しいですし、業界慣習を知らずに個社特有の運用を理解することも難しいでしょう。
システムの複雑さはどこから生まれるのか
一方で、システム開発における複雑さの源泉は別の場所にあるように思います。
法律や制度には外部に正解があります。業界慣習にもある程度の共通認識があります。
しかし企業固有のルールには外部の正解がありません。
事業の成長や運用上の事情によって変化し続けますし、例外も増えていきます。そのためシステムの複雑さは、企業固有のルールから生まれることが多いように感じます。
つまり、
- 学ぶ順序は「世界 → 業界 → 企業」
- 複雑さの源泉は「企業 → 業界 → 世界」
と言えるかもしれません。
おわりに
ドメイン知識と言うと、法律や業界知識をイメージすることが多いかもしれません。
しかし実際の開発現場で向き合うのは、それらを前提とした企業固有のルールであることも少なくありません。
AIがコードを書く時代になったとしても、「そのシステムは何を解決するのか」「その会社はなぜそのルールを持っているのか」を理解することの価値はむしろ高まるのではないかと思います。
ドメイン知識について考える際は、「世界のルール」「業界のルール」「企業のルール」のどこに属する話なのかを意識すると、少し整理しやすくなるかもしれません。
ボブおじさんが使っているAIコーディングエージェントに与える品質ツール群
きっかけ
Cleanシリーズの書籍で知られるボブおじさん(Uncle Bob Martin)のX投稿を見て、気になったのでやってみました。
Before every check-in, I run a suite of tools that cause the AI to improve the code. Those tools are things like test coverage, crap analysis, mutation testing, and acceptance test mutations.
— Uncle Bob Martin (@unclebobmartin) 2026年5月19日
要点は4つ
- テストカバレッジを取る
- カバレッジと複雑度を測定し、両者の掛け合わせスコアであるCRAPスコアを取る
- ミューテーションテストを行う
- 受け入れテストのミューテーションを行う
テストカバレッジを取る
これはその通り受け取れば良さそう。単体テストを整備して、実行し、カバレッジを測定するモニタリングする。 Codecovのようなツールを用いてもいいし、単体テストに備え付けのレポーターを使ってもいいし、GitHubのプルリクエストでCIを走らせて、結果をコメントで追記させても良さそう。
Claude Codeへの指示でテストコードはしっかり書くようにしているつもりだったが、最初に測定したカバレッジは10%そこそこでした。きちんと測定し続けるのは大事！
参考) CLAUDE.mdのテスト関連指示
## 開発手順
- 先にテストコードを作成してTDDで開発すること
- 異常値、偽陰性、偽陽性、境界値、状態遷移を考慮して入出力＆振る舞いのパターンを洗い出し、テストを整備せよ。
- 形骸的なモックによる無意味なカバレッジ向上はNG。
- ホスト環境への副作用や破壊的変更に注意。
- 冪等性を担保し、実行日時や外部状態に依存しない造りにせよ。
- テストを先に書くだけでなく、実装後のリファクタリングも必要ないか確認すること。
CRAPスコアの算出
CRAPは Change Risk Anti-Patterns の略で、複雑なコードかつテスト不足なコードを検出する指標とのこと。
サイクロマチック数(CC)とテストカバレッジをもとに下記の式で算出できる (Understanding CRAP and Cyclomatic Complexity Metrics)
CRAP = CC² × (1 - coverage/100)³ + CC
30以下だと許容範囲。30〜60だと注意が必要。60以上だとリファクタリングの検討をした方が良いという感覚らしい。
ミューテーションテストの導入
ミューテーションテストはコード中の条件式を変えたり、AND/ORの条件式を書き換えた時、テストがどれだけ失敗するかをテストする手法。
以前から面白い考え方だと思ってはいましたが、業務で整備するのはなかなかコストが重いなと思っていました。 AIコーディングエージェントなら疲れず取り組んでくれるので向いている気がします。
受け入れテストのミューテーションを行う
元の投稿は下記の文章でした。
acceptance test mutations
単に受け入れテスト(E2Eテスト)の実施と読んでいましたが、改めて考えると受け入れテスト自体にミューテーションテストの取り組みを入れているのかもしれません。
たとえば
Given ログイン済み When 商品を購入する Then 注文が作成される
を
Then 注文が作成されない
に変えるようなことです。Playwrightとかの実行コードを書き換えることでも同じようなことができるかな?
バグは見つかった?
それぞれは聞いたことがあっても、個別に導入して使えるようにするには一定労力がかかります。 とはいえClaude Codeに頑張らせることで、7万行程度のLaravelリポジトリに1〜2日程度で実用に載せることができました。
- カバレッジを測定してGitHubのPRにコメントを残すところまで
- CRAPスコアを算出して、スコアが高い箇所のリファクタリングやテストの追加を行う
- Playwright CLIを使った主要画面のハッピーパステストを行わせる
導入過程で見つかった不具合は2件ほどでしたが、今後新しく作られるPRの品質を機械的に引き上げることができそうなのは良いなと感じています。
あとは
- リンター
- 型チェック
- セキュリティスキャン
も組み合わせるとより良さそうです。
AIコーディング時代のチーム開発について考えていること
「実装コストが高い」が崩れた後のアジャイル開発
最近、AIコーディングエージェントを前提とした開発プロセスや組織の形について、ぼんやり考えています。
CursorやClaudeCodeを使っていると、「実装する」こと自体のコストが目に見えて下がります。もちろんまだ万能ではなく、最終的には人間がレビューする必要もあります。それでも、開発の重心は確実に動き始めているように感じます。
とはいえ、自分の現場で十分に試したわけではないので、ここから書く話はかなり机上の空論寄りです。
実装速度はもうボトルネックではないのでは?
従来のアジャイル開発は、「実装コストが高い」という前提のうえに組み上げられていたのではないかと思います。だからこそ、タスクを細かく分解し、見積もり、スプリントに積み、優先順位を慎重に決めることに意味がありました。
しかしAIコーディングツールを使うと、小さな改善や試作は驚くほど速く形になります。そうなると、ボトルネックは実装ではなく「どの課題を解くか」に移っていくはずです。バックログマネジメントよりインサイトマネジメント、という言い方が個人的にしっくり来ています。
課題を大量に積んで管理することよりも、
- ユーザー理解
- 仮説
- 検証から得た学び
- 現場からのフィードバック
をチームで共有することの方が、ずっと価値を持つのでしょう。
イテレーションも、もっと短くなるでしょう。感覚としては、2〜3日のサイクルあたりが自然に思えてきます。 ただし、短くなるのは実装期間であって、人間が考える時間まで短くなるわけではありません。むしろ、ユーザーを観察し、課題を理解し、仮説を立てる部分にこそ時間をかけるべきです。 チームで課題を定め、実装は半日で終わらせ、すぐ次のフィードバックを得る。そんなリズムに近づいていくのではないかと思います。
チームはもっと小さくなる
個人的には、AI時代には小さいチームの方が取り組みやすいと感じています。
極端に言えば、
- エンジニア2名
- デザイナー1名
- 企画1名
ぐらいでも、多くのプロダクトは十分に回せるはずです。実装そのものがボトルネックになりにくいからです。 逆に人数が増えれば、認識合わせ・調整・レビュー・意思決定のコストが一気に膨らみます。 オフショアのあり方も変わるでしょう。これまでは「人を増やして実装する」ことに大きな意味がありました。ですがAIにコードを書かせる前提に立つと、単純な人海戦術の価値は急速に下がっていきます。少人数でコンテキストを共有しながら進めるチームの方が、結果的に速くなりそうです。
ただし、完全な1人開発に振り切るのは避けたいところです。 AIを使えば「それっぽいもの」は簡単に作れてしまいます。だからこそ、本当に妥当な設計になっているか、認識がズレていないかを相互に確認できる人数は必要だと思います。とくにジュニア育成を考えると、完全な個人商店モデルでは続かないのではないでしょうか。
「分担」より「同席」へ
これまではフロント担当・バックエンド担当・アプリ担当・インフラ担当のように役割を分け、並列に進めるのが普通でした。 しかしAIによって一人が扱える範囲が広がると、「手分けする」こと自体の価値が下がっていきます。
そこで重要になるのは、
- 少人数
- 同席
- 高頻度のコミュニケーション
の方ではないかと思います。
一つの課題をその場で議論し、その場でAIに実装させ、その場で確認する。 モブプロに近いですが、人間がコードを書くわけではないので、また少し違う形になりそうです。
AIコーディングの話ではレビューの負荷が問題にされることが多いです。 PRの差分を細かくレビューというより、「変更全体をどう把握し続けるか」を同席の元で素早く行っていく形になるのではないかと。
開発生産性の改善はより重要になる
AIを使い倒すほど、開発基盤の質がそのまま生産性に効いてきます。
具体的には、
- lint
- 自動テスト
- CI/CD
- サンドボックス環境
といった土台です。
設計のひずみを直したり、ライブラリやフレームワークを更新したりする作業は、むしろAIが得意とする領域だと思います。夜間にずっと動かして直してもらうという運用も十分ありえるでしょう。
そうなると重要なのは、「内部実装がどうなっているか」よりも、「外から見た挙動が壊れていないか」です。E2Eテストやオブザーバビリティの重要性は、これから一段上がるのではないかと思います。
リポジトリは「コード置き場」ではなくなる
リポジトリは「チーム知識の集積場所」として下記を含めていくことになるでしょう。
- DBスキーマ
- ドメイン知識
- ユーザー理解
- デザインルール
- 開発規約
特にDBコメントや業務ルールの記述は、これまで以上に重要になります。 AIはコードからある程度推測できるとはいえ、「なぜ存在するのか」「どういう背景なのか」まで書かれていれば、出力の質は段違いに上がります。
モノレポの価値も上がるでしょう。AIコーディングツールは複数リポジトリを横断して読めますが、それでもコンテキストが一箇所にまとまっている方が扱いやすいと感じます。人間向けというより、「AIが理解しやすい構造」を意識する、と言った方が近いのかもしれません。
デザインシステムも同じです。AIに自由にUIを作らせるより、
- コンポーネント
- デザイントークン
- UIルール
を整備し、そこに従わせる方が結果的に安定するはずです。これは人間向けというより、AI向けのガードレールに近いと思います。
チーム目標の切り方も変わる
開発速度が上がるほど、逆にチーム間の調整がボトルネックになっていきます。 ですので、他チームと干渉しすぎず、自律的に意思決定できる単位でチームを切っていく方向に寄っていくのではないでしょうか。 実装能力そのものよりも、「何を達成したいチームなのか」の方が重要になっていきます。
まだみんなが試行錯誤している段階です。数年後には全然違う形になっているかもしれませんが、自分でも実際に試しながら、考えを更新していきたいです。
参考) 似たような課題を扱った記事
アジャイルプラクティスガイドブックの台湾版が出版されます
2023年7月20日に出版した アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 の台湾版が出版されることになり、見本誌をいただきました。
堅めの印象を与える韓国語版と異なり、日本の書籍と同じデザインです。韓国語版・台湾版のオファーは日本語版の出版後、割とすぐにオファーをいただいていました。これで出版にまつわるイベントはひと段落となりそうです。
今でも不定期にXで感想を探していますが、参考になると言っていただけることも多く、書籍を書いてよかったなと都度感じております。執筆した当時は古びない内容を扱って書いたつもりでしたが、AIの浸透をはじめとするソフトウェア開発の変化はここ最近大きく、知見をまとめて残すタイミングとしては本当に良かったです。
初めてチームに参加して開発に取り組む人に、アジャイルなソフトウェア開発の取り組み方のヒントを探している人にとって、1冊で様々な内容を網羅した書籍となっています。ぜひこれからも多くのソフトウェアエンジニアの助けになることを願っています。
アジャイルプラクティスガイドブックの韓国語版が出版されます
2023年7月20日に出版した アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 の韓国語版が出版されることになり、見本誌をいただきました。
固めでしっかりとした紙質 & 堅めな印象を受けるかっこいい表紙に驚きましたが、マンガを交えて開発プロセスを紹介する中身は原著のままです。韓国の方にも広く読まれて、ソフトウェア開発の役に立って欲しいなと願っております。
プロダクトディスカバリーにかけるリソースは何に影響するのか
はじめに
「顧客やニーズを調査して何を作るかを考える」プロダクトディスカバリー作業はとても大事だと思うのですが、ここに時間や人手をかけるとどのような良い効果が期待できるのか、個人的にしっくりきていません。
1. プロダクトデリバリーで成功する確率が上がる 説
「時間をかけて調べたんだから、きっと成功するはずだ」というやつです。 でも時間をかけても100%成功する打ち手なんてわかるはずがないですし、冷静に考えればすぐに違うとわかるはずです。
時間をとって考えた方が成功確率がほんのわずかに上がることはあるのでしょうが、そこに時間をかけるよりも打ち手の数を増やした方が成功する確率は高められる気がします。
2. プロダクトデリバリーで得られる成果が大きくなる(数値がより伸びる) 説
成功率でないとすると「成功したときのリターンが大きくなるはず」と考えたいですが、これもしっくりきません。 そうあって欲しいと願うプロダクトマネージャーの祈りのように感じます。
思いつきでも大きな成果が出る打ち手はありますし、開発工数が大きくなれば成果もつれて大きくなるかというと必ずしもそうではないでしょう。私にはこうあって欲しいという願望以上の理屈が見出せません。
3. 1変更を加えた影響がプロダクトに長く関与する 説
成功率も成功したときのリターンも変わらないのであれば、「グロースハック」のような短期の打ち手をたくさん打てばよいとなりそうです。 しかし、これもプロダクトが場当たり対応ばかりになって中長期で伸びるイメージが湧きません。
中長期を睨み、大小様々な打ち手を組み合わせてプロダクトを改善し、成長する方向に導いていくのだとすると、ディスカバリーへの投資による効果は「打ち手の方向が揃うため、ある打ち手が他の打ち手やプロダクト全体に影響を及ぼしやすくなる」ではないかと考えています。グロースハックのような点の打ち手ではなく、複数の打ち手が相互に関係・影響しあい相乗的な効果が出しやすくなる。
ただし個別の打ち手の成功率や成功した時のリターンは工数とは対してリンクしないので、たくさんの打ち手を考えて筋が良さそうなものをどんどん実行していった方が良い・・・こうではないかと。
おわりに
プロダクトマネージャーの人はどう考えているのか気になります。ぜひ考えをお聞かせください。
リリース間隔が開いてようが、開発はアジャイルにやった方が良いのでは?
はじめに
Xで「toB SaaSはリリース期間を長く取る必要があるので、アジャイルでない開発プロセスでも良いのではないか? (意訳)」という内容の投稿を読み、自分の中では答えが出ている問いだったのでメモがわりの投稿です。
「リリース間隔は短ければ良い」とは限らないプロダクトは確かにある
プロダクトにもよるのでしょうが、「toB向けのプロダクトでは必ずしもリリース間隔が短いことが良いとは限らない」のは事実だと思います。
- プロダクトの展開前に変更内容の周知や、サポート・セールスの教育・学習が必要
- プロダクトの更新作業にコストがかかる。オンプレで運用されているとか
- そもそもユーザーが頻繁なアップデートを望んでいない など
リリース日の決定を開発以外の部門に委ねるメリット
「開発の終了 = リリース」だとすると、リリース日に合わせて成果が最大化できるように開発スケジュールを組もうと考えますが、「開発の終了 != リリース」だとどうでしょう?
「この機能は開発が完了しました。いつリリースしてもらっても大丈夫です。セールス・マーケティング・サポートの都合に合わせて、一番良いリリース日を好きに選んでください」と言えると、いろんな選択肢が考えられます。マーケティングは大きなプロモーションを打とうとするでしょうし、サポートは問い合わせが多い事項の改善を早く出したいと考えるでしょう。リリースタイミングを短くできなくても、いつリリースするかがコントールできると、事業として取れる打ち手は広がります。
過去に聞いて良いと思ったtoBプロダクトのリリース管理のやり方
「オンプレ環境にインストールして利用するタイプのソフトウェア」でしたが、年に3回のリリースが予定されており、「いつリリースされるか」「リリースに何が含まれるか」は公開されていませんでした。問い合わせをするとおおまかなロードマップは共有してもらえ、「いつのリリースに含まれるかは確約できないが、開発チームはこの機能に取り組んでいる。これが搭載されればこんな課題が解決できる」という話は聞くことができました。確約ではないけどおおよその実現時期も知ることはできました。展示会に合わせた大きなプロモーションとともにリリースされることもあれば、しれっと新バージョンが出ているということもありました。内部では希望の期日に開発が間に合うことも間に合わないこともあったと思うのですが、リリース日を調整するなどして対応していたのではないかと思います。
まとめ
リリース間隔が開いていて短くすることが叶わなくても、開発はアジャイルに短いサイクルで確認しながら進めた方が良いし、開発の終了とリリースを同じにしなければならない理由はないはずです。リリースのコントロールをステークホルダーに委ねることができると、事業上の選択肢を広く持つことができます。
