分からないまま進めない――調達マネジメント（2）：プロジェクトマネジメントスキル 実践養成講座（10）（2/2 ページ）
期待に応えてくれるベンダの見極め方
その後、初目手部長はX社と価格交渉をしてみたが、X社からは快い返事が返ってこなかった。困った彼は、知り合いの経験豊富なプロジェクトマネージャに相談してみることにした。
初目手部長 「X社、Y社のどちらにしようか迷っている。提案内容は両社とも問題なさそうで、信頼感でいけばX社がいいように思うのだが、価格的にはY社の方が2割も安い。どうすればいいか？」（先の表1を見せながら説明）
出来杉マネージャ 「これで決めるのは、運を天に任せるようなものですね（苦笑）。決定する前に、もう少し深く検討する必要があるかと思います」
初目手部長 「深く検討するといっても、何を検討すればいいのかよく分からない。教えてくれないか」
出来杉マネージャ 「分かりました。検討ポイントを整理してみましょう」
『提案内容』は、両社とも要望をおおむね満たしているので『○』とひとくくりにしていますが、貴社の要望は1つではないと思います。システム機能についての要望でも多くの要望があるでしょう。システム機能以外にも性能（パフォーマンス）への要望もあれば、作業の役割分担の要望もあるでしょう。このような多くの要望に対して両社の提案は本当に互角なのでしょうか。
『価格』については、Y社の方が安いとのことですが、両社の見積範囲は同じなのでしょうか。仮に同じ場合、Y社の安さの理由はどこにあるのでしょうか。またその価格は、開発費用だけでなく、稼働後の運用コストを考慮しているのでしょうか。
『信頼感』の評価理由にX社の担当者と過去に仕事をしたことを挙げていますが、その人がいれば本当に今回のプロジェクトを安心して任せられるのでしょうか。ほかの見方でも信頼感を測る方法が何か必要ではないでしょうか。
『提案内容』『価格』『信頼感』という3つの項目で評価していますが、なぜこの3つで評価しているのでしょうか。この3つだけで十分なのでしょうか。
初目手部長 「なるほど。まだ検討不足だったようだな。もう少し考えてみるとするか」
基本的にベンダ選定のゴールは、「適切な価格」で「期待に応えてくれる」企業を選ぶことにある。ここで注意しないといけないことは、「期待に応えてくれる」ことが第1で、「価格」が第1ではないことである。つまり、いくら安くても期待に応えてくれなければ意味がなく、安ければよいということでは決してないということだ。期待に応えられる企業かどうかの見極めが甘く、後になってトラブルになり、「誰がこんなベンダを選んだのか」という事態に陥ってしまうことはよくある。では、期待に応えてくれるベンダかどうかを見極めるための勘所を解説する。表2にベンダ選定の評価項目とポイントを整理するのでご覧いただきたい。
| 視点 | 評価項目 | 評価のポイント |
|---|---|---|
| （1）分かっているか | 理解力 | RFP（ニーズ／要件）の理解度、充足度を提案書、プレゼンテーション、質疑応答を通じて確認する |
| （2）実現可能か | 実現可能性 | ベンダの提案ソリューション（回答）に対する実現可能性とリスクを確認する ベンダ側は「大丈夫です」といい張ることもあるので、不明な点は、第三者（社内外の有識者）の意見を参考にするとよい |
| （3）知っているか | 技術力 | 提案内容に関連する他プロジェクトでの実績を確認する。「関連する」という点がポイントで、業界、アプリケーション領域、技術環境などの観点で類似プロジェクトの経験有無を見る 注意すべきは、会社としての実績だけでなく、より重要なのは「実際に参画するメンバーの経験有無」である |
| （4）回せるか | マネジメント力 | 開発・テスト手法、変更管理、進ちょく管理などプロジェクト管理手法を確認する プロジェクトマネージャの人柄、コミュニケーション力（うまくやっていけそうか）を確認する |
| （5）信頼できるか | 企業力 | 財務状況、パッケージベンダ選定時には比較的多い外資系企業では、場合によっては本国の方針でプロジェクト中に日本撤退ということもあり得るので、特に注意が必要 組織（規模）――小規模の会社には、何かあったとき（トラブル発生、キーパーソンの病気・退職など）にリカバリーが利かない効かないというリスクがある 社会的信用不安の有無――財務状況だけでなく、不祥事や係争案件の多さなどにも注意が必要 |
| （6）価格は妥当か | コスト、パフォーマンス | 見積もりの前提や範囲は適切か 各社間の差を確認する場合は、単純に金額だけでなく包含されている作業（成果物）範囲を併せて考える 導入コストと運用コストのトータルで比較する 内部または第三者が見積もりを作成し、その金額と比較する |
| 表2 ベンダ選定の評価項目とポイント | ||
期待に応えられるベンダかどうかを判断するためには、（1）ベンダが目的や課題、要望を正しく理解しているかどうかをまず見極める必要がある。しかし、（2）分かっていても提案内容が実現可能でなければ意味がない。（3）さらに実現可能でも実際にスキルがなければ意味がない。また、（4）スキルがあっても実際にプロジェクトを推進していけるかどうかは別問題で、マネジメント力も見極める必要がある。そして、（5）個人のメンバーに依存しない組織の問題として、企業が信頼できるかどうかを確認する必要がある。これら5つの項目に、（6）妥当な価格かどうかを加えて総合的に評価する。ぜひ、ベンダ選定の勘所として押さえていただきたいポイントである。
ベンダの作業管理の勘所
ベンダ選定が無事終わったからといって、後はお任せでというわけにはいかない。ベンダの作業管理として「進ちょく」と「品質」をマネジメントする必要がある。
この勘所は、「当たり前のことを当たり前にやっていくこと」である。進ちょく管理でいえば、タスクの全体像の洗い出しがきちんとできているか、マイルストーンは設定されているか。遅れが生じた場合、原因を把握できているか、そのキャッチアップは気合でやりますという精神論ではなく、合理的理由のある対策であるか。また、品質管理でいえばレビュー、テストの結果確認をきちんと行っているかなどが挙げられる。
しかし、当たり前のことをやるといっても、これがなかなか難しい。ベンダの作業管理を難しくしている要因の1つに「プロジェクトのマルチベンダ化」が挙げられる。最近のプロジェクトでは、複数のベンダが参画するケースは一般的である。複数のITベンダと取引している企業は全体の7割以上に上っているという調査結果もある。
そこで以下では、マルチベンダ・マネジメントの勘所を解説することにしよう。
まず、とある基幹システム構築プロジェクトの体制図（図1）をご覧いただきたい。
図1 プロジェクト体制図この例では、3つのアプリケーション領域とインフラをそれぞれ別のベンダが担当しており、今回の中心は会計システムの再構築であるので、B社がメインベンダである。
しかし何かトラブルが起こっているようだ。様子をのぞいてみよう。
E社 「初目手さん、ハードウェアの要件をそろそろ決めていただかないと、納期が間に合わないのですが。大まかなデータやトランザクションの見積もりが決まっていれば、それを基にこちらで提案しますが」
初目手部長 「B社が考えていて、そろそろできてくるころだと思う。B社から入手して送るよ。少し時間をくれないか」
（B社に連絡する）
初目手部長 「ハードウェアの見積もりに使いたいので、データとトランザクションの見積もりが必要なのだが、もうできているかな？」
B社 「ちょうど作成して承認をいただこうとしていたので、お送りします」
（B社から見積もりを受け取り、E社に送る）
初目手部長 「先日の件、B社からもらったのでさっきメールで送ったよ。あれでいいかな？」
E社 「ありがとうございます。いま中身を確認しますね。えっと……。
あれ！？ これ、会計領域の分しかありませんが、受注と在庫の分はどこでしょう？」
初目手部長 「ないのか。B社が先にできた分だけ送ったのかな。B社に確認してまた連絡するので、ちょっと待ってくれないか」
（B社に再度確認のため連絡をとる）
初目手部長 「先ほどの見積もりの件だが、会計領域の分しかなかったようだが、ほかの分はいつごろできそうかな？」
B社 「えっ！？ 弊社の担当は会計領域なので、会計の分しか作っていませんよ。C社とD社が作っているのではないでしょうか」
初目手部長 「何だって？ ハードウェア見積もりのためにデータとトランザクションの見積もりをお願いしたじゃないか。全部の領域が必要なのは当然だろ」
B社 「おっしゃるとおりですが、弊社の担当は会計領域で、それ以外のところはC社とD社の担当です。それをわれわれが作るのは無理な話ですよ」
初目手部長 「誰も実際に作るのが御社ということはいっていない。御社はメインベンダとしてこのプロジェクトに参画しているのだから、あなた方が中心となってC社・D社に作成を依頼し、それを取りまとめるくらいするのが当然ではないか」
B社 「確かに弊社は今回のプロジェクトでは会計領域を担当しておりメインベンダだと認識しております。ただ、あくまで担当は会計領域のシステム構築で全体のプロジェクトマネジメントは、A社のご担当という認識ですが」
初目手部長 「何をいっているのだ。あなたがたはメインベンダなのだから、とにかくC社とD社に働きかけて取りまとめてもらわないと困る」
B社 「そういわれましても……」
複数のベンダが参画するプロジェクトでは、「ベンダ間の役割分担（責任分解点）を明確にせよ」ということがよくいわれる。もちろんこれは正しい。担当領域（やるべき作業）を事前に洗い出し、誰が何をやるということを事前に確認しておく。これにより、作業の抜け漏れや重複の回避に役立つ。しかしそれだけでは十分とはいえない。いくら事前に役割分担を明確にしても、プロジェクトを進めていくと想定外の作業が発生したり、担当の切り分けが難しいグレーゾーンの作業が発生したりするためだ。
このことを例示した図2をご覧いただきたい。
図2 Aさんの敷地を掃除するための役割分担と残ったゴミAさんは、敷地の掃除をB〜Eさんに依頼した。B〜Eさんの分担は図のように境界線を引いて決めた。各自、自分の領域はきれいにした。しかし、4人の境界線上にゴミが1つ残っている（図2の真ん中の部分）。
このようなとき、誰も手を付けずに、互いに自分の責任ではないことを主張する。これではいつまでたっても問題は解決しない。誰かがやらなければ目標を達成できないのである。
大事なことは2つある。1つは「全体を見渡す」という役割が必要なことで、それを誰がやるかを初めから決めておくことである。つまり、名前だけのプロジェクトマネージャではなく、プロジェクト全体の内容、進ちょく、課題、リスクなどをコントロールしていく真のプロジェクトマネージャである。発注者が自ら行うことが可能であれば自らやってもよいし、困難であれば、ベンダや外部のコンサルタントに依頼するとよいだろう。
もう1つは、必要であれば参画するベンダの意識を改善することである。
これは先に述べたプロジェクトマネージャの役割の1つであるが、ベンダ側が自社の担当領域に固執するのではなく、「プロジェクト全体の目標達成に協力する」という意識を持ってもらうことである。想定外やグレーゾーンのタスクについてもプロジェクト全体の目標達成には必要であり、前向きに解決していくような働きをしてもらうことが必要となる。
具体的な施策としては、進ちょく会議の場などで全ベンダが定期的に一堂に会する場を設けることをまず挙げておく。各ベンダから個別に進ちょく報告を受けるような進め方の場合、ベンダと全体感を共有することが難しくなるだけでなく、ベンダ間同士でのコミュニケーション機会も制限される。その結果、自社の担当領域に閉じた働き方につながる恐れがあるのだ。注意すべきは、このような場に営業担当だけが参加しているプロジェクトである。実務リーダークラスの参加が重要である。
進ちょく会議で全ベンダが一堂に会する場合、よく問題となることがあるので補足しておこう。進ちょく報告や課題の管理方法、いい換えれば、プロジェクト運営方法が、会社によってバラバラになることである。全体感が見えにくい、分かりづらいなどの弊害もあるので、あらかじめプロジェクトで統一したフォーマットやプロセスで運営することをルール決めしておくことをお勧めする。
今回のまとめ
- ベンダ選定においては、分からないことがあるままで先に進めない。必要な場合は、内部や外部の有識者の意見を活用すること（セカンドオピニオンの活用）
- ベンダ選定は、「期待に応えてくれる」企業を「適切な価格」で選定すること。そのための評価項目は、
理解力（分かっているか）
実現可能性（実現可能か）
技術力（知っているか）
マネジメント力（回せるか）
企業力（信頼できるか）
コストパフォーマンス（価格は妥当か）
- 複数ベンダ間の役割分担（責任分解点）を明確にすることも重要だが、それだけでは不十分
- 全体を見渡す「真のPM」を誰がやるかを明確にする
- ベンダ側が自社の担当領域に固執するのではなく、「プロジェクト全体の目標達成に協力する」意識を持ってもらう
- 全ベンダが一堂に会する場を設ける。その場合、共通のプロジェクト運営方針を定め、それに従い運営することも重要
著者プロフィール
杦岡充宏（すぎおかみつひろ）
スカイライトコンサルティング シニアマネジャー。米国PMI認定PMP。関西学院大学商学部卒業後、アンダーセンコンサルティング（現アクセンチュア）を経て現職。製造業や流通業のCRM領域において、業務改革やシステム構築のPM（プロジェクトマネジメント）の実績多数。特に大規模かつ複雑な案件を得意とする。外部からの依頼に基づき、プロジェクトの困難な状況の立て直しにも従事、PMの重要性を痛感。現在は、同社においてPMの活動そのものをコンサルティングの対象とするサービスを展開している。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。