システム企画 重点教科書

システム化計画とは、経営が目指す方向性と、実際に作るシステムとの間をつなぐ「最初の設計図」です。いきなり画面のデザインやプログラムの中身を考え始めるのではなく、その前段階として「そもそも何のためにシステム化するのか」「どこまでの範囲を対象にするのか」を整理する工程だと考えてください。

システム化構想とシステム化基本方針

会社が新しい情報システムを作ろうとするとき、最初に固めるべきなのは細部の仕様ではなく、大きな方向性です。この「何のために、どんな姿を目指してシステム化するのか」という構想をシステム化構想と呼びます。たとえば「紙の伝票処理をなくして、受注から出荷までの時間を半分にする」といった、いわば事業の狙いを言葉にする段階です。

システム化構想が固まったら、それをもう少し具体的な行動指針に落とし込みます。これがシステム化基本方針です。会社が持つ情報システム戦略、つまり経営戦略を実現するために情報システムをどう活用していくかという全社的な方針に沿って、個別のシステム化構想・基本方針が組み立てられる、という上下関係を覚えておきましょう。経営戦略があり、それを実現する情報システム戦略があり、さらにそれを個々のシステム化構想・基本方針が支える、という三段構えのピラミッドをイメージするとわかりやすいと思います。

システム化計画に盛り込む内容

システム化計画では、まず対象となる業務を分析します。そのうえで、情報システム戦略に基づいてシステム化構想・システム化基本方針を立て、複数のシステムがある場合はどれから手をつけるかという開発順序、大まかな金額の見通しである概算コスト、そして導入によってどんな効果が得られるのかという、システム化の全体像を明らかにしていきます。

この計画づくりで欠かせないのが、投じる費用に対してどれだけの効果が見込めるかを見極める費用対効果の視点です。どれほど魅力的なシステムでも、コストに見合う効果が説明できなければ経営者の承認は得られません。あわせて、このシステム化がどこからどこまでの業務・部門を対象にするのかという適用範囲を明確に線引きしておくことも重要です。範囲があいまいなまま進めると、後になって「この業務も含まれると思っていた」といった認識のズレが発生しやすくなります。

また、いつまでに何を終わらせるかというスケジュール、誰が責任を持って計画を推進するのかという体制も、この段階で決めておくべき項目です。プロジェクトには必ず不確実な要素がつきものなので、途中でどんな問題が起こりうるかをあらかじめ洗い出しておくリスク分析も行います。予算オーバーや納期遅延、要員不足といったリスクを早い段階で想定しておくことで、後々のトラブルに備えることができます。

こうした一連の検討をどのような手順・段取りで進めていくかという流れ全体を企画プロセスと呼びます。「思いつきでシステムを作り始める」のではなく、構想から方針、計画へという決まったプロセスを踏むことこそが、システム化計画の本質だといえるでしょう。

具体例で理解するシステム化計画

少しイメージしやすいように、旅館業を営む会社を例に考えてみましょう。この会社は「電話とノートで受けている予約管理を効率化したい」と考えたとします。まず経営陣が固めるのは「予約から会計までを一気通貫でデジタル化し、フロント業務の負担を減らす」というシステム化構想です。次に、この構想を実現するための考え方として「まず予約管理から着手し、翌年度に会計連携を追加する」といったシステム化基本方針を定めます。

ここからシステム化計画に落とし込む段階では、予約管理システムを先に、会計システムを後にという開発順序を決め、それぞれにかかる概算コストを見積もります。そして「毎月の予約対応の電話時間が20時間減る」といった効果を試算し、投じる費用に対してその効果が見合うかという費用対効果を経営陣に説明します。対象を「予約管理業務のみ」とするのか「清掃・在庫管理まで含める」のかという適用範囲の線引きも、この段階で明確にしておく必要があります。

このように、システム化計画は単なる技術選定の作業ではなく、「経営の狙いを、実行可能な計画に翻訳する」という橋渡しの役割を担っています。だからこそ、開発担当者だけでなく経営層や現場の責任者も交えた体制づくりと、あらかじめリスク分析をしておくことが、後工程をスムーズに進めるための土台になるのです。

システム化計画とプロジェクトマネジメントの違い

システム化計画とよく混同されやすい言葉に、プロジェクトマネジメントがあります。システム化計画は「そもそも何を、なぜ作るのか」という企画段階の話であるのに対し、プロジェクトマネジメントは、いざ開発が始まってからの進捗・品質・コストを管理していく実行段階の話です。試験問題では両者の役割の違いを問われることがあるため、システム化計画は「企画のフェーズ」であるという位置づけを意識しておくと、選択肢を絞り込みやすくなります。

計画段階でのリスクへの向き合い方

システム化計画の中で行うリスク分析は、セキュリティ分野で学ぶリスクマネジメントの考え方と根っこは同じです。「起こりうる問題を洗い出し、それがどれくらい深刻かを見積もり、対応の優先順位をつける」という基本の流れをこの段階でも適用します。たとえば「開発を委託する予定のベンダーが途中で対応しきれなくなるかもしれない」というリスクがあるなら、あらかじめ複数のベンダー候補を検討しておく、といった備えが考えられます。システム化計画の時点でリスクの芽を早めに摘んでおくことが、後の要件定義や調達をスムーズに進めるための鍵になります。

システム化計画で「何のために」という大きな方向性が固まったら、次は「具体的に何を作るのか」を言葉にしていく段階に進みます。これが要件定義です。

業務要件定義とは

システム化計画の段階で固まった大きな方向性を受けて、次に行うのが業務要件定義です。これは、会社の経営戦略やシステム戦略、そして実際にシステムを使うことになる利用者のニーズを踏まえながら、「このシステムにどんな機能・要件を求めるのか」を具体的な言葉にしていく作業です。ここでいう「要件」とは、簡単にいえば「これができないと困る」という条件のことだと考えてください。

システム化計画が会社全体を見渡す「地図」だとすれば、業務要件定義はその地図の中の一区画を、実際にどう使うかまで踏み込んで描く「設計図」に近い工程です。ここでボタンの掛け違いが起きると、完成したシステムが現場のニーズと合わない、という事態につながりかねません。

要件定義の進め方(調査から定義まで)

業務要件定義は、思いつきで機能を並べる作業ではなく、決まった順序で進めます。まず利用者の要求の調査を行い、現場で働く人たちが何に困っているのか、何を実現したいのかを丁寧にヒアリングします。次に、集めた要求をそのまま鵜呑みにするのではなく調査内容の分析を行い、本当に必要なことは何かを整理します。

あわせて、今どのようなやり方で業務が行われているかを把握する現行業務の分析も欠かせません。現状を正しく理解しないまま新しいシステムを設計すると、現場の実態にそぐわない仕組みができあがってしまうためです。ここまでの調査・分析の結果を踏まえて、いよいよ業務要件の定義、つまり「このシステムで何を実現するか」を文書としてまとめていきます。

機能要件と非機能要件

業務要件を定義する際には、「何を実現するか」を大きく2つの種類に分けて考えます。ひとつは、システムが実際に行う処理や機能そのものを指す機能要件です。たとえば「注文を受け付けられる」「在庫数を自動で更新する」といった、目に見える働きがこれにあたります。もうひとつは、機能そのものではなく、そのシステムがどれくらいの品質・性能で動くべきかという条件を指す非機能要件です。たとえば「表示に時間がかからない」「止まりにくい」「不正アクセスから守られている」といった、性能や信頼性、セキュリティに関する条件がこれにあたります。この機能要件・非機能要件の定義をセットで行うことが、要件定義の大きな柱になります。機能要件は「何をするか」、非機能要件は「どれだけの品質でするか」と対比させて覚えると、試験本番でも迷いにくくなります。

要件の合意

要件をまとめて終わりではありません。定義した内容を発注側と開発側の双方できちんと確認し、認識のズレがないことを確かめる要件の合意というプロセスが最後に控えています。ここで曖昧なまま先に進んでしまうと、後工程で「思っていたものと違う」というトラブルの火種になります。要件定義とは、単に要望を聞き取るだけの作業ではなく、「調査する、分析する、定義する、合意する」という一連の流れをきちんと踏むことが大切なプロセスなのです。

要件定義でつまずきやすいポイント

要件定義の現場でよく起きる失敗のひとつが、利用者の要求の調査を省略して、いきなり「こういう機能があれば便利だろう」と作り手側の想像だけで進めてしまうことです。現場の利用者と開発側とでは、業務に対する知識の量も視点もまったく異なります。だからこそ、現行業務の分析を通じて「今、実際にどんな手順で仕事をしているのか」を正確に把握し、そのうえで利用者のニーズを丁寧に拾い上げるプロセスが欠かせません。

また、機能要件ばかりに気を取られて非機能要件の検討がおろそかになるケースもよく見られます。たとえば「注文を受け付ける」という機能要件だけを決めても、「セール中に注文が殺到したときに固まらずに動き続けられるか」という非機能要件を詰めておかなければ、実際の運用で大きなトラブルにつながりかねません。機能要件と非機能要件は、いわば車の両輪のような関係にあり、どちらか一方だけでは業務要件定義は完成しないのです。

経営戦略・システム戦略との結びつき

業務要件定義は、現場の要望を集めるだけの作業に見えるかもしれませんが、その根っこには必ず会社の経営戦略やシステム戦略があります。たとえば「他社より早く商品を届けることで差別化する」という経営戦略があるなら、業務要件定義では「出荷までのリードタイムを短縮する機能」が優先度の高い要件として位置づけられるはずです。逆に、現場からの要望をそのまま積み上げるだけで経営の方向性と結びつけずに進めてしまうと、出来上がったシステムが経営戦略に貢献しない、という本末転倒な結果になりかねません。要件定義は、現場の声を聞く作業であると同時に、常に経営戦略・システム戦略という上位の目的に立ち返りながら進めるべき工程なのです。

要件定義から調達へのバトンタッチ

業務要件の定義と要件の合意まで終わると、次はいよいよ「誰が、どうやってこのシステムを作るのか」を決める段階に移ります。ここで固めた機能要件・非機能要件は、この後の調達計画において提案依頼書(RFP)に盛り込まれ、ベンダー企業へ提示される重要な情報になります。つまり要件定義は、社内で完結する作業ではなく、次の調達計画・実施へと確実に引き継がれていく、システム企画全体の中核をなす工程なのです。

自社ですべてを開発するのではなく、外部のベンダー企業から力を借りる場面は少なくありません。ここでは、そうした「外部から調達する」ときの基本的な流れを学びます。

調達の基本的な流れ

要件定義で「何を作りたいか」が固まったら、それを自社だけで開発するのか、それとも外部のベンダー企業に依頼するのかを検討します。外部に依頼する場合の一連の手続きを調達と呼び、その流れはおおむね決まった順序で進みます。

まず、どんな技術や手段があるのか情報を集める情報提供依頼(RFI: Request For Information)から始まり、それをもとに具体的な依頼内容をまとめた提案依頼書(RFP: Request For Proposal)を作成して配付します。次に、どんな基準でベンダーを選ぶかという選定基準を作成したうえで、ベンダー企業から提案書および見積書を受け取り、提案内容を比較評価します。そして最終的に調達先を選定し、契約を締結、納品されたものを実際に確認する受入れ・検収という工程で締めくくられます。「情報を集める、依頼する、比べる、選ぶ、契約する、確認する」という一連の流れをひとつのストーリーとして覚えておくと、試験問題の順序を問う設問にも対応しやすくなります。

RFIとRFPの違い

調達の流れの中でも特につまずきやすいのが、RFIとRFPの違いです。情報提供依頼(RFI)は、まだ提案依頼書を作る前の段階で行うもので、どんな技術動向や手段があるのかをあらかじめ把握するために、ベンダー企業へシステム化の目的や業務概要を伝えて情報の提供を依頼することを指します。いわば「どんな選択肢があるのか教えてください」という、下調べのための依頼です。

これに対して提案依頼書(RFP)は、導入したいシステムの概要や依頼したい内容、調達条件などを具体的に示し、ベンダー企業に対して正式な提案書の提出を依頼するための文書です。RFIが「情報を集める」段階であるのに対し、RFPは「これを実現できる提案をください」と一歩踏み込んで依頼する段階、という違いを意識すると整理しやすいでしょう。

提案書と見積書

RFPを受け取ったベンダー企業は、それに基づいて検討したシステム構成や開発手法などの内容をまとめた提案書を作成し、依頼元に提示します。提案書には、どのような技術でどう実現するかという、いわばベンダー側からの回答がまとめられています。

あわせて提出されるのが見積書です。これは、システムの開発・運用・保守などにかかる費用を示す文書で、取引先を選ぶ際の判断材料になるだけでなく、実際に発注する内容を確認するためにも重要な役割を果たします。提案書が「何を、どうやって作るか」を示すものだとすれば、見積書は「それにいくらかかるか」を示すもの、と対比させて覚えるとよいでしょう。

調達に関する新しい視点

近年の調達では、単に価格や性能だけでなく、環境への配慮を調達の判断基準に組み込むグリーン調達という考え方も注目されています。製品やサービスを選ぶ際に、環境負荷の少ないものを優先的に選ぶという発想です。

また、生成AIの活用が広がる中で、AIを使ったサービスやAIが生成したデータをどのように契約に落とし込むかを整理したAI・データの利用に関する契約ガイドラインも、これからの調達実務で押さえておきたい新しいテーマです。AIを活用したシステムを調達する場面が増える中、著作権や責任の所在といった論点を契約の段階できちんと整理しておくことの重要性が高まっています。

調達先の選定から受入れ・検収まで

複数のベンダー企業から提案書と見積書を受け取ったら、それぞれの内容を横並びで比較し、機能面・費用面・実績などの観点から評価します。この比較評価を経て、最終的にどのベンダーに依頼するかを決めるのが調達先の選定です。ここで大切なのは、単に見積金額が安いベンダーを選ぶのではなく、提案書に示された技術力や実現方法、そして自社の要件をどれだけ満たしているかを総合的に見極めることです。

調達先が決まったら契約締結に進み、いよいよ開発・導入が始まります。そして納品されたシステムが、契約どおりの内容で、要件定義で決めた機能要件・非機能要件を満たしているかどうかを実際に確認する工程が受入れ・検収です。ここで問題が見つかれば、修正を依頼したうえで再度確認を行います。検収が完了して初めて、調達というプロセスにひとつの区切りがつくことになります。

調達プロセス全体を俯瞰する

ここまで見てきたように、調達は「情報を集める(RFI)」「依頼する(RFP)」「比べる(提案書・見積書の比較評価)」「選ぶ(調達先の選定)」「契約する(契約締結)」「確認する(受入れ・検収)」という、いくつもの段階を踏む息の長いプロセスです。それぞれの段階でどんな文書が作られ、誰が何を確認するのかを意識しながら順番を覚えると、試験で問われる並べ替え問題にも落ち着いて対応できるようになります。システム企画とは、経営の狙いをシステム化計画で言葉にし、要件定義で具体化し、調達計画・実施で実現へとつなげていく、一連のつながりを持ったプロセスなのだと理解しておきましょう。