システム開発を外注する前には、システム化構想（＝経営・業務課題から、なぜ・何を・どこまでシステム化するかを決める計画）を作ります。機能を先に並べるのではなく、課題、目標、対象業務、実現方式、予算、優先順位を整理することが、過剰開発と見積もりのずれを防ぐ基本です。
システム化構想とは何か
システム化構想は、開発を始めるための仕様書ではなく、「そもそもシステムへ投資すべきか」「どの方法で課題を解決するか」を判断するための計画です。新規開発だけでなく、既製のクラウドサービス導入、既存システムの改修、業務ルールの変更、開発しないという選択肢も比較します。
発注のご相談を受ける開発会社の立場から見ると、初回相談でよくあるのが「顧客管理システムを作りたい」「DXを進めたい」という依頼です。しかし、解決したい課題や現状の負担がわからないままでは、開発会社は仮定を置いて見積もるしかありません。その結果、各社の提案範囲がそろわず、金額も比較しにくくなります。
要件定義やRFPとの違い
システム化構想、要件定義、RFPは、作成する目的と粒度が異なります。要件定義（＝作るものを具体化する工程）へ進む前に構想を整理しておくと、不要な機能の議論を減らせます。
| 資料・工程 | 主な目的 | 主な内容 | 答える問い |
|---|---|---|---|
| システム化構想 | 投資方針を決める | 課題、目標、対象業務、方式、予算、ロードマップ | なぜ、何を、どの順番で変えるか |
| 要件定義 | 作るものを具体化する | 機能、データ、画面、権限、性能、運用条件 | システムが何を満たすべきか |
| RFP | 複数社へ提案を依頼する | 依頼背景、提案範囲、条件、選定基準 | 開発会社へ何を提案してもらうか |
システム化構想では、画面数や項目名まで決める必要はありません。一方、「営業部門の負担を減らしたい」といった抽象的な表現だけでも不十分です。対象業務、利用者、現状の問題、達成したい状態、投資上限を、意思決定できる粒度まで整理します。
構想を作るべき案件
特に次のような案件では、見積もり依頼より先に構想を作る価値があります。
- 複数部門の業務が変わる
- 新規事業としてWebサービスやアプリを立ち上げる
- 基幹システムや長年使った業務システムを更新する
- SaaS導入とスクラッチ開発のどちらがよいか決まっていない
- 開発予算が数百万円以上になり、経営判断が必要になる
- 既存データの移行や他システムとの連携がある
- 個人情報、決済情報、機密情報を扱う
- 一度に全範囲を開発できず、段階導入が必要になる
小規模なフォーム追加や単純な画面改修では、詳細な構想書を作るとかえって負担になる場合があります。その場合でも、目的、対象範囲、予算、完了条件を1〜2ページにまとめてから相談すると、認識のずれを抑えられます。
システム化構想書に入れる項目
構想書で重要なのは資料の厚さではなく、投資判断と次工程に必要な情報がそろっていることです。小規模案件なら5〜10ページ程度、大規模案件なら調査資料を含めて数十ページになることもありますが、枚数を目的にしてはいけません。
必須項目のテンプレート
| 項目 | 記載する内容 | 確認ポイント |
|---|---|---|
| 背景 | 市場環境、経営方針、制度変更、既存システムの問題 | なぜ今取り組むのか |
| 現状の課題 | 手作業、二重入力、処理遅延、ミス、属人化など | 事実と推測を分けているか |
| 対象者 | 社員、管理者、顧客、取引先など | 人数、利用場所、IT習熟度も把握したか |
| 対象業務 | どの業務の開始から終了までを変えるか | 前後工程や例外処理を含むか |
| 目標 | 導入後に実現したい業務・顧客体験 | システム導入そのものが目標になっていないか |
| KPI | 効果を測る数値指標 | 現在値、目標値、測定方法があるか |
| 対象範囲 | 今回実施する範囲と対象外 | 部門、機能、データ、拠点ごとに明確か |
| 実現方式 | SaaS、パッケージ、ローコード、スクラッチなど | 費用だけでなく適合性と制約を比較したか |
| 制約条件 | 予算、期限、既存契約、セキュリティ、法令 | 変更できる条件とできない条件を分けたか |
| 概算費用 | 初期費用、利用料、保守費、移行費、社内工数 | 開発後の継続費用も含むか |
| 導入計画 | 調査、要件定義、開発、移行、教育、公開 | 段階導入や中止判断の時点があるか |
| 推進体制 | 責任者、意思決定者、現場担当者、外部支援者 | 誰が最終決定するか明確か |
| リスク | データ不足、現場定着、外部連携、法令など | 対応策と責任者を決めたか |
KPI（＝目標の達成度を測る数値指標）は、「使いやすくする」のような曖昧な表現ではなく、測定できる形にします。たとえば、月間作業時間、1件あたりの処理時間、入力ミス件数、問い合わせ件数、申込完了率などです。ただし、無理に数値目標を作るのではなく、現在値を計測できない場合は、構想段階で測定方法を決めます。
1ページでまとめる場合の構成
経営会議や初回相談に使う要約版は、次の順序にすると理解されやすくなります。
- 解決したい経営・業務課題
- 現状の業務と問題が起きる場面
- システム化後の状態
- 対象者と対象範囲
- SaaS導入や新規開発などの候補
- 概算予算と希望時期
- 期待効果と測定方法
- 未決事項と主要リスク
- 次に承認してほしい内容
経営層向けの資料では、機能名よりも投資理由、効果、総費用、リスクを前方に置きます。現場向けの資料では、業務がどう変わるか、入力負担が増えないか、例外対応をどうするかを補足します。同じ構想でも、読み手に合わせて要約の見せ方を変えることが大切です。
システム化構想を作る7つの手順
システム化構想は、欲しい機能を集めるところから始めるのではなく、現状把握、目標設定、選択肢比較、範囲決定の順に進めます。一般的な検討期間は、小規模案件で2〜6週間、複数部門にまたがる案件で1〜3か月、基幹業務を含む案件では2〜4か月以上が目安です。
1．意思決定者と検討目的を決める
最初に、構想を誰が承認し、今回どこまで決めるのかを明確にします。事業責任者が意思決定者になり、現場担当者、情報システム担当者、経理・法務などが必要に応じて参加する形が基本です。
開始時に決める項目は次のとおりです。
- 構想策定の責任者
- 参加部門と担当者
- 最終的な承認者
- 検討期限
- 今回決める事項と保留できる事項
- 調査に使える社内工数と外注予算
関係者全員の希望を同じ重みで採用すると、範囲が膨らみます。意見を集める人と、投資判断をする人は分けて考えます。
2．現状を事実で把握する
次に、現在の業務、利用中のツール、データ、発生している負担を確認します。担当者へのヒアリングだけでなく、帳票、Excel、マニュアル、問い合わせ記録、処理件数などの証拠も見ます。
現状調査のチェックリストは次のとおりです。
- 業務の開始条件と完了条件
- 担当部門と承認者
- 月間・年間の処理件数
- 通常処理と例外処理
- 使用中のシステム、Excel、紙帳票
- 二重入力や転記が発生する場所
- ミス、遅延、差し戻しが起きる頻度
- 既存データの種類、件数、品質
- 外部サービスや取引先との連携
- 繁忙期と業務停止が難しい時期
「作業が大変」という声だけでは、開発投資の妥当性を判断できません。たとえば、月間処理件数と1件あたりの時間を測れば、削減可能な工数を概算できます。現状値が取れない場合は、一定期間だけ計測してから方針を決める方法もあります。
3．課題と原因を分ける
目に見える問題と根本原因を分けて整理します。「入力ミスが多い」は問題であり、原因は入力項目の多さ、マスタの不統一、教育不足、確認手順の欠如など複数考えられます。
原因が業務ルールにある場合、システムを作っても問題が残ります。逆に、入力内容を減らす、承認ルールを統一する、既存ツールの設定を変えるだけで解決できることもあります。構想段階では、システム開発ありきにせず、業務改善とシステム化を組み合わせて考えます。
4．目標と効果測定の方法を決める
目標は、事業成果、業務成果、システム利用の3段階で整理すると判断しやすくなります。
| 段階 | 例 | 注意点 |
|---|---|---|
| 事業成果 | 解約抑制、売上機会の拡大、サービス提供能力の向上 | システム以外の要因も影響する |
| 業務成果 | 処理時間短縮、ミス削減、進捗可視化 | 現在値と測定方法が必要 |
| 利用状況 | 利用率、入力完了率、継続利用率 | 利用率だけを最終目的にしない |
費用対効果は、削減時間だけでなく、売上機会、リスク回避、顧客体験、将来の拡張性も含めて評価します。ただし、金額換算が難しい効果を無理に大きく見積もらず、定量効果と定性効果を分けて記載します。
5．実現方式を比較する
課題と目標が決まったら、複数の実現方式を比較します。主な選択肢は次のとおりです。
| 方式 | 向いている状況 | 主な注意点 |
|---|---|---|
| 業務ルールの変更 | 原因が手順や役割分担にある | 定着支援と責任者の合意が必要 |
| 既存ツールの設定変更 | 現行製品に必要機能がある | 設定限界と保守契約を確認する |
| SaaS導入 | 一般化された業務を早く整備したい | 月額費用、データ持ち出し、仕様制約を確認する |
| パッケージ導入 | 業界特有の標準業務へ対応したい | カスタマイズの増加に注意する |
| ローコード開発 | 社内業務を短期間で改善したい | ライセンス費用と複雑な要件への適性を確認する |
| スクラッチ開発 | 独自業務や競争優位を反映したい | 初期費用と保守体制が必要になる |
方式比較では、初期費用だけでなく、3〜5年程度の利用料、保守費、改修費、データ移行費、解約・乗り換えのしやすさも確認します。具体的な年数は事業計画やシステムの想定利用期間に合わせて設定してください。
6．初期範囲と段階導入を決める
すべての要望を初回開発に入れるのではなく、目標達成に不可欠な範囲を先に決めます。優先順位は、事業への効果、緊急性、法令上の必要性、利用頻度、実装難易度、他機能への依存関係から判断します。
範囲を決める際は、少なくとも次の単位で対象と対象外を記載します。
- 対象部門・拠点
- 対象ユーザー
- 対象業務
- 必要な機能群
- 取り扱うデータ
- 連携する外部システム
- データ移行の有無
- 運用開始後の保守範囲
対象外を明記しないと、開発会社と発注者の間で見積もり前提がずれます。範囲の整理方法は、開発スコープの決め方｜要件定義前の整理手順でも詳しく解説しています。
7．概算費用とロードマップを作る
最後に、方式ごとの概算費用と実施順序を整理します。構想段階の金額は、詳細仕様を確定した見積もりではなく、投資判断のための幅を持った概算です。
予算には次の項目を含めます。
- 構想策定、調査、要件定義の費用
- 設計、開発、テストの費用
- クラウドやSaaSの初期費用・利用料
- データ整備・移行の費用
- 外部システム連携の費用
- マニュアル、研修、導入支援の費用
- 公開後の保守運用費
- 発注者側の担当者工数
- 仕様変更や調査不足に備える予備費
ロードマップには、調査、要件定義、試行、開発、データ移行、教育、本番移行を記載します。また、「調査結果が条件を満たさなければ中止する」「試行で効果が確認できれば次段階へ進む」といった判断点も設けます。
外注費用・見積もりと支援会社の選び方
システム化構想の策定支援を外注する費用は、対象部門、ヒアリング人数、現状資料の有無、方式調査、成果物の範囲によって変わります。一般的な目安として、小規模な整理支援は30万〜100万円程度、標準的な構想策定は100万〜300万円程度、複数部門や基幹業務を対象とする調査は300万〜800万円以上になる場合があります。
| 支援範囲 | 期間の目安 | 費用の目安 | 主な成果物 |
|---|---|---|---|
| 数回の相談・ワークショップ | 1〜4週間 | 30万〜100万円程度 | 課題整理、方式案、次工程の論点 |
| 標準的な構想策定支援 | 1〜3か月 | 100万〜300万円程度 | 現状分析、目標、方式比較、概算、ロードマップ |
| 複数部門・基幹業務の構想策定 | 2〜4か月以上 | 300万〜800万円以上 | 業務調査、全体構想、投資計画、移行方針、推進体制 |
これらは一般的な目安であり、開発費は含みません。現場調査、セキュリティ評価、法令調査、既存システム分析、詳細なデータ調査が必要な場合は、費用と期間が増えます。無料相談や無料見積もりは初期判断には有用ですが、複数部門へのヒアリングや比較調査まで無償で行われるとは限りません。
見積もりで確認する項目
構想策定支援の見積もりは、総額だけでなく作業範囲と成果物を確認します。
- ヒアリング対象者と回数
- 現行資料や既存システムの調査範囲
- 業務フロー整理の有無
- SaaS・パッケージ・開発方式の比較範囲
- 技術的な実現可能性調査の有無
- 概算費用の算出条件
- 費用対効果の試算範囲
- 成果物の種類と記載内容
- 報告会、経営会議への説明支援
- 修正回数と追加作業の単価
- 次工程への引き継ぎ方法
不確定要素の多い調査では、準委任契約（＝作業遂行を委託する契約）が使われることがあります。一方、ヒアリング回数や成果物が明確な短期ワークショップなら、固定額の支援メニューが適する場合もあります。契約方式だけで判断せず、どこまで調査し、何を納品し、未決事項をどう扱うかを確認してください。
支援会社を選ぶ基準
システム化構想の支援会社は、資料作成能力だけでなく、業務と技術の両方を踏まえて選択肢を比較できるかで選びます。
- 新規開発だけでなく、SaaS導入や業務変更も提案できる
- 現場の要望をそのまま機能へ変換せず、目的を確認する
- 概算費用の前提条件と除外範囲を説明できる
- 開発費だけでなく、移行・運用・保守まで考慮する
- 経営層と現場の双方へわかりやすく説明できる
- 特定製品を選ぶ場合に、その理由と制約を示せる
- セキュリティ、個人情報、法令上の論点を確認できる
- 要件定義や開発へ引き継げる形式で成果物を作れる
開発会社自身が構想策定を支援する場合は、構想から開発へ円滑につながる利点があります。一方、自社が得意な技術や製品へ誘導されないかも確認が必要です。「開発しない選択肢を含めて比較できますか」「概算の前提が変わった場合、費用へどう影響しますか」と質問すると、提案の中立性と説明力を見極めやすくなります。会社との面談で確認する内容は、開発会社への質問リスト｜商談での見極め方も参考にしてください。
構想が固まりきっていない場合でも、課題整理や方式比較から外部支援を利用できます。自社でどこまで準備すべきか判断しにくい場合は、開発のご相談はこちらからご相談ください。
よくある失敗と回避策
| よくある失敗 | 起きる問題 | 回避策 |
|---|---|---|
| 製品や技術を先に決める | 業務に合わず、追加開発が増える | 課題と目標を決めてから方式を比較する |
| 現場の要望をすべて採用する | 初期範囲が膨らみ、予算と納期を超える | 事業効果と利用頻度で優先順位を付ける |
| 現在値を計測しない | 導入効果を検証できない | 作業時間や件数を導入前に測る |
| 例外業務を調査しない | 本番開始後に手作業が残る | 通常時と例外時の両方を確認する |
| 概算を確定見積もりとして扱う | 要件定義後の金額差を追加請求と誤解する | 前提条件と精度を明記する |
| システム費用だけを予算化する | 移行、教育、保守の費用が不足する | 導入後を含む総費用で比較する |
| 意思決定者が参加しない | 方針が決まらず、調査が長期化する | 判断事項と承認期限を先に設定する |
| 大規模な一括導入を前提にする | 効果確認前に投資が膨らむ | 優先業務から段階導入する |
相談前には、最低限次の情報を用意しておくと初回打ち合わせが進みやすくなります。
- 解決したい課題を3つ以内に絞る
- 主な利用者と利用人数を把握する
- 現在使用しているツールや資料を集める
- 希望時期と、その時期が必要な理由を書く
- 想定予算または投資上限を社内で確認する
- 絶対に変えられない条件を整理する
- 最終決裁者と相談窓口を決める
詳細な仕様を作ってからでなければ相談できないわけではありません。むしろ、方式が決まっていない段階で画面や機能を細かく決めすぎると、より適したSaaSや業務改善の選択肢を見落とすことがあります。発注者は課題、目標、制約を整理し、技術的な実現方法は開発会社と一緒に比較するのが現実的です。
まとめ
- システム化構想は、仕様を決める前に投資目的と実現方針を決める計画です
- 機能ではなく、経営・業務課題、対象者、現状、目標から整理します
- SaaS、パッケージ、ローコード、スクラッチ開発、業務変更を比較します
- 対象範囲だけでなく対象外を明記し、初期開発の膨張を防ぎます
- 概算費用には開発費だけでなく、移行、教育、利用料、保守、社内工数を含めます
- 小規模案件は2〜6週間、複数部門の案件は1〜3か月程度を構想策定の目安とします
- 外注費用は、簡易支援で30万〜100万円程度、標準的な策定支援で100万〜300万円程度が一般的な目安です
- 構想段階の概算と、要件定義後の確定見積もりを区別することが重要です
- 支援会社は、新規開発以外の方法も含めて中立的に比較できるかを確認します
よくある質問
システム化構想書と要件定義書の違いは何ですか？
システム化構想書は、なぜシステム化するのか、どの業務を対象にするのか、どの方式で進めるのかを決める資料です。要件定義書は、構想で決めた方針をもとに、必要な機能、データ、画面、運用条件などを具体化する資料です。
アイデアだけの段階でも開発会社へ相談できますか？
相談は可能ですが、課題、対象利用者、現在の業務、希望時期、想定予算をわかる範囲で整理しておくと、具体的な提案を受けやすくなります。最初から詳細な仕様書を用意する必要はありません。
システム化構想は誰が作るべきですか？
最終責任は発注者側が持ち、事業責任者、現場担当者、情報システム担当者、経理・法務などが必要に応じて参加します。専門知識が不足する場合は、開発会社やITコンサルタントに調査、整理、方式比較を支援してもらう方法があります。
構想段階で開発費を確定できますか？
構想段階で算出できるのは、前提条件を置いた概算費用が中心です。開発費を確定させるには、要件定義で機能、データ、外部連携、非機能要件、移行範囲などを具体化する必要があります。概算を確定見積もりとして扱わないことが重要です。