投資すべき理由と要件定義4
投資すべき理由と要件定義3の続きです。
投資が必要な理由を明確にしつつ要求を定義していきます。前回投稿した「投資すべき理由と要件定義3」の稟議書に書いてある、本当に欲しい機能は「再配達の時間を受け付ける」だけなのです。
だから「自動的に時間をずらす」「LINEやメールなどで配達しますよ、連絡メールをいれる」などの便利機能は機能は不要です。
［便利機能の実装には個人情報（個人を特定できる情報）と紐づけていくことが必要になります。例えば配達住所を変更するには、現在設定されている住所と新しい配達先の住所を入植する必要がありますし、配送には必ず個人名が入りますので、名前と住所、名前とメールアドレスなどで個人を特定することが可能になります。これらの機能の実装はとても大きな工数がかかることが理解できると思います。]
もしも自分が企業側の担当者であれば「再配達完了時にメールもしくはSMSで連絡する」のみ、要求用件に入れるかもしれません。それでも経費がかかりますし、再配達時に時間を確認して「OK」と入力されたら確定するという、確認フローをいれますから最初のサービスインでは不要と判断するでしょう。
会社にとって経費は無限ではありません。
さて、実際に再配達を受け付けるためのシステムを考えてみましょう。ご不在票には下記の情報が記載されています。
・問い合わせ番号
・配送業者名と担当者（TEL）
・不在票を入れた日時
・送り主の情報
・荷物の内容
本当に再発配達に必要な情報は何なのか？それは問い合わせ番号です。データベースの構造がイメージできる人は、すぐにピンとくると思いますが、不在票のなかでユニークな項目は「問い合わせ番号」以外にありません。
なので「不在票の情報より、再配達依頼ができるホームページ（と音声受けシステム）を作る」「セキュリティ対策より個人情報はなるべくシステム上に保持したくない」
までが要求仕様になります。
要求仕様を満たすための、要件を定義します。最低限のシステム動作（お客様で操作する画面）は
・「問い合わせ番号」の入力
－＞入力された番号がある場合－＞配達日と時間の入力
－＞入力された番号がない場合－＞問い合わせ番号の入力に戻る
・配達日と時間の入力
－＞入力された日時に再配達が可能－＞受付完了
－＞入力された日時に再配達が不可能（もしくは入力誤り）－＞配達日と時間入力に戻る
以上になります。
上記のようにお客様の画面を動作させる場合に、画面以外でシステム側に実装が必要な機能は
・受付するべき、問い合わせ番号のデータを販売管理システムよりインポート
・受付した問い合わせ番号と再配達日時を配送業者毎に渡す画面を作成（もしくは販売管理システムや配送業者管理システムへエクスポート）
でしょうか？
それ以外にも「販売管理システムとの連携は１日？回とする」「受付したデータはｘｘｘｘシステムにｘｘ分毎にエクスポートする」「連携されたデータは２週間以上たったデータはすべて理論削除する」「理論削除してｘｘ月たったデータは物理削除する」が追加で要求定義として定義が必要になります。
さらにセキュリティ対策も必要です。
問い合わせ番号は個人情報ではありません。また問い合わせ番号と再配達日時以外のデータはシステム上には保持しないので、個人情報保護を考える必要がありません。これは大きな利点です。一切の個人情報および企業情報が入っていないならば、データベースを暗号化する必要がありません。
企業情報をWEB上に入れるのも、出来る限り回避したいので、自分ならば配送業者毎に再配達データを渡す画面は別システムで構築します。
ですがSQLインジェクションなど、セキュリティ対策は必ず必要ですが、圧倒的に工数を削減できます。
どうです？これで稟議書に書いてある「小さな会社では再配達時間指定システムがないので、再配達期日時間指定システムを構築する必要がある」はこなせていませんか？
使ってみて、本当に追加機能が必要なら、追加発注すれば良いと考えます。
このように、本当に必要な機能は？というのを洗い出すには、要求機能要件を決定している投資すべき理由を意識する必要があるのです。投資すべき理由に基づき、機能を要求している場合には、実装する必要・理由が明確に存在し、担当者はSI会社に、どんなに伝えにくい概念やイメージであったとしても、熱意をもって説明できます。
逆に言うと、SI会社は、理由なき機能を要求を受け入れてはいけません。必ず理由を明確にしてもらうこと、理由が投資すべき理由に紐づいていることを確認して、プロジェクトを推進する必要があると、自分は考えます。
ちなみにシステム開発は「ルール（制約）をシステムで矯正する「という一面があります。制約を考えるには下記の読み物を斜め読みで良いので一度読んでみてください。
