利益:
- AI サポートにより、曖昧なビジネス リクエストを明確でテスト可能なソフトウェア要件とユーザー ストーリーに変換する機能
- AI を使用して、システム設計、データ モデル、アーキテクチャ上の決定の長所と短所を構造化された方法で比較する能力
- AI の提案された設計を要件、拡張性、制約に照らして批判的に検証する能力
ソフトウェア プロジェクトの大部分はコードが悪いためではなく、要件の誤解が原因で失敗します。 「ユーザーにレポートをダウンロードさせてください」のような 1 文のリクエストでは、何十もの未回答の質問が残ります。どの形式ですか?担当者は誰ですか?レコードは何件ありますか?遅い場合はどうなりますか?要件分析 (ビジネス要求を明確でテスト可能な技術的ニーズに変換する) とソフトウェア設計 (これらのニーズを満たすために紙の上で構造を構築する) は、コードを記述する前に最もコストのかかるミスを防止する段階です。この単元では、この段階で AI を「思考パートナー」として使用する方法を学習します。これは、不確実性を解き明かし、選択肢を整理しますが、最終的な決定はユーザーに任せるパートナーです。
ここでAIは2つの大きな価値を生み出します。まず、スキップした質問が尋ねられます。これにより、リクエスト内の隠れた仮定や特殊なケースが表面化します。 2 番目に、設計上の決定の長所と短所を簡単に表にまとめます。しかし、そこが危険です。AI は、コンテキスト (予算、チーム、既存のシステム、法的制約) を完全に理解することなく、「ベスト プラクティス」として一般的な推奨事項を提供します。このアドバイスをあなた自身の真実に照らしてフィルタリングするのはあなたの仕事です。
コンセプト: ユーザーストーリー: 「... として、... できるようになりたいです。なぜなら...」という形式でニーズを表現する短い文。受け入れ基準: ジョブが「完了」したとみなされるために満たさなければならないテスト可能な条件。非機能要件: 速度、セキュリティ、スケーラビリティなど、「何をするか」ではなく「どのように動作するか」に関連する要件。
曖昧な要求からテスト可能な要求へ
優れた要件は測定可能で検証可能です。 「システムを高速化する」のではなく、「検索結果が 500 ミリ秒以内に返されるようにする」のです。 AI を使用して不確実性を絞り込む方法を段階的に説明します。
- リクエストをそのまま渡して質問を生成します。 AIに解決策を求めるのではなく、まず「このリクエストで不明な点を質問として列挙してください」とします。
- あなたが答えを与えます。コンテキストを知っているのはあなただけです。実際のビジネス上の制約を踏まえて AI の質問に答えます。
- それをユーザーストーリーと受け入れ基準に変換します。明確化されたニーズをテスト可能な項目に変換します。
- エッジケースとネガティブなシナリオを追加します。 「空の結果」、「不正なユーザー」、「大きすぎるファイル」など。
あいまいさの抽出プロンプト: 「次のビジネス リクエストをソフトウェア要件に変換します。まだ解決策は提案しないでください。まず、このリクエストで回答されていないすべてのあいまいさと隠れた前提を質問のリストとして抽出します。質問を次の見出しの下にグループ化します: 範囲、ユーザー/権限、データ ボリューム、パフォーマンス、エラー条件、セキュリティ。リクエスト: 「ユーザーが注文履歴をレポートとしてダウンロードできるようにする。」
ユーザー ストーリー + 受け入れ基準プロンプト: 「次の明確化されたニーズを、INVEST 原則に準拠するユーザー ストーリーに分割します。各ストーリーに 3 ～ 5 個のテスト可能な受け入れ基準を (Given-When-Then 形式で) 書きます。少なくとも 2 つのネガティブ シナリオ (不正アクセス、空のデータ) を追加します。ニーズ: [ここに明確なニーズを書き込みます]」
設計上の決定を AI と比較する
デザインは常にトレードオフの関係にあります。スピードと柔軟性、シンプルさとスケーラビリティ? AI はこれらのトレードオフを簡単なスプレッドシートにまとめます。たとえば、「通知の送信」機能の場合、同期 (リクエスト時に送信) アプローチを使用するか、非同期 (キュー、バックグラウンドで送信) アプローチを使用するかを議論できます。
設計比較プロンプト: 「「ユーザーに電子メール通知を送信する」機能を設計しています。(A) HTTP リクエスト中の同期配信、(B) メッセージ キューに入れてバックグラウンドで非同期配信の 2 つのアプローチを比較します。ユーザーの待ち時間、フォールト トレランス、複雑さ、インフラストラクチャのコスト、デバッグの難しさの軸で表を作成します。どのような場合に最終的にどちらを選択するかを 2 文で要約してください。作成しないでください。私にとっての決断です。」
軸
同期送信
非同期（キュー）
ユーザーの待ち時間
長い間（出荷待ち）
ショート（すぐに戻ります）
フォールトトレランス
低 (送信が爆発するとリクエストも爆発する)
高(リトライ可能)
複雑さ
低い
中～高 (キュー インフラストラクチャ)
インフラコスト
低い
追加のコンポーネントが必要
どこに当てはまるか
少量、簡単なアプリケーション
大量の重要な配信
ヒント: AI に「私に代わって決定を下すのではなく、選択肢と条件を示すだけです」と指示すると、考えるよう強制され、提案を盲目的に受け入れるリスクが軽減されます。最良のデザイン決定は、コンテキストを知っている人 (あなた) によって下されるものです。
弱いプロンプト / 強いプロンプト
弱点: 「注文システムのデータベースを設計する。」 (結果: どの規模、どの関係性、どの制約が明確でないか、一般的で非現実的なスキーム。) 強い: 「小規模な電子商取引用のデータ モデルの草案を提案します。エンティティ: 顧客、注文、製品、注文品目。制約: 注文には多くの製品が含まれる可能性があります。製品の価格は時間の経過とともに変化する可能性がありますが、現在の価格は過去の注文で保持される必要があります。1 日あたり最大 500 件の注文が予想されます。関係とその理由」を決定したことを説明してください。価格履歴の問題をどのように解決したかを指定してください。コードではなく、エンティティとフィールドのリストとして指定してください。」
強力なプロンプトの違い。規模 (1 日あたり 500 件の注文)、ビジネス ルール (過去の価格を維持する必要がある)、および希望の出力形式。 「過去の価格は維持しなければなりません」のような一文でデザインは完全に変わります。これを指定しない場合、AI は不正確ではあるものの、一見もっともらしい図を生成します。
ミニケース
ケース 1 — 隠れた仮定。チームは「ユーザーがプロフィール写真をアップロードできる」リクエストを直接コード化します。別のチームはAIに不確実性について「最大サイズ?許可されている形式?不適切なコンテンツ管理?古い写真を削除?」と質問した。のような8つの質問が生成されます。最初のチームは、サーバーが 20 MB のファイルでいっぱいになったときに、本番環境で問題が発生していることを知りました。 2 番目のチームは設計でそれを解決します。
ケース 2 — スケールの仮定が正しくありません。 AI は、レポート機能用の複雑なキャッシュ レイヤーを提案します。実際のデータは 1 日あたり 30 件のレポートしかないことをエンジニアが指摘すると、AI が提案を簡素化します。スケールを指定しないと、不必要に複雑になるというコストがかかります。を指定すると、2 週間の不要な作業が節約されます。
ケース 3 — 許容基準のギャップ。 「支払いが失敗したらどうなるの？」質問がなかったので、支払いが失敗した場合でも、注文システムは注文を「確認済み」としてマークします。 AI によって生成された否定的なシナリオのリストは、このギャップを捉えています。 1 行の受け入れ基準により、リアルマネーの損失を防ぎます。
よくある間違い
- リクエストをコードに直接渡します。曖昧さが解決される前に書かれたコードは、間違った問題をすぐに解決してしまいます。
- AI の一般的な「ベスト プラクティス」を盲目的に採用する。コンテキスト (規模、予算、チーム) を指定しない場合、推奨事項は機能しません。
- 非機能要件をスキップします。速度、セキュリティ、スケールが指定されていない場合、設計は不完全になります。
- 幸せなシナリオを考えているだけです。空のデータ、権限のないユーザー、エラー状態などのネガティブなシナリオを設計に含める必要があります。
- AIに判断を委ねる。 AI は選択肢を生成します。どちらのトレードオフが自分のビジネスに適しているかを決定します。
要約すれば
要件の分析と設計は、最も安価なエラーが見つかる段階です。ここでは、AI が不確実性を明らかにする質問を生成し、ユーザー ストーリーと受け入れ基準を草案し、トレードオフをグラフで設計します。しかし、その背景を知っているのはあなただけです。規模、予算、チーム、法的制約に基づいて AI の推奨事項をフィルタリングし、最終的な決定を下すのはあなたの仕事です。 「私に決定を下すのではなく、選択肢を示してください」という規律は、より良い設計とより深い学習の両方につながります。
アプリケーションタスク
コンテキストから 1 文のジョブ リクエストを選択します。まず、あいまいさプロンプトを AI に適用し、実際の制約を使用して質問に答えます。次に、明確化されたニーズを少なくとも 2 つのユーザー ストーリーとそれぞれの 3 つの受け入れ基準に変換します。少なくとも 1 つのネガティブなシナリオを含めてください。最後に、設計上の決定事項（同期/非同期、テーブル構造など）の比較表を作成し、独自の決定事項を 2 文で記述します。
チェックリスト
- [ ] リクエストをコードに渡す前に、質問として曖昧な部分を削除しました。
- [ ] AI にコンテキスト (規模、権限、パフォーマンス、法的制約) を与えました。
- [ ] ユーザー ストーリーをテスト可能な受け入れ基準に分割しました。
- [ ] 少なくとも 1 つのダウンサイド/エッジ シナリオを追加しました。
- [ ] 設計上の決定をトレードオフ テーブルで評価しました。
- [ ] 最終的な決定は AI に任せず、自分の状況に基づいて決定しました。