筆者がNPOの仲間と小中学生向けのロボットプログラミング講習会を実施していることはこの日記でこれまでも紹介してきた。毎年度，新規募集をかける関係で，4月は講習がない。この期間は講師にとって充電期間である。

　近代科学社が発行している「実践ロボットプログラミングLEGO Mindstorms NXTで目指せロボコン！」という本がAmazonで目に付いたので，購入して勉強してみた。藤吉弘亘さんら大学の先生方が共著で書いておられるだけあって，プログラミングの入門書としても優れているし，NXTについても，センサの仕組みなどがわかりやすく解説されている。ただし，解説されている開発環境は，C言語ライクなNXCとNXTソフトウェア（NXT-SW）であり，私たちがロボットプログラミング講習会で使用されているRobolabについては触れられていない。

　その本の中でPAD（Problem Analysis Diagram）に興味を惹かれた。PADが何かと書く前に筆者の講習会におけるこれまでのジレンマについて説明する。

　小中学生にプログラムのパターンを教えることがどうも好ましく思えないのである。会社の新人向けのプログラミング教育なら，仕事として成果を早く上げさせるためにプログラムのパターンを覚え込ませることが必要だと思う。プログラムの定石を教えてしまうことがまず重要で，プログラムについて深く考えるのはその後でも構わないだろう。

　しかし，小中学生には「自分でプログラムを考える楽しさ」とか「自分で解決策を発見する喜び」を味わってほしいと思う。だから，プログラミングを穴埋め問題みたいにしたくないのだ。

　でも，プログラムパターンを教えた方が，結果が出やすいのである。結果が出れば，当然，やる気が増幅する。教えないと結果がついてこないので，なんとなく遊びになってしまう。これが私のジレンマの要約だ。

考え方を教えよう

　実際にプログラムを作成する前に，考えをまとめる手段として，フローチャートによって図式化する方法を教えようという意見は，以前から講師の間でもあった。よいことなのだが，私はもう一つ積極的になれなかった。というのは，フローチャートは自由度が高すぎるのだ。ビヨーンと線を延ばせるので，同じロジックのフローを書いても違う表記の仕方ができてしまう。フローチャートを教えるなら，プログラムのパターンごとのフローの書き方の定石も教えないと，標準化できない。

　また，フローチャートは，構造化プログラミング以前のBASICやCOBOLプログラムの作成時に使われており，突然，遠くのラベルへジャンプする処理を表現しやすい。もちろん，入念にロジックを見直せば，きれいなフローチャートを作成できるのだが，スパゲッティのようなプログラムをスパゲッティのままで表現できてしまう柔軟さがフローチャートにはある。

　これに対し，PADは1980年ごとに日立製作所の二村良彦さんたちによって考案された構造化プログラミングにマッチした問題分析図である。プログラムを処理，選択，反復の三つの記号だけで表現し，プログラムは基本的に上から下に流れるだけだ。

　1980年代は，構造化プログラミングが主流になった時期である。goto文でどこかのコードブロックに飛ぶのではなく，サブルーチンを実行することが当たり前になった時期である。

　現在はというと，オブジェクト指向の普及時である。だったら，UMLの各ダイアグラムを教えるべきなのかもしれないが，オブジェクト指向の各図に対応する言語は，JavaやC++である。オブジェクト指向のロボットは小中学生には荷が重すぎる。大学や企業でやってくれればよい分野だ。

　関数型のNXCとマルチタスク当たり前のNXT-SWはたしかに，PADとうまくマッチすると思う。Robolabは歴史が長いので，フローチャートともマッチする。たくさん，飛び先を作成できるからだ。でも，Robolabでもサブルーチンを作成したり，マルチタスクを実行することはできるので，PADで，まずプログラムを考えることも可能だと思う。

　記号が簡単なので，子どもたちも書きやすいだろう。ノートに鉛筆でPADを書いてからプログラムを作成するようにすれば，パソコンやロボットのないところでもプログラムをビジュアルに考えられるようになるはずだ。

　「プログラムを考えるのはおもしろいだろう」と，どれだけ言ってみても，所詮，それは自分の考え通りにロボットが動いた成功体験のある子にしか伝わらない言葉だ。考え方や身に付けてもらうためには，ツールを教えなくてはいけない。“考えるためのツール”としてPADを使ってみよう。