AIの登場で品質をどう語りますか？ 〜 要件定義・設計編 〜

言うまでもなく、システム開発において「品質」は非常に重要です。でも、みなさん。「品質が大事」という一言で終わっていないでしょうか？本当に大切なのは、開発のどのタイミングで、何の品質を、どう担保するのか。
そして、それを継続的かつ円滑に回していくための「プロセス」だと考えています。

これまで、システムの品質をつくり、確認し、守るのは基本的に「人」の役割でした。

しかし、AIの登場によって、その考え方にも大きな変化が生まれています。人が担ってきた品質管理をAIに置き換える、という単純な話ではありません。これまでの「人による品質担保」に、「AIによる品質担保」という新しい選択肢が加わった。と捉えています。

AIによる品質については、実装やコードレビューなど、下流工程での活用が数多く語られています。
この記事ではそこだけではなく、要件定義や設計といった上流工程も含め、開発プロセス全体の中でAIが品質にどう関われるのかを考えていきたいと思います。

要件定義の品質：主体は顧客とPM
設計の品質：エンジニアのバイブル
品質の指標に関して
まとめ

要件定義の品質：主体は顧客とPM

本フェーズのアウトプットは、システム導入後の業務運用の定義(業務フロー)と、機能要件・非機能要件の定義(要件定義書)です。本アウトプットを前提で話します。

要件定義は顧客との共同作業

要件定義のアウトプットは、顧客へのヒアリングに加え、既存の業務手順書や現行システム、現場の運用実態を確認し、PMの経験や社内に蓄積されたノウハウを組み合わせて作成します。顧客の要望を出発点に、その背景にある課題や制約を整理し、開発と検証ができる具体的な条件へ落とし込んでいく作業です。

要件定義での瑕疵混入と、取り除く作業

ここで混入する瑕疵としては、「欠落」「重複」「不明確」「誤認」が考えられます。これらを排除することが、品質を確保するうえで最も重要なプロセスであり、その一端を担うのがレビューと是正処置です。瑕疵は各工程で混入するものであり、後工程で表出することを避けるため、是正処置によって解消します。指摘数・是正処置数が、品質を測る指標となりますが、混入事由を明確にすることも、今後の瑕疵の混入を防ぐ手がかりになると考えます。

今までであれば、こんな感じの話で終わっていたかと思いますが、AIの登場によりAIがレビューするという流れになってきています。

要件定義フェーズでAIが出来ること

単にAIにレビューさせることは可能です。レビュー対象の文章を提示すれば、「重複」や「不明確」な記述は指摘できると考えます。しかし、「欠落」や「誤認」はどうでしょうか。書かれていないことや、顧客自身が勘違いしていることまで指摘できるのでしょうか。

私は可能だと考えます。過去に成功した要件定義や、レビューの指摘事項、是正内容、瑕疵の混入事由などを与え、ベンチマークとして比較することで、AIでも欠落や誤認の可能性を指摘できると考えます。比較する情報が大量になった場合にも、AIの処理能力を活かせるのではないでしょうか。
補足：完全にAIにより取り除けるという意味ではなく、確認すべき問いを増やしてくれると考えている。

弊社では、AIによるレビューを想定し、顧客から形式について強い要望がない限り、要件定義書をMarkdown形式で作成しています。コードとともに管理でき、変更履歴や差分も確認しやすくなるためです。

設計の品質：エンジニアのバイブル

本フェーズのでのアウトプットは、案件の内容にもよるが、基本設計書、画面仕様書、API仕様書、データベース仕様書、シーケンス仕様書等である。本アウトプットを前提で話します。

設計はシステムに具現化するための設計図

設計は、まさしく設計書を作り、それを見たらシステムを組めるというところまで落とし込んだものになります。設計がろくにできていない状態で、実装に回すってことは、その後の出来は全て実装するエンジニアのセンスに委ねるということになります。それでは、会社としての品質は保てません。。

弊社では、AIに実装をさせることを視野に、AIが見ても一定のアウトプットが出せるようなところまで落とし込み、設計書を作成します。

設計での瑕疵混入と、取り除く作業とその限界

設計段階で混入する瑕疵には、要件定義と同様に「欠落」「重複」「不明確」「誤認」が考えられます。

「欠落」は、要件定義に記載された要件が設計に反映されていないことです。「重複」は、同じ責務や処理が複数箇所に不要に設計されていることです。例えば、同じ目的・機能を持つAPIを重複して設ける場合が該当します。「不明確」は、処理の条件や期待される結果などが十分に定義されず、設計内容を一意に解釈できないことです。期待値が１つに定まらないという状況もあります。「誤認」は、要件の読み違いや技術的な理解・判断の誤りによって、要件を満たさない設計となることです。

これらの瑕疵は、要件定義と同様に、レビューによって検出し、是正します。また、原因に応じて再発防止のための是正処置を講じます。

ただし、要件定義から設計へと工程が移る際には、特有の問題が生じます。要件定義は顧客とPMが中心となって進め、設計はエンジニアが担うなど、工程間で担当や責任が分かれていることが多いためです。
このような体制で特に懸念されるのが、「誤認」という瑕疵です。設計者が要件の背景や意図を読み違えていても、技術者だけのレビューでは、設計としての整合性や技術的な妥当性に目が向き、その読み違いを見逃す可能性があります。

一方、PMや顧客が設計レビューに参加すれば解決するとも限りません。要件の背景や意図を理解していても、技術的な設計内容を読み解き、適切に問題を指摘できるとは限らないためです。
このように、要件を理解する人と設計を理解する人の間には知識の隔たりがあり、従来のレビューだけで誤認を取り除くには一定の限界があります。

要件と設計の隔たりを埋めるAI

その限界を乗り越える可能性を開くのがAIです。AIは、要件定義と設計の両方を参照し、業務上の要求と技術的な実現方法を照らし合わせることができます。人の役割分担によって生じる知識の隔たりを補い、工程をまたいだ確認ができるのです。

また、人のレビューでは、読み落としや「理解しているつもり」によって、要件の解釈間違いを見逃すことがあります。AIにも読み落としや誤解はありますが、人とは別の視点で照合することで、見過ごされていた不整合を発見できる可能性があります。

この観点から、要件定義書と設計書を個別にレビューするだけでなく、AIによって両者を一体としてレビューすることには大きな意味があります。各文書の中だけでは見つけにくい、要件から設計への抜け漏れや解釈のずれを確認できるためです。

品質の指標に関して

要件定義・設計では、指摘数と是正数を基本に、瑕疵の重大度や混入事由を併せて確認します。ただし、件数だけでは品質の良し悪しは判断できません。

最も重視するのは、後工程への流出です。実装やテスト、運用で見つかった問題のうち、要件定義・設計に起因するものがどれだけあり、どの程度の影響を与えたかを確認します。これは、各工程のレビューと是正が有効に機能したかを振り返る重要な指標です。

流出した瑕疵について、混入した原因と見逃した理由を整理し、人とAI双方のレビュー観点に反映することで、次の品質改善につなげます。

指摘数・是正数に加え、瑕疵の重大度や混入事由、特に後工程への流出を重視し、AIを活用して数値化・重み付けすることも考えられます。過去の成果物や指摘・是正記録を基に、共通の評価基準を設けることで、品質を一定の尺度で評価できる可能性があります。

プロジェクトの規模や特性の違いも考慮すれば、各プロジェクトを横断して品質の傾向や改善状況を把握する指標として活用できるのではないでしょうか。

まとめ

ここで紹介するのは、あくまで現時点での一つの考え方です。
AIの台頭により、システム開発におけるAIの役割や関わり方は、今後さらに大きく変化していくかもしれません。
その前提で、一つの解釈として捉えていただければと思います。

まずは、各工程における「人」と「AI」の品質への関わり方を、ざっと表にまとめてみます。

フェーズ	アウトプット	対応	担保する内容	指標
要件定義（顧客・PM）	業務フロー、要件定義書（機能要件・非機能要件）	顧客との共同確認、レビューと修正・是正処置。 AIによる過去の要件定義や指摘・是正事例との比較	顧客の業務・課題・制約が反映され、開発と検証ができる具体的な条件として定義されていること	瑕疵の種類別の指摘数、修正完了数・未解決数、是正処置の実施状況
設計（エンジニア）	基本設計書画面仕様書 API仕様書データベース仕様書シーケンス仕様書など	技術的なレビューと修正・是正処置。 AIによる要件定義書と設計書の横断的な照合	要件が設計に正しく反映され、人やAIが実装できる具体性と、期待する動作が一意に定まる明確さを備えていること	瑕疵の種類別の指摘数、修正完了数・未解決数、要件の設計反映率、是正処置の実施状況