IT部門がない会社でも「筋が通ったシステム企画」はつくれる

年商5〜10億規模の中堅企業では、専任のIT部門がなく、総務や経理、事業部のマネージャーがシステム企画を「半分ボランティア」のように担っていることが少なくありません。その結果、現場の業務はよく分かっているものの、IT投資やガバナンスの専門知識が不足し、ベンダーからの提案やSaaSの売り文句を「良さそうだから」とそのまま採用してしまいがちです。ここでつまずくと、ROIが見えないまま予算だけが膨らんだり、導入後に「結局、現場で使われないシステム」になったりします。

本来、IT部門の有無にかかわらず、システム企画は「経営課題から逆算して構想をつくり、役割分担を決め、外部パートナー活用を前提に実装までの道筋を描く仕事」です。ところが、経営はROIとリスク許容度で判断したい、現場は業務改善の要望を伝えたい、ベンダーは技術やサービスの話をしたいと、それぞれ話している言語が違うため、合意形成が止まりやすくなります。このギャップを埋めるためには、「翻訳」の視点で役割分担を設計し、情報の非対称を前提に外部パートナー活用を仕組みとして設計する必要があります。

この記事では、IT部門がない会社でも実践できるシステム企画の型を紹介します。経営判断としての投資ストーリーの作り方、作るか買うかの判断フレーム、社内の役割分担と外部パートナー活用の設計、そして90日で企画から要件・体制・実装につなぐロードマップまで、実務レベルで使える形で整理します。読み終わる頃には、「経営として筋の通ったIT投資ストーリー」と「ベンダーに渡せる企画・要件の叩き台」を持ち帰っていただくことを目指しています。

1. なぜIT部門のない会社でシステム企画が難しいのか

まず押さえておきたいのは、「IT部門がないから失敗する」のではなく、「システム企画の前提条件が整理されていないから失敗する」ということです。専任の情シスがいない企業では、ITに詳しい人ほど日々の問い合わせ対応やトラブルシューティングに追われ、「そもそも何のための投資か」「ROIがどこで生まれるか」を腰を据えて考える時間が取れません。結果として、システム企画の出発点が「現場から来た要望一覧」や「ベンダーから提案されたパッケージ」になってしまいます。

また、IT部門不在の企業では、経営・事業・管理・現場の役割分担があいまいなまま進行しがちです。例えば、経営は「売上を伸ばしたい・海外展開に対応したい」と考えていますが、その意図が具体的なKPIやスコープに落ちる前に、現場からは「この帳票を自動化してほしい」「このSaaSを入れたい」という話が上がってきます。一方、法務や経理は、監査やコンプライアンスの観点からリスクを気にするものの、どこまでをシステム側で担保し、どこからを運用ルールでカバーするかの線引きが曖昧です。この「誰がどこまで責任を持つのか」が見えない状態では、どれだけ良いシステム企画のアイデアがあっても、意思決定が進みません。

さらに、ベンダーとの情報格差も無視できません。ITの専門用語やクラウド、AIのトレンドに詳しくない経営・現場に対して、ベンダーは自社サービスの前提に基づいた説明を行います。その結果、「本来は自社に不要な高度な機能」を受け入れてしまったり、逆に「セキュリティやガバナンスに必要な要素」が見落とされたりします。この情報非対称を前提に外部パートナー活用を設計しないと、見積りや契約の段階で大きなリスクを抱えることになります。

だからこそ、IT部門がない会社ほど、「どのレベルまでを社内で判断し、どこからをプロに任せるか」という役割分担を明確にし、経営・事業・管理・現場・ベンダーの「翻訳者」としてのシステム企画担当を立てることが重要です。以降のセクションで、この翻訳と外部パートナー活用をどのように設計していくかを具体的に見ていきます。

2. 経営判断としての投資ストーリーをつくる：ROI・優先順位・リスク許容

良いシステム企画は、必ず「経営として筋の通った投資ストーリー」から始まります。ここでいう投資ストーリーとは、「何にいくら投じて、どのような成果とリスクプロファイルを得るのか」を説明できる物語です。最初に取り組むべきは、改善したい業務や新規事業を「売上向上」「コスト削減」「リスク低減」「将来の成長オプション」という4つの箱に分けて整理することです。例えば、見積〜請求プロセスの自動化は主にコスト削減とミス削減によるリスク低減の領域に入り、海外向けECサイト構築は売上向上と将来のオプション（他国展開や新サービス）に関わります。

次に、それぞれのシナリオで期待できる効果を概算します。ここでは細かい数字の正確性よりも、「桁感」が重要です。例えば、「見積作成に毎月合計80時間かかっており、その半分を削減できるなら年間○○万円相当の人件費が浮く」といったレベルで構いません。こうした計算をいくつか並べることで、経営層にとって「どの順番で投資すべきか」「何を捨て、どこに集中するか」が見えやすくなります。これがシステム企画の優先順位づけの土台です。

同時に、「どこまでリスクを許容するか」も明言しておく必要があります。たとえば、「個人情報を扱う部分は、クラウドサービスのデータセンター所在地や暗号化方式に一定の条件を課す」「決済や税額計算のロジックは、必ず監査・税理士チェックを通す」といったラインを決めておきます。ここで定めたリスク許容度は、後の外部パートナー活用や契約交渉で重要な判断材料になります。

この投資ストーリーをまとめる際のおすすめは、「A4一枚の投資サマリ」を作ることです。投資目的、対象業務、期待効果、想定コスト、リスクとその許容方針、必要な役割分担を1ページに収め、経営会議で確認します。この1枚が、後のシステム企画の議論をブレさせない羅針盤になりますし、ベンダー側に「何のためのプロジェクトか」を共有するうえでも有力なドキュメントになります。

3. 作るか買うか：受託開発・SaaS・AI活用を見極めるシステム企画

投資ストーリーが定まったら、次に「作るか・買うか」の判断に進みます。ここでのポイントは、単に開発費とSaaS料金を比較するのではなく、「自社の競争優位と運用能力を踏まえたシステム企画」として検討することです。ざっくり言えば、「自社の競争力の源泉に近い領域ほど、自社仕様で作る価値が高く、業界標準に近いバックオフィス機能ほど、既存のSaaSやパッケージを活かした外部パートナー活用が向く」と考えられます。

受託開発を選ぶ場合、メリットは柔軟な要件反映と他システムとの連携自由度です。その一方で、要件定義やテスト、保守・改修における役割分担を社内外で明確にしておかないと、「社員しか業務が分からない」「ベンダーしかシステムが分からない」という二重の属人化が起こりやすくなります。SaaSを選ぶ場合は、導入までのスピードとコスト予測のしやすさが魅力ですが、仕様変更の自由度やデータの取り扱い（エクスポート、バックアップ、解約時のデータ移行など）に制約がある点をシステム企画の時点で織り込む必要があります。

近年は、多くの企業がAIを組み込んだシステム企画を検討しています。ここでは「精度」だけでなく、「学習に必要なデータが自社に揃っているか」「誤判定が起きた際のリスクをどう許容するか」「モデルやプロンプトを誰が管理するか」といった視点が重要になります。AI部分だけを外部サービスに任せ、周辺のワークフローや監査ログの設計は自社主導で行うなど、ハイブリッドな外部パートナー活用も有効です。

判断に迷ったら、「5年TCO」で比較してみてください。初期費用＋5年間のサブスク・保守・改修・インフラ費を洗い出し、「投資ストーリーで描いた効果と見合うか」「組織の役割分担と運用体制で本当に回せるか」を確認します。ここまで見たうえで、「ここはSaaSを採用して、足りない部分だけを受託で作る」「AIは既製サービスを使い、周辺のデータ連携や運用だけをカスタマイズする」といったシステム企画ができると、実行フェーズでのブレが少なくなります。

4. IT部門なしでも回る役割分担設計と外部パートナー活用の発注術

判断の方向性が見えてきたら、いよいよ社内外の役割分担を設計します。ここでは、プロジェクトマネジメントでよく用いられるRACIの考え方が役に立ちます。R（Responsible）は実務の担当者、A（Accountable）は最終責任者、C（Consulted）は相談先、I（Informed）は情報共有先です。IT部門がない会社のシステム企画では、経営層をA（投資判断と優先順位）、事業責任者をR（業務成果への責任）、管理部門をC（監査・コンプライアンス）、現場リーダーをR（要件提供と受入テスト）、そしてシステム企画担当を「翻訳者役のR」として位置付けると整理しやすくなります。

重要なのは、「情シス兼務の担当者が何でも屋にならないこと」です。システムやSaaSの選定、ベンダーとの調整は行いつつも、「業務の決定権」と「投資の最終判断」は必ず事業責任者と経営層に残します。これにより、トラブル時や仕様変更時に、「そもそも何のための投資だったか」を原点に立ち返りやすくなります。また、運用設計やマニュアル作成は現場リーダーを巻き込み、教育・定着までを含めた役割分担として明記しておくことが大切です。

一方、外部パートナー活用における発注術の肝は、「比較可能なRFP（提案依頼書）を用意すること」です。RFPには、プロジェクトの目的、現状業務の概要、スコープの境界線（例：既存基幹システムは触らない、会計領域は別プロジェクトなど）、必須要件・任意要件、非機能要件（性能・可用性・セキュリティ・保守体制）を整理して記載します。この段階で完璧なシステム企画である必要はありませんが、「何をやる・やらないか」が書いてあるだけで、見積もりの質が大きく変わります。

加えて、契約のフェーズでは、外部パートナー活用における責任分界を明文化します。「ベンダーはシステムの正常動作とSLAを保証し、会社側は適切なマスタ登録やユーザー管理・運用ルールの徹底を担う」といった役割分担を契約書や合意書に落とし込むことで、トラブル時の対応もスムーズになります。RFPと契約書の両方に「誰がどこまで何を担うか」が書かれている状態が、IT部門のない会社にとっての理想的なシステム企画です。

5. 90日ロードマップで企画から要件・体制・実装へつなぐ

ここまでで、投資ストーリー、作るか買うかの方向性、社内外の役割分担というシステム企画の骨格が見えてきました。最後に重要なのは、これらを「いつ、誰が、どこまで進めるか」という時間軸に落とすことです。おすすめは、90日を3つのフェーズに分けるシンプルなロードマップです。

Day1〜30：現状整理と投資ストーリーの確定
この期間は、現場の業務フローとデータの流れを棚卸しし、「どこでボトルネックがあり、どこに投資する意味があるのか」を可視化します。同時に、経営層・事業責任者・管理部門と対話しながら、ROIとリスク許容度、優先順位を整理した投資ストーリーを固めます。ここでは、A4一枚の投資サマリと、簡易なシステム企画メモをアウトプットにするのがおすすめです。

Day31〜60：要件定義の骨格と体制・役割分担の確定
次の30日では、画面や入力項目の細部に入る前に、「業務フロー」「必要なデータ項目」「他システムとの連携ポイント」「権限・承認」「非機能要件（セキュリティ・性能・保守）」といった、骨格部分の要件を整理します。このタイミングで、経営・事業・管理・現場・システム企画担当の役割分担をRACIなどで明文化し、会議体や意思決定プロセスを決めておくと、後半がスムーズになります。

Day61〜90：外部パートナー活用の具体化と実装準備
最後の30日で、RFPのドラフトをもとにベンダーから提案・見積もりを受け、比較・交渉を行います。同時に、PoC（概念実証）やトライアル導入を小さい範囲で実施し、実際の画面や操作感を関係者に見てもらうことで、「このシステム企画なら行けそうか」を確かめます。このフェーズでは、契約条件と運用・保守における役割分担を整理し、ユーザー教育やマニュアル整備の段取りも固めます。

このように90日単位で区切ることで、「完璧なシステム企画ができるまで始めない」のではなく、「まずは投資ストーリーと役割分担が整理された状態まで到達する」ことを現実的なマイルストーンにできます。そのうえで、外部パートナー活用を組み合わせながら、段階的にMVPや本番運用へと進めていくイメージです。

6. グローバル展開・監査・セキュリティを見据えた運用・ガバナンス設計

最後のピースが、運用・ガバナンスです。多くのシステム企画が、ここを「後で考える」にしてしまうことで、導入後に監査や海外展開の局面で苦労します。IT部門のない会社だからこそ、最初から「運用で事故らない仕組み」として役割分担とルールを決めておくことが重要です。

セキュリティの観点では、最低限「誰が、どのデータに、どの権限でアクセスできるのか」をロールベースで定め、重要な操作（マスタ変更、承認、エクスポートなど）のログを一定期間保存する仕組みをシステム企画に組み込みます。これにより、問題が起きた際の原因追跡が可能になり、監査の際にも説明しやすくなります。また、パスワード方針や多要素認証、退職者のアカウント削除など、運用ルール側で担保すべき点は、マニュアルや規程に落とし込み、現場と管理部門の役割分担として明記します。

グローバル展開を見据える場合、「どの国の顧客や社員が、どのシステムにアクセスするのか」「個人データはどの国・地域で保管されるのか」を、システム企画の要件として書き込んでおくことが重要です。多言語対応や多通貨決済、各国の税制・インボイス制度への対応など、機能面の要件も増えますが、すべてを一度に対応するのではなく、「どの国を第1フェーズとするか」「将来の展開を見越して、データ構造だけは汎用的にしておくか」といった考え方で分割するのが現実的です。

外部パートナー活用の観点では、ベンダーやクラウド事業者のセキュリティ認証（ISO 27001、SOC2など）や、データセンターの所在地、インシデント発生時の報告フローなどを確認し、自社のリスク許容度に合うかどうかをチェックします。契約上も、「どこまでをベンダーが保証し、どこからを自社が運用で補うか」という役割分担を記載しておくと、トラブル時に責任を押し付け合うリスクを減らせます。

ポイント：運用・ガバナンスは「あとから乗せるオプション」ではなく、最初からシステム企画の一部として設計することで、IT部門がなくても安定した運用が可能になります。

ここまで整えておけば、たとえ社内に大人数のIT部門がなくても、「現場が自律的に回せる運用」と「経営・監査にも説明できるガバナンス」の両立に近づきます。そして、この全体像を一緒に描き、実装まで伴走してくれるパートナーこそが、本当の意味で価値のある外部パートナー活用と言えるでしょう。

まとめ：経営と現場の間を埋めるシステム企画を、伴走してくれるパートナーと共に

IT部門のない会社にとって、システム企画は「よく分からないけれど避けて通れないテーマ」になりがちです。しかし、投資ストーリーをつくり、作るか買うかの方針を決め、社内外の役割分担を設計し、90日ロードマップで具体的なステップに落とし込めば、「何から手をつければ良いのか分からない」という状態からは確実に抜け出せます。重要なのは、「全部自分たちだけでやろう」と無理をするのではなく、最初から外部パートナー活用を前提にしつつ、「何を自社で決めるべきか」「どこからをプロに任せるか」を整理することです。

この記事で紹介した考え方は、どの業界のシステム企画にも応用できますが、実際に自社の文脈に合わせるには、現場の業務フローや既存システム、組織の文化・ルールといった前提条件を丁寧に読み解く必要があります。「うちの会社では、どのように役割分担を設計すれば良いか」「この投資ストーリーは妥当か」「どこまでをSaaSにし、どこからをカスタマイズすべきか」といった悩みは、社内だけで抱え込まず、システム企画〜要件定義〜技術選定〜開発・導入〜運用・ガバナンスまで一気通貫で伴走してくれるパートナーと一緒に考えていくのが近道です。

株式会社ソフィエイトは、そうした「経営と現場の間を埋める」伴走型のパートナーとして、IT部門のない中堅企業のシステム企画や役割分担設計、そして現実的な外部パートナー活用の仕組みづくりを支援しています。もし、この記事を読みながら「うちもそろそろ本気でシステム企画をやり直したい」「既存のベンダーとの付き合い方を見直したい」と感じた方は、ぜひ一度ご相談ください。投資ストーリーの整理から、現場を巻き込んだ合意形成、その先の実装・運用まで、一緒にロードマップを描いていきましょう。