非エンジニアの友人にPythonを教えた。彼はPythonistaとなった。

※Pythonistaとか言っていますが、Pythonicなコード書きまくっているとかエンジニアに転職したとかではないです。

でも言いたかったから書いた！

サマリ

• 友人は非エンジニアですがプログラミングに興味があり、初心者向けの本で勉強していたのですが、読み終えても自分が作りたいものをどう作ればいいのかわからず悩んでました。
• そんな中京都大学からPythonを使ったプログラミング演習の教材が無料公開されました。
• そこで、教材を週に1回オンラインで画面共有しながらいっしょに読み、いっしょにコードを書いていきました。
• 約2か月後、彼は今自分でファイル整理用のスクリプトやCLIの海戦ゲームを作り、今はCLIでWizardryをつくろうとプログラミングを楽しんでいます。
• この記事では以下を紹介します。
  • どう進めていったか
  • 彼をつまづかせていたもの：教えるほうが学ぶスコープを広げてしまっていた
  • 教えたことで自分が得られたもの

この文章の対象者

• ITエンジニア
• プログラミングをちょっと知っている人

対象をあえて書いているのはプログラミングを知らない人だとわからない言葉が多く読みにくいと考えたためです。

経緯

友人もわたしももやもやとしているものがありました。

友人のもやもや

• プログラミングに興味がある。仕事でめんどうな作業は自動化できるようならやってみたい。
• 本を読んでコードを写経して本に書いてあるとおりのことならできるようになったが、自分が欲しい物を作ろうとするとどうすればいいのかわからない。

私のもやもや

• 友人の話を聞いて本を勧めたが、実際彼がどういうところで悩んでいるのかわからない。
• 人に1からプログラミングを教えるってやってみたいが、ハードル高いな。
  • 題材や教材はどうしよう。
  • たまに参加するハンズオンでレクチャーしてくれる人ほどしっかりやれる自信もない。

そんなときに2020年2月13日に京都大学からPythonを使ったプログラミング演習の教材が無料公開されました。

この教材の最初の方を読み、以下の文で、これ教材としてすごくいいのでは？これなら友人はできるようになるのでは？と思いました。

この授業は Python というプログラミング言語を紹介するのではなく、Python というプログラミング言語で実際にプログラムを書く（書けるようになる）ことを目的にしています。多くの解説書がプログラミング言語の紹介に終始しがちです。

0.2 屋上屋を重ねる理由, https://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433/245698/1/Version2020_02_13_01.pdf, （検索年月日：2020年6月6日

そこで友人に話をもちかけました。

私「非エンジニアの人にPythonを教えられるようになりたいんやけど、生徒役としてつきあってもらえない？」

友人「ええよ。」

私「でも経験ないからつたないところがあると思うけどいい？」

友人「ええよ。」

私「（いい友人を持ったなー）」

（なんかこの記事ポエムか日記みたいになってきたな。）

実施した環境

それぞれの環境

• 私
  • OS: macOS Catalina
  • エディタ: AnacondaのIDLE、途中からVisual Studio Code（以下VSCode）
  • Python: 3.7.3
• 友人
  • OS: Windows 10
  • エディタ: AnacondaのIDLE
  • Python: Anacondaバンドルのもの

会話と画面共有にはDiscordを使いました。

ご存知でない方はSlackやgoogle hangoutなどをイメージしていただければ大丈夫です。
だいたい同じです。

エディタについては、やりはじめた当初は揃えてAnacondaのIDLEを使っていました。
が、2回目か3回目になってから私が使い慣れているVSCodeを使い出しました。

環境についふりかえって思ったこと

エディタの違いはそこまで問題にはならない

途中でわたしがVSCodeを使いだしても友人はそこで何か混乱するということはなかったので、以降私はそのままVSCodeを使いました。

混乱が起きなかった理由としては、画面構成はさほど変わらなかったのが1つかなと感じました。

• AnacondaのIDLEを使っていて、主に見るのはコードのエディタと実行結果を表示するコマンドプロンプト。
• VSCodeも見る分には、コードのエディタと実行結果を表示するターミナル。
  • VSCodeでわたしがライブコーディングするときにハイライトされたエディタや補完を使っていてもそこでナニソレ？とはなりませんでした。

ただ、これは人によってはエディタが違うことを気にする人はいるかもしれませんね。

また、教材で薦められているAnacondaの使い方でわからないことがあったらすぐフォローできるように、自分も使える状態にしておいたのもよかったのかもしれません。

多機能なエディタを最初から使うことを勧めなかったのは正解だったのでは？

わたしはVSCodeが好きなのでVSCodeを布教したい心はありましたが、それはしませんでした。

AnacondaのIDLEはシンプルで、テキストエディタ＋そのままPythonファイルを実行できるようになっています。また、教材にIDLEの使い方のフォローがしっかりとされていたので、ちょっと困ってもそれをいっしょに見れば解決できました。。

今にして思うとこれは正解だったと思います。
多機能で便利だからとVSCodeを使ってもらおうとすれば、学ぶ範囲がプログラミングに加え、エディタも入ります。

自分も大学でプログラミング演習を受けたとき、プログラミングもはじめてな上にエディタがemacsで覚えることが多くて困惑した覚えがあります。
（emacsが悪いのではなく、学ぶスコープが広くなっているのが問題）

OSは揃えたほうがいい

文字コードの問題がでて、送ったコードが読めなかったり、Anacondaの操作で一方ではうまくいくけど、もう一方ではうまくいかないというのでつまりました。

こういうことで時間をつぶすのはもったいないので、自分がWindowsPCにしておけばよかったと思いました。

やったこと

スケジュール

基本的には以下のようにすすめました。

• 週1回実施。1回2〜3時間。
  • 基本的には毎週だが、各自の予定によっては中止していた。
• 時間枠内で進められる分だけすすめる。
  • 予習・復習の強制はない

結局6回ぐらいで最後の三目並べの演習のところまでいきました。※後述しますが一部飛ばしてすすめました。

進め方

教材をはじめから順番に読み進めていきました。

ただ、全ての項目はせず、以下の章だけしました。

• 1. まえがき
• 1. コンピュータとプログラミング
• ２. Pythonの実行環境と使い方
• 1. 変数と演算、代入
• 1. 制御構造（for文やif文などの基本文法）
• 1. 関数を使った処理のカプセル化
• 1. クラス（※これは紹介にとどめて詳細は割愛しました）
• 1. リスト
• 1. ファイル入出力
• 1. 三目並べで学ぶプログラム開発

省いた部分はクラスやGUIアプリケーションの作り方、オブジェクト指向についてです。
以下の理由で省きました。

• 彼に作りたいものを聞くとGUIは必須ではなかった。
  • 作りたいもの
    • 株のトレードをするときに毎回やっている自分が考えた式で計算をするプログラム
    • ファイル整理をするプログラム
• クラスを使わないと実装で困りそうな規模のプログラムはしばらく作らなさそうだった。

読み進め方

教材では、基本文法からテーマごとに読むパートと演習パートがあってそれぞれ進め方を変えました。

読む箇所は、私が教材のpdfファイルを画面共有しながら読み合わせていきました。
節（例：２．１と５．４とか）ごとに読み終えたら、気になったことがないか聞きました。
友人から質問があって、なにか例を出すときはPythonの対話モードで例を出しながら進めました。

ここで意識していたのは「わからないことはある？」ではなく、「気になったところはある？」と聞いていたことです。
はじめてだと、わからないことと気になったことの区別がつきづらいかなと思いそのように聞いていました。

演習パートの進め方

わたしも彼もそれぞれで演習をやり、やってみた感想を友人から聞きました。

明確には決めてなかったですが、順調にいけていたらそろそろ終えそうかな？と時間が経過したところで状況を確認していました。

• うまくいっているのか？
• 悩んでいるのはどんなことなのか？
  • 覚えたてでまだスムーズに進められないだけ？
  • よくわからないエラーがで詰まっている？

進め方でよかったこと

一定の時間で調子を聞く

演習パートで適度に途中でどんな感じか聞いたのはよかったことだったと思います。

オンラインで自分の画面を共有していると、相手の状態は把握できません。（Discordの仕様で一方向にしか共有できない）
すると、お互い無言でカタカタとキーボードを打っているだけになり、どのような状態なのかわからなりやすくなります。そこで、こまめに状況を聞いたのは良かったと思いました。

また、１人でやりきるのも大事ですが、１人で悩み続けるのも効率は悪いので、それを防ぐことができたのはよかったなと思いました。

ちなみに区切る時間の目安は１５分〜３０分にしていて、これは良かったと思います。
※この時間はポモドーロテクニックやgoogleの15分ルールを参考にしていました。

節ごとに気になったところを聞いていく

この内容ならば簡単だから大丈夫かなっと思っていても、慣れていない人からすると何だこれ？ってなっていることがあります。
例えば最初にループの紹介で以下のようなサンプルコードを出してます。

>>> for i in range(9):
...     print(i)
... 
>>> 

ここで、range関数について説明はしているのですが、
友人は最初、forとrangeはセットで使うものだと思っていたようです。

ところが少し進んで以下のようなfor文がでてきます。

>>> for i in ["三条", "四条", "五条"]:
...     for j in ["河原町", "烏丸", "堀川"]:
...         cross = i+j
...         print(cross)
... 

for とrangeはセットで使うと思っている人からすると困惑する内容です。

読んで実行すればなんとなく、リストの"三条"、"四条"、"五条"と参照されていっているのはわかります。
ただ、唐突にこれがでてくると困ったようです。

for文はinのあとにかいてある変数の要素数分繰り返して実行するものであり、rangeは要素作成のやり方のひとつと補足したらすっきりしたと言ってくれました。

今気にすべきところでないところを言ってあげる

サンプルコードの中に次の節ででてくるif文を使っている例がありました。

講義であれば、「これはあとで説明しますね。」で済みますが、１人で読んでいるとそうはいきません。

混乱します。

そういうときに、これは後で説明するよ、とか。今は気にしなくていいよとサポートできたのは、彼の悩みを減らす助けになったかなと思います。

質問はウェルカムだと示す

先に書いた「気になったところはある？」と聞くようにしたことに関連します。

多少できるようになっても、次にわからないところがでてきたときに適切な質問ができないとそこから先にすすむのは難しいです。

気になったところを聞いて、その質問はいいよ！とか、なんでも聞いていいんだよ！という雰囲気作りは気にしていました。

今回の経験を通じてわかったこと

• 彼を躓かせていたものは、なんとなくはわかるけど気になるところがあるまま進めるしかなかったことかなと思いました。
• 上述のforの例だったり、節ごとに聞いてよかったと言ってもらえたあたりからの想像ですが。
• 微妙にわからないものが積み重なると、実はけっこうわかっていないことが多くていざ独力でやろうとしたから大変だったのでは？と感じました。
• 自分も学ぶときは、ちょっと気になった部分はそのままにはせず、ふりかえられるようにする。もしくはすぐ調べたり聞いて解消するようにしようと思いました。
• 実際、彼は最後の１人で三目並べをつくるという演習は、いっしょにではなく１人でやりきりました。
• さらに彼が作りたかった海戦ゲームを三目並べのソースコードを参考にしつつ作りきってしまいました。
  • シンプルなゲームでしたがやってて楽しかった :)

まとめ

今回人に教えたことによって、学ぶときに大事なのはいかに学ぶ範囲を絞り、その範囲のことに集中できるようにするかということを改めて実感しました。

覚えたての言語で新しいサービスを作るといった一足飛びなことは、やらないほうがいいと聞いたことがありますが、こういうことが関係するのでしょうね。

最後に、わたしの思いつきに協力してくれて、そして今プログラミングを楽しんで毎週改良した海戦ゲームのコードを送ってくれる友人K。ありがとう。
そして、このような機会を作るきっかけを作ってくださった教材の著者である喜多一先生、ありがとうございました。

後日談（2020年6月16日追記）

自分としてはすごい数のLGTMいただいててびっくりしました。本日会社に行ったときにリーダーから記事がランキングに載っていたよって言われて、通知とか全然見ていなかったんで帰宅後確認して、なんか夜になった今もテンパっています。
そんなわたしの記事ですが読んだ方々のなにかに役立っていれば幸いです。

さて、余談はこのぐらいにして、この記事を書いたあとすぐに、友人にこの文を読んでもらい、フィードバックをもらいました。せっかくなので追記しました。

「気になるところがある？」って聞き方はよかった

友人曰く、わからないところはある？って聞かれると、たぶん「ない」って答えてしまうとのこと。
なぜならばこれは教科書であり、「載っていることは正解でありこういうものなんでしょ？」って完結してしまうから。
もちろんこれは彼自身も人によって捉え方は違うだろうと言っていました。けど、気になるところがあるって聞かれると、話しやすかったのは確かだそうです。

コメントで常にこういう聞き方にしているといただきました。わたしも今後は相手によらず、こういう聞き方をすることを意識していこうと思います。

小さなわからないが積み重なって大きなわからないになる

気になったところを細かく解消して、先に進めたのはよかったと言ってもらえました。
どうよかったかというと、きっちりと理解できた部分が増えたことで、最後の三目並べのサンプルコードをみたり、海戦ゲームを作ったときは、〜まではわかる、わからない部分はココ！とある程度確信をもてた。
そうなると、あとはわからないところについて集中してやれてなんとかできたらしいです。

これはプログラミングに限らず、他のことを学ぶときにも共通することだなと思いました。
自分もわからないところが不明瞭なときは、だいたいほとんどわかっていない…。

エディタはシンプルなAnacondaバンドルのものでよかった

最初から補完やスニペットなどの便利機能を使ってしまうと曖昧な理解になってしまってたと思う。文法の理解が誤っているという問題にぶちあたる機会が増えたからそれは別によかった。間違ってコードを書いて実行したらエラー箇所教えてくれるし、そこまで困らなかった。と友人が言っていました。

これについてはわたしも確かにそうだと思う機会が直近でありました。
golangを学び始めたのですが、最初から補完機能使いまくりながらコードを書いていました。すると、2ヶ月位か間が空いて久々に書こうとしたら、エラー連発しました。しかも基本的なところのミスばかり。
目的が学ぶことであれば、エディタにはそれに沿った拡張機能のみをいれるべきだなと感じました。（例えばハイライト機能だけとか）

さいごに

繰り返しになりますが、良い経験をさせてもらいました。1人では得られなかった経験です。
この記事にコメントくださった方々も読んでくださった方々もありがとうございました。

友人とはこれから教える教わるの関係ではなく、2人とも興味がでたライブラリを勉強する仲間になりました。来週からは時間は２，3時間もとりませんが、ほそぼそコツコツ楽しくやっていこうと思います！