データ登録処理時の確認メッセージと内容チェックの順序

業務システムを作っていると、データ登録処理なんてのは大量に作ることになるわけで、そのあたりのよくある機能や実装というのはいつものやり方があるかとおもいます。が、そのやり方を選択した理由まできちんと考えていて、人に聞かれたときに説明できるかどうか、というと意外に答えられない人が多いのでは無いかと。

実際、以下のような話が挙がりました。

データ登録処理の際内部ロジックをどう実装すべきか
- 登録ボタン押下 → 登録しますか確認 → データ内容チェック → 登録
- 登録ボタン押下 → データ内容チェック → 登録しますか確認 → 登録

どちらの実装を主張する人も、「普通こうだから」という理由しか話さないので、それぞれの方法を採る理由について考えてみました。

はじめに: これは設計者、実装者の責任です

まず先に言っておくと、この手の方針決めは「いつもそうやっているから」ではなく「なぜなのか」を人に説明できるように心がけましょう。設計にしても実装方針にしても、なんにせよ理由ありきで行うべきです。仕事で作るプログラムや設計に「なんとなく」はNG。特にプロジェクトメンバーが増えれば増えるほど、こうした理由をきちんと述べることで、作業依頼時に相手の腑に落ちる指示が出せますし、並行作業時に都度都度方針ややりかたを聞かれたりする回数も減り、余計な作業コストを出さないようにできます。こういうところに手間をかけず「いいからやれ！」という指示を出すと人間関係やモチベーションといった、修復に非常に手間のかかる部分で損害が出始めます。設計者もプログラマーも、常に「数ある選択肢からこの方法を選んだのはなぜか」に意識を向けましょう。

先に「登録しますか？」確認を行う場合

よくある「登録します。よろしいですか？」的な確認メッセージを先に出し、その後で内容のチェックと登録処理を行うという方式は、以下のような場合に使うと良いと思います。

データの内容に不整合やエラーが含まれる頻度が低い。

たとえば別システムで生成されたデータファイルが元になっている場合など、手作業の割合が少ない入力データの場合に向いています。この方式のデメリットとして、データにエラーがあった場合、利用者は確認メッセージとエラー通知、2回のメッセージを見る羽目になるというものが挙げられます。これがあまり頻発すると「メッセージ出す回数減らしてよ！」という要望につながる可能性もあり、「メッセージがウザい」といったクレームの元になる可能性もあります。なので、そういうことが想定されるなら後述の方式を検討しましょう。

一方、この方式のメリットは「ユーザー側のアクションと、プログラム側のアクションを綺麗に分離できる」ということにあります。利用者の「登録したい」という意思は登録ボタンで決定されているので、まずはそれに対して確認を行うことで「利用者主導の手順」をいったん終わらせます。そこから先はプログラム側の仕事。内容のチェックと、実際にデータを登録する処理を走らせる。たとえば、データ内容チェックと登録処理を合わせた結果を戻り値とする関数にするといった構造にし、入力されたデータの確認結果は「DB登録失敗などのシステム側のトラブルと同じレベルで通知される」ように作ることもできます。そうすれば、登録ボタン押下から始まる「UI系の処理」と「内部系の処理」を分離してプログラムの構造をわかりやすくしやすくなります。

先にデータ内容チェックを行う場合

「登録します。よろしいですか？」の前に入力内容のチェックと、不備があれば「登録できないデータが入力されています。」的なメッセージを出すという方式。この方式の最大のメリットは、データ不備があればメッセージは1回だけでやりなおし。確認メッセージは表示されません。すなわち、不備がある場合でもメッセージ回数は1回で済むということにあります。なので

データの内容に不整合やエラーが含まれることが多い。

という場合に用いると、UI上での利用者とのやりとりを減らすことができます。手作業で大量の入力を行うような場合などですね。ただし、この場合登録ボタン押下イベントから始まる処理は、あくまでメッセージ表示の要否を確認して必要であればメッセージ表示するという流れを主軸にしたものになり、プログラムの構造がフラットな感じになりがちです。よく考えて実装しないと、ひたすらべた書きの処理が並ぶメソッドを作りがち。ですが、利用者にたびたびメッセージを出して手を煩わせることが無くなるという点ではメリットも大きい方法なので、状況に応じて選択し分けましょう。

もう1つの方式: データ確認機能を用意する

全く別の方式として、あまりにデータ不備が多い場合や、利用者自身に「データをチェックしている」という処理を意識させたい場合、「データチェックボタン」のようなものを用意してそれを押さなければ先に進めないようにする、といった手もあります。こうすれば、データ登録時の確認は最低限のものにできます。この場合も「データチェックボタンを配置したのはなぜか」をきちんと考えて、基本設計レベルで設計書に記載しておくと、類似した機能の設計時や実装時の方針決めの指針となることがあります。

まとめ: 理由無しの設計や実装はやめて！

ここまでの内容はあくまで私の私見で、もしかしたらもっと良い考え方や理由があるかもしれません。ですが、仮に最善で無かったとしても方針や設計の根底にある考え方をこうした機能の端々できちんと説明することで、設計に芯を持たせることができます。こういう芯がきちんと見えれば、チーム開発などの場合の意思疎通やコミュニケーションを効率化できますし（迷っても指針があれば自分で決定できる）、最悪、利用者の要求と齟齬があった場合でも、何と何がかみ合っていないのかが明確になりやすいので、問題解消への道筋も立てやすくなります。とにかく、設計者、実装者は常に「自分がなぜそれを選んだのか、なぜそう決めたのか」を考え、必要であれば記述し、必要であれば都度関係者に説明できるようにしましょう。「適切な設計」「適切な実装」は、必ず利用者やシステム全体の仕上がりに好影響をもたらすはずです。