システム企画（システム化計画・要件定義・調達計画/実施）

この単元の範囲

基本情報技術者試験のシラバスでは、大分類7「システム戦略」の中に中分類18「システム企画」が置かれている。ここは「経営課題をどう情報システムに落とし込むか」を扱う単元で、開発工程（設計・実装・テスト）が始まる前段、つまり企画・要件定義・調達の3ステップを対象とする。シラバスの小分類は「1. システム化計画」「2. 要件定義」「3. 調達計画・実施」の3つで構成され、時系列としては「何を作るか構想する→要件を定義する→どこに発注するか決める」という順番で並んでいる。プロジェクトマネジメント（設計後の進行管理）と混同しやすいが、システム企画はあくまで「作る前の意思決定」の単元である。

1. システム化計画

小分類1の目標は、システム化構想の立案とシステム化計画の立案の目的・考え方・手順のあらましを理解することである。項目は(1)システム化構想の立案、(2)システム化計画の立案の2つに分かれる。

1-1 システム化構想の立案

経営戦略や事業目標から出発し、「情報システムで何を実現したいか」という大枠の構想を描く段階である。個別の業務効率化だけでなく、全社最適の視点でシステムをどう組み合わせるかを検討するシステム最適化手法、関係部門間で構想の方向性を合わせるシステム化構想の共有、利用者体験を起点にシステムのあり方を設計するシステムデザインといった考え方が用いられる。

ビジネス分析の知識体系を整理したBABOK（ビジネスアナリシス知識体系ガイド）もこの段階の拠り所となる。また、情報システムを役割で分類する視点として、受発注や在庫のような正確な記録を扱うSoR（Systems of Record）、顧客接点でのやり取りを支えるSoE（Systems of Engagement）、データ分析から洞察を得るSoI（Systems of Insight）という3分類がある。たとえば基幹システムはSoR、顧客向けアプリはSoE、BIダッシュボードはSoIに近い性格を持つ、とイメージすると整理しやすい。さらに、パッケージソフトやSaaSを自社仕様に合わせて改修するのではなく、標準機能に業務側を合わせるFit to Standardという考え方も、システム化構想の段階で採否を検討する対象になる。

1-2 システム化計画の立案

構想を具体的な計画に落とし込む段階である。全社レベルでどのシステムに優先的に投資するかを定める全体システム化計画と、個々のシステム開発案件ごとの個別システム化計画に分かれる。計画には、対象範囲を定めるシステム適用範囲、複数年にまたがる全体開発スケジュール、誰がどう進めるかを定めるプロジェクト推進体制、必要なスキルを育てる要員教育計画が含まれる。

投資判断の場面では、投資額に対してどれだけの効果が見込めるかを測る開発投資対効果、複数のIT投資案件を金融ポートフォリオのようにリスクとリターンで管理するITポートフォリオ、企画から開発・運用・廃棄までの一連の流れを表すシステムライフサイクル、導入によって生じ得るリスクをあらかじめ洗い出す情報システム導入リスク分析が用いられる。たとえば「新規顧客管理システムと既存会計システムの刷新、どちらを先に投資すべきか」を判断する場面では、ITポートフォリオの考え方で複数案件を横並びに比較検討する。

2. 要件定義

小分類2の目標は、要求分析と要件定義の目的・考え方・手順を理解し、担当する事項に適用できるようになることである。項目は(1)要求分析、(2)要件定義に分かれ、(2)はさらに①要件定義の目的、②要件の定義、③要件定義の手法、④利害関係者要件の確認の4項目に分解される。

2-1 要求分析

「利用者は何に困っていて、何を実現したいのか」を明らかにする段階である。ユーザーニーズ調査によって利用者の声を集め、現状分析で業務の実態を把握し、そこから課題定義を行い、最終的に要求仕様書としてまとめる。調査手法としては、多人数に定量的に尋ねるアンケートと、対象者に直接話を聞くインタビューがあり、インタビューはあらかじめ質問項目を固定する構造化、大枠だけ決めて自由に深掘りする半構造化、話の流れに任せる非構造化に分類される。たとえば新しい勤怠管理システムを企画する際、まず現場の担当者にアンケートで大まかな不満を把握し、次に代表的なユーザーに半構造化インタビューで具体的な業務の詰まりどころを聞き出す、という組み合わせ方が実務でもよく使われる。

2-2 要件定義

要求分析で明らかになったニーズを、実際にシステムへ落とし込める形の「要件」として整理する段階である。要件は3種類に分かれる。業務上実現すべきことを定める業務要件定義、その業務要件を実現するために情報システムが持つべき機能を定める機能要件定義、そしてパフォーマンス・信頼性・移行要件など、機能そのものではないがシステムの品質に関わる要素を定める非機能要件定義である。たとえば「注文から24時間以内に出荷指示を出せること」は業務要件、「注文データを自動で倉庫システムに連携する機能」は機能要件、「同時アクセス1,000件でも3秒以内に応答すること」は非機能要件、という対応関係になる。

要件を明文化する手法としては、データの流れを図示するDFD、条件と処理の組合せを表形式で整理する決定表（デシジョンテーブル）、システムの構造や振る舞いを標準化された記法で表すUML、データの構造を中心にシステムを設計するDOA（Data Oriented Approach：データ中心アプローチ）がある。また、要件定義には発注者・利用部門・情報システム部門など多様なステークホルダが関与するため、意見の対立を調整しながら合意形成を進めるファシリテーションの技術が欠かせない。

3. 調達計画・実施

小分類3の目標は、調達計画の策定のあらましと調達実施の目的・考え方を理解することである。項目は(1)調達と調達計画、(2)調達の実施に分かれ、(2)はさらに①調達の方法、②情報提供依頼書、③提案依頼書、④提案書・見積書、⑤調達選定、⑥調達リスク分析、⑦契約締結の7項目に分解される。

3-1 調達と調達計画

要件が固まったシステムを、自社で開発するか外部に発注するかを判断する段階である。この判断基準を内外作基準と呼ぶ。外部委託する場合は、委託先がさらに別の会社へ再委託するといった多段階の調達構造全体を管理するソフトウェアのサプライチェーンマネジメント、購入・利用するソフトウェアのライセンス条件を適切に管理するライセンス管理が重要になる。

3-2 調達の実施

外部発注を行う場合の一連の手続きである。発注方式には、複数の提案を競わせて選ぶ企画競争入札、価格を中心に競わせる一般競争入札がある。手続きの流れとしては、まず発注候補となる企業の技術力や実績を把握するためにRFI（Request For Information：情報提供依頼書）を送る。次に、実現したい要件を具体的に示して提案を求めるRFP（Request For Proposal：提案依頼書）、価格の見積りを求めるRFQ（Request For Quotation：見積依頼書）を発行する。これに対して各社から提案書・見積書が提出され、内容・実績・価格などを総合的に比較する調達選定を経て発注先を決定する。

選定にあたっては、リスク面の検討も欠かせない。委託先の内部統制がしっかりしているか、法令遵守の体制があるか、企業の社会的責任を果たしているかというCSR（Corporate Social Responsibility：企業の社会的責任）調達、環境負荷の小さい製品・サービスを優先するグリーン調達の観点も調達リスク分析に含まれる。

最後に交わす契約締結では、業界標準的な契約条項を整理したソフトウェア開発委託モデル契約や情報システム・モデル取引・契約書が参考にされる。契約形態としては、成果物の完成を約束せず一定の業務遂行を委託する（準）委任契約、成果物の完成と納品を約束する請負契約があり、要件定義やコンサルティングのように成果物の形が事前に確定しにくい工程では準委任契約、パッケージ開発のように仕様と納期が明確な工程では請負契約が選ばれやすい。このほか、著作権などの知的財産の利用を許可する知的財産権利用許諾契約、ソフトウェアの使用条件を定めるソフトウェア使用許諾契約やライセンス契約も、調達実施の最終段階で交わされる代表的な契約類型である。

---

参考文献

• IPA「基本情報技術者試験シラバス Ver.9.2」大分類7「システム戦略」中分類18「システム企画」（p.83-85）: https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kpe-att/syllabus_fe_ver9_2.pdf