PRDから始める、生きたドキュメントと実装への最短ルート

4.5K Views

September 11, 25

#dena ai talks

スライド概要

人間にもAIにも理解可能な「実装設計図」をチームの共有知として確立するために、kencomチームがとったアプローチについて解説します。

イベント概要: https://dena.connpass.com/event/364933/
アーカイブ動画：https://youtu.be/r0CO2zEWgJg

DeNA_Tech

@DeNA_Tech

スライド一覧

DeNA が社会の技術向上に貢献するため、業務で得た知見を積極的に外部に発信する、DeNA 公式のアカウントです。DeNA エンジニアの登壇資料をお届けします。

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

（ダウンロード不可）

関連スライド

Roslynアナライザー_ Unityでの開発環境を改善するための静的解析の仕組みの構築

DeNA_Tech 65.4K

ディメンショナルモデルの実導入と実装について

DeNA_Tech 50.6K

Difyによる全社LLMプラットフォーム運用とv1アップデート

DeNA_Tech 40.6K

GraphQLやるならDataloaderを使おう

DeNA_Tech 33.9K

GitHub Actions x Unity プロジェクトの裏側

DeNA_Tech 29.9K

【DeNA TechCon 2025】 DeNAがマスタデータ管理にOyakataを使う理由

dena techcon 2025

DeNA_Tech 28.2K

各ページのテキスト

PRDから始める、生きたドキュメントと実装への最短ルート黒木保 DeSCヘルスケア製品開発統括部プロダクト開発部開発グループ株式会社ディー・エヌ・エー © DeNA Co., Ltd. 1

自己紹介黒木保 (tamotsu.kuroki) DeSCヘルスケア製品開発統括部プロダクト開発部開発グループ ● ● ● 2022年4月: DeNA入社 2022年7月: DeSCヘルスケア配属 ○ kencom 新規開発・保守・運用チーム最近 ○ kencom 効率化チーム ○ kencom データ連携リアーキテクチャチーム @John-bardera @John_bardera [email protected] © DeNA Co., Ltd. 2

kencomって？ 1 ● 2015年からサービス提供！ ● いろんな健診・ライフログデータをアプリで見れる！ ● ポイントとかの概念がある！ ● ユーザにも種類がある！ © DeNA Co., Ltd. 3

要求をどうやってコードに落としていますか？ © DeNA Co., Ltd. 4

2 コードに落とすまで ● 要望 © DeNA Co., Ltd. 5

2 コードに落とすまで ● 要望 ● ユーザーストーリー © DeNA Co., Ltd. 6

2 コードに落とすまで ● 要望 ● ユーザーストーリー ● 機能要件 © DeNA Co., Ltd. 7

2 コードに落とすまで ● 要望 ● ユーザーストーリー ● 機能要件 ● ドメインモデル設計 © DeNA Co., Ltd. 8

2 コードに落とすまで ● 要望 ● ユーザーストーリー ● 機能要件 ● ドメインモデル設計 ● DB設計 ● … © DeNA Co., Ltd. 9

10.

全て「共有知」にできていますか？ © DeNA Co., Ltd. 10

11.

3 私たちにはできていなかった ● ドキュメントが部分的にしか存在しない ● 人によってドキュメントの質が不安定 ● 情報が古く、メンテナンスされていない ● 結局、実装した人に聞くしかない ● 最終的には、コードを読まないとわからない © DeNA Co., Ltd. 11

12.

なぜできなかったのか © DeNA Co., Ltd. 12

13.

なぜできなかったのか A. 圧倒的にコストが高いから。 © DeNA Co., Ltd. 13

14.

「暗黙知」へ依存 © DeNA Co., Ltd. 14

15.

暗黙知による課題 © DeNA Co., Ltd. 15

16.

手戻りコストの増大共有知が足りておらず、レビュー段階で実装の修正が必要になる © DeNA Co., Ltd. 16

17.

開発の属人化・ブラックボックス化担当者不在による開発停止リスク © DeNA Co., Ltd. 17

18.

AI活用の阻害指示に必要な「実装意図」「ドメイン知識」の不足 © DeNA Co., Ltd. 18

19.

私たちのアプローチ © DeNA Co., Ltd. 19

20.

まずゴールを設定した © DeNA Co., Ltd. 20

21.

人間にもAIにも理解可能な「実装設計図」をチームの共有知として確立する © DeNA Co., Ltd. 21

22.

1 © DeNA Co., Ltd. 要件駆動ドメインモデリング自動化プロセスの全体像 22

23.

要件駆動ドメインモデリング自動化プロセスの狙い 2 ● ドメインモデルなどの仕様と同時に、仕様の意図を含めた情報全てが管理できる ● AIのプロセスとしてまとめることで、設計の道順で迷わない、質が一定 ● コードと同じリポジトリにあることで、AI活用が容易 ● 単純にGitによる差分・ログ管理が可能 © DeNA Co., Ltd. 23

24.

3 © DeNA Co., Ltd. ユーザーストーリーの作成 24

25.

ユーザーストーリーの作成 3 ● 入力 ● ○ 要求(PRD) ○ (Legacy Code) 出力 ○ ユーザーストーリー ■ © DeNA Co., Ltd. 受け入れ基準を持つ 25

26.

要求の例: 3 ユーザーストーリーの作成 # 企業データ連携 PRD ## 業務背景 ● 入力: 要求(PRD) ○ 現在はPRDほど厳密ではない ○ 「あるドメインモデルは、こういう業務背景をもち、ざっくりこんなことを実現したい」を書いたもの弊社システムに契約企業より提供された企業データを取り込み、他のすべてのデータ（社員等）の基盤となる企業マスターデータを構築します。 ## スコープ - `弊社システム API`からの企業データ取り込み(同期処理) - 企業マスターデータの管理(新規作成・更新・論理削除) - 外部システム向け企業情報提供 API - データ連携結果の監視機能 ## 実現したいこと ### データ連携 - `us-0010`: `弊社システム API`による企業データ取り込み ### API 提供 - `us-0011`: 企業情報取得 API を提供 © DeNA Co., Ltd. 26

27.

3 ユーザーストーリーの作成テンプレート: # [機能名] ユーザーストーリー ● プロンプト ## ストーリー ○ ユーザーストーリーはこうあるべき！に従って - As a [ユーザーの種類・役割] - I want [実現したい機能・行動] - So that [得られる価値・目的] ○ ファイルに出力して ### No [XXXX-0010] ○ わからないことは人に聞いて - Given - [前提条件1] - [前提条件2] - When - [実行する行動] - Then - [期待される結果] … © DeNA Co., Ltd. 27

28.

3 ユーザーストーリーの作成ユーザーストーリーの例: # 企業データ取り込みユーザーストーリー ● 出力: ユーザーストーリー ○ ○ © DeNA Co., Ltd. 受け入れ基準は他にも「既存企業レコード更新」「企業レコード論理削除」「API接続エラー時の処理」「データ形式エラー時の処理」ファイルとして出力される ## ストーリー - As a システム管理者 - I want 弊社システムAPIから企業データを取り込みたい - So that 企業マスターデータを最新状態に維持し、他のデータ連携の基盤を構築できる ## 受け入れ基準 ### No 0010-0010: 新規企業レコード作成 - Given - 弊社システムAPIから取得した企業データのうち、企業IDがDBに存在しない企業がある - When - 企業データ取り込み処理を実行する - Then - 新規企業レコードが作成される - 企業ID、企業名、企業コード、その他企業情報がDBに保存される - 作成日時、更新日時が現在時刻で保存される 28

29.

4 © DeNA Co., Ltd. 概念抽出の作成 29

30.

概念抽出の作成 4 ● 入力ユーザーストーリー ○ ● 出力 ○ © DeNA Co., Ltd. 用語集 30

31.

4 概念抽出の作成テンプレート: ● プロンプト ○ ○ テンプレートに従ってわかんないことは人に聞いて # 用語集 ## [プロジェクト識別名] プロジェクトで使用される用語の定義集 ### [ドメイン識別名] #### [日本語名] ○ 検索で辿り着ける形式知はいらないよ ○ ファイルに出力して - 英語名: [英語名] - 略語: [略語1(省略可能)] - 説明: [説明] #### [日本語名] - 英語名: [英語名] - 説明: [説明] © DeNA Co., Ltd. 31

32.

用語集の例: 4 概念抽出の作成 ## 企業データ連携プロジェクトで使用される用語の定義集 ### 企業・マスターデータ関連 ● 出力: 用語集 ○ ドメインに関連すること ○ システムに関連すること ○ エンジニア用語まで ■ 「論理削除」とか #### 企業 - 英語名: company - 説明: 弊社システムから取得される企業情報を表すエンティティ。企業マスターデータの基本単位となる #### 企業名(カナ) - 英語名: name_kana - 説明: 企業の正式名称のカナ表記 … ### システム・データ連携関連 #### 弊社システム - 英語名: internal_system - 説明: 企業情報の唯一のデータソースとして機能する上流システム … © DeNA Co., Ltd. 32

33.

34.

35.

[beta]

テンプレート:

5

ドメインモデルの作成

● プロンプト

© DeNA Co., Ltd.

○

純粋にドメインモデルのみ
定義して

○

テンプレート(サンプル)に
従って

○

制約とか、わかんないことは
人に聞いて

○

mermaidでファイルに
出力して

# サンプル
```mermaid
classDiagram
%% 学校：教育機関全体を表す。複数のクラスを持つ。
class School {
%% 学校名：学校の正式名称
%% 制約: 必須、100文字まで
+String name
}
%% 学級：学校に所属し、複数の生徒が在籍する単位。いわゆる「クラ
ス」。
%% 予約語と紛らわしいため `SchoolClass` としている
class SchoolClass {
%% 学級名：年度や組を含む名称（例：「2025年度 1年A組」）
%% 制約: 必須、50文字まで
+String name
}
%% 学校は、複数のクラスで構成される（Composition）
%% 学校が廃校になれば、クラスも存在しなくなる強い関係。
School "1" *-- "*" SchoolClass : 構成される
```
35

36.

37.

ドメインモデルの例: 5 ドメインモデルの作成 ● 出力: ドメインモデル ○ ○ sampleに従って制約や説明含めて記述 mermaidなので人も認識しやすい！ ```mermaid classDiagram %% 企業：企業データ連携における中心的なエンティティ。弊社システムから取得される企業情報を表す。 class Company { %% 企業ID：企業を一意に識別するための識別子 %% 制約: 必須、弊社システムが管理する主キー +String company_id %% 企業コード：企業ごとにdescにおいて一意に採番している文字列 %% 制約: 必須、5文字まで、英数字とアンダースコア +String company_code %% 企業名（カナ）：企業名のカタカナ表記 %% 制約: 必須、1000文字まで、全角カタカナと長音記号のみ +String name_kana %% 従業員数：企業の従業員数 %% 制約: 必須、0以上999999以下の整数 +Integer num_employees ... } ``` © DeNA Co., Ltd. 37

38.

39.

40.

41.

42.

43.

44.

45.

1 目的の達成と現在地 ● 実装前の「共有知化」を達成 ○ ◎: 目的であった一定の質の共通認識が形成できた → 生成物をまずリポジトリに含めて良いかのレビュー体制により仕様の認識齟齬が減少 ○ © DeNA Co., Ltd. △: 資料に落とし込めない暗黙知は依然存在している 45

46.

1 目的の達成と現在地 ● 実装前の「共有知化」を達成 ○ ◎: 目的であった一定の質の共通認識が形成できた → 生成物をまずリポジトリに含めて良いかのレビュー体制により仕様の認識齟齬が減少 © DeNA Co., Ltd. ○ △: 資料に落とし込めない暗黙知は依然存在している ○ △: 長期的にこのプロセスで管理可能かは、まだ評価できない 46

47.

48.

49.

50.

51.

https://engineering.dena.com/team/kencom/

52.