【システム開発】バリデーションのポイント

単項目チェック

共通

長さチェック

姓

旧字体チェックを含めた使用可能文字チェック

名

旧字体チェックを含めた使用可能文字チェック

住所

旧字体チェックを含めた使用可能文字チェック

電話番号

許可文字はプラス（国際電話）、ハイフン、数字の3種類

メール

RFC体系に沿うようにする。

日付

存在する日付かチェック

複数項目チェック

• 元号と日付のチェック
• 開始日、終了日のチェック

業務チェック

• 会員ID存在チェック
• 排他制御

その他のチェック

非機能要件のチェックに使う。個々の画面では行わず共通処理として実装する。他のチェックに比べて高い技術力が必要になる。

ログイン認証

セッションタイムアウトチェック

エラーになった場合はログイン画面に戻してあげると親切

サービス時間外チェック

エラーメッセージのポイント

ユーザーが気付きやすいようにエラーメッセージは多少強調してあげることが重要

どこでチェックするか

基本、チェックに担保が取れるサーバーサイドでチェックを実施をして、工数的に余裕があればフロントエンドでもチェックを実施するというのがスタンダードです。特にインターネットに公開するようなWebアプリであればフロントエンドでのチェックも実施した方が良いでしょう。

フロントエンド

• JavaScriptで行う。
• サーバーへの通信が発生しない。
• 画面で持っている情報しか利用できない。
• ユーザーがソースを改ざんして突破されてしまう可能性もあるので注意

サーバーサイド

• サーバーへの通信が発生する。
• 入力値をDBや外部システムを参照可能
• ほぼ改ざんされる可能性がないので担保が取れる。

チェックの順番

「単項目チェック→複数項目チェック・業務チェック」の順にやるのが一般的。

例外的なパターン

複数画面で登録を行うパターン

他の人と競合しないように必ずDB登録前にもチェックを行うことが必要。なお、複数画面に登録においてエラー内容によって画面の遷移先を戻すというのは多岐に渡る場合があり非常に工数がかかるケースも多いので気軽にできる内容ではないです。顧客調整をして行うようにしましょう。

日付跨ぎ・年跨ぎ

年が変わってマスタデータが変わる場合に、前年、前日のデータとして登録してしまわないか。

法改正・キャンペーン終了・有効期限切れ

前年度の契約条項を確認してしまった上で登録処理をさせていないか。

実装方法

ValueObject

DDDなどでは一般的です。適正な値はドメインでちゃんと処理しましょうねという考え方です。

モデル

RailsやLaravelなどのフレームワークなどを使った場合は一般的です。

Controller

バリデーション専用のモデルを作って呼びましょうという考え方です。確かにまとまっていてわかりやすいかも。