【事例紹介】PMBOK以外のフレームワーク（PRINCE2）を使ったサイトリニューアルプロジェクト

100周年記念事業としてサイトリニューアルプロジェクトが始動

飲料業界のクライアントの100周年記念事業として、コーポレートサイト・商品サイトの役割を再定義してリニューアルするプロジェクトがクライアント内で立ちあがり、10年以上協業してきた制作プロダクションからプロジェクトマネージャーとして参加要請を受け、クライアントに対して企画・提案するところから最初の業務が始まった。提案は社長を含めた役員会に承認され無事に受注し、関係する部門やグループ会社のメンバーも含めると総勢50名以上の大所帯となり、サイトリニューアルプロジェクトとしては、1年以上を要する大規模なものとなった。

本プロジェクトには以下の特徴があり、①の影響を②の手法でコントロールする形となった。

① 変動要素の大きいインフラ構築のコンサルティングをスコープに含む。
② プロジェクトマネージメント手法は一般的に利用されるPMBOKではなく、PRINCE2を利用。

【マネージメント手法であるPMBOKとPRINCE2の比較】

■PMBOKについて
アメリカで開発されたプロジェクトマネージメント手法で日本のプロジェクトでも一般的に使われている。管理するパラメーターは主にQCD（Quality＝品質、Cost＝コスト、Delivery＝納期、以下QCD）の３つ。プロジェクトマネージャーが判断を行い、プロジェクトリーダー・プロジェクトオーナーが承認する。

■PRINCE2について
イギリス政府の情報システム開発プロジェクトにも採用され、イギリス以外の国でも多く利用される。管理するパラメーターはQCD以外にスコープ、リスク、ベネフィットの６つ。プロジェクトマネージャーが情報整理を行い、プロジェクト委員会が判断し承認する。
PRINCE2の体制の特徴は、プロジェクトマネージャーの上位に、判断を行うプロジェクト委員会が設置されていることだ。プロジェクトマネージャーはプロジェクトメンバーから情報を収集し、判断しやすいように情報を整理してプロジェクト委員会に伝える役割に担う。プロジェクト委員会は、プロジェクトエグゼクティブ（クライアント側の最高責任者）が、シニアユーザー（サイト運用を主管する部門の部長）、シニアサプライヤー（受注側の制作プロダクションの部長）のサポート・アドバイスを受け、プロジェクトエグゼクティブがスピーディーに判断できるように組織されている。

インフラ調査で難航していたところに追い打ちをかけたのが、仕様書が存在しない既存システムの存在。

企画・提案の段階で、ペルソナ定義・カスタマージャーニー策定をしていたこともあり、インターフェー設計やデザイン制作などは概ね予定通りに進行していたが、インフラ構築のコンサルティングを進める中で、大きな２つの問題が露見して難航することになる。

１つ目の問題は、明確な運用ルールやガイドラインが無かったこともあり、サイト運用を主管する部門が把握していないサーバが存在し、ブランド規定などが守られていないブランドサイトやキャンペーンページも散見していた。サーバと公開されているデータの棚卸を行い、既存のサーバ構成図・ドメインリストを作成し各部門とグループ会社の運用担当者に個別にヒアリングを行った。作成したドキュメントを最新化して現状を正確に把握するまでに数か月を要した。

２つ目の問題は、基幹システムと連携して商品情報をWEBページに表示する既存システムがあり、そのシステムを開発したSIerが仕様書などを残さずに運用業務から撤退してしまい、容易に改修が行えない状態になっていた。

商品改訂などによって新たに表示が必要になった情報も、システム改修を行えないことでWEBページに自動で反映することができず、手作業で変更点を反映するような余計な業務が増え、運用を担当する部門の負荷を高くしていた。

プロジェクト開始当初は、システムテンプレートのデザイン刷新のみを想定していたが、既存システムの仕様を完全に把握できなければ動作テストも不完全なものとなってしまうので、既存システムを破棄して新たにWEBアプリケーションを開発することになった。既存システムに関わる業務内容を関係部門へヒアリングし、業務フロー図を作成して要件定義・設計を進めることになり、想定外の作業が発生し、最終的には予算を大幅に増やし、公開日を6ヶ月後ろ倒すことになったのである。

PRINCE2の体制が、承認フローを円滑に機能させることになった。

通常であれば100周年記念事業として立ち上げられたプロジェクトで、いきなり予算とスケジュールが変更になるような事態が起きた場合、クライアント内は大騒ぎになるところだが、今回のプロジェクトにはインフラ構築のコンサルティングという大きな変動要素を含んでいたので、予めマネージメント手法も考慮していたことで大きな混乱を避けることができた。

本プロジェクトのマネージメント手法として利用したPRINCE2の体制では、プロジェクトマネージャーは、プロジェクト委員会が判断しやすいように、各プロジェクトチームから情報を吸い上げて伝達するような交通整理をする役割が大きい。例えば、定例会のようなオフィシャルな意思決定の場とは別に、プロジェクトマネージャーがプロジェクト委員会の一角であるシニアユーザーやシニアサプライヤーと個別に打ち合わせを行い、プロジェクトエグゼクティブが判断するために必要な情報を事前に引き出し、アドバイスをもらうようなコミュニケーションをすることが多い。日本でいう根回しのようなコミュニケーション方法が、PRINCE2のフレームワークの中で定義されており、プロジェクトマネージャーの特性によってコミュニケーションのクオリティーが左右されにくいメリットがある。

また、プロジェクト委員会には受注側である制作プロダクションの部長がシニアサプライヤーとして存在する。PMBOKの体制に慣れていると、クライアント側のメンバーに受注側のメンバーが紛れ込んでいるような違和感を覚えるが、プロジェクトエグゼクティブが、発注側・受注側双方の意見を聞きながらスピーディーな判断をする体制となっており、インフラ構築のコンサルティングという大きな変動要素を含んだ本プロジェクトでは効果的に働いた。

さらにスピーディーな判断を可能にするために、プロジェクトエグゼクティブにはクライアントの役員に担当していただいた。一般的なプロジェクトではプロジェクトオーナーの上に役員会が存在することが多く、プロジェクト内で承認されたことが役員会で覆ることが頻繁に起こる。プロジェクトの背景や経緯などを十分に把握することなく独善的な判断をされることで、なんとか踏みとどまっていたプロジェクトメンバーの士気低下を惹き起こすことも少なくないのではないだろうか。役員であるプロジェクトエグゼクティブが下した判断が最終決定となり、承認されたことが覆る心配が消えたことでプロジェクトメンバーの士気も高く維持された。

体制のメリットは他にもあった。プロジェクト進行や提出資料について、インフラ・システムやWEBに詳しいプロジェクトメンバーがクライアント側に不在のため、判断しやすいように配慮をして欲しいと、プロジェクト開始前にクライアントから要望をもらっていた。デザイン案だけでなく、サーバ構成やシステム仕様についても、メリット・デメリットが伝わるように複数案を提示し誰が見ても分かるように内容をかみ砕いて丁寧に資料を作成した。その上で、事前にシニアユーザーやシニアサプライヤーに説明して伝わりにくい点や判断ポイントなどについてアドバイスをもらうことができ、プロジェクト委員会の承認フローを円滑に進めることができた。

PRINCE2の体制は、自社製品開発などの自発型のプロジェクトや、受託型であっても変動要素が多いプロジェクトにおいて効果を発揮

「使いやすく、わかりやすいサイトを構築する」ことを目標に掲げ、アジャイル形式でデザインのクオリティーを高めた甲斐もあり、サイトリニューアルの次年度の第3者評価において、高い評価を得ることができた。特に評価が高かったインターフェースはプロジェクト全体でいうところの氷山の一角であったが、インフラ・システムでの苦労が報われたようで嬉しかった。クライアントからの評価も高く、グループ会社のサイトリニューアルプロジェクトなどを幾つか任されることになった。

PRINCE2のフレームワークを使ったプロジェクトに出会う機会はまだ少ないが、クライアントやプロジェクトの特徴を考慮して取り入れることをお奨めしたい。個人的な観点にはなってしまうが、クライアント側の最高責任者が積極的に判断を行うPRINCE2の体制は、自社製品開発などの自発型のプロジェクトに向いていると感じた。今回のプロジェクトのように、受託型であっても変動要素が多い場合にも、強みを発揮できると感じる。PMBOKではカバーが難しい部分を補うためにも、PRINCE2を参考にすることはプロジェクトの成功に役に立つと考えている。