前回の業務分解を、要件の言葉に翻訳する
前回のM-04では、今の業務を担当者・入力情報・手順・判断・出力・例外・引き継ぎの7要素に分解しました。今回は、その分解結果を、これから作るシステムの要件の言葉へ翻訳します。特に「手順」と「判断」の部分が、機能要件の材料になります。業務を分解しただけでは、まだ設計には渡せません。この講義で、そのまま設計へ渡せる形に整えていきます。ここが上流工程の中心です。
このスライドのポイント
- 前回（M-04）: 現行業務を7要素（担当者・入力情報・手順・判断・出力・例外・引き継ぎ）に分解した
- 今回: その分解結果を、これから作るシステムの「要件の言葉」に翻訳する
- 特に「手順」と「判断」が、機能要件の材料になる
機能要件とは何か
機能要件とは、システムが何をできるかを表す要件のことです。書き方には型があります。入力として何を受けて、どんな条件のときに、結果として何が起きるか。この3点を書いて、初めて機能要件になります。たとえば「経費を管理できる」という言い方は、一見すると要件のように見えますが、入力も条件も結果も含んでいません。3点に分解して、初めて作れる要件に変わります。この型を覚えることが、この講義の核です。
このスライドのポイント
- 機能要件＝システムが「何をできるか」を表す要件
- 記述の型: 入力（何を受けて）・条件（どんな条件で）・結果（何が起きるか）
- 「管理できる」「見える化する」は、3点に分解して初めて要件になる
曖昧な要件は、AIの解釈で機能が決まる
機能要件を曖昧なまま渡すと、何が起きるでしょうか。AIは、その曖昧さを自分の解釈で埋めて機能を組み立てます。「経費を管理できる」とだけ渡せば、登録のことか、一覧のことか、承認まで含むのかを、AIが勝手に決めてしまいます。これはA-06で学んだ「曖昧な仕様による誤り」が、コードを書く前の上流の段階で起きている状態です。だからこそ、前回の業務分解が効いてきます。分解結果は、この3点を埋めるための材料そのものだからです。
このスライドのポイント
- 曖昧な要件を渡すと、AIの解釈で機能が勝手に決まる
- 「経費を管理できる」→登録か・一覧か・承認まで含むかをAIが判断してしまう
- A-06の「曖昧な仕様による誤り」が、コードを書く前の段階で起きている
曖昧要件を3点へ分解する
曖昧な要件を要件へ変える手順を見ます。「経費を管理できる」という一言は、まず具体的な動作へ割り開きます。登録できる、一覧できる、承認できる、差し戻せる、というように分けます。ここまでで、いくつの機能が必要かが見えてきます。そのうえで、分けた動作の一つひとつに、入力・条件・結果を書き入れます。大きな一言のままでは決して埋まらなかった3点が、動作へ分解すると自然に埋まっていきます。この二段構えが分解のコツです。
このスライドのポイント
- ビフォー: 「経費を管理できる」（1つの大きな言葉）
- アフター: 「登録できる」「一覧できる」「承認できる」「差し戻せる」へ割り開く
- 分けた動作の一つひとつに、入力・条件・結果を書き入れる
具体例:「承認できる」の3点記述
具体例として、経費精算アプリの「承認できる」を3点で書いてみます。入力は、承認ボタンが押されること。条件は、押した人が申請者の上長であり、かつ申請の状態が「申請中」であること。結果は、状態が「承認済み」へ変わり、申請者へ通知が届くことです。ここで使った「状態」という言葉は、H-06で学んだ状態の考え方と地続きです。そして、この一行はK-02で学んだ契約の一単位にも、そのままつながっていきます。
このスライドのポイント
- 入力: 承認ボタンの押下
- 条件: 承認者が申請者の上長で、状態が「申請中」
- 結果: 状態が「承認済み」へ変わり、申請者へ通知される
- ここで使う「状態」は、H-06で学んだ状態と地続き
技術サンプル: 機能要件3件の3点記述表
07は技術サンプルです。経費精算アプリの機能要件を3件、表にまとめました。登録できる、一覧できる、承認できるの3つを、それぞれ入力・条件・結果で書き分けています。読むときの要点は3つです。1つ目に、機能の名前ではなく動作が書かれていること。2つ目に、条件の欄に権限や状態が入っていること。3つ目に、この表の1行が、すでに学んだK-02の契約やH-03の画面遷移の一単位に対応していくことです。表の下の質問例を、要件をAIに点検してもらうときに使ってください。
このスライドのポイント
- 種別: table
- 目的: 機能要件を3件、入力・条件・結果で記述して並べて確認する
- サンプル本体: 下表
混同しやすい:「機能の名前」と「機能要件」
混同しやすいのが、機能の名前と機能要件の違いです。「承認機能」という言葉は、機能の名前にすぎません。何を受けて、どんな条件で、何が起きるのかが書かれていないからです。一方、「承認できる」を入力・条件・結果まで書いたものが、機能要件です。もし要件定義の資料が機能名の箇条書きで埋まっていたら、それはまだ要件になっていない、と気づいてください。名前の一覧は、作るべきものの目次にすぎず、そのままでは設計にもAIにも渡せません。
このスライドのポイント
- 機能の名前（例:「承認機能」）: 何を受けて何が起きるかが書かれていない
- 機能要件（例:「承認できる」＋入力・条件・結果）: そのまま作れる
- 名前だけの一覧は、要件ではなく「作るものの目次」
バイブコーディングでの確認点:「曖昧動詞の検出」
バイブコーディングでの確認点です。AIに機能要件の一覧を作らせたら、続けて「曖昧な動詞の検出」を頼んでください。分解が必要な言葉の筆頭は、管理する、対応する、連携する、見える化する、の4つです。これらは一見きちんとした要件に見えますが、中身が決まっていません。見つけたら、その場で入力・条件・結果へ分解します。AIへの質問はこう投げます。「この一覧の曖昧な動詞を挙げ、それぞれ入力・条件・結果に分解してください」。検出を習慣にすると、要件の穴が早く見つかります。
このスライドのポイント
- AIに要件一覧を作らせたら、続けて「曖昧動詞の検出」を依頼する
- 要分解ワードの筆頭: 管理・対応・連携・見える化
- 見つけたら、その場で入力・条件・結果へ分解する
- AIへの質問例: 「この一覧の曖昧な動詞を挙げ、それぞれ入力・条件・結果に分解してください」
まとめと次回
最後に一問一答です。機能要件を書くときの記述3点は何でしょうか。（間）答えは、入力・条件・結果です。30秒でまとめます。機能要件は、機能の名前ではなく、動作を入力・条件・結果の3点で書きます。管理や対応といった曖昧な動詞は、まだ分解が足りないという合図です。次回のM-06では、何をできるかではなく、どの品質で動くかを決める非機能要件を学びます。関連資料は「AIアプリ要件定義シート」と「要件定義プロンプト100」です。
このスライドのポイント
- 一問一答: 機能要件の記述3点は？→ 入力・条件・結果
- 30秒まとめ: 名前ではなく動作を、入力・条件・結果で書く。曖昧な動詞は分解の合図
- 次回: M-06 非機能要件（何をできるかではなく、どの品質で動くか）
- 関連資料: 「AIアプリ要件定義シート」「要件定義プロンプト100」
