AIシステム開発の要件定義で、通常の外注と変わる三つ

AIを使うシステム開発を外部に発注するとき、通常のシステム開発と同じ渡し方で要件定義をすると、動くものは出ても意図と違うものになりがちです。変わる点は三つあります。仕様の割り方、AIに渡してよい情報の範囲、何を確かめれば合格かです。この記事は発注側の目線で書きます。実装者向けの書き方の手順は扱いません。

通常の外注と変わる三つ

三つとも、実装が始まる前に決めることが条件です。実装が進んでからでは、実装に合わせた基準になります。

仕様の割り方が変わる理由

人向けの要件定義をそのままAIに渡すと、動くものは出ても意図とは違います。手戻りは、人手だけの開発より大きくなります。何が確定していれば、その塊をAIに渡してよいかを先に決めます。画面、入出力、例外の扱いを、人の言葉で先に書きます。

この分割は、エンジニアが読みやすい仕様書の書き方とは別の話です。発注側が、渡す前に何を確定させるかという分割の単位を持つことが目的です。分割の考え方そのものは人向けの要件定義を、AIに渡せる粒度まで割る方法で詳しく書いています。

行間を読む前提が働かない

人が実装するときは、書かれていない部分を経験で補います。画面の細かい挙動や、想定していない入力への対応がそれに当たります。AIにはこの前提が働きません。書かれていないことは、書かれていないとおりに実装されます。要件定義の段階で、この差を意識しておく必要があります。

入力の範囲を区切る理由

顧客情報や未公開の事業計画を、AIに渡してよい範囲を先に区切ります。区切らないまま進めると、機密が外部のAIサービスに渡ったあとで気づくことになります。この案件でAIに何を渡してよいかで書いた線引きが、ここに当たります。

通常の外注と違う理由

通常の外注では、実装者に渡す情報の範囲は契約と業務上の慣習で決まります。AIを使う開発では、実装者だけでなくAIサービス自体にも情報が渡ります。渡す先が一段増える分だけ、確認する範囲も広げる必要があります。

合格条件が変わる理由

AIが実装もテストも書くと、テストが実装の写し鏡になり、検証として成立しません。何を確かめれば出してよいかを、実装前に人が書きます。何を確かめれば合格かで詳しく書いています。

検収の物差しが変わる

通常の外注では、仕様どおりに動くかどうかで検収します。AIを使う開発では、仕様どおりに動くことに加えて、頼んだとおりに動くことまで確認する必要があります。この二つの違いは何を確かめれば合格かで書いています。契約の形にどう反映するかはAI開発の契約形態は請負か準委任かで扱っています。

要件定義書に書く前に、決めておくとよいこと

要件定義書を書き始める前に、この案件がどこまで仕様を固められる段階にあるかを見立てておくと、書く手間が減ります。仕様と合格条件がすでに固まっている段階であれば、要件定義書は確定事項の記録として書けます。まだ探索の要素が多い段階であれば、要件定義書よりも先に、どこまでを固め、どこからを進めながら決めるかという区切りを話し合っておく必要があります。

この見立てが、契約形態の選び方にもつながります。仕様が固まっている段階なら請負契約で仕様どおりの完成を約束できますが、探索の要素が多い段階では、成果物の完成を約束しない準委任契約のほうが実態に合います。契約形態を選ぶ考え方はAI開発の契約形態は請負か準委任かで書いています。

発注側が見落としやすい前提

通常の外注に慣れている発注側ほど、要件定義書さえ渡せば、あとは実装者の経験で細部が補われると考えがちです。この前提は、AIを使う開発では成立しません。実装者の経験に相当する「行間を読む力」を、AIは持っていないためです。見落としやすいのは、正常な操作だけを想定した要件定義書を渡し、異常な操作や想定外の入力への対応を実装側の裁量に任せてしまう進め方です。この部分をAIに任せると、想定していない挙動として実装されることがあります。

もう一つ見落としやすいのは、発注側の担当者が複数人いて、それぞれが実装者に口頭で補足を伝えている場合です。人が実装者であれば、複数の担当者から伝わった補足情報を、経験でまとめて整理してくれることがあります。AIに渡す情報は、口頭の補足も含めて、着手前に一つの文書へまとめておく必要があります。まとめずに進めると、担当者ごとに違う前提のまま実装が進み、後になって食い違いが表面化します。

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

仕様の割り方、入力の範囲の線引き、合格条件の設計だけでも相談できます。実装を当社が担当しない案件でも同じです。すでに要件定義書がある案件でも、AIに渡す前提で見直すところから相談できます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

AIを使うシステム開発の要件定義は、通常の外注と何が違いますか

仕様の割り方、AIに渡してよい情報の範囲、何を確かめれば合格かの三つが変わります。実装が始まる前に、この三つを決めます。

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

動くものは出ても意図とは違うものになります。手戻りが人手だけの開発より大きくなります。

仕様をAIに渡せる粒度まで割るとは、具体的に何をすることですか

何が確定していれば、その塊をAIに渡してよいかを決めることです。画面、入出力、例外の扱いを、人の言葉で先に書きます。

この記事は、エンジニア向けの仕様書の書き方を解説していますか

していません。発注側が渡す前に何を確定させるかという分割の単位を扱っています。実装者の書き方の手順は対象外です。

AIに渡してよい情報の範囲は、誰が決めるのですか

発注側です。顧客情報や未公開の事業計画をAIに渡してよいかどうかを、着手前に区切ります。

合格条件を実装前に決めるのはなぜですか

AIが実装とテストの両方を書くと、テストが実装の写し鏡になります。全部通っても、確かめたことにはなりません。

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

できます。仕様の割り方、入力の範囲の線引き、合格条件の設計だけをお受けしています。

AI開発は通常のシステム開発より費用が安くなりますか

書く時間は短くなりますが、決める時間と確かめる時間は増えます。安くなる前提では進めません。

すでに要件定義書がある場合、作り直す必要がありますか

作り直す必要はありません。既存の要件定義書を、AIに渡せる粒度まで割り直すところから始められます。

仕様がまだ固まっていない段階でも、要件定義書を書くべきですか

その段階では、要件定義書よりも先に、どこまでを固め、どこからを進めながら決めるかという区切りを話し合うことを勧めます。

要件定義の段階の見立てが、契約形態の選び方にどう関わりますか

仕様が固まっている段階なら請負契約が合い、探索の要素が多い段階なら準委任契約が合います。要件定義の見立てと契約形態の選び方は、地続きの判断です。

正常な操作だけを想定した要件定義書は、なぜ問題になりますか

異常な操作や想定外の入力への対応が、実装側の裁量に任されてしまうためです。人であれば経験で補いますが、AIは想定していない挙動として実装することがあります。