🤖

「レビューお願いします」が怖くなくなる！ AIで設計書を“伝わるシナリオ”に翻訳する実践法

に公開
AI
要件定義
開発プロセス
プロンプトエンジニアリング
idea

「ウォーターフォール開発のレビュー、なんだかいつも一方通行だな…」
「顧客がITに詳しくなくて、設計書を読んでもらえているか不安…」

開発現場にいると、こんな悩みに一度はぶつかるのではないでしょうか。
完璧な設計書を書いたつもりでも、顧客の業務シーンとズレていて、後の工程で大規模な手戻りが発生…。考えただけで胃が痛くなりますよね。

本記事では、そんな開発上流工程の「認知負荷」と「すれ違い」を解決する、今日から使える実践的なテクニックをご紹介します。

テキストだけの難解な設計書を、AIを使って 「顧客が本当にチェックできる具体的なシナリオ」 にわずか5分で翻訳する方法です。理論は知っている、という方にこそ、改めて確認していただきたい内容です。

なぜ「翻訳」が必要か？ 設計書レビューのよくある“すれ違い”

従来の設計書レビューでは、人間側の思い込みや文章の曖昧さが、顧客の「分かったフリ」を引き出すことがあります。

  • 専門用語をスルーされる

    • 「二段階認証」「日次バッチ」などの言葉は正しくても、顧客がその重要性や影響範囲を具体的にイメージできず、本来すべき質問が見過ごされます。

  • 機能の羅列で、業務の流れが見えない

    • 個々の機能仕様は正しくても、「誰が、どの順番で、どんな状況で使うのか」という一連のストーリーがなければ、運用時の問題点に気づけません。

  • 「未記載」事項が誰にも気づかれない

    • 設計書に書かれていない「障害時の運用」や「イレギュラー対応」は、問題が起きて初めて発覚し、プロジェクトが炎上する原因になります。

これらのすれ違いを防ぐ鍵は、設計書を顧客の言葉で、具体的な業務シナリオに落とし込むことです。

“伝わるシナリオ”生成プロンプト3ステップ

ここからは、実際に設計書を翻訳していくための具体的な手順です。AIに問いかける際に、以下の3つのプロンプトを順番にコピペするだけでOKです。

Step 1: 顧客の言葉へ「正規化」する

まずは、設計書の専門用語をほぐし、誰が読んでも分かる言葉に変換させます。曖昧な点や未記載の項目をAIに洗い出させるのがポイントです。

プロンプト① 正規化

あなたは要件定義アナリストです。
以下の設計書を非エンジニアでも読める粒度に正規化してください。
曖昧/未記載は「⚠未記載」セクションにまとめ、根拠条を引用してください。

# 設計書
{設計書のテキスト}

▶︎ AI出力例：

  • 誰が使う：一般社員／上長／管理者
  • できること：出退勤打刻・修正申請・承認
  • 制約：オフライン不可／二段階認証は管理者のみ
  • ⚠未記載：障害時代替手段／バッチ失敗対応

この時点で、顧客は「自分たちが使うシステム」として具体的にイメージし始め、特に「未記載」部分から重要な質問が生まれます。

Step 2: 「ユーザー1日シナリオ」で業務を追体験する

次に、正規化された要件を元に、ユーザーの一日の動きを時系列でシミュレーションさせます。特に、問題が起きる「例外系」のシナリオを生成させることが重要です。

プロンプト② 1日シナリオ化

以下の観点で1日シナリオを作成してください：
- 時系列順（8:00-20:00を想定）
- 各アクションの前提条件と結果
- 想定される障害点（通信断、システム障害、ユーザーエラー）
- 代替フローの有無
最大8ステップ、各ステップに「時刻」「アクション」「結果」「次のステップ」を明記

▶︎ AI出力例（例外系）：

  1. 9:00 地下で電波なし → 打刻不可
  2. 復帰後ログイン → 現時刻で打刻
  3. 当日修正申請 → 上長承認 → 翌朝反映

このような具体的なシナリオを見ることで、顧客は「あ、うちの現場だと地下の倉庫に行くことがあるけど、その時はどうしよう？」といった、設計書だけでは気づけなかった課題を発見できます。

Step 3: 「Yes/Noチェックリスト」で論点を絞る

最後に、シナリオから見つかった論点を、顧客が「Yes/No」で直感的に答えられる質問リストに変換します。これにより、レビュー会議での議論が発散するのを防ぎます。

プロンプト③ チェックリスト生成

シナリオから発注元がYes/Noで回答できるチェックリストを生成。
各項目に「根拠条」と「重要度A/B/C」を付与し、以下のJSONスキーマで出力してください。
{
  "checklist": [
    {
      "q": "質問文",
      "evidence": "根拠条",
      "priority": "A|B|C"
    }
  ]
}

▶︎ AI出力例：

{
  "checklist": [
    {
      "q": "オフライン時の暫定打刻手段は定義済みか？",
      "evidence": "打刻=オンラインのみ",
      "priority": "A"
    },
    {
      "q": "バッチ失敗時の通知・再実行手順は定義済みか？",
      "evidence": "翌日9時反映",
      "priority": "A"
    }
  ]
}

「根拠条」があることでAIの回答を鵜呑みにせず、人間がファクトチェックできるのがポイントです。

運用に乗せるためのヒント ✅

AIからの回答をそのまま使わず、人間が最終的な品質を担保するための最低限のチェックです。

  • ✅ 機密情報は匿名化する
    • 顧客情報や社外秘の情報は、入力する前に必ず匿名化するか、セキュリティが担保されたエンタープライズ向けのLLMを利用しましょう。
  • ✅ 「根拠条」を必ず確認する
    • AIは時々「分かったフリ」をします。 チェックリストの「根拠条」が、元の設計書と一致しているか人間の目で必ず確認し、AIの誤読を防ぎましょう。
  • ✅ スプリントごとに更新する
    • この手法はアジャイル開発でも有効です。各スプリントの開始時に、最新の仕様を元にシナリオとチェックリストを更新することで、常に最新の認識をチームと顧客で共有できます。

まとめ

AIは非常に優秀なアシスタントですが、「万能な専門家」ではありません。その特性を理解し、賢く付き合うことが、これからの時代の開発者に求められるスキルです。

AIとの協働で「伝わる設計」を実現するために、以下の3つのポイントを意識してみてください。

  1. 失敗パターンを知る: 設計書がなぜ伝わらないのか、典型的なすれ違いパターンを頭に入れておく。
  2. プロンプトで予防線を張る: 「正規化」「シナリオ化」「チェックリスト化」という明確な指示で、AIの思考を適切に導く。
  3. 人間が最終チェックする: 「根拠条」を元に人間が監査することで、アウトプットの品質を担保する。

この3つの仕組みを実践することで、AIは単なる「文章生成ツール」から、顧客との対話を円滑にする信頼性の高い「思考パートナー」へと進化します。このプロンプトセットをコピーして、ぜひ今日のレビューから試してみてください。

Discussion