要件を決める

5-1要件とは何か

要件とは、「この仕組みで、何を、どこまで実現しなければならないか」を言葉にしたものです。家を建てるときの「4人家族が住める」「駅から徒歩15分以内」「予算は〇〇円まで」にあたります。設計図（どう作るか）は専門家が描きますが、要件（何が必要か）は住む人が決めなければ、誰も決められません。

業務の仕組みも同じです。システム部門やベンダーは作り方の専門家ですが、あなたの業務で何が困っていて、何ができれば成功なのかは知りません。要件を書くのは、業務を知っている人の仕事です。

5-2要件を構成する7つの要素

要件は、次の7つの要素で考えると漏れが少なくなります。

要素	答える問い	請求書処理の例
① 目的	なぜやるのか。何の困りごとを解決するのか	月末に集中する入力作業を減らし、支払いの遅れをなくす
② 成功の物差し	何がどうなったら成功か	1件あたりの処理時間を15分から5分に。支払い遅延を月3件から0件に
③ 対象範囲	どの業務の、どの部分が対象か	国内取引先からの請求書（月約800件）。受け取りから支払いデータ作成まで
④ やらないこと	今回は対象にしないことは何か	海外取引先の請求書、支払いの実行、取引先マスタの整備
⑤ 利用者と場面	誰が、いつ、どんな状況で使うか	経理担当4名が日中に。月末3営業日は1日150件を処理
⑥ 機能	仕組みが何をできなければならないか	請求書から取引先・金額・期日を読み取る。発注データと照合する。差異を一覧にする
⑦ 制約・前提	守らなければならない条件、変えられない事情	会計システムは現行のまま。電子取引の保存ルールを守る。予算は年〇〇円

この中で特に重要なのが、②成功の物差しと、④やらないことです。

成功の物差しを先に決める

物差しが決まっていないと、完成したものが成功なのかどうか、誰にも判断できません。物差しは、時間・正確さ・量・負担・お客様への影響のどれかで、できるだけ数字にします。そして、導入前の数字を測っておくことが欠かせません（第19章）。

やらないことを書く

「やらないこと」を書かないと、作っている途中で「ついでにこれも」と要望が増え続け、期限と予算を超えます。やらないことを書くのは、範囲を狭めるためではなく、今回やることに集中するためです。今回やらないことは、次の段階の候補として残しておけばよいのです。

5-3機能要件と非機能要件

⑥機能は、さらに2種類に分けて考えます。

• 機能要件：仕組みが何をするか。「請求書から金額を読み取る」「発注データと照合する」など
• 非機能要件：仕組みがどのくらいの水準で動くか。速さ、量、止まらなさ、安全性、費用など

業務担当者は機能要件には気づきやすい一方、非機能要件は書き漏らしがちです。しかし、使い物になるかどうかは非機能要件で決まることがよくあります。

非機能要件の観点	業務担当者が答えられる問い	例
速さ	結果がどのくらいで返ってくればよいか	1件の読み取り結果が30秒以内に表示される
量	いちばん多いとき、どのくらいの件数を処理するか	月末3営業日は1日150件、ピーク時は1時間に40件
止まらなさ	止まったら業務にどんな影響があるか。何時間なら待てるか	半日止まっても手作業で回せる。月末は2時間以上止まると支払いに影響
安全性	誰が見てよく、誰が変えてよいか	経理担当と経理課長のみが閲覧・修正できる
費用	導入と運用にいくらまでかけられるか	AIの利用料は1件あたり〇円以内、年間〇〇円以内
保存	何を、いつまで残す必要があるか	請求書の原本と処理の記録を、法令で定められた期間保存する

非機能要件の技術的な実現方法は作る側が考えますが、「どの水準が業務に必要か」は業務担当者にしか答えられません。特に「止まったら業務がどうなるか」は、必ず業務側から伝えてください（第12章で詳しく扱います）。

5-4AIを使う仕組みに特有の要件

AIを組み込む仕組みでは、従来のシステムにはなかった要件を決める必要があります。

要件	決めること	例
正確さの水準	どのくらい正しければ使えるか。どう測るか	取引先名と金額の読み取りで98%以上。過去の請求書200件の例題で測る
根拠の提示	AIが結果の根拠を示す必要があるか	照合で差異ありとした場合は、請求書と発注データの該当行を並べて示す
判断できないとき	AIが判断できない場合にどうするか	読み取れない項目は空欄にし、推測で埋めない。担当者に回す
渡してよい情報	AIにどの情報を渡してよいか	取引先名・金額は可。個人の口座番号は渡さない
人の確認	どこで誰が確かめるか	支払いデータ作成前に、経理担当が差異ありの全件と、差異なしの1割を確認する
記録	AIの入力・出力・確認結果をどう残すか	読み取り結果、確認者、修正内容を1年間残す
変更時の確かめ直し	AIやルールを変えたとき、何で確かめ直すか	AIの版や指示を変えたら、同じ例題200件で正確さを測り直す

「判断できないとき」の要件は特に重要です。何も決めないと、AIは読み取れない項目を推測で埋め、もっともらしい誤りを作ります。「分からないときは分からないと返す」ことを要件として明記しておきます。

5-5良い要件と、曖昧な要件

要件は、誰が読んでも同じ意味に受け取れることが大切です。曖昧な要件は、作る側が都合よく解釈できてしまいます。

曖昧な要件	何が問題か	書き直した要件
AIで請求書を自動処理する	どこまでが「自動」か分からない	請求書から取引先・金額・期日を読み取り、発注データと照合して、差異の有無を一覧にする。支払いの判断は担当者が行う
読み取りの精度を高くする	「高い」の基準がない	取引先名と金額の読み取り正確さが、例題200件で98%以上
使いやすい画面にする	人によって意味が違う	差異のある請求書が一覧の上に並び、1クリックで原本の画像と読み取り結果を並べて見られる
すぐに結果が出る	「すぐ」が何秒か分からない	1件の読み取り結果が30秒以内に表示される

書き直すときのコツは3つです。主語と範囲をはっきりさせる（誰が・どこまで）、形容詞を数字や条件に置き換える（高い→98%以上）、確かめ方が分かるようにする（例題200件で測る）。完成したときに「満たしているかどうか」を判定できる要件が、良い要件です。

5-6優先度を付ける

要件を書き出すと、たいてい予算や期限に収まらないほどの量になります。そこで、一つひとつに優先度を付けます。

• 必須：これがなければ使えない。目的が達成できない
• あるとよい：なくても使えるが、あれば効果が上がる
• 今回はやらない：次の段階で検討する（④やらないこと に移す）

判断に迷ったら、「これがなかったら、成功の物差しを達成できないか」と問います。達成できるなら、それは必須ではありません。必須の要件だけで最初の版を作り、使いながら「あるとよい」を足していくほうが、早く確実に効果が出ます（第19章）。

5-7要件メモを1枚にまとめる

ここまでの内容を、1枚のメモにまとめます。分厚い要件定義書でなくても、この1枚があるだけで、システム部門やベンダーとの会話の質が大きく変わります（第18章）。