【事例紹介】既存顧客向けポータルサイトにおける要件定義事例

ミッションやKPIの異なる複数の部門が、同一のシステムを利用するケースは少なくありません。 今回は、メインで検討を行っている部門に対して、他部門が別角度で要件定義を行い、メイン部門側へのインプットを行ったプロジェクトの事例をご紹介いたします。

プロジェクトの目的／背景

背景

今回の事例におけるクライアントは、回線やWebサービス等、様々なICTサービスを取り扱う通信事業会社です。クライアント企業では、主に自社のサービスをご利用中の法人ユーザー向けに、様々な情報や手続き機能を提供するポータルサイトを有しています。このポータルサイト、現時点では、「契約情報が閲覧できる」など限定的な機能のみの提供となっており、今後の機能拡充に向けて要件定義／開発を段階的に実施している、という状況です。そのような中、エンタープライズ層の法人向けにアカウント営業を行っている部門から、ポータルサイトの要件定義に関するご依頼をいただきました。

プロジェクトの目的

ポータルサイトの機能拡充にあたっては、主にSMB層向かいのマーケティング部門を中心としたワーキンググループで、メインストリームの要件定義が進められていました。それもそのはず、このポータルサイトの起こりは、（アカウント営業がつかない）SMB層ユーザーとの接点をWebで構築し、コミュニケーション機会を創出する、というものだったからです。そのため、このままでは、ご依頼元となっているアカウント営業部門が所掌するエンタープライズ層に関する要件が漏れてしまいます。そこで、メインストリームの検討ではカバーしきれないエンタープライズ層ユーザー／アカウント営業ならではの課題解決のために、要件定義を行い、ワーキンググループにインプット／反映していく、というのが今回ご紹介するプロジェクトの目的です。

プロジェクトの流れと詳細

Step 1：機能／コンテンツの具体化

このステップでは、SMB層とのニーズの違いを考慮し、提供すべき機能／コンテンツを検討の上、業務フロー／画面遷移フローを具体化しました。

当プロジェクトでは、エンタープライズ層の中でも、ポータルサイトへのニーズが特に強い情シス部門のユーザーをターゲットとしています。今回のケースでは、ターゲット／チャネル／購買プロセスいずれも限定的であるため、戦略策定プロジェクトでよく行われるようなカスタマージャーニーの策定などは実施しません。代わりに、ニーズをしっかりと整理し、それを機能／コンテンツ定義のための主なインプットとします。

はじめに、ニーズは業務に紐づき生じるものと考え、情シスがポータルサイトを利用して行うであろう主な業務種

• ヘルプデスク対応
• ネットワーク運用／保守
• サーバ運用／保守
• デバイス／アカウント管理
• その他事務業務

の5つに観点を分けました。

さらに、より細かい粒度でMECEにニーズを洗い出すため、「業務の流れ」の観点を加え、

• 【ヘルプデスク対応】受け付け > 確認／処理 > 回答／連絡
• 【ネットワーク運用／保守】監視／状況確認 > 切り分け／連絡 > 対応／処理／報告
• 【サーバ運用／保守】監視／状況確認 > 切り分け／連絡 > 対応／処理／報告
• 【デバイス／アカウント管理】状況確認／依頼 > 対応／設定 > 連絡／払出
• 【その他事務業務】権限設定 > 契約／請求情報確認 > 契約／更新／支払

の各観点で、ニーズの整理を行いました。

次に、施策（提供すべき機能／コンテンツ）の洗い出しです。

洗い出すためのインプットは3点。

• 先ほど洗い出したニーズに基づく仮説ベースでの施策
• 他社事例のベンチマーク調査に基づく施策
• 大企業情シス在職者へのヒアリング（デプスインタビュー）

これらをベースに、最終的に、全54個の施策を定義。うち、業務フロー／画面遷移フローが必要なものについては、あわせて定義を実施しました。

なお、54個の施策については、提供価値の重みづけも実施しました。顧客視点でのニーズがあれば、その施策は必然的に提供価値は高いと判断できます。

一方で、たとえ顧客ニーズが低くとも、クライアント視点でのビジネス効果（業務稼働削減効果等）が期待できるのであれば、やはり提供価値は高いと判断できます。そのため、顧客視点／クライアント視点の両軸で評価を行いました。

Step 2：提供範囲の明確化

このステップでは、エンタープライズ層の契約状況や、各サービスの情報提供状況等に基づき、各施策ごとの対象サービスと施策範囲（機能／コンテンツ範囲）を明確化しました。

クライアントが提供しているサービスは多数あるため、機能／コンテンツ提供を全てのサービスで一度に対応させるわけにはいきません。また、サービスによっては、既に一部の機能／コンテンツは提供済みの可能性もあるため、未提供の範囲（＝今後提供していくべき範囲）を明確にする必要があります。

そのため、

• どのサービスが、エンタープライズ層からのニーズが強いのか（ニーズに基づく、サービスの絞り込み）
• どのサービスで、今後提供が必要な機能／コンテンツはどれか（現在の提供状況に基づく、これから提供すべき機能／コンテンツの明確化）

について、サービスを主管する各部とも調整の上、データやヒアリングに基づき、対象とすべきサービスと機能／コンテンツの範囲を明確化しました。

Step 3：実現性の検証

このステップでは、バックエンド側のデータの保持状況／ID管理状況等から、具体化した施策の実現性に無理がないか検証を行いました。

施策定義をはじめとするフロントエンドの知見に加え、システムやデータといったバックエンドについても深い知見を有するのが弊社の強みです。

施策を実施するにあたっては、

• 企業を特定するためのID／そのIDに紐づくデータ
• 契約を特定するためのID／そのIDに紐づくデータ

にどのようなものがあり、各ID間がどのようなシステムでどう紐づいているのか、紐づけの精度はどの程度か、が実施可否に大きく影響します。そのため、ID／データの観点から、各施策のフィージビリティを評価。このフィージビリティ評価と、Step1における提供価値の評価をあわせ、最終的な施策の重要度／優先度を決定しました。

プロジェクトの成果

その後、当プロジェクトで取りまとめた上記要件について、本稿の冒頭で触れたワーキンググループ（ポータルサイトの機能拡充に向けてメインストリームの検討を行っている、SMB層向かいのマーケティング部門を中心としたグループ）への報告を実施しました。

結果として、アカウント営業部門とワーキンググループの目線を合わせることができ、具体的な要件の落としどころを定めていくための下地を整えることができました。

また、要件に関する検討の粒度／深さに関しては、プロジェクト依頼元のアカウント営業部門のみならず、メインストリーム側のワーキンググループからも高い評価をいただきました。

まとめ

フロントエンド／バックエンド両面の知見を併せ持つことに加え、クライアントに対する深い理解を有することが弊社の強みです。

クライアントのビジネスモデル、システム構成、流通データ、体制。

真の要件定義は、これらの理解の上に成り立ちます。今回ご紹介したプロジェクトでご好評をいただいたのも、この顧客理解ゆえのものと考えております。

ファーストデジタルでは、他にもDXに関わる様々な領域でご支援を行っております。

お困りごとがございましたら、お気軽にご相談ください。