Pages Navigation Menu

For Creative Communication

要件定義フェーズの始め方

まもなく、久しぶりに少し大きめのWeb制作プロジェクトが始まる。キックオフから情報設計(ワイヤーフレーム作成)手前までの工程を「要件定義フェーズ」と呼んでいるが、個人的にはこのフェーズが一番楽しく、得意な時間だ。

注)SIerやシステム構築案件での「要件定義」という言葉と、Webプロジェクトの要件定義フェーズはけっこう意味合いが異なると思う。「ディスカバリー(Discovery:発見)」フェーズという呼び方も好きだが、一旦この記事では要件定義フェーズと呼ぶ。

要件定義フェーズは、まず「要求事項収集(Requirements Gathering)」あるいは「要求の導き出し(Requirements Elicitation)」という活動から始まる。 この辺りの活動の教科書にしているのは、アラン・M・デービス著『成功する要求仕様 失敗する要求仕様』という本だ。「要求の導き出し」という表現はこの本の第2章のテーマであり、導き出し⇒トリアージ(優先順位付け)⇒仕様化と流れていく最初のアプローチになる。PMBOK®プロセス番号5.1「要求事項収集」とほぼ対応していて、プロジェクトスコープを決めるための標準手順だ。

成功する要求仕様 失敗する要求仕様
アラン・M・デービス
日経BP社
売り上げランキング: 302,194

活動の定義よりも、要求の導き出しの「テクニック」として用いられる手法を並べて見る方が、やることがわかりやすいかもしれない。

  • インタビュー(実務上「ヒアリング」と呼ぶことが多い)
  • ファシリテートされたグループミーティング(いわゆるブレストのこと)
  • コンピュータを使った共同作業(HangoutしながらGoogleDocsに同時に書き込むような活動)
  • 観察
  • アンケート
  • プロトタイピング、シナリオ、モデリング記法

これら手法のどれを・どのように組み合わせて、要件定義フェーズを進めていくか。 その判断は、ステークホルダーの状況によって変化する。

たとえば、Webの運用やコンテンツに関わる部署が複数にわたり、各部門の若手からマネージャーまで数十人が関与するようなケースでは、全員が半日〜一日程度、一堂に会してブレーンストーミングをすれば、効率的に意見を集約できる。「Webにどんなコンテンツ・機能が必要か」をとにかく洗い出してまとめる作業は案外楽しくて、大勢の社員を巻き込むことによるプラスの効果も得られやすい。「アンケート」との合わせ技も有効だ。

一方、部門ごとの管轄領域が明確に異なるようなケース(たとえば総合大学の各学部広報)では、属性を混ぜたブレストがあまり有効でなく、むしろ緻密にインタビュー(デプス、グループインタビュー)を重ね、個別の要求を集約するほうが現実的かもしれない。個別のインタビューは時間がかかるが、キーマンへの聞き込みにはとにかく時間をかけたほうがいい。

軽視してはいけないのは、メインのプロジェクト担当者およびその上長(決裁者)に対する深掘りのインタビューだ。むしろ「初手」の定石として、2時間でも3時間でもじっくり話を聞いて、プロジェクトの根底にある本質的要求を探りたい。提案時にプロデューサーが当てた質問でも、RFPに書いてある項目でも、あえてじっくり訊き直す。企画文書に書かれてている言葉の意味を完全に理解し、同じ目線に立ててはじめて、プロジェクトが開始できる。

さらに、エンドユーザーへの「観察」を織り込めるとしたら、誰を対象に、いつ・どのように行うかのアレンジが必要になる。「自分がエンドユーザー/顧客になってみる」という体験もできるなら、リアルな気づきを得ることもできる。


さて、要件定義フェーズを始める前に、注意すべきことがある。

着手前に、「ステークホルダー特定」が終わっている必要があることだ。ステークホルダーの「量」と「質」が明確になる前に、「各論」のヒアリングに入らないこと。

PMがプロジェクトに着任した段階では、プロジェクトチームとのコミュニケーションも不十分で、ステークホルダーを洗い出し切れていることは稀だろう。例えばWebリニューアルなら、キックオフMTGまでに「Webサイトに関わりそうな全人物の一覧(更新、閲覧、バックエンド管理、etc.)」を、クライアントに洗い出してもらうと、キックオフでの確認と議論が捗る(大概、発注側はステークホルダーの範囲を狭く見がちだ)。そして受注側からは「要件定義フェーズを通じて答えを得たい質問集」をぶつけ、それぞれの問いを誰に・どのように当てていけば、要求を集めるかを協議したい。

要件定義フェーズのゴールは、要求を可能な限り網羅的に集め、予算・期間などの制約下で取捨選択し、スコープを固めること。 もちろん、変化の速い時代に、「完全にFixした要件」を求めるのは幻想だ。アランも「要求は変化する」ということを繰り返し書いている。とはいえ、ステークホルダー認識が漏れていて後からスコープ外の要件がぽこぽこ出てくるような事態と、多様なステークホルダーと調整しながら柔軟に着地点を探っていく進め方とでは、天と地ほどの違いがある。ステークホルダー分析からの「要求の導き出し」プロセスを、確実にデザインできるようにしておきたい。

コメントを残す