かんたんで複雑な、ウェブサービスの作り方を紐解くブログ

ウェブサービスの機能要件をまとめる3つの方法

UX
2021/08/01

ウェブサービスを作る上で大切になる機能。ユーザーにとって使いやすい機能とはどんなものか、そして機能を洗い出すためにはどのように進めればよいのか。 そんなウェブサービスに必要となる「機能要件のまとめ方」について、今回の記事では考えてみます。

下準備としてサービス・プロダクトの利用フローをまとめる

機能を洗い出すためには、いくつかの下準備が必要となります。その下準備として、まずはじめに必要となるのが「サービス・プロダクトに必要なフロー」をまとめる必要があります。 これは、具体的にどういうことか?例えば「SNSサービスを作る」というプロジェクトがあったとします。SNSサービスの場合のフローの場合、以下2タイプのユーザー観点からフローをまとめていく必要があります。 例えば、以下のような形です。 【一般ユーザーのフロー】 【1】一般ユーザーがまずは会員登録・ログインする 【2】一般ユーザーが日常生活について投稿する 【3】一般ユーザーの投稿が他のユーザーのタイムラインに表示される 【4】タイムラインに表示された投稿に対して、他の一般ユーザーがいいね・返答する 【5】返答に対して、はじめに投稿したユーザーが追加の返答を行う 【6】それぞれのユーザーのいいね・投稿に基づいて、タイムラインに表示される内容が最適化される 【7】登録済みの会員情報で変更・追加が発生した場合、該当する会員情報を変更する 【8】過去の投稿で消したいものが合った場合、投稿したユーザーが投稿を削除する 【9】SNSに興味を失った場合、一般ユーザーがアカウント自体を削除し退会する 【システム管理者 / サービス運用者側のフロー】 【1】システム管理者がサービスの運用担当者を登録する 【2】運用担当者がシステムにログインする 【3】過去に一般ユーザーから投稿されている投稿が適切 / 不適切かをチェックする 【4】投稿が不適切な場合、該当コメントを非表示 / 削除する 【5】不適切な投稿が続く一般ユーザーが入れば、強制的にアカウント削除を行う 【6】運用担当者が退職などで不在となった場合、該当する運用担当者のアカウントを削除する この「フローの作成」をまず行うことでウェブサービスの全体像が見え、次のステップに移ることができます。

各フローに基づいて必要な画面を洗い出す

ここまでで、ウェブサービス全体の利用フローが見えてきました。そしてこの利用フローが見えてくると、各フローごとに必要な画面がわかってきます。 例えば「一般ユーザーがまずは会員登録・ログインする」フロー箇所であれば以下の画面が必要となります。 ■会員登録画面 ■ログイン画面 ■ログアウト画面 ■パスワードを忘れた場合画面 ■パスワード再発行画面 このようにフローに基づいて画面が算出でき、大枠のウェブサービス内に必要な画面ボリュームを算出できます。そしてここでポイントとなるのが「機能が多く含まれる重要な画面設計を、この段階で先に行ってしまう」ことです。 画面を作ってみると、新たに必要な機能だったり、一つの機能を作ると関連する他のサブ機能の存在も見えてきて、次に行う本題の機能要件がまとめやすくなり、かつ機能要件段階で漏れが少なくなります。

画面に基づいて機能を洗い出す

そして「フロー」「画面」がまとまったら、いよいよ機能要件定義を開始します。そしてこの「機能要件を定める」段階でのポイントとしては大きく3つあります。 1つ目が「CRUD」という概念です。これは「Create(作成する)」「Read(閲覧する)「Update(更新する)」「Delete(削除する)」」の頭文字を取った考え方で、何かしらデータを保持する場合には、基本的にはこの4つの機能が必要となります。 例えば先程の会員登録であれば、CRUDは以下です。 ■CRUD=会員登録を行う ■Read=会員情報を閲覧する ■Update=会員情報を更新する ■Delete=会員情報を削除する そして、これら機能は一般ユーザー向けだけではなく、もちろん運用担当者やシステム管理者も同様の対応をできないといけません。このようにCRUDとして漏れがないかを確認することが必要です。 2つ目が、メイン機能に関連したサブ機能の洗い出しです。例えば「会員登録」機能がメイン機能として存在する場合、「パスワード変更機能」などがサブとして存在します。 一般的にパスワード変更などでは、通常の会員情報の変更などとは異なり、セキュリティを意識して、登録したメールアドレスを利用して変更を行う必要があります。こういったサブとして必要となる機能が無いかも、しっかりと検討する必要があります。 3つ目に、各機能の制約をあわせて考えることです。例えば「いいね機能」が合ったとします。この「いいね機能」は1日に何回もクリックできるのか、もしくは一つの投稿に対して1回のみか、またユーザー自身が投稿した内容に対しても、いいねのクリックができるのか?それら一つ一つの機能の制約も合わせて定義する必要があります。 これらポイントを意識して「機能一覧」をまとめると、実装をはじめるタイミングで困ることなく、プロジェクトを進めることができます。

最後に感想として

このように「全体のフロー」→「各フローに必要な画面」→「各画面に必要な機能」という形で洗い出していくことで、大枠の機能要件を算出できます。 とはいえ、その後に詳細な設計を行う中で画面設計書をたくさん作っていると、新たに必要な機能が現れてきます。そのため、機能要件は定めつつも、それらはプロジェクトを進めていく中で変化していく前提として、認識しておく必要があります。 大枠を定め、その後の変化を恐れず、地道に進めていくことが機能要件定義成功の鍵です。 読んでくださった方、ありがとうございます。