システム戦略 - 18.システム企画 - 3.調達計画・実施 - 2.調達の実施

Last Update : January 02 2021 16:00:47

     

a. 調達の方法

外部の提供先から調達する場合は、外注先の選定する方法として企画競争による選定と入札による選定と、入札を行わずに発注者側が選定する随意契約とがある。
また、入札には、入札情報を一般に公示し、参加申し込み者を募り、条件を満たした参加者の間で入札を行い選定する方法の一般競争入札と、発注者側が前もって指名した業者の間で入札を行い選定する指名競争入札の2つがある。

調達までの一般的な流れ

  1. 情報提供依頼書(RFI)の作成
    ITベンダの保有製品や提供可能なサービスの概要などの情報提供を依頼する文書(RFI)を作成し、情報の提供を要請する。
  2. 提案依頼書(RFP)の発行
    ITベンダに、必要とするハードウェアやソフトウェア、サービスなどのシステムの概要や、依頼事項、保証要件、契約事項などを記述した文書(RFP)を発行し、具体的なシステム提案を依頼する。
  3. 選定
    ITベンダから提出された提案書を、あらかじめ決めておいた方法で評価し、調達先を決定する
  4. 契約の締結
    評価を経て調達先(供給者)を決定する。


b. 情報提供依頼書 ( RFI : Request For Information )

企業が調達や業務委託を行う際、自社の要求を取りまとめるための基礎資料として、外部業者に情報の提供を要請すること。あるいはその要請をまとめた文書をいう。一般にRFPを作成するために発行される。
最新技術の調達や普段は取り引きのない業者への発注を検討する場合、一般の公開情報だけでは調達条件や選定条件を取りまとめることができないことがある。こうしたときに、調達先・依頼先候補の事業者に必要情報の提供を求める文書がRFIである。
RFIの目的は、知りたい情報を文書として明確化することで、相手からセールストークなどのあいまいな言葉ではなく、明快な回答を確実に得ることである。複数業者の回答を比較する場合も同一の質問に対する答えであれば、検討しやすい。RFIの発行は、提案や見積もりといった交渉の前段階で行われるもので、数多くの外部事業者から、自社が求める能力を持ち、交渉に足る相手を絞り込むといったことも狙いとなる。この場合、RFI発行先が必ずRFP発行先・発注先になるわけではない。
ハイテクを対象としたRFIでは、自社が知らない新製品・新技術に関する知見を得ることも目的となる。IT調達におけるRFIはITベンダの技術要件を確認するもので、どのような技術を保有しているか、どのような経験があるかなどを確認するものとなる。


c. 提案依頼書 ( RFP : Request For Proposal )

企業が情報システムやITサービスなどを調達する際に、発注先となるITベンダに具体的なシステム提案を行うよう要求すること、またはその調達要件などを取りまとめたシステム仕様書を指す。日本語では「提案依頼(書)」「提案要請(書)」「提案要求(書)」「提案要望(書)」「提案募集(書)」「入札依頼(書)」「見積依頼(書)」「提案書提出要請(書)」など、さまざまな訳が使われる。
ITベンダ側はRFPに基づいて大まかなシステム設計を行って提案書を作成し、ユーザー企業に提出する。ユーザー企業はその提案書を評価して、調達先の決定や契約の締結などを行うことになる。
RFPには決まった書式はないが、システムの「概要と目的」「必要な機能」「求められるシステム条件」「サービスレベル」「予算」「納期」「契約条件」「評価プロセスと評価基準」「調達方針」「環境」など具体的な要求を盛り込む必要がある。さらに各要求に優先度を付け、システム導入にあたってゆずれない条件を明記することもポイントだ。またベンダに対して、「提案書の形式」「提出期限」「提出先」「提出方法」などを指定する。
RFP作成については、まずユーザー企業内で対象となる部門スタッフ(エンドユーザー)へヒアリングを行い、現状の業務やシステムに対する改善要望を洗い出すことから始まる。この作業を担当するのは主にユーザー企業の情報システム部門だが、場合によってはシステム導入の対象部署から担当者が任命されることもある。いずれにしても、業界特有のビジネス用語をできるだけ排除することが重要だ。このヒアリング結果を受け、具体的な機能要件に落とし込む。
RFPの作成は、ベンダへの情報提供のほかに、事前にシステム要件を明らかにすることで、開発フェイズに入ってからの混乱を未然に防止することが期待される。とはいえ、実際に開発作業に着手すると、エンドユーザーからの要求が変更される可能性もある。特に最近のプロジェクトでは、機能を少しずつ追加してエンドユーザーに検証してもらいながら開発を進めるスパイラル型開発が主流なので、出来上がったシステムを見てさらに高度な要求を突き付けるエンドユーザーも少なくない。また最初のRFPはあいまいで開発工程に入ってから、詳細な要求が決まるというパターンも多い。こうしたリスクを防ぐには、エンドユーザーの要望を初期段階で引き出すテクニックが必要となる。こうした声に応えるため、ユーザー企業のRFP作成を支援するコンサルティングファームも増えてきた。
RFPをまとめる目的は、概ね以下の通りである。

  • 現状の整理
    意外と現状を第三者に伝えられるほどまとまっていないものである。
  • 要望の整理
    課題や要望を話し出すときりがなく出てくる。端的にまとめることが必要。
  • 文書化による社内意見の調整・共有化
    大抵、社内の意見はまとまりにくいものであり、たたき台の状態であっても 文書として何かあるとまとめやすいものである。
    多くの問題の一つに「私は知らなかった、聞いてない」ということがあるの で、文書としてまとめて共有化するのがよい。
  • ベンダーからの誤解の予防
    外部に頼むときは、体制/役割/作業内容/成果物 を予め確定させて発注 すべきである。これらが曖昧であればうまくいくはずがない。
  • 第三者に聞きやすい(複数ベンダーに依頼しやすい)


d. 提案書・見積書依頼書 ( RFQ : Request For Quotation )

調達先・業務委託先(候補)に対して、価格およびその内訳を示す見積もりを作成するように依頼すること、あるいはそうした依頼を示した文書をいう。
システム開発では、どのようなものをどのようなレベルで作成するかが決まらないと価格見積もりを行うことができない。そこでRFQに先立ってRFIやRFPを発行し、システムの概略を決める必要がある。小規模システムではRFPとRFQが1つに集約されるケースもある。


e. 調達選定

調達先の選定にあたっては、提案評価基準や要求事項適合度など明確に選定手順を確立し、提案企業の提案書や見積書をもとに開発の確実性、信頼性、費用の妥当性、スケジュール、最終納期などを比較検討することで行う。


f. 調達リスク分析

品質・コストでのリスク、法律上のリスク、セキュリティ上のリスクなど調達に伴うリスクを分析する必要がある。
内部統制・コンプライアンス・CSR調達・グリーン調達などの観点から検討する。

CSR調達
CSR(Corporate Social Resposibility)は、企業が社会の構成員として、法令遵守はもちろん人権や環境にも配慮し、消費者や従業員、地域社会などのステークホルダーに対して責任を果たすという考え方こと。
調達先を選定する場合に、相手企業がCSRを行っているかどうかで選定を判断すること。

グリーン調達
企業などが製品やサービスを外部から調達するとき、有害物質の含まれないものや廃棄時に水や土壌を汚染しないものなど、環境負荷に配慮した物品を優先的に選択すること


g. 契約締結

調達先を選定したら、納入システム、費用、納入時期、発注元と調達先との役割分担などを確認して契約を行う。
契約形態には、請負契約と(準)委任契約とがある。

  • 請負契約
    仕事や物の完成を約束する
  • (準)委任契約
    特定の行為を行うことを約束し、必ずしも完成を約束しているわけではない

また、ソフトウェアには知的財産権が含まれるので、知的財産権利用許諾契約も必要になる。
ソフトウェア開発の委託契約の参考となるモデルとして、ソフトウェア開発委託モデル契約がある。また、契約書のモデルとして、情報システムモデル取引・契約書がある。


  [ 例題 ] 
  1. 平成29年度秋期 問64  グリーン調達
  2. 平成24年度春期 問66  提案依頼書
  3. 平成23年度春期 問64  RFI
  4. 平成22年度春期 問67  RFP


     

www.it-shikaku.jp