はじめに
開発業務をしていると、こんな経験はないでしょうか。
- 上層部から仕様が降りてきたが、なぜその仕様になったのか分からない
- 他のエンジニアが決定した仕様について、技術的な判断理由が分からない
- 過去に決定した仕様を変更しようとしたが、当時の経緯が分からない
- 仕様の背景を知るために、当時の担当者へ確認する必要がある
- 会議に参加していないメンバーに、決定事項だけが共有されている
これらに共通するのは、「何を決めたか」は残っていても、「なぜそう決めたか」が残っていないという問題です。
今回は、この問題をAIによって改善できないかと考え、会議の音声データを起点に、意思決定の背景を記録し、要件定義・設計・開発タスクまでつなげるワークフローを紹介します。
※本記事はワークフローの提案です。実際の導入による工数削減や品質改善の効果を検証したものではありません。
1. 現状の課題：仕様は残るが、背景が残らない
① 上層部の意思決定の背景が分からない
例えば、非エンジニアの上層部から次のような依頼があったとします。
ログイン中のユーザーだけを一覧表示する機能を追加してほしい。
要求自体は理解できます。
しかし、次のような疑問が残ります。
- なぜログイン中のユーザーだけなのか？
- どのような課題を解決したいのか？
- どのような効果を期待しているのか？
- 他の方法では実現できないのか？
これらの背景が共有されていなければ、エンジニアは提示された仕様を実装することはできても、より適切な代替案を提案することが難しくなります。
② エンジニア間でも判断理由が共有されない
この問題は、上層部とエンジニアの間だけではありません。
エンジニア同士でも発生します。
例えば、次のような仕様が決定されたとします。
ユーザー一覧の更新間隔は30秒とする。
仕様書には「30秒間隔で更新する」と記載されていても、その理由が残っていないことがあります。
実際には、以下のような理由があったかもしれません。
- DBへの負荷を抑えるため
- リアルタイム性より安定性を優先したため
- 既存システムの制約があったため
- 開発工数を考慮したため
こうした判断理由が共有されていないと、後から仕様を変更する際に、当時の制約を見落としてしまう可能性があります。
③ 時間が経つほど情報が失われる
仕様を決定した当時は、担当者が背景を理解していたとしても、時間が経過すると状況が変わります。
- 担当者の異動や退職
- 別メンバーへの引き継ぎ
- 過去の仕様変更
- 当時の議論内容の忘却
その結果、既存仕様の理由を調べ直す必要が生じます。
仕様書は残っているのに、なぜその仕様になったのかを誰も説明できない。
この状態を改善する必要があると考えています。
2. 解決したいこと：意思決定の背景を資産として残す
今回の目的は、単に議事録を自動作成することではありません。
仕様と一緒に、意思決定の背景や判断理由を記録し、後から誰でも確認できる状態にすることです。
例えば、従来の仕様書では次のように記載されていたとします。
従来の記録
| 項目 | 内容 |
|---|---|
| 機能 | ログイン中ユーザー一覧 |
| 仕様 | ログイン中のユーザーのみ表示する |
| 更新間隔 | 30秒 |
これを、以下のような形式で残せると理想的です。
目指したい記録
| 項目 | 内容 |
|---|---|
| 要求 | ログイン中のユーザーを一覧表示する |
| 目的 | 現在利用可能なユーザーを探しやすくする |
| 背景 | 非ログインユーザーが一覧に混在している |
| 決定事項 | ログイン中のユーザーのみ表示する |
| 更新間隔 | 30秒 |
| 更新間隔の決定理由 | DBへのアクセス負荷を考慮したため |
| 検討した代替案 | リアルタイム更新 |
| 技術的制約 | DB負荷と更新頻度のバランス |
| 未確認事項 | ログイン状態の判定基準 |
※上記は説明用の架空の例です。
こうした記録が残っていれば、仕様を変更するときにも、当時の判断材料を参考にできます。
また、エンジニアが仕様を理解する際にも、単なる実装内容だけではなく、要求の目的から考えられるようになります。
3. 提案：会議音声×AIによる開発ワークフロー
そこで考えたのが、会議音声とAIを組み合わせたワークフローです。
使用するツールの候補としては、以下を想定しています。
- Plaudなどの録音・文字起こしツール：会議の音声を記録する
- AI要約ツール：会議内容から決定事項や判断理由を抽出する
- Claude Code：抽出した情報をもとに要件定義や設計を支援する
- RedmineやGitなど：決定事項、設計書、開発タスクを管理する
ワークフローの全体像
【会議・ヒアリング】
|
v
【① 音声録音】
Plaudなど
|
v
【② 文字起こし・AI分析】
・要求
・目的、背景
・決定事項
・判断理由
・却下された案
・技術的制約
・未決事項
|
v
【③ 人間による内容確認】
・認識違いの修正
・情報の補足
・決定事項の承認
|
+----------------------+
| |
v v
【④ 意思決定の記録】 【⑤ Claude Code】
・議事録 ・要件定義書
・判断理由 ・DB設計
・制約事項 ・API設計
・関連資料 ・画面設計
| ・タスク分割
| |
+-----------+----------+
|
v
【⑥ レビュー・承認】
|
v
【⑦ 開発・実装】
この仕組みによって、会議で決めた内容を、その背景とともに開発工程へ引き継ぐことを目指します。
4. 具体的な活用イメージ
STEP 1：会議を録音する
まず、要件定義や仕様検討の会議を録音します。
対象となるのは、例えば以下のような会議です。
- 上層部との仕様検討
- エンジニア間の技術検討
- システム設計の打ち合わせ
- 仕様変更に関する会議
- 障害対応後の振り返り
ここでは、できるだけ会話内容をそのまま記録します。
なお、実際の業務で録音する際は、参加者の同意や社内規定に従う必要があります。
STEP 2：AIで意思決定の情報を抽出する
録音データを文字起こしし、AIに内容を整理させます。
一般的な議事録では、決定事項や次のアクションが中心になりがちです。
今回はそれに加えて、なぜその結論になったのかを重点的に抽出します。
例えば、以下のようなプロンプトを使用します。
以下は仕様検討会議の文字起こしです。
会議内容から、次の情報を整理してください。
1. 要求・要望
2. 要求が発生した背景
3. 解決したい課題
4. 決定事項
5. 各決定事項の判断理由
6. 検討した代替案
7. 代替案を採用しなかった理由
8. 技術的制約
9. 未決事項・確認事項
10. 次に必要なアクション
【重要】
・文字起こしに存在しない情報は推測で補完しない
・不明な項目は「不明」と記載する
・決定事項と提案段階の内容を区別する
・判断理由は、根拠となる発言も併記する
・発言の時刻がある場合は参照時刻を記載する
・矛盾している内容は確認事項として抽出する
このように指示することで、単なる要約ではなく、意思決定の記録として利用しやすい形式に整理できます。
STEP 3：人間が決定内容を確認する
ここは重要な工程です。
AIは会議内容を整理できますが、必ずしも正確に理解できるとは限りません。
例えば、会議中の「30秒更新でもいいかもしれない」という発言を、AIが決定事項として扱ってしまう可能性があります。
そのため、次の内容を確認します。
- 決定事項が正しいか
- 判断理由に誤りがないか
- 検討中の案が決定事項になっていないか
- 重要な制約が抜けていないか
- AIが事実を推測で補っていないか
AIが作成した情報を、そのまま確定仕様として扱わないことが重要です。
STEP 4：Claude Codeで要件定義・設計につなげる
確認済みの情報をClaude Codeへ渡します。
既存システムの構成やコードも参照できる環境であれば、会議内容と実際のシステムを照らし合わせながら、設計の初稿を作成できます。
例えば、次のように指示します。
以下の会議記録をもとに、
既存システムを考慮した設計案を作成してください。
【作成対象】
1. 要件定義書
2. 機能要件・非機能要件
3. API設計
4. DB設計
5. 画面設計
6. 開発タスク一覧
7. テスト観点
【重要】
・決定事項とAIによる設計提案を区別する
・会議で確認されていない仕様を確定しない
・既存の設計や実装方針を尊重する
・技術的制約と判断理由を設計書に反映する
・不足している情報は確認事項として列挙する
・設計判断の根拠となった会議記録を示す
これにより、会議内容を設計へ反映する際の転記や整理の負担を減らせる可能性があります。
また、AIが既存システムとの矛盾や、追加で確認すべき事項を洗い出す用途にも活用できます。
5. 期待できる2つのメリット
メリット①：ドキュメント作成と開発準備の時間短縮
従来の開発フローでは、会議終了後に次のような作業が発生します。
- 会議内容を思い出す
- 議事録を整理する
- 決定事項を要件定義書へ反映する
- 設計書を作成する
- 開発タスクに分割する
これらの工程をAIで支援することにより、人間が行っていた情報整理やドキュメント作成の作業を削減できると考えています。
ただし、AIによる初稿生成が速くても、レビューや修正に時間がかかる可能性はあります。
そのため、実際に導入する際には、ドキュメントの生成時間だけではなく、確認・修正を含む総作業時間で効果を評価する必要があります。
メリット②：意思決定の背景をチーム全体で共有できる
個人的には、こちらが最も大きなメリットだと考えています。
会議で決定された仕様だけでなく、その背景も共有できれば、次のような効果が期待できます。
上層部とエンジニアの間
上層部が何を実現したいのか、どのような課題を解決したいのかを把握しやすくなります。
その結果、エンジニアは要求された仕様を実装するだけでなく、目的に合った代替案を提案しやすくなります。
エンジニア間
技術的な判断理由や制約を共有できます。
例えば、DB負荷を理由に更新間隔を30秒にしたのであれば、後から別メンバーが仕様を変更する際にも、その理由を確認できます。
将来の保守・仕様変更
当時の判断理由が残っていれば、現在もその制約が存在するのかを確認できます。
これにより、過去の仕様を無条件に踏襲するのではなく、現在の状況に合わせて再検討しやすくなります。
6. 導入時に考慮すべきこと
便利な仕組みですが、いくつか注意点もあります。
| 課題 | 対策 |
|---|---|
| AIが発言内容を誤認識する | 元の文字起こしや録音と照合する |
| 発言していない理由をAIが補完する | 不明事項は不明として扱う |
| 提案と決定が混在する | 決定・提案・保留を分類する |
| 会議中に背景が語られない | 理由や目的を質問する運用を取り入れる |
| 機密情報が外部に送信される | 社内ポリシーと利用サービスのデータ取り扱いを確認する |
| 生成した設計が正しいとは限らない | エンジニアがレビュー・承認する |
| 記録が増えて検索しにくくなる | チケットや設計書と関連付けて管理する |
また、すべての会議を録音・分析する必要はないと考えています。
まずは、仕様決定や技術的な判断が発生する会議に限定して試す方が、導入しやすいでしょう。
重要なのは、AIだけで完結させないこと
AIは、会議中に語られた内容を整理することはできます。
しかし、会議で説明されなかった判断理由を、正確に復元することはできません。
そのため、会議の進め方自体も重要になります。
例えば、仕様を決める際に次の3点を確認するだけでも、記録の質は変わるはずです。
- なぜその仕様が必要なのか？
- なぜその方法を選んだのか？
- 他の選択肢を採用しなかった理由は何か？
AIの活用と合わせて、こうした確認を習慣化することが必要だと考えています。
7. まずは小さく検証してみる
いきなり会議から設計・実装までを自動化するのではなく、段階的に検証するのが現実的です。
| 段階 | 検証内容 | 確認すること |
|---|---|---|
| Phase 1 | 会議音声から意思決定を抽出 | 決定事項や背景を正しく抽出できるか |
| Phase 2 | 決定事項をRedmineなどに記録 | 後から必要な情報を探せるか |
| Phase 3 | Claude Codeで設計書の初稿を生成 | 既存システムや制約を反映できるか |
| Phase 4 | 設計から開発タスクを生成 | タスクの粒度や依存関係が適切か |
| Phase 5 | プロトタイプ生成まで拡張 | 実装準備の工数を削減できるか |
まずはPhase 1とPhase 2だけでも、十分に価値があると考えています。
効果を確認する際には、例えば次の指標が使えます。
- 議事録・決定記録の作成にかかった時間
- AIが抽出した決定事項の正確性
- 判断理由が記録されている割合
- 仕様の背景を確認するために発生した問い合わせ件数
- 設計書の作成からレビュー完了までの時間
こうした指標で比較すれば、導入による効果を客観的に評価できます。
まとめ
今回提案したのは、会議音声を起点に、AIを使って意思決定の背景を記録し、要件定義や設計につなげるワークフローです。
期待する効果は、大きく2つあります。
① ドキュメント作成や開発準備の効率化
会議内容の整理、要件定義書・設計書の初稿作成、タスク分割などをAIで支援することで、手作業を削減する。
② 意思決定の背景・意図の可視化と共有
上層部の要求の背景や、エンジニアが行った技術的判断の理由を記録し、他のメンバーや将来の担当者が参照できるようにする。
AIを活用する目的は、単に設計書を速く作ることではありません。
「何を作るのか」だけでなく、「なぜそれを作るのか」「なぜその設計を選んだのか」を、チーム全員が理解できる状態にすることです。
仕様という結論だけでなく、そこに至る意思決定の過程まで残す。
そうすることで、エンジニアがより適切な設計や提案を行える環境につながるのではないかと考えています。