〇 「システム調達」こそプロジェクト化せよ、成功のポイントは大きく3つ。
IT関連で「プロジェクト」というと、いわゆるシステム開発（プログラム開発を伴わず、システム構築やシステム導入と呼ばれるケースも多いが、ここでは便宜的にひっくるめてシステム開発と呼ぶことにする）フェーズを思い浮かべがちだが、システム調達フェーズもまた1つの重要なプロジェクトである。ただ漫然とRFP（提案依頼書）を作ればそれで済むものではない。
プロジェクトとは何か。その定義はネットや書籍などで確認してみると、どれもほとんど同じことが書いてある。ここでは「ChatGPT」の回答を用いることにする。「プロジェクトの定義を教えてください」というシンプルな質問をしたところ、下記の回答を得た。さらに分かりやすくするために、ChatGPTが示した6つの特徴に筆者が補足説明を加えてみた。
プロジェクトの定義――ChatGPTの回答。
プロジェクトは、特定の目的や目標を達成するために一時的に行われる取り組みや活動のことです。プロジェクトは、一連のタスクやアクティビティを計画し、実行し、管理して、ある目標を達成するために行われます。通常、プロジェクトには以下の特徴があります。
1. 一時的な性質：プロジェクトは明確な開始と終了の時点があります。目標達成後には完了します。
〔筆者の補足〕
調達フェーズは毎日定常的に行う業務ではなく、ある期間に行う仕事で開始と終了は明確だ。開始は多少曖昧な場合があるかもしれないが、終了はソリューションおよびベンダーの選定が済んで、契約を締結する時点である。その後はシステム開発フェーズに引き継がれる。
2. 独自の目的：プロジェクトは特定の目標や成果を達成するために実施されます。その目標は一般的に明確かつ具体的です。
〔筆者の補足〕
調達プロジェクトの目標は「最適なソリューションおよびベンダーを選定し、適切な予算内で契約すること」である。そのためにRFPを記載し、複数の提案および見積もりを比較評価するのである。
3. 固有の範囲：プロジェクトは定められた範囲内で実行されます。スコープと目標が明確に定義されています。
〔筆者の補足〕
調達の対象となるシステムの範囲（スコープ）はRFP作成段階で明確化される。スコープが明確でないと調達はうまくいかない。曖昧だとベンダーはリスクを感じてバッファーを取った高額な見積もりを出すことになる。さらに、開発フェーズに入ってから「最初のスコープ想定と話が違う」という深刻なトラブルを引き起こす原因となる。
4. リソースの利用：プロジェクトは、人的資源、財務資源、時間などのリソースを利用して遂行されます。
〔筆者の補足〕
システム調達の実行には数カ月以上の期間が必要である。その期間内に様々なタスクを行う。その中でも大きなタスクがRFP作成だが、それには調達担当者のリソースだけでなく、エンドユーザーへのヒアリングやベンダーとのやり取りのために、多数の人の時間的リソースを使うことになる。自社だけで調達フェーズを進めるのが難しい場合にはコンサルタントを活用することもあり、相応の費用が発生する。調達フェーズは人、カネ、時間といったリソースを少なからず消費するのだ。
5. 計画と管理：プロジェクトは計画され、実行され、進行状況が管理されます。通常、プロジェクトマネージャーやチームが関与します。
〔筆者の補足〕
これまで当コラムの過去記事でも記載してきたように、調達フェーズでは様々な行うべきタスクとその順番があり、計画的に行わないと、とん挫したり、予定を大幅に超えて時間が掛かったりしてしまう。エンドユーザーやベンダーといった相手もあるので、相手の事情や都合も考慮しなければならない。その上で、何をどういう順番でいつまでに行うかといった進捗管理が必須となる。
6. 成果物の提供：プロジェクトの結果として成果物や成果が生み出されます。これは製品、サービス、レポート、システムなどさまざまです。
〔筆者の補足〕
成果物には調達する側が作るRFPとベンダーに提出してもらう提案書および見積書が最重要なものである。それ以外にも調達フェーズの初期段階で用いるRFI（情報提供依頼）とそれに対するベンダーの回答、エンドユーザーヒアリングの議事録などの中間成果物もたくさん作られる。
定常業務とごちゃ混ぜにしてはいけない。
いかがだろうか。上記を見れば、調達フェーズがプロジェクトそのものであることがよく分かるはずだ。それにもかかわらず、実際の調達活動ではシステム開発のようなプロジェクト体制を組まずに、担当者が日常業務の合間の時間をやり繰りしていることが散見される。定常業務とプロジェクトでは、その性質が全く異なる（図1）。それをごちゃ混ぜにしてはいけない。現実的には同じ人がやるのかもしれないが、だからこそ違いをより一層認識して、分別してプロジェクトとして取り組むべきである。
「当社はシステム要員が少なくノウハウもない。またコンサルタントを雇うカネなど経営者は出してくれない」というような厳しい現実もあるだろう。たとえそうであっても、できる範囲でプロジェクトとしての「構え」を作る努力すべきだ。手前味噌ながら当コラムのような調達やRFP作成に関する情報をできるだけ収集するだけでも、無手勝流で行うよりはよほどましなはずだ。
調達フェーズをきちんとプロジェクトとするためのポイントは以下の3つである。
1. プロジェクトマネージャーを立てること。
「形から入る」ことは必ずしも悪いことではない。調達フェーズのようにプロジェクト化が周囲からあまり認識されていないようなケースでは有効である。単なる「調達の担当者」と「調達フェーズのプロジェクトマネージャー」ではやはり響きが違う。特にベンダー側は受け取り方も違ってくる。
2. 調達フェーズのタスクと順番をきちんと理解する。
調達の対象となるシステムや規模、あるいはパッケージ利用か、スクラッチ開発かはたまたSaaS（Software as a Service）利用か、などによって多少は異なるものの、調達フェーズでやることはそう大きくは変わらない。ゴールまでの全体の流れを先につかんでおくとよい（図2）。
3. 目的を明確にすることを意識する。
何が目的でシステムを導入するのか。その目的を、できればRFPを作成する前か、RFPの最初の作業として定義できるとよい。システムの目的が定まらないと、プロジェクトのスコープに影響するからである。それが難しい場合は次善としてRFPを作りながら固めていくことになるが、手戻りや修正のリスクが生じることがある。また「RFP作成はあくまで調達の手段であって目的ではない」ことを最初に、そしてRFP作成途中でも常に意識してほしい。
プロジェクト化というと大げさで手間もかかると思うかもしれないが、「急がば回れ」である。システム開発のプロジェクトと同様に最も非効率なのは「手戻り・やり直し」である。その「手戻り・やり直し」を極力発生させないためには、やはり調達フェーズをきちんとプロジェクト化して推進していくことをお勧めしたい。
