5-6 システム企画
システム企画
システム企画では、経営・業務上の目的を実現するために、システム化の対象、期待効果、費用、体制、調達方法を具体化します。開発を始めてから目的や範囲を考えるのではなく、投資判断と関係者の合意を形成する上流段階です。
この節の目標は、課題分析からシステム化構想、投資評価、RFI・RFP、提案評価、契約までの流れを説明し、適切な調達判断ができるようになることです。
1. 企画は課題と目的から始める
| 段階 | 確認する内容 | 成果物の例 |
|---|---|---|
| 現状調査 | 業務、利用者、データ、既存システム、費用 | 業務フロー、課題一覧 |
| 課題分析 | 原因、影響、優先度、制約 | 課題構造、改善優先順位 |
| システム化構想 | 目的、対象範囲、将来像、期待効果 | システム化構想書 |
| システム化計画 | 体制、日程、費用、リスク、調達方法 | システム化計画書 |
| 投資評価 | 費用対効果、回収期間、リスク | 投資評価資料 |
| 調達 | 情報収集、提案依頼、評価、契約 | RFI、RFP、評価表、契約書 |
「在庫管理システムを導入する」は手段です。目的は、欠品削減、過剰在庫削減、棚卸時間短縮など、測定できる業務成果として定めます。
2. 完全ケース：紙の購買申請を改善する
会社では、備品購入の申請書を紙で回覧しています。申請から承認まで平均5日かかり、進捗を問い合わせる電話も多く発生しています。
現状と課題
- 申請書がどこにあるか分からない。
- 金額ごとの承認者を申請者が判断している。
- 同じ内容を購買台帳へ再入力している。
- 承認記録の検索に時間がかかる。
目的とKPI
- 承認期間：平均5日から2日へ短縮
- 問い合わせ件数：月80件から20件へ削減
- 再入力作業：月30時間から5時間へ削減
- 監査時の記録検索：1件15分から1分へ短縮
TO-BE
申請者がWebフォームへ入力し、金額と部門に応じて承認経路を自動設定します。承認状況を画面で確認でき、承認済みデータは購買台帳へ連携します。
このケースでは、単に紙を画像化するのではなく、承認ルール、入力項目、例外処理、保存期間、アクセス権限を設計します。
3. 要件を種類で分ける
| 要件 | 内容 | 例 |
|---|---|---|
| 業務要件 | 業務として実現したい成果 | 承認期間を2日以内にする |
| 機能要件 | システムが提供する機能 | 申請、承認、差戻し、検索、通知 |
| 非機能要件 | 性能、可用性、セキュリティ、運用など | 応答3秒以内、権限管理、バックアップ |
| データ要件 | 扱うデータ、品質、保存、移行 | 申請番号、金額、承認履歴、保存期間 |
| 制約条件 | 予算、納期、法令、既存環境 | 年度内導入、既存認証基盤を利用 |
非機能要件を後回しにすると、機能は動いても利用者数に耐えない、復旧できない、権限が不適切といった問題が起こります。
4. 費用対効果を比較する
システム投資では、導入費だけでなく、運用、保守、教育、移行、廃棄まで含むTCOを考えます。
例として、初期費用500万円、年間運用費100万円、年間の人件費削減効果250万円、評価期間を3年とします。
- 3年間の総費用：500万円＋100万円×3年＝800万円
- 3年間の総効果：250万円×3年＝750万円
この条件だけなら、3年間では費用が効果を50万円上回ります。ただし、処理速度、監査対応、誤発注削減など金額化しにくい効果もあります。逆に、教育負担、移行失敗、ベンダ依存などのリスクも評価します。
金額、期間、計算対象をそろえずに複数案を比較してはいけません。
5. RFI・RFP・見積依頼を区別する
| 文書・活動 | 目的 | 主な内容 |
|---|---|---|
| RFI | 市場、技術、製品、事例の情報を集める | 実現方式、標準機能、導入事例 |
| RFP | 自社の目的と要件を示し、具体的な提案を求める | 範囲、要件、制約、評価方法、提出条件 |
| RFQ・見積依頼 | 条件を基に価格や納期を確認する | 数量、仕様、価格、支払条件 |
| 提案書 | ベンダが実現方法を提示する | 構成、体制、日程、費用、リスク |
RFIは情報収集、RFPは提案依頼です。要件が曖昧なまま価格だけを求めると、各社の前提が異なり、公平に比較できません。
6. RFPに含める内容
- 背景、現状、解決したい課題
- 目的、KGI・KPI
- 対象業務と対象外の範囲
- 業務・機能・非機能・データ要件
- 既存システムとの連携、移行条件
- 体制、役割分担、想定スケジュール
- セキュリティ、法令、運用、保守条件
- 提案書の形式、期限、問い合わせ方法
- 評価項目と選定手続
特定製品の機能をそのまま要件として書くと、目的に合う別方式を排除する場合があります。必須条件と希望条件を区別します。
7. 提案を総合評価する
| 評価観点 | 確認する内容 |
|---|---|
| 要件適合 | 必須要件を満たすか、前提や未対応事項は何か |
| 実現性 | 技術、体制、日程が現実的か |
| 費用 | 初期費用、運用費、追加費用、TCO |
| 品質・運用 | テスト、監視、障害対応、保守、教育 |
| セキュリティ | 認証、権限、ログ、データ保護、委託先管理 |
| 移行 | データ移行、切替え、旧システム停止、切戻し |
| ベンダ | 実績、担当者、継続性、再委託、財務・供給能力 |
価格に重みを付ける場合でも、必須要件を満たさない提案を最安値だけで選ぶのは不適切です。評価基準を提案受付後に変えると、公平性も損なわれます。
8. 契約と責任分担を確認する
契約では、作業範囲、成果物、検収条件、費用、納期、変更手続、知的財産権、秘密保持、個人情報、再委託、障害対応、契約終了時のデータ返却などを明確にします。
- 請負契約：仕事の完成を目的とする。
- 準委任契約：一定の業務を善良な管理者の注意をもって遂行する。
- 労働者派遣契約：派遣先が派遣労働者へ指揮命令する。
契約名だけでなく、実際の指揮命令、成果物、責任分担を確認します。変更要求は口頭で進めず、影響を評価して正式に合意します。
9. 調達の判断手順
- 経営・業務上の目的とKPIを決める。
- 現状、課題、対象範囲、制約を明確にする。
- 内製、外部委託、パッケージ、クラウドなどを比較する。
- 必要に応じてRFIで情報を集める。
- RFPへ要件と評価基準を記載する。
- 同じ基準で提案を比較し、前提とリスクを確認する。
- 契約で範囲、責任、変更、権利、運用を明確にする。
- 導入後、KPIとTCOで効果を評価する。
10. よくある誤りと理由
- 製品導入を目的にする：目的は業務・経営成果です。
- RFIとRFPを混同する：RFIは情報収集、RFPは具体的な提案依頼です。
- 初期価格だけで選ぶ：運用、保守、移行、教育を含むTCOを比較します。
- 機能要件だけを書けばよいと考える：性能、可用性、セキュリティなどの非機能要件も必要です。
- 提案後に評価基準を変える：公平で説明可能な選定ができなくなります。
- 口頭で変更を依頼する：費用、納期、品質、責任への影響を正式に合意します。
11. セルフチェック
- 課題、目的、手段を区別できているか。
- 業務、機能、非機能、データ、制約の各要件を確認したか。
- 費用と効果の期間・前提をそろえたか。
- RFI、RFP、見積依頼の目的を区別したか。
- 提案評価と契約で責任・変更・権利・運用を確認したか。
理解を確認したら、第5章の練習問題と第5章の知識カードで文書と工程を使い分けてください。企画の前提となる全体最適は、システム戦略で確認できます。
公式範囲との対応
本節は、IPA「ITパスポート試験シラバス Ver.6.5」のシステム化計画、要件定義、調達計画・実施に対応し、システム化構想、投資評価、RFI、RFP、提案評価、契約、請負・準委任・労働者派遣などを扱います。