システム企画とは、システム開発の前段階で行われる、要求定義やステークホルダーとの合意形成のプロセスです。システム企画は事業目的とシステムの整合性や、利用者と関係者のニーズ、予算と期限などを明確にし、関係者間で合意するプロセスです。
システム企画を適切に行うことで、システムの事業への貢献度合いを明確化でき、その後のシステム設計やシステム開発の効率や品質を向上させることができます。
この記事では、システム企画の進め方を解説します。
システム企画やシステム要求定義の段階で
といったキーワードが出てきたら、クライゼルの各ページをぜひご参照ください。クライゼルを活用することで、安価に安全に業務課題を解決できるでしょう。
システム企画ってなに？
さて、辞書で企画を調べてみると、
「ある事をするため、計画を立てること。もくろみ（物事を成し遂げようと考えること）」
とあります。つまり、ビジネスでの「企画とは」現状の課題や不満を解決するために、計画を立てて関係者の合意を得ることといえるでしょう。
しかし「企画」の前に「システム」という文字が入ると、すぐに要件定義や、システム開発に目が行きがちです。そうではなく、システム企画ではシステム化の対象となるビジネスを理解して、そのうえでビジネスから求められる要求事項をまとめ、システム化の計画を立案し、ステークホルダーの合意を得ることが大切となります。
冒頭にも記載していますが、システム企画は、システム開発の前段階で行われる、要求定義やステークホルダーとの合意形成のプロセスです。システムの「要件定義」や「設計」、「開発」ではありません。
誤解を恐れずに、もっとわかりやすく言うと、システム企画は、
- 対象とする事業や業務にシステムがどのように寄与するかを明確にすること
- 事業や業務上の要求を明確にすること（ニーズやWANTSを明確にするもの）
- システム化の方針稟議承認を得るもの（システム規模が小さい場合は、予算承認や実行稟議の承認）
と言えるでしょう。
システム企画を考える前に
多くの会社は経営戦略に基づき、会計年度ごとに事業戦略を立案し、その実行のために予算（売上、原価、販売管理費、人件費等）を立案します。
よって、システム企画をして、その方針稟議や実行稟議の承認を得るためには、予算立案のスケジュールを予め把握しておく必要があります。システム企画もそのスケジュールに合わせて準備することが必要です。
すでに、方針稟議や予算がすでに承認されているのであれば、方針稟議の内容の確認や、予算の名目や金額を再確認しておくといいでしょう。
もちろん、規模が小さいシステムの場合はそのような承認作業は不要かもしれませんが、システム企画の作業とステークホルダーとの合意は必要でしょう。
システム化の流れ
いまやビジネスでITを利活用することはあたりまえのこととなっています。よって、ビジネス部門の方々にとってもビジネスに密接に関係するシステムの
までの流れを把握しておくことは重要なことです。
一般的にシステム化の流れは以下のようなV字のプロセスになります。
システム企画の流れ
システム化の流れは、経営戦略に基づき、システム企画を行い、システム企画に基づき要求定義を行います。その上でシステム要件定義を行い、ソフトウエアの要件定義を行いプログラミングします。
そして注目したい点は、このプロセスを踏んで作られたシステムが最終的にビジネスに貢献したか否かの評価は、システム企画の内容に対して行われる点です。
つまり、システム企画を行わずにシステム化するのは、その成功・失敗がきわめて不明確な状況でお金、時間、人を投資するようなことになります。
システム企画が不十分だとどうなる
それでは、システム企画が不十分だとどのようなことが起こりうるでしょうか。
システム化の方向性や目的が不明確で、投資結果を評価できない。
システム化を実施する前にシステム化の目的やビジネスへの貢献度を想定していないので、多くのリソースを投入してシステムを作ったけど、それらが当初想定した通りにビジネス貢献したかを評価することができません。
完成してもシステムが使われない。無駄な投資になる。
システム化の方向性や目的が関係者間で合意されていないので、結局つかわれない、または一部しか使われないといったことが起こりえます。このような状態は避けたいですね。
要件が固まらない。要件定義書が作られない。システムの実現可能性が十分に検討されない。
システム企画でシステム化の方向性や目的がない、または合意を得ていない状況で後工程の要求定義、システム要件を決めようとおもっても、要求が定まらない、要件が決まらない状況に陥ることはシステム化あるあるですね。
そのためにも、システム企画の段階で、システム化の方向性、目的はしっかり決めておくといいでしょう。
なお、システム規模が中～小程度の場合は、システム企画のタイミングで要求定義まで行っておくと、ステークホルダー間の意思疎通もさらに円滑になるでしょう、システム企画と要求定義は共にビジネス側の担当者が主体となりまとめるべきものですので同時に進めたほうが効率的な場合も多くあります。
結果として、不十分な見積のまま開発に入り、開発規模（期間、費用）が増大する。つまり、事業に寄与しない。
システム企画が不十分、要件定義が不十分な状況で、システム開発に入ると各工程での後戻りが多発して費用が増大することは多々あります。それでは事業への貢献度も低くなってしまうでしょう。
システム企画は誰がやるべき？
システム企画はだれが行うべきものでしょうか。
前述の通り、システム企画は事業目的とシステムの整合性や、利用者と関係者のニーズ、予算と期限などを明確にし、関係者間で合意をとるプロセスです。
よって、事業側つまりシステムを使うユーザ側で行うべきでしょう。もちろんそこに、ITに詳しいスタッフが入ることもあるかもしれません。しかし、事業の為のシステムですので、事業の方向性や目的を主体として、システムの方向性や目的を検討し、それをビジネス要求としてまとめることになります。
システム規模が大きければ、システム企画は社長や事業管掌の役員クラスが責任をもって進めることになり、システム規模が中ぐらいであれば、事業部門の部門長や部長が中心となって進めるべきものです。そうすることで、事業にシステムがどのように寄与するか、システムにどのくらいの投資ができるのかといったことをしっかりと企画できるでしょう。
しかし、多忙な役員や部門長がシステム企画業務にコミットして時間を使うことはできない場合が多いため、その場合は事業推進のスタッフやIT推進のスタッフが事業責任者の目線でシステムを企画し、その企画の考案中に何度も事業責任者と相談・検討を重ねて作成することになります。
そのようにして作られたシステム企画の最終責任者は事業責任者になります。
システム企画のポイント
さて、システム企画を考えるうえで注意すべきポイントはどのようなことでしょうか。予め以下に留意しておくとシステム企画が進めやすいでしょう。
システムで最低限やりたいことを考える
ビジネスの目的に合わせたシステム化の目的や背景を明確にしたら、システム化の範囲を決めます。その際に最低限実現したいことは何のかを考えましょう。
特に新規事業の場合は未確定な要素が多分にあり、ビジネス環境も自社が想定している以上に変化する可能性があり得ます。それらに柔軟に対応できるように、最低限の範囲を決め、段階的にシステム化を進められるようにしておくと後戻りや、余分な投資をしなくて済みます。
システム化ありきで進めない
前述しましたが、システムという文字が入ると、システムを作ることを前提として進みがちです。そうではなく、該当事業を進める上での課題を明確にして、その課題に対応する解決先をシステムとシステム以外の両面で考えることが必要です。
システムを使うよりアルバイトを使って手作業で解決を進める方が安く上がることも十分にあり得ます。ですので、システムを開発する、システムを導入するという以外の選択肢をいつも考えておきましょう。そうすることで最低限のシステムを構築できる可能性が高まります。
課題解決の優先順位を決めてとりかかる
該当事業を進める場合の課題を整理すると、複数の課題が出てきます。それらの課題のなかで事業に与えるインパクト、実現性（コスト、時間）の観点で優先度を予め決めておくといいでしょう。そうすることで、システムで最低限やらなければならないことが明確になります。
シンプルな業務設計を心がける
システム化の対象となっている業務はそもそも必要なのか、今までのやり方とは異なる方法で業務をすすめられないか検討しましょう。業務の見直し、再設計をすることで思ってもみなかったほど業務をシンプルにすることができるかもしれません。そのことで、システム規模を小さくすることができます。
厳守すべき QCD (Quality Cost Delivery) を決める
システム化のタイミングでいろいろな問題が発生することを予め想定し、その際にQCDの目標値とズレの許容度を明確にしおきます。
その上でどれを最も厳守するべきか、ステークホルダー間で合意しておくといいでしょう。この合意があると、例えば納期を厳守するために、コストをかけて対応するなどといったことがスムーズに進められます。
プロジェクト推進体制を明確にする
システム企画のなかで重要なことの一つは、推進体制の合意です。システム化の対象が複数の部署にまたがる場合は特に、だれがそれらの部署を代表してシステム化を推進するのか。それがその担当者やステークホルダー間で合意されている必要があります。
業務部門はその担当者がその役割を担えるように、担当者の既存業務を他の人へオフロードするなどの対策も計画しておくべきでしょう。名前だけのシステム推進担当では意味がありません。
責任の所在を明確にしておく
前述の通り、システム企画は事業側がその責任を負います。なお、システム企画を検討中のタイミングで、事業の課題の抽出や課題解決案を検討することになりますが、その検討事項や課題をだれがいつ検討するのか、検討結果はだれが承認するのか、それを明確にしておきましょう。
そして、完成したシステム企画はどのレベルの承認（稟議）を取るべきものなのかを予め想定して動くといいでしょう。それを想定しているだけで、システム企画に関与してもらわなければならない上位職の方々が明確になるでしょう。
システム企画書の項目
システム企画を文書化したものがシステム企画書になります。システム企画書は、対象の事業や業務の範囲でボリュームが異なりますが、項目としてはおおよそ以下のような項目になります。
- エグゼクティブサマリー
システム企画内容をわかりやすく、A4で１枚程度のボリュームにまとめます。 - 起案の背景
なぜ企画をすべきなのか、なぜ今なのかを記述します。 - 企画の目的
事業目標や業務目標の観点からシステム企画の目的を記述します。 - 現状の課題
どのような課題や問題か、それをほっておくとどのようなことが起きるのか、一過性の問題か継続的な問題か、それがどれくらい会社にとって重大なのかを記載します。 - 原因
課題や問題はどのような原因でおきているのか、原因を取り除くと解消されるのかを記述します。 - 解決策（before／after）
解決の方針と解決策を記述します。解決策は一つではない場合がほとんどです。よって、解決の方針に基づいて解決策を記述します。
現状と対比した形（Before ／After ）で記載すると読み手の理解が進むでしょう。 - 費用（想定）
システム企画の時点で想定される解決策を実行するうえでの費用を記述します。 - 効果
解決策によってもたらされる効果を極力数字で記述します。その際、投資対効果に関しても記述するようにしましょう。 - 体制
プロジェクトの実行体制を役割と共に記載します。社内外の関係者を記載します。 - スケジュール
システム企画の規模によりますが、中期短期のスケジュールを明確にします。中期スケジュールは3年間の半期単位の粒度、短期スケジュールは１年間の月単位の粒度で記載するといいでしょう。業務の再設計などシステム開発以外の面で時間を要することが多々あるのでそれらを別途抜け漏れなくタスクとして書き出しておき、それらを反映してスケジュールを考えます。 - リスク
ビジネスにはリスクがつきものです。当然システム企画に関してもリスクが予見される場合はそれらと、リスク事象発生時のインパクト、それらをヘッジする案を記述しておきます。
まとめ
今回はシステム企画に関して記載しました。今日ビジネスとシステムはきっても切り離せません。システムの開発や導入を検討する際はいきなり開発や導入の作業を始める前に、システム企画を実施して、ビジネスで実際に使えるシステムを企画するようにしましょう。
システム企画がないシステム導入は、施主の希望がない注文住宅のようなものかもしれません。それはそれで、行き当たりばったりで楽しいかもしれませんが、ビジネスでは大きな問題をはらんでいます。
今回の記事が皆さんの参考になれば幸いです。
トライコーンでは、各種Saasとそれに付随するソリューションサービスを提供しております。システム企画の段階で、
といったキーワードが出てきたらぜひ、当社までお問合わせください。解決案を貴社とご一緒に検討させていただきます。
当社へのお問合わせはこちら。お気軽にお問合わせください。
