【IT分野での2025年問題の本質:step5】ベンダー及びパッケージ選定プロセスのポイント

人事

2020年04月08日(水)掲載

「ステップ4」のベンダー選定・評価プロセスの流れを、以下の3-2.図1で例示しました。尚、下記は、RFIとRFPを使用する2段階での選定ケースがあります。また、下記の3-2.図1中のPMPとは、プロジェクトマネージメント計画書(Project Management Plan)を意味します。

3-2.図1 ベンダー選定・評価プロセス

(図1:筆者作成)

では、3-2.図1をもとに、ベンダー選定・評価プロセスの中で重要なポイントを解説しましょう。尚、「選定準備フェーズ」で、候補ベンダーからのRFP回答が返ってくるまでに実施すべき作業の詳細は、「ステップ6:ベンダー提案回答受領迄になすべきPMPの作成」に記載しております。そして「選定・評価フェーズ」作業についても、「ステップ7:プロジェクトマネージメント計画書(PMP)をもとに選定」のところで詳しく解説しますので、ここでは全体の流れとポイントのみを解説しておきます。

事前準備フェーズのポイント

先ず、ここで一番重要なことは、一緒に再構築プロジェクトを推進して貰えるベンダー(パッケージベンダー、或いはITベンダー)を特に意識して選定することです。そして、パッケージありきで候補ベンダーを選定することは、再構築プロジェクト全体を考えると必ずしも得策ではないということを念頭において、RFIやRFPを作成することです。ITベンダーでも、複数のパッケージライセンスを提供できるベンダーもありますので、パッケージベンダーにこだわる必要はありません。よって、幅広い観点からRFIを送るベンダーを選定してください。また、候補ベンダー数は、この段階では少なくとも10社以上は選定する必要があるでしょう。

そして、その中からRFPを送り、回答を貰うベンダーを8社ほど選定します。ここで注意するポイントは、ベンダーが回答内容をよく検討できるように、十分な回答期間を確保することです。よくあるケースは、早くベンダーを選定したいがために、RFPの回答までに1週間~10日間程度しかないケースです。これではベンダーが十分な提案回答書を作成できず、また、RFPの内容に関しての質問・回答の期間も十分に取れません。

可能であれば、最低でも2~3週間ほど確保してください。また、その間の各ベンダーからの質問に対しては、公平性を保つために全ベンダーに同時に回答するように心がけてください。そして、その対応は再構築プロジェクト開始後にメインで加わるメンバーがRFPの内容を深く理解した上で、RFPの問い合わせ対応や回答取り纏めにあたる必要があります 。
既にこの一連のコラム内のRFPの作成部分で、「可能であれば、基幹システム再構築プロジェクト開始後にPMとなるメンバーが、RFPの作成の取り纏めをしてください」と書いたのもこのような背景があります。この再構築「準備フェーズ」の段階から、既にプロジェクトは始まっているともいえるのです。

RFPに関する質問や回答の手順もRFPの中にも記載していると思いますが、依頼するプロジェクトの主旨やベンダーに期待すること、また、これら質問回答の手順等を周知徹底するためにも、RFPに関する説明会を開催するのが望ましいです。各ベンダーからRFP説明会に出席して貰い、RFPを渡すタイミングでこれらについても説明すると良いでしょう。

また、通常、各ベンダーからの出席者は2、3名に絞るのが適切です。なぜなら、各ベンダーの取り纏め営業、取り纏めSE(システムエンジニア)のみならず、プロジェクト開始後にベンダーからメインでプロジェクトに参加する技術者も出席するケースもありますので、2名とお願いしてもベンダー側からそれ以上の出席者を要望してくるケースもあります。それ故に、出社者の人数を平等に決めておく必要があります。誰が(プロジェクトに関わる可能性のあるどのような技術者が)RFP説明会に出席するか否かも、実はベンダー選定上の基準のひとつになり得るのです。

選定準備フェーズのポイント

各ベンダーがRFPへの提案回答書を作成している間に、企業側としてやるべきタスクはたくさんあります。故に、依頼する企業側にとっても、RFPを送ってから回答受領までのそれなりの期間必要となるのです。これは、3-2.図1の中の「選定準備フェーズ」にあたります。そして、その間になすべきタスクは以下に記載しています。

・プロジェクトマネージメント計画書(PMP)(案)の作成 ~ この詳細は、「ステップ6:ベンダー提案回答受領迄になすべきPMPの作成」で詳しく解説しますが、このPMP(案)は、 基幹システムの再構築プロジェクト開始後のバイブルとも言うべき重要な位置づけのドキュメントです。
この「準備フェーズ」の段階では、既に策定済みのプロジェクトの全体計画やRFPの作成段階において策定した情報をもとに、ベンダーに依頼する企業の情報システム部門自らで策定するということが重要なのです。ただし、この段階ではあくまでもPMPのドラフト、つまり素案レベルで十分です。
ベンダーからRFPの回答提案を待っているこの段階で、素案を作成するのは早いと思われるかしれません。しかし、このPMPはベンダー選定の観点からも必要となります。特に最終候補に残るようなベンダーのPM候補から詳細をヒアリングする際に、ベンダーPMの経験やスキルの判断材料にもなります。PMPの項目内容等の詳細は、次回のコラムをご参照ください。

・評価基準の策定 ~ この「ベンダー評価基準」は、「再構築プロジェクトを成功すべく、最適な支援ベンダーを選ぶ」という意味で重要です。この評価基準が明確でないが故に、ベンダーの選定を間違えてその後プロジェクトが大変な状況になるという事例も実際多々ありますので、あながち大げさではありません。
この「評価基準」に関しても、次のコラムの「ステップ7:プロジェクトマネージメント計画書(PMP)をもとに選定」のところで詳しく解説しますが、ここで敢えて少し触れるとすれば、最初の提案回答の内容からベンダーを絞る際のベンダー評価シートの評価項目についてです。
注意すべきことは、この評価シートのみでベンダーの候補を程度絞ってしまうと、そのあとのベンダープレゼンテーションで本当に貴社にとって有益なベンダーを選定から外してしまうというようなリスクも存在するということです。確かに回答の内容も重要です。しかし、ITの導入サポート、プロジェクトサポートとしてのベンダー選びには、単に技術面だけでは評価できない難しい面も多々あります。もし、そのようなドキュメント上では評価できない優れたベンダーを安易に書類上の評価から排除してしまった場合、最終候補ベンダーを選ぶ際に、その中に最適なベンダーがいない選択肢の中から選ばざるを得ず、間違った観点からベンダーを選んでしまうという、後戻りが出来ない状況になる可能性もあります。 
よって、安易に書類選考だけでベンダーをふるいに掛けるのは少し注意が必要です。各評価項目の内容、重みも重要となるのです。このあたりの詳細は、次のコラムで詳しく解説します。

評価・選定フェーズのポイント

上記(2)の準備フェーズがしっかりできていれば、あとはそれに従って貴社に最適なベンダーを選ぶだけです。しかし、ここにも重要なポイントがいくつかあります。
詳細は、評価基準同様、次のコラムの「ステップ7:プロジェクトマネージメント計画書(PMP)をもとに選定」のところでも触れますが、ここで先ずひとつだけお伝えしたいことがあります。
それは、ベンダーの選定を、IT部門だけでなく業務メンバーや幹部も含めた場にて、プレゼンテーション方式で行っていただきたいということです。これには、いくつかの明確な理由がありますが、ここでは一番重要な理由を以下に記しておきます。

今の時代、企業にとって将来の企業戦略にも深く関与する基幹システムを支援して貰えるベンダーの選定は、非常に重要であるため、全社的に合意を取った上で進める必要があります。つまり、今後の基幹システム再構築プロジェクトの開始に向けて、企業としての一体感、コンセンサスを得ることが重要なのです。
よく、幹部の中から、「ITは分からないから情報システム部門で決めて貰いたい」というような意見をもらう場合もありますが、企業の基幹システムはITよりも業務のほうが重要であり、これを実現するのがIT、基幹システムなのです。よって、このITの選択を間違えると、企業のIT戦略、ひいては企業戦略全体にも大きな影響を与えます。

最後に、この「ステップ5:ベンダー及びパッケージ選定プロセスのポイント」で私からお伝えしておきたいことがあります。

それは、基幹システム再構築開始前の「準備ステップ」を実施するにあたり、推進体制はIT部門だけではなく、業務部門を考慮したベストメンバーをあてていただきたいということです。当然、現場の業務メンバーは常に多忙であり、時間や費用面で人材リソースにも限りがあるのは承知しています。しかし、メンバーの採択はそれだけ重要なことであると私は認識しております。そして、決して「基幹システムの再構築」プロジェクトの開始を焦らず、じっくりこの「準備ステップ」も重要なステップの一部と認識し、全社的に進めてください。先ほど「企業としての一体感、コンセンサスを得ることが重要」と言わせていただいた理由はここにもあります。
 
私は、これまで国内外の多くのプロジェクト、特にグローバルERP導入プロジェクトを見てきましたが、この準備フェーズで焦る、もしくは疎かにしたが故にプロジェクトが上手く行かなかったり、結果的にコストが大幅に増額したケースもありました。会社全体で準備フェーズをしっかり取り組むことで、プロジェクトの終盤で業務メンバーから満足のゆく承諾を得られず、本番運用が出来ないというトラブルも避けることが出来るのです。このようなトラブルは、過去多くの企業で発生しており、これは「プロジェクトの準備フェーズ」から推進体制に業務のキーパーソンをプロジェクトに巻き込んでいないことが原因だと考えられます。

そして、プロジェクト失敗の原因をベンダーやパッケージの責任にするケースが多くあるようです。その原因を追求すると、結局は企業側がこの「準備フェーズ」を疎かにして強引にプロジェクトを進めてしまった、あるいは、プロジェクト開始後の企業側のプロジェクトマネージメントが上手くいっていなかったケースが多いと考えられます。これは、ベンダーに多くを任せてしまっている、もしくは企業側のPMにマネージメントスキルが不足している等、企業側にも様々な課題があるが故に発生しています。しかし、これらは事前にPMがリスクマネージメントをすることにより多くの課題は回避することが出来ます。これを称して「プロジェクトマネージメント」、その「リスク管理」を実行する人をPM(Project manager)といい、単にプロジェクトの進捗結果をフォローするだけではPMとは言えません。
PMやMO(Project Management Office)に関しての詳細は、また別のコラムでの解説としましょう。

私の一連のコラムでは、これまでの私の経験をもとに、今後「IT分野での2025年問題」や「2025年の崖(経済産業省のレポートより)」に対応するために、「基幹システムの再構築」を早急に実施しようとしている企業が、少しでも再構築プロジェクト成功のための参考になる情報をコラムの中で提供させていただきます。
そして、プロジェクト開始後も重要な「ITプロジェクトマネージメント」の失敗事例や成功ノウハウも含めて、この一連の「準備フェーズ」のコラムの中で、併せて随所にふれさせていただきます。

執筆者H.K氏

大阪大学工学部卒業後、電機業界の大手企業に入社し、情報システム事業部門勤務。米国への社費留学にて、コンピュータサイエンス修士号取得後、米国・東南アジア・欧州の関連会社に出向駐在を経験。日系企業の基幹システム導入支援等を多数実施。定年後はIT顧問として活動中。英語・海外関連著書30冊以上あり

関連コラム

ページTOPへ戻る