Geminiで要件定義を整理する手順：申請フロー電子化の要件を作る

結論

Geminiで要件定義を進める近道は、頭の中にある「こうあるべき」を書き起こすのではなく、ドライブにある申請様式とGmailに残った承認のやりとりを参照させ、今どう回っているかを先に再現させることです。そのうえで規程との差を出させ、曖昧な要望を確かめられる条件に書き直させます。初稿までは目安として1時間、素材がGoogleの中にそろっていればコピーの往復は要りません。どの例外を残すか、どこまでを今回の範囲にするかは、関係部署と決めます。

要件定義でGeminiに任せる範囲を先に決める

AIに要件を書かせると、一見整った文書が出ます。そこに社内の誰も同意していない決めごとが紛れ込むのが怖いところです。作業を分けてから始めます。

Geminiに任せる	人が判断する
現行の申請経路を、様式とメールから再現する	再現された経路が実態と合っているか
規程と実際の運用の食い違いを列挙する	食い違いのどちらに合わせるか
要望を、達成を確かめられる条件に書き直す	条件の数値と、そこに置く理由
必須と要望に分ける案を示す	予算と期限を踏まえた最終の線引き
抜けている観点を指摘する	指摘のうち今回の範囲に入れるもの

右の列は、社内の事情を知らないと動かせません。誰の承認を飛ばすと角が立つか、監査でどこを見られるか、来年の組織再編で部署がどう変わるか。Geminiはどれも知らないまま、もっともらしい案を出します。

この記事では、従業員250名ほどの企業で、備品購入と経費精算の申請を紙と押印からワークフローに移す場面を例にします。総務部の担当者が要件をまとめ、ベンダーに見積もりを頼むところまでを想定します。

素材がGoogleの中にあるなら、入口を使い分ける

同じGeminiでも、呼び出す場所で向いている作業が変わります。

入口	向いている作業
Geminiのアプリやウェブ画面	ドライブの様式とGmailのやりとりをまとめて読ませ、現行フローを再現する
Googleドキュメントの中のGemini	書き出した要件定義を章ごとに直す。規程の文書を開いて差分を確かめる
Gmailの中のGemini	長い承認の往復から、差し戻しの理由と経緯を拾う

プランや時期によって使える機能が異なるため、最新の仕様は公式情報で確認してください。会社のアカウントでは管理者が連携を止めていることもあります。その場合は様式のファイルをアップロードし、メールの本文を貼り付ければ、以降の手順はそのまま使えます。

具体例1：申請様式とメールから、今のフローを再現させる

要件定義の出発点は、理想のフロー図ではなく、今起きていることです。いきなり要件を書かせず、現状の再現だけを頼みます。

Googleドライブにある次の資料と、Gmailのやりとりを確認してください。
この段階では要件を書かないでください。

- ファイル名に「備品購入申請」を含む様式と記入例
- ファイル名に「経費精算」を含む様式
- 「購買管理規程」という名前のドキュメント
- 件名に「購入申請」または「精算」を含む、直近3か月のメール

確認したら、次を答えてください。

1. 読み込んだファイルの名前と最終更新日の一覧
2. 様式の各項目と、それが誰の入力を想定しているか
3. メールのやりとりから読み取れる、実際の申請から支払いまでの経路。
   誰から誰に渡り、どこで止まりやすいかを含めて時系列で書く
4. 差し戻しが発生したメールを抜き出し、その理由を分類する
5. 読み取れなかった箇所と、そこを埋めるために誰に聞くべきか

4番が、この仕事でいちばん効きます。差し戻しの理由は、そのまま新しい仕組みで防ぐべきことの一覧になります。金額の記入漏れ、承認者の指定間違い、証憑の添付忘れ。人の記憶から引き出そうとすると「たまにある」で終わりますが、メールから拾えば件数の多い順に並びます。

3番の再現は、必ず総務の担当者に見せて直してもらいます。メールに残らない経路が必ずあるからです。廊下で口頭で承認をもらう、部長が不在のとき課長が代理で押す。こうした運用はメールに痕跡が残らず、Geminiには見えません。

規程と実態の差を突き合わせる

現行フローが再現できたら、規程と照らします。電子化の要件定義で最初に決めるべきなのは、機能ではなく、どちらに合わせるかです。

先ほど再現した実際の運用と、「購買管理規程」に書かれた手続きを
突き合わせて、食い違いを一覧にしてください。

【出力の形】
表にしてください。列は次の5つです。
・項目
・規程での定め
・実際の運用
・食い違いが生じている理由として考えられること
・電子化するときに決めなければならないこと

【条件】
・規程の条文番号を必ず引用する
・理由の欄は推測になるため、推測であることを明記する
・どちらが正しいかの判断は書かないでください

最後の条件を入れる理由ははっきりしています。規程に合わせるのか、実態に合わせて規程を直すのかは、経営と監査に関わる判断です。総務の担当者でも一人では決められません。Geminiに「実態に合わせるべきです」と書かれた文書が出回ると、決めていないことが決まったように扱われます。

出てきた表は、そのまま次の打ち合わせの議題になります。たとえば「3万円未満は課長決裁」と規程にあるのに、実際は全件が部長まで上がっているとします。電子化のときに規程どおりに戻すのか、運用を追認するのか。ここを決めずに要件を書くと、承認経路の設定で手戻りします。

社内の規程そのものを見直す作業は、社内規程をAIで作成する方法で扱っています。

「承認を早くしたい」を、確かめられる文に直す

関係部署から出てくる要望は、そのままでは発注できません。達成したかどうかを判定できる文に書き直します。

ヒアリングで出た要望を、達成を判定できる要件の文に書き直してください。

【出た要望】
・承認が早くなるようにしたい
・どこで止まっているか分かるようにしたい
・紙に戻らないようにしたい
・経理の入力作業をなくしたい
・不正な申請ができないようにしたい

【書き直しのルール】
・1つの要望につき、厳しさの違う案を2つ出す
・「誰が」「いつ」「何をした状態」を含む文にする
・時間、件数、金額の数値は、私が伝えていない限り空欄にして「要確認」と書く
・その要望の裏側にある、本当に困っている状態を1行で推測して添える。推測だと明記する
・その要件が満たされたことを、稼働後にどのデータで確かめるかを1行書く

裏側の推測を添えさせると、要望の言葉をなぞるだけの要件を避けられます。「承認が早くなるように」の裏側には、だいたい別の困りごとがあります。備品が届かないと現場の作業が止まる、月末に精算が集中して経理が残業する。困っている状態が見えると、承認を速くする以外の解き方も見えます。申請の種類ごとに締切を分けるだけで解決することもあります。

数値の空欄は自分で埋めます。今の平均が何日で、何日になれば現場が困らないのかは、申請件数を数えて現場に聞いた人しか書けません。Geminiが埋めた数字を残したまま見積もりに出すと、過剰な性能を要求してしまいます。

必須と要望を分け、抜けを突かせる

条件の形になった要件は、この規模の案件でも40項目前後になります。全部は入りません。

整理した要件を、次の3段階に分けてください。

A：これがないと申請業務が回らない
B：あると楽になるが、運用でしのげる
C：稼働後の次の段階で検討する

【条件】
・分けた理由を、回らなくなる場面として1行で書く
・AとBのどちらとも言えるものは、分類せずに「判断が必要」として別に並べ、
  判断が分かれる理由を書く
・Aに入れた要件は、それを外したときに誰の作業が増えるかを一言添える
・私が答えていない前提がないと分けられないものは、質問として返す

判断が必要な欄に並んだものが、打ち合わせで話すべきことです。きれいに3つに分類されて返ってくると、議論する場所が消えてしまいます。

分類が固まったら、抜けを探させます。

ここまでの要件一覧を、次の3者の立場で読み直してください。

1. この案件に見積もりを出すワークフロー製品のベンダー
2. 当社の情報システム部門の担当者
3. 年に一度、経費の使い方を確認する監査の担当者

それぞれの立場から「これでは判断できない」「これが書かれていないと困る」
と感じる箇所を5点以内で挙げ、影響の大きい順に並べてください。

次の観点は、書かれているかどうかを必ず確認してください。
・承認者が不在のときの代理と、権限の委譲
・組織変更があったときの承認経路の作り直し
・申請と承認の記録をいつまで残すか
・既存の会計システムへのデータの受け渡し
・スマートフォンから申請と承認ができる必要があるか
・添付する証憑の形式と容量

監査の担当者を読み手に入れると、記録の保存と改ざん防止の要件が出てきます。業務部門が書く要件ではまず抜ける部分です。

具体例2：部署ごとの例外を、要件に落とし込む

申請フローの電子化がこじれるのは、ほぼ例外の扱いです。営業部だけ承認者が違う、工場は購買部を通す、役員は事後申請が認められている。

再現した現行フローと、Gmailのやりとりから、
部署や金額や申請の種類によって扱いが変わっている箇所をすべて抜き出してください。

【出力の形】
表にしてください。列は次のとおりです。
・例外の内容
・どの部署、金額、種類に当てはまるか
・その根拠がメールや規程のどこにあるか。根拠が見つからない場合は「不明」と書く
・その例外を新しい仕組みで設定として持たせる場合の難しさ

【条件】
・「不明」と書いた例外を最後にまとめて並べ、誰に確認すべきかを添えてください
・例外をなくすべきかどうかの意見は書かないでください

根拠が不明な例外こそ、確認に行くべきものです。誰も理由を説明できない例外が、いつの間にか続いていることがあります。理由が説明できなければ、この機会に揃える選択肢が出ます。説明できるなら、設定で持たせる必要があると分かります。どちらにせよ、ベンダーに聞かれる前に自分たちで把握しておくと、見積もりの精度が上がります。

例外が多いと分かった時点で、要件の書き方も変わります。ひとつひとつの例外を機能として並べるのではなく、「承認経路を、申請の種類と金額と部署の組み合わせで、情報システム部門が画面から設定できること」という一文にまとめるほうが、ベンダーには伝わります。

Googleドキュメントに書き出して、関係部署に回す

要件がそろったら、文書にします。Geminiの回答はGoogleドキュメントに書き出せるので、見出しと表を保ったまま新しい文書になります。ここからは共同作業です。

ここまでの内容を、ベンダーに渡す要件定義書の初稿としてまとめ、
Googleドキュメントに書き出してください。

【構成】
1. 電子化の目的と、達成したい状態
2. 対象とする申請の種類と、対象外にするもの
3. 関係部署と役割
4. 現行フローと、規程との食い違い
5. 機能要件 … 表にする。列は 番号 / 要件 / 分類 / 確かめ方 / 出どころ
6. 承認経路と権限の要件
7. 非機能要件 … 保存期間、記録、可用性、端末、保守
8. 既存システムとの連携
9. 決まっていないこと … 誰にいつまでに確認するかを併記する

【条件】
・私が伝えていない数値は書かず「要確認」と記す
・5章の出どころ欄には、規程の条文番号かメールの件名か、担当者の氏名を入れる

書き出した文書は、経理と情報システム部門に共有し、コメントで指摘をもらいます。紙やPDFで回すより、どの行に誰が何を言ったかが残るので、後から要件の変更理由をたどれます。

文書の体裁を整える段階では、ドキュメントの中からGeminiを呼び出して章ごとに直すと、初稿の他の部分を壊さずに済みます。整え方はGeminiで書式を整える手順にまとめています。

うまくいかないときの対処

古い様式や別案件のメールが混ざる。 ファイル名のあいまいな指定で起こります。読み込んだファイルの一覧を先に出させる手順を省かないでください。案件ごとにフォルダを分け、フォルダ名で指定すると減ります。

現行フローの再現が、規程をなぞっただけになる。 メールを参照できていないときの典型です。件名の指定を広げるか、代表的な申請1件のスレッドを直接指定して読ませ、そこから広げます。

要件が機能の名前の羅列になる。 「機能の名前を使わず、申請者と承認者と経理担当者の一日が電子化後にどう変わるかで書いてください」と、書く視点を指定し直します。

確認していない数値が残ったまま文書になる。 書き出す直前に「要確認」の扱いをもう一度指示します。書き出した後は、文書内で数字を検索し、自分の記録と照らします。

やりとりが長くなり、前半の条件が効かなくなる。 要件一覧をドキュメントに書き出して保存し、新しい会話でその文書を指定してやり直すほうが早く済みます。

例外が多すぎて要件がまとまらない。 すべてを要件にせず、「設定で対応する」「今回は対象外にする」「運用でしのぐ」の3つに振り分けてから書くと収まります。振り分けの案はGeminiに出させ、決めるのは関係部署との打ち合わせです。

ベンダーに出す前に確かめること

Geminiが出した要件定義書は、社内の誰も合意していない下書きです。順に確かめます。

現行フローの再現と例外の一覧を、総務と経理の担当者に見てもらいます。「ここに書かれていない回り方をしている申請はありませんか」と聞くのが、いちばん抜けが出ます。

承認経路と権限の要件を、決裁権限を持つ人に見てもらいます。誰がどこまで承認できるかは規程に紐づくため、勝手に変えられません。

保存期間、記録、既存の会計システムとの連携は、情報システム部門と経理に確認します。業務部門では判断できない制約がここに出ます。

入力する情報の扱いにも決まりがあります。申請メールには氏名、取引先名、金額が含まれます。これをGeminiに参照させてよいかは、自社の生成AI利用ルールによります。判断がつかないときは、情報システム部門に先に確認してください。

同じ作業を他のツールで進める手順は、ChatGPTで要件定義を整理する手順とCopilotで要件定義を整理する手順にまとめています。社内の文書がMicrosoftの製品に寄っているなら、後者が近道です。

まとめ

電子化したい申請を1種類だけ選び、その様式がドライブのどこにあるか、直近3か月の申請メールがGmailにどれだけ残っているかを確かめるところから始めてください。Geminiに読んだファイルの一覧を出させ、実際の経路を再現させ、規程との食い違いを表にします。その表を持って総務と経理に確認しに行けば、要件定義の骨格はその週のうちに立ちます。決まっていないことの一覧は、消し込む担当者と期限を入れて管理してください。