【事例紹介】Withコロナにおける、オンラインイベントの要件定義支援とPMO活動

INDEX

• まとめ

休日返上で対応したのに大量に残ってしまった課題。どう進めたら公開直前での手戻りを避けられたのか？

まず、本プロジェクトに至る経緯から説明します。本件クライアントでは毎年BtoB向けに大規模なオフラインでのイベントを開催しておりましたが、本プロジェクトの前年はコロナ禍により例年通りのオフラインによる開催は断念せざるを得ず、代替としてオンラインでの開催が決定しました。初の大規模オンラインイベント開催に向け、クライアント社内でプロジェクトが立ち上がりましたが、当時のプロジェクトではイベントサイトの公開直前までクライアント上層部から多くの追加要望・仕様の変更が噴出し、満足のゆくシステムが完成しないままイベント開催に至る結果となりました。当時のプロジェクトに参画していたシステム開発ベンダーも休日返上で対応し最善を尽くしましたが、発注側・受注側双方に課題が残る結果に終わりました。

本事例の年度での開催に向けては、前年度の反省からプロジェクトの上流において漏れなく要望を洗い出すことができるだけのスキルを持った旗振り役が必要になり、弊社のコンサルタントへ要件定義支援および設計・実装フェーズにおけるPMOの役割での参画を依頼され、プロジェクトがスタートすることになります。

期間に余裕が無い！各工程の本質を見極めた作業の取捨選択にも、豊富なプロジェクトマネージメントの経験が役立つ。

クライアント社内の複数部門に跨るメンバーのみならず、グループ会社まで参加する一大プロジェクトです。

一方で、前年度に構築したイベント用システムは、初の試みでありながらも会期中には大きなトラブルが発生することもなく安定して稼働していたこと、またゼロからの構築で多額の費用を投入した経緯もあり、動画配信プラットフォーム、CMSなどの既存機能は見直しつつも、再度ゼロベースでの構築ではなく、前年度構築のシステムをある程度流用することは、早々に基本方針として打ち出されていました。

そのため、今年度のイベント開催に向けては、前年度のシステム基盤は踏襲した上で、前年にスケジュールや工数などの種々の問題から実装に至らなかった、あるいは前年度の反省から新たに浮上した要件を追加実装する必要があります。

例としてはチャットツールと連携してイベントに参加するユーザーを担当営業がアテンドする仕組みや、オンライン会場を盛り上げるためのオンラインチャット機能、収集した顧客データを営業活用に利用する仕組みなどが挙げられますが、これら多くの新機能について、既存機能との整合性を確保しつつ要件定義を行う必要がありました。

本来であれば必要な機能の抜け漏れを防ぐため、あるいはユーザビリティの確保のために、機能の要件定義を行う前段階として、ターゲットとなるユーザーのペルソナを設定しカスタマージャーニーを定義することによりシステムの利用シーンを解像度高く理解するフェーズに十分な時間を掛けるべきです。

しかしながら、本プロジェクトに弊社が参画した時点でイベントの開催時期は差し迫っており、システムのローンチ次期から逆算すると要件定義には2ヶ月程度しか確保できない状況でした。これはイベントの規模や必要と想定される機能数を考えると、相当無理のあるスケジュールです。

そのため、改めてペルソナを設定し、カスタマージャーニーから検討していてはシステムの構築がイベント開催に間に合わないと判断し、いきなり機能の要件定義からスタートする進め方を採らざるを得ませんでした。

そのような状況の中でも要件の網羅性を担保し、かつシステムのローンチスケジュールは死守すべく、本プロジェクトにおいては定例会に参加するメンバーから、個々人が必要と感じている機能についてその場ですべての意見やアイデアを出してもらい、その場で参加者全員が各機能について徹底的に議論し、具体的な機能や仕様をドキュメントに落とすところまでを定例会の場ですべて完了させる、というスクランブル体制での対応を行いました。

もちろん、作成したドキュメントは弊社にてさらに詳細化し、次回の定例会では詳細化した仕様についてクライアントから承認を得た上での最終FIXとなります。

定例会は要件定義フェーズの約2ヶ月間のうち、平日はほぼ毎日数時間単位で開催しておりましたが、定例会を重ねるごとに必要な機能のアイデアは増えてゆきますし、詳細化した仕様に対しさらに議論が発生したり、詳細化した仕様により新たな要件が生まれたりと、「本当に想定している開発期間に収まるのか？」という疑問が全員の頭の中に浮かんでいたと思います。

開発ベンダーの顔が青ざめていくのを横目で見ながら、とにかく「ここで全部出し切りましょう。」と言い続けました。

データ活用は難しい！デジタルへの知見とコンサルティング、どちらも高レベルなスキルが求められる。

また、要件定義フェーズにおいて工夫した点としては、各機能に必要な入力データと、他の機能との連携に必要な出力データについてもドキュメントに落とし、システム設計にまで踏み込んだ要件定義を行った、という点が挙げられます。

これは、前年度のプロジェクトにおいて、ローンチ直前にクライアント側の要望が噴出していたことを考慮してのことです。本来ウォーターフォールであればそれぞれの工程で決定すべき内容は全て固めてしまい、後工程に進んだら前工程に戻ることはない、というのが教科書的な進め方です。しかしながらシステム構築に関わるプロジェクトの実情としては、設計フェーズで具体的に見えてきたシステム仕様に対して、クライアントから要件自体の変更や、機能の追加要望が入ることは多いでしょう。

このような状況で、システム開発ベンダーサイドとしても、プロジェクト収支や瑕疵担保責任等の問題から、「要件定義書に載っていない機能追加や、仕様変更は受け入れられない。」といった紋切り型の対応を取らざるを得ない場合も多々あります。

今回のプロジェクトにおいてはすでにスケジュールにバッファが無く、このような手戻りが発生したり、プロジェクトが設計フェーズで頓挫してしまったり、といった最悪の事態を招くことのないよう、通常よりも設計フェーズの内容にまで踏み込んだ要件定義を行うことによりリスクヘッジを試みました。

このように、タイトなスケジュールの中で最大限の成果を出すための工夫を重ねてプロジェクトをマネジメントしてきましたが、プロジェクト中最も難航したのは、データを活用したマーケティングに関わる要件定義です。

具体的には、アカウント作成時に登録されたユーザーの属性に合わせて、画面に表示するコンテンツやデータを出し分ける機能の詳細仕様であったり、動画の閲覧やお気に入り登録といった行動履歴データをGoogle Analyticsで取得したサイト内行動データと紐づけ、それによって得られたデータをSFAに連携して営業活動に役立てるためのデータ連携フローの定義であったり、といった部分になります。

これらについて、クライアント側の要望を引き出しながら、仕様に落とし込む作業が最も難航した部分でした。 なぜならば、このような機能の要件を詳細に定義するためには、Google Analyticsなどのアクセス解析ツールに関する知識だけでなくクライアント社内のマーケティングツールに関する理解、クライアントの業務プロセスを紐解き再構築するビジネスコンサル的な要素など、必要となるスキルが多岐に渡るためです。

今回は、おすすめコンテンツのレコメンドのページには具体的にどんな情報が表示されるのか？ユーザーが離脱した場所などのアクセスログはGoogle Analyticsでどこまで詳細に取れるのか？収集したデータはどのように連携すればDMPに自動で引き渡しができるか？など、実現すべき機能の具体的や、利用するツールによる実現性の検証まで、その場で確かめ疑問を持ち越さないように進める必要がありました。

成果物としては連携先システムに引き渡すデータ項目・データ形式までを明文化してドキュメント化を行いましたが、今回は通常要件定義フェーズでは参加しないエンジニアの方にも、スポットで定例会に参加していただき、その場でフィジビリティ検証まで行える体制で議論を行いました。

加えてシステム開発ベンダーの開発責任者にも定例会に参加してもらい、機能上のフィジビリティだけでなく、リソースとスケジュールに照らし合わせた実現難度もその場で確認をし、コストに見合わない要件を今回のスコープから外すという判断まで定例会の場で実施しました。

その上で、開発リソースやスケジュールの面で重要機能の実現が難しい場合には、他の優先度の低い機能を落としたり、リーズナブルな工数で実装が可能な仕様に見直したりと、前向きに機能を取捨選択していくことができました。

これはクライアントサイドにおいて意思決定するレイヤーと、システム開発ベンダー側の距離が縮まったことで、お互いの考え方や開発リソースの逼迫状況が伝わりやすくなったことによるメリットで、このため要件定義フェーズ完了後も、スムーズに設計・開発フェーズに入ることができました。

こうして要件定義フェーズを進めていきましたが、スケジュールの遅れは1日も許されない状況であったので、設計以降のフェーズにおいても、実装する機能の優先順位や開発工数の見積もりはかなり細かく行いました。

全体のスケジュールへの影響も把握できるよう、実装やテストと一纏めにして進捗を管理するのではなく機能ごとに細分化して進捗管理を行い、工程の遅れを早期に察知しリカバリーできるような体制で臨みました。

特にユーザーの登録属性情報と連携したコンテンツの出し分けなど、実装難易度が高く遅れが発生するリスクの高い機能について重点的に進捗確認ができたことで、実際に多少の開発遅延は発生したものの素早くリカバリーすることができ、全体のリリーススケジュールに与える影響を最小限に実装を完了することができました。

時間がない時こそ、本当に必要な対応に絞って工数を集中投下することで、高難度のプロジェクトも成功に導ける。

たとえば要件定義フェーズにおいて今回の実装スコープ外とした要件としては、管理画面の構成や表示方法などの細かい仕様に関する要望が挙げられます。イベント開催までに実装が難しい仕様については、クライアント・開発ベンダーともに双方前向きな姿勢で次年度に課題を持ち越す判断ができました。

通常このような短期間のシステム構築プロジェクトでは、ローンチ日に向けては土日出勤、夜間作業、3交代制シフト、ウォールームでの毎時の進捗管理など、いわゆるデスマーチと呼ばれる状況が発生するのが常ですが、本プロジェクトにおいてはシステム開発ベンダーに無理な稼働を強いることもなく、予定通りオンラインイベントを開催することができました。今回追加実装した機能も想定通りの役割を果たしてくれました。

システム構築を管掌するクライアントの情シス部門担当者からは「本当に動きが早いよね。」、「よくこの短い期間でここまでのドキュメントを用意してくれた。具体的にイメージができた。」、「他部門を含めた情報整理や連携がスムーズにできて助かった。」といった有難いお言葉をいただけました。また、構築したシステムの運用主体となる営業部門のメンバーからは、構築したイベントサイトが非常に高く評価され、このシステムをイベント開催中の限られた期間のみ運用するのはもったいないと、定常的に公開して有効活用する取り組みも進んでいます。

まとめ

今回のプロジェクトにおいては、本来はシステム開発ベンダーのSEが設計フェーズ以降で行うような機能の洗い出しや仕様への落とし込みなどを、PMが要件定義フェーズで一部先行して行うことで、タイトなスケジュールの中でも手戻りを極力抑えてシステム構築までを完遂することができました。

ウォーターフォールプロジェクトにおいて要件定義と設計のフェーズが分かれていることには当然理由があり、今回採用したプロジェクトの進め方は、必ずしも全てのプロジェクトにおいて有効であるとは断言できません。

しかしながら限られた時間の中でも、細部まで踏み込んだ対応を通じてプロジェクトに関わるメンバー間に積極的なコミュニケーションが生まれ、前向きな姿勢を引き出せたことが、プロジェクトの成功につながったと考えています。また、プロジェクトの状況にあわせて常に最適な進め方を採用し困難なプロジェクトも強力に推進できることは、多くのDXプロジェクトを成功に導いてきたファーストデジタルの強みであると自負しています。