ベンダ選択の手順
ITベンダ選択は準備に多少の時間をかけて行うことが望ましいです。拙速はベンダ選択を間違えたり、
ITベンダとの確認事項の漏れが生じやすいです。手順に沿ってベンダの評価基準と比較項目を常に頭
におきながらベンダ選択に関する情報を得ることを心がけて下さい。ＥＲＰパッケージを含む対象とす
べきパッケージ商品の保有がベンダ選択の前提です。ベンダ選択の手順はパッケージ導入とともに
システム開発でも同じです。
信頼できるベンダの選択は自社の努力なしにはありえないです。着実にしてクールに行うことです。
① 提案書の受理
・ 提案依頼書（ＲＦＰ）への回答有無の整理をします。未回答、未資料を洗出します。
・ 提案依頼書の項目ごとのベンダ別比較表を作成します。
② 内容検証・質問整理
・ 回答内容の意味不明・疑問点を洗い出し、整理します。
・ 回答内容で最もレベルが高く信頼できる内容を項目別基準にします。ベンダ別比較表
にその旨の印をつけておきます。
・ プレゼンテーション用のベンダ共通とベンダ個別の質問表を用意します。
③ プレゼンテーション
・ 進行役、質問者などの役割と時間割を決めて行います。
・ 「何を」重点にプレゼンを行っているかに注視し、自社要求への理解度をチェックします。
・ 担当予定のＰＭの発言に気をつけて、任せられる力量があるか否かをチェックします。
・ 下記の「評価レベル２」の内容を質問し、その答えの具体性・信頼性をチェックします。
・ 回答での持ち越しを確認し、回答の時期・仕方を確認します。
・ 各ベンダのプレゼン評価を自社の参加者から記述してもらいます。
④ 回答確認
・ プレゼンなどでの質問・留意情報への回答情報を入手します。約束日時を守らせます。
⑤ ベンダ評価
・ （参考）下記の「ベンダ選択の評価基準」
⑥ ベンダ決定
・ 決定に際してのベンダとの約束事項があれば、文書で通知すべきです。必要があれば、
両社の合意内容を文書で残すことが大事でです。
・ 作業開始の時期・内容をベンダと確認します。
選択手順での留意すべき点
① この基本手順に沿って行い、必要があればヒアリング追加・打合せを入れることも
構いません。ベンダとの接触が多ければ多いほど、情報の正確性は高くなります。
但し、各ベンダに対して平等に行うことです。
② 対象ベンダが多い場合は、上記①か③のステップで対象ベンダを絞ることです。
残ったベンダに対して、③ステップ以降を行うやり方もあります。当然、再度の提案
を受けることもありえます。
③ 自社の信用のためにも、上記日程は公開して行うことが大事です。
ベンダ選択の評価基準
ベンダ選択がパッケージ導入の成否に大きな影響を与えます。自社の弱みを考慮に入れ、下記の
評価内容を審査基準にしてベンダの評価と選択を行って下さい。
「評価レベル－１」の基準
① パッケージ商品の適合性
（参考）「パッケージ商品の選択方法」ページ
② 提案書作成の回答、誠意
・ ベンダ提案書（提案依頼書への回答）の回答有無、回答の分かりやすさ
・ 自社・業界の言葉の使用頻度と理解度 （→ベンダ言葉が多いのはダメ）
・ 自社向けのオリジナリティを重視して作成している内容
（→他社使用のコピーはダメ）
・ 提案依頼書以外での自社向けの提案、提示、課題提起の有無
・ 提案書のページ量でなく、内容による質での判断 （→分かり易さ）
→ この評価レベルで合格に到達していないベンダは、「評価レベル－２」に行く
必要性はありません。
「評価レベル－２」の基準
① ＰＭの力量
・ 自社プロジェクトへの参加度合い（専任か兼務か、使用できる時間）
・ 最終稼動までの責任を果たす役割（→途中交代は絶対ダメ）
・ 自社の課題・弱みへの理解とそれを解決できる能力、実績
・ 提案書でのＰＭ本人による作成ページの内容確認（→無しは不向き）
・ 経営的発想の有無／業務改善の実績／業務知識の保有の確認
・ プロジェクトマネ－ジャの経験と実績（→複数の経験がないと不適）
【参考】 ダウンロード資料＜070 プロジェクトマネ－ジャの評価方法＞
② SEの力量
・ 主担当のＳＥが評価対象になります。
・ 得意分野（アプリケーション、業務知識、技術、フェーズ担当）の確認
（→はっきり語れない人はダメ）
・ 自社要求（業務範囲、管理、課題）への理解と咀嚼力
・ ドキュメント作成の実績、コミュニケーション力、社会常識の保有
③ ベンダの体制
・ 体制の中に、協力会社（ＳＥ・ＰＧ）が存在する場合の責任と役割
（主要なシステムに対する責任担当がベンダ社員でない体制はリスク
が大きい。責任担当の経験と業務知識の確認が大事です。責任担当
が協力会社の作業管理がメインであれば体制の欠陥です。）
・ 担当の会社が３社以上の構成であれば、体制としてはマイナス評価
（プロジェクト運営とコスト面から自社にマイナスに働きます。）
・ 自社のプロジェクトに対する進捗・問題管理・品質管理の位置付け
（プロジェクト以外の担当者有無、レビューサイクル、問題解決の方法）
・ ＰＭを管理する責任者の役割とチェック方法、自社への報告サイクル
・ この体制の役割とタスクに対して、形式でなく実質的活動の保証
・ ベンダのスタッフ機能による自社プロジェクトへの指導と監視内容
④ システム機能の確認スケジュール
・ 導入方式が「フォターフォール型」でドキュメント主体のスケジュールは危険で
す。動く画面でのユーザ確認と仕様確認が早めに位置付けられているスケジュ
ールが重要です。
・ システム機能の最終確認（利用者の納得）はテストフェーズまでいくこと
を前提にした作業の仕方・スケジュールの確認です。
（利用者の我がままでなく必要不可欠として発生する可能性が大です）
・ 作業フェーズの組立てにおいて、利用者のシステム機能要求の吸い上げ
と対処方法です。
（自社もベンダも気づかないシステム機能の追加・変更は皆無とは言えま
せん。例外のパッケージもありますが）
⑤ 成功要因からの必要事項
・ プロジェクトを成功させるのに避けて通れない要因があります。プロジェクト
とシステムの機能要求からのリスクです。これらのリスク要因を前もって理
解し、防止策を講じることです。
・ これらの成功要因（リスク要因との背中合わせ）を自社の実情に照らし合
わせて、必要事項をベンダ評価の基準にすることです。
（参考） 「プロジェクトを成功させる要因とリスクマネジメント」
⑥ 総費用
（参考）予算と期待効果ページの「想定される予算項目の一覧」
ベンダ選択という名の「人の選択」
ベンダといった会社組織の選択とともにＰＭ・ＳＥの
選択という側面をもっているのが、この業界の特性
でもあります。パッケージ導入なりシステム開発は
担当するリーダクラスの資質に依存する比重がまだ
高いです。
それは企業活動における情報システムの利用価値
が深化を続けて いるのに、情報システムのパッケー
ジ化・ツール化が追いついていけない面があるから
です。それをカバーし、企業ニーズへの情報システム
の適用を行う作業を人の経験・ノウハウが支えている
のが現状です。また、情報システムの利用も単なる
業務処理の効率化から経営管理に直結した仕組みなり流通取引の変化への対応へとシフトしつつ
あり、情報システムの複雑化を招きつつあります。
情報システムの複雑化・多様化への対応とともに、ＰＭ・ＳＥに要求されているのが自社プロジェクト
への指導と目的達成へのガイド役です。自社の弱み・課題と発生する作業に応じたノウハウ・知識・
経験の提供です。ベンダの機能する体制をバックにしたＰＭ・ＳＥの力量と自社プロジェクト（＝力量）
がパッケージ導入の成功への両輪です。成功のカギは人と人の力量と信頼にあります。
（参考） 稼動体制とシステム評価ページの「プロジェクト成功の証し」
