調達活動の基本 ~内外製分析、RFP作成、ベンダーの評価と選定~【プロジェクトマネジメントの基礎】

2022年10月25日

要求定義が終わったら

プロジェクトの要求定義が終わった後は、要求を実現するために動き始めます。たとえばソフトウェア開発プロジェクトの場合は、実際の開発に進んでいきます。
しかし、要求事項のすべてを組織内の人員や設備だけで実現できるのは稀です。多くの場合、開発を外部の業者(ベンダー)に依頼したり、必要な設備を購入したりして、要求を実現しようとします。
こうした活動をPMBOKでは調達と呼びますが、この調達に失敗するとスケジュール遅延や品質の低下を招いてしまいます。

今回はソフトウェア開発を想定し、ベンダーの選定などの調達活動について解説していきます。

何を調達するのか?

要求事項が整理されていたら、各要求事項を実現するために何が必要で、組織内の資源、つまり人員や設備で対応できるか否かを考えていきます。
また、組織内で対応できる場合でも、外部に依頼する方が品質やコストの面で優れている場合もあります。そのため、内外製分析を行い、何を外部に依頼するのかを検討していきます。
内外製分析については下記の記事もご参照ください。

どのように調達するのか?

調達の仕方を確認する

外部から調達しなければならないものが整理できたら、次はどのようにして調達するのかを考えていきます。
たとえば、プロジェクトのためにパソコンが1台追加で必要になった場合は、家電量販店で簡単に購入することができます。しかし、その数が10台、100台となると、メーカーに問い合わせなければなりません。
このように、調達しようとするものによっては、購入の手続きが複雑であったり、手元に到着するまでに時間がかかったりすることがあるので注意が必要です。

ソフトウェア開発プロジェクトの場合

ソフトウェア開発プロジェクトの場合、一番のポイントとなるのがベンダー(開発業者)の選定です。プロジェクトの要求事項を実現するのに十分な技術力や力量が無いベンダーに依頼すると、スケジュールの遅延や品質の低下につながります。

ベンダーを選ぶ方法はいくつかあります。付き合いのあるベンダーに依頼する方法や、目ぼしいベンダーをリストアップし、その中から選定する方法、提案を公募するという方法もあります。
プロジェクトの規模が大きい場合は、RFPを作成し、公募する手法を採るのが一般的です。

RFPの作成

RFP作成の目的

RFPとは“Request for Proposal"の略で、日本語では「提案依頼書」と呼ばれます。
企業や役所、大学などが外部にソフトウェア開発やWebサイトのリニューアルなどを委託しようと考えている時に、このRFPが作成されます。
RFPが無くてもベンダーからの提案は受けることができますが、RFPを作成し、プロジェクトの目的や求める品質、スケジュールを提示することで、認識の齟齬を小さくすることができます。

RFPについて詳しくは、下記の記事をご参照ください。

RFPの内容

RFPには以下のような項目を盛り込みます。

  1. プロジェクト概要
  2. 業務・システム概要
  3. 機能要件
  4. 非機能要件
  5. 開発条件
  6. 提案依頼事項
  7. 提案手続き
  8. 評価
  9. 契約事項

これらの情報を目ぼしいベンダーに提示し、提案を募ります。

提案の評価

ベンダーから提案を受けた後は、その提案内容を評価します。
ここからはベンダーを評価する手法を紹介していきます。

発注先選定分析

発注先選定分析の画像

発注先選定分析とは多基準意思決定分析の一種で、様々な角度から発注先を評価し、適切なベンダーを選定しようとする手法です。
一面的な評価でベンダーを選択してしまうと、金額は安いけれども技術力がなく、プロジェクト進行も拙い会社を選んでしまうことも少なくありません。
そのため、発注先を判断する軸を複数持ち、各基準においてどのくらいの水準にあるのかを見定めるのが発注先選定分析です。
主にベンダーを広く公募する時に使う手法であり、RFPなどにあらかじめ発注先選定のための基準を記載するのが一般的です。

発注先選定分析については下記の記事もご参照ください。

CMMI(能力成熟度モデル統合)

能力成熟度モデル統合(CMMI)の5つのレベルのイメージ図

CMMI(能力成熟度モデル統合)“Capability Maturity Model Integration"の略で、ソフトウェアを開発する組織の成熟度を測るものです。
まったくプロセスが確立されていないレベル1の状態から、プロセスが確立され、定量的フィードバックを行いながら改善活動を行うレベル5までの5段階で組織を評価します。
このCMMIはもともとアメリカの国防総省が失敗続きのソフトウェア開発を改善するために、カーネギーメロン大学ソフトウェアエンジニアリング研究所に依頼して策定した指標です[1]深沢隆司『48のキーワードから学ぶ実践プロジェクトマネジメント』翔泳社、2004年、224頁。
組織の状況をじっくりと見定める手法であるので、長期にわたるプロジェクトや保守を行う業者を選定する時に役に立つ考え方です。

CMMIについては下記の記事もご参照ください。

契約とその後

評価が終わり、依頼するベンダーが決まった後は、その旨を通知します。
改めて提案内容に虚偽が無いか、支払いはどのようにするのかなどを協議し、正式な契約を結びましょう。

契約が終わった後は、本格的にプロジェクトで求める製品やサービスの開発をしていきます。ソフトウェア開発プロジェクトであれば、設計を行い、プログラミングをする段階に入ります。

依頼者側であれば、今後は主にベンダーがプロジェクトマネジメントを進めていくため、負担が軽減します。とはいえ、ベンダーに任せきりにして良いと言う訳ではなく、プロジェクトのパフォーマンスを評価し、進捗に問題が出ていないかを監視していく必要があります。

一方でベンダー側は、これから設計や開発を行い、適切に依頼者とコミュニケーションを取りながら、プロジェクトをけん引して行かなければなりません。開発については、システム開発のVモデルやアジャイル開発の記事をご参照ください。

1深沢隆司『48のキーワードから学ぶ実践プロジェクトマネジメント』翔泳社、2004年、224頁。