読み込み中...
読み込み中...
読み込み中...
読み込み中...
読み込み中...
企業が IT を活用して競争力を高めるには、場当たり的にシステムを導入するのではなく、経営戦略と整合した 情報システム戦略 を立てることが欠かせません。たとえば、ある小売チェーンが「全店舗の在庫をリアルタイムに把握したい」と考えたとき、POS システム・倉庫管理システム・本部の分析基盤をどう組み合わせるかを全体最適の視点で設計する必要があります。
このセクションでは、組織全体の IT 構造を俯瞰する エンタープライズアーキテクチャ(EA) 、業務そのものを見直す BPR・BPM 、外部サービスを活用する ソリューションビジネス と クラウドサービス 、そしてシステム導入の計画立案までを体系的に学びます。
エンタープライズアーキテクチャ(EA) とは、組織全体の業務と情報システムの構造を4つの体系(アーキテクチャ)で整理し、全体最適を実現するための設計手法です。経済産業省が推進した「EA 策定ガイドライン」にも採用されており、FE 試験でも頻出です。
| 体系 | 英語 | 対象 | 具体例 |
|---|---|---|---|
| ビジネスアーキテクチャ(BA) | Business Architecture | 業務プロセス・組織構造 | 業務フロー図、組織図 |
| データアーキテクチャ(DA) | Data Architecture | データの構造・関連 | ER 図、データ辞書 |
| アプリケーションアーキテクチャ(AA) | Application Architecture | アプリケーションの構成・連携 | アプリケーション関連図 |
| テクノロジアーキテクチャ(TA) | Technology Architecture | ハードウェア・ネットワーク基盤 | ネットワーク構成図、HW 一覧 |
EA では、まず現状の姿( As-Is )を整理し、次に理想の姿( To-Be )を描き、そのギャップを埋める移行計画を策定します。
上位のアーキテクチャが下位を規定する関係にあり、業務要件(BA)からデータ(DA)→アプリ(AA)→技術基盤(TA)の順に設計します。
既存の業務プロセスを根本的に見直し、 ゼロベースで再設計 する手法です。マイケル・ハマーとジェイムズ・チャンピーが提唱しました。
BPR は「改善」ではなく「改革」です。部分的な効率化ではなく、業務の目的そのものに立ち返って設計し直す点が特徴です。
業務プロセスを 継続的に モニタリング・分析・改善する管理手法です。BPR が一度きりの大改革であるのに対し、BPM は PDCA サイクル を回し続ける点が異なります。
| 項目 | BPR | BPM |
|---|---|---|
| アプローチ | 抜本的な再設計 | 継続的な改善 |
| 頻度 | 一度きり(大規模) | 継続的(日常的) |
| リスク | 高い(大きな変化) | 低い(段階的) |
業務プロセスの一部を 外部の専門業者に委託 することです。コールセンター業務や給与計算など、コア業務以外を外部に任せて自社はコア業務に集中する戦略です。
業務の流れを可視化するために、さまざまなモデリング手法が使われます。
データの流れを図示する手法です。4つの記号で構成されます。
| 記号 | 名称 | 意味 |
|---|---|---|
| 丸(○) | プロセス | データを処理・変換する機能 |
| 矢印(→) | データフロー | データの流れ |
| 二重線(=) | データストア | データの保管場所 |
| 四角(□) | 外部エンティティ | システムの外部(顧客・取引先等) |
データの実体(エンティティ)と関連(リレーションシップ)を図示する手法です。データベース設計の基礎として使われ、データアーキテクチャ(DA)の中核をなします。
業務の手順・承認ルートを定義し、電子的に管理する仕組みです。紙の回覧を電子化することで、承認の迅速化・進捗の可視化・証跡の記録が可能になります。
ソリューションビジネス とは、顧客の経営課題に対して IT を活用した解決策(ソリューション)を提供するビジネスの総称です。単にハードウェアやソフトウェアを売るのではなく、課題の分析からシステム構築・運用までを一体的に提供します。
| サービス | 説明 |
|---|---|
| SoE(System of Engagement) | 顧客や取引先との「つながり」を重視するシステム(SNS、モバイルアプリ等) |
| SoR(System of Record) | 企業の基幹業務データを正確に記録・管理するシステム(会計、在庫管理等) |
| SOA(Service Oriented Architecture) | 業務機能をサービス単位で部品化し、それらを組み合わせてシステムを構築する設計手法 |
| ASP(Application Service Provider) | アプリケーションをネットワーク経由で提供する事業者 |
| ホスティングサービス | サーバやストレージを貸し出すサービス。自社で機器を保有しなくてよい |
| ハウジングサービス | 顧客の機器をデータセンターに設置し、回線や電源を提供するサービス |
クラウドサービスは、IT リソースをインターネット経由で利用する形態です。自社でサーバを保有・管理する オンプレミス に対し、初期費用を抑えて柔軟にスケールできるメリットがあります。
| モデル | 提供範囲 | 利用者が管理する範囲 | 代表例 |
|---|---|---|---|
| IaaS (Infrastructure as a Service) | ハードウェア + 仮想化基盤 | OS、ミドルウェア、アプリ | AWS EC2, Azure VM |
| PaaS (Platform as a Service) | IaaS + OS + ミドルウェア | アプリケーションのみ | Heroku, Google App Engine |
| SaaS (Software as a Service) | すべて(アプリまで) | 設定・データのみ | Gmail, Microsoft 365, Salesforce |
| 形態 | 説明 |
|---|---|
| パブリッククラウド | 不特定多数の利用者にサービスを提供(AWS、Azure、GCP 等) |
| プライベートクラウド | 特定の組織専用に構築されたクラウド環境 |
| ハイブリッドクラウド | パブリックとプライベートを組み合わせて使い分ける |
| マルチクラウド | 複数のパブリッククラウドを併用する |
システム化計画とは、経営戦略や情報システム戦略に基づいて、 どの業務をどのようにシステム化するか を具体的に計画することです。
| 項目 | 説明 |
|---|---|
| 対象業務の明確化 | どの業務をシステム化するかを決定する |
| システム化の目標 | システム化によって達成したい定量的な目標を設定する |
| 対象範囲の決定 | システム化する範囲と、しない範囲を明確にする |
| スケジュール | 開発・導入のスケジュールを策定する |
| 費用対効果 | システム投資の効果を定量的に評価する |
| リスク分析 | 想定されるリスクと対策を明確にする |
システム投資の判断には、費用対効果の分析が重要です。
TCO を正しく見積もらないと、「導入は安かったが運用費がかさんで結局高くついた」という事態になりかねません。運用・保守費は一般に TCO の 70〜80% を占めるとも言われます。
ポイント
EA(エンタープライズアーキテクチャ) は BA(業務)・DA(データ)・AA(アプリ)・TA(技術)の4体系で全体最適を図る。 BPR は業務プロセスをゼロベースで再設計する抜本的改革、 BPM は継続的に改善する管理手法。ソリューションビジネスでは SoR (記録系)と SoE (つながり系)の区別、 SOA のサービス指向を押さえる。クラウドは IaaS (インフラ)・ PaaS (プラットフォーム)・ SaaS (ソフト)の責任分界を理解する。システム化計画では TCO (総保有コスト)で運用費まで含めた評価が重要。
用語
システム化計画が定まったら、次は具体的にシステムを企画し、開発を担うベンダー(IT 事業者)を選定・調達するフェーズに入ります。たとえば、ある製造業の企業が「生産管理システムを刷新したい」と決めた場合、まずユーザー部門の要望を整理し(要件定義)、複数の IT ベンダーに提案を依頼し(RFP)、最適なベンダーを選定して契約します。
このセクションでは、 要件定義 の進め方、ベンダー選定に使う RFI・RFP 、 調達計画 と 提案評価 の手法、そしてサービス品質を担保する SLA までを学びます。
要件定義 とは、システムに求められる機能や性能を明確にするプロセスです。開発の最上流工程であり、ここでの認識のずれは後工程で大きな手戻りを生むため、最も重要な工程の一つです。
| 種類 | 説明 | 例 |
|---|---|---|
| 業務要件 | システム化の対象となる業務の内容・ルール | 「注文は翌営業日までに出荷する」 |
| 機能要件 | システムが実現すべき機能 | 「在庫数が基準値を下回ったら自動発注する」 |
| 非機能要件 | 性能・信頼性・セキュリティ等の品質要件 | 「応答時間3秒以内」「稼働率99.9%以上」 |
| 項目 | 内容 |
|---|---|
| 性能要件 | レスポンスタイム、スループット |
| 信頼性要件 | 稼働率、障害復旧時間 |
| 拡張性要件 | 将来のデータ量増加やユーザー数増加への対応 |
| セキュリティ要件 | 認証方式、暗号化、アクセス制御 |
| 移行要件 | 既存システムからのデータ移行方法 |
| 運用・保守要件 | バックアップ方針、監視体制、障害対応手順 |
非機能要件は「当たり前品質」とも言われ、ユーザーが明示的に言語化しにくい要件です。開発側がヒアリングでうまく引き出すことが求められます。
要件定義ではユーザー部門と開発部門の認識を合わせるために、さまざまな手法が使われます。
| 手法 | 説明 |
|---|---|
| ヒアリング(インタビュー) | ユーザーに直接話を聞いて要件を引き出す |
| ブレーンストーミング | 複数の関係者でアイデアを自由に出し合う |
| プロトタイピング | 試作品(プロトタイプ)を作成し、ユーザーの反応を見ながら要件を確認する |
| ユースケース分析 | システムの利用場面(ユースケース)を洗い出し、アクターとシステムのやりとりを記述する |
上の図のように、システム企画は経営戦略から始まり、要件定義を経て調達へと進みます。各工程が前工程の成果物に依存するため、上流での品質確保が極めて重要です。
ベンダー選定のプロセスでは、 RFI と RFP という2つの文書が登場します。
ベンダーに対して、技術動向・製品情報・事例などの 情報提供を依頼 する文書です。RFP を作成する前段階で、市場調査や候補ベンダーの絞り込みに使います。
ベンダーに対して、システムの要件・制約条件・評価基準などを示し、 具体的な提案を依頼 する文書です。
RFP に含まれる主な項目:
| 項目 | 内容 |
|---|---|
| システム概要 | 目的、対象業務、利用者数 |
| 要件 | 機能要件、非機能要件 |
| 制約条件 | 予算、スケジュール、技術的制約 |
| 提案に含めてほしい事項 | 開発体制、スケジュール、費用見積 |
| 評価基準 | 提案を評価するための基準(配点等) |
| 契約条件 | 契約形態、知的財産の帰属 |
RFI → RFP の順序 で進める点が試験で問われます。RFI で情報収集してから RFP で具体的な提案を求めるという流れです。
調達計画では、 何を、いつ、どのように調達するか を計画します。
| 項目 | 説明 |
|---|---|
| 調達対象 | ハードウェア、ソフトウェア、開発サービス、運用サービスなど |
| 調達方式 | 一括調達か分割調達か。自社開発か外部委託か |
| 調達スケジュール | RFP 発行から契約締結までのタイムライン |
| 選定基準 | 技術力、価格、実績、信頼性などの評価基準と配点 |
ベンダーからの提案書を公正に評価するために、定量的な評価手法を用います。
| 手法 | 説明 |
|---|---|
| 総合評価落札方式 | 価格と技術の両面を総合的に評価して選定する |
| 加点方式 | 評価項目ごとに点数をつけ、合計点で比較する |
| 除外方式 | 最低基準を満たさない提案を除外してから評価する |
| 評価項目 | 配点 | A社 | B社 | C社 |
|---|---|---|---|---|
| 技術力 | 30 | 25 | 28 | 22 |
| 価格 | 25 | 20 | 18 | 25 |
| 実績 | 20 | 18 | 15 | 12 |
| 保守体制 | 15 | 12 | 14 | 10 |
| プロジェクト管理 | 10 | 8 | 9 | 7 |
| 合計 | 100 | 83 | 84 | 76 |
この例では B 社が最高得点で選定されます。価格だけでなく総合力で判断する点がポイントです。
SLA とは、サービスの提供者と利用者の間で、サービスの品質水準を具体的な数値で合意する文書です。「このレベルのサービスを保証します」という約束を明文化したものです。
| 指標 | 内容 | 例 |
|---|---|---|
| 可用性 | サービスが利用可能な時間の割合 | 稼働率 99.9% 以上 |
| 応答時間 | リクエストに対する応答にかかる時間 | 平均応答時間 3 秒以内 |
| 障害復旧時間 | 障害発生から復旧までの時間 | 4 時間以内に復旧 |
| サポート対応時間 | 問い合わせへの対応可能時間帯 | 24 時間 365 日対応 |
| データバックアップ | バックアップの頻度と保存期間 | 日次バックアップ、30 日間保持 |
SLA はクラウドサービスの契約でも重要です。たとえば AWS は EC2 に対して月間稼働率 99.99% の SLA を提示しています。SLA を理解しておくことで、ベンダーのサービス品質を客観的に比較・評価できます。
システム開発の契約は、大きく2種類に分かれます。
| 契約形態 | 説明 | リスク負担 |
|---|---|---|
| 請負契約 | 成果物の完成を約束する。完成責任はベンダーが負う | ベンダー側が大きい |
| 準委任契約 | 業務の遂行を約束する。成果物の完成義務はない | 発注者側が大きい |
一般的に、要件定義は準委任契約、設計・開発は請負契約とする 多段階契約 が推奨されています。
ポイント
要件定義では 機能要件 と 非機能要件 (性能・信頼性・セキュリティ等)を明確にする。ベンダー選定は RFI (情報提供依頼)→ RFP (提案依頼)の順で進める。提案評価は技術力・価格・実績などを 加点方式 で総合評価する。 SLA はサービスの品質水準(稼働率・応答時間等)を数値で合意する文書。契約形態は 請負契約 (成果物の完成責任あり)と 準委任契約 (業務遂行義務のみ)の2種類を区別し、工程に応じて使い分ける。
用語