3.1.1. 調達の前提

1. 概要
1. 1.1. 調達の前提とは
2. 1.2. 重要性
2. 詳細説明
1. 2.1. 調達前提の主要要素
2. 2.2. 調達方法の種類と特徴
  1. 2.2.1. 調達方法の分類
  2. 2.2.2. システムの特性に応じた調達方法の選択
3. 応用例
1. 3.1. 実際の業界での調達前提の考慮例
2. 3.2. 新たな調達トレンドと前提条件の変化
4. 例題
5. まとめ
1. 5.1. 調達の前提の重要ポイント
2. 5.2. 情報処理技術者として押さえるべきポイント

1. 概要

1.1. 調達の前提とは

　システム開発において「調達の前提」とは、システム開発に必要なハードウェア、ソフトウェア、サービス、人材などのリソースを外部から入手する際に考慮すべき基本的な条件や状況を指します。これらの前提条件を正しく理解し、適切な調達方法を選択することは、システム開発の成功に直結する重要な要素です。

1.2. 重要性

　調達の前提を適切に把握することの重要性は以下のとおりです。

最適なコスト・パフォーマンスの実現
プロジェクトのリスク低減
開発スケジュールの遵守
品質確保
組織の方針や規制への準拠

　これらの目標を達成するためには、システムの用途、規模、取組方針、前提条件、制約条件などに応じた適切な調達方法を選択する必要があります。

2. 詳細説明

2.1. 調達前提の主要要素

　調達の前提となる主要要素は、以下の図のように整理できます。これらの要素を総合的に検討することで、最適な調達方法を選択することが可能になります。

図１：調達前提の主要要素

2.1.1. システムの用途

　システムの用途は調達方法に大きな影響を与えます。

基幹系システム：高い信頼性・可用性が求められるため、実績のある製品・ベンダーからの調達が重視されます。
情報系システム：柔軟性や拡張性が重視され、最新技術の採用も検討されます。
Web系システム：スケーラビリティやセキュリティが重視され、クラウドサービスの活用も一般的です。
組込みシステム：ハードウェア要件に合致したコンポーネントの調達が必要です。

2.1.2. システムの規模

　システム規模によって適切な調達手法は異なります。

大規模システム：分割調達や段階的な調達が検討され、複数ベンダーの管理が必要になります。
中規模システム：一括調達とパッケージの組み合わせなど、バランスのとれた調達が検討されます。
小規模システム：パッケージ製品やクラウドサービスを活用した効率的な調達が検討されます。

2.1.3. 取組方針

　組織の方針や戦略によって調達の方向性が定まります。

コスト重視：初期投資を抑えるためにクラウドサービスやオープンソースの活用を検討します。
品質重視：実績のあるベンダーや製品の選定が優先されます。
スピード重視：パッケージやSaaSの活用、アジャイル開発の採用などが検討されます。
自社技術力向上：内製化を進めつつ必要なリソースを外部調達する方針が取られます。

2.1.4. 前提条件

　調達における前提条件とは、調達を行う上で考慮すべき既存の状況や与えられた条件を指します。

予算制約：利用可能な予算の上限と支出計画。
納期要件：システム導入が必要とされる時期や全体スケジュール。
技術要件：システムが対応すべき技術的な要件や標準規格。
既存システムとの連携：既存環境との互換性や連携性の必要性。
組織の調達ポリシー：組織が定める調達ルールや優先事項。

2.1.5. 制約条件

　制約条件とは、調達の選択肢を制限する外部要因や遵守すべき条件を指します。

法的規制：業界特有の規制や個人情報保護法などの法令による制約。
セキュリティ要件：組織のセキュリティポリシーや機密情報保護に関する要件。
運用体制の制約：運用・保守を担当する組織の体制や能力による制限。
ベンダーロックイン回避：特定ベンダーへの過度な依存を避けるための制約。

2.2. 調達方法の種類と特徴

2.2.1. 調達方法の分類

　調達方法は様々な観点から分類することができます。以下の表は、主要な調達方法の分類と特徴をまとめたものです。

分類	調達方法	特徴	メリット	デメリット
契約形態による分類	一括調達	システム全体を一つのベンダーから調達する方法	責任の所在が明確管理工数の削減システム全体の整合性確保	ベンダーロックインコスト高となる可能性特定分野での専門性不足
契約形態による分類	分割調達	システムの各部分を異なるベンダーから調達する方法	コスト削減最適なベンダー選定が可能ベンダーリスクの分散	ベンダー間調整の負担責任の所在が不明確システム全体の整合性確保が難しい
調達対象による分類	ハードウェア調達	サーバー、ネットワーク機器、端末などの物理的な機器の調達	資産計上可能セキュリティ管理の自由度	減価償却管理の負担技術的陳腐化のリスク
	ソフトウェア調達	パッケージ製品、ミドルウェア、OS、アプリケーションなどの調達	開発期間の短縮実績のある機能利用	カスタマイズに制限ライセンス管理の負担
	サービス調達	開発サービス、保守サービス、クラウドサービスなどの調達	専門性の活用柔軟なリソース調整	品質管理の難しさセキュリティリスク
	人材調達	SE、プログラマー、PMなどの人的リソースの調達	柔軟な体制構築必要スキルの即時補強	ナレッジ共有の課題定着率の問題
調達方式による分類	購入型	製品やライセンスを購入して所有する方式	資産として計上可能長期利用ではコスト効率が良い	初期投資が大きい陳腐化リスク
	リース型	一定期間リースし、期間満了後に返却する方式	初期投資の抑制一定期間での機器更新	長期では割高になる可能性中途解約の制限
	サブスクリプション型	必要な期間だけサービスを利用する方式（SaaS等）	初期投資不要柔軟なスケールアップ/ダウン常に最新版を利用可能	長期利用ではコスト増カスタマイズの制限ベンダー依存度が高い

表１：調達方法の分類と特徴

a) 契約形態による分類

一括調達：システム全体を一つのベンダーから調達する方法
- メリット：責任の所在が明確、管理工数の削減
- デメリット：ベンダーロックイン、コスト高となる可能性
分割調達：システムの各部分を異なるベンダーから調達する方法
- メリット：コスト削減、最適なベンダー選定が可能
- デメリット：ベンダー間調整の負担、責任の所在が不明確になりやすい

b) 調達対象による分類

ハードウェア調達：サーバー、ネットワーク機器など
ソフトウェア調達：パッケージ製品、ミドルウェアなど
サービス調達：開発サービス、運用サービス、クラウドサービスなど
人材調達：SE、プログラマー、PMなどの人的リソース

c) 調達方式による分類

購入型：製品やライセンスを購入して所有する方式
リース型：一定期間リースし、期間満了後に返却する方式
サブスクリプション型：必要な期間だけサービスを利用する方式（SaaS等）

2.2.2. システムの特性に応じた調達方法の選択

　システムの特性に基づいた調達方法選択の考え方は以下のとおりです。

高い信頼性・可用性が求められるシステム
- 実績のあるベンダーからの調達
- SLAの厳密な設定
- 冗長構成のための追加調達
短期間での開発が求められるシステム
- パッケージ製品やクラウドサービスの活用
- アジャイル開発に対応したベンダー選定
- プロトタイピングツールの活用
コスト制約の厳しいシステム
- オープンソースソフトウェアの活用
- クラウドサービスの利用（初期投資抑制）
- 複数ベンダーの競争入札
拡張性・柔軟性が求められるシステム
- モジュール分割を前提とした調達
- API連携可能な製品の選定
- マイクロサービスアーキテクチャ対応製品の選定

3. 応用例

3.1. 実際の業界での調達前提の考慮例

3.1.1. 金融業界の事例

　金融機関のシステム調達では、高いセキュリティと信頼性が前提条件となります。

前提条件：24時間365日の可用性、厳格なセキュリティ要件、金融規制への準拠
調達方法：実績のあるベンダーからの一括調達、厳格なSLA設定、詳細な監査要件
具体例：バンキングシステムの更新において、金融庁のガイドラインに準拠したセキュリティ要件を満たす製品のみを調達対象とし、実績豊富な大手ベンダーから一括調達を行う。

3.1.2. ECサイト運営企業の事例

　ECサイトでは、トラフィック変動への対応と拡張性が重要な前提条件です。

前提条件：季節変動に対応できるスケーラビリティ、短期間での機能追加
調達方法：クラウドサービス（IaaS/PaaS）の活用、アジャイル開発対応のベンダー選定
具体例：季節イベントによるトラフィック急増に対応するため、オートスケーリング機能を持つクラウドプラットフォームを調達し、機能追加に柔軟に対応できるマイクロサービスアーキテクチャを採用。

3.1.3. 製造業の事例

　製造業では、既存の生産管理システムとの連携が重要な前提条件となります。

前提条件：既存生産管理システムとの連携、工場現場での運用性
調達方法：APIによる連携可能な製品の選定、現場での使いやすさを重視
具体例：生産ラインのIoT化において、既存のERPシステムとのリアルタイム連携を前提条件とし、標準APIを持つセンサーデバイスとミドルウェアを調達。

3.2. 新たな調達トレンドと前提条件の変化

3.2.1. クラウドファーストの前提

　近年、多くの組織ではクラウドファーストを調達の前提条件としています。

従来の前提：オンプレミスを基本とし、必要に応じてクラウドを検討
新たな前提：クラウドを基本とし、必要な場合のみオンプレミスを検討
調達への影響：CapEx（資本的支出）からOpEx（運用支出）へのシフト、サブスクリプションモデルの増加

3.2.2. マルチクラウド戦略の台頭

　単一クラウドプロバイダへの依存リスクを回避するため、マルチクラウド戦略が新たな前提として注目されています。

従来の前提：単一クラウドプロバイダの選定と集中利用
新たな前提：複数クラウドの使い分けによるリスク分散
調達への影響：クラウド間連携技術の重視、クラウドに依存しないアーキテクチャの採用

3.2.3. アジャイル開発に適した調達

　アジャイル開発の普及により、調達の前提も変化しています。

従来の前提：ウォーターフォール開発を前提とした一括調達
新たな前提：イテレーション単位での柔軟な調達、価値ベースの契約
調達への影響：時間&マテリアル契約の増加、DevOpsツールチェーンの調達重視

3.2.4. ゼロトラストセキュリティの要件

　境界防御から脱却したゼロトラストモデルが新たなセキュリティ前提となりつつあります。

従来の前提：境界防御（ネットワーク境界でのセキュリティ確保）
新たな前提：ゼロトラスト（すべてを信頼せず常に検証する）
調達への影響：ID管理・認証基盤の重視、エンドポイントセキュリティ製品の調達増加

4. 例題

例題1

　A社は全国に支店を持つ金融機関で、現在のATMシステムの刷新を計画しています。新システムは24時間365日の稼働が求められ、キャッシュレス決済にも対応する必要があります。また、2年以内に全国展開を完了させる必要があります。このケースにおける適切な調達方法とその理由を述べてください。

解答例

　このケースでは、以下の前提条件を考慮する必要があります。

24時間365日の稼働（高い信頼性・可用性）
キャッシュレス決済対応（新技術への対応）
2年以内の全国展開（厳格なスケジュール）
金融機関のシステム（セキュリティ・法規制）

　これらの前提条件を踏まえると、以下の調達方法が適切です。

ATM端末ハードウェア：実績のあるATMベンダーからのリース調達（保守を含む）
基幹システム連携部分：金融システムに精通したSIerからの一括調達
キャッシュレス決済部分：API連携可能な決済サービスプロバイダとの契約

　一括調達ではなく機能別の分割調達を選択する理由は、キャッシュレス決済などの新技術対応部分については専門性の高いベンダーを個別に選定することで、品質とスピードの両立が期待できるためです。また、ATM端末については購入ではなくリース契約とすることで、将来的な技術更新への対応を容易にします。

例題2

　B社はスタートアップ企業で、新規にECサイトを立ち上げる計画です。初期予算は限られていますが、サービス成功時には急速なトラフィック増加が見込まれます。また、競合他社に先んじてサービスをローンチする必要があります。このケースにおける適切な調達の前提条件と調達方法を説明してください。

解答例

　このケースでの主要な前提条件は以下のとおりです。

限られた初期予算（コスト制約）
将来的なトラフィック増加への対応（スケーラビリティ）
迅速なサービスローンチ（時間制約）
スタートアップ企業（運用リソースの制約）

　これらの前提条件から、以下の調達方法が適切です。

インフラ：パブリッククラウド（AWS、Azure、GCPなど）のサブスクリプション契約
- 理由：初期投資を抑えつつ、トラフィック増加に応じたスケールアップが可能
ECプラットフォーム：SaaSタイプのECプラットフォーム（Shopify等）の利用
- 理由：開発期間の短縮、初期投資抑制、運用負荷軽減
カスタマイズ開発：アジャイル開発に対応した開発パートナーとの時間&マテリアル契約
- 理由：要件変更への柔軟な対応、段階的な機能追加が可能

　スタートアップの限られたリソースという前提を考慮し、自社での運用負担を最小化できるクラウドサービスやSaaSを積極的に活用する調達戦略が適切です。また、成長に応じて支払いが変動するサブスクリプションモデルを選択することで、初期投資を抑えつつスケーラビリティを確保できます。

例題3

　C社は中規模の製造業で、既存の生産管理システムと連携する在庫管理システムの開発を計画しています。社内にはITエンジニアが少なく、システム開発の経験も限られています。また、予算は確保されていますが、必要最小限に抑えたいと考えています。このケースにおける調達の前提条件と最適な調達方法を検討してください。

解答例

　このケースでの主要な前提条件は以下のとおりです。

既存生産管理システムとの連携（システム連携要件）
IT人材リソースの制約（運用・保守の制約）
コスト効率化の要望（予算制約）
製造業特有のプロセス（業務知識要件）

　これらの前提条件から、以下の調達方法が適切です。

システム全体：製造業向け在庫管理パッケージソフトウェアの購入
- 理由：開発工数の削減、製造業の業務ノウハウが組み込まれている
システム連携：生産管理システムとのインターフェース開発を専門ベンダーに委託
- 理由：専門的な技術が必要な部分のみ外部リソースを活用
運用・保守：パッケージベンダーによる保守サポート契約の締結
- 理由：限られた社内IT人材リソースの負担軽減

　社内リソースの制約という前提条件を考慮し、なるべく標準機能が豊富なパッケージソフトウェアを選定することで、カスタマイズ範囲を最小限に抑え、コストと納期のリスクを低減できます。また、運用・保守のサポート契約を含めた調達を行うことで、限られたIT人材で安定運用が可能となります。

例題4

　D社は大手小売業で、新たなPOSシステムとECサイトを連携させたオムニチャネル戦略を推進するためのシステム調達を計画しています。CIOから「ベンダーロックインを避け、将来の柔軟な拡張が可能なシステム構成にすること」という指示が出ています。D社ではシステム部門が充実しており、自社での開発・運用能力も備えています。以下の観点から、適切なRFP（提案依頼書）に含めるべき調達の前提条件を検討してください。

システムアーキテクチャに関する前提条件
ベンダー選定における前提条件
契約形態に関する前提条件

解答例

　D社の場合、以下の前提条件をRFPに明記することが適切です。

システムアーキテクチャに関する前提条件
- マイクロサービスアーキテクチャの採用を前提とし、個別のサービスが独立して開発・展開可能であること
- 標準的なAPIを介したシステム間連携を前提とし、特定ベンダー固有の連携方式に依存しないこと
- クラウドネイティブな設計を前提とし、複数のクラウド環境への移行が可能であること
- コンテナ技術を活用し、環境依存性を最小化すること
ベンダー選定における前提条件
- 特定ベンダーによる一括受注ではなく、専門性に応じた複数ベンダーへの分割発注を前提とすること
- 各ベンダーは自社が担当する部分のソースコードを提供し、D社が全体のソースコード管理を行うことを前提とすること
- オープンソースソフトウェアの積極的な活用を前提とし、商用ソフトウェアの選定においても代替製品が存在するものを優先すること
契約形態に関する前提条件
- 段階的な開発を前提とし、フェーズごとにベンダー選定を見直す可能性があること
- 初期開発後の保守・運用はD社主体で行うことを前提とし、ナレッジトランスファーを契約に含めること
- ベンダーが提供するAPI・インターフェースの仕様変更に関する事前通知義務を契約に含めること