複数ベンダーが並ぶプロジェクトで、発注者側のPMOが握るべきこと

大きなシステム刷新では、ひとつのプロジェクトに複数のベンダーが並ぶことがよくあります。基幹システム、周辺の業務システム、基盤やネットワークを、それぞれ別のベンダーが担う、といった形です。各社はそれぞれの契約の範囲で責任を持って動きます。問題が起きやすいのは、その範囲と範囲の間です。

この記事では、発注者の側に立ってプロジェクト全体を見るPMOが、複数ベンダーの体制で何を押さえておくべきかを書きます。テーマは4つです。ベンダー間の境界、共通の課題管理、日程の結合点、そして会議体の設計です。発注者の組織に業務委託で入り、全体のとりまとめを任された場面を想定しています。

発注者側のPMOは、どのベンダーの代わりでもない

最初に、立ち位置をはっきりさせておきます。発注者側のPMOは、特定のベンダーの味方でも、ベンダーの作業を肩代わりする人でもありません。発注者の立場から、プロジェクト全体がつながって動くようにするのが役目です。

各ベンダーは、自社の契約の範囲を守ろうとします。これは当然のことで、責めることではありません。ただ、その結果として、どの社の範囲にも入っていない仕事が生まれます。たとえば、2つのシステムの間でデータを受け渡すとき、データの形式をだれが決めるのか。受け取った側でエラーが出たとき、原因を調べるのはどちらなのか。こうした仕事は、だれかが拾わないかぎり、だれも手をつけません。

たとえば、結合テストの直前になって、片方のベンダーは「仕様書のとおりに送っています」と言い、もう片方は「仕様書の解釈が違う」と言う場面です。どちらも嘘はついていません。隙間を早い段階で見つけて、持ち主を決めておくこと。それが発注者側のPMOがまず握っておくべき仕事です。

発注者の内部にも、隙間はあります。業務部門、情報システム部門、調達や契約の部門では、プロジェクトへの関わり方も関心も違います。ベンダーから質問が来たとき、だれが答えるのかが決まっていないと、回答が遅れたり、部署によって違う答えが返ったりします。ベンダーとの境界だけでなく、発注者の中で、どの種類の問いにどの部署が答えるのかも整理しておくと、全体の動きがなめらかになります。

ベンダー間の境界を一覧にする

隙間を見つけるために、まずベンダー間の境界、つまりインターフェースを一覧にします。システムどうしのデータ連携だけでなく、業務や作業の受け渡しも含めて洗い出します。

一覧に載せる項目は、たとえば次のようなものです。

• 境界の名前と、関わるベンダー
• 受け渡すもの（データ、ファイル、画面の遷移、作業の結果）
• 仕様を決める側と、それに合わせる側
• 仕様の確定日と、確定の判断をする人
• テストの責任の分け方と、障害時の一次切り分けの担当

この一覧づくりで外せないのは、「仕様を決める側」を一つに決めることです。両方のベンダーが相手に合わせるつもりでいると、仕様はいつまでも決まりません。どちらが決めるかを発注者として決め、合意を議事録に残します。どうしても決めきれない境界は、発注者自身が仕様の持ち主になる、という判断もあります。

一覧の初版を、PMOが一人でゼロからつくる必要はありません。各社に、自社の範囲の外とやり取りするものを挙げてもらい、それを突き合わせる方法が効率的です。一方の社が挙げたのに、もう一方の社が挙げていない境界があれば、そこが認識のずれている場所です。突き合わせの結果を全社に見せ、抜けや食い違いを一緒に埋めていくと、各社が自分の責任の範囲を見直すきっかけにもなります。

気をつけたいのは、一覧をつくって終わりにしないことです。プロジェクトが進むと、境界は増えたり変わったりします。新しい機能の追加や範囲の変更があったときに、境界の一覧も見直す、という手順を決めておきます。

課題管理は、一つの表で全体を見る

ベンダーごとに課題管理表を持っていると、ベンダーをまたぐ課題がどこにも載らない、あるいは2つの表に別々の書き方で載る、ということが起きます。発注者側のPMOは、全体を見渡せる共通の課題管理の仕組みを用意します。

やり方は現場によって違いますが、基本は、ベンダーをまたぐ課題と、発注者の判断が必要な課題を、一つの表に集めることです。ベンダーの社内だけで完結する課題まで全部を集める必要はありません。何を共通の表に載せるかの基準を決め、各社に伝えます。

たとえば、起票のルールとして「他社の作業に影響する課題」「発注者の判断が必要な課題」「日程の結合点に影響する課題」は共通の表に載せる、と決めておきます。担当の欄には会社名ではなく、個人の名前を書きます。会社名だけだと、社内でだれが持っているのかが外から見えず、確認のたびに手間がかかります。

複数のベンダーにまたがる課題では、課題の持ち主を発注者側に置くのが基本です。ベンダーのどちらかを持ち主にすると、もう一方の社への働きかけが「他社からの依頼」になり、動きが鈍くなりがちです。発注者側の担当者が持ち主になり、各社に作業を割り振る形にすると、話が進みやすくなります。

原因がどの社にあるか分からない課題も出てきます。たとえば、結合テストで画面に表示される数値が合わないが、送る側と受ける側のどちらに原因があるのかがまだ分からない、という場面です。こうした課題で、どちらの社が先に調べるかを決めずにおくと、互いに相手の調査結果を待って時間が過ぎます。原因の切り分けをどの社がいつまでに行うかを、発注者がその場で決めて課題表に書きます。原因が分かったあとで、修正の担当と費用の扱いを改めて話し合えばよいのです。

各社が使っている課題管理のツールが違うこともあります。その場合、各社に共通の表への転記を頼むことになりますが、二重の手間になるので、載せる項目は最小限にします。課題の要点、影響する範囲、担当者、期限、状態くらいで十分です。詳しい経緯は各社のツールに置いたままにし、共通の表から参照できるようにしておけば、手間を抑えながら全体を見渡せます。

日程は「結合点」から押さえる

各ベンダーは、それぞれのWBSを持って日程を管理しています。発注者側のPMOが各社のWBSを細かく見る必要はありません。押さえるべきは、各社の日程が互いに依存し合う点、つまり結合点です。

結合点は、次の手順で洗い出します。

1. 各社のWBSから、他社の作業を前提にしているタスクを挙げてもらう
2. その前提が、どの社のどの作業の完了なのかを書き出す
3. 前提となる作業の完了予定日と、待っている側の開始予定日を並べる
4. 余裕が少ない、または日付が逆転している組み合わせに印をつける
5. 印のついた組み合わせを、共通の日程表に載せて定例で確認する

結合点になりやすいのは、インターフェース仕様の確定、テスト環境の準備完了、テスト用データの受け渡し、本番切り替えのリハーサルといった点です。どれも一社だけでは完了できず、一社が遅れると他社の日程が連鎖して崩れます。

結合点の日程は、各社のWBSとは別に、発注者が持つ共通の日程表で管理します。各社の進み具合の報告とは別に、結合点の一つひとつについて「予定どおりか」「遅れる兆しはあるか」を定例で確認します。遅れの兆しがあれば、関わる各社を集めて早めに打ち手を話し合います。

結合点で遅れが出たとき、どう対応するかを決めるのは発注者です。待っている側の作業の順番を入れ替えるのか、仮のデータや仮の仕様で先に進めるのか、全体の日程を見直すのか。どの選択にも、費用や品質への影響があります。PMOは選択肢と影響を整理して、発注者の責任者が判断できる形にまとめます。ベンダーどうしで話し合って決めてもらおうとすると、どちらも自社に不利な案を避けるので、なかなか結論が出ません。

会議体は、全体と個別と横断を分けて設計する

ベンダーが増えると、会議も増えます。何でも全社が集まる会議で話そうとすると、関係のない話を長く聞く時間が増え、肝心の話が深まりません。会議体は、目的ごとに分けて設計します。

よく使われるのは、全体の定例、ベンダーごとの個別の定例、テーマごとの横断の会議という3つの組み合わせです。全体の定例では、結合点の状況と、ベンダーをまたぐ課題を確認します。個別の定例では、その社の進み具合や、その社だけに関わる課題を扱います。横断の会議は、データ移行やテストの進め方など、複数の社が関わる技術的なテーマごとに、必要な人だけを集めて開きます。

たとえば、ある社の作業の遅れについて、原因が体制や品質の問題にありそうな場面です。これを全体の定例で取り上げると、他社の前で問題を指摘されることになり、相手は身構えてしまいます。こうした話は個別の定例で扱い、全体の定例には、他社に影響する部分だけを結論として持ち込みます。

情報の伝え方は、各社に対して公平にします。ある社にだけ先に伝えた情報が、別の社には遅れて伝わると、不信感が生まれます。全社に関わる決定は、全体の定例か、全社宛ての連絡で同時に伝えるようにします。

会議体を決めたら、一覧にして各社に配ります。会議の名前、目的、頻度、参加する会社と役割、議事録の配布範囲を書いておきます。特に議事録の配布範囲は、個別の定例の内容が他社に流れないよう、はっきり決めておく必要があります。どの会議に、どの社から、だれが出るのかが分かっていれば、各社も自社の体制を組みやすくなります。

契約と情報の線を越えない

複数ベンダーの体制で動くとき、発注者側のPMOは、契約と情報の線を意識しておく必要があります。早く物事を進めたいあまり、この線を越えてしまうと、後で大きな問題になることがあります。

一つは、ベンダーへの依頼の経路です。各社への依頼は、契約で決められた窓口を通して、発注者の名前で行います。PMOが業務委託で入っている場合、自分の判断で各社に作業を依頼してよいかどうかは、発注者との取り決めによります。どこまで任されているのかを、発注者の責任者と確認しておきます。

もう一つは、情報の扱いです。ある社の見積や単価、体制の情報を、別の社に見せてはいけません。各社の成果物を他社と共有する場合も、秘密保持の取り決めの範囲を確かめてからにします。共有フォルダのアクセス権を、ベンダーごとにどう分けるかも、早い段階で決めておきます。

ベンダーどうしが直接やり取りしてよい範囲も決めておきます。インターフェース仕様の細かい確認のように、技術者どうしで直接話したほうが早い話はたくさんあります。すべてを発注者経由にすると、伝言ゲームになって時間がかかります。一方で、直接のやり取りの中で、仕様の変更や作業の分担が勝手に決まってしまうのは困ります。技術的な確認は直接してよい、ただし決めたことは発注者が出る場で確認する、といった線を引いておくと、速さと統制の両方を保てます。

契約の範囲を変えるような話が出てきたら、PMOがその場で引き受けたり約束したりせず、発注者の責任者と、契約を担当する部署に回します。契約や秘密保持の解釈で迷うときは、発注者の法務部門などの専門家に確認してもらってください。

最初の一手は、境界の一覧を1枚つくること

複数ベンダーのプロジェクトで握るべきことは多くありますが、すべての出発点は、ベンダー間の境界がどこにあるかを知ることです。もし今のプロジェクトに境界の一覧がなければ、まずは知っている範囲で1枚つくってみてください。仕様を決める側が空欄のまま残る境界があれば、そこが次に手を打つべき場所です。