フローチャートの考え方を学びましょう
フローチャートとは簡単に言うと、プログラムの処理・作業の流れを表す図です。（フローチャートはプログラミングだけでなく、作業手順の確認・明確化等にも有益です。）従って、フローチャートは俗にいう設計図に相当すると思います。設計図が正しく書けていれば、後は設計図通り、プログラムを作成するだけとなります。またフローチャートを作成するという事は日本語でプログラムを作成するという事です。
即ち、ある意味、フローチャートはプログラムとは等価であり、プログラムの動作を全て表したものといっても良いでしょう。別な意味で言えば、フローチャートが正しく書けたら、後はそれをプログラム言語で実際に記述するだけとなり、正しく動くプログラムができたも同然状態になるといわれています。逆に言えばフローチャートが正しく書けていない場合は、プログラムが正しく動作するか？が付くといえるでしょう。
現在、講師はチャレンジコースの題材程度ではフローチャートを描くことはしませんが、新人の頃は作成するソフトウェア全てのフローチャートを描いていました。フローチャートを作成する事は、プログラム化する処理のステップByステップの処理記述を作成する事になりますので、その時点で処理の不明点・曖昧点が明確化され、プログラム作成以前に不具合となりそうな部分を無くしていけます。
フローチャートの作成は先ずプログラムの動作内容や作業の内容を書き出しておくことが必要です。作成編で具体的に説明しますが、作業内容やプログラム内容を箇条書きして必要項目が網羅されているか確認しましょう。既存作業を改善する場合は複数回（二回以上）作成した作業手順で現在の作業を実際に実施してみることを強くお勧めします。その際、書き出した内容に漏れがないか、不明瞭なものがないか確認してください。また、時間が掛かる作業や面倒くさい作業等具体的に内容の確認もしましょう。そういった点は、後で改善する時に重要且つ優先的なポイントになり得ます。
尚、ここで、何故当会では初心コースで最初にデバッグ手法を学んでいただくのかを説明しておきます。目的は二つあります。
一つ目は、プログラムというのは論理的なものであるため、作成するには論理的思考が求められます。デバッグも同様に論理的な動作を確認するものですから、論理的に操作する以外に方法がありえません。即ち、論理的思考に慣れて頂くのが第一の目的です。最初は難しいかもしれませんが、必要に応じてデバッグを繰り返すうちに、自ずと論理的な動作が身についてきて、結果論理的思考にたどり着けるものと考えています。
二つ目は、プログラムを作成し始めてからデバッグ手法を学んだのでは遅すぎるという事です。もし皆さんが、ご自身でプログラムを作成し想定通りに動作しなかったら、どうされるでしょうか？私の場合は動作しないと確認出来たら、直ぐにデバッグをして、どこが可笑しいのかを見極め、修正を行うようにしています。勿論、自身の作成したプログラムに問題がない場合もありました。その場合、デバッグする事で論理的な問題を全て排除（無い確認を）してその上でも動作しない結論に達した場合、何が可笑しいのか推論を立て更にデバッグで検証を行っています。結果から言うと、最終的にEXCELの問題という結論を得ることもあります。尚、何故デバッグの検証を十分行うかは自身のプログラムに問題がないことを確認する事が第一義ですが、同時に回避策を探るという側面もあります。何故、回避策を探るのかというと、バグ報告をしても簡単にはEXCELは修正されないからです。回避策があれば、それに従ってプログラムを修正し動作させています。