人向けの要件定義を、AIに渡せる粒度まで割る方法

人向けに書かれた要件定義をそのままAIに渡すと、動くものは出ても意図とは違うものになります。手戻りは、人手だけの開発より大きくなります。仕様をAIに渡せる粒度まで割ることが、実装前に決めることの一つ目です。中身は三つあります。何が確定していれば渡してよいかの単位、渡す前に確定させる事項、割ったあとに残る責任の置き方です。

そのまま渡すと、何が起きるか

人向けの要件定義は、実装する人が行間を読むことを前提に書かれています。画面の細かい挙動や、想定していない入力への対応は、書かれていないことが多く、実装者の経験で補われます。AIには、この行間を読む前提が働きません。書かれていないことは、書かれていないとおりに実装されます。

結果として、動くものは出ますが、頼んだつもりのものとは違うことがあります。この差は、実装が終わってから気づくと、手戻りが大きくなります。

曖昧さが起きやすい場所

例外処理、入力値の検証条件、権限による表示の違いは、人向けの要件定義で書かれずに残りやすい部分です。実装者であれば、似た画面の慣習から推測して補うことがありますが、AIはその慣習を前提にしません。これらの場所を意識して先に書き出しておくことが、割る作業の中心になります。

仕様をAIに渡せる粒度まで割る三つ

確定させる単位を、どこで区切るか

一つの機能を丸ごと渡すのではなく、確認できる最小の塊まで分けます。目安は、その塊だけを見て「できた」「できていない」を判断できるかどうかです。大きな塊のまま渡すと、途中で前提が変わったときに、どこまで作り直すかが曖昧になります。

塊が大きすぎるときに起きること

大きな塊のまま渡すと、実装が半分ほど進んだ段階で前提の誤りに気づいても、どこから作り直すべきかの境界が分かりません。小さな塊に分けておくと、誤りが見つかった塊だけを作り直せます。

渡す前に確定させておく事項

画面に表示するもの、入力と出力の形式、例外が起きたときの扱いは、人の言葉で先に書きます。これらは実装者が行間を読んで補ってきた部分であり、AIに渡す前に書き出しておかないと、書かれていないとおりに実装されます。

ここで書く内容は、AIに渡してよい情報の範囲とは別の話です。渡してよい情報の線引きはこの案件でAIに何を渡してよいかで書いています。

入出力の形式を先に書く理由

入力の形式が決まっていないと、AIは受け取った値をどう扱うかを独自に補います。数値と文字列の区別、必須項目と任意項目の区別といった基本的な部分が、書き手の意図と違う形で実装されることがあります。細かく見えますが、この部分の食い違いが後工程の手戻りにつながりやすいため、先に書いておく価値があります。

割ったあとに残る責任

仕様を割っても、動いたものと意図の差がゼロになるとは限りません。差が見つかったとき、それが仕様の割り方の不足なのか、実装の誤りなのかを切り分ける必要があります。この切り分けを誰が担うかを、実装前に決めておきます。合格の物差しの決め方は何を確かめれば合格かで書いています。

切り分けの基準

渡した仕様に書かれていたことと違う動きをしていれば、実装の誤りです。渡した仕様に書かれていなかったことについて意図と違う動きをしていれば、仕様の割り方の不足です。この基準をあらかじめ共有しておくと、差が見つかったときに責任の押し付け合いにならずに済みます。

仕様を割ったあと、AIに何を渡すかを別に決める

仕様を割る作業と、AIに渡してよい情報を線引きする作業は、順番に行います。まず仕様を確定できる単位まで割り、そのうえで、その単位の中に顧客情報や未公開の事業計画が含まれていないかを確認します。含まれている場合は、その部分を別の扱いにするか、AIに渡す前に伏せる必要があります。この線引きの考え方はこの案件でAIに何を渡してよいかで書いています。

仕様の割り方が細かいほど、機密情報が混在している塊を見つけやすくなります。大きな塊のまま渡してしまうと、機密情報が仕様の中に埋もれたまま渡ってしまう危険があります。

要件定義全体の中での位置づけ

仕様を割る作業は、要件定義という大きな工程の中の一部です。AIを使うシステム開発の要件定義全体で何が変わるかはAIシステム開発の要件定義で、通常の外注と変わる三つで書いています。仕様の割り方に加えて、AIに渡してよい情報の範囲と、何を確かめれば合格かという三つを合わせて決めることで、要件定義の全体が整います。

開発を頼まなくても、ここだけ相談できる

仕様を割る単位の決め方、渡す前の確定事項の書き方だけでも相談できます。実装を当社が担当しない案件でも同じです。すでに要件定義書がある案件でも、割り直すところから相談できます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

人向けの要件定義を、そのままAIに渡してはいけないのですか

渡すことはできますが、動くものは出ても意図とは違うものになりがちです。書かれていない部分は、書かれていないとおりに実装されます。

仕様を割る単位は、どう決めればよいですか

その塊だけを見て「できた」「できていない」を判断できる最小の単位が目安です。大きな塊のまま渡すと、前提が変わったときの作り直しが大きくなります。

渡す前に確定させる事項とは、具体的に何ですか

画面に表示するもの、入力と出力の形式、例外が起きたときの扱いです。実装者が行間を読んで補ってきた部分を、人の言葉で先に書きます。

この方法は、エンジニア向けの仕様書の書き方と同じですか

違います。エンジニア向けの書き方は実装のしやすさを見ますが、ここで言う分割は発注側が渡す前に何を確定させるかという単位を扱います。

割ったあとに差が見つかったら、誰の責任ですか

仕様の割り方の不足か、実装の誤りかを切り分けます。この切り分けを誰が担うかを、実装前に決めておきます。

AIに渡してよい情報の範囲と、仕様の割り方は同じ話ですか

別の話です。仕様の割り方は渡す粒度の話で、情報の範囲は機密や権利の線引きの話です。両方を着手前に決めます。

開発を頼まなくても相談できますか

できます。仕様を割る単位の決め方、渡す前の確定事項の書き方だけをお受けしています。

雛形やチェックリストは公開していますか

この記事では出していません。何が決まっていないと止まるかまでを書いています。案件ごとに書き起こします。

曖昧さは、要件定義のどこに起きやすいですか

例外処理、入力値の検証条件、権限による表示の違いです。実装者の慣習で補われがちな部分ほど、AIに渡す前に書き出す価値があります。

塊を小さく分けすぎると、何か問題がありますか

分けすぎると、塊どうしの整合性を確認する手間が増えます。「できた」「できていない」を判断できる最小の単位を目安に、分けすぎない範囲で区切ります。

仕様を割る作業と、AIに渡してよい情報を線引きする作業は、どちらが先ですか

仕様を割る作業を先に行います。確定できる単位まで割ったうえで、その単位の中に機密情報が含まれていないかを確認する順番になります。

この記事の内容は、要件定義全体のうちどの部分に当たりますか

要件定義全体のうち、仕様の割り方だけを扱っています。AIに渡してよい情報の範囲や、何を確かめれば合格かは別の記事で書いています。三つを合わせて、要件定義の全体が整います。