会員証アプリの要件定義

要件は「なにがしたいか」「どんな品質を満たすべきか」を整理するもので、「どう実現するか」(設計)とは分けて管理しています。

整理の方針

要件ドキュメントを書き始める前に、次のルールを決めました。

• 機能要件は、アクター(登場する役割)を主語にした「できること」で記述する。実装レイヤーや画面仕様は書かない
• 非機能要件は、開発フェーズの暫定目標とリリース時目標の二段構えで定量化する。最初から本番品質を狙うと開発が進まず、目標がないと品質が曖昧になるため
• 実現手段(採用技術・構成)は要件に書かず、設計側に書く

登場する役割と組織構造

要件の主語になるアクターは、会員(エンドユーザー)、ショップスタッフ、テナント管理者、プラットフォーマー(運営)の4つです。

契約と店舗の関係は「テナント」と「ショップ」の2階層で表現します。

• テナント: サービスの契約単位。個別店舗・商店街・モール・チェーン本部など、すべての契約主体が該当
• ショップ: 実際の店舗で、会員証が使われる場所。商店街内のチェーン店支店のように、1つのショップが複数のテナントに所属することもある

graph TB
    Platform["プラットフォーム"]
    TenantA["テナントA<br/>(契約単位。本店と支店を束ねる)"]
    TenantB["テナントB<br/>(商店街・モールなど)"]
    TenantC["テナントC<br/>(契約単位。店舗1軒)"]
    ShopA["ショップA<br/>(本店)"]
    ShopB["ショップB<br/>(支店。商店街にも加盟)"]
    ShopC["ショップC"]
    ShopD["ショップD<br/>(個別店舗)"]

    Platform --> TenantA
    Platform --> TenantB
    Platform --> TenantC
    TenantA --> ShopA
    TenantA --> ShopB
    TenantB --> ShopB
    TenantB --> ShopC
    TenantC --> ShopD

この図のように、1店舗だけのお店(テナントC)でも、複数店舗を束ねるチェーン(テナントA)でも、商店街やモールのように複数のテナントが同じショップを共有する場合(テナントB)でも、同じ構造で扱えます。この「1店舗でも商店街でも同じ構造」が、個人店から地域単位まで同じ仕組みでカバーするための土台です。

反面、1店舗だけのお店でも「テナントとして契約し、その下にショップを登録する」という2段階の初期設定が必要になり、操作はやや複雑になります(手順は管理画面と運営の仕組みの「契約から運用開始までの流れ」を参照)。

機能要件の全体像

機能ごとに「要件・利用シナリオ・業務ルール」を1ページずつ整理しています。全体像は次の通りです。

機能	概要
アプリ機能	エンドユーザー向けアプリの基本機能(機能と画面)
デジタル会員証	店舗ごとの会員証発行・表示(必須機能)(紹介ページ)
チェックイン	来店記録・他の付随機能への連携基盤(紹介ページ)
ポイント・スタンプ	来店・購買による付与と特典交換(紹介ページ)
クーポン	クーポン発行・配信・利用・抽選(福引)(紹介ページ)
会員ランク	ポイント・スタンプの蓄積(台紙の進み)に応じた会員ランクと特典
お知らせ・通知	プッシュ通知とお知らせ(紹介ページ)
予約	来店予約(承認型・自動確定型)と店舗側からのショップ予約(紹介ページ)
鍵解錠	会員証連動の鍵解錠(将来提供予定)
運営管理	プラットフォーマー・テナント・ショップの関係と管理機能(紹介ページ)

各機能を検討する際の考え方は、システム非依存の形に一般化して業務ノウハウとして公開しています。

• 会員証概説
• 来店記録(チェックイン)概説
• クーポン概説 / ポイント概説 / 会員ランク概説
• お知らせ・通知概説
• 予約概説

非機能要件の整理

性能・可用性・セキュリティ・運用性・保守性・スケーラビリティ・法令対応の7カテゴリで整理し、数値目標は「暫定(開発フェーズ)」と「リリース時」の二段階で設定しています。

例えば可用性であれば、月間稼働率・障害復旧目標(RTO)・データ損失許容(RPO)のそれぞれに暫定とリリース時の目標値を定めています。最初から本番品質の数値を課すのではなく、フェーズに応じた現実的な基準を先に明文化しておくことで、品質の議論を後回しにしない、という進め方です(具体的な数値はここでは省きます)。

セキュリティは、次のような方針を要件として明文化しています。

• 認証は認証基盤に集約し、業務システム側はトークン検証のみを行う(パスワードを業務側で保持しない)
• 会員向け機能は「本人のデータのみ操作できること」(所有者検証)を必須とする
• トークン・パスワード等の機密値はログに出力しない
• データは論理削除で履歴を保持し、法令に基づく削除請求には物理削除の手順を別途用意する

業務ルールの決めごとの例

要件段階で決めた、システム全体に効く決めごとの一部です。

• 決済機能は持たない。既存の決済手段との共存を前提にする
• 紙の会員証との共存を前提にする(全廃を強制しない)
• 同一会員 × 同一テナントの会員証は1枚のみ(重複所有不可)
• 日時は日本時間(Asia/Tokyo)で統一する

こうした「やらないこと」「割り切り」を要件段階で明文化しておくと、設計・実装での迷いが減ります。

つづきは 設計 へ。