情報システムの開発を外注するときの手順は、一般に次のようになります。
- 業務要件の検討
- 経営戦略やＩＴ戦略、利用部門のニーズなどから、開発するべき情報システムへの業務要件を検討します。
このとき、ＩＴの動向や類似業務のシステム化について、専門家（ベンダーやコンサルタント）からの情報を得たいことがあります。そのような情報提供依頼をＲＦＩ（Request For Information）といいます。これは発注を前提としたものではないので、ベンダの一方的なサービスになりますが、受注に参加したいベンダは積極的な情報提供をしてくれます。 - ＲＦＰの作成
- ＲＦＰ（Request For Proposal：提案依頼書）とは、複数ベンダに発注を前提した提案を求める文書です。適切なＲＦＰを作成することが、適切な提案書が得られ、よいシステムを調達できる前提になります。→参照：ＲＦＰの重要性
業務要件を整理して、何をしたいのかをベンダが理解しやすいように、より具体的に詰める必要があります。組織図や業務の流れ、想定されるデータの量、現在のシステムなど、システム構築に必要とされる多様な資料を添付します。
このとき、要件を機能要件と非機能要件に区分して提示すること、開発プロジェクト全体の期間あるいは納期を提示することが大切です。
また、評価がしやすいように、ＲＦＰで提案書の記述内容を指定しておくことが望まれます。 - 提案評価基準
- ＲＦＰを作成するとともに、提案を評価する基準を作成しておきます。この基準なしに提案を比較評価するのでは、評価者により観点が異なり、関係者が合意するのが困難になりますし、透明性が低下するので関係者への説明の説得性が低下します。
なお、評価項目には提案システムに限定せず、ベンダの財政状況、過去の実績、技術力なども入ります。予定金額も必要です。
逆に、評価基準との比較がしやすい提案書になるよう、ある程度の体裁を指定するのが適切です。
ＲＦＰおよび評価基準は、経営者など決裁者の承認を得ておくことが重要です。 - 見積依頼書（ＲＦＱ）
- ベンダに見積書の提出を依頼します。提案書とともに提出してもらうこともありますが、提案を分析してさらにベンダを絞り込んでから見積依頼をすることもあります。
なお、多くの見積書総額が予定金額と大きく乖離した場合は、一度白紙に戻して、業務要件から見直すことになります。 - 要求事項適合度評価
- ベンダからの提案書（及び見積書）を提案評価基準に照らして分析し、要求事項適合度（定性的表現もある）の一覧表を作成します。上位数社に対してヒアリングを行い、再評価して順位をつけ、決裁者の承認を得ます（留意）。
数社ベンダを候補にして提案書を検討しますが、経営者は見積金額だけに関心を持ちます。ＩＴ部門は、提案のそれぞれに評価やコメントをつけたりしますが、見積金額の順位を覆すだけの説得力がありません。費用が重要な評価要素なのは当然ですが、これが大きな危険をはらんでいることに留意する必要があります。
ハードウェアの費用やソフトウェアの保守費などが入っていないというのは極端ですが、文書化など付帯的な業務が欠けており、それが契約に含まれているかどうかが後でトラブルの原因になることがよくあります。また、データ入力での誤りデータのチェック機能などはピンからキリまでのレベルがありますが、ベンダが過少に低くとらえていることがあります。特にＷｅｂシステムでは、通常時とピーク時のアクセス数が極端に異なりますが、ピーク時の対処に考慮していないと、実施後大きなトラブルになります。このように、ベンダも気づかない手抜きはよくあるのです。 - システム仕様書
- 順位の高い順に、指名を前提とした具体的な交渉に入ります。
ＲＦＰは業務からの要件を示したものであり、提案書には情報システム開発の観点から修正したシステム要件が示されているはずですが、実際に情報システムを開発するには、もっと具体的に詳細にわたって検討する必要があります。そして、発注者とベンダの双方で協議し合意した結果をシステム仕様書の体裁にまとめます。
さらに協議を重ねて、発注者とベンダの業務分担、納期や費用などの合意をしたＳＯＷ(Statement of Work，作業範囲記述書)を作成します。
- ＬＯＩ（仮発注合意書）
- 正式の契約を締結する以前に、ＬＯＩ(Letter of Intent：仮発注合意書)を交わすことがあります。これは契約前に、システム仕様書やＳＯＷなどの作業があるし、納期などの事情により、開発業務の一部を開始することもあるからで、そこでの業務分担や費用について合意をしておく必要があるからです。 また、その間のプロセスで合意に達しないときは、二番手の候補に変更することがあるからです。
- 契約
- これらの合意に達したら、契約を行い、開発に入ります。
契約においては、業務分担、支払条件、成果物の著作権帰属など多様な項目に関して、明確な合意をしておくことが重要です。これに関しては、経済産業省「情報システム・モデル取引契約書」を参考にするのがよいでしょう。 - 開発
- 業務分担に応じて双方が開発作業をします。先に合意したシステム仕様書を基に、改めて要件定義、外部設計などのプロジェクトが開始されます。
外部設計書に基づきプログラミングやデータベースの実装などはベンダ側の業務ですが、得意先コードの設定や得意先台帳などの作成など、発注側が行う業務も多くあります（参照：システム開発での利用部門の任務 ）。 - 検収・稼働
- ベンダ側のシステム開発が完了し、ハードウェアの設置などができたら、発注者立ち合いでテストを行います。それで満足すべき状態になったら発注側に引き渡します。
本稼働になった後でも、トラブルが発生するのが通常です。それで、瑕疵担保責任やＳＬＡ（サービスレベル・アグリーメント：納入システムの機能、アフターサービスに関する合意文書）を取り交わします。
調達リスク
情報システムの調達は、通常の物品の調達と比較して、内容を明確に伝達するのが不明確になりがちです。サンプルを提示することも困難です。新技術を用いるとき、予定した期限に期待した機能が提供される保証はありません。
システム外注にあたっては、このようなリスクがあることを認識し、リスクアセスメントを行い、その発生を低減するために、共通フレームなどの概念・用語の採用、レビュー、代替案の検討などを行うことが重要です。