9月に行われた講演会の内容を書き起こしました。
ぜひ、ご覧ください。
自己紹介
こんにちは。初めまして。
「紙とえんぴつで学ぶアルゴリズムとフローチャート」著者の岩松洋です。
兵庫県の姫路市というところで、コンサルタントをする傍ら、
プログラミング教室をやってます。
大学卒業後、大手メーカーの子会社にてシステム開発に従事しました。
10年在職したのち退職し、実家の神戸に戻って一人プログラマーとして
合同会社グランドサークルを設立しいくつかのきっかけをいただいて
現在はコンサルタントをメインに活動しています。
2019年よりプログラミング教室を始め、
約10年ぶりにプログラミングに携わるようになりました。
というのがざっくりとした僕の経歴です。
今日は
「プログラミングを学んだのにプログラムを書けない」という課題を解決するために書いた
「紙とえんぴつで学ぶアルゴリズムとフローチャート」が誕生した経緯をお話します。
本に書いたこと
プログラミングを学んだのにプログラムを書けない！
出版のきっかけになったのは、当校で実施していた
アルゴリズム体験講座「紙とえんぴつでプログラミング」でした。
当校には
「テキストでプログラミングを学ばれた方が自分で作りたいプログラムを書くことができない」
という課題がありました。
出版のきっかけになったのは、当校で実施していた
アルゴリズム体験講座「紙とえんぴつでプログラミング」でした。
当校には
「テキストでプログラミングを学ばれた方が自分で作りたいプログラムを書くことができない」
という課題がありました。
「テキストに沿って学習を進めていき、テキストの課題は解けるようになったのに、
いざ自分でプログラムを作ろうと思った時に、どう書いたらいいかわからない」
という課題です。
おそらく多くのプログラミング教室が抱える課題だと思います
この課題の解決方法を考えるとき、
「プログラマーの頭の動きがどうなっているか？」ということを考えました。
システム開発には、
1．要件定義、2．外部設計、3．詳細設計、4．コーディング、5．単体テスト、6．統合テスト
という工程があります。
当校のテキストで主に身に付けることができるのは、4．コーディングでした。
プログラミング言語を学んでいたということです。
プログラムを作るために必要なのは、コーディングと、その一つ上流の詳細設計。
この二つでプログラムを書くことができます。
プログラマーがやっているのは詳細設計とコーディングだから、
足したいことは詳細設計だとおもい、アルゴリズム講座「紙とえんぴつでプログラミング」が始まりました。
【本に書いたこと：「プログラミングとは？」】
アルゴリズム講座には、プログラミング経験のない方も来られます。
そこで、プログラミングをどう伝えたらいいか？ということに悩みました。
例えばウィキペディアを調べると
「コンピュータープログラミングとは、ある特定のコンピューティングの結果・・・」という表現が見つかります。
この表現はプログラミングを正確に表現していると思うのですが、
このまま伝えてもプログラミング経験のない方に伝わるとは思えません。
そこで、考えて、小学生向けのプログラミングの本などを調べて見つかった表現が
「プログラマーがコンピューターにやらせたいことをコンピューターが実行できるように伝える」でした。
プログラミングは「伝えること」なので、伝えるためには、
・伝えることを相手が理解しやすいように組み立てる
・相手が理解できる言葉で伝える
この二つが必要です。
前者が設計を身に付けること、後者がプログラミング言語を覚えることになります。
相手に自分の考えを「伝える」ことなので、英会話にも似ています。
プログラミングは伝える相手がコンピューター、英会話は伝える相手が（おそらく）外国人。という違いがあるだけです。
【本に書いたこと：「アルゴリズムとフローチャート」】
プログラミングは「伝えること」。
伝えるために必要な、「相手が理解しやすいような組み立て」がアルゴリズム。
アルゴリズムを見やすいように図で表したものがフローチャートです。
例えば身近なこともアルゴリズムにできます。
私が自宅から最寄りの姫路駅まで移動するアルゴリズムは、
1．最寄りのバス停まで歩く
2．「姫路駅行き」のバスに乗る
3．20分ぐらいバスに乗って待つ
4．終点で降りる
5．姫路駅まで歩く
これがアルゴリズムです。
この日本語を理解できるロボットでもいたら、僕と同じように姫路駅まで移動してくれるでしょう。
これも立派なプログラムと言えますね。
フローチャートは、このアルゴリズムを一つずつを、長方形の箱に入れてつないだだけ。
「バス停まで歩く」→「『姫路駅行き』のバスに乗る」→「20分ぐらい乗る」→「終点で降りる」→「姫路駅まで歩く」
アルゴリズムより見やすくなりました。
こうやって作りたいプログラムのアルゴリズムを考え、フローチャートの形で書くことがプログラムの設計です。
こういう設計をやった後でプログラムを書き、コーディングをするとプログラムを作れるようになります。
【本に書いたこと：「紙とえんぴつで学ぶ」】
アルゴリズムやフローチャートを考えるときは、「手書き」をおすすめしています。
特に、考えることに慣れるまで、紙にえんぴつで書くことはとても有効な手段です。
科学的な根拠があるわけではありませんが、手書きは、目線と手先が一致します。
パソコンだと手と目が別々のところで動くので、考えが出にくい気がします。
手書きの方が考えが出やすいように思うので、最初のうちは手書きをしましょう。
頭の中にフローチャートが浮かぶようになったら、最初からパソコンに向かっても大丈夫です。
「紙とえんぴつで学ぶアルゴリズムとフローチャート」には、
プログラミング教室の生徒さんに書いてもらったフローチャートを掲載しています。
「手で書いた方が整理しやすい」と言ってくださる生徒さんが多かったです。
【本に書いたこと：「誰に何を伝えたいか？」】
「プログラミングを学んだのにプログラムを書けない」という課題をお持ちの方に
「設計を身に付けたらプログラムを書けるよ！」ということを強くお伝えしたいです。
プログラミングを諦めそうになっている方に、「大丈夫。設計を学ぼう」とお伝えしたい。
ただ、暗記では設計をできるようになりません。
本書で設計の手法や考え方を知って、アルゴリズムとフローチャートをたくさん練習してほしいと思います。
プログラムを書けるようになります。
【本に書いていないこと：「本質的な表現を見つける」】
僕は、プログラミングを
「プログラマーの作りたいものを、コンピューターに伝えること」と表現します。
「伝えること」だから、伝えるために「伝える内容」と「伝える言葉」が必要です。
伝える内容として設計やアルゴリズムが、伝える言葉としてプログラミング言語を学ぶ必要があります。
多くの教材で学べるのはプログラミング言語で、
そこに設計、アルゴリズムを加えると、プログラムを作ることができるようになります。
僕は「プログラマーの作りたいものを、コンピューターに伝えること」という表現が
プログラミングの本質的な表現だと感じています。
そして、本質的な表現が見つかると、それを身に付けるために必要なことも見えてきます。
例えば僕のお客様に鉄鋼業の方がいます。金属を削って加工する仕事です。
この仕事を「図面通りに加工すること」と表現しています。
また、僕がやっているセミナーでは、
経営について「経営者が『こうしたい』と思う会社像に近づけるためにする日々の行動」という表現をしています。
こういう表現が見つかると、その実現のために必要な要素も見つかります。
鉄鋼業の場合は、「図面通り」と「加工すること」。
図面通りを実現するために、図面を読み取る技術が必要です。
加工することを実現するために、加工技術が必要です。
実現方法や習得方法に悩んだときは、本質的な表現というのを探してみるのも一つの方法です。
そして、プログラミングの「設計」「アルゴリズム」に必要なものは、
全体の把握と分解や流れの整理。
これらは繰り返し練習することで身につくことです。
【本に書いていないこと：「『覚える』と『身につける』」】
例えば、じゃんけんをするとき皆さんは最初に何をしますか？
「最初はグー？」「じゃんけんぽん？」「じゃんけんに誘う？」「どの手を出すか考える？」どれが正解でしょうか？
僕は、最初にすることを「『じゃんけんぽん』と言う」と本に書きました。
他の答えはUdemyで公開している動画教材の課題の答えとして、受講者からいただいたものです。
どの答えも間違いではないです。
僕が本に掲載した「じゃんけんのフローチャート」を覚えても、
じゃんけんのプログラムしか作れません。
他のプログラムを作りたいと思ったら、アルゴリズムを自分で考えられるようにならないといけません。
暗記をしてできることは、同じことの繰り返しだけです。設計は身につけるものです。
じゃんけん以外のプログラムの設計をできるようになりたかったら、
「設計の考え方を知って、たくさん設計の練習をする」しか方法はありません。
設計は、設計者の数だけ答えがあっていいものです。
その設計をもとにして書いたプログラムが思ったように動いたら、どんな設計をしてもかまわない。
これが設計です。
設計の採点は、相手が「考えて」「書いた」ものを一つ一つチェックするしかありません。
その設計でうまくプログラムを書けそうなら、自分の答えと違っていても、OKにしないといけません。
こうやって採点するのは大変です。
とても評価しにくいです。
課題にしにくいものです。
まとめると、「覚えること」はマニュアルやメモを見ながらできます。
「身に付けること」は「考える」「やってみる」「振り返る」繰り返し練習や実践をやってみることでできるようになります。
同じことが当てはまる仕事はたくさんあると思います。
【本に書いていないこと：「全体と部分」】
プログラミングでは、作りたいプログラムが「全体」です。
書いたプログラム（コード）の一行一行が最も細かい部分。
作りたいプログラムとコードをつなぐものがアルゴリズムとフローチャートです。
こういうふうに全体を把握して一行一行にまで分解するのがプログラミング。
分解して考えることがプログラミング思考とか論理思考と呼ばれるものです。
例えば、三目並べのプログラムを考えます。
○×を書くゲーム、皆さんもやったことがあるでしょう。
この三目並べが全体です。
フローチャートを書くとき、僕はこの図のように10個ぐらいの枠で書きました。
前半はこんな感じで、
後半はこんな感じです。
それで、さらに分解して、これだけ細かいフローチャートにして、それからやっとプログラムを書きます。
僕の全体の把握と、分解です。
僕は10個ぐらいの枠で三目並べを表現するんですが、
今回本を書くときに協力してくださった方は、3つの枠で三目並べを表現されました。
僕は10個、この方は3個。
厳密には正しくないところもありますが、だいたい合ってます。
これを分解していくと、プログラムを書けます。
この全体の把握の仕方がすごいなって思います。
全体と部分という考え方はいろんなところで見られます。
料理だったら、作りたい料理が全体で、手順の一つ一つが部分です。レシピですね。
仕事だったら、担当する仕事の入り口から出口までが全体、一つ一つの業務が部分です。
これは業務フローになります。
こういうふうに、全体を把握することと、そこから部分に分解するということ。
必要があれば、一行一行にまで分解すること。こういう考え方は身に付けておくと便利です。
「紙とえんぴつで学ぶアルゴリズムとフローチャート」は、
プログラミングの本ですが、それ以外にもいろんなことを込めた本です。
プログラミングを学ぶ方にはもちろん、それ以外の方にも読んでいただきたい本です。