架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。 記事「「作らない」も選択肢に入れて、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. 完了条件の確認

4. 次工程へ渡すもの