現場で3年目くらいの人が基本設計で四苦八苦していたので、設計過程とか成果物レビューとかで色々考えたり気付いたり事があったので共有します。
私個人の考え方ですので、明らかに間違っている点や説明不足などありましたらご指摘していただけると助かります。
基本設計の考え方
基本設計は、やりたい事をどうやったら実現できるかを設計することです。
事前に要件定義フェーズがあって、そこでやりたい事と言うのが決まっています。
それに対して、システムとしてどうやったらできるかな、と考えて、それを人に説明するお仕事です。
基本設計のレビュアーは、やりたい事がその設計で本当に実現できるか、もっと効率良い方法はないか、
実現方法にシステムの制約が抵触していないか、などを確認します。
やりたい事の粒度を細かくする
要件定義フェーズで決まったやりたい事というのは、まだやりたい事としては大味です。
なので、まずは少し粒度を細かくして、説明しやすくします。
基本設計レビューとかでは、要件定義との認識違いが発生していないかの確認で有用です。
各項目の実現方法を説明する
実際に、どうやったら実現できるかを説明します。
基本設計にあまり慣れていない人は、ここだけ基本設計書に書いてレビュアーに
「何が書いてあるかわからない」「もっと具体的に」「そもそも要件理解してる？」とか言われます。
具体例１
要件：夜間実行のバッチ処理が遅すぎてそろそろシステム開始時間を超える恐れが出てきたので改善する
基本設計開始
私「調査した結果、取引数増大によってメインの会計処理の数が増えたからっぽい」
私「最近クラウドで流行りの並列でやれば処理あんまり変えずに短縮できるんじゃね？」
やりたい事のリストアップ
・「メイン処理」を並列実行することによって速度を改善する
→これにより、現状の処理にあまり手を入れずに速度改善が見込める
・バッチ処理を「前処理」「メイン処理」「後処理」に分割する
・「メイン処理」を並列実行できるように処理を変更する
・エラーが発生しても処理を止めない（既存通り）
・前処理から再実行することで、エラーが発生して未処理だったものだけが再実行されるようにする（既存通り）
実現方法
前処理で、会計処理を行う必要があるレコードを抽出し、レコードの主キーを100件ずつまとめて、新規作成する並列実行管理テーブルに登録する。
テーブルに登録するのは主キー100件と、並列実行管理用のIDとする。
テーブル登録をトリガーとしてメイン処理バッチが起動するようにする（複数起動可能）。
メイン処理では登録された主キー100件分を直列実行し、結果登録テーブルに実行結果を登録する。
→エラーが発生した場合は、エラーが発生したレコードの主キーと、エラー内容を登録する
前処理バッチにエラー再実行用の引数を設定し、エラー発生レコードのみを抽出して再実行できるようにする
全てのメイン処理が終了後、後処理バッチで結果を統合する。
レビュー指摘など
テーブル登録をトリガーにするのはどうやるのか？
並列実行管理テーブルのテーブル設計を書いて欲しい
後処理バッチの起動についての記載がない。どうやって全てのメイン処理が終わったことを判定するのか？
このシステム内で並列実行してる処理は一つもないのでそんな前例のない事はやめてくれ。
具体例２
要件：夜間実行のバッチ処理が遅すぎてそろそろシステム開始時間を超える恐れが出てきたので改善する
基本設計開始
私「だいたいこういうのはクソ重いSQLを改善すればどうにかなるんだよな」
私「やっぱり実行に20秒かかってる副問合せマシマシのSQLあるっぽいわ。直すべき。」
やりたい事のリストアップ
・実行に時間のかかっているSQLの改善によって処理速度を改善する
実現方法
バッチ処理で実行している全てのSQLを洗い出し、SQLの実行計画を確認する。
重いSQLを改善する。
レビュー指摘など
全てのSQLって何本くらいあるのか？
→600本です
→それ全部確認するのものすごい時間かかるのでは？今遅いやつだけにしたらどうか。
システムがかなり売れていて、今後数年で規模が10倍くらいになりそうだが、すぐ同じ問題が発生する可能性があるのではないか？
バッチ処理はかなり複雑なのだが、SQLが本当に正しく修正できるか不安。そのリスクを負いたくない。