はじめに

これは設計時の見落とし Advent Calendar 2018の25日目の記事となります。

業務アプリケーションの設計をするときに、見落としがちなところに焦点をあてて紹介します。
下流工程からの手戻りを少なくして双方の負担を減らしましょう。
バッチ系とシステム系について書いてみます。ただ元記事が10年前なので今となっては古いところがあるかも知れません。

これまでの記事一覧

いつ行うか（日次/週次/月次の処理頻度）
どの程度処理に時間がかかるのか(1回当たりの処理件数)
バッチ処理中はその期間内のデータ更新を不可としているか
許容時間より処理がかかった場合はどうするのか
DB更新ならCommitする単位(件数)をどうするのか
ログ出力が考慮されているのか(異常箇所の把握)
異常終了した場合の再実行の考慮をしているか(運用含め)

再実行する場合、データ全体を処理前に戻して再実行する方法と、異常終了した時点から再実行する方法があります。
仮処理(締め前に現在の集計結果をみたい)でバッチを流すことも考慮する(完了フラグを更新するかしないかの違い)

マスタの履歴を考慮するとか、変更されることが考えられるマスタはトランデータにマスタの内容ごとセットするとかの考慮が必要。
マスタを変更すると過去のデータを参照した場合も、最新のマスタ内容で出力されることをユーザーに周知しておく必要がある。

採番する単位をどうするのか？
所属ごと分けるのか、全社共通とするのかなど

伝票番号など飛び番があると、あとで問題になることがあります。
例外エラーの発生等により飛び番で作成されてしまう場合がありますので、ユーザーに了解を得ておく必要があるかと思われます。
ログなどで追える考慮は必要かもしれませんね。

※上場企業では伝票番号の飛び番は許されません、不正があると思われるため

途中登録をどうするのか？
例えば見積入力画面では「保存」、「確定」の2つの状態が存在する。

業務担当者が忙しいなどの理由で完全な情報として登録出来ない場合には「保存」を行いデータベースに書き込む、この状態の場合には見積りとして確定させない。

順序を追って処理する場合、登録した行為を戻す処理を考えておく。

≪例≫

どこまでシステムで対応するか、どこまで手で対応するか？
それとも放置なのか？

アクセスログをどの単位で、どこまでとるのか？
個人情報保護により調査する必要性も考慮し、かつ、アクセスログを取ることで動作が遅くならないか・・・などなど

設計時の見落とし Advent Calendar 2018の最後の記事でした。
参加して頂いた皆様ありがとうございます。

最後の3日くらいは箇条書き状態になってしまいました。本来はもっと一つ一つに焦点をあてて記事を書ければ良かったのですが、まだ至らないところです。
設計時の見落としについては、ネタがあればたまに書いていきたいと思っています。