システム開発の企画書の作り方｜「システムありき」にしない現状分析と課題の抽出（3C・PEST・SWOT）ARTICLE

「AIを使って何かやりたい」「他社が入れているツールをうちにも」——こうした一言から始まったシステム開発の企画は、高い確率で途中で止まるか、できあがっても使われません。何を解決したいのかが決まっていないまま、手段だけが先に決まっているからです。

本記事はシリーズ「発注側のための要件定義」の第2回です。第1回で整理したとおり、企画は発注側が主役になる最初の工程です。この回では、発注側が要求を言葉にする前段階として、「なぜこの企画が必要なのか」を明文化する企画書の作り方を扱います。

「システムありき」で始めると、なぜ失敗するのか

システム開発の企画には、大きく2つの入り方があります。

一つは「システムありき」です。話題のツールや、他社が導入した仕組みが起点になり、「うちにも入れよう」から始まります。入れること自体が目的になるので、入れたあとに「何に使うか」を考えることになります。

もう一つは「目的から」です。まず自社の現状を分析し、解決すべき課題を選び、その解決策を考えます。システムは、解決策を実現する手段の一つとして、必要であれば最後に出てきます。

「システムありき」の企画が失敗しやすいのは、手段が先に固定されると、課題のほうを手段に合わせて後付けしてしまうからです。経営層に「このシステムで何が解決するのか」と聞かれて答えに詰まる。開発側に「何を作ればよいか」と聞かれて機能の羅列しか出てこない。どちらも、目的が先にないことの現れです。

企画書は、この「なぜ必要なのか」を明文化するための道具です。書式を整えることが目的ではなく、書く過程で「目的が先にあるか」を自分たちで確かめることに価値があります。

企画書に必ず入れる5つの要素

企画書の形式は会社ごとに違って構いませんが、次の5つの要素は必ず入れます。

1. 現状分析：企画が必要な理由を裏付ける分析です。現状の問題点と、市場の動きのような外部環境、社内の人や仕組みのような内部環境の因果関係を示します。
2. 目的と全体像：現状分析で浮かび上がった問題点の中から、解決すべき課題を選び、それをどう改善して、どんな状態を目指すのかを示します。
3. 企画内容：「誰に」「何を」「どうやって」実施するのかを、具体的なプランに落とし込みます。
4. スケジュール：企画が立ち上がってから、どのくらいの期間をかけて実施するのかを示します。システム開発が必要であれば、ローンチの時期を明確にします。
5. 収支計画：立ち上げに必要なコストを算出し、あわせて、どの部分で、いつ回収するのかを明記します。

5つの要素は、独立した項目というより、「なぜ → 何を → どうやって → いつ → いくら」という一本の筋です。書き上げたら、上から順に読んで筋が通っているかを確認します。現状分析にない問題が目的に出てきたり、企画内容にない施策の費用が収支計画に出てきたりしたら、どこかで飛躍しています。

実際に書くときの目安として、項目ごとに次の問いに答える形にすると、抜けが分かりやすくなります。

現状分析は5つの観点で見る

5つの要素の中で、最も手間がかかり、最も省略されやすいのが現状分析です。「現状は分かっているから」と飛ばしがちですが、分かっているつもりの現状を言葉と数字にすること自体が、企画の土台になります。

現状分析は、次の5つの観点で見ます。

• 市場：市場の規模、成長率、トレンドを把握します。縮んでいる市場で効率化するのか、伸びている市場で機会を取りにいくのかで、企画の性格が変わります。
• 競合：競合他社の製品やサービス、価格、強みと弱みを評価します。自社の企画が「すでに他社がやっていること」なのか「まだ誰もやっていないこと」なのかが分かります。
• 顧客：誰が、何に困り、どう行動しているかを分析します。顧客の声やアンケートの集計もここに入ります。社内向けのシステムなら、顧客は「使う社員」です。
• 技術と業界の動き：技術の進化、業界の動向、規制の変化、業界標準の登場などを調べます。今後の成長要因とリスク要因の両方を見ます。
• 自社の内部：組織内のリソース、能力、プロセス、文化を評価します。企画を実行できる人と仕組みが自社にあるかを、正直に見る観点です。

前の4つが外部環境、最後の1つが内部環境です。外の変化と、自社の実力との「差」が、解くべき課題になります。外だけを見ると「やるべきだが、うちにはできない」企画になり、内だけを見ると「できるが、やる意味がない」企画になります。

5つすべてを深く調べる必要はありません。企画に関係の深い観点を選び、そこを調べます。社内の業務改善であれば、顧客（使う社員）と自社の内部が中心になり、市場や競合は軽く触れる程度で十分です。

分析の枠組み：3C・PEST・SWOT

現状分析には、広く使われている枠組みがあります。枠組みを使う利点は、見落としに気づけることと、関係者との共通言語になることです。代表的な3つを紹介します。

3C分析：誰に売り、誰と競うか

Company（自社）、Customer（顧客）、Competitor（競合）の3つに焦点を当てます。自社の強み・リソース・技術、顧客のターゲットとニーズと購買行動、競合の戦略と製品と優位性を並べ、「自社が顧客に選ばれる理由」を探します。新しいサービスや事業の企画で、最初に使う枠組みです。

PEST分析：外の環境をもれなく見る

Political（政治）、Economic（経済）、Social（社会）、Technological（技術）の4つの外部要因を評価します。法制度や規制、景気や為替、人口動態や生活様式の変化、技術革新などです。自社ではどうにもならない外の変化を一通り確認するための枠組みで、「見えていなかった追い風や向かい風」に気づくことができます。

SWOT分析：内と外を組み合わせる

Strength（強み）、Weakness（弱み）の内部要因と、Opportunity（機会）、Threat（脅威）の外部要因を組み合わせます。「強みを活かして機会を取る」「弱みが脅威に当たらないようにする」というように、4つの掛け合わせから打ち手を考えられるのが特徴です。既存の業務や事業の改善企画で使いやすい枠組みです。

枠組みは、埋めることが目的ではありません。空欄が多い象限があれば、そこが調べきれていない観点です。埋まらない欄をそのままにせず、調べるか、「分からない」と明記するかを決めます。

現状分析から企画書へ：仮説を立てて進める

現状分析が終われば企画が書けるかというと、そうではありません。分析は材料であって、課題と解決策はそこから「選ぶ」必要があります。

進め方のコツは、各段階で仮説を立てることです。

• 現状分析の段階で「たぶん、問題の中心はここだ」という仮説を置き、それを確かめるように分析する
• 課題の抽出で「この課題を解けば、目的に最も近づく」という仮説を置き、関係者に当てて反応を見る
• 解決策で「この方法なら、この課題が解ける」という仮説を置き、費用と効果を試算する

仮説が外れたら、前の段階に戻って立て直します。最初から正解を書こうとすると、分析が終わらず企画書に着手できません。「たぶんこうだ」を置いて確かめ、外れたら直す、を繰り返すほうが、結果として早く、筋の通った企画書になります。

課題を選ぶときの基準は、目的に対する効果の大きさです。現状分析をすると問題点はたくさん出てきますが、すべてを解こうとすると企画が膨らみます。「これを解けば売上が上がる」「これを解けばコストが下がる」と、成果に直結する課題を優先し、効果の小さいものは意識的に落とします。ここで落としたものは、次の工程（要求定義）で「やらないこと」として記録しておくと、あとから蒸し返されにくくなります。

企画書でよくあるつまずき

1. 現状分析が「不満の列挙」で終わる

「入力が面倒」「二重管理になっている」「探すのに時間がかかる」と、現場の不満を並べただけで現状分析とするケースです。不満は材料としては大切ですが、それがなぜ起きているのか、放置するとどうなるのかまで掘らないと、課題にはなりません。不満の裏にある原因を一段、二段と掘り下げてください。

2. 目的が「システムを導入すること」になっている

目的の欄に「〇〇システムを導入する」と書いてあるケースです。導入は手段であり、目的ではありません。「導入して、何がどうなれば成功なのか」を書き直します。目安は、システムという言葉を使わずに目的を一文で言えるかです。

3. 収支計画に回収の話がない

かかる費用は書いてあるのに、それをどこで、いつ回収するのかが書かれていないケースです。経営層が企画を判断するときに最も見るのはここです。売上の増加でもコストの削減でも構いませんが、「何が、いくら、いつから」変わるのかを、現状分析の数字と結びつけて書きます。

支援の現場で見た、企画を「目的から」に戻す効果

K.S.Rogers の要件定義支援では、「作りたいものは決まっている」という状態で相談を受けても、いったん現状と目的に立ち返るところから始めることが多くあります。

HRスカウト業務のAI効率化を要件定義で地に足をつけた事例は、その典型です。AIで効率化したいという入り口から、どの業務の、どの部分に、どれだけの効果があるのかを整理し直すことで、作るべきものの輪郭がはっきりしました。

企画の段階で「目的から」に戻すのは、遠回りに見えて、最も手戻りの少ない進め方です。ここで筋が通っていれば、次の要求定義で「何を求めているのか」を言葉にする作業が、格段に楽になります。

参考になる公的資料

• IPA「ユーザのための要件定義ガイド 第2版」：要件定義の前段階として、企画や目的の明確化がどう扱われるべきかも整理されています
• 経済産業省「デジタルスキル標準」：DX推進に必要な人材の類型と役割が定義されています。現状分析の「自社の内部」で、企画を実行できる人が社内にいるかを見るときの参考になります

企画の整理からご一緒します ―― K.S.Rogers の要件定義支援

K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、要件定義支援サービスを提供しています。「やりたいことはあるが、企画書にできない」という段階からご相談いただけます。

まとめ

• システム開発の企画は「システムありき」ではなく「目的から」始めます。手段は、課題と解決策が決まったあとに決まります
• 企画書には現状分析・目的と全体像・企画内容・スケジュール・収支計画の5つを入れ、「なぜ → 何を → どうやって → いつ → いくら」の筋が通っているかを確認します
• 現状分析は市場・競合・顧客・技術と業界の動き・自社の内部の5つの観点で見ます。外の変化と内の実力の差が、解くべき課題です。3C・PEST・SWOTは見落としに気づくための道具として使います
• 分析から企画書までは、各段階で仮説を立てて確かめながら進めます。課題は、目的に対する効果の大きさで選びます

次回は、企画で決めた目的をもとに、要求定義の進め方と要求仕様書の書き方（要望・要求・要件の違い、関係者からの要求の集め方と優先順位のつけ方）を扱います。シリーズの全体像は要件定義の進め方を、企画の段階で相談したい方はお問い合わせからお気軽にご連絡ください。