Lean Baseball

No Engineering, No Baseball.

スラスラ教える・教わるPython - 押し付けない・楽しむプログラミング学習のカタチ

Python プログラミング エンジニアリング 学習

先々週は札幌、そして先週（というより昨日まで）沖縄とPython祭り真っ盛りでした.

このエントリーは, PyCon Kyushu in Okinawa 2019でお話した, 「スラスラ教える・教わるPython」のふりかえりとなります.

(自分で話した内容のまとめとか補足です).

なお, イベントそのものの感想・ふりかえりはnoteに書いたのでそちらも合わせてご覧いただけると幸いです.

note.mu

TL;DR

  • 押し付け、いわゆる「マウンティング」をした時点で負け
  • プログラミングを学ぶ・使うなら楽しくやる（たとえ仕事でも）
  • ヤル気をモチベートする方法なんぞ無い
  • ペアプログラミングは良いコミュニケーションツールだ

打順

資料

話したスライドそのまま公開しました.

資料作成にあたり,

  • プログラミングを「教わった」対象者である, 弊社アナリストの森本氏
  • スライドの査読・フィードバック等でお手伝いしてくれた #rettypy メンバーの岩永さん, 竹野さん

彼らのフィードバック, 特に当事者である森本氏には事前アンケートなど快諾してもらって感謝しています.*1

ありがとうございました！

一番言いたかったこと「マウンティングするな！」

f:id:shinyorke:20190520192952j:plain
これが秘訣でした

ここが一番気を使ったことであり, 終始大切にしてた決まり・価値観でした.

森本氏と私は上司部下の関係ではないですが*2,

  • プログラミング経験（20年以上離れている）
  • 実年齢（干支を一周ちょっと離れている）

などなど、（私自身が意識しなくても）マウンティングを取れる要素はたくさんあったわけで.

これらが悪い方に作用(押し付け&マウンティング)したりすると,

  • プログラミング以前に, 講師に気を使う(教わる方が恐縮する)
  • 言われた事・教えたことしかやらなくなる
  • 結果, 楽しくないし学びも少なくなる

という悪循環が簡単に想像できた(&それに近い事は見てきたし自分もやらかしてる)ので,

押し付けるな・マウンティングするな！

を自然と気をつけていた気がします.

これが完璧に作用した, とも思っていないですが少なくとも,

  • 教わる側(森本氏)が「PyDataやりたい」「質問あります！」等, 自ら講師(私)に提案したり
  • 状況に合わせ,カリキュラムややり方を変えたことにより,いい意味で「言われたこと・教えたこと」以外の脱線が多数発生
  • 結果, 今こうして仕事でプログラミングを生かしている.

という現実が今ここにある(から発表ができた)ので,大枠間違ってなかったんじゃないかなと思います.

プログラミングに限らず, 何かを学ぶ・活かす時はやはり自己責任というのがあり, 講師がやれることってある意味限度があるのですが,

経験・キャリアが豊富で力があるモノはその実力を「場作り」で示す！

って大事だよなあーと改めて思いました.

かわぐちかいじ作品の漫画の主人公みたいな感じで(伝わるかなこれ笑)*3.

二番目に言いたかったこと「プログラミングを楽しもう、好きになろう」

f:id:shinyorke:20190520200937j:plain
やっぱ楽しくないと

「自分が書いた・作ったものが意図通りに動く」楽しさって素晴らしいよ！

色々な意見があるかと思いますが,

プログラミングを「言われてやる」「仕事だからやる」.

Pythonを「流行ってるからやる」「機械学習したいからやる」.

ではなくて,

「プログラミングって楽しいよ！一緒にやっていこうぜ！！」

感をなるべく前に出すようにしていました.

工夫したことは,

  • その場で書いて動かせるサイズの写経・ペアプロを取り入れる
  • プログラミング・エンジニアリング文化由来の「しょうもない話」を取り入れる
  • 時折, 野球の話を取り入れる(セイバーメトリクス, なんJほか)

特に最後の「野球の話」は, 森本氏がガチのアナリストであり, セイバーメトリクスの指標や考え方の話はお互いツーカーなので,

# ピタゴラス勝率を算出する
r = 658  # 得点
er = 665 # 失点
print(r**2 / (r**2 + er**2))
> 0.4947091428251498

みたいな例をその場で披露したりなど,親近感を湧かせる工夫をしました.

これはウチが「スポーツ」「野球」の事業の会社なのでやったことですが,他でも勿論応用できると思いますのでぜひ真似してみるといいかなと思います.

反響

発表後の感想などです.

当日の会場など

質疑応答で一個, その後のランチ・懇親会などで話題に上がったのが一個

【質問】教わる側がやる気ない・モチベーションが無いときの対処方法

【答】（少なくとも私の状況だったら）教えるのをやめて別の方法で解決してた

私が学校の先生・講師だったり、プログラミング教室を運営してる人間であれば話は別かもしれませんが,

教わる気がないorヤル気がなかったらやめる！というのは大分初期から決めてました.

アナリストがプログラミングできるのは確かに理想的なのですが,何かしらの理由により無理な場合は,

  • データの前処理や集計の自動化に振り切る(教育の時間をなくして)
  • 振り切って作った仕組みでできたものをアナリストにわたす

ぐらいで良かったと思っています.

幸いにも森本氏が前のめりにやってくれたおかげでこの未来はなくなりましたが,

職場でのプログラミング教育は戦略的にやるべき（全体最適化の一部である）

と思ってやっていたのでまあそういうことです.*4

【質問】具体的によく使っていたプラクティスは

【答】ペアプログラミング

アジャイル的な意味の厳格なペアプログラミングじゃなくて,

「一つの画面を共有して一緒に眺めながらやる」

ゆるいペアプログラミングを軸にしていました.

これは以前コンサルやってた頃に,一緒にやってたお客さんがペアプロ好きでしょっちゅうやってた

→やる内に自分も好きになった

→公私ともども,困ったらペアプロ的なアプローチを雑にやる

習慣がついてたので,そのままやりました.

この辺の細かい話はまた別の機会に言語化します(っていうのがこのエントリーのオチです).

Twitter上

発表中・発表直後

「押し付けない」「楽しむ」の価値観がやっぱ刺さってたのかな？と思いました.

「意図的に黒船を」も「楽しむ」きっかけの一つでやったことなのでここも引っかかって嬉しかったです.

これは森本氏と私の二人三脚がちゃんとできていた事かなと.（身内でありながら）毎回予習やってたのはホント凄いことだと思います.

スライド公開後

いくつかこのようなツイートがあって大変感謝しております！

参考になれば幸いです！

補足情報：本編で話さなかったこと

ちょっとした補講として本編で話さなかったことを.

#スラpy とJupyter本が教材になった理由

もちろん, 書籍の出来の良さもありますが,

著者がもくもく会・リアルで会える場所にいたから

というのが最大の理由かもしれません笑

こちらのスライド,

f:id:shinyorke:20190520204013j:plain

「意図的な黒船」の方々の一部は書籍の著者の方々で,ご協力してもらってホント感謝してます.

以前このブログでも紹介してますがこの2冊はホント素敵なので迷った方はぜひ読んでみてください.

スラスラわかるPython

スラスラわかるPython

PythonユーザのためのJupyter[実践]入門

PythonユーザのためのJupyter[実践]入門

結局この方法は真似できるのか？

あくまでも私と森本氏の場合うまくいった！なのですべてを真似して再現するのは無理かなと

何度でも言いますが, 大切なのは

  • 押し付け、いわゆる「マウンティング」をした時点で負け
  • プログラミングを学ぶ・使うなら楽しくやる（たとえ仕事でも）

この二つなので,これらをいい感じにやったらうまくいくと思います.

状況は人それぞれ,組織によって異なるのであとはよしなに.

【次回】決め球は「ペアプログラミング」 - って話がしたい

最後になりましたが, この発表を通して

「マウンティング」しない, 楽しい「ペアプログラミング」というノウハウを共有すべきでは！？

と思いたったので, PyCon JP 2019のトークとして応募しました.

トーク通るといいな...と祈ることにより,このふりかえりは終わりたいと思います.

最後になりましたがたくさんのご意見・フィードバックありがとうございました！

*1:ちなみに,この発表は仕事でもなんでもないです.

*2:一部ツイートやリアルの感想で「いい上司に恵まれたんですよ！」的なコメント頂きましたが, チームのメンバー（森本氏に限らず）は対等であり、お互いの職域・領域のエキスパートなので上司・部下という思想を持ったこと自体ありません

*3:「空母いぶき」の秋津艦長, ちょっと古い作品だと「沈黙の艦隊」の海江田四郎とか.「力あるやつは技量で結果を出して示せ！」的なの好きですしそれを目指していきたい.

*4:言い方を変えると,ヤル気無いやつをヤル気出させるのは「個別最適化」であり,そこにかかるコストと見合うかどうかを考えてやるべきです.