マルチベンダー体制による大規模サイト開発プロジェクトを成功に導くポイント（3）
「近年、大規模なWebサイトの開発を行う際「マルチベンダー体制」でプロジェクトを進めるケースが増えてきています。
WEBSASが発足して10年ですが、その間のWebサイトに関わるテクノロジーの進化やニーズの多様化も背景となり、当社も単独でなく他社開発ベンダー様と協力して、お客様のプロジェクトを推進する事が多くなっています。
そのような中で、PMBOKで語られるプロジェクト管理ノウハウをベースとしつつ、これまでのWEBSASの大規模Webサイト開発の経験を活かして、マルチベンダー体制でのプロジェクトを成功に導くポイントについて、いくつかご紹介させて頂きます。
第二回では、マルチベンダー体制におけるプロジェクトの「立ち上げ」・「計画（体制整備）」までのポイントについて、述べさせていただきました。
第三回では引き続き、プロジェクトの「計画」プロセスにおけるポイントについて述べさせていただきます。
- マルチベンダー体制による大規模サイト開発プロジェクトを成功に導くポイント（1）
- マルチベンダー体制による大規模サイト開発プロジェクトを成功に導くポイント（2）
- マルチベンダー体制による大規模サイト開発プロジェクトを成功に導くポイント（3）
- マルチベンダー体制による大規模サイト開発プロジェクトを成功に導くポイント（4）
「計画」プロセスにおけるポイント
プロジェクトの「計画」プロセスでのポイントについて述べます。
PMBOKの定義では「実行」プロセスのアクティビティも一部含まれますが、これまでの経験をもとに重要なポイントを挙げています。
プロジェクト全体のマイルストーンを確定する
前回の「計画」プロセスの中で、ベンダー選定を行いました。
各ベンダーからは、分割されたサブシステムのスコープ前提に基づく、プロジェクト計画（スケジュール）が提示されている状態にあります。
「事務局」としては、各ベンダーから提示されたプロジェクト計画の整合性を確認し、プロジェクト推進上の問題がないか確認する必要があります。
特に注意したいのは、上流工程におけるインタフェース仕様確定のタイミングと、サブシステム間の結合試験開始のタイミングであり、これらを重要なマイルストーンとします。
各ベンダーも、プロジェクト全体の進行を意識したスケジュールを提示していると思いますが、それぞれの都合である程度ズレが発生している可能性があります。
「事務局」はこのズレを決して見逃す事はできません。この時点でズレを解消しておかないと、後々のリスクにしかなりません。
ズレを解消する為には各ベンダーとの交渉も必要になりますが、この段階での計画変更は後工程での変更に比べるとインパクトは少ないものです。
とはいえ、特定のベンダーに対して無理強いをして、現実味のないスケジュールとなっては本末転倒であり、特に、難易度が高いサブシステムや新規開発となるサブシステムが存在する場合には、その状況を考慮すべきです。
この調整における拠り所としても、プロジェクトの「憲法」や「グランドデザイン」を、各ベンダーに事前に共有している事が重要と言えます。
工程・成果物の共通理解を図る
マイルストーンの確定と並行して、各ベンダーの工程や成果物の共通理解を行う事も重要です。
ベンダー各社は、PMBOKなどの管理プロセスを理解していますが、それぞれベンダー標準のプロセス定義や成果物定義を行っているケースも多いです。
例えば、上流の設計工程においては「システム設計」「基本設計」「外部設計」といったような表現がされますし、試験工程でも、「内部結合」「外部結合」「システムテスト」「連携テスト」「総合試験」といったような表現がされます。
単に表現上の差であれば問題は大きくありませんが、各ベンダーの工程定義に対する成果物や完了基準が異なっていると、関係する他ベンダーへの影響が発生する可能性があります。
「事務局」を中心として、各ベンダーから提示されたプロジェクト計画（スケジュール）の工程定義について確認し、プロジェクト全体で共通理解を図る必要があります。
コミュニケーションのツールとルールを定める
マルチベンダー体制の実行プロセスにおいて、コミュニケーション品質（情報の質と量）を高める事が重要です。
複数ベンダー（その中の関係者も含む）が多くなればなるほど、コミュニケーションパスが増えます。
ベンダーによってはセキュリティポリシー上の制約などもあり、コミュニケーションとして使えるツールが限られる事もありますが、プロジェクト全体として情報伝播がしやすいツールの導入や会議体の設置が必要です。
ここでは、ベンダー各社のコミュニケーションに関するツールや運営方法に関する参考をご紹介します。
Backlog（プロジェクト管理ツール）
- 共有すべき課題の管理や、ファイルの共有ができる。
- 担当者をアサインできる事で、タスクの抜け漏れを防げる。
- 単純なブロードキャストや、OneToOneの連絡などには不向き。
Slack（コラボレーションツール）
- 複数の任意の関係者を設定したチャネルを作成できる。
- ブロードキャスト、ナローキャスト、OneToOneのコミュニケーションができる。
- 特定の話題に対するスレッド化ができる。
- 課題やタスクの管理には不向き。
システム間連携会議
- 「事務局」を中心に各ベンダーのPMクラスのキーマンが参画し、プロジェクト全体の進捗状況や課題・リスクを共有する。
- プロジェクト全体の方針確定や、ベンダー間の調整を行う事ができる。
- 時間制約があるため、取り扱う情報の粒度には十分に留意し、事前に宿題・議題を共有する事が重要。
- 特にベンダーのPMクラスなどは多忙を極める為、プロジェクト開始から終了までの会議スケジュールを事前におさえておくなど準備が必要。
まとめ
第三回では、第二回に引き続きプロジェクトの「計画」プロセスにおけるポイントについて述べました。
ベンダーを含めた体制が整い、「マイルストーンが明確化」され「工程・成果物の共通理解」も得ることができ、プロジェクトを推進する上での「コミュニケーションツールとルール」も整備でき、プロジェクトに血が通い始めました。
第四回では、プロジェクトの「実行」プロセスにおけるポイントについてご紹介させて頂きます。
