【AI×設計書】AIで要件定義書・機能仕様書を書く｜プロンプト設計とレビューフローの実践

はじめに

チャットに「注文機能の要件定義書を書いて」とだけ頼むと、応答時間や画面項目まで埋めた文章を返すことがあります。確認しないまま実装の前提にすると、合意していない数値が仕様になります。

この記事では、要件定義書と機能仕様書を分ける依頼と、返ってきた文を人が見る手順を整理します。対象は、業務システムの機能を文章で残すエンジニアです。チャットの応答を作る側を、この記事ではモデルと呼びます。特定のチャット製品の画面操作は書きません。出力の見本は、記録した実出力ではなく、見る点を示す例です。

背景：要件定義書と機能仕様書

IPA の機能要件の合意形成ガイド 概要編（2010年）は、要件定義の目的を、業務でシステムを使う立場から望むシステム像の明確化だとしています。結果は要件定義書にまとめます。同じガイドは、外部設計を次の工程だと説明しています。要件定義の結果から、利用者や他システムとの接点と、機能の中身を明確にします。

この記事の機能仕様書は、1機能の入力、出力、判定、対象外を書く文書です。判定は、入力への結果を1通りに決める文です。空のクーポンコードは、割引なしで受け付けます。この文が判定の例です。画面一覧と帳票を、この記事の機能仕様書には書きません。ガイドの外部設計の成果物そのものでもありません。

個々の要求については、ISO/IEC/IEEE 29148:2018 の 5.2.5 から次の3点を見ます。節番号の詳細は Source に置きます。

見る点標準での呼び名この記事での見方
一義Unambiguous読み手が1つの解釈にできる
検証できるVerifiableできたかどうかを示せる。数値でも、はい／いいえでもよい
その階層に合うAppropriate要件定義に、実装の細部を書かない

5.2.5 には、必要であることや、一文に1つの内容であることも含まれます。この記事の確認は、上の3点に限っています。

同じ標準の 5.2.6 では、要求の集まりに未決の印が残ると、集まりとしての完全さは満たさない、とされています。未確認を残した下書きは、完成版ではありません。先に数値を作って穴を隠す文書より、穴が見える文書を先に出します。

依頼文：未確認を本文に移さない

材料が短いほど、モデルは空欄をそれらしい数値で埋めやすくなります。依頼では、決まっていることと、決まっていないことを見出しで分けます。

必須は「対象」へ書きます。やらないことは「対象外」へ書きます。必須でない要望は「希望」へ書きます。数値の穴は「未確認」へ書きます。

要件定義の依頼例は次のとおりです。

次の材料だけで、要件定義書の下書きを書いてください。

材料:
- ログイン済みの利用者が、注文の合計金額（円の整数）とクーポンコードを送る
- クーポンコードが空でも、注文を受け付ける。割引はしない
- 金額の計算式と、応答時間の目標は未確認
- クーポンの残回数は、必須でない要望

見出しは「目的」「利用者」「対象」「対象外」「希望」「未確認」だけにしてください。
対象には、今回行うことを書いてください。
対象外には、今回やらないことを書いてください。
希望には、必須でない要望を書いてください。
未確認には、数値や項目が決まっていない行を書いてください。
未確認の数値、画面項目、テーブル名は書かないでください。
空欄を埋める例が必要なら、本文ではなく「未確認」に書いてください。

戻ってきてほしい形の見本は、次のとおりです。

目的: ログイン済みの利用者が、注文を送れるようにする。
利用者: ログイン済みの利用者。
対象: 合計金額（円の整数）とクーポンコードを受け取る。空のクーポンコードは、割引なしで受け付ける。
対象外: ゲストの注文。
希望: クーポンの残回数を、あとから確認できるとよい。
未確認: 金額の計算式。応答時間の目標。

機能仕様は、この見本のうち確定した行だけを入力にします。ログイン済みは利用者の条件として残します。希望と未確認は、仕様の本文へ移しません。

次の要件定義のうち、確定している行だけを機能仕様にしてください。

確定:
- 利用者はログイン済みである
- 入力は合計金額（円の整数）とクーポンコード
- 空のクーポンコードは、割引なしで受け付ける

未確認:
- 金額の計算式
- 応答時間の目標

希望（本文へ移さない）:
- クーポンの残回数

見出しは「入力」「出力」「判定」「対象外」「未確認」です。
判定には、入力への結果が1通りに決まる文を書いてください。
未確認の行と希望の行は、仕様の本文へ移さないでください。
画面一覧、帳票、テーブル定義、フレームワーク名は書かないでください。

機能仕様の見本は、次のとおりです。

入力: ログイン済みの利用者に限る。合計金額は円の整数。クーポンコードは空を許す。
出力: 受け付けたかどうか。
判定: 空のクーポンコードは、割引なしで受け付ける。
対象外: ゲストの注文。金額の計算。
未確認: 応答時間の目標。希望の残回数。

29148 の 5.2.4 では、拘束力のある要求の例に shall、希望の例に should が使われています。shall は必須を指します。should を、要求そのものとは扱いません。日本語の下書きでは、英単語へ機械的に置き換えません。同節の注記は、アジャイルで shall を使わないユーザーストーリーもあり得る、としています。見出しで必須と未確認を分けるやり方は、shall の有無に依存しません。

失敗例：1つの依頼で両方を書かせる

失敗しやすい依頼は次のとおりです。

注文機能の要件定義書と機能仕様書を、実装できる粒度で書いて。

材料無しの依頼で混ざりやすい形は、次のとおりです。これは記録した実出力ではなく、見る点を示す例です。

目的: 注文を保存する。
性能: API の応答は 200ms 以内とする。
画面: 合計、消費税、クーポン割引額を表示する。
データ: orders.total は decimal とする。

ずれは4つです。

  • 200ms は、渡した材料に無い
  • 消費税と割引額も、材料に無い
  • decimal は実装の選択である。機能仕様へは移さず、未確認へ戻す
  • 要件と機能仕様が、1つの塊になっている

「実装できる粒度」という一句が、未確認の穴を埋める指示になっています。性能や画面項目が必要なら、人が数値と項目を材料へ足してから、もう一度依頼します。未確認へ書かれた数値は、人が材料へ書くまで確定へ移しません。

レビュー：材料に無い行を戻す

モデルの出力を、そのまま次の工程へ渡しません。見る順は次のとおりです。

  1. 材料に無い数値と項目に線を引く。未確認の中の数値も、人が材料へ書き足すまでは確定へ移さない。引いた行は「未確認」へ戻す
  2. 1つの文を、2つの意味に読めるときは文を分ける。秒数と基準が無い「すばやく保存する」は、この例に当たる
  3. 実装の型、フレームワーク名、テーブル名は、機能仕様へ移さない。未確認へ戻す。機能仕様へ移せるのは、入力、出力、判定の文だけである
  4. 「未確認」が空のとき、その版を確定候補にする。確定候補は、使う側へ未確認が残っていないことを見せる版である。未確認が残るときは一覧のまま渡し、確定候補と呼ばない

「すばやく保存する」は、測れる条件が無く、はい／いいえの結果も無い文です。空のクーポンを割引なしで受け付ける文は、数値が無くても検証できます。

材料に載せないもの

接続先は、社内文書の接続先一覧を参照する、と書きます。URL そのものは書きません。顧客名と接続文字列も、チャットへは貼りません。

まとめ

  • 要件定義には、対象、対象外、希望、未確認を分ける。機能仕様には、確定した入力、出力、判定だけを書く
  • 依頼文で「未確認」を指定し、空欄を数値で埋めさせない
  • 材料に無い行は未確認へ戻す。未確認が残る一覧は、確定候補と呼ばない

次に試す手順は次のとおりです。

  1. 上の要件定義の依頼文を、自分の機能名に変えて送る
  2. 返ってきた「未確認」を読む。人が決められる行だけを材料へ足す。モデルの未確認に入った数値は、人が材料へ書くまで確定にしない
  3. 足した行を「確定」に移し、機能仕様の依頼文を送る
  4. レビューの 1 から 3 で線を引く。未確認が残るときは一覧のまま渡す。空なら確定候補として、使う側へ見せる

関連書籍

Amazonのアソシエイトとして、Thousand Tech Blog は適格販売により収入を得ています。紹介リンクであることの開示です。

まとめの手順は、この本を読まなくても試せます。試したあと、要求と仕様の書き分けを本で見たいときの1冊です。

見る範囲は第6章と第8章です。第6章は要求の書き方です。第8章は要求を仕様にすることです。第8章には、検証可能性、曖昧な表現、要求と仕様の混在、確定しない仕様の表現があります。書名は ［改訂第2版］要求を仕様化する技術・表現する技術（清水吉男 著、技術評論社、2010年）です。チャットへの依頼文は、この本の範囲外です。

Source

AIAI,LLM,プロンプト

Posted by 千原 耕司