Skip to content
Published on

IT事業企画と提案書作成 完全ガイド：RFP分析・ISMP・WBS・コスト算定・SLAまで

🇰🇷KO🇺🇸EN🇯🇵JA
Split View✨Start Quiz
Authors
  • Name
    Twitter

IT事業企画と提案書作成

はじめに

IT事業は単にシステムを開発することではなく、組織の戦略的目標を技術で実現する総合的な活動である。成功するIT事業のためには、事業企画段階から提案書作成、プロジェクト遂行、そしてサービス運用まで体系的なアプローチが必要だ。

韓国のIT事業環境は、公共と民間の領域で異なる特性を示す。公共IT事業は調達庁ナラジャンター（電子調達システム）を通じた入札手続き、ソフトウェア振興法に基づく事業対価算定基準、そして国家情報化基本法に根拠した情報化戦略計画（ISMP）策定義務など、厳格な規定が適用される。民間IT事業は比較的柔軟だが、費用対効果（ROI）を明確に証明するビジネスロジックがより重要となる。

この記事では、IT事業の種類とライフサイクルを出発点に、RFP分析戦略、ISMP方法論、提案書作成の核心技法、プロジェクト計画策定、コスト算定とROI分析、SLA管理、そして実際の成功事例まで、IT事業企画の全プロセスを実務の観点から体系的に解説する。

IT事業の種類とライフサイクル

IT事業の主要種類

IT事業は遂行目的と方式によって、大きく以下のように分類される。

種類説明主な特徴
SI（System Integration）新規情報システムの分析、設計、開発、構築明確な開始と終了、成果物中心
SM（System Management）構築済みシステムの運用・保守年単位契約、SLAベース管理
コンサルティングIT戦略策定、診断、改善方案導出知識ベースサービス、報告書成果物
SaaS導入クラウドベースソフトウェアサービスの導入サブスクリプションモデル、カスタマイズ範囲制限
クラウド移行オンプレミスからクラウドへのマイグレーションインフラ再設計、リファクタリング必要
データ分析ビッグデータ、AI/MLベース分析システム構築データ品質が成否を左右

IT事業のライフサイクル

IT事業は企画から廃棄まで明確なライフサイクルを経る。

事業企画 → 予算確保 → RFP作成 → 入札/提案 → 評価/選定 → 着手 → 遂行 → 検収/終了 → 運用/保守

各段階の主要活動は以下の通りである。

第1段階：事業企画

  • 現行システム分析（As-Is）および目標システム定義（To-Be）
  • 事業タイムリー性分析（技術的、経済的、運用的実現可能性）
  • ステークホルダー識別および要求事項収集
  • 事業範囲および推進戦略策定

第2段階：予算確保と調達

  • 事業対価算定（SW事業対価算定ガイド基準）
  • 予算要求書作成および承認
  • 調達方式決定（一般競争、制限競争、随意契約）

第3段階：提案と選定

  • RFP作成および公告
  • 事前説明会（Pre-bid Conference）開催
  • 提案書受付および技術/価格評価
  • 優先交渉対象者選定および契約締結

第4段階：事業遂行

  • 着手報告、中間報告、最終報告
  • 段階別成果物レビューおよび品質管理
  • 変更管理（Change Management）プロセス運用
  • PMOによるガバナンス管理

公共IT事業と民間IT事業の違い

# 公共IT事業の特徴
規制環境:
  - 国家情報化基本法
  - ソフトウェア振興法
  - 電子政府法
  - 調達庁契約規定

対価算定:
  基準: SW事業対価算定ガイド（科学技術情報通信部）
  方式:
    - ファンクションポイント（FP）方式
    - 投入工数（Man/Month）方式

入札方式:
  - 一般競争入札（基本）
  - 制限競争入札（資格制限）
  - 交渉による契約（技術中心評価）

# 民間IT事業の特徴
意思決定:
  - C-Level承認中心
  - ビジネスケース（ROI）ベース
  - ベンダー関係およびリファレンス重視

契約方式:
  - 定額（Fixed Price）
  - 実費精算（Time and Material）
  - 成果ベース（Outcome-based）

RFP分析と対応戦略

RFPの構造理解

RFP（提案依頼書）は、発注機関がIT事業の目的、範囲、要求事項、評価基準などを整理して提案者に伝達する核心文書である。適切に作成されたRFPを正確に分析することが、提案成功の第一歩だ。

RFP一般構造：

1. 事業概要
   - 事業背景および目的
   - 事業範囲
   - 推進日程
   - 事業予算

2. 現行システム現況
   - インフラ構成図
   - アプリケーションシステム現況
   - データ現況

3. 要求事項
   - 機能要求事項（FR）
   - 非機能要求事項（NFR）
   - データ要求事項
   - インターフェース要求事項
   - セキュリティ要求事項

4. 提案要件
   - 技術部門（システム構成、アーキテクチャ）
   - 管理部門（方法論、組織、日程）
   - 支援部門（教育、保守、技術移転）

5. 提案書評価基準
   - 技術評価項目および配点
   - 価格評価方式
   - プレゼンテーション評価

6. 提案案内
   - 提出日程および方法
   - 提案書作成規格
   - 問い合わせ先

RFP分析チェックリスト

RFPを受領したら、以下の項目を体系的に分析する必要がある。

分析領域核心確認事項分析目的
事業背景発注動機、上位計画との連携顧客の真のニーズ把握
事業範囲含む/除外範囲の明確性リスクおよび追加コスト予測
要求事項機能/非機能要求の具体性レベル提案方向および差別化ポイント
評価基準配点構造、加点/減点項目提案書の力点集中領域
日程事業期間の現実性投入人員および工数算定
予算事業費の妥当性Go/No-Go意思決定
技術環境指定プラットフォーム、既存システム連携技術アーキテクチャ設計方向

Go/No-Go意思決定フレームワーク

すべてのRFPに提案するのは非効率的である。体系的なGo/No-Go分析が必要だ。

Go/No-Go評価マトリクス（100点満点）

戦略的適合性（25点）
  - 会社事業戦略との一致度          0-10点
  - リファレンス確保価値            0-8点
  - 長期関係構築可能性              0-7点

競争力（25点）
  - 類似事業遂行経験               0-10点
  - コア技術保有有無               0-8点
  - 専門人材確保可能性              0-7点

収益性（25点）
  - 予算対比収益率見通し            0-10点
  - 追加事業連携可能性              0-8点
  - 投入リソース対比効率性          0-7点

リスク（25点）
  - 技術的難易度                   0-10点
  - 日程の現実性                   0-8点
  - 発注者協力水準見通し            0-7点

判定基準：
  80点以上：Go（積極参加）
  60-79点：Conditional Go（条件付き参加）
  60点未満：No-Go（不参加）

RFP質疑応答戦略

事前説明会と質疑応答は、RFPの曖昧な部分を明確にし、競合他社に対する優位性を確保する重要な機会である。

効果的な質問戦略：

  • 核心技術要件の解釈範囲を確認する質問
  • 発注者が最も重視する価値を間接的に把握する質問
  • 現行システムの運用現況と課題を確認する質問
  • 既存の類似事業との差別性を確認する質問

注意すべき点：

  • 自社の提案方向を露出する質問は避ける
  • 競合他社にも有益な汎用的質問は最小化する
  • 核心的で具体的な質問で発注者の信頼を獲得する

ISMPと情報化戦略

ISMPの概念と目的

ISMP（情報化戦略計画、Information Strategy Master Plan）は、組織の中長期情報化ビジョンと戦略を策定し、これを実現するための段階的な実行ロードマップを導出する体系的な計画策定活動である。

韓国の公共部門では、大規模IT事業（一定規模以上）を推進する前にISMP策定が義務化されており、これを通じて事業の妥当性と推進方向を事前に検証する。

ISMP策定手順

Phase 1：環境分析（全体期間の約25%）
  +-- 経営環境分析
  |   +-- 組織戦略およびビジョン分析
  |   +-- 業務プロセス分析（BPR）
  |   +-- ステークホルダーインタビュー
  +-- 情報化現況分析
  |   +-- 現行システムアーキテクチャ分析
  |   +-- 情報資源現況分析
  |   +-- 情報化成熟度評価
  +-- ベンチマーキング
      +-- 同業界事例分析
      +-- 先進技術トレンド調査

Phase 2：将来モデル策定（全体期間の約35%）
  +-- 目標アーキテクチャ設計
  |   +-- ビジネスアーキテクチャ（BA）
  |   +-- データアーキテクチャ（DA）
  |   +-- アプリケーションアーキテクチャ（AA）
  |   +-- テクノロジーアーキテクチャ（TA）
  +-- ギャップ分析（As-Is vs To-Be）
  +-- 情報化課題導出

Phase 3：実行計画策定（全体期間の約40%）
  +-- 課題優先順位評価
  |   +-- 戦略的重要度
  |   +-- 緊急性
  |   +-- 技術的実現可能性
  |   +-- 課題間の先行・後行関係
  +-- 段階別推進ロードマップ
  |   +-- 短期（1年以内）
  |   +-- 中期（1-3年）
  |   +-- 長期（3-5年）
  +-- 投資所要予算算定
  +-- 推進体制設計

情報化アーキテクチャ（EA）フレームワーク

ISMPで目標アーキテクチャを設計する際は、EA（Enterprise Architecture）フレームワークを活用する。

アーキテクチャ領域主要内容成果物
ビジネスアーキテクチャ（BA）業務プロセス、組織構造、機能分類業務機能分解図、プロセスマップ
データアーキテクチャ（DA）データモデル、データフロー、データ標準概念/論理データモデル、データフロー図
アプリケーションアーキテクチャ（AA）アプリケーションシステム構成、システム間連携、機能配置アプリケーション構成図、インターフェース定義書
テクノロジーアーキテクチャ（TA）インフラ、ネットワーク、セキュリティ、プラットフォーム技術スタックインフラ構成図、技術標準定義書

ISMP成功要因

核心的成功要因：

  1. 経営層の積極的な参加と支援（Executive Sponsorship）
  2. 現業部門との緊密な協力および意見収集
  3. 現実的で実行可能な課題導出
  4. 既存の情報化資産の活用度を考慮した段階的移行戦略
  5. 明確な成果指標（KPI）設定と追跡体制

よくある失敗原因：

  • 経営戦略と乖離した技術中心の計画
  • 現業の参加なく外部コンサルタント主導で策定
  • 過度な目標設定（Big Bangアプローチ）
  • 予算確保なきロードマップ策定
  • 策定後の実行管理体制の不在

提案書作成の核心戦略

提案書の構成体系

提案書は大きく技術提案、管理提案、価格提案の3つの領域で構成される。各領域でRFPの評価基準に合わせて戦略的に内容を構成する必要がある。

提案書標準目次構造：

第1編 技術部門
  第1章 事業理解
    1.1 事業背景および環境分析
    1.2 現行システム分析
    1.3 核心課題導出
  第2章 提案システム
    2.1 システムアーキテクチャ
    2.2 機能設計
    2.3 データ設計
    2.4 インターフェース設計
    2.5 セキュリティ設計
  第3章 開発方案
    3.1 開発方法論
    3.2 段階別遂行方案
    3.3 品質管理方案

第2編 管理部門
  第1章 プロジェクト管理
    1.1 プロジェクト推進体制
    1.2 プロジェクト管理方案（範囲、日程、品質、リスク）
    1.3 コミュニケーション管理
    1.4 変更管理
  第2章 投入人員
    2.1 投入組織図
    2.2 核心人材の能力
    2.3 人員投入計画
  第3章 事業遂行日程
    3.1 マスタースケジュール
    3.2 段階別詳細日程

第3編 支援部門
  第1章 教育および技術移転
  第2章 瑕疵担保および保守
  第3章 類似事業遂行実績

技術提案作成戦略

技術提案は提案書の核心であり、発注者の問題をどのように解決するかを技術的に証明する領域である。

アーキテクチャ設計原則：

原則説明適用事例
拡張性（Scalability）ユーザー/データ増加に柔軟に対応マイクロサービスアーキテクチャ、オートスケーリング
可用性（Availability）障害時にもサービス継続性を保証二重化、フェイルオーバー、DR構成
セキュリティ（Security）データ保護およびアクセス制御暗号化、認証/認可、ネットワーク分離
互換性（Interoperability）既存システムとの円滑な連携標準API、ESB、メッセージキュー
保守性（Maintainability）変更と改善が容易な構造モジュール化、クリーンアーキテクチャ、CI/CD

差別化戦略：

  • 顧客の隠れたニーズ（Hidden Needs）を発掘して反映
  • 業界トレンドと革新技術を組み合わせた未来志向型アーキテクチャ提示
  • 類似プロジェクト遂行経験から導出したベストプラクティス提示
  • 具体的なPoC（Proof of Concept）結果やプロトタイプのデモンストレーション

管理提案作成戦略

管理提案は、プロジェクトを成功裏に遂行できる管理能力を証明する領域である。

# プロジェクト推進体制例
推進組織:
  発注者:
    役割: 事業総括、要求事項確定、検収
    構成:
      - 事業責任者（PO）
      - 現業担当者
      - 情報化担当者

  受注者:
    役割: システム分析/設計/開発/テスト
    構成:
      PM:
        役割: プロジェクト総括管理
        資格: PMP又は類似事業PM経歴10年以上
      PL:
        役割: 技術リーダーシップ、アーキテクチャ設計
        資格: 該当技術分野専門家
      開発チーム:
        役割: 設計/開発/単体テスト
      QAチーム:
        役割: 結合テスト、性能テスト、品質管理
      DBA:
        役割: データモデリング、DBチューニング

  PMO:
    役割: 事業監理、品質監督
    構成:
      - 監理員
      - 品質管理専門家

価格提案戦略

価格提案は、技術力を合理的なコストで提供できることを証明する領域である。公共事業では対価算定基準に基づいて透明に算出する必要があり、民間事業では競争力のある価格と価値提案のバランスが重要だ。

価格構成要素算定基準比重（SI基準）
直接人件費等級別日額単価 x 投入工数約60-70%
直接経費機器、ソフトウェア、出張、教育約10-15%
諸経費直接人件費の110-120%含む計算
技術料（直接人件費+諸経費）の20-40%含む計算
一般管理費直接人件費の一定割合含む計算
利潤総原価の一定割合以内約10-15%

プロジェクト計画策定

WBS（作業分解構造）の作成

WBSはプロジェクトの全体範囲を管理可能な単位（Work Package）に階層的に分解する基本ツールである。効果的なWBS作成がプロジェクト成功の基盤となる。

WBS構造例（次世代システム構築事業）

1.0 プロジェクト管理
    1.1 着手段階
        1.1.1 着手報告書作成
        1.1.2 着手報告会
        1.1.3 プロジェクト計画書策定
    1.2 実行管理
        1.2.1 週次報告
        1.2.2 月次報告
        1.2.3 課題/リスク管理
    1.3 終了段階
        1.3.1 最終報告書作成
        1.3.2 最終報告会
        1.3.3 成果物引渡し

2.0 分析
    2.1 現行システム分析
        2.1.1 業務プロセス分析
        2.1.2 データ現況分析
        2.1.3 インターフェース現況分析
    2.2 要求事項分析
        2.2.1 要求事項収集
        2.2.2 要求事項定義書作成
        2.2.3 要求事項レビューおよび確定
    2.3 分析報告
        2.3.1 分析報告書作成
        2.3.2 分析段階レビュー会

3.0 設計
    3.1 アーキテクチャ設計
    3.2 UI/UX設計
    3.3 データベース設計
    3.4 インターフェース設計
    3.5 設計報告

4.0 実装
    4.1 開発環境構築
    4.2 共通モジュール開発
    4.3 業務別機能開発
    4.4 インターフェース開発
    4.5 データ移行開発

5.0 テスト
    5.1 単体テスト
    5.2 結合テスト
    5.3 システムテスト
    5.4 性能テスト
    5.5 ユーザー受入テスト（UAT）

6.0 移行
    6.1 移行計画策定
    6.2 データ移行
    6.3 システム切替
    6.4 安定化運用

スケジュール計画

WBSを基に、各作業の所要期間、先行・後行関係、リソース割当を考慮して詳細スケジュールを策定する。

技法説明活用場面
CPM（Critical Path Method）最長経路を識別して最短事業期間を算定全体スケジュール最適化
PERT（Program Evaluation and Review Technique）楽観/悲観/最頻3点見積もりで不確実性を反映不確実性の高い作業
ガントチャート（Gantt Chart）作業別の開始/終了日程を棒グラフで可視化スケジュール状況報告
マイルストーン（Milestone）主要チェックポイントの定義進捗管理基準点

リソース割当計画

# 人員投入計画例（12ヶ月SIプロジェクト）
投入人員計画:
  分析段階: # 1-3ヶ月
    PM: 1名 (100%)
    PL: 1名 (100%)
    アナリスト: 3名 (100%)
    DBA: 1名 (50%)
    合計: 約5.5人月/月

  設計段階: # 3-5ヶ月
    PM: 1名 (100%)
    PL: 1名 (100%)
    設計者: 4名 (100%)
    DBA: 1名 (100%)
    UI設計者: 1名 (100%)
    合計: 約8人月/月

  実装段階: # 5-10ヶ月
    PM: 1名 (100%)
    PL: 1名 (100%)
    開発者: 8名 (100%)
    DBA: 1名 (100%)
    QA: 2名 (50%)
    合計: 約12人月/月

  テスト_移行: # 10-12ヶ月
    PM: 1名 (100%)
    PL: 1名 (100%)
    開発者: 6名 (80%)
    DBA: 1名 (100%)
    QA: 3名 (100%)
    合計: 約10.8人月/月

リスク管理

プロジェクトリスクは事前に識別し、対応戦略を策定しなければならない。

リスク種類事例対応戦略
スコープクリープ（Scope Creep）顧客の追加要求事項頻発変更管理プロセス厳格適用、要求事項凍結時点の明確化
人員離脱コア開発者の退職知識共有体制、バックアップ人員確保、文書化強化
技術リスク新技術適用失敗PoC事前実施、技術検証段階の包含
スケジュール遅延先行作業遅延の累積クリティカルパス集中管理、バッファ確保
品質リスクテストカバレッジ不足テスト自動化導入、品質ゲート設定
外部依存性外部システム連携遅延インターフェース事前協議、モック開発

コスト算定とROI分析

ファンクションポイント（Function Point）方式

ファンクションポイント方式は、ソフトウェアの機能的サイズを測定して開発コストを算定する国際標準（ISO/IEC 20926）の方法である。韓国の公共IT事業で最も広く使用される対価算定方式だ。

ファンクションポイント算定手順：

1. 機能タイプ識別
   - 内部論理ファイル（ILF: Internal Logical File）
   - 外部連携ファイル（EIF: External Interface File）
   - 外部入力（EI: External Input）
   - 外部出力（EO: External Output）
   - 外部照会（EQ: External Inquiry）

2. 機能複雑度評価
   - 単純（Low）、普通（Average）、複雑（High）
   - DET（データ要素タイプ）とRET/FTR基準適用

3. 未調整ファンクションポイント計算
   - 各機能タイプ別の複雑度に応じた加重値適用

   機能タイプ別加重値：
   ILF：単純=7、普通=10、複雑=15
   EIF：単純=5、普通=7、複雑=10
   EI： 単純=3、普通=4、複雑=6
   EO： 単純=4、普通=5、複雑=7
   EQ： 単純=3、普通=4、複雑=6

4. 補正係数適用
   - 規模補正、アプリケーションタイプ補正、言語補正など

5. 最終開発費算定
   ファンクションポイント当たり単価 x 補正済みファンクションポイント = 開発原価

投入工数（Man/Month）方式

# 投入工数ベースコスト算定例
人件費算定:
  等級別月額単価: # 2026年基準（仮想）
    技術士: 月額 12,500,000ウォン
    特級技術者: 月額 10,800,000ウォン
    高級技術者: 月額 9,200,000ウォン
    中級技術者: 月額 7,600,000ウォン
    初級技術者: 月額 5,800,000ウォン

  投入計画:
    PM_特級: 12人月
    PL_高級: 12人月
    アナリスト_高級: 9人月（3名 x 3ヶ月）
    設計者_中級: 12人月（4名 x 3ヶ月）
    開発者_中級: 48人月（8名 x 6ヶ月）
    QA_中級: 9人月（3名 x 3ヶ月）
    DBA_高級: 12人月

  直接人件費合計: 約9億ウォン

総事業費算定:
  直接人件費: 9億ウォン
  諸経費: 9.9億ウォン # 直接人件費の110%
  技術料: 3.78億ウォン # （直接人件費+諸経費）の20%
  直接経費: 1.5億ウォン # 機器、SWライセンス、教育等
  総原価: 24.18億ウォン
  利潤: 2.418億ウォン # 総原価の10%
  総事業費: 26.598億ウォン # 約26.6億ウォン

TCO（総所有コスト）分析

TCOはシステム導入から廃棄まで、ライフサイクル全体にわたる総コストを分析する方法である。

コスト項目初期コスト年間運用コスト5年TCO
ハードウェア/インフラ5億ウォン5千万ウォン（保守）7億ウォン
ソフトウェアライセンス3億ウォン6千万ウォン（保守）5.4億ウォン
開発費26.6億ウォン-26.6億ウォン
運用人員-4億ウォン20億ウォン
教育/訓練5千万ウォン1千万ウォン9千万ウォン
データ移行1億ウォン-1億ウォン
合計36.1億ウォン5.2億ウォン60.9億ウォン

ROI（投資収益率）分析

ROI計算フレームワーク：

1. 定量的効果（Tangible Benefits）
   - 業務処理時間短縮：年2億ウォン（人件費削減）
   - 手作業エラー減少：年5千万ウォン（再作業コスト削減）
   - 運用効率化：年3億ウォン（プロセス自動化）
   - 合計：年5.5億ウォン

2. 定性的効果（Intangible Benefits）
   - 意思決定速度向上
   - 顧客満足度向上
   - データドリブン経営能力強化
   - 規制遵守リスク低減

3. ROI計算
   5年総効果：5.5億ウォン x 5年 = 27.5億ウォン
   5年TCO：60.9億ウォン

   単純ROI = （総効果 - 総コスト）/ 総コスト
           = （27.5 - 60.9）/ 60.9
           = -54.8%

   ただし、定性的効果と機会コストを含めると：
   補正後総効果：年15億ウォン（定性的効果含む）
   5年補正効果：75億ウォン

   補正ROI = （75 - 60.9）/ 60.9 = 23.2%
   損益分岐点（BEP）：約4年1ヶ月

SLAとサービスレベル管理

SLAの構成要素

SLA（サービスレベル合意書）は、ITサービスの品質を定量的に定義し、モニタリングし、未達の場合にペナルティを適用する体系的な管理ツールである。

# SLA定義書例
サービスレベル合意書:
  サービス可用性:
    目標: 99.95%
    測定期間: 月単位
    除外時間: 計画されたメンテナンス時間（毎月第2日曜日 02:00-06:00）
    算定方式: '（全サービス時間 - 障害時間）/ 全サービス時間 x 100'
    ペナルティ:
      99.90以上_99.95未満: 月額保守費の5%減額
      99.50以上_99.90未満: 月額保守費の10%減額
      99.50未満: 月額保守費の20%減額

  応答時間:
    オンライン取引: 平均3秒以内（ピーク時5秒以内）
    バッチ処理: 定められた時間内に完了
    レポート生成: 30秒以内

  障害対応:
    深刻（Critical）: 認知後30分以内に対応、4時間以内に復旧
    重大（Major）: 認知後1時間以内に対応、8時間以内に復旧
    軽微（Minor）: 認知後4時間以内に対応、24時間以内に復旧
    情報（Info）: 認知後8時間以内に対応、営業日基準3日以内に復旧

SLAモニタリング体制

モニタリング項目測定ツール測定周期報告対象
システム可用性APM（Application Performance Monitoring）ツールリアルタイム月次報告
応答時間RUM（Real User Monitoring）リアルタイム週次報告
障害件数/復旧時間ITSM（IT Service Management）システムイベントベース月次報告
バッチ処理状況ジョブスケジューラ日次日次報告
セキュリティイベントSIEM（Security Information and Event Management）リアルタイム月次報告

SLA改善サイクル

効果的なSLA管理は、継続的な改善サイクルを通じて実現される。

SLA改善サイクル（PDCA）：

Plan（計画）
  - SLA指標定義および目標水準設定
  - モニタリング体制構築
  - ステークホルダー合意

Do（実行）
  - SLAベースのサービス運用
  - リアルタイムモニタリング
  - 障害対応プロセス実行

Check（点検）
  - 月次/四半期別SLA達成率分析
  - 未達項目の原因分析
  - トレンド分析および予測

Act（改善）
  - 改善課題導出および実行
  - SLA基準再設定（必要に応じて）
  - 運用プロセス最適化

成功事例

事例1：公共機関の次世代システム構築

プロジェクト概要：

  • 対象：政府傘下公共機関の基幹業務システム次世代転換
  • 規模：約50億ウォン、18ヶ月
  • 範囲：既存メインフレームベースシステムをオープンプラットフォーム（Java/Spring）に転換

核心的成功要因：

  1. 徹底した現行分析：3ヶ月間のAs-Is分析を通じて1,200件の業務機能と800画面を精密にマッピング
  2. 段階的移行戦略：Big Bang方式ではなく業務領域別の順次転換でリスク最小化
  3. 現業参画の最大化：業務領域別の現業担当者をプロジェクト専任として配置
  4. テスト自動化：回帰テスト自動化により、転換エラーを事前に90%以上遮断
  5. データ移行リハーサル：3回にわたるデータ移行リハーサルにより、本番移行時のデータ完全性を確保

教訓：

  • 次世代事業で最も重要なのは既存業務ロジックの正確な理解
  • データ移行はプロジェクト初期から別トラックとして管理する必要がある
  • ユーザー教育時間を十分に確保して、本番稼働後の混乱を最小化すべきである

事例2：金融圏クラウド移行事業

プロジェクト概要：

  • 対象：中堅金融会社の非基幹業務システムのクラウド移行
  • 規模：約30億ウォン、12ヶ月
  • 範囲：20のアプリケーションシステムのクラウドマイグレーション

マイグレーション戦略（6Rフレームワーク適用）：

戦略適用システム数説明
Rehost（リホスト）8件変更なくクラウドインフラに移動
Replatform（リプラットフォーム）5件一部のプラットフォーム要素のみクラウド最適化
Refactor（リファクタ）4件クラウドネイティブアーキテクチャで再設計
Retire（廃止）2件使用中止システムの廃棄
Retain（維持）1件オンプレミス維持（規制要件）

核心的成功要因：

  1. 金融規制の事前レビュー：金融監督院クラウド利用ガイドライン遵守確認
  2. セキュリティアーキテクチャ設計：ネットワーク分離、データ暗号化、アクセス制御体制構築
  3. コスト最適化：リザーブドインスタンスとオートスケーリングの組み合わせで年間40%コスト削減
  4. 段階的移行：非基幹システムから移行して運用経験を蓄積後に拡大

事例3：大企業ERPの高度化コンサルティング

プロジェクト概要：

  • 対象：製造大企業のERPシステム高度化戦略コンサルティング
  • 規模：約8億ウォン、6ヶ月
  • 範囲：ISMP策定およびERP高度化ロードマップ導出

遂行方法論：

  1. グローバル14法人の業務プロセス標準化水準診断
  2. 業界ベストプラクティス対比ギャップ分析
  3. ERP拡張モジュール（SCM、PLM、MES）導入妥当性分析
  4. 3カ年段階別高度化ロードマップ策定

主要成果物：

  • 現行業務/システム分析報告書
  • 目標アーキテクチャ設計書
  • 課題定義書（32件の実行課題）
  • 3カ年推進ロードマップ
  • 投資所要予算書（総額約150億ウォン規模）

まとめ

IT事業の成功は技術的能力だけでは実現しない。事業の本質を理解し、顧客のニーズを正確に把握し、これを体系的な方法論と管理体制で実現する総合的な能力が必要である。

IT事業企画者と提案書作成者が覚えておくべき核心原則：

  1. 顧客視点で考えよ：技術ではなくビジネス価値を先に語れ
  2. 数字で証明せよ：定性的効果も可能な限り定量化して説得力を高めよ
  3. リスクを隠すな：リスクを認知し対応方案を提示することが信頼を与える
  4. 実行可能な計画を立てよ：過度な約束はプロジェクト失敗の始まりだ
  5. コミュニケーションを怠るな：ステークホルダーとの持続的なコミュニケーションが変更リスクを減らす
  6. 教訓を蓄積せよ：すべてのプロジェクトの経験を組織資産として管理せよ

IT事業環境はクラウド、AI、デジタルトランスフォーメーションなどで急速に変化しているが、体系的な企画と堅固な提案能力の重要性は変わらない。この記事で取り上げた内容が、IT事業を企画し提案書を作成する実務者にとって実質的な助けとなることを願う。

参考資料

  • 韓国情報化振興院（NIA）、情報化戦略計画（ISMP）策定ガイド
  • 科学技術情報通信部、SW事業対価算定ガイド（2025年改訂版）
  • PMI、PMBOK Guide 第7版
  • IFPUG、Function Point Counting Practices Manual（CPM）4.3.1
  • 韓国ソフトウェア産業協会、ソフトウェア技術者平均賃金公表
  • ITIL 4 Foundation、Service Level Management Practice
  • 調達庁、交渉による契約提案書評価基準ガイド
  • 金融監督院、金融部門クラウド利用ガイドライン
Discuss on Twitter • View on GitHub