YAPC::Okinawa 2018 ONNASONの記録

2018/03/03に沖縄県恩納村で開催されたYAPCに参加してきた。
yapcjapan.org

今回はなんと、スピーカーとしての参加。
http://yapcjapan.org/2018okinawa/timetable.html#/detail/10

初めはこの一連の出来事を時系列にまとめようと思っていたのだけど、あまりにもトピックや感想が多すぎて、ちゃんと書こうと思ったら完全に「仕事」になりそうだったので、頭に浮かんだ順に即興的に書いていくことにした。

スライドができるまで

今回、ぼくが発表したスライドは以下。

speakerdeck.com

ただし、当日の発表ではDEMOを多用しているので、このスライドに載っているのは全体の半分からせいぜい3分の2程度。

それは今回のスライドを作るときに強く意識していたことで、発表時にただスライドを読み上げるだけみたいな、紙芝居のように「スライドをめくりながらそれを見て喋る」みたいにはしたくなかった。

理想としては、スライドには見出しだけを列記する。そしてその一つ一つについて、画像なりDEMOなり、あるいは身ぶり手ぶりで説明してく、みたいにしたかった。

だから、スライドだけを見ても面白くもなんともない、現場にいないと(あるいは動画などで発表の様子を見ないと)意味がわからない、そんな感じにしたかったし、それで良いと思っていた。

(実際には、スライドだけを見てもある程度内容を想像できるようになっているとは思うのだけど。ただ事前の方針として、「後からスライドを見る人のために現場では不要な説明を加えたりしないようにしよう」と思っていたということ)

なにしろ今回一番大事にしたかったのは、わざわざ40分もの間ぼくの発表に付き合ってくれる人たちで、その人たちが「うひー、退屈だな」と思わないようにする、というのがほとんど最大のミッションでもあった。

スライドに書かれた文字が読み上げられるだけ、というのはなかなかツライ。大学の授業でもそういう先生が時々いた。
逆に、「その場にいないと得られない情報がどんどん飛んでくる」というのはスリリングで面白い。

だから、構想を練って項目を立てている最中もスライド化のことはなるべく考えず、Keynoteを立ち上げるのも可能なかぎり後に回した。

シャドープレゼンテーション

構想の練り方としては、だからスライドを作りながら考えるのではなく、かといってメモ帳やノート系のアプリを使うのでもなく、とにかく実際に喋ってみた。

頭の中にあるネタを喋りきって、それをすべて録音して、それを自動音声入力でテキスト化して、それをtextlintでざっくり表記統一して、それをプリントアウトして、それを眺めながら紙のノートにパラパラと見出しを書き出して、それを見ながらまた喋る。

これをたぶん3〜4周やった。

とにかく喋る&録音する、というのはシャドーボクシングならぬシャドープレゼンテーションみたいな感じ。

話を聞いている人たちのことを思い浮かべながら(その人たちは皆ぼくの発表に好意的だと設定しつつ)、その人たちに語りかける。

これはちょっとラジオにも近い。目の前にはいない、でもたしかに存在するはずの人々を想像しながら喋っていく。

だからこれは、「ポッドキャスト風ブレスト」とも言える方法で、それをやりながらどんどん構想を煮詰めていった。

ノートにプロットを書き出しつつ構成する、というのも試してはみたのだけど、プロポーザルを見てもわかる通り、ネタがあまりにも多すぎて、まともに精査していたら時間がいくらあっても足りないし、単純にもの凄く疲れそうだった。

その点、とりあえず思うままに喋るだけなら、頭の中はほとんど無意識というか、自動操縦のような感じになって、あまりくたびれずに膨大なアイディアを吐き出せたと思う。

加えて、喋りながら構想を練ると、60分も90分も喋っているうちにどんどん体が疲れてきて、また気分的にも飽きてくるので、この段階でネタの淘汰も進んでいく。

この話、そんなに無理してまで言わなくてもいいな・・みたいなストッパーが自然にかかるというか。

先にスライドを作り込んでからそれを実践するという順番だと、頭で考えた計画に体を従わせる感じになるが、この方法だと先に体の限界を設定しておいて、その条件を考慮しながら構想を作っていく感じになって、より現実的というか、結果的にではあるが、案外効率的だったように思っている。

ミニマルなスライドのメリット/デメリット

初めにブレスト的に、一旦最後まで喋ったときには90分ぐらいかかった。

理想としては、40分の持ち時間のうち、最後に5分の質疑応答を入れるとしたら発表自体は35分に収める必要があるから、ほとんど1時間オーバーしてる。

さすがにこれはまずい、と見出しのメモを見ながらあれこれ削って、やがて70分になり、50分になり、「ここから先は同じ方法では削れないな」と判断したところで、ようやくスライドを作りはじめた。

この時点で全体の構成はほとんど頭に入っていたから、スライドの初稿は1時間もかからずできたのではなかったか。
かなりあっさり最後まで行って、びっくりした。

とはいえ、この段階では上記のとおり、見出し中心の簡素な内容だったから、枚数も少ない。たぶんその時点では20枚ちょっと。

スライドの枚数が少ないと、短時間で作れるし、修正もラクだし、1枚あたりのクオリティも上げられるから、そういう意味ではメリットが大きい。

ただし、そのぶん本番ではスライドをカンペ的に使うことができないから、当日のプレッシャーや負担が大きくなる。
これはトレードオフで、実際ぼくも発表直前まで、本番で内容を全部忘れてしまったらどうしよう? という不安がつきまとった。

スライドの言葉

初稿ができた後は、少しずつ画像を足したり、説明文を補足したりして推敲を重ねた。
これにより、スライドの枚数も、1枚あたりの文字数も増えていった。

その作業をしていて気づいたが、スライドを作りながら物を考えると、「スライドの中の言葉」で思考するようになっていく。
言い換えると、その「スライドの言葉」を使わなければ論理が進まなくなっていく。

「スライドの言葉」とは、普段ぼくらが誰かに直接話しかけるときの「言葉」とはちょっと違って、スライドの中の世界だけで鳴り響く言葉だ。
これを使い始めると、スライド上の文字は加速度的に増殖していく。

その言葉を使うこと自体は悪いことでないけれど、文字数が増えるのは良いことではない。
単純に見づらくなるし、何より前述の「スライド読み上げプレゼン」まで一直線だ。

それはまずい、ということで、そこからまた文字を削ったり、枚数を減らしたり、最大限の抵抗はしたけれど、やはり終盤のまとめに至るあたりでは、そういった説明的な言葉が優勢になってしまった感がある。

いらすとや回避

スライドに文字をなるべく載せない方策としては、DEMOやスクリーンショットを使うこともそうだが、イラストを活用することも考えた。

この点、いらすとやさんに行けば大抵のフィーリングはイラスト化されていて、これはたしかに依存しやすいというか、めちゃくちゃ便利なツールだなと思わされた。

ただ、各所でいらすとやさんのイラストを使ったものを見ていると、中にはハイコンテクストにうまく活用している事例もあるものの、あまり多用すると誰の発表なのかわからなくなるというか、そもそもいらすとやさんのイラストというのはけっこう記名性が高いように感じられるので(匿名的ではないというか)、発表を乗っとられてしまうような危惧があった。

そこで2番めの案として、自分で手書きしてみることを考えた。

具体的には、以前にきしだなおきさんのブログで見た、こちらのような感じ。
d.hatena.ne.jp

さらさらっとルーズリーフのような紙に絵を描いて、そのままポンとプレゼンしている。スゴイ。

しかしどうも簡単には真似できない。ざっと描いてみることまでは出来ても、ぼくだったらその後の推敲であーでもないこーでもないとかえって時間をかけてしまいそうで、今回はそれだけの時間はないな、と思い直して諦めた。

それでふと「あー、これしかないか」と思ったのがGitHubやSlackでもおなじみのemojiを使うことで、ためしにKeynoteに入れていったら、思いのほか効果的だった。🤗

主張しすぎることもなく、かといって地味すぎることもなく、また微妙なフィーリングもそこそこ表現できて、何より簡単に入れたり外したりできる。

おかげで、文字ばっかりの状態に比べて少し楽しげな感じになって、おそらくはそれが奏功してウケた部分もあって*1、ホッとした。

客層とテーマのマッチング

沖縄までわざわざITカンファレンスに行くような人といったら、その時点で大半がエンジニア/プログラマーだろう、とはぼくも思っていた。

にもかかわらず、ぼくの発表は「ノンプログラマーがどうやってプログラミングを役立てているか」というものだったから、客層とマッチしないのでは? という懸念があった。

普通に考えたら、そのテーマから想定される客層というのは、「これからプログラミングを始めてみたいノンプログラマー」であり、その関心はと言えば、「自分がプログラミングを導入したら普段の仕事がどれだけ捗るのか?」みたいなことだろう。

しかし一方で、ぼくの今回の発表の価値というのはそういうところだけにあったのではなく、これはプロポーザルにも書いたことだが、「大半のプログラミング技術に関する情報はプログラマーが発信しているが、ここではノンプログラマーの私がそれを発信する」という点に意味があった。

通常、プログラミングに触れるノンプログラマーは、つねに「教わる側」であり、教わる側は言葉を持たない。

「わからないな」と思ったとき、それは「わからない自分が悪いのだ」と思ってしまいがちだ。

しかし実際には、ノンプログラマーがプログラミングに触れるとき、そこではいろいろなことが起こっている。
わからないのは、「教科書が間違っているから」かもしれないし、「教え方が悪いから」かもしれないし、「カリキュラム(勉強の仕方)が合ってないから」かもしれない。

ぼくはプログラミングを始めたのが38才を過ぎてからで、今では43才になろうとしているから、まあこれは年齢のせいというよりも性格のせいかもしれないが、いずれにせよ、自分の考えを伝えるための言葉を少しは持っている。

だから、変だなと思ったら「変だ」と言うし、しょうもない成果物でも「できた!」と言うし、YAPCトークにも応募する(それも今回で2回め)。

結果的に、普段あまり人々が聞く機会のない発表が実現したわけで、これは誰が聞いても新鮮であるには違いない。

残る問題は、ぼくがそこでどれだけ「純度の高い情報」を提供できるかということで、だからその点には神経を費やした。

もしそこで、ノンプログラマーにも背景がわかるように・・と終始基礎的な話をしていたら(ターミナルの立ち上げ方とか 、Vimの初期設定の手順とか)、一緒に聞いているプログラマーには退屈な時間になってしまうだろうし、かといって専門的な話をしようとしても中途半端になるだけだろう。

だから、とことん「自分が面白いと思ってる話」だけを取り上げることにした。

枝葉的な解説は最小限にとどめ、自分自身がエキサイトするような事象を集めて、そのことだけを話そう、と。

その純度が高ければ高いほど、つまりぼく自身が「この話、面白い!」と思えれば思えるほど、発表はきちんと聞き手に届くはずだと思って、そうした。

懇親会の終わりに話したこと

入門書のジレンマ

発表が終わり、懇親会になり、その終盤、朝からつづいた雨も上がり、会場から一人また一人と夜の庭へ出ていくのが見えた。

それにつられるように、ぼくも会場からフラフラと出ていったところで、ぼくの発表を見たという人から声をかけられた。

その人は、自分もプログラマーではなく、今回スポンサーをしている会社のひとつに勤めているのだと言った。

それからしばらく、いろいろと嬉しい感想をもらいながら、上に書いた「ノンプログラマー発の技術情報であることに意味がある」みたいな話をした。

ぼくらノンプログラマーが技術情報に触れようとしたとき、それを書いているのはつねにプログラマーなのだと。

その人は、プログラマーが書いた入門書などを読んでもわからないことがあると言い、ぼくは「それは自然なことだ」と言った。

プログラマーはノンプログラマーではないがゆえに、ノンプログラマーがどこでつまづくのかをわからないのだと。

もちろん、中には例外的な人もいて、結城浩さんなどはその例にはあたらない。

結城さんはつねに、読者が「今どこにいるのか」を考えながら書いているから、相手がプログラマーであろうとノンプログラマーであろうと、読者を置いてけぼりにはしない。

逆に言えば、わかりづらい入門書とは、読者が「今どこにいるのか」を想像できていないのだ。

何であれ、情報を整理して他人に伝えるときには、膨大な、かつ茫漠とした情報の海の中から、必要と思える要素を取捨選択しなければならず、それはつまり不要な部分を省略しなければならないということだ。

わかりづらい入門書というのは、そのとき、省略してはいけない部分を省略してしまっている。

ビルの上の階まで上がろうというとき、適切な高さの階段が均等に積まれていれば誰でも上がっていけるが、所々に異様に高い段差があったら、上がれない人が出てくる。

入門書を書くような人というのは、すでに専門家として何年もキャリアを積んでいる人だから、「どの階段を省略したら入門者がついてこれなくなるのか」を想像しながら書いていくのが難しいのかもしれない。

だからこそ、自分のようなノンプログラマーが技術情報を発信することには何らかの価値があるだろうと思うし、そのときもたぶんそういう話をした。

プログラマーとノンプログラマーを分けるもの

そのときに話したことをもう一つ書いておくと、これは本来、今回の発表にも入れたいと思っていたのだけど、とても時間が足りなくてカットしたもので、「プログラマーとノンプログラマーの違いは何か?」という話。

また喩え話になるが、ノンプログラマーによるプログラミングが「趣味の魚釣り」だとしたら、プログラマーによるプログラミングは「漁業」である。

趣味の魚釣りと漁業との違いは、「誰のために魚を獲るのか?」ということで、言い換えれば、「獲った魚を食べるのは誰か?」ということだ。

漁師は自分たちの食べ物を確保するために漁をしているのではなく、不特定多数の他人が食べる魚を獲っている。

一方で、趣味の釣り人は自分が楽しむために魚を釣っている。

どちらが偉いわけでもないが、他人の口に入るものを扱う以上、責任は漁師の方が遥かに重い。
それゆえ、面倒なこともたくさんしなければならないし、多くの技術を身につける必要もある。

どれだけ多くの魚を獲れるかという意味で、趣味の釣り人が漁師に勝てる日は来ない。やっていることのケタが違うのだ。

くり返すが、これはべつにプログラマーがノンプログラマーより偉いという話ではない。

視点を変えて、たとえばぼくは今編集を生業にしているけれど、その分野で言ったらぼくの方が漁師ということになる。

だから考えるべきは、趣味の釣り人が魚を釣るように、ノンプログラマーのぼくがプログラミングをかじったところでそれが何になるのか? ということだ。

その答えはある。

ぼくにとってのプログラミングはどこまでも趣味に過ぎず、その技術が毎日大量のトラフィックを重い責任のもとにさばいているプログラマーのそれを超える日は永遠に来ないが、それでもプログラミングを通してぼくの本業の生産性が高まったら、それはめぐりめぐって、プログラマーを含む社会への貢献を果たすことになるだろう。

何もプログラミングの世界で職業プログラマーに勝つ必要などなく、自分の生産性を上げたり、あるいは自分の人生を豊かにしたりできれば、それだけでも充分意味のあることなのだ。

ジェロニモと私

最後にもうひとつ、これを書いてこの記事を終わるが、その会話の最後の方で、「結局、ノンプログラマーがプログラミングを習得する方法としては、やっぱり仕事に取り込むっていうのが効果的なのでしょうか?」みたいな質問をもらって、それについてあらためて考えられたのもよかった。

ぼく自身がなぜプログラミングを続けてこれたのかと考えたら、それは「仕事に役立つから」というより、プログラマーの人たちがいつもなんだか楽しそうで、「あんな風になりたいな〜・・」と思ったからだった。

これは以前、吉祥寺.pmというイベントで発表したとき、そのスライドに入れるつもりだったものの結局時間がなくて削った話なのだけど、『キン肉マン』という漫画に出てくるジェロニモというキャラクターがいて、彼は本当は人間なんだけど、超人のテリーマンたちに憧れて正義超人の仲間に入って、しかしその後悪魔超人たちと闘ってメタメタにやられてしまう。

そこで出てくる名ゼリフに、「だってオラは人間だから」というのがあって、ノンプログラマーでプログラミングなんてやってると、そんなのばっかり。

プログラマーと自分とではまったくいる場所が違うというか、素地が違うというか、土台が違いすぎるので相手にならない。ツライ。

だけど、大事なのは勝つとか負けるとか、誇らしいとかみっともないとかではなくて、そのジェロニモテリーマンとかキン肉マンとかに対して抱いたような「憧れ」があるかどうかなのだと思う。

プログラミングをやる理由が「仕事に役立つ!」というだけだとちょっと弱くて、それだけだと「だって人間だから・・」みたいな感じでつぶれちゃう。くじけてしまう。そんな気がする。

だけどそこに、「憧れ」が残っていたら続けられる。というか勝手に続いていく。

それはべつに特定の誰かに対するものでなくても、ぼくだったらテクノロジーを味方につけることで稀に体験する、「それまで100日かかっていた作業が5分で終わった」みたいな劇的な変化への憧れというか、希求がいつもある。

ぼく自身が経験的に責任をもって言えるのはそこまでなんだけど・・と、そういう話をした。

その他のトピック

上記の機会では、相手の方からのコメントが本当にどれもクリエイティブ&丁寧なものだったので、普段考えていることをどんどん話すことができて、他にもたくさん面白い会話をしたのだけど、ひとまずここまで。

YAPC::Okinawaについては、前夜祭やイベント翌日のハッカソン、その後のお土産屋めぐりや、そもそものプロポーザルに至る話など、まだまだトピックはあるのだけど、その辺はまた時間ができたら、続編として書いてみたい。

*1:P19.「Finderは疲れる」というあたりなど。