# 選択肢比較表・企画書ひな形（記入例）

架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「「作らない」も選択肢に入れて、4つの案を比較し企画書にする」（01-04）の本文で使った内容をまとめたもの。空欄版は `01-04-options-proposal_template.md`。

## 1. 選択肢比較表

| 選択肢 | 内容 | 目的への効果 | 費用 | 運用担当 | 変更しやすさ |
|---|---|---|---|---|---|
| A. 運用変更 | 依頼の連絡手段をメールに統一し、進捗確認の時間を決めるなどのルール変更 | 一部の目的には効果があるが、権限や履歴の記録は改善しにくい | 低い | 総務担当がルールの周知・運用を担う | 変更は容易だが、効果は限定的 |
| B. 既存機能の活用 | 依頼を1行ずつ台帳に記入し、状態列と承認者列を持つ | 状態が見えるようにはなるが、権限の分離や履歴の記録は不十分になりやすい | 低い | 総務担当が台帳を管理する | 台帳の項目追加は容易 |
| C. 既製サービス | 市販のワークフロー製品を設定して使う | 権限・履歴の機能が最初から用意されていることが多い | 契約・設定の費用がかかる | 設定・契約管理を誰かが担う必要がある | 自社の要件に合わせられるかは製品次第 |
| D. 新規開発 | 依頼・履歴・役割を持つアプリを新しく作る | 目的に合わせて作れるため、効果は高い | 開発・保守の費用がかかる | 保守担当を自分たちで持つ | 要件に合わせて柔軟に変更できるが、変更のたびに開発が必要 |

## 2. 企画書

| 項目 | 内容 |
|---|---|
| 目的 | 依頼の対応状況が分かる、承認の記録が残る、担当の重複対応が減る |
| 採用案 | D. 新規開発（暫定） |
| 非採用理由 | A・Bは権限の分離や履歴の記録が不十分。Cは自社の要件に合わせられるかが製品次第で未確認 |
| 前提（仮置き） | 01-03の目的から、「役割ごとに見える範囲を分ける」「承認の記録が必ず残る」「依頼ごとに担当が1人決まる」の3条件は譲れそうだと仮置きする。要件として確定するのは02-01（記事A） |
| この時点で未確認のこと | 既製サービスの費用・機能（03-02・03-03で調べる）。自己承認を認めるか、承認者を依頼ごとに決めるか（記事AのQ表） |
| リスク | 開発・保守の費用がかかる。要件を満たしたかは検証が必要 |
| 次の判断者 | 総務課長（架空） |

## 3. 完了条件の確認

- [x] 4種類の選択肢がすべて比較表にある
- [x] 採用案と非採用案の両方に理由がある
- [x] 企画書に前提条件と未確認事項がある

## 4. 次工程へ渡すもの

- [x] 選択肢比較表・企画書（第1〜2節）
- [ ] 承認者：総務課長（架空）— 記入例のため未承認の扱い