6-1.バッチプログラム設計書の作成
設計書の構成
かつてのウォーターフォール型の開発では、概要設計(要件定義書)～基本設計（外部設計）～詳細設計（内部設計）という三段階の設計を経てプログラミングに入っていました。
場合によっては、更に詳細な文書として「プログラム設計書」があったりしましたが、最近はそこまで文書を作成しなくなっていると思います。
プログラム言語が高級言語化することで、実装の都合によるロジックの説明を記述する必要性が減ってきており、ビジネス的な要件をそのままの形で実装に落とし込みやすくなっているためです。
特にSQLの登場は画期的で、データ取得元の表がFROM句、そこから取得する項目がSELECT句、抽出条件がWHERE句として記述されます。更には登録先のテーブルとその列情報のマッピングがINSERT文となります。
つまりは、プログラミングの主要な部分は設計書から、そのままSQL文に落とし込みやすくなっているのです。
最近では、概要設計書と項目のIN/OUTを記載したマッピング定義書(ほぼSQLの内容)の2本立てが多いと思っています。
以下に、バッチプログラム設計書の章立てと、その内容を記します。
OracleやPL/SQLというくくりに限らず、様々なシステムのバッチプログラムで使用可能かと思います。
設計書の章立て
設計書に記述すべき要素は以下のようになると思います。
【機能概要】
ビジネスを実現するために、この機能が何をするのか、ということを言葉にします。
決してロジックは記述しないこと。
例）経費精算システムから送られた経費データを、仕訳データとして加工を行い取り込みます。
のような文章で十分でしょう。
良くありがちな悪い例は次のようなものです。
悪例）経費精算システムから送られたCSVファイルを1行ずつループで読み込み、XXXXマスタで○○コードの変換を行い、ZZZZZテーブルにINSERTします。
ここでは、この機能が行うべき業務上の処理すべき事を記載するセクションであり、どのようなロジック、実装を行うかは、もっと後ろのセクションで記述すべきです。
【前提条件】
この処理を実施する上で整えられているべき条件。
前提となる処理や整えておくべきマスタデータや環境について記述します。
・（夜間バッチ専用として動作するため）オンラインがクローズされていること。
・XXマスタが最新化されていること
・事前に○○処理が正常終了し、△△データが作成されていること。
といった、この機能を動かすために、事前に行われているべきことを記述します。
時々「連携元のデータが正しいこと」といった予防線を張っているような記述をする人が居ますが、そういうためのセクションでは無いことに注意しましょう。
【実行タイミング】
この機能が実行されるタイミングを記述します。
大まかにはスケジューラによる時間指定起動なのか、ユーザー操作によるオンライン起動なのかを明記すべきでしょう。
スケジューラ起動であれば起動時刻やサイクル（日次、週次、月次なのか）も必要になります。
【データフロー】
これは個人的な意見かもしれませんが、設計フェイズではデータフロー図を書きます。
処理とエンティティ（表）の関係を記述します。
外から入ってきたデータが、どのような経路をたどって最終的な出力結果に至るのかを一目でイメージできる図があると、システムの理解が深まります。
【ER図】
改めて説明の必要は無いかと思います。テーブル間の関連を表した図です。
実は、私はこれをあまり書いたことがありません。
本当にテーブル構成が複雑な大規模システム開発の際にかなりきっちりしたモノを作りましたが、それ以外は、参考情報として記述するくらいです。
とは言え、SQLの記述経験が浅いうちは常々ER図を書くようにしておくことをお勧めします。
SQLを記述する上でも便利かつ確実に記述できますし、テーブルの関連を図式する習慣がついていると、後々システム設計を行うようになってからも経験が生きるでしょう。
【処理フロー】
ここではじめて、処理全体の構成が登場し、実装のイメージが見えてきます。
業務でのデータ処理手順に準じつつ、プログラムの実装も意識しながら記述します。
それが一致するのが望ましい姿ですが、どうしても矛盾が生じるケースも出てきます。
そのような場合は、とにかくわかりやすく記述することを心がけます（それは自分自身にとってではなく、レビュアーとなる同僚や上司、顧客、そしてこの文書を読んで作業をすることになるプログラマ、それぞれの立場にとって誰もがわかりやすい文書になることを目指します）。
また、処理の流れは文章でもなく、単なる箇条書きでもなく、いくつかの章立てに分け、１つの章の中にロジックを記述するようにします。
章＝プロシージャの関係が成り立つことをイメージしながら記述するのが望ましいでしょう。
【例外ケース一覧】
エラーのケースとエラーメッセージの一覧です。
【リカバリ方法】
例外発生時のリカバリ方法です。
単純に再実行するだけでリカバリ可能であることが望ましいのは言うまでもありません。
しかし、実際にはそのようにいかない場合もありますので、再実行時に必要な作業（マスタのデータを修正する、ワークテーブルをクリアする、等）を記述します。
概要設計書の記述内容としては、このくらいのことが記述されていれば概ね足りるでしょう。
より詳細な内容については、マッピング定義書として記述します。
