システム企画と調達

ITパスポート 無料テキスト 単元15／第3章　システム戦略と企画／ストラテジ系／重要度 ★★★★★／出題箇所 ストラテジ系／読む目安 45分　登録不要で読めます

システム化計画と要件定義

情報システムを導入するときは、いきなり開発に入るのではなく、まず何をどう作るかを固める段階を踏みます。最初の段階がシステム化計画です。システム化計画では、情報システム戦略に基づいて対象業務を分析し、システム化構想やシステム化基本方針をまとめます。具体的には、どのシステムから着手するかという開発順序、概算のコスト、期待できる効果、スケジュール、実施体制、想定されるリスクの分析、システム化の適用範囲などを整理し、システム化の全体像を明らかにします。

システム化計画がまとまったら、次に要件定義を行います。要件定義は、経営戦略やシステム戦略、実際にシステムを使う利用者のニーズを踏まえて、システムに求める機能や条件を具体的に定める工程です。松村さんがよく使う例えでいうと、システム開発は家を建てる手順に似ています。要件定義は「どんな家に住みたいか」を施主が伝える段階に当たり、この後の設計・開発という工程すべての土台になります。

要件定義で整理する内容は大きく2種類に分かれます。機能要件は、業務上どうしても必要な機能そのものを指し、利用者へのヒアリングや現行業務の分析を通じて洗い出します。非機能要件は、処理速度、セキュリティ、可用性など、機能そのものではないけれど満たすべき品質面の条件を指します。要件定義の進め方は、利用者の要求を調査し、その内容を分析したうえで現行業務を分析し、業務要件を定義し、最後に発注者と開発者の間で要件の合意を取るという流れが一般的です。この合意が不十分なまま開発に進むと、後工程で大きな手戻りが発生する原因になります。

家づくりに例えるなら、要件定義でイメージがあいまいなまま工事に入ってしまうと、完成間際になって「思っていた間取りと違う」と気づくようなものです。手直しには余計な時間と費用がかかります。システム開発でも同じで、要件定義の段階でどれだけ丁寧に認識をすり合わせられるかが、その後のプロジェクト全体の成否を左右します。システム化計画から要件定義までの流れと、それぞれの工程が何のために存在するのかを押さえておくことが、試験対策としても実務の理解としても土台になります。

RFIとRFP(調達プロセス)

要件定義が固まると、発注者は開発を担うベンダー企業を選ぶ調達の工程に進みます。調達の基本的な流れは、情報提供依頼、提案依頼書の作成と配布、選定基準の作成、ベンダーからの提案書・見積書の入手、提案内容の比較評価、調達先の選定、契約締結、受入れ・検収という順序で進みます。

この流れの中で発行される2つの文書の違いを押さえておくことが重要です。RFI(Request For Information、情報提供依頼書)は、提案依頼書の作成に先立って、システム化の目的や業務概要をベンダーに示し、考えられる技術や手段について情報提供を依頼する文書です。まだ発注先を絞り込む前の段階で、市場にどのような選択肢があるかを幅広く把握する目的で使われます。RFP(Request For Proposal、提案依頼書)は、導入システムの概要や依頼事項、調達条件を明示し、具体的な提案書の提出をベンダーに求める文書です。一言で区別すると、RFIは情報を集める段階、RFPは提案を求めて発注先を絞り込む段階という違いになります。時系列としてはRFIが先、RFPが後です。

RFPを受け取ったベンダーは、要件を踏まえた提案書を作成します。提案書には、システム構成や開発手法など、RFPを基に検討した具体的な実現方法が示されます。あわせて、開発や運用、保守にかかる費用を示す見積書も提出されます。発注者は、あらかじめ作成しておいた選定基準に沿って、複数のベンダーから届いた提案内容と見積もりを比較評価し、調達先を決定します。近年は、環境に配慮した調達を求めるグリーン調達や、AIやデータを扱う契約で参考にされるAI・データの利用に関する契約ガイドラインにも注意が向けられています。

RFIとRFPは、どちらも発注者からベンダーへ働きかける文書という点は共通しています。違いは、まだ選択肢を広く探している段階か、それとも候補を絞り込んで具体的な提案を比較する段階かというところにあります。試験では、この2つの文書名とタイミングを入れ替えた選択肢がよく出題されるため、情報を集める段階と提案を求める段階のどちらの話かを、文章から読み取る練習をしておくと安心です。

契約と検収

調達先のベンダーが決まると、発注者とベンダーの間で契約を締結します。契約書には、開発の範囲、納期、費用、成果物の内容、責任の所在などが明記されます。どのような契約形態を選ぶかは開発内容の性質によって異なり、成果物の完成を約束する請負契約と、業務の遂行そのものを委任する準委任契約の違いは、実務でもたびたび問題になります。

契約を結ぶ際には、見積書の内容についても十分に確認する必要があります。見積書は、システムの開発、運用、保守などにかかる費用を示す文書で、取引先を選ぶ判断材料であると同時に、発注内容を確認するための重要な文書でもあります。見積もりの妥当性を確認せずに契約を進めると、後になって想定外の費用が発生したり、スケジュールが遅延したりする原因になります。

契約後は、要件定義の内容に基づいて実際の開発が進められます。開発の途中経過は、発注者とベンダーの間で定期的に共有され、必要に応じて仕様のすり合わせが行われます。

システムが完成すると、納品されたものを受け取る受入れの工程を経て、検収が行われます。検収は、納品されたシステムが契約内容や要件定義書の内容を満たしているかどうかを、発注者が実際に検証する工程です。松村さんの例えでいえば、家が完成した後に蛇口から水がきちんと出るかを確かめる段階に当たります。検収が完了すると、発注者は代金の支払いに進みます。システム化計画から要件定義、調達、契約、検収に至る一連の流れを理解しておくことは、システム開発を発注する立場で仕事をするうえでの基礎知識です。

検収を終えたあとも、システムとの付き合いは続きます。実際に運用を始めると、当初は想定していなかった不具合や改善要望が出てくることも珍しくありません。契約書に保守や運用の範囲をあらかじめ定めておくことで、こうした運用開始後のやり取りもスムーズに進めやすくなります。発注から検収までの流れを一つのプロジェクトとして俯瞰しておくと、実際に自分が発注側の担当者になったときにも、今どの段階にいるのかを見失わずに済みます。契約形態の違いは単元7で扱った請負契約・準委任契約の内容とも重なるため、あわせて振り返っておくと理解が深まります。

この単元の確認問題

答えを見る前に、まず自分の言葉で答えてみてください。言葉にできないところが、そのまま本試験で止まるところです。

「第3章　システム戦略と企画」の他の単元

• 単元14　システム戦略と業務プロセス

← 単元一覧へ