システム戦略と企画

情報システム戦略 とは、企業の経営戦略を実現するために、ITをどのように活用するかを計画することです。経営目標の達成に向けて、どのシステムに投資し、どのような優先順位で構築するかを決定します。

その基盤となる考え方が EA（Enterprise Architecture：エンタープライズアーキテクチャ） です。EAは、組織全体の業務とシステムの構造を4つの層で整理・最適化するフレームワークです。

層	名称	内容
第1層	ビジネスアーキテクチャ（BA）	業務プロセスや組織構造の定義
第2層	データアーキテクチャ（DA）	データの構造・関連・管理方針の定義
第3層	アプリケーションアーキテクチャ（AA）	業務を支援するアプリケーションの構成
第4層	テクノロジアーキテクチャ（TA）	ハードウェア・ネットワーク等の技術基盤

なぜこの順序なのでしょうか。まずビジネスの目的（BA）が「何を実現したいか」を決め、それに必要なデータ（DA）が定まり、そのデータを扱うアプリケーション（AA）が設計され、最後にそれを動かす技術基盤（TA）が選定されます。つまり 上位の層が下位の層を決定する という関係です。技術ありきではなく、ビジネスの目的から出発する点がEAの本質です。

情報システム戦略を策定する際に重要な概念を整理します。

情報化計画 は、経営戦略に基づいてITシステムの導入・更新を具体的にスケジュール化したものです。現状の分析（As-Is）から理想の姿（To-Be）を描き、ギャップを埋めるための計画を立てます。

近年の情報システムは、SoR（System of Record） と SoE（System of Engagement） の2つに大別されます。SoR は会計・在庫管理などの基幹系システムで、データの正確性と安定稼働が最優先です。SoE は顧客向けアプリやSNS連携など顧客接点のシステムで、市場変化への素早い対応が求められます。この2つを両立させる考え方を バイモーダルIT と呼び、SoR は堅牢な開発手法（ウォーターフォール）、SoE は俊敏な開発手法（アジャイル）で進めるのが一般的です。

IT投資評価 は、情報システムへの投資がどれだけの効果を生むかを評価する取り組みです。

評価指標	説明
ROI（投資利益率）	投資に対する利益の割合。(利益 ÷ 投資額) × 100
TCO（総所有コスト）	システムの導入から運用・廃棄までにかかる総費用
NPV（正味現在価値）	将来のキャッシュフローを現在価値に割り引いた合計

実務では、まず TCO で総コストを把握 し、次に ROI で投資対効果を評価 して投資判断を行います。例えば、TCO が5年間で3,000万円のシステムが年間1,000万円の業務効率化をもたらすなら、ROI = (5,000万 − 3,000万) ÷ 3,000万 × 100 = 約67% と計算できます。

TCO（Total Cost of Ownership：総所有コスト） は、システムの購入費用だけでなく、運用・保守・教育・廃棄までの総費用を把握するための概念です。

• イニシャルコスト（初期費用） — ハードウェア・ソフトウェア購入、導入作業、初期教育
• ランニングコスト（運用費用） — 保守契約、ライセンス更新、電気代、人件費

ITガバナンス は、経営者がITの活用を組織的に管理・統制する仕組みです。IT戦略が経営戦略に沿っているか、IT投資が適切に行われているか、リスクが管理されているかを監督します。ITガバナンスは、コーポレートガバナンス（企業統治）の一部として位置づけられます。

業務の効率化や品質向上のために、さまざまな改善手法と分析ツールが活用されます。

BPR（Business Process Reengineering：ビジネスプロセスリエンジニアリング） は、既存の業務プロセスを根本的に見直し、劇的な改善を図る手法です。部分的な改善ではなく、業務のあり方そのものをゼロベースで再設計する点が特徴です。

BPM（Business Process Management：ビジネスプロセスマネジメント） は、業務プロセスを継続的にモニタリング・分析し、PDCAサイクルで改善を繰り返す手法です。BPRが「抜本的な改革」であるのに対し、BPMは「継続的な改善」に重点を置きます。

どちらを選ぶかの判断基準は明確です。現状のプロセスが根本的に非効率（例: 紙ベースの申請を全てデジタル化する）な場合は BPR で抜本改革します。すでにある程度合理的だが改善の余地がある（例: 承認ステップを1段階減らす）場合は BPM で継続的に改善します。BPR はリスクが大きい反面、成功すれば劇的な効果が得られます。

手法	特徴	アプローチ
BPR	業務プロセスの抜本的な再設計	ゼロベースで再構築
BPM	業務プロセスの継続的な改善	PDCAサイクルで段階的に改善

業務を分析・設計するためのモデリング手法を理解することが重要です。

業務フロー図 は、業務の手順を図式化したものです。誰が（役割）、何を（作業）、どの順番で行うかを可視化し、非効率な手順やボトルネックを発見するために使います。

DFD（Data Flow Diagram：データフロー図） は、データの流れに着目してシステムの処理を図式化する手法です。4つの基本記号で構成されます。

記号	名称	意味
○（円）	プロセス	データを処理・変換する機能
→（矢印）	データフロー	データの流れ
＝（二重線）	データストア	データの保管場所（DB、ファイル）
□（四角）	外部エンティティ	システム外部のデータの発生源・送信先

なぜこの4つの記号だけで十分なのでしょうか。データフローを表現するには「データがどこから来るか（外部エンティティ）」「どう加工されるか（プロセス）」「どこに保管されるか（データストア）」「どう流れるか（データフロー）」の4要素があれば、システムのデータの流れを完全に表現できるためです。シンプルだからこそ、業務部門の人にも理解しやすい図になります。

E-R図（Entity Relationship Diagram） は、データベース設計で使われる図で、データ間の関係性を表現します。

• エンティティ（実体） — 管理対象のデータ（顧客、商品、注文 など）
• リレーションシップ（関連） — エンティティ間の関係（1対1、1対多、多対多）
• アトリビュート（属性） — エンティティが持つ項目（氏名、価格、日付 など）

UML（Unified Modeling Language：統一モデリング言語） は、システムの設計をさまざまな視点から図式化するための標準的な表記法です。ITパスポート試験では、以下の図を理解しておく必要があります。

UMLの図	用途
ユースケース図	システムの機能と利用者の関係を表す
クラス図	データの構造と関連を表す
シーケンス図	オブジェクト間のやり取りの時間順序を表す
アクティビティ図	処理の流れを表す（業務フローに近い）
状態遷移図（ステートマシン図）	オブジェクトの状態変化を表す

状態遷移図 は試験でも出題される重要な図です。例えば、ECサイトの注文は「受付 → 処理中 → 発送済 → 完了」、「受付 → キャンセル」のように状態が変化します。各状態とその間の遷移（イベント）を図にすることで、システムの振る舞いを明確にできます。

要件定義 は、システム開発の最上流工程であり、「何を作るか」を明確にするプロセスです。ユーザーの業務上の課題やニーズを整理し、システムが実現すべき機能や性能を文書化します。

要件定義が不十分なままシステム開発を進めると、完成後に「想定と違う」「必要な機能がない」といった問題が生じ、手戻りが発生します。要件定義の品質がプロジェクト全体の成功を左右すると言われています。

要件は大きく2つに分類されます。

分類	内容	具体例
機能要件	システムが実現すべき機能	商品検索機能、カート機能、決済処理
非機能要件	性能・信頼性・運用条件など	レスポンス3秒以内、稼働率99.9%、24時間運用

非機能要件は以下のカテゴリに分類されます。

カテゴリ	説明	例
性能要件	応答速度、処理能力	画面表示3秒以内、同時接続1000人対応
信頼性要件	障害への耐性、復旧	稼働率99.9%、RTO4時間以内
セキュリティ要件	安全性の確保	通信の暗号化、アクセス権限管理
拡張性要件	将来の拡張への対応	ユーザー数10倍まで対応可能な設計
移行性要件	既存システムからの移行	データ移行期間1週間以内、並行稼働期間の設定
運用・保守要件	日常の運用と保守	バックアップは毎日実施、監視は24時間体制

「画面表示3秒以内」という性能要件には根拠があります。Webサイトでは3秒以上待つと約40%のユーザーが離脱するという調査結果があり、この数値がUX設計のベースラインとして広く使われています。

機能要件は「何ができるか」を定義し、非機能要件は「どの程度のレベルで動くか」を定義します。非機能要件は見落とされがちですが、システムの品質を大きく左右する重要な要件です。

要件定義のプロセスでは、ユーザーの要求を正確に引き出し、整理・合意するためにさまざまな手法が使われます。

• ヒアリング（インタビュー） — ユーザーに直接質問して要望を聞き出す
• ワークショップ — 関係者が集まってディスカッションし、要件を洗い出す
• プロトタイピング — 試作品（プロトタイプ）を作り、ユーザーに操作してもらってフィードバックを得る。認識のズレを早期に発見できる
• ユーザーストーリー — 「○○として、△△したい。なぜなら□□だから」の形式で要件を記述する。アジャイル開発でよく使われる

手法	メリット	適する場面
ヒアリング	詳細な要望を聞ける	業務の深い理解が必要な場合
プロトタイピング	認識のズレを早期発見	UIが重要なシステム
ユーザーストーリー	利用者視点で要件を記述	アジャイル開発

システム開発を外部に委託する場合、適切な調達プロセスを経て発注先を選定します。調達プロセスでは、RFI → RFP → RFQ という3段階の文書を使って情報収集から契約に至ります。

なぜこの順序なのでしょうか。まず RFI で広くベンダーの情報を収集して候補を絞り込み、次に RFP で具体的な要件を提示して技術的な提案を求め、最後に RFQ で費用の見積もりを取得します。段階的に絞り込むことで、技術力が不十分なベンダーに見積もりを依頼する無駄を省き、適切なベンダー選定が可能になります。

文書	正式名称	目的
RFI	Request for Information（情報提供依頼書）	ベンダーの技術力・実績などの情報を収集する
RFP	Request for Proposal（提案依頼書）	具体的な要件を提示し、提案書の提出を依頼する
RFQ	Request for Quotation（見積依頼書）	提案内容に対する費用の見積もりを依頼する

RFPに対してベンダーから提出された提案書は、あらかじめ定めた 評価基準 に基づいて評価します。

評価項目	評価の観点
技術力	提案内容の実現可能性、技術的な優位性
実績	類似プロジェクトの経験、導入事例
費用	総コストの妥当性、コストパフォーマンス
体制	プロジェクトマネージャの経験、要員の質と量
スケジュール	納期の妥当性、マイルストーンの設定

評価方法としては、各項目に点数をつけて合計する 総合評価方式 が一般的です。

システム開発の契約形態には主に3種類あります。それぞれの特徴を正確に理解しましょう。

契約形態	完成責任	指揮命令	特徴
請負契約	ベンダーが負う	ベンダー側	成果物の完成を約束。納品後に瑕疵（不具合）があれば修補義務
委任契約（準委任）	負わない	ベンダー側	業務の遂行を約束。成果物ではなく作業に対して報酬
派遣契約	負わない	発注者側	発注者の指揮命令下で業務を遂行

• 請負契約 は成果物に責任を持つため、要件が明確な場合に適する
• 準委任契約 は作業に対する契約で、コンサルティングや運用保守によく使われる
• 派遣契約 は発注者が直接指示を出せるが、長期的な依存にはリスクがある

請負と準委任の大きな違いは 瑕疵（不具合）への対応 です。請負契約では、納品物に不具合が見つかった場合、ベンダーに修正義務（契約不適合責任）があります。一方、準委任契約では、ベンダーは 善管注意義務（専門家として当然払うべき注意）を果たしていれば、たとえ結果が期待通りでなくても責任を負いません。この違いから、要件が明確で成果物を確実に得たい場合は請負、要件が不明確で試行錯誤が必要な場合は準委任が適しています。

注意すべき問題として 偽装請負 があります。これは、形式上は請負契約だが、実態として発注者が直接指揮命令を行っているケースです。労働者派遣法に違反する違法行為です。

SLA（Service Level Agreement：サービスレベル合意書） は、サービスの品質水準を発注者とベンダーの間で取り決める文書です。

SLAの項目例	内容
可用性	システムの稼働率（例: 99.9%以上）
応答時間	サービスの応答速度（例: 3秒以内）
障害対応	障害発生時の初動対応時間（例: 30分以内に連絡）
データ保護	バックアップ頻度、データ保持期間

稼働率の数値を具体的に理解しましょう。年間の総時間は 365日 × 24時間 = 8,760時間です。稼働率 99.9% の場合、許容されるダウンタイムは 8,760 × 0.001 = 約8.76時間/年（月あたり約44分）です。99.99% なら約52分/年、99.999%（ファイブナイン）なら約5分/年となります。「9」が1つ増えるだけで要求される信頼性が桁違いに高くなり、コストも大幅に増加します。

SLAを定めることで、サービス品質に対する期待値を明確にし、トラブル時の責任範囲を事前に合意できます。

ベンダー管理 は、外部委託先であるベンダーとの関係を適切に管理する活動です。進捗管理、品質管理、リスク管理を通じて、プロジェクトの成功を確保します。複数のベンダーに分割発注する場合は、ベンダー間の調整も重要になります。