新規事業を構想して、システムの開発を進めようと思った時、
まず最初に要件定義を行います。
本記事では、オプスインでの要件定義の進め方を、
架空の中古家具CtoCマッチングシステムでの要件定義を例に説明いたします。
(※進め方はあくまで一例です。プロジェクトの規模や内容によって変わることがございます。）
1. サービスに関係する人の種類とサービスで行われることのヒアリング
まずは、このサービスでどのようなことが行われるかをヒアリングしていきます。
「家具を出品し」と一言にいっても、それを実現するためには、そもそも「家具が登録」されていないといけませんし、
家具を登録する前には、「ユーザーアカウント登録」や「ログイン」をしている必要があります。
サービスを成り立たせるために必要なすべてのプロセスをヒアリングし、可視化してきます。
同時に、どんな関係者(=アクター)がいてどんなことを行うかをヒアリングします。
概要から、出品と購入をするユーザー、運営管理者が必要なことはわかりますが、
他にも購入された家具を輸送することに関連するアクターや、
もしかしたら、出品された家具を保管する倉庫に関連するアクターもいるかもしれません。
関係者の洗い出しと関係者ごとのプロセスを可視化していくことで、
サービスで行われることを明確にします。
2. 機能一覧と画面一覧の定義
サービスで行われることが明確になったら次は、
それを実現する上で必要なシステムの機能を定義していきます。
例えば、「ユーザーが購入する家具を探す」といったプロセスがあった場合にも、
家具の種類や条件から探す、部屋のテイストから探す、評価の高い出品者から探すなどいろんな形態が考えられます。
サービス特性に応じてどんな機能が必要かということをヒアリングしながら、定義していきます。
機能の定義が終わったら次は、
それらの機能を実現する上で必要な画面を定義します。
例えば「ユーザーが会員登録をする」機能を実現するためには、
「メールアドレスとパスワードを登録する」画面
「認証メールを送信完了したことを表示する」画面
「初回ログイン時プロフィールを入力する」画面
などが必要になるかもしれません。
実際のユーザーの操作を想像しながら画面を定義します。
3. 外部システムとの関係や連携機能の定義
本システム内では行わず、外部のシステムで行うことも定義していきます。
例えば、
購入時のクレジットカード決済機能はStripe(決済代行サービス)を利用する、
ユーザーからの問い合わせ対応はZendesk(カスタマーソフトウェア)を利用するなど、
利用する外部システムの定義と、連携方法の定義を行います
4. 定時で自動実行される(バッチ)機能の定義
画面には表れないような、定時で自動実行される(バッチ)機能も漏れなく定義をしていきます。
例えば、
購入してxx日後の9:00に家具使用感のレビュー依頼をメールで通知する
などサービスを成り立たせるために必要な機能を定義します。
5. 非機能要件の定義
機能面以外で必要な、性能や信頼性、セキュリティ、システムの構成等の定義もしていきます。
例えば、
期待される性能として、ユーザー利用のフロント画面の表示時の平均サーバーレスポンスタイムが1.5秒（1500ミリ秒）を超えないことや
負荷要件として、10,000PV / 時は耐えられるようにする、
対応するブラウザは何か、
サーバーのセキュリティをどうするかまたその脆弱性診断はどのように行うかなどなど、、
必要な項目の定義を行います。
オプスインでは20以上の項目を定義しています。
最後に
上記の5つの項目を行うことでシステムに必要とされる要件が決まっていきます。
いかがでしたでしょうか。
要件定義フェーズでやることのイメージをつけていただくことで、
少しでも新規事業開発のお役に立てれば幸いです。
