要件定義のキックオフで、プロジェクト計画書をあえてベンダーに作ってもらう意味とは？

ベンダーからキックオフの連絡が来ない

「ベンダーとのキックオフ会議はどのように進めればよいですか？」

あるプロジェクトで、ようやくベンダーが決まりました。長い道のりでした。

RFPを作っているときは順調でしたが、その後、ベンダー選定で時間がかかります。決め手に欠き、社内で意見が割れ、追加のプレゼンを経て、ようやく決まったところです。

もともとのスケジュールより遅れたため、早く要件定義のキックオフを迎えたいのですが、その日程と内容がなかなか決まりません。

場数を踏んでいるベンダーであれば、キックオフの段取りが明確です。先方からすぐに連絡が来ます。しかし、そうでもないベンダーも少なくありません。

今回は後者で、キックオフの内容を問い合わせても

「現在内部調整中です」とか「顔合わせを行います」とか、曖昧な回答しかもらえません。

このような状況においては、自社の情シスPMOから積極的に仕掛けていく必要があります。

キーワードは「プロジェクト計画書」です。

どのようにアプローチすべきでしょうか？

プロジェクト計画は2回訪れる

プロジェクトは、立場の異なる様々な利害関係者と一体となって、進めるものです。そのため、難易度が高く、目的をはき違えたり、目指すゴールがバラバラだったりした場合、プロジェクトは空中分解してしまいます。

だからこそ「プロジェクト計画書」の存在意義があります。

プロジェクト関係者と「計画」を共有し、同じ方向性に進んでいくための「羅針盤」のようなものです。

このプロジェクト計画書ですが、作成および共有する場面は2回訪れます。

なぜ「2回」あるのでしょうか？

簡単な話で、関係者が変わるからです。

その2回のタイミングを整理してみます。
 

①社内プロジェクト立ち上げ時（社内キックオフ時）

IT戦略やDXなど全社的な上位の計画で、施策が決まったら、それを「プロジェクト計画書」に落とし込んでいきます。

まずは社内でプロジェクトを立ち上げるため、目的・ゴール・体制・スケジュールなどを定義します。そして体制図に書かれてある「経営層」「事業部門」「IT部門」の関係者全員で「社内キックオフ」を開催します。

ここで社内の認識を合わせ、全社的な承認も得ることができます。

 

②ベンダー共同プロジェクト立ち上げ時（要件定義キックオフ時）

ベンダー選定後、「社内メンバー」と「ベンダー」を交えて、あらためて「要件定義キックオフ」を行います。

そのキックオフ時に用いるのも「プロジェクト計画書」です。

同じ名前ですが、社内立ち上げ時とは内容が異なります。

採用したベンダーの「提案書」をベースにしており、システム寄りの具体的な内容まで盛り込んで書くものです。

あえてベンダーの意味

この要件定義キックオフに向けた「プロジェクト計画書」を作るのは誰でしょうか？

ベンダーです。

その理由は3つあります。

1つ目の理由は、ベンダーの提案内容を最終化するためです。

ベンダーの提案書はあくまで提案時の話であり、正式にユーザーが承認したものではありません。大筋で合意したからこそ選んだわけですが、細かい部分で調整は必要です。

この調整を行っていく「たたき台」となるのが、このプロジェクト計画書です。

もちろんシステム機能については、これから要件定義できちんと確認していきますが、プロジェクト計画レベルの調整は、最初に行わないと意味がありません。

特にそれぞれの体制や窓口、役割分担、成果物、スケジュールなどはとても重要なので、明確にしておく必要があります。
 

2つ目の理由は、ベンダーの理解度を測るためです。

例えば、自社が作ったプロジェクト計画書で要件定義キックオフを開催した場合を想像してみてください。

おそらくベンダー側から反論は出ないでしょう。

作った者でないと、その内容に当事者意識は持てないからです。そして計画に対して受け身になります。よほど不利な内容でない限り、わざわざベンダー側から指摘をして、手間を増やすようなこともしないでしょう。

だからこそ、プロジェクトの目的やゴール、新システムの方針などで、ベクトルがずれていないか、自社と認識が合っているかを「ベンダーの言葉」で語ってもらうのです。

そこで、ベンダーがこのプロジェクトで「腹落ち」しているかがわかります。
 

3つ目の理由は、ベンダーとの距離を一気に縮めるためです。

ベンダーが作成することで、これを説明するのは、ベンダー側のキーパーソンである「プロジェクトマネージャー」となります。

説明を受けて、ギャップが発生した部分は調整が必要なので「コミュニケーション」が生まれます。

管理者レベル、現場レベルなど、体制図のそれぞれのレイヤー同士で、調整・確認が自然な流れで行われます。

これが、自社とベンダーが「一枚岩」になっていく最初のステップなのです。

情シスの得意技

要件定義に入ると、成果物の主体がベンダーに切り替わっていきます。

この成果物の中心は「要件定義書」です。

しかし、最初の成果物は「プロジェクト計画書」であるべきです。

ベンダーに作らせるのは、自社が手抜きをしているわけではありません。

ましてや、自社が丸投げして受け身になっているわけでもありません。

ベンダーの理解度を「積極的」に確認するため、あえて依頼するのです。

なお、このプロジェクト計画書の扱いについては、事前に「RFP」で要求しておくべきです。その上で、ベンダーと契約手続きをしている裏で、このプロジェクト計画書の調整を進めていきます。

そうすることで、要件定義のキックオフをスムーズに開催できます。

そして、このようなベンダーとの調整は、「情シス」がPMOとして得意技とすべきです。最初の段階で、リーダーシップを発揮すれば、情シスが社内で信頼されるきっかけとなります。

貴社の情シス（情報システム部門・IT部門）は、ベンダーとの「要件定義キックオフ」をどのような段取りで進めていますでしょうか？