ITによる企業変革の最終準備──失敗しないベンダー選びと実行計画の立案

情報提供／監修：
マネジメント・プロセス・コンサルティング株式会社
代表取締役社長　巻幡 雄毅氏

▼次世代リーダー必見！巻幡氏のWebセミナーをオンデマンド配信中！
【セミナータイトル】企業変革、準備が成否の8割を決める～第6回：ベンダー選定の進め方
【セミナータイトル】企業変革、準備が成否の8割を決める～第7回：実行プロジェクト計画立案のポイント

ベンダー選定の進め方

企業変革のためのITシステムを築くに際して、どのようなベンダーを選び、実行プロジェクトの計画をどう策定するかは、最終的な準備作業であり、プロジェクトの成否に大きくかかわるプロセスです。

このうち、ベンダーの選定においては、「この仕事を誰に“任せる”のが適切か」という考え方で選定を進めようとする方がまま見受けられますが、これは間違いです。というのも、企業変革はベンダーに「任せる」ものではなく、「自ら行うべき」ものだからです。ですから、自社のプロジェクトを任せる相手ではなく、手伝ってくれる相手を探しあてるという視点を持つことが大切と言えます。

この選定のプロセスは、大きく「選定準備」と「選定実施」の2つの作業に分かれます。

このうち選定準備とは、何を重視してベンダーを評価するかの軸を定めて、提案を募る候補を絞り込み、それらの候補に提案をもらうための「RFP」を作成する作業を指しています。一方の選定実施においては、説明会の実施や提案書の評価、社内の合意形成などを行います。

言うまでもなく、プロジェクトには期限があります。その期限どおりにプロジェクトの各タスクをこなす体制を築くための準備作業が、ベンダー選定であるとも言えます。

ということで、以下では、「体制づくり」という観点から、ベンダーに対する「提案依頼」や、提案の「評価選定」をどう行っていくかについて説明します。

「選定依頼」と「評価選定」のポイント

ベンダーに提案を依頼するときの出発点は、プロジェクトのタスクとしてどのようなものが存在するかを明確にすることです。

例えば、プロジェクトの構成要素には、「プロジェクト運営」「業務」「システム(アプリケーション、インフラ)」「移行」「教育／展開」などがあります。そして、これらの要素にひもづくかたちで「プロジェクト準備」「要件定義」「基本設計」「詳細設計、開発」「テスト、移行」「稼働後フォロー」といったタスクが存在します。

これらのタスクは、すべて遂行すべきもので「やるべきタスク」と表現できます。その「やるべきタスク」と「想定体制」とのギャップを埋める作業が、すなわち、社外のベンダーに提案を依頼するという作業になります。また、この作業を行ううえでは、「道具を選ぶ」「人を選ぶ」「道具＋人を選ぶ」という選定パターンの中から、どれを選ぶかを検討することも必要になります。

このように、ベンダー選定は体制構築の一環です。「やるべきタスク」と社内リソース全体を見渡して、社内的なスキルやノウハウの不足を補うためにベンダーの助けを求めるのか、それとも量的に足りない部分をベンダーに補ってもらうのかを、しっかりと見定めておくことが肝心です。

一方、評価選定は大きく「（ベンダーの）提案の輪郭を把握する」ことと、「評価項目・重みづけを決める」ことの2つに分けることができます（図1）。


図1：評価選定のポイント（スライドP.9）

このうち、提案内容を把握する作業は、プロジェクト開始後に発生する齟齬を解消する手だてと言えます。

例えば、提案依頼の際によく見受けられる問題の一つとして、「情報の非対称性から十分な提案依頼を出せない」という点が挙げられます。

ベンダーは、基幹システム刷新・再構築の案件を数多くこなし、相応の知見・情報を保持している場合が多くあります。ところが、提案依頼を出す側のユーザー企業は、基幹システム刷新・再構築にかかわる頻度がとても少なく、10年に一度、あるいは20年に一度あるかないかです。そのため、ベンダーとユーザー企業がそれぞれ持つ知見・情報に圧倒的な格差（つまりは、非対称性）があるのが通常で、結果として、ユーザー企業がどのような提案をベンダーに依頼すべきかがわからなくなり、依頼内容が不明確になることが非常に多いのです。

依頼内容が不明確であると、ベンダー側の提案は「やるべきこと」よりも、自社が「やれること」を優先させるような内容になりがちです。したがって、ユーザー企業はプロジェクトの大きな絵の中から、ベンダーにして欲しいことをしっかりと切り取って提示することが重要です。

また、ベンダーがユーザー企業に出す提案書は自己PRのツールでもあります。それゆえに、どのような前提・仮説に基づいて、その提案になったかの説明が不十分であることが珍しくないのです。

上述したような問題を解決せずにいると、実際のプロジェクトが始まったのちに、ユーザー企業の期待とベンダーの作業との間にズレが生じ、結果として、費用が想定をはるかに超えるかたちで膨れ上がってしまう事態に陥りかねません。それを避けるための手だてが、「（ベンダーの）提案の輪郭を把握する」という作業です。

ここでは、例えば、ユーザー企業が「どのようなインプットをすると、どのようなアウトップにつなげてくれるのか」といった点を明らかにしていきます。また、提案の前提として、ユーザー企業の工数や意思決定のスピードをベンダー側がどのように見積もっているのか、あるいは期待しているかといったことも確認する必要があります。さらに、提案の対象業務／システム領域（＝対象のスコープ）や支援対象の業務範囲なども明確にすることが必要とされます。

一方、評価項目の重み付けでは、表を作り、分野ごとに評価項目を設定して、配点・重み付けを行います。あらかじめ評価の仕方を整理しておいて、評価選定に入っていきます。

「選定準備」と「選定実施」の具体的なステップ

次に、具体的な作業ステップを見ていきます。

まず、選定準備については「選定の位置づけ検討・確認」「提案依頼先企業の検討」「評価軸の整理・確認」といった作業があります。これらを実施し、提案依頼書と提案要項を作成していきます（図2）。


図2：選定準備の作業ステップ（スライドp11）


提案依頼書はいわゆるRFPで提案してほしい内容をまとめたもので、提案要項は実施にあたって留意してほしいポイントをまとめたものです。

提案要綱とは、「いつの時点で、こういった形式で提案書を出してください」「プレゼンはこういうルールでお願いします」「記載項目はこういうものを網羅してください」といったポイントを明記していきます。

続く、選定実施では、「提案依頼説明、提案説明会」の実施、「評価・選定・通知」を行います。説明会を実施し、提案書とプレゼンを比較・評価し、結果を、「評価結果報告書」としてまとめます。これらを終えたら、実行プロジェクトの計画立案に入っていきます。

実行プロジェクトの計画を立てる

言うまでもなく、企画・構想・選定の最終的なゴールはプロジェクト計画書を作ることです。この「最終的なプロジェクト計画書」においては、「あとはやるだけ」「できると確信が持てる」というレベルになるまで計画を具体化させておくことが肝心です。その作業を進めるうえでの重要なポイントは、プロジェクトにおける各種の輪郭・境界線を明らかにすることと、タスクのインプット／アウトプットを、その確認方法を含めて明らかにすることです。

また、ベンダーからもらう「提案書」と、ユーザー企業が策定する「プロジェクト計画書」は非常に似ていますが、違うものです。言い換えると、違いを知ることで、ベンダーの提案書以外に何を考慮しなければいけないのか整理することができます。

提案書は、ベンダーのポテンシャルを表現したもので、特定の前提や仮説に基づいて作られています。これに対して、プロジェクト計画書は、プロジェクトメンバー全員に、それぞれの役割や活動、さらにはプロジェクト運営方法を理解させ、プロジェクトの開始から終了までをガイドするための資料です。

さらに、活動範囲に関しても、提案書のそれは、通常システム構築のための活動しか記載されていませんが、プロジェクト計画書で定義する活動範囲は、業務運用体制の構築から組織役割変更の活動、マネジメントプロセス、規定、基準の構築までを含みます。

「範囲」「スケジュール」「体制/役割・運営方法」に留意する

次に、実際にプロジェクト計画を策定するうえで必要になる切り口を説明します。

切り口はいくつかありますが、ここでは「範囲」「スケジュール」「体制/役割・運営方法」という3つの視点で見ていきます。

まず「範囲」とは、スコープのことです。計画書ではスコープの明確化が必要とされますが、その際のポイントは、対象だけを抜き出して定義するのではなく、対象ではないものも明確にしておくことです。具体的には、業務フローやシステム鳥瞰図、組織図などをベースに、全体の中でスコープを切り出して見せるという表現方法を使い、「業務」「システム」「組織」というそれぞれの切り口について、相互の関係性／網羅性をチェックできるようにしておくことです（図3）。


図3：実施プロジェクト計画の視点(1)範囲（スライドp9）


次に「スケジュール」という視点ですが、ポイントは「いつまでに、何をするか」を、フェーズ単位で分割し、それぞれの想定ゴール、完了方法、必要な準備を明確にすることです（図4）。想定ゴールは、各種アウトプットの作成作業完了だけでなく、合意形成まで含めて考慮する必要があります。また、完了の確認方法と確認に必要な準備は必ず明確にしておきましょう。


図4：実施プロジェクト計画の視点(2)スケジュール


3つ目の視点である「体制/役割・運営方法」では、プロジェクトの透明性を担保することが重要です。そのために、プロジェクト運営は「進捗管理」と「課題管理」の2点に集約して、シンプルに運営する事をお勧めします（図5）。

また、進捗管理では、マスタースケジュール、週次、日次といったように、会議ごとに異なる粒度のスケジュールを共有しながら進捗を管理していきます。課題管理は、「誰がボールを持っているかがわからない」という状態にしないために実施するものです。


図5：「体制/役割・運営方法」で留意すべきポイント（p13）

企業変革は準備が成否の8割を決める

以上、全3回にわたり、企業変革に必要なマネジメントプロセスと、構想策定のポイント、ベンダー選定とプロジェクト計画立案のポイントを紹介してきました。それを通じて最もお伝えしたかったことは「企業変革はチャレンジではない。絶対に実現できる」ということです。

チャレンジという言葉には「やってみる」「できなくてもしょうがない」というニュアンスが含まれていますが、企業の変革には「絶対にできる」というスタンスで臨んでいただきたいと思います。加えて言えば、変革は正しく設計することが何よりも大切です。設計できないものは実現できませんが、設計できたものは必ず実現できるのです。

変革は準備が成否で8割が決まります。ぜひ、「企画」「構想」「選定」というフェーズを通じて正しく設計し、変革を実現させてください。