業務要件から、最初に作る機能と後回しにする機能を分ける

原稿の管理表（13項目：記事ID・カテゴリ・要件ID・先に読むと理解しやすい記事・成果物パス・対象ツール・検証状況・最終更新日など）

管理項目	内容
記事ID	02-02
主な中カテゴリ	02-02 必要な機能と優先順位を決める
関連中カテゴリ	02-01、02-03、03-02、04-01
関連要件ID	REQ-001〜004
先に読むと理解しやすい記事	記事A（02-01、困り事を業務要件へ変える）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	業務要件を「最初に作る機能」「後で追加する機能」「今回は作らない機能」の3つに分け、理由と代替運用を添えた機能一覧を作れる
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/02-02-feature-scope_template.md、templates/02-02-feature-scope_example.md
出典	第11節参照
対象ツール・バージョン	特定ツールに依存しない。AIへの指示例は汎用の文章
検証状況	本文・ひな形・記入例はClaude Codeが作成。2026-09-20、ユーザーによる実読でPASS
残課題	第11節参照
最終更新日	2026-09-19（新規作成）。2026-09-21（Final Content Audit：読む順路の「本文は今後制作予定」（全項目に本文がある現在は誤り）を削除。本文は不変）

この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。

この記事は何の話か。作る機能の範囲を決める話です。記事Aで決めた業務要件を、そのまま全部いっぺんに作るのではなく、「最初に作る機能」「後で追加する機能」「今回は作らない機能」の3つに分けます。

なぜ必要か。要件をすべて同時に作ろうとすると、開発が長引き、判断も複雑になります。範囲を絞らずに始めると、「本当に必要な部分」が後回しになり、逆に「無くても困らない部分」に時間がかかることがあります。

この記事を読むとできるようになること。

• 業務要件を、機能の単位に分解できる
• 各機能を「最初に作る」「後で追加する」「今回は作らない」に分け、理由を書ける
• 今回作らない機能について、代わりにどう運用するかを説明できる

読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。

• 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「3区分の考え方」と「機能一覧の形」が分かり、ひな形を埋め始められます。
• 作って確かめる：上に加えて第5.3節（AIへの依頼）→第6節（失敗例と直し方）→第7節。
• 設計判断を深める：上に加えて第8節（優先順位の比較、外した機能の代替運路、適用限界）。

1. 今回の業務課題と完成するもの

この記事でやることは、記事A（02-01）で作った業務要件一覧を、「まず何を作るか」が決まった機能一覧に書き換えることです。

記事Aは、「困っている」という言葉を「誰が・どの条件で・何をできる／できない」という要件に変えました。しかし要件が決まっただけでは、まだ「何を作るか」は決まっていません。1つの要件を満たすのに複数のやり方があり、また複数の要件をまとめて1つの機能で満たせることもあります。さらに、要件には入っていない「あると便利そうな機能」（通知、添付ファイルなど）も、検討の途中で出てきます。

この記事を読み終えると、次のものが手元にできます。

• 依頼・承認業務に関わる機能の一覧
• 各機能を「最初に作る」「後で追加する」「今回は作らない」に分けた区分と理由
• 今回作らない機能について、当面どう運用するかの代替案
• 機能と要件IDの対応表

2. 前提知識と読む順路

この記事で使う言葉を先に説明します。言葉を覚える必要はありません。「何のことを言っているか」が分かれば十分です。

機能

一言でいうと、利用者が実際に行える1つの操作のまとまりです。

たとえば、「依頼を提出する」「依頼を承認する」が1つずつの機能です。

これがないと、要件（「割当承認者だけが承認できる」等の約束）はあっても、それを画面や処理としてどう実現するかが決まりません。1つの要件が複数の機能に関わることも、1つの機能が複数の要件を満たすこともあります。

システム開発では、要件を実現する具体的な操作の単位を機能（feature、フィーチャー）と呼びます。この記事では、記事Aの要件一覧を機能の単位に分解し直します。

最初に作る範囲（最小限の機能）

一言でいうと、それが無いと業務が回らない、必ず要る機能です。

たとえば、「依頼を作る」「提出する」「承認する」が無ければ、そもそも承認業務がアプリになりません。

これがないと、どこまで作れば最初のバージョンとして使えるのかが決まらず、開発がいつまでも終わりません。

システム開発では、これを最小限の機能（MVP、Minimum Viable Product）と呼びます。「最小」は「機能が少ない」という意味ではなく、「業務が回るために必要な、削れない部分」という意味です。

後で追加する機能（拡張候補）

一言でいうと、無くても最初の業務は回るが、将来必要になりそうな機能です。

たとえば、「提出済みの依頼を取り下げる」は、間違えて提出した場合に便利ですが、無くても「差戻してもらう」という代わりの操作で当面は運用できます。

これがないと、「今回作らない」機能と「将来作る可能性がある」機能の区別がつかなくなり、あとから「これは検討したのか、検討していないのか」が分からなくなります。

システム開発では、これを拡張候補・バックログ（backlog）と呼びます。この記事では、拡張候補にも関連要件ID相当の対応と代替運用を必ず書きます。

今回は作らない機能

一言でいうと、この初版の対象外だと決めた機能です。

たとえば、「代理承認」は、誰がいつ代理できるかという社内ルールが確認できていないため、初版では作りません。

これがないと、「なぜ作らなかったか」の理由が残らず、後から「検討漏れ」なのか「検討した上で外した」のか区別がつきません。

システム開発では、対象外にした理由と代替運用を明記することで、「決めていない」のではなく「決めて外した」ことを示します。

読む順路：業務要件から機能への分解の元になる考え方は記事Aの業務要件一覧です。方式（画面か自動化か等）の比較は03-02、画面の操作シナリオは04-01が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。

3. 理解する：全部を一度に作らない理由

3.1 「全部大事」は判断を先送りしているだけ

聞取りメモ（記事A）に出てきた依頼・承認・一覧・通知・添付といった機能の候補を並べると、どれも「あった方がよい」ように見えます。しかし「あった方がよい」を全部同時に作ろうとすると、次のことが起きます。

• 一番大事な「承認が正しく行われること」の確認が、機能全体の複雑さに埋もれる
• 「無くても困らない機能」に開発の時間が取られ、「無いと困る機能」が遅れる
• 途中で「これは本当に必要か」を聞き直す機会がないまま、全部が「決定事項」として進む

範囲を絞ることは、機能を減らすことではありません。「最初に確かめるべきこと」を先に確定させ、それ以外を「後で」「今回はしない」に分けて、判断を先送りにしないことです。

3.2 よくある誤解

「機能が多いほど良いアプリだ」。使われない機能は、確認する対象が増えるだけで、業務の困り事は解決しません。記事Aの要件（誰が・どの条件で・何ができるか）を満たす機能から先に作ります。

「後で追加すればいいので、今は全部作る」。全部を最初に作ると、どれが「本当に必要で今すぐ確かめるべきか」が分からなくなります。先に範囲を決めるのは、後から機能を足せなくするためではなく、最初に確かめる順番を決めるためです。

「作らない機能は要件から消してよい」。作らないと決めた機能も、理由と代替運転を記録に残します。消してしまうと、「検討した上で外した」のか「検討していない」のかが分からなくなります。

「AIに機能一覧を作らせれば範囲が決まる」。AIは機能の候補を出したり、記事Aの要件との対応を下書きしたりできますが、「どれを最初に作るか」「代替運用で業務が回るか」は、その業務に責任を持つ人が判断します（第5.3節）。

4. 判断すること

4.1 何を確認すればよいか

記事Aの要件一覧と対象外一覧（第5.4節・第7節）をもとに、次を確認します。

4.2 勝手に決めてはいけないこと

• どの機能を「最初に作る」に含めるかは、業務が実際に回るかどうかで決まります。開発のしやすさだけで決めません。
• 「今回は作らない」機能の代替運用（例：通知の代わりに一覧をこまめに見る）が、実際の業務で耐えられるかは、その業務の責任者が判断します。この記事では架空の判断として進めます。
• 記事Aの対象外一覧（代理承認・承認取消・取り下げ・通知・添付）に新しい項目を追加したり、逆に対象外から要件に戻したりしません。区分を付け直すだけです。

4.3 AIに任せる範囲

機能の洗い出し（記事Aの要件からの分解案）、要件IDとの対応の下書き、抜け漏れ候補の提示はAIに任せられます。しかし、どの機能を初版に入れるか、代替運用で業務上許容できるか、失敗した場合の影響を受け入れられるかは、人が決めます。

5. 作って確かめる：機能一覧を作る

5.1 準備

記事Aの成果物（業務要件一覧、対象外一覧）を用意します。この記事では、記事Aの記入例（ai_request_example.md・requirements_example.md）の内容をそのまま使います。

5.2 機能一覧（最初に作る・後で・今回はしない）

記事Aの要件と対象外一覧を、機能の単位に分解し、3区分に整理します。

5.3 AIに機能一覧の下書きを頼む

記事Aの要件一覧・対象外一覧をAIに渡し、機能への分解案と要件IDとの対応の下書きを作らせます。

記事Aの業務要件一覧（REQ-001〜005、007）と対象外一覧（代理承認・承認取消・取り下げ・通知・添付）を渡します。

依頼：
1. それぞれの要件・対象外の項目を、利用者が実際に行う操作（機能）の単位に分解してください。
2. 各機能について、対応する要件ID（対象外の項目は「—」）を示してください。
3. 「これも機能として洗い出した方がよいのでは」という抜け漏れ候補があれば、理由とともに提示してください（採用するかは人が判断します）。

してはいけないこと：
- どの機能を最初に作るか、後で作るか、作らないかを決めないでください（人が判断します）。
- 記事Aにない新しい要件や対象外の項目を作らないでください。

AIの下書きは、機能の分解案と要件IDの対応表の形で返ってきます。次の節で、この下書きを完成条件と照合します。

6. 初稿・失敗例・修正

6.1 説明用の失敗例（AIの初稿という設定）

AIへの依頼で「抜け漏れ候補を提示してください」と頼んだ結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。

• 「依頼の一括承認」機能を新規に追加（記事Aの要件にも対象外一覧にもない）
• 「代理承認」を「最初に作る」機能として分類（記事Aの対象外一覧に反する）
• 「一覧閲覧」の関連要件IDを空欄のまま提示

6.2 見つけ方と直し方

見つけ方は記事Aと同じです。AIの下書きを、記事Aの業務要件一覧・対象外一覧・第4節の確認事項と1項目ずつ照合します。

• 「依頼の一括承認」：記事Aの要件にも対象外一覧にもない新しい機能です。この記事では業務要件を機能に分解するだけで、新しい機能を発明しません。削除します。
• 「代理承認」の区分：記事Aの対象外一覧で対象外と決まっており、設計書5.3でも拡張候補（後で）とされています。「最初に作る」への分類は誤りです。「後で」に修正します。
• 「一覧閲覧」の関連要件ID：記事Aの要件一覧でREQ-002が対応しています。REQ-002を補います。

AIへの修正指示は次のとおりです。

指摘：
1. 「依頼の一括承認」は記事Aの要件にも対象外一覧にもありません。削除してください。
2. 「代理承認」は記事Aの対象外一覧にあり、最初に作る機能ではありません。「後で」に区分し直してください。
3. 「一覧閲覧」の関連要件IDが空欄です。記事A第5.4節を確認し、対応する要件IDを補ってください。

変えないこと：
- 記事Aの要件一覧・対象外一覧の内容そのものは変更しないでください。

6.3 修正後の機能一覧

修正後の機能一覧は、第5.2節の表のとおりです（新しい機能を追加せず、記事Aの要件・対象外一覧の範囲内で分類し直したもの）。

7. 確認結果

第5.2節の機能一覧を、完了条件と照合します。

残る制限：この機能一覧は架空ケースのものです。実際の業務に適用するときは、代替運用（差戻し依頼、共有フォルダのリンク等）が本当に業務として耐えられるかを、業務の責任者に確認する必要があります。この記事の本文と記入例はClaude Codeが作成したものです。非エンジニアの読者による実読は2026-09-20に実施しPASSしましたが、実際の業務担当者による内容確認（自分の職場への当てはめ）は行っていません。

8. 設計を判断する

8.1 優先順位の比較軸

「後で」に区分した3機能（取り下げ・承認取消・通知）について、業務への効果・実装の難しさ・失敗した場合の影響から比較します。

この比較から、次に着手するなら「通知メール」（効果が高く失敗の影響が低い）を先に検討し、「承認取消」は不変条件（記事A第8.2節）の設計が固まってからにする、という順序が考えられます。ただし、実際の着手順は業務の責任者が決めます。

8.2 外した機能の代替運用が業務上耐えられるか

代替運用は「システムで実現しない」というだけで、「業務ができなくなる」わけではありません。ただし、代替運用が実際に耐えられるかどうかは検証していません。たとえば「添付ファイルの代わりに共有フォルダのリンクを文字で書く」は、リンク切れやアクセス権限の管理が別途必要になります。この記事では、その運用が実際に回るかどうかまでは確かめていません。

8.3 適用限界

この記事の区分は、架空企業「みらい業務サービス」の小規模な業務支援アプリを前提にしています。利用者数が多い、法令上の記録保存義務がある、複数部署にまたがるといった場合は、「今回は作らない」とした機能（保存期間の管理等）を初版から検討する必要が出てくることがあります。

9. 持ち帰る成果物

自分の業務に使うときの手順は次のとおりです。

1. 前工程（02-01）の業務要件一覧・対象外一覧を用意する
2. 要件・対象外の項目を、機能の単位に分解する
3. 各機能を「最初に作る」「後で」「今回は作らない」に分け、理由を書く
4. 「後で」「今回は作らない」の機能には、代替運用を書く
5. 最初に作る機能が要件IDと対応しているか、未採用テーマが「今回は作らない」に入っているかを確認する

10. 次工程への受渡し

次へ渡すもの：機能一覧（最初に作る・後で・今回は作らないの区分と理由）、代替運用の一覧。

次工程での使われ方：03-02（作り方の候補を比較する）では、最初に作る機能をどう実装するかの方式比較の対象になります。04-01（利用者の操作と業務の流れを描く）では、最初に作る機能が操作シナリオの範囲になります。

前工程へ戻る条件：代替運用が業務として耐えられないと分かったら、区分をやり直すために02-02のこの表に戻ります。要件そのものに不足が見つかったら、02-01（記事A）に戻って要件を見直します。

11. 根拠と更新情報

• この記事の会社・人物・機能一覧はすべて架空の設定です。
• 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
• 機能の区分（最初に作る・後で・今回は作らない）と拡張候補（取り下げ・承認取消・代理承認）、未採用テーマ（管理者による緊急の業務変更、退職者データの詳細な保存期間）は、教材設計書AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.2・5.3節に基づきます。これは教材ケースの定義であり、実在企業の開発計画や外部の一般基準ではありません。
• 通知メール・添付ファイルの区分（後で／今回は作らない）は、記事A第7節（今回は作らないこと）の記入例の判断を引き継いだものです。
• 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。作成時点（2026-09-19）では人（ユーザー）による実読・内容確認は未実施でした。
• 2026-09-20：ユーザーによる実読でPASS。本文・要件・機能の区分・結論は変更していません。
• 未確認事項：業務担当者による内容確認（自分の職場への当てはめ）、代替運用（差戻し依頼、共有フォルダのリンク等）が実際の業務で耐えられるかは確認していません。「後で」の機能の着手順（第8.1節）は比較の一例であり、確定した計画ではありません。