ソフトウェアエンジニアがプログラミング教材をつくってみるという試行
今年の6月にTechpitというプログラミング教材マーケットプレイスのスタッフからのオファーがあって、教材を作ることになった。
なった、というか今年のチャレンジの一つとして教材を作るという選択をしたという方がニュアンスとしては正しい。教材を書いたからと言って報酬が出るわけではないし。教材が売れれば相応の収入にはなるけど、売れる保証はどこにもないので、どうなるかは蓋を開けてみないとわからない。
現時点で全体の40%くらいの執筆を終えたので、これまどのことを振り返る。
なぜ始めた?
一つは依頼があった、というところ。3月にはんなりPython+PyData Osakaの可視化特集会 - connpassで発表した資料のDockerを使った可視化環境の作り方 - Speaker Deckを見つけてくれて、それで教材作ってみませんか、とのオファーをもらった。 その後TechPitのスタッフと話したり、主催しているはんなりPythonの参加者さんと話をする中で、入門書が終わったあとにやる良い教科書がないであったり、具体的なものを作りながら学べるものがほしいといった意見があったので、ニーズがあるのはわかった。 ということでそういったニーズにあった教材を作ってみよう、ということで制作を始めた。コミュニティをやっていると、生の声というかそういうのを得られる機会にもなるのでよい。
どんな教材を作っているの?
教材のタイトルは「ニュース系サイトのスクレイピングコマンドを作ろう【Ruby】」で、タイトル通りの内容。TechPitには現在60くらいの教材があって、Webアプリケーションを作ってみよう、という感じのタイトルが多い。かぶらないものがいいなぁと思い、いろいろ考えた結果この教材を作ろうと決めた。
事前にTechPit側がアンケート調査みたいなことをやってくれるのだけど、それで悪くない結果だったのもあってこれを書くことにした。 ただ、アンケート調査の方法とか回答者がわからんので、どこまで信用できるかわからない。
ターゲットとか
入門書とか学習コースみたいなので一通りRubyを学んだ人が、さて次にどうしようかな、となった時に学べるものを目指して書いている。 入門書に書いてあるサンプルコードは実際のプロダクトのコードとは程遠かったりする。
a = [1,2,3,4,5] a.each() { |v| print v }
みたいな。 メソッドの動きを理解することは大事だけど、それをどのような場面で使うと課題解決につながるかは、このコードから想像することは難しい。 そういった部分を埋められるような教材ができたらいいなぁと思っているし、ニーズもあるんではなかろうか。
書籍との差別化
プログラミングの書籍で感じるのはサンプルコードがすでに完成コードになってるっていうこと。これって初心者からしたらわかるようでわからんのじゃないかなぁ、と思う。うまく言語化できないけど。 自分も10数年プログラミングをしているけど、ダイレクトに完成コードを書くことなんてない。書いて直す、を繰り返す ことで完成コードができていくので、それを表現したいと思っている。
書籍ではできない表現をオンライン教材だとできると思うし、その一環として動画を作ってみた。
動画作ってみた
恥ずかしながら動画をつくった。この動画はリファクタリグを題材にしたパートの動画で、ペライチのコードをメソッドにまとめていく、という作業を解説している。実際につくってみてわかるのは
- 声が低い
- 滑舌がいまいち
- 動画のテンポが悪い
- 当然見てる人いない
って言う感じ。
普段見ている動画コンテンツのクオリティってものすごく高いし、それにかかっている労力もすごいことは容易に想像がつく。
それなりのクオリティーのものが出来てから公開したいところなんだけど、コンテンツは作りきって公開してなんぼだし、公開したからこそ改善点が多々あることがわかる。
やりきるって大事。
どんな内容でもいいのでフィードバックください。
今んとこかかってる時間とか
6章立ての構想で現在2章まで執筆が終わっている。事前の打ち合わせとか構想とか執筆を始める前に要した時間が20時間で、執筆を始めてからが40時間ほど費やしている。慣れてきたので残り4章を40時間くらいで終えたい感じ。
1部あたり1000円の収益だとしたら500部売れればまぁトントンかなぁって感じだけど、そんなに売れるのかは疑問。たぶん自分でも売るための行動というか営業というかそんなのは必要なんだろうなぁ。
つらい部分
日々のメモとか記録に
プログラムだとすらすらかけるのに
何かを説明する文章だと
なかなか手が動かない。そうして書いた文章も短くて、少なくて、
なんとかひねり出した文章が
こんなもんなのか、と打ちのめされる。
なんてことが残されていた。ふだん何気なく書いているコードの裏側のことを言語化することは意外と難しい。 何を考えながらコーディングしているのかだったり、言語仕様としての知識だったり、OSの動きを理解してないと文章で説明できないってのがわかる。そして言語化するための裏付けをしないといけないので自分の理解も深まる。
なので、同じようにソフトウェアエンジニアをやっている人には、教材の制作をおすすめします!
完成できるのか
このまま時間を確保して完成までもっていきたい。 執筆中のテキスト読みたいよ、っていう人いたら連絡ください。なんかしらの方法はあると思う。