2024年02月14日
自社のWEBサイトリニューアルを推進する際、序盤の要件定義フェーズで時間が足りなくなることがあります。
スケジュールを決めて、あらかじめアジェンダを決めて会議進行しようとするものの、ついつい一回の打ち合わせで時間を超過してしまったり、未決のまま会議が終わってしまったり。
実は、それらは要件定義の前段階となる「要求定義」が明確になっていないことが原因であることが多いです。
要求が定まっていない、洗い出しきれていない、社内で認識共有されていないことが原因で、会議中に発注側の企業が議論をはじめてしまって収拾がつかなくなる。これは、要件定義の会議でしばしば見られる光景です。本記事では、そもそも要求定義の「要求」とは何なのか？要件定義との違いを解説するとともに、要件定義フェーズの質を高める方法論をご紹介します。
そもそも「要求」とは何なのか。下の図をご覧ください。
要求とは、サイトをリニューアルしたいと思った理由に対して、現状の課題を洗い出し、それに対してどうしたいのか？を具体的に落とし込んだものです。
【要望】＝サイトをリニューアルしたいと思った理由
例）
・デザインが古くなっており、企業の見られ方を一新したいから
・発信している情報が古くなっており、サイトの掲載内容をアップデートしたいから
【現状】＝要望に対して課題となっていること
例）
・中長期計画でビジョンを発信しているものの、伝わりがよくないと感じる。
・広報部がサイト更新を担っているが、各事業部の最新の取り組みまで理解が及ばず、PRが後手になってしまう（情報発信が滞ってしまっている）
【要求】＝要望を具体化したもの
例）
・ビジョンに対して取り組んでいる具体的な活動内容を発信し、将来性ある企業だと印象づけたい
・複数の部署がCMSでサービス紹介ページや事例記事を更新できるようにしたい
・一方でトンマナや記事フォーマットを共通化することで、情報発信の統制を図りたい
【要件】＝実装構築にむけてベンダーと合意したスコープ、実施内容
例）
・チャレンジしている企業を印象づける動画、特設コンテンツを設置する
・記事フォーマットを「新製品情報」「バージョンアップ情報」「メンテナンスのお知らせ」「緊急のお知らせ」の4種を用意し、記事のデザインテンプレートを用意する
・コンテンツの編集権限のみ許可されたアカウントと、チェック〜公開までが行える承認権限をもったアカウントの2種類を用意し、情報発信の統制を図れるようにする
要件定義とは、現状の課題を解消するための具体的な要求に対して、ベンダーとの間でスコープ、実施内容を合意すること。つまり、要求が不明瞭のままでは要件はなかなか具体的にならず、合意にむけては相応の時間がかかってしまうというわけです。
要件定義の前に、要求定義を行っておくメリットは3つあります。
現状の課題感に対してどうありたいと考えるかは、役職や部署によって異なるものです。特に、先の例であげた要望のひとつ「デザインが古くなっており、企業の見られ方を一新したい」に対する現状の見解や、どんな企業に見られたいのかというイメージは人によって異なりますし、社内で明確に言語化できているケースは少ないでしょう。
その場合、ベンダーの多くはなぜ企業イメージを一新したいのか、それは具体的にどのようなイメージなのかを遡ってヒアリングすることになりますが、社内のなかで共通認識＝正解が存在しないため、ベンダーと協議した要件を会社としてOKと伝えるには、どうしても時間がかかってしまいます。社内の共通認識を事前にかためておけば、工数の大幅な圧縮につながります。
一つの要件についてベンダーと合意がみえてきた段階になって、別の部署から要求の後出しをうけることがあります。たとえば「ウチはこういうニーズがあるので、こういう使い方も想定してほしい」といったような意見です。こうなると要件追加となり、ベンダーが持ち帰って、また次回に持ち越し…となります。推進責任者からすれば「後から言わないでよ」と言いたくなるところですが、どのような要求があるのかを関連部署から事前に聞き出しておくことで、事前に手戻りを防ぐことができます。
要件定義では「こんな機能がほしい」と機能要件だけを伝えられることがしばしばありますが、なぜその機能が必要なのか、その手段が本当に最適解なのかを探るには、背景にある「現状」と「要求」の深掘りが必要になります。
たとえば、「ここの設定をあとから編集できるようにしてほしい」といったように、なぜその機能が必要なのか要求が不明瞭のまま、要件を伝えられるケースがあります。何の用途でその機能を使いたいのか業務シーンに立ち返っていくと「そのようなシーンは頻度としては少ないから優先順位をさげてもいい」という判断に至ることがあります。サイトの実装構築には時間と予算、リソースが限られている以上、どうしても必要な要件なのか、余力があったらほしい要件なのかジャッジしていく必要があります。その判断材料を明確にするためにも、要求定義は必要といえます。
要求定義のポイントは、事前に社内の要求をどれだけまとめておけるか、ということですが、白紙状態から意見を出すのは難しいもの。「要求を具体化しておいてください」と関連部署に頼んだとしても、ベンダーが求めているレベルの内容が返ってくることは少なくないでしょう。
そこで、要求定義をワークショップで行うという方法があります。関連部署のスタッフを集めて、現状の課題を棚卸しし、優先順位をつけた上で、関連部署の主要メンバーで要求を具体化していくというものです。
この方法をとるメリットは三つあります。
多くの関与者が集まるサイトリニューアルプロジェクトでは、さまざまな部署の担当者との折衝だけでも推進責任者にとって十分な負担になります。全員の日程調整こそ大変ですが、その場で合意形成を行うことで関与者各位とのコミュニケーションコストを大幅に軽減することができます。
サイトリニューアルを成功に導くにあたって推進責任者が特に影響をうけやすいのが、周囲の人々の「協力度」です。一生懸命がんばっても「何かやってるな」という程度に思われることもしばしば。前述のとおり、いかに社内の共通認識を固められるかが成否の鍵を握るため、できるだけ関与者の関心を高めておく必要があります。ワークショップでは現状の課題に対して、自らの意見を出すことになるため、その後議論がどうなったのか。他人に意見はどうなのかなど、関心を持ってもらいやすくなります。
ワークショップでは、皆で同じ時間を過ごし、一つの課題に対してむきあうことからプロジェクトチームの一体感が生まれやすいという副次的な効果が期待できます。サイトリニューアルプロジェクトのメンバーとは、リニューアル後のサイト運用においても協力し合う関係性です。ここで互いの意見、価値観を認識しあうことこそが要求定義のワークショップを行う真の目的といえるでしょう。
ただ、ワークショップを行った経験がない、どうやって実施すればいいかが想像できない、といった方もいらっしゃるかと思います。その場合は、ワークショップのアジェンダ設計、当日のファシリテーションを専門家に頼むのも一つの手です。
大伸社ディライトでは、サイトリニューアルの要件定義を実施するだけでなく、要求定義のための社内ワークショップからご支援することも可能です。ワークショップの実施についてご興味ある方は、ぜひ以下よりお問い合わせください。
