よくある例えがよくないケース
以前、ジョークやユーモアに関する書籍で、「考え落ち」についての項目があった。
落語家がよくやる例えは「武士の印籠が落ちたのを見て飲食店の亭主が『お食事は如何ですか」という噺なのだそうだ。筆者はこの噺がわかりにくく面白くない理由を説明している。
「『印籠が落ちた』という事象から『空腹で腹帯が緩んだ』という結論を想起させるのは無理がある。印籠が落ちるのにはたくさんの可能性があり、聞き手は迷いが出て笑えない」
たしかにそうなのだ。よくある例えが、必ずしも適切とは限らない。フローチャートの問題でも同じようなことが言える。
よくある設問がよくないケース
プログラミング学習の一環でフローチャートを描かせる先生がいる。
例えば「朝起きてから家を出るまでのフローチャートを書きましょう」といった具合だ。
私はいつもこれは悪問だと思っている。
粒度が明確ではないので描きたくても描けないのだ。
たとえば「朝食を作る」という一言で終わる場合もあるし、「パンを焼く」「ミルクを入れる」という粒度に分解することもあるし、「まずキッチンに入り右に90度方向転換の後、前進3歩」のように動作のレベルまで分解することもある。
これはプログラミングでも同じことが起きるんだけど、その話をここでいっぺんに考えさせるのは無理がある。
また、人によって動作が違うので共通化できないというのもある。
プログラミングにおけるフローチャート
この時講師の大半があまりにも慣れきっていて見落としているのは、フローチャートを作る粒度についての前提条件である。
フローチャートを作る粒度にはきちんと前提条件がある。
まずは選択肢を用意しておくべきだ。「目を覚ます」「朝食を食べる」「お手洗いに行く」「カバンを持つ」「靴を履く」「家を出て鍵を閉める」……といった要素を並べ変えさせる。これはメソッドを選ぶ作業に相当する。
プログラミングの授業では、この粒度は暗黙の前提になってしまっていることが多い。
例えば、最大値を求める際のアルゴリズムを考えさせる時には、なんとなく、四則演算と比較演算子を使うような気分でいる。
しかしよく考えてみれば、「最大値を求める」メソッドがある言語もあるだろう。その場合フローチャートは「開始→最大値を求める→終了」でいい。
私の場合
私がプログラミングについて教える時には、解説時にこの粒度について触れる。受講者の回答をいくつか比較し、ここは粒度が高い、低いなどの解説を加える。
レイヤーの低い言語ではメモリレベルで制御することもある。洗練された言語では便利なメソッドがたくさん取り揃えてある。
つまり、粒度について説明することを前提に自由度が高い問題を投げるのだ。そうでないと、なんだか初学者はわかったような、わからないような、モヤモヤした気持ちを抱えてつまずいてしまいがちだ。
