2017年11月25・26日に行われたななめな学校¹に講師として参加し、「プログラミング」をテーマにした授業をしました。その際考えたことや、実際の授業内容について紹介します。

プログラマーである自分にとって「プログラミング」をテーマに設定することは自然なことでしたが、2020年度のプログラミング教育必修化は時事的な話題でもあります。予備知識として、文科省のサイトから学習指導要領(平成29年3月公示)やその解説資料をダウンロードして読んでみました。

学習指導要領におけるプログラミング教育

まず勘違いしていたのが、「必須化」といっても「プログラミング」という教科が追加されるというわけではなく、既存教科の中に組み込んでいくということなんですね。総則では受け皿となる教科として「算数科」「理科」「総合的な学習の時間」を挙げ、“学習内容と関連付けながら計画的かつ無理なく確実に実施されるものであることに留意する必要がある”とされています。まぁ、それはそうか…と思いました。

(3) 第2の2の(1)に示す情報活用能力の育成を図るため,各学校において， コンピュータや情報通信ネットワークなどの情報手段を活用するために必要な環境を整え，これらを適切に活用した学習活動の充実を図ること。また，各種の統計資料や新聞，視聴覚教材や教育機器などの教材・教具の適切な活用を図ること。
あわせて，各教科等の特質に応じて，次の学習活動を計画的に実施すること。
ア 児童がコンピュータで文字を入力するなどの学習の基盤として必要となる情報手段の基本的な操作を習得するための学習活動
イ 児童がプログラミングを体験しながら，コンピュータに意図した処理を行わせるために必要な論理的思考力を身に付けるための学習活動

〜総則　第1章総則の第3の1の(3)〜

ここだけを読むと、いわゆる「プログラミング技術の習得」に言及されているように思えたのですが、さらに続けて読み進めてみるとどうやら違うようでした。

小学校段階において学習活動としてプログラミングに取り組むねらいは，プログラミング言語を覚えたり，プログラミングの技能を習得したりといったことではなく，論理的思考力を育むとともに，プログラムの働きやよさ，情報社会がコンピュータをはじめとする情報技術によって支えられていることなどに気付き，身近な問題の解決に主体的に取り組む態度やコンピュータ等を上手に活用してよりよい社会を築いていこうとする態度などを育むこと，さらに，教科等で学ぶ知識及び技能等をより確実に身に付けさせることにある。

〜小学校学習指導要領解説　総則編　P85〜

つまり実践的なプログラミング能力を身につけるための指導ではないということらしいのです。しかし、まだ学習経験の少ない小学生にとって、実際に何らかの“プログラミング言語を覚えたり, プログラミングの技能を習得したり”することなしに、“コンピュータに意図した処理を行わせるために必要な論理的思考力”を身につけるのは難しいのではないか思いました。確かに既存のプログラミング言語を扱うと、細かい前提知識が必要となり、本質にフォーカスしにくいということも想像できます。かといって、体験を伴わない形で概念的な話を聞かせるだけでは、ほとんど意味が無いと思うのです。

必要なのは魅力的なプログラミングへの入口

前述の指導要領を読むなどして簡単に調べたところでは、一般的な学校の授業の中でプログラミング技術が習得できるような状況には、当分の間はならなそうだと感じました。おそらく年に数回、そういえばそれっぽい授業があったなぁというくらいの感じになるのではないでしょうか。そういった状況で大切なのは、子どもたちにプログラミングの世界を魅力的に伝え、興味を持ってもらうことだと思います。企業などが主催する小学生向けプログラミング教室や、市販のプログラミング教材など、入門に適したコンテンツはすでに多くあります。本人が興味さえ持てば、そういったもので学校以外の場面で学ぶことが出来ます。小学校のプログラミング教育においては、限られた時間の中で、プログラミングの「楽しさ」を伝えることが重要な事なのではないだろうかと考えました。

授業内容の構想

子供向けのプログラミング学習と聞いてまっさきに思い浮かぶのがScratch²というプログラミング環境です。ただ、これを使ってしまうと経験者と初心者のレベル差がでてきてしまいます。今回、事前にプログラミング経験を知ることができなかったので、もっと別の教え方をした方が良いと考えました。
そこで考えたのが、人やカードなどのアナログなものを使ってプログラミング体験をしてもらおうというアイデアです。かつてのコンピュータは、パンチカードでプログラミングしていたのですから、別にデジタルデバイスがなくてもプログラミングはできます。授業の中でも「ペッパーのプログラムは、紙と鉛筆さえあれば今ここでも書けます（ただし実行はできないけどね）」という話をしました。また、オリジナルのルールを設定すれば、経験値に関わらず同じ条件で学習できるはずだと思ったからです。

時間制限への対策

今回の制約として大きかったのは時間です。与えられた授業時間は2時間30分でした（途中1回休憩をはさみます）。小学校の通常の授業と比べるとながいようですが、たった1回の授業です。対象が大人でも、この時間の中で満足なプログラミング体験をしてもらうのは難しい時間なのではないでしょうか。そこで、グループワークにしようと考えました。通常プログラミングは1人で取り組むものですが、あえてグループワークを導入し同じ課題に協力して取り組むことで、個々の待ち時間を節約したり満足感の平均値も上げたりできると考えたからです。

また、授業の始めと終わりに、子ども達に伝えたいことを簡潔にまとめたレジュメを提示しました。なかでも下の2つは実際にプログラミング体験をする前に意識しておいたほうが良いと思ったことです。それぞれについて説明します。

1. プログラムに「正解」はない　あるのは「目的」のみ

プログラミングは表現であり、目的を達成するための行為です。目的の達成には多くの道筋があり、目的を達成しさえすればOKだということを、まず冒頭で伝えておきたいと思いました。色んな答えがあるはずだとあらかじめ意識していれば、プログラミングの世界をより楽しむことができるはずです³。

2. ロボットはかしこくない

一般的にロボット⁴は賢いものとして扱われることが多いです。でもそういう意識のまま、初めてプログラミングを体験すると、「なんでこんなことができないんだ」「面倒だ」とストレスに感じてしまいます。前提としてロボットはかしこくないと意識しておけば「じゃあしょうがない、自分がしっかりプログラムしてやろう」という姿勢で望む事ができます。この方がプログラミングはきっと楽しく思えるはずです。

授業内容の紹介

考えたのは、5人1組でマス目状のステージに配置されたアイテムをゲットしていくゲームです。アイテムをゲットするために、ロボット役の先生⁵をプログラムします。「すすむ」「右向け右」など、カードの種類がいくつもあるので、1つずつ使い方の説明と練習問題というのを1セットとして繰り返す流れで進めていきました。

まず、こちらで用意したステージをプロジェクションし、各チーム自分達のステージ上に同じようにアイテムなどを配置して再現します。矢印の書いてあるダンボールがスタート位置、それ以外のダンボールはブロック（進入禁止のマス）です。アイテムは、紙コップの中に入っていてお菓子とジュースの2種類があり⁶、なかには中身がどちらかわからないように「？」と書かれた蓋がしてあるものもあります⁷。

ステージの準備ができたら、カードを並べてプログラムを書いていきます。左枠はプログラム本体用、右枠はカスタムカード⁸を定義する用の枠です。

プログラムができたら、カードを順番に読み上げながら、ロボット役の先生を動かして確認します。ここで先生には「かしこくないロボット」役に徹してもらいました。先生が気を利かせて「賢く」振る舞ってしまうとゲームが成立しません。あくまでプログラムに忠実に動いてもらうように、授業前に細かくルールを確認しておきました。

お菓子効果

休憩前のステージと最後のファイナルステージの2つについては、獲得したアイテムの数だけチームの人数分、本物のお菓子をプレゼントしました。安直な手段でしたが、そのルールを伝えた時に子ども達のテンションが高まったのを感じ、やはり効果は絶大だなと思いました。

ファイナルステージ

ファイナルステージでは各チームに問題作りをしてもらいました。問題はステージとそのステージをクリアするプログラムのセットです。隣のチームの問題を解いてゲットできたアイテムは自分たちのものです。逆に、自分たちの作ったステージで隣のチームに取られなかったアイテムは自分達のものになります。このように攻守入れ替わるステージです。最初に、問題作りをしてもらい、出来上がったところからひとつずつ回答が正しいことを確認していきました。確認ができたチームのステージは証拠として写真を取り、プログラムの方は消してもらい、別のチームに問いてもらう準備をします。

下はその時に撮った写真一覧です。皆かなり複雑なステージです。左下のステージだけ矢印が手書きなのは、隣のチームにスタート位置がバレないように裏返しておきたいという意図らしいです。記録のため、後で僕が画像に手書きで矢印を入れました。そこまで本気でやってくれるとは、予想していなかったです…（汗）。

全チームの問題作りが完了したら、時計回りに場所を移動して、今度は隣のチームの問題を解く番です。後で1チームずつプログラムの確認をしていくのに時間を残しておきたかったので、ここでの時間制限は厳密にしました。そして最後に、全員の前で各チームの作ったステージや、それに挑戦したチームのプログラムの確認をしていきます。

予想外のドラマ

あるチームは途中で1枚だけカードの数を間違えていました。相手の思わぬミスで自分たちのお菓子を守れた出題側チームは湧き上がりました。逆に、解答側チームの空気は一瞬で凍りついたのを感じましたが、「大丈夫まだ続けられるよ！」といって、そのままプログラムの実行を続けると、偶然的にいくつかのアイテムを追加でゲットすることが出来ました。内心『よかった…』と思ったのですが、その後自分たちのステージのアイテムは全て取られてしまい、また落ち込むことに…。こんなドラマが生まれるとは、授業前は予期していませんでした。

グループワーク（チーム制）の副産物

グループワークにしたのは時間的な制約を考慮したからでしたが、他に色んな効用があったようです。特にファイナルステージの解答時間は結構タイトだったこともあり、全体を俯瞰して指示を出すもの、カスタムカードを作るもの、枠からはみ出ないようにカードをきれいに並べるものなど、チームワークの良し悪しが勝敗にも大きく関わってきました。どんどん積極的にプログラミングする子、冷静に問題箇所を発見する子、新しいアイデアを思いつく子、即席のチームでしたがそれぞれが役割を見つけて活躍していました。隣のチームのやり方を偵察に行って報告したり、カスタムカードを使って他のチームとは違う新しい命令を作って盛り上がったりなど、グループワークならではの楽しさも沢山ありました。

幻のチャレンジステージ2

個人的には当日の時間調整でやむなく削ったチャレンジステージ2（下のスライド参照）でプログラミングの「凄さ」を体験してもらいたかったのが心残りです。きっと自力で解ける子もいたので、せめて家に持ち帰って考えてもらえるような用意をしておけばよかったと反省しました…。

おわりに

限られた時間の中で、プログラミングの「楽しさ」を最大限に伝えるという点を、重要な課題に設定しました。結果としてまとめた「先生をプログラミングしておかしをゲットしよう」の内容は、ステージのバリエーションを増やせば、もっと深く学びをすすめることもできます。特殊な教材も不要です。グループワークにしたことで、子どもたちも非常に楽しんでくれたようだったので、効果はあったのではないでしょうか。（もし同じ内容をやってみたいという方は、ご連絡いただければ提供できる資料はお渡しします！）

近年の機械学習分野の盛り上がりをみると、今回扱ったようなプリミティブなプログラミングは将来的には現代における手書き文字のような、限定された場面でしか使われない技術になる可能性もあります。10年後、20年後にななめな学校があったとして、今回の授業を受けてくれた子どもたち世代が次世代に向けて一体どんなことを伝えたいと思うのだろう…？そんな妄想をするとなんだかワクワクします。

最後になりましたが、今回の授業内容の検討や実施、またこの記事の執筆にあたってもお手伝いくださったアシスタントの皆様には大変お世話になりました。ありがとうございました。

---

エンジニアを募集しています！

---

KARAPPOでは、エンジニアリング的視点から生まれる新しいアイデアや問題解決の提案、ユニークで面白いチャレンジをしていくために、エンジニアを募集しています。ななめな学校のような、地域に貢献する活動には今後も継続して参加・協力していきます。自分も参加したい／興味があるという方は、ぜひこちらの募集要項をご覧になってご応募ください（この記事読んだよと書いてくださるとさらに喜びます）。よろしくお願いします！

1. 千葉市メディア芸術振興事業実行委員会主催の小学校3年〜6年の子供たちを対象にしたイベント。「なななめな視点」を持つことを学び、表現の幅を広げてもらおうという趣旨で、様々なクリエーターを講師を迎えて催されます。今回は2日間で計6名の講師が招かれ、各講師1日2回の授業を行いました
2. 単純なアニメーションからインタラクティブなゲームまで、色んなものを作ることができるプログラミング教育のためのソフトウェア
3. 実際の授業でも、ある課題について必要以上に複雑なプログラムを書いた子がいて、その後他の子がもっとシンプルな回答をする場面がありました。その時、どちらも目的を達成していたので「正解」だと教えました
4. 「機械」と読み替えてもらって結構です。授業の中では同じ意味で用いました
5. アシスタントの方5名に協力いただき、各チームに1人ずつついてもらいました
6. それぞれ色の違う棒を入れています
7. 蓋のされたものは「条件分岐」を使ってゲットします
8. 関数に当たるカードです。処理のまとまりに名前を付けて、使いまわしたり、プログラムを読みやすくしたりできます

今回はKARAPPOで普段行っている公開作業（デプロイ）の仕組みについて解説し、改めてどういう考えで今の形に落ち着いたのか整理してみようと思います。
この記事のメインターゲットは、受注案件メインの制作会社などで、公開作業を毎回手作業で行っているエンジニアの方々です。一括りに「ウェブエンジニア」といっても、ウェブアプリ開発系の現場ではデプロイ・ツールも充実していて、色々モダンな手法があると思います。しかし、その他のウェブ制作の現場では、実は意外と未だにFTPクライアントを使ったアップロードなどしているところもあるんじゃないか？と思い¹、そういう人たち向けに書いてみます。比較的少ない投資ですぐ運用できるので²、もし気に入ったら詳しい使い方などはGitHubのドキュメントを読んでみて下さい。

drone-deploy の紹介

紹介するのは drone-deploy というシェルスクリプトで書かれたプログラムで、OSSのCIサービス DroneとGitHubなどのバージョン管理サービスと合わせて使います。gitのログを確認すると2014年8月から現在（2017年10月）まで、既に丸3年以上実戦で運用し、メンテナンスしてきた秘伝³のスクリプトです。

karappo/drone-deploy

全体をざっくり解説すると、下の図のようになります。

1. ローカルでの開発
2. GitHubにpush

ここまでが、ユーザーがやることで、あとはdrone-deployがやってくれます。

3. Droneへのclone
4. drone-deployからスクリプトを取得
5. スクリプトの実行
   1. 前処理（環境毎の置換処理など ※）
   2. ファイルの転送
   3. 後処理（キャッシュの削除など ※）
6. Slack等への通知（任意）

※ プロジェクト毎に自由にカスタマイズ可

以上、シンプルです。では、導入前の課題とそれが導入後どう解決されたかについて書いていきます。

開発から公開までのワークフローの一元化

せっかくgitでソースコード管理をしていても、デプロイを手作業で行っている限り、リポジトリのコードが最新である補償は残念ながらありません⁴。
そこで、Herokuのようにgit pushしたらあとは自動でやってくれるような仕組みにしたいと思いました。また、社内の全員が同じワークフローで仕事を行うことで、特定の個人に依存しない皆が使える環境を構築出来ました。例えばツールのアップデートも、皆が共通で使っているdockerイメージを更新すれば良いので簡単です。
また、ファイル数が多い場合など、単純に転送にかかる時間も長くなり、無駄なコストになります。rsync⁵を使えれば良いのですが、フロントエンドエンジニアにはちょっとハードルが高いです。ですが、こんな便利なものは誰でも気軽に利用できるようにするべきだと思っていました。ワークフローを統一したことで、それが実現できたのも大きなメリットでした。
また、branchで展開先を切り替えたり、pushしたら通知が来るまでは他の作業をしたりできるのは、実際かなりの負担軽減になっていると思います。

デプロイ作業のコード化

例えば、長く付き合いをさせていただいているお客さんから、久しぶりに改修やリニューアルなどというお話を頂くことがあります。久しぶりに作業すると、例えば既に作業マシンを新調していてサーバーの接続情報を調べるところから始めなければならないこともあります。また、それがもし緊急の要件で、さらに担当者以外の人間が対応をしなければならないとなると、手間取って非効率的ですし、精神的にも不安が残ります。
もしこの手続きがコード化されていれば、その辺の心配をせず安心して対応することができるようになります。例えば一番初歩的なところだと、Ignore fileの機能を使うことで、うっかりWordPressのuploadsフォルダを上書きしてしまうことを防止出来ます。プロジェクト毎にそうした手続きをしっかりとコード化できるので、いつ更新したかわからなかったり他人が読んだ時に不明な点が入り込む余地のある“秘伝のタレ”的手続書よりも、常に稼働してきたコードの方が信頼できますよね。

色んなサーバー環境への対応

制作会社では案件によって様々なサーバー環境に対応しなければなりません。何でもできるVPSやPaaS等で運用している案件もあれば、gitもrsyncも入っていないようなレンタルサーバーで運用している案件もあります。そのあたりに対応するために、転送にgitは使わず、rsyncとlftpを使います。FTP接続のみ（しかもSFTP非対応とかだったり…）のサーバーなどもたまにあるので、あまり好ましくはないですが、lftpで素のFTPプロトコルによる転送も選択可能にしています。
前章までの繰り返しになりますが、担当者が責任持って、望ましい転送方法をあらかじめ選択していれば、本来SFTPが使えるのに何故か特定の人だけFTPで転送している、などということも予め抑止できます（デプロイ作業のコード化）。また、ターゲットとなるサーバーが望ましいプロトコルに対応した際に、.drone.ymlをアップデートしさえすれば誰がやっても適切な転送方法が選択されます（ワークフローの一元化）。また副産物として、デプロイ用のサーバーが一箇所に集約するので、IP制限のあるサーバーに対して、出先からもデプロイすることができるようになりました。

環境毎の設定変更を自動化

ここまでに書いた問題点は、実はDroneのプラグイン機能を使って解決することもできそうなのですが、drone-deployを作ろうと思いたった、もう一つ重要な要件があります。それは環境毎の設定切替機能です。
例えば、WordPressのサイトでローカルとステージング、本番環境でそれぞれDBの設定を変えなければならない、ステージングサイトでは認証を追加したいなど、環境に合わせて変更したい部分があります。例えばRailsとかだと、環境変数をまとめた設定ファイルを置いて管理しますが、そのようなことができるといいなと思ったのです。
例を見てもらうと早いと思うので以下を御覧ください。WordPressのwp-config.php内のDBの設定部分の抜粋です。

ローカル開発時では、下記のような状態で開発をすすめ、deploy時にその下に示したように変換してくれるという機能です。

// Activate only in local environment
//DEP_REMOTE_RM /*
define('DB_NAME', 'LOCAL_DATABASE');
define('DB_USER', 'root');
define('DB_PASSWORD', 'root');
define('DB_HOST', 'localhost');
//DEP_REMOTE_RM */

// Activate only in master branch's deploy target
//DEP_MASTER_RM define('DB_NAME', 'PROD_DATABASE');
//DEP_MASTER_RM define('DB_USER', 'PROD_USER');
//DEP_MASTER_RM define('DB_PASSWORD', 'PROD_PASSWORD');
//DEP_MASTER_RM define('DB_HOST', 'PROD_HOST');

// Activate only in staging branch's deploy target
//DEP_STAGING_RM define('DB_NAME', 'STAGING_DATABASE');
//DEP_STAGING_RM define('DB_USER', 'STAGING_USER');
//DEP_STAGING_RM define('DB_PASSWORD', 'STAGING_PASSWORD');
//DEP_STAGING_RM define('DB_HOST', 'STAGING_HOST');

↓

// Activate only in local environment
/*
define('DB_NAME', 'LOCAL_DATABASE');
define('DB_USER', 'root');
define('DB_PASSWORD', 'root');
define('DB_HOST', 'localhost');
*/

// Activate only in master branch's deploy target
define('DB_NAME', 'PROD_DATABASE');
define('DB_USER', 'PROD_USER');
define('DB_PASSWORD', 'PROD_PASSWORD');
define('DB_HOST', 'PROD_HOST');

// Activate only in staging branch's deploy target
//DEP_STAGING_RM define('DB_NAME', 'STAGING_DATABASE');
//DEP_STAGING_RM define('DB_USER', 'STAGING_USER');
//DEP_STAGING_RM define('DB_PASSWORD', 'STAGING_PASSWORD');
//DEP_STAGING_RM define('DB_HOST', 'STAGING_HOST');

Railsのようにファイルで切り出すのではなく、コメントアウトを利用して同一コード内に記述するスタイルです。この例の場合、masterブランチにpushしている想定です。sed⁶を使って//DEP_REMOTE_RMや//DEP_MASTER_RMという文字列を削除しています。同じようにstagingブランチにpushすれば、//DEP_REMOTE_RMと//DEP_STAGING_RMが削除されるという具合です。必要なとこだけこの形式でコメント化しておけばよいという形です。詳しくはこちらを参照して下さい。
複数の環境設定をいちいちデプロイ時に、置換する手間がなくなるので、以前までと比べるとかなり効率化されます。個人的にはこれが一番のオシ機能です。

Droneを選んだ理由

CIのサービスはTravis CI や CircleCI など色んな選択肢がありますが、Droneを使うことにしました。その理由は、DroneはOSSでセルフホスティングが可能なため、機密情報の取扱など考えると都合が良かったからです。開発は今も結構盛んなので、まだしばらくは安心して使えそうです。dockerを使って簡単にインストールできるのも良くて、比較的に気軽にアップデートが出来ます（手順はQiitaにまとめてます）。昔VPSでGitlabをホスティングしていた頃の苦労を考えると、dockerベースの運用は隔世の感があります…。CIは最悪壊れても致命的ではないというのもありますが。

今後の展望

Droneにはプラグイン機能があるので、パッケージングしてみるのも面白そうです。その方が他の人も使ってもらいやすいかもしれないですよね。
プラグインはgoで書くのが基本だと思いますが、一応Bashでも作れるみたいなので、ちょっと迷います。シェルスクリプトは文法的なところで結構つまずくので、メンテのしやすい言語で書き直すのは良い気がしますが、逆に依存しすぎると今後移植性の面で不利になるかもしれません。悩ましいですね…。

おわりに

KARAPPOでは、作業負担の軽減や制作物のクオリティアップのために、エンジニアリングの力でできることが、まだまだたくさんあると思っています。そうした作業の手伝いや開発をしてくれる仲間がいると嬉しいです。

---

エンジニアを募集しています！

---

KARAPPOでは、エンジニアリング的視点から生まれる新しいアイデアや問題解決の提案、他の会社ではできないような面白いチャレンジをしていくために、今よりエンジニアの数を増やしたいと思っています。貢献したい／しても良いよという方は、ぜひこちらの募集要項をご覧になってご応募ください（この記事読んだよと書いてくださるとさらに喜びます）。よろしくお願いします！

1. 実際KARAPPOも数年前はそんな状態でした
2. Droneをホスティングするサーバー代だけす。DigitalOceanなら１分単位で借りられます
3. 秘伝といいつつOSSですが
4. 『直接サーバー上のコードを触るってこと？そんなバカな？！』と思われるかもしれませんが、コーディングからデプロイまでのしっかりとしたワークフローが整備されていないと、いつかそんな「バカ」なことが起こる可能性が残るので、これも精神衛生上よくありません…
5. 差分符号化を使ってデータ転送量を最小化し、遠隔地間のファイルやディレクトリの同期を行うCLIツール
6. テキスト変換をしてくれるコマンド

KARAPPOには僕を含めて2名のエンジニア¹がいます。受注案件メインの小さなデザイン会社なので、ほとんどの場合それぞれが別々の案件に並行してあたっています²。そのため、自社プロダクトの運用がメインの会社や、たくさんのエンジニアがいる制作会社と比べると、テック系の話題について社内で話すことも少なく、同時に刺激を受ける機会も少ないのではないかと思います。

そんな日常の中でエンジニアとして常にスキルアップしていくためには、積極的に刺激をうける努力が必要です。こうした問題は、フリーランスの方や、リモートで仕事をされている方も少なからず共感していただけるのではないでしょうか。この記事では、そんな孤独なエンジニアさん達に向けて、テック系ポッドキャストの有用性について紹介したいと思います。

ながらは効率的

ポッドキャストを聞く習慣のない人からすると「トレンドを追いたいなら、ブログを読めば良いのでは？」と思われるかもしれません。確かに、特定のテーマについてまとめられたブログ記事をじっくり読んで理解を深めるというのは、非常に有用ですし、技術ネタがまとまったポータルサイトなどもあるので便利です。ただ、個人的には普段の業務時間の中で情報収集に割ける時間は非常に限られています（落ち着いている時期でない限り、ほぼゼロです…）。そんな生活でも移動時間や家事をしている時間、就寝前など、何かをしながら聞く習慣をつければ、情報取得機会を生活の中に予め挿入してしまえるという点で、活字メディアよりも音声メディアの方が都合が良いのです。

本音やニュアンスが伝わってくる

音声メディアは現時点ではまだサーチエンジンの検閲外だということもあって、活字メディアでは出てきにくい本音がぽろりと出てきたりもします³。また、言外の微妙なニュアンスが伝わってくる点もとても良いところだと思います。活字メディアだと、どうしても無意識的に建前のようなものの影響を受けてしまったり、文章が整えられてしまうことで、筆者がどれくらいの熱量で推薦しているのかについては測りかねる部分があったりもします。今週一週間の技術トピックスまとめのような配信している番組では、ある程度セレクトされた内容を、効率よく得ることができます。そして、話し手の雑感と合わせて配信されるので、活字メディアよりも温度感がわかるのが良い点です。

継続的デリバリー

色々なポッドキャストを購読していると、会社名義の番組もあれば個人名義や有志のグループなど、色々な運営母体があります。それらで共通して話題に上がるのが、いかにして継続的に番組を発信するかというテーマです。例えば、Googleカレンダーに収録の予定表を公表してみたり、フリートーク系の番組では各エピソード内に毎回同じコーナーを入れてみたり、機材や環境に凝ってみたり、他にも様々な工夫でなんとか継続性を高めようと努力されている様子が伺えます。そうした様子がリスナーにも見えるのは、ポッドキャスト特有の面白さではないでしょうか。

エンジニアに限らず社会人にとって『継続性』というのは普遍的なテーマです。ここで試されているノウハウは、別の場面でも役立つヒントになると感じます。そして、そこまでして情報を発信するということの重要性も、ホストの皆さんの試行錯誤の様子から逆説的に感じることができて勇気付けられます。

その他の話題

ホストの方々はOSS⁴のコミッター／オーナーである場合が多く、僕もGitHub上でOSSの運用をしているのですが、そういう話ができる人が周りにいないので、その辺りの話が聞けるのも非常に貴重だなと思います。また、他の会社の中の話、技術スタックや働き方などの話題について聞けるのもとても参考になります。また、ガジェットやゲーム好きな人も多いので、そういう話題も多いです。僕は昔からゲームとは縁遠い人生を歩んできましたが、話しを聞いているうちに俄然興味が湧いてきてしまいました。

独自のコミュニティ形成

ホストの方々のなかには自身の番組のことを「ラジオ」と言っている人が意外に多く、「リスナー」とのコミュニケーションをTwitterを通じてとっているので、ブログよりも親近感が持てます。例えば、Rebuild（後述）のようにサポータープログラムがあったり、Backspace.fm⁵のようにリスナー専用のMastodonインスタンスがあったり、Yatteiki.fm⁶はやっていき場というスペースの運営をしているなど、各番組ごとに独自の方法でコミュニティを形成しています。

得られる情報の密度が高い

Rebuildの@miyagawaさんは以前、新しい技術の概要をつかむためにスクリーンキャストを見ることがが多いとおっしゃっていました。ローカルに環境を整えて試すのは、意外と本筋ではないところで詰まったりして効率が悪い場合があるので、経験を積んだエンジニアであれば、スクリーンキャストを見る方が、知りたいことが効率よく掴めて理にかなっています。スクリーンキャストを見れば、使った気になれるのです。

少し強引かもしれませんが、僕はポッドキャストを聞けば、使い倒した気になれると思っています。特定の技術テーマについて掘り下げるエピソードでは大抵、熟練者が話してくれます。熟練者の率直な感想が聞けると、既知の問題点などについてもあらかじめイメージすることができとても有益です。

百見は一聞にしかず

人は書くときよりも自然とわかりやすい表現を選んでいると思いますし、話し言葉の方が頭に入ってきやすいです。また、聞き手が上手だと素朴な疑問を代わりに聞いてくれたりするので、「百聞は一見にしかず」の逆で「百見（=ブログ）はー聞（=ポッドキャスト）にしかず」だなぁと感じます。

今まさに”Podcast”復興期？

Googleトレンドで”Podcast”を見てみると、2006年くらいに第一の波がきていて、長い間落ち着いていましたが、ここ数年でまた徐々に復興していきています。自分自身の体感としても、特にテック系の番組が増えたことによって、盛り上がっている印象を受けます。日本だけでなく、海外でもたくさん面白そうな番組があるので、英語のリスニング素材としてもいいのではないでしょうか。

おすすめの番組

1. Rebuild

http://rebuild.fm

日本語テック系ポッドキャストの草分け的存在。「いいとも」的な長寿番組です。この番組に影響を受けたと公言するポッドキャスターも数知れずです。最近の回で、技術ネタ的に面白かったのはこのエピソードです。OSまで作っちゃうスーパーエンジニアの@higeponさんがDeepLerningフレームワークのKerasを使ってチャットボットを作った話が聞けます。最近は、テック要素少なめの回も多いので、過去エピソードから面白そうなものをつまみ食いしても良いと思います。エピソードのタイトルがどれも秀逸です。

2. mozaic.fm

https://mozaic.fm

ガチンコ・テック系番組です。ホストの@Jxckさんが特定のテーマについてゲストを迎え、ほぼ雑談なしで、かなりコアな話をします。話す内容の技術レベル高いので流し聞きづらいかもしれませんが、モチベーションが上がります。2017年7月から、Monthly Webというシリーズが始まりました。毎回、かなりな熱量のエピソードばかりだったので、定期的に軽めのエピソードが聞けるのではと期待しています。

3. くもキャスト

http://kumocast.jp

mozaic.fmとは対照的に、2人の若者たちがゆるゆるとした雰囲気でおしゃべりをする番組です。ホストの1人が学生の頃から配信されているので、インターンに行ってきた話しや、就職した話、職場の話など、癒やされます。テック要素少なめでしたが、最近はゲストを迎えるようになって話題も広がり、面白くなってきそうです。期待しています！

4. codelunch.fm

http://codelunch.fm

Cookpadで働く@h13i32maruさんとオタク感漂う@iizukakさんが、たまにゲストを迎えて、毎回テーマに基づいて話す番組です。話してる内容のレベルはかなり高いのですが、雰囲気ゆるめで雑談も面白く（特に@iizukakさんのオススメ本のコーナーが良かった）、一番楽しみにしていた番組だったで、徐々に更新が途絶え、去年は１度しか更新されず悲しいです…。復活を切望しています！

5. Takram Podcast

https://itunes.apple.com/jp/podcast/takram/id1161310459

デザイナーさんも読んでくれているかもしれないので、最後にデザイン系の番組も混ぜておきます。Takram代表の田川さん直々にホストをしておられます。社をあげて力を入れて運営している感じがするので、今後もコンスタントに更新してくれるだろうと期待しています。内容は、毎回社内外からゲストを迎えて色んなテーマについて語られます。Takram自体が“Design Engineering”を謳っている会社なので、テック系の話題も豊富です⁷。

 

これから聞き始める人のために、ちょっとだけ紹介しましたが、他にもたくさんあるので、興味のある方はぜひこちらの「日本語Tech系Podcastいろいろ」という記事を参照してください。残念ながら更新が止まってしまった番組を含め、新しく始まった番組も細かくアップデートされていて、網羅性が高いです。Qiitaアカウントをお持ちの方は、いいね！しておけばリストの更新情報が通知されるので便利です。

おすすめのアプリ

購読はiOSアプリのOvercastをiPhoneに入れて使っています。Overcastの目玉は倍速再生機能が秀逸なところです。普通のアプリだと倍速再生した時に、単純に全体の再生速度が変わるだけなのですが、Overcastの場合、音声データの内容に応じてリアルタイムに再生速度を賢くコントロールしてくれます。例えば1.5倍に設定した時、無音部分は2.0倍、音声部分は1.2倍といった具合に、リアルタイムにタイムストレッチの設定を調整して、全体の再生時間を圧縮しつつも音声部分は聞き取りやすくしてくれます。また、タイムストレッチ機能自体もよくできていてピッチの変化も気になりません。大抵の日本語の番組は倍速で、英語の番組は0.75倍で聞いています。さらに、番組ごとにタイムストレッチなどの設定を記憶してくれる機能や、視聴の終わったエピソードデータを自動削除して端末容量を節約してくれる機能、話し声をブーストしてくれる機能など、細かく気が利いています。個人的に助かるのは、リストに加えても”Subscribe”しなければ、自動でDLされないことで、更新の多い番組も一応リストに入れておいて手動でDLするような使い方ができます。作者は自身もAccidental Tech Podcastという番組を配信している著名なエンジニア@marcoarment ‏さんです⁸。

おわりに

長い文章を最後まで読んでいただき、ありがとうございます！この記事を読んでポッドキャスト面白そうかも？と思っていただけたら嬉しいです。人気のある番組はサポーター／スポンサー制度を取り入れているところもありますが、そのほとんどが有志の方が自費で運営しておられます。そんな方々への感謝の気持ちと、この記事をきっかけに少しでもリスナーが増えてくれるといいな、そして、もっともっと良質なコンテンツが増えるといいなと思っています。

---

僕たちの孤独を埋めてくれるエンジニアを募集しています！

---

KARAPPOでは、エンジニアリング的視点から生まれる新しいアイデアや問題解決の提案、他の会社ではできないような面白いチャレンジをしていくために、今よりエンジニアの数を増やしたいと思っています。貢献したい／しても良いよという方は、ぜひこちらの募集要項をご覧になってご応募ください（この記事読んだよと書いてくださるとさらに喜びます）。よろしくお願いします！

1. 2人ともデザイナーと兼務しています。
2. 自社でWebサービスの運用もしているので、そこには2人とも参加していますが。
3. 著名人のインパクトある発言だと、部分的にツイートされてしまう場合もあるのでしょうが、そうでなければ、これらはリスナーだけが知り得る貴重な情報です。
4. Open Source Software
5. ガジェット系の話題が多く、テック系随一の配信量を誇る長寿番組。
6. 複数のMCが代わる代わるエピソードを配信するという面白いスタイルの番組。
7. 「Takramが使うITとツール」というエピソードの、ファイル共有のためにオリジナルで作ったTakram Driveの話や、プロジェクトマネージメントのためのツールの話などが面白かったです。
8. Instapaperの作者でもあります。