【Excelプログラミング講座】9　デバッグをしよう！

​​​​【Excelプログラミング講座】第9回です。 この講座では、エクセル野球シミュレーション「ダイナミックベースボール」のゲームプログラムを材料として、エクセルVBAでのプログラミングを初心者向けに解説していきます。 ▼ダイナミック・ベースボールのページ 過去記事をまとめたサイト↓ ▼​エクセルプログラミング講座 前回は、条件分岐が複雑化すると何がどうなっているか分かりにくくなるので、 「ノートにすべての場合を書き出し、一目瞭然にしておく」という話をしました。 お盆休みをはさんだので、もう忘れてますか？ そんなときは、​​前回​​をもう1度見に行ってください。 （この連載記事にどれだけの需要があるのかは分かりませんが・・・） さて、そんなふうにすべての場合を想定してプログラムを組んだとしても、 人間のやることですから、分岐によってはうまく作動せず、エラーになることが多いです。 エジソンも言いました。 失敗は成功の元。 プログラムのエラーは、あって当たり前。 そのエラーをすべて見つけて、ことごとく修正していくことによって、完成していくのです。 「ダイナミックベースボール」は公開後10年以上経ちますが、いまだにエラーが発見されます。 エラーを見つけることをデバッグ（バグとり）といいます。 ゲーム会社では、デバッグ専用の人たちが日夜テストプレイに明け暮れます。 一般ユーザーがどんな操作をするか分からないので、ありとあらゆることをやってみて、プログラムが誤作動しないかチェックするのです。 で、今回はそうやって見つかったバグ（エラー）をどう修正するか、を実例で紹介します。 「にかとまは、実は野球ゲームを作っています 」という僕のブログ記事に寄せられた実際のバグ報告を元に、紹介します。 【エラー内容】 ・セーフティバントをした打者がアウトになった場合に 　打数が２増えてしまいます。 【エラー報告を聞いたときの思考】 ・打者成績の細かいところまでよく見てくれてる！ ・打数が1増えるべきところを2増えていると言うことは、二重に処理されているかな？ ・セーフティバントをした後のプログラムの処理を順に追っていこう。 【デバッグの実際】 （1）再現を試みる エラー報告のとおりに自分もやって、同じことが起きるかどうか、確認します。 今回のエラーの発生条件は、「セーフティバントをしたとき」なので、 再現が容易です。 セーフティバントをして、すぐに打者成績のワークシートを見てみると、 確かに、打数が2増えていました。 （2）原因を突き止める 「バント」ボタンを押したときのプログラムは、 標準モジュール3　の　「バント」のところに書いてあります。 バント処理の最初の条件分岐は、ランナーの有無が条件。 セーフティバントとはランナーがない状態のバントなので、 記述をず～っと下に行くと、以下の箇所があります。 ～～～～～～～～～～～～～～～～～～～～～～～～ MsgBox ("なんとセーフティバント～！！")， ， "バント！" Call SeisekiB(Range("H6")， 22) ～～～～～～～～～～～～～～～～～～～～～～～～ Call SeisekiB(Range("H6")， 22)　の意味は、 　　バッター成績反映のサブルーチン（SeisekiB）を呼び出し　 　　DB_main.xlsの”H6"番地のセル＝選手名を、 　　DB_teamdata.xlsで検索し、22番目の列＝「打数」を1増やす すなわち、ここでいったん打数が1増えています。 その語の記述を追っていくと、 やはり！ Call SeisekiB(Range("H6")， 22) という、打数を1増やす命令がまた出てきました。 二重処理がめだたく見つかりました。 あとは、どちらかを削除すればいいわけです。 さて、どっちをとるか？ どっちをとってもいいのですが、 条件分岐の中の処理をとるよりも、条件分岐する前の処理をとったほうが わかりやすいので、最初のをとることにします。 （3）プログラムを修正する ～～～～～～～～～～～～～～～～～～～～～～～～ MsgBox ("なんとセーフティバント～！！")， ， "バント！" Call SeisekiB(Range("H6")， 22) ～～～～～～～～～～～～～～～～～～～～～～～～ ここの、最初の　 Call SeisekiB(Range("H6")， 22) というのを、消します。 これで、めだたくデバッグ終了！ （4）動作確認 本当にエラーが直っているかどうか、確認しなければいけません。 実際に「バント」ボタンを押し、セーフティバントを敢行して、打者成績への反映具合をチェックします。 直っていると、ほっとします。（＾0＾） 【今日のまとめ】　デバッグの手順 　　​​ （1）再現を試みる （2）原因を突き止める （3）プログラムを修正する （4）動作確認 完璧主義の人は、こういうバグ取りにすんごい熱意を燃やして、バグがとれるたびに歓喜に打ち震えます。そして、デバッグの苦労が大きければ大きいほど、「完成した！」と思えたときの喜びも大きくなります。 テストプレイはとっても大事ですので、もちろん自分でも何度もプレイしてチェックするのですが、同じ人がデバッグすることには、限界があります。その人が考えもつかないことをやってくれることもありますので、なるべく他の多くの人にデバッグしてもらうようにしましょう。 身近にそういう人がいない場合は、未完成版の時点でネット公開し、デバッグ報告を多数の方から受け付けるのも一つの方法です。 さあ、あなたも、レッツ、デバッグ♪​​​