課題発見・企画学習記事全11節Design
「作らない」も選択肢に入れて、4つの案を比較し企画書にする
この記事で身につくこと運用変更、既存機能の活用、既製サービス、新規開発の4つの選択肢を説明し、「作らない」も正当な結論であることを言える。
記事内目次（24項目）
この記事の会社・人物・企画書はすべて架空の設定です。実在する会社や案件とは関係ありません。この記事の時点では要件（REQ-001〜）はまだ決まっていません。要件は記事A（02-01）で確定します。この記事で使うのは、01-03の目的から導いた「譲れそうな条件」の仮置きです（第3.3節）。第5.4節の指示文と第6節の初稿は説明用の例で、実際のAI出力を観測したものではありません。
この記事は何の話か。01-03で決めた目的をもとに、「運用ルールを変えるだけ」「今ある表計算を活用する」「既製のサービスを使う」「新しくアプリを作る」という4つの選択肢を比較し、企画書にまとめる話です。
なぜ必要か。新しいアプリを作ることを最初から前提にしてしまうと、実はもっと簡単な方法（運用ルールの見直しなど）で目的が達成できる場合を見落とし、不要な開発費用と手間をかけてしまいます。
この記事を読むとできるようになること。
- 運用変更、既存機能の活用、既製サービス、新規開発の4つの選択肢を説明し、「作らない」も正当な結論であることを言える
- 依頼・承認管理について、選択肢比較表を目的・費用・運用担当・変更しやすさで埋められる
- 比較結果から採用案・非採用理由・適用限界・残るリスクを企画書にまとめられる
- 「この時点で分かっていること」「仮置きしていること」「後工程で確定すること」を分け、未来の決定を既知のように書かない企画書にできる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（4つの選択肢と、この時点で分かっていること）→第4節（判断すること）→第5.2〜5.3節（比較表と企画書）→第9節。ここまでで「作らない」も含めた4案の比べ方と、企画書に何を仮置きと書くかが分かります。AIへの依頼は出てきません。
- 作って確かめる：上に加えて第5.4節（AIに下書きを頼む：渡す情報と指示文）→第6節（初稿に混ざる「結論の先取り」「未確認の数値」の見つけ方）→第7節。
- 設計判断を深める：上に加えて第8節（採用・非採用の理由、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、01-03で決めた目的（依頼の対応状況が分かる、承認記録が残る、担当の重複対応が減る）をもとに、4つの選択肢を比較し、採用案と非採用理由を企画書にまとめることです。
01-03までで「何を目指すか」が決まりました。この記事では、その目的を「何によって」達成するかを、新規アプリ開発以外の選択肢も含めて検討します。
この記事を読み終えると、次のものが手元にできます。
- 選択肢比較表（4つの選択肢を目的・費用・運用担当・変更しやすさで比較）
- 企画書（目的、採用案、非採用理由、前提、リスク、次の判断者）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
運用変更
一言でいうと、新しい道具を導入せず、ルールや手順の見直しだけで対応することです。たとえば、「依頼の連絡手段をメールに統一する」というルールを決めるだけの対応です。
既存機能の活用
一言でいうと、今すでにある道具（表計算ソフトなど）の使い方を工夫して対応することです。
既製サービス
一言でいうと、他社が作って提供している、設定して使えるサービスを利用することです。
新規開発
一言でいうと、この業務に合わせて新しくアプリを作ることです。
これがないと、「新しく作る」以外の選択肢を検討せずに開発を始めてしまい、費用や手間に見合わない結果になることがあります。
読む順路：目的・指標は01-03が該当します。この記事の企画書は、記事A（02-01）の入力になり、記事Aの第8.1節では、確定した要件をもとに同じ4案を比べ直します。
3. 理解する：「作らない」も正当な結論
3.1 4つの選択肢
| 選択肢 | 費用の目安 | 向く場面 |
|---|---|---|
| 運用変更 | 低い | ルールの見直しだけで目的が達成できる場合 |
| 既存機能の活用 | 低い〜中程度 | 権限・履歴の要件がそれほど厳密でない場合 |
| 既製サービス | 中程度〜（契約によっては）高い | 要件が製品の標準機能に近い場合 |
| 新規開発 | 開発費用・保守の負担がかかる | 権限・履歴などの要件が既製品や運用変更では満たせない場合 |
3.2 よくある誤解
「システム開発の教材だから、新しくアプリを作るのが正解」。目的が運用変更や既存機能の活用で達成できるなら、それも正当な結論です。この記事では4つの選択肢を対等に比較します。
「既製サービスは費用が分からないので比較できない」。正確な費用が分からなくても、「契約と設定が必要」「自社の要件に合わせられるかは製品次第」という比較の軸は書けます（第5.2節）。
「AIに『作るべきか』を決めさせればよい」。AIは各選択肢の一般的な特徴を提示できますが、この業務でどの選択肢を採用するかは、01-03の目的と、そこから導いた条件に基づいて人が判断します（第4節）。
「要件はもう分かっているので、それを前提に比べてよい」。この記事の時点では、要件はまだ決まっていません。分かっているのは01-02の課題と01-03の目的です。目的から「権限の分離・承認記録・担当割当は譲れそうだ」と仮置きすることはできますが、それを確定した要件として書くと、後工程の決定を先取りしたことになります（第3.3節）。
3.3 この時点で分かっていること・仮置き・後工程で確定すること
結論から言うと、企画書は「今分かっていること」だけを根拠にし、まだ決まっていないことは「仮置き」か「後工程で確定」と書き分けます。
| 区分 | 内容 | 出所・確定する場所 |
|---|---|---|
| この時点で分かっていること | 課題3件（進捗が見えない、承認記録が残らない、担当割当が曖昧）。改善の目的3つと、その指標が「架空の仮定・未測定」であること | 01-02、01-03 |
| この記事で仮置きすること | 目的3つから、「役割ごとに見える範囲を分ける」「承認の記録が必ず残る」「依頼ごとに担当が1人決まる」の3条件は譲れそうだ、という仮置き。案の比較はこの仮置きの上で行う | この記事（第5.3節「前提」） |
| 後工程で確定すること | 上の3条件が本当に要件になるか、どう書くか（要件ID、受入条件）。既製サービスの費用・機能 | 記事A（02-01）、03-02・03-03 |
仮置きは、後で変わる可能性があるものとして書きます。たとえば記事Aで「承認者は部署で固定」と決まれば、「担当が1人決まる」の意味が変わり、B案（表計算の台帳）の評価も変わります。この記事の採用案が「暫定」なのは、その理由です。
4. 判断すること
企画書を作るときに人が判断することは、次の4つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 4案を同じ軸（目的への効果・費用・運用担当・変更しやすさ）で比べるか | 軸が案ごとに違うと、比較ではなく「作りたい案の説明」になる（第3.2節） | 不可。軸は01-03の目的から作り、この記事で新しい軸を足さない | 新規開発だけが有利に見える表になり、「作らない」が検討されない |
| 目的から「譲れそうな条件」を仮置きするか、要件の確定を待つか | 要件が無いと案を比べられない。しかし要件の確定は02-01（第3.3節） | 可（「仮置き」と明記し、記事Aで確定したら比べ直す） | 仮置きを確定した要件のように書くと、02-01で要件が変わっても企画書が直されない |
| 既製サービス（C案）の費用・機能を、この時点でどこまで書くか | 調べていない数値を書けば、それが根拠になる | 可（「契約と設定が必要」「要件に合うかは製品次第」という定性的な軸で仮置きし、03-02・03-03で調べる） | 未確認の金額が企画書に載り、費用比較の根拠として一人歩きする |
| 採用案を「暫定」にするか「確定」にするか | この時点の材料（課題・目的・仮置きの条件）では、確定に足る根拠がない | 可（暫定とし、次の判断者と、確定に必要な材料を書く） | 暫定の判断が確定として引き継がれ、要件確定後に見直されない |
勝手に決めてはいけないこと：01-03の目的にない基準を、この記事で新しく比較軸に加えません。まだ確定していない要件（権限・履歴の厳密さなど）を、この記事で断定しません。要件IDを付けた要件は記事A（02-01）で確定するものであり、この記事では使いません。
AIに任せる範囲：各選択肢の一般的な特徴（費用の傾向、向く場面）の提示、比較表の下書き、企画書の形への整理はAIに任せられます。しかし、この業務でどの選択肢を採用するかと、何を仮置き・何を後工程で確定と書くかは、人が判断します。AIは「一般的には新規開発が柔軟です」のように結論を先に出しがちで、4案を対等に比べる形に人が戻す必要があります（第6節）。
5. 作って確かめる：選択肢比較表と企画書を作る
5.1 準備
01-03の目的・指標と、01-02の課題一覧を用意します。第3.3節の3区分（分かっていること・仮置き・後工程で確定）を先に決めておきます。
5.2 選択肢比較表
| 選択肢 | 内容 | 目的への効果 | 費用 | 運用担当 | 変更しやすさ |
|---|---|---|---|---|---|
| A. 運用変更（共有表計算と運用ルールの見直し） | 依頼の連絡手段をメールに統一し、進捗確認の時間を決めるなどのルール変更 | 一部の目的（連絡手段の統一）には効果があるが、権限や履歴の記録は改善しにくい | 低い | 総務担当がルールの周知・運用を担う | 変更は容易だが、効果は限定的 |
| B. 既存機能の活用（表計算の共有台帳） | 依頼を1行ずつ台帳に記入し、状態列と承認者列を持つ | 状態が見えるようにはなるが、権限の分離や履歴の記録は不十分になりやすい | 低い | 総務担当が台帳を管理する | 台帳の項目追加は容易 |
| C. 既製サービス | 市販のワークフロー製品を設定して使う | 権限・履歴の機能が最初から用意されていることが多い | 契約・設定の費用がかかる | 設定・契約管理を誰かが担う必要がある | 自社の要件に合わせられるかは製品次第 |
| D. 新規開発 | 依頼・履歴・役割を持つアプリを新しく作る | 目的に合わせて作れるため、効果は高い | 開発・保守の費用がかかる | 保守担当を自分たちで持つ | 要件に合わせて柔軟に変更できるが、変更のたびに開発が必要 |
5.3 企画書
| 項目 | 内容 |
|---|---|
| 目的 | 依頼の対応状況が分かる、承認の記録が残る、担当の重複対応が減る（01-03） |
| 採用案 | D. 新規開発（ただし、この記事の時点では暫定。記事Aで要件を確定したうえで比べ直し、最終判断する） |
| 非採用理由 | A・Bは、仮置きした3条件（役割ごとの範囲、承認記録、担当の割当）のうち、権限の分離と履歴の記録を満たしにくい。Cは、自社の業務（依頼の状態と役割）に合わせられるかが製品次第で、この記事の時点では確認できていない |
| 前提（仮置き） | 01-03の目的から、「役割ごとに見える範囲を分ける」「承認の記録が必ず残る」「依頼ごとに担当が1人決まる」の3条件は譲れそうだ、と仮置きする。これらが要件になるかどうかと、要件の書き方（要件ID・受入条件）は記事A（02-01）で確定する。確定後にこの比較を見直す |
| この時点で未確認のこと | 既製サービスの費用・機能（03-02・03-03で調べる）。自己承認を認めるか、承認者を依頼ごとに決めるか（記事AのQ表で確認する） |
| リスク | 新規開発は費用・保守の負担が大きい。要件を満たしたかどうかは検証（記事B）が必要。仮置きした条件が記事Aで変われば、採用案も変わる |
| 次の判断者 | 総務課長（架空） |
5.4 AIに比較表の下書きを頼む
材料（課題、目的、仮置きした3条件、4案）がそろうと、比較表の下書きをAIに頼めます。AIがするのは、4案を同じ軸で表に整えることです。採用案の判断と、何を仮置きと書くかは人が行います。
| 渡す情報 | 内容 | 渡さない情報と理由 |
|---|---|---|
| 課題と目的（架空） | 01-02の現象3件、01-03の目的3つ（数値は架空の仮定・未測定） | 実在の製品名・実際の見積金額（調べていない。架空の題材では存在しない） |
| 仮置きした3条件 | 役割ごとの範囲、承認記録、担当の割当（仮置きであることを明記） | — |
| 4案と比較軸 | 運用変更・既存機能の活用・既製サービス・新規開発。軸は目的への効果・費用・運用担当・変更しやすさ | — |
指示文は次のとおりです。これは説明のために書いた例で、実際にAIへ送信した記録ではありません。
架空企業「みらい業務サービス」の依頼・承認の業務について、改善の選択肢4案を比較する表の下書きを作ってください。
材料：
- 課題（01-02）：進捗が見えない、承認記録が残らない、担当割当が曖昧
- 目的（01-03）：依頼の対応状況が分かる、承認の記録が残る、担当の重複対応が減る（効果の数値は未測定）
- 仮置きの条件：役割ごとに見える範囲を分ける、承認の記録が必ず残る、依頼ごとに担当が1人決まる（要件はまだ確定していません）
4案：A. 運用変更、B. 既存機能の活用（表計算の台帳）、C. 既製サービス、D. 新規開発
比較軸：目的への効果、費用、運用担当、変更しやすさ
してはいけないこと：
- 採用案を決めないでください。4案を同じ軸で対等に並べてください。
- 既製サービスの具体的な製品名・金額を書かないでください。調べていません。
- 仮置きの条件を「要件」「決定事項」と書かないでください。
返し方：
- 表だけを返してください。各案の欄は「この前提では」という条件付きの表現にしてください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
第5.4節の指示に対して、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではなく、教えるために不備を入れた説明用の例です）。
- 「REQ-003（自己承認禁止）を満たせるのは新規開発だけなので、新規開発が最善です」と、まだ決まっていない要件IDを根拠に、他の3案の比較を省いて結論だけを記載していた
- 「既製サービスの費用は月額◯◯円です」と、確認していない具体的な金額を記載していた
- 仮置きの3条件を「決定事項」という見出しで書いていた
6.2 見つけ方と直し方
見るところは3つです。4案が同じ軸で並んでいるか。根拠に、この時点で存在しないもの（要件ID、調べていない金額）が使われていないか。仮置きが確定のように書かれていないか。
| 問題点 | なぜ問題か | どう見つけるか | 誰が判断するか | どう直したか |
|---|---|---|---|---|
| 「REQ-003を満たせるのは新規開発だけ」と結論だけ書いている | REQ-003は記事Aで確定する要件で、この時点では存在しない。未来の決定を根拠にした結論は、要件が変われば崩れる。また4案の比較が無く、完了条件を満たさない | 根拠に出てくる「REQ-」「決定事項」を、第3.3節の表と照合し、この時点で分かっていることに含まれるかを見る | 業務の責任者（架空：総務課長） | 要件IDを削り、「仮置きした3条件のうち権限の分離と履歴の記録は、A・Bでは満たしにくい」という条件付きの表現にし、4案の比較を復元した |
| 「月額◯◯円」 | 調べていない数値。企画書に載ると費用比較の根拠として使われる（01-03の「測っていない数値」と同じ型） | 数値に出所（見積書、公式の料金表、調査日）があるかを問う。無ければ未確認 | 業務の責任者 | 金額を削除し、「契約・設定の費用がかかる」にとどめ、「03-02・03-03で調べる」を未確認事項に書いた |
| 仮置きの3条件が「決定事項」になっている | 記事Aで変わる可能性がある条件が、変わらないものとして引き継がれる | 「決定事項」「確定」と書かれた項目に、決めた記録（誰が・いつ）があるかを問う | 業務の責任者 | 見出しを「前提（仮置き）」に直し、確定する場所（記事A）を添えた |
AIへの修正指示は次のとおりです（説明用の例）。
指摘：
1. REQ-003はまだ決まっていません。要件IDを根拠にせず、仮置きの条件に対する条件付きの評価として書き直し、4案すべての比較を示してください。
2. 既製サービスの具体的な金額は確認していません。金額を書かず、費用がかかるという記述にとどめてください。
3. 仮置きの3条件は決定事項ではありません。「前提（仮置き）」とし、確定する場所（02-01）を添えてください。
変えないこと：
- 4案と比較軸は変更しないでください。6.3 修正後の企画書
修正後の選択肢比較表・企画書は、第5.2〜5.3節のとおりです。要件IDと金額は無く、前提はすべて「仮置き」と明記されています。
6.4 最終判断
修正後の企画書を採用します。ただし採用案（D）は暫定です。記事Aで要件が確定したら、記事Aの第8.1節で同じ4案を確定した要件で比べ直します。その結果、仮置きした条件が変わればこの企画書も直します。
7. 確認結果
第5.2〜5.3節の内容を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 4種類の選択肢がすべて比較表にある | 第5.2節にA〜Dの4案を記載 |
| 採用案と非採用案の両方に理由がある | 第5.3節に採用案（D）と非採用理由（A・B・C）を記載 |
| 企画書に前提条件と未確認事項がある | 第5.3節「前提（仮置き）」「この時点で未確認のこと」に記載。前提はすべて仮置きで、要件IDは使っていない |
残る制限：この比較・企画書は架空の課題・目的に基づく一例です。既製サービス（C案）の実際の費用・機能は調べておらず、確認できていません。前提の3条件は仮置きであり、要件としての確定は記事A（02-01）で行います。第5.4節の指示文と第6節の初稿は説明用の例であり、実際にAIへ送信・観測した記録ではありません。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 採用案・非採用案の理由（規模・費用・変更容易性から）
| 選択肢 | 判断 | 理由 |
|---|---|---|
| A・B（運用変更・既存機能の活用） | 非採用（この記事の時点） | 仮置きした3条件のうち、権限の分離と履歴の記録は、これらの案では満たしにくい。条件が記事Aで変われば見直す |
| C（既製サービス） | 非採用（この記事の時点） | 自社の業務に合わせられるかが製品次第であり、この記事の時点では確認できていない。03-02・03-03で改めて比較する余地を残す |
| D（新規開発） | 採用（暫定） | 仮置きした3条件を満たせる可能性が最も高い。ただし費用・保守の負担というリスクを伴い、記事Aで要件が確定するまで確定にしない |
8.2 適用限界
この企画書は、架空企業「みらい業務サービス」の小規模な業務を前提にした一例です。実際の業務では、既製サービスの費用や機能を実際に調べたうえで、この判断を見直す必要があります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 選択肢比較表・企画書ひな形（目的、採用案、非採用理由、前提、リスク、次の判断者） | templates/01-04-options-proposal_template.md | templates/01-04-options-proposal_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（目的・指標）を用意する
- 運用変更・既存機能の活用・既製サービス・新規開発の4案を、目的・費用・運用担当・変更しやすさで比較する
- 採用案と非採用理由を書く
- 企画書に前提条件（仮置き）・未確認事項・リスク・次の判断者を書く
- 「今分かっていること」「仮置き」「後工程で確定すること」を分けて書く
10. 次工程への受渡し
次へ渡すもの：選択肢比較表、企画書（採用案、非採用理由、前提、リスク）。
次工程での使われ方：記事A（02-01）では、この企画書を入力として業務要件を整理し、仮置きした3条件が要件（REQ-002・003・005 など）になるかを確定します。確定後、記事Aの第8.1節で4案を比べ直します。非採用と判断された場合は、運用改善の手順（A・B案）へ分岐します。
前工程へ戻る条件：この企画書の前提が01-03の目的と食い違う場合は、01-03に戻って確認します。
11. 根拠と更新情報
- この記事の会社・人物・企画書はすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 選択肢の比較内容（B〜D案）は、記事Aの第8.1節の比較（案B・C・D）と整合させています。運用変更（A案）は、この記事が01-02の課題（連絡手段の不統一）に基づいて追加したものです。記事Aの比較は確定した要件（REQ-002・003・005）を根拠にしていますが、この記事は要件確定前の仮置きの条件を根拠にしている点が違います。
- 第5.4節の指示文は、この記事のために書いた指示文の例であり、実際にAIへ送信した記録ではありません。
- 2026-09-20（Phase 5B-2A）：受入監査で「記事Aで確定するREQ-002・003・005を、この記事の前提として既知のように扱っている」と指摘された。第3.3節で「分かっていること・仮置き・後工程で確定」を分け、企画書の前提を目的から導いた仮置きの3条件に改め、要件IDを本文の根拠から除いた。あわせて読む順路、第4節の判断項目、第5.4節「AIに比較表の下書きを頼む」、第6節のレビュー観点の表と最終判断、記事間の参照を追加した。4案の比較表と採用案（暫定）は変えていない。
- 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 未確認事項：既製サービス（C案）の実際の費用・機能は調べておらず、確認できていません。