見出し画像

【通算088|要求AI 05】検証結果を4つの視点で評価する——Kiroが書いたのは「システムの視点」だけだった

前回の検証で、Kiroは曖昧な一文から8要件の要求仕様を生成した。

今日はその結果を、宣言どおり「要求を可視化する4つの視点」で評価する。


要求を可視化する4つの視点


評価の結果

  • 目標 × — なぜ作るのか、成功の基準、作らない範囲——一切問われず、書かれず

  • 人間 △ — 申請者・承認者・管理者の3役割を発明したが、実在の組織は不明のまま

  • システム ◎ — 8要件・5状態・検証ルール・EARS記法。教科書的に厚い

  • データ △ — 用語集9語は事実上のミニデータモデル。だが属性も保存要件も浅い

順に見ていく。

目標の視点——ゼロ回答。 生成された仕様書の冒頭には「申請状況の可視化と承認プロセスの効率化を実現します」とある。もっともらしいが、これはKiroの作文であって、私の目標ではない。年間いくらの工数を減らしたいのか。監査対応が動機なのか。目標を聞く質問は一度もなかった。

人間の視点——役割が追加された。 申請者・承認者・管理者という3つの役割が定義され、「自分の申請は自分で承認できない」というルールまで付いた。だが、承認者は上長なのか経理なのか。代理承認は。誰がどの申請を割り当てるのか。実在する組織の形は、何も反映されていない。

システムの視点——詳細に定義された。 提出→承認→差し戻し→再提出の流れ、5つの状態、入力検証、履歴、権限。定型文(EARS記法)による受入基準。分析機能が出してきた唯一の質問も「金額の上限チェックは要るか?」というシステムの質問だった。

 「金額の上限」までは来たのに「金額で承認者が変わるか」という業務の質問には届かない

データの視点——あるが「下書き」?。 用語集に9つの用語と5つの状態が定義された、これは事実上の簡易データモデルだ。だが費目の体系も、証憝の保存要件もない。そして「下書き」状態が定義されているのに下書き保存の要件がない、という矛盾がある。

公平に言えば、指示が雑だったのだから当然ではある

ここでフェアに認めておきたい。私が渡したのは「経費申請を承認できるようにしたい」という、わざと雑にした一文だった。雑な指示から雑な仕様が出てくるのは、当然といえば当然だ。

確認したかったのは、雑な指示からKiroがどこまでの要件を導いてくれるか、あるいは足りない部分を聞いてくるかだった。結果は見てのとおり——導いてくれたのはシステムの視点の「一般解」まで。目標・人間・データについては、聞いてこなかった。そこまでには至らなかった、というのが今回の結果である。

改善案:指示そのものを「4つの視点」で構造化する

雑な一文を渡して質問を待つのではなく、最初の指示を4つの視点の形に構造化して渡せば、より良い結果が得られるのではないか——それが今回の評価から導いた仮説だ。

  • 目標 — どんな目的で作るのか(例:承認の滞留を減らす、監査に耐える記録を残す)

  • 人間 — 誰が使うのか(申請者・上長・経理。代理承認はあるか)

  • システム — どんな流れ・ルールで動くのか(金額による承認者の分岐など)

  • データ — 必要なデータ、保存すべきデータは何か(費目、証憝、履歴の保存期間)

次回は、この4つの視点それぞれで仕様を決めてからKiroに渡し、指示の構造化で生成される要件定義(書)がどう変わるかを検証する。引き続きKiroで検証を続け、出てきた結果を再度4つの視点で評価する——同じものさしで測るから、改善の度合いが数えられるはずだ。

今日のまとめ

  • 4視点評価の結果:目標×/人間△/システム◎/データ△

  • ただし渡した指示が雑だったのだから、当然といえば当然。雑な指示から導ける範囲は「システムの一般解」までだった

  • 改善案:最初の指示を4つの視点で構造化して渡せば、より良い結果が得られるのではないか

  • 次回、4視点で仕様を決めてからKiroに渡して検証する。結果は再び4視点で評価する

#AIエージェント #Kiro #AWS #要件定義 #スペック駆動開発 #要求仕様 #システム開発 #SE #生成AI #50代

いいなと思ったら応援しよう!