RDBを使うシステム開発においては、レスポンス（応答時間）がかかることも、障害の一つにあげられます。
画面では、3秒ルールというものがよく言われていますが、どんな機能においても、3秒以内の応答を確保できるという保証はありません。
基本設計時には、どういう処理がどのくらい時間が掛かるかをSEが知っていて、お客さまに、その時間で許されることなのかを確認する作業が必要になります。
もちろん、ハードウエアの選択、ネットワーク、同時使用人数など、さまざまな条件において、レスポンスは変わってきてしまうわけですから、何を標準としてレスポンスを計るかの前提条件も重要になります。
実際、わたしなどは短気ですので、社内テストにおいても、画面の操作で、ボタンを押してから数秒間何も表示されない状態は、本当に嫌いなのです。
（そういう意味では、人よりも許せる範囲が少ないので、SEに向いているともいえるでしょう）
ましてや、操作しても応答までに数秒ではなくて10秒、ひいては1分もかかるということであれば、後から「何とか速くならないか」というクレームが入るのも、当たり前のことなのです。
こういった場合、後からSQL文を直すということで対処することが多いのですが、実際のところは、詳細設計中やその前のデータベース設計時、そしてその前の基本設計時に、レスポンスについてどれだけ考慮して打ち合わせしているか、設計しているかで、ほぼ決まってくる話なのです。
レスポンスについては、オラクル社やMicrosoft社の、DB製品に特化したチューニングの書籍に任せたいと思っています。
私は、これらの本を読むことで、さまざまな示唆やアイデアを得ることができました。
さて、今回、敢えて確認したいことは、プログラム単体のレスポンスではなく、データコンバートや、移行、テスト環境の構築といったものについての作業時間の話です。
日々のバッチや締めのバッチもそうですが、こういった処理は、決められた時間内に作業が終わることが、必須である処理なのです。
例えば、お客様が使用していない深夜0時から朝9時までに行う、などです。
こういう処理の予測時間を想定しないで実行することはあり得ません。
必ず、どの順番でどの処理を行い、どのくらい掛かるかを、シュミレーションして行うことが必要です。
そして、10時間余裕があるとしたら、リスクバッファと終了後のチェックを含めて、半分の5時間が最大使用時間だと思っています。
また、最初に必ず「バックアップ」を行い、どの段階で処理を中断しても、「元の状態に戻せる」、つまり、最低でも、作業を始めるときと同じ状態に戻せることが、最重要です。
1,000万件の処理を行う場合、可能であれば、テスト環境で、同じ件数でどのくらい時間が掛かるのかを、全て網羅してシュミレーションしておくことが必要です。
RDBの場合、処理によって件数が多くなればなるほど、遅くなるものが一般的です。
100件と1,000件と比べて10倍、10,000件は100倍といかないのです。
インデックスを付けて処理を行なうのか、削除して行うのか。
どんなデータを確認して、正常処理が行なわれたと判断すべきなのか。
処理の前にシュミレーションを行い、準備しておくことは、ここでも重要なのです。
そしてもちろん、どのような環境下において、どんな処理が、何時間掛かったのかを記録し報告することは、他の仕事にも役立つことなのです。
Vol.00140