情報システム戦略｜システム化計画・要件定義・RFIとRFP【ITパスポート】

会社の情報システムは、経営戦略を実現する道具として計画し、何を作るかを決め、外部の会社から調達して手に入れます。

経営戦略から情報システム戦略・システム化計画へ
SoR・SoE・SoI ── 3種類のシステム
要件定義 ── 何を作るかを決めて合意する
要件を図にする（DFD・決定表・UML）
調達の流れ（RFI・RFP・提案書・見積書）
まとめ
この節で解ける公開問題

経営戦略から情報システム戦略・システム化計画へ

情報システム戦略は、経営戦略や事業戦略を実現するために、情報システムをどう作り、どう使うかの方針です。システムは目的ではなく、経営の目標に役立つから作ります。この方針を全社の計画に落としたものが情報システム化基本計画です。

経営戦略からシステムの調達までを、左から右へ5枚のカードで表した図。経営戦略（何を目指すか）→情報システム戦略（情報システム化基本計画）→システム化計画（システム化の全体像）→要件定義（何を作るかを決めて合意）→調達（RFI・RFP・契約）。

上の段で決めたことを、次の段が具体的にしていきます。

経済産業省の「システム管理基準」（令和5年）は、IT戦略を「ITガバナンス方針」と「IT基本計画」に分け、IT基本計画で明確にする事項を次のように挙げています。

IT基本計画で明確にする事項（システム管理基準）

1.　組織体の現在のニーズと将来的なニーズへの対応

2.　ITシステムの利活用に関わるステークホルダー（利害関係者）の特定と、そのニーズの反映

3.　組織体のデジタル活用能力を使いこなして、組織の価値を高めること

4.　IT戦略の目標の達成状況を評価するための、開発計画などでの成果（パフォーマンス）の期待値と、ITエコシステム（他の組織と共に使うデジタル基盤やITサービス）を選ぶ基準

全社の計画なので、個々のシステムの細部までは書きません。業務要件とその優先順位を利用者と合意するのは後の要件定義の段、インシデント（障害など）を管理する手順は運用の段で決めることです。

基本計画が決まると、個々のシステムについてシステム化計画を立てます。対象の業務を分析し、まずシステム化構想（どの業務をどう変えるかの大枠）とシステム化基本方針を立て、各システムの開発順序、概算コスト、効果、スケジュール、体制、リスク、適用範囲まで、システム化の全体像を明らかにします。

段ごとに決めることが違うので、その段ではまだ決まっていないことは求められません。たとえばシステム化構想を立てる段では、作るものが決まっていないので、ベンダー企業（システムを作って納める会社）にはその業務の分野でどんな技術が使えるか（情報技術動向）を聞きます。開発コストの見積りや、発注する側の体制・役割分担は、構想のあとで計画を具体的にしていく中で決めるもの、相手の技術者の資格は調達先を選ぶ段で見るものです。

SoR・SoE・SoI ── 3種類のシステム

システム化計画では、作るシステムの性格も考えます。

SoR・SoE・SoI を比べた図。左のSoR＝記録のためのシステム（会計・受発注・在庫。正確さと安定稼働）。右のSoE＝つながりのためのシステム（SNS・アプリ・ECサイト。素早く頻繁に変える）。下の中央のSoI＝洞察のためのシステム（データを分析して気づきを得る）。SoRとSoEの両方から、SoIへデータの矢印が向かう。

記録するSoR、顧客とつながるSoE、その両方のデータから気づきを得るSoIです。

システムの3つの性格

SoR（Systems of Record）　… 記録のためのシステム。会計、受発注、在庫、人事など社内の基幹となる情報を扱い、正確さ・高い信頼性・安定稼働が最優先。変更は慎重に行う

SoE（Systems of Engagement）　… 顧客とのつながりのためのシステム。SNS、スマートフォンのアプリ、ECサイトなど。顧客の反応に合わせて素早く、頻繁に作り変える

SoI（Systems of Insight）　… 洞察のためのシステム。SoR と SoE にたまったデータを分析し、売れ筋や顧客の傾向などの気づきを得る

「止まると困る記録」はSoR、「顧客との関係を育てる仕組み」はSoE、「データから気づきを得る仕組み」はSoIです。同じ会社でも、会計システムは安定して動かし続け、会員アプリは毎月のように改善します。

似た略語と取り違えないようにします。IoT（Internet of Things）はモノをインターネットにつなぐこと、PoC（Proof of Concept、概念実証）は新しい考え方が実現できるかを小さく試して確かめることで、どちらもシステムの性格を表す言葉ではありません。

スーパーマーケットのチェーンが、レジの売上記録と会員アプリの閲覧履歴を集めて分析し、「一緒に買われやすい商品の組合せ」を見つける仕組みを作りました。この仕組みに最も当てはまるものはどれですか。

要件定義 ── 何を作るかを決めて合意する

要件定義は、経営戦略やシステム戦略、利用者のニーズを踏まえて、システムに求めることを決める段です。利用者の要求を調べて分析し、現行の業務も分析したうえで、次の3つを決め、関係者と合意します。

要件定義で決めることを木の形で表した図。上に業務要件（業務として何を実現したいか）。そこから2本の矢印が、機能要件（システムが何をするか）と非機能要件（性能・信頼性・セキュリティ）に分かれる。下の帯には利用者と開発者が向き合い、レビューして合意する。

業務要件から機能要件と非機能要件を決め、利用者と開発者がレビューして合意します。

要件の3つの種類

業務要件　… 業務として何を実現したいか。例：注文をその日のうちに出荷できるようにする

機能要件　… そのためにシステムが何をするか。例：注文を受け付けて、在庫を引き当て、出荷の指示を出す

非機能要件　… 機能以外の、どれだけよく動くか。性能、信頼性、セキュリティ、使いやすさなど。例：画面は3秒以内に応答する、営業時間中は止まらない

システム管理基準は、業務要件定義で利用者と関係者を特定し、要望を集めて優先順位を付け、業務要件として合意するとしています。業務要件をもとに、開発者がシステムとして必要な機能や性能を整理するのがシステム要件定義です。開発者が進める場合でも、利用者は任せきりにせず、システム要件のレビューに参加して、業務に合っているか（妥当性）を確かめます（共同レビュー）。技術的に実現できるかの検証や、保守ができるかの見極めは、開発や運用を担う側の仕事です。

合意した要件は、あとで「できあがったシステムが正しいか」を判定する物差しになります。そのため、要件が曖昧なまま進むと、次のことが起きます。

要件が曖昧だと起きること

開発中の手戻り　… 作り始めてから「そういう意味ではなかった」と仕様変更が続き、作り直しが増える

受入れテストが作れない　… 受入れテストは、納品されたシステムが要件どおりかを発注側が確かめるテスト。物差しが曖昧だと合格の基準を決められない

一方で、プログラムを書き間違えて意図と違う動きをするのは、要件が正しくても起きる作る段の誤りです。また、システム化構想がまとまらないのは要件定義より前の段の問題で、要件の曖昧さが原因ではありません。

要件を図にする（DFD・決定表・UML）

要件は文章だけでは食い違いやすいので、決まった書き方の図にして確かめます。

要件を図にする3つの方法。左＝DFD（データの流れ）：四角から丸へ、丸から2本の平行線へ矢印でつないだ図。中央＝決定表（条件の組合せと動作）：チェックの印と横棒が並んだ表。右＝アクティビティ図（作業の流れと担当）：人のアイコンが付いた上下2つの区画に、開始の黒丸、作業、分岐のひし形、終了の二重丸を矢印でつないだ図。作業の流れが上の区画から下の区画へ移る。

データの流れはDFD、条件の組合せは決定表、作業の流れと担当はアクティビティ図で描きます。

DFD（Data Flow Diagram）は、データの流れを描く図です。データの出どころや行き先になる人・組織（外部実体、四角）、データを加工する処理（プロセス、丸）、データをためておく場所（データストア、2本線）を、データの流れ（矢印）でつなぎます。何のデータがどこへ流れるかは描けますが、処理の順番や条件による分かれ道は描きません。

決定表は、条件の組合せと、そのときに行う動作を表にしたものです。条件の漏れや矛盾が一目で分かります。

たとえば「会員か」「購入額が5,000円以上か」の2つの条件なら組合せは4通りです。表にすると「会員でなく、しかも5,000円未満のときだけ送料500円、ほかは無料」という決まりを、漏れなく書けます。

UML（Unified Modeling Language）は、システムや業務を図で表すための表記法を集めたものです。そのうちアクティビティ図は、開始（黒丸）から作業を矢印でつなぎ、分かれ道（ひし形）を通って終了（二重丸）までの作業の流れを描きます。アクティビティ図を区画（パーティション）に分けると、どの作業をだれ（どの役割）が受け持つかを表せます。たとえば「営業」と「倉庫」の区画に分ければ、受注の確認は営業、出荷は倉庫、という分担が見えます。一方、作業にかかる時間やコスト、成果物の品質の目標値を書き込む記号はありません。

調達の流れ（RFI・RFP・提案書・見積書）

システムを外部の会社から手に入れることを調達といいます。

調達の流れを左から右へ6つの段で表した図。情報提供依頼（RFI）→提案依頼書（RFP）→提案書・見積書→比較評価・選定→契約締結→受入れ・検収。RFIの下には「技術や事例の情報を集める」、RFPの下には「提案書の提出を依頼する」と添えてある。

RFIで情報を集め、RFPで提案を求め、比べて選んでから契約します。

調達で使う4つの文書

情報提供依頼書（RFI）　… 発注する側が作る。RFPを作る前に、システム化の目的や業務概要を示して、考えうる手段や技術動向の情報をベンダー企業に出してもらう

提案依頼書（RFP）　… 発注する側が作る。導入するシステムの概要、提案してほしい事項、調達の条件などを示し、提案書の提出を依頼する

提案書　… ベンダー企業が作る。RFPを基に検討したシステム構成や開発手法などを、依頼元に提案する

見積書　… ベンダー企業が作る。開発・運用・保守などにかかる費用を示す。調達先を選び、発注内容を確かめるのに使う

RFIは「教えてください」、RFPは「提案してください」で、どちらも発注する側からベンダー企業に出す文書です。 RFIで発注する側は目的や業務、現行システムの概要を示し、ベンダー企業からは使えそうな技術とその動向や活用事例などを出してもらいます。新システムに求める要件を示して提案を求めるのはRFPです。なお、性能などの要件を発注者とベンダー企業が一緒に定義するのは要件定義の作業、サービスの品質のレベルについての合意事項を並べた文書はSLA（サービスレベル合意書）で、どちらもRFPではありません。

国や自治体の調達では、条件を満たせばだれでも参加できる一般競争入札が原則です。価格の安さだけで決める方法のほか、価格と技術力などを点数にして総合的に評価する総合評価落札方式があります。加算方式は、価格を点数にした価格点と技術点を足した合計点で比べます。環境への負荷が少ない製品やサービスを優先して選ぶことをグリーン調達といい、国はグリーン購入法にもとづいて取り組んでいます。

メーカーの作り方の言葉も、この節の用語です。OEM（相手先ブランド製造）は、他社のブランドで売られる製品を製造すること、ファブレスは工場を持たずに企画や設計に集中し、製造は外部に任せることです。

ある市が、総合評価落札方式（加算方式）で業者を選びます。3社の点数は次のとおりです。 A社：価格点50、技術点20　／　B社：価格点35、技術点45　／　C社：価格点25、技術点48。 落札するのはどの会社ですか。