コトラ（広報チーム） 
システム企画とは、経営や事業、現場業務の課題を整理し、ITをどのように活用するかを決める上流工程です。単に新しいシステムを導入する計画ではなく、目的、対象範囲、費用、期待効果、進め方を明確にし、関係者の合意を得る活動を指します。
社内SEや情報システム部門の担当者は、技術だけでなく、業務や経営の視点も持ってシステム企画を進める必要があります。本記事では、システム企画の基本的な考え方から実務の進め方、企画書の内容、求められるスキルまでを解説します。
システム企画の概要
システム企画の目的
システム企画の目的は、事業や業務上の課題を解決し、組織として目指す成果につなげることです。業務の効率化、コスト削減、売上向上、顧客対応の改善、セキュリティ強化、法令対応などが代表的な目的です。
重要なのは、導入するシステムそのものではなく、導入後にどのような業務や成果を実現したいかを明確にすることです。たとえば「入力作業を減らす」ではなく、「月次集計にかかる時間を短縮し、担当者が分析や改善に使える時間を増やす」と整理すると、企画の意義が伝わりやすくなります。
システム企画とシステム化企画の違い
システム企画は、経営課題や業務課題に対して、ITを含めた解決の方向性を考える広い概念です。一方でシステム化企画は、解決策のうち「どの業務を、どのようにシステムで支援するか」を具体化する活動として使われることがあります。
実務では両者を明確に区別しない場合もあります。ただし、システム化構想では業務全体の将来像や変革の方向性を描き、システム化計画では対象範囲、実現方法、費用、体制、スケジュールを具体化するという整理をしておくと、検討を進めやすくなります。
社内システム企画で扱う主なテーマ
社内システム企画では、部門ごとの業務改善だけでなく、全社に関わるシステムやIT基盤を扱います。対象になるテーマは、企業の規模や業種、既存システムの状況によって異なります。
- 基幹システムの刷新や更新
- 会計、人事、販売、購買、在庫などの業務システム導入
- クラウドサービスの導入や統合
- データ活用基盤や分析環境の整備
- セキュリティ対策、認証基盤、ネットワークの見直し
- 社内申請、ワークフロー、文書管理の電子化
- 顧客対応や営業活動を支援する仕組みの整備
- 問い合わせ対応や定型業務の自動化
企画担当者は、個別部署から上がる要望をそのまま受け入れるのではなく、全社方針や他システムとの関係も踏まえて判断します。
DX・業務改善・基幹システム刷新との関係
DXは、デジタル技術を活用して業務や事業のあり方を変え、競争力を高める取り組みです。システム企画は、DXを実行可能な施策に落とし込む役割を担います。
業務改善では、紙や表計算ソフトで行っている作業を見直し、重複入力や確認作業を減らすことがあります。ただし、すべての課題をシステムで解決する必要はありません。業務ルールの整理、承認手順の削減、役割分担の変更だけで改善できる場合もあります。
基幹システム刷新では、古いシステムの保守切れ、ブラックボックス化、法制度変更、業務変化への対応などが検討のきっかけになります。刷新の際は、現行システムをそのまま再現するのではなく、業務を標準化し、本当に必要な機能を見極めることが重要です。
要件定義との違い
システム企画は、「なぜ取り組むのか」「何を実現するのか」「どの範囲を対象にするのか」「投資する価値があるのか」を決める工程です。要件定義は、企画で決めた方向性をもとに、システムに必要な機能や性能、運用方法などを具体的に決める工程です。
たとえば、システム企画では「受注情報を一元管理し、月次集計の作業時間を削減する」という目的と方向性を定めます。要件定義では、「どの項目を登録するか」「誰が閲覧・変更できるか」「どの帳票を出力するか」「どの程度の処理速度が必要か」といった詳細を決めます。
システム企画担当者の役割と仕事内容
経営や事業の方針をシステム施策に落とし込む
システム企画担当者は、経営方針や事業計画を理解し、必要なIT施策に変換します。たとえば、新規事業の拡大、顧客対応の品質向上、グループ会社との業務統合といった方針に対し、必要なデータ、システム、運用体制を整理します。
この役割では、経営層の抽象的な方針と、現場で必要となる具体的な仕組みをつなぐ力が求められます。技術的に可能かどうかだけでなく、事業戦略に合っているか、実行する優先度が高いかを判断することが重要です。
現場業務の課題を整理する
現場からは「入力が面倒」「画面が使いにくい」「データが探せない」といった要望が出ます。企画担当者は、こうした声の背景を確認し、業務全体のどこに本質的な課題があるのかを整理します。
ヒアリングでは、担当者の意見だけでなく、実際の業務手順、処理件数、発生頻度、例外対応、他部署とのやり取りも確認します。現場の要望をそのまま機能要件に置き換えるのではなく、課題の原因と影響範囲を把握することが必要です。
システム化の方針と優先順位を決める
限られた予算、人員、期間の中ですべての要望に対応することはできません。そのため、システム企画では、取り組むテーマの優先順位を決めます。
優先順位を決める際は、経営への影響、業務への影響、緊急性、法令対応の必要性、費用対効果、技術的な実現性、他施策との関連を確認します。制度改正対応やセキュリティ対策のように実施が必須のものと、効果を比較して選ぶものを分けて考えると判断しやすくなります。
関係部署と外部の開発会社を調整する
システム企画は、情報システム部門だけで完結する仕事ではありません。利用部門、経営層、経理、法務、セキュリティ担当、外部の開発会社など、多くの関係者との調整が必要です。
特に外部へ開発や導入を依頼する場合は、自社の目的や業務要件を正確に伝え、提案内容を比較・評価します。開発会社に任せきりにするのではなく、発注側が業務の責任者として判断を行い、必要な意思決定を進めることが重要です。
導入後の効果を確認し改善につなげる
システムは導入して終わりではありません。企画段階で設定した目標に対して、実際にどの程度の効果が出たかを確認する必要があります。
確認する指標には、作業時間、処理件数、入力ミス件数、問い合わせ件数、利用率、売上、コストなどがあります。期待した効果が出ていない場合は、システムの問題だけでなく、運用ルール、教育、データ整備、業務手順に原因がないかを確認し、改善策を検討します。
システム企画の進め方
現状業務を可視化して課題を洗い出す
最初に行うのは、現状の業務を把握することです。業務フロー、担当者、使用している帳票やツール、データの流れ、承認手順、他部署との連携を整理します。
業務フローを図にすると、重複入力、属人化、紙の受け渡し、確認待ち、システム間の二重管理などが見つかりやすくなります。業務を可視化する際は、通常の流れだけでなく、例外処理やトラブル時の対応も確認することが大切です。
目的と目指す業務の姿を明確にする
現状の問題を整理したら、将来どのような業務の姿を実現したいかを定めます。これは、現状を示す「As Is」に対して、将来のあるべき姿を示す「To Be」と考えると分かりやすくなります。
目標は、できるだけ測定可能な形にします。たとえば「業務を効率化する」ではなく、「月次集計に要する時間を削減する」「申請の差し戻し件数を減らす」「必要な情報を当日中に確認できるようにする」と設定します。
システム化の範囲と実現方法を検討する
目指す姿を定めた後は、どこまでをシステムで対応するかを検討します。対象業務、対象部署、対象データ、他システムとの連携、移行対象などを整理します。
実現方法としては、既存システムの改修、パッケージ導入、クラウドサービスの利用、新規開発、ノーコードツールの活用、業務手順の見直しなどがあります。自社の強みとなる独自業務は個別開発を検討し、一般的な業務は標準機能を活用するなど、業務の特性に合わせて選択します。
費用・効果・リスクを見積もる
企画の実行可否を判断するには、初期費用だけでなく、導入後の運用費用も含めて考える必要があります。システムの総費用には、開発費、ライセンス費、機器費、移行費、教育費、保守費、運用人件費などが含まれます。
費用対効果は、売上増加、作業時間の削減、ミス削減、紙や郵送費の削減、リスク低減などから見積もります。投資利益率は、投資による利益を投資額で割って算出する考え方があり、投資案件の比較に活用できます。
リスクについては、スケジュール遅延、予算超過、データ移行の失敗、利用定着の不足、セキュリティ事故、外部委託先への依存などを想定します。リスクの発生可能性と影響を整理し、事前に対応策を決めておくことが重要です。
実行計画を作成して意思決定を得る
検討結果をまとめ、経営層や責任者に判断を求めます。この段階では、目的、対象範囲、期待効果、費用、リスク、体制、スケジュールを分かりやすく伝える必要があります。
意思決定者が知りたいのは、システムの細かな技術ではなく、「なぜ今必要なのか」「実施しない場合にどのような影響があるのか」「どの程度の投資と効果を見込むのか」といった点です。選択肢が複数ある場合は、それぞれの利点と注意点を比較して提示します。
調達から導入後評価までの進め方
導入方法を比較して選ぶ
システムの実現方法には、自社開発、外部委託、パッケージソフトの導入、クラウドサービスの利用などがあります。どの方法が適切かは、対象業務の独自性、導入までの期限、予算、社内の技術力、将来の拡張性によって変わります。
一般的な業務であれば、既存のサービスやパッケージを利用することで、導入期間や初期費用を抑えられる場合があります。一方で、自社独自の業務が競争力につながっている場合は、標準機能に業務を合わせるか、追加開発を行うかを慎重に判断する必要があります。
提案依頼書を作成して候補を募る
外部の開発会社やサービス提供会社から提案を受ける際には、提案依頼書を作成します。提案依頼書は、発注側が背景、目的、対象範囲、要件、予算、スケジュール、評価基準などを示し、提案を依頼するための文書です。
提案依頼書が曖昧だと、各社が異なる前提で提案するため、内容や費用を比較しにくくなります。目的、必須条件、希望条件、非機能面の条件、導入後の保守体制などを明確にし、同じ条件で提案を受けられるようにします。
必要に応じて、提案依頼書の前に情報提供依頼を行うこともあります。情報提供依頼では、市場にどのような製品やサービスがあるか、技術的に実現可能か、概算費用や期間はどの程度かを確認します。
提案内容・費用・体制を比較して選定する
候補を選ぶ際は、価格だけで判断しないことが重要です。要求への適合度、提案内容の具体性、導入体制、類似案件の経験、品質管理、セキュリティ、保守体制、スケジュールの妥当性を総合的に評価します。
評価基準は、提案を受ける前に決めておくと、公平な比較につながります。たとえば、機能要件への対応、非機能要件への対応、体制、実績、価格、導入後のサポートを評価項目とし、重要度に応じて配点を設定します。
見積書を確認する際は、初期費用だけでなく、数年間の総費用を比較します。保守費、ライセンス費、クラウド利用料、追加改修費、データ移行費、教育費などが含まれているかを確認します。
導入プロジェクトの進行を管理する
導入が決まったら、発注側と開発側で役割分担、会議体、意思決定の方法、課題管理の方法を決めます。発注側は、要件の確認、業務判断、データ準備、テスト、受け入れ確認などで主体的に関わる必要があります。
進行管理では、予定どおりに作業が進んでいるかだけでなく、品質、課題、リスク、変更要求を確認します。特に仕様変更は、費用や納期に影響するため、変更の理由、影響範囲、優先度を確認し、正式な手続きで判断することが大切です。
導入後に効果を測定して改善する
導入後は、企画段階で設定した目標に対して実績を確認します。利用者へのアンケートやヒアリングも行い、使いにくい点、運用上の問題、追加で必要な支援を把握します。
効果測定では、定量面と定性面の両方を確認します。作業時間やコストのように数字で確認できる効果に加え、情報共有のしやすさ、業務の標準化、属人化の解消、利用者の負担感といった変化も重要です。
システム企画書に盛り込む主な項目
背景・現状の課題・企画の目的
企画書では、なぜこの企画が必要なのかを最初に示します。経営方針、事業環境の変化、現場業務の問題、システム老朽化、制度変更など、取り組みの背景を整理します。
現状課題は、「使いにくい」「非効率」といった表現だけで終わらせず、具体的な事実で示すことが重要です。処理時間、エラー件数、問い合わせ件数、手作業の量、データの重複などを整理すると、課題の重要性が伝わりやすくなります。
対象業務とシステム化の範囲
どの部署のどの業務を対象にするのかを明確にします。対象外の業務や、将来の拡張候補も記載しておくと、関係者の認識合わせに役立ちます。
また、データの範囲、他システムとの連携、移行する情報、利用者数、利用場所なども整理します。範囲が曖昧なまま進めると、後から追加要望が増え、費用や期間が膨らむ原因になります。
実現方法と全体スケジュール
実現方法では、既存システムの改修、サービス導入、新規開発などの選択肢を整理し、採用する案と理由を示します。複数案がある場合は、費用、実現性、導入期間、将来性、リスクを比較します。
全体スケジュールには、企画、要件定義、調達、設計、開発、テスト、移行、教育、稼働開始までの大まかな流れを記載します。業務繁忙期、制度変更日、契約更新時期など、動かせない期限がある場合は早い段階で明確にします。
推進体制と役割分担
企画を実行するには、責任者、実行担当者、利用部門、情報システム部門、外部委託先の役割を明確にする必要があります。特に、業務上の判断を誰が行うのか、最終決定を誰が行うのかを決めておくことが重要です。
利用部門が十分に参加しないと、実際の業務に合わないシステムになるおそれがあります。情報システム部門は技術面や全体最適の観点を担い、利用部門は業務要件や受け入れの責任を担うという形で役割を整理します。
費用対効果・リスク・判断してほしい事項
費用は、初期費用と運用費用に分けて示します。取得から廃棄までにかかる総費用の考え方を持ち、導入後の保守、ライセンス、運用人件費も含めて確認することが必要です。
効果は、売上向上、コスト削減、リスク低減、顧客満足度向上、業務品質向上などに分けて示します。数値化が難しい効果もあるため、定量的な効果と定性的な効果を併記するとよいでしょう。
最後に、企画書では意思決定者に判断してほしい事項を明確にします。予算承認、対象範囲、実施時期、推進体制、調達方針などを整理し、何を決めれば次の工程に進めるのかを示します。
システム企画を成功させるポイント
システム導入そのものを目的にしない
新しい技術やサービスの導入が目的になると、導入後に利用されない、期待した効果が出ないといった問題が起こります。まずは業務や事業の課題を明確にし、その解決にシステムが本当に必要かを考えます。
導入しない選択肢も含めて検討する姿勢が重要です。業務ルールの見直し、不要な手続きの廃止、担当分担の変更、既存機能の活用で解決できる場合もあります。
現場・経営層・関係部署を早期から巻き込む
現場だけで決めると全社方針との整合が取れず、経営層だけで決めると現場に定着しない可能性があります。企画の初期段階から、利用部門、経営層、情報システム部門、関連部署の意見を集めることが大切です。
関係者を巻き込む際は、全員の要望をすべて実現することが目的ではありません。目的と優先順位を共有し、実現できない要望についても理由を説明しながら合意形成を進めます。
優先順位を決めて段階的に進める
大規模な企画ほど、すべてを一度に実現しようとすると、期間、費用、リスクが増えます。重要度の高い機能から段階的に導入し、効果を確認しながら次の段階へ進む方法が有効です。
段階導入では、最初に何を実現するかが重要です。利用者が効果を実感しやすい領域、他の施策の土台となる領域、リスクが高い領域などを優先候補として検討します。
業務を必要以上に複雑にしない
現行業務の例外処理や個別対応をすべて新システムに再現しようとすると、システムは複雑になり、費用も保守負担も増えます。特に基幹システムの刷新では、標準機能に業務を合わせる考え方も必要です。
業務ごとに「本当に必要か」「全社共通にできないか」「手作業で対応しても問題ないか」を見直します。業務の標準化と簡素化を進めることが、システム導入の成功につながります。
目的・予算・期限・責任者を明確にする
システム企画では、目的、予算、期限、責任者が曖昧なまま進むと、意思決定が遅れやすくなります。企画開始時点で、何を達成するのか、どこまで費用をかけられるのか、いつまでに決める必要があるのかを整理します。
責任者は、単に会議に参加する人ではなく、業務上の判断や優先順位の決定を行える立場の人が担うことが望ましいです。判断が必要な事項を先送りしない体制を作ることが、プロジェクトの停滞を防ぎます。
システム企画に必要な知識とスキル
業務を理解して課題を整理する力
システム企画では、技術より先に業務を理解する必要があります。営業、経理、人事、購買、製造など、各部門がどのような目的で、どのような情報を使い、どのような手順で仕事をしているかを把握します。
課題整理では、利用者の要望を聞くだけでなく、事実や数値にもとづいて原因を確認します。「時間がかかる」という声に対して、どの作業に何時間かかっているのか、なぜ時間がかかるのかを掘り下げる力が必要です。
システムの仕組みを理解する基礎知識
システム企画担当者は、必ずしも高度なプログラミング能力を持つ必要はありません。ただし、システム構成、データ連携、クラウド、セキュリティ、ネットワーク、データベース、運用保守などの基礎知識は必要です。
基礎知識があると、外部の開発会社からの提案を理解しやすくなり、実現性やリスクについて適切な質問ができます。技術を目的にするのではなく、業務課題に対して技術をどう使うかを判断するために学ぶことが重要です。
数字で費用対効果を説明する力
企画を承認してもらうには、必要性を数字で説明する力が求められます。費用だけでなく、作業時間、人件費、ミスによる損失、売上機会、リスク発生時の影響などを整理します。
投資効果を示す際は、過度に楽観的な数字を置かないことが重要です。前提条件を明確にし、どの程度の利用率や作業削減を見込んでいるのかを説明できるようにします。導入後に実績と比較すれば、次の企画の精度向上にもつながります。
関係者の意見をまとめる調整力
システム企画では、部門ごとに優先することが異なります。利用部門は使いやすさや機能を重視し、経営層は投資効果を重視し、情報システム部門は安全性や保守性を重視する傾向があります。
企画担当者には、それぞれの意見を整理し、対立を解消する調整力が必要です。そのためには、目的、判断基準、制約条件を共有し、感覚的な議論ではなく事実と優先順位にもとづいて話し合うことが重要です。
企画内容を分かりやすく伝える資料作成力
システム企画書や説明資料では、専門用語を並べるだけでは意思決定につながりません。相手に応じて、経営層には投資効果やリスクを、現場には業務の変化や使い方を、開発会社には要件や制約を伝える必要があります。
資料作成では、結論、背景、課題、解決策、効果、費用、判断事項の順に整理すると分かりやすくなります。図や業務フローを使い、現状と将来の違いを見える化することも、関係者との認識合わせに役立ちます。
