概要

先週末、PyTexasから、テキサス州オースティンで開催された年次カンファレンスで講演してほしいと声をかけてもらいました。

楽しい旅行でしたし、たくさんのことを学びました。一方で、金銭面でも時間の面でも、かなり高くつきました。今回メモを残すのは、学んだことを共有したいからというだけでなく、カンファレンスに参加して得られるメリットが、かかったコストに見合うのかを考える材料にしたいからでもあります。

お気に入りの講演

意図的なデプロイ：フィーチャーフラグ管理のベストプラクティス

講演者：OptimizelyのCaitlin Rubin

フィーチャーフラグを使うと、アプリケーション全体を新しくデプロイし直さなくても、実行時にアプリケーションの振る舞いを変更できます。大きな変更を加える場合は、段階的にロールアウトしたいことがよくあります。まずユーザーの1％に有効化し、次に5％、その次に25％という具合です。変更によって本番環境で大きな問題が起きたときの被害を抑えるためです。チームはこのような段階的なロールアウトを、フィーチャーフラグで実現することがよくあります。

フィーチャーフラグには、共有地の悲劇という問題があります。個々の開発者にとっては、新機能のためにフラグを1つ追加するのは簡単です。しかし全員が新しいフィーチャーフラグを次々に追加していくと、アプリケーションには非常に多くの実行経路が蓄積し、プログラムの振る舞いを把握するのが難しくなります。さらに、チームが機能を全体で有効にした後は、分岐ロジックを削除してフラグを取り除くという面倒な作業を、開発者が行う動機もほとんどありません。

この講演では、フィーチャーフラグとは何か、なぜ問題を引き起こしうるのかが簡潔に説明され、問題を防ぐための具体的な手順も紹介されました。特に気に入ったのは、Caitlinが提案した「WIP制限」、つまり仕掛かり中の作業に対する上限です。チームがWIP制限を2に設定すれば、同時に存在できるフィーチャーフラグは2つだけになります。これによって、開発者はフィーチャーフラグを使うべきタイミングを慎重に考えるようになりますし、アプリケーションが分岐する機能ロジックを必要としなくなったら、フラグを削除することも徹底できます。

ほかに気に入った点：

• スライドの構成がすっきりしていて、観客を大量の文章で圧倒しなかった
• 数秒おきにスライドが進むか更新され、テンポが保たれていた
• Caitlinはステージ上で落ち着いていて、明瞭かつ穏やかに話していた
• プレゼンテーション全体に、ユーモアがほどよく散りばめられていた

mypyでORMから自由になろう！

講演者：uStudioのThomas Stephens

私は以前から、オブジェクトリレーショナルマッピング（ORM）フレームワークが苦手でした。ORMを使えば、開発者はシリアライズやデシリアライズのロジックを大量に手書きしなくても、アプリケーションのオブジェクトをデータストアに出し入れできます。Thomasは、私がORMシステムに対してずっと感じていたものの、うまく言葉にできなかった問題を明確に説明してくれました。ORMシステムは、オブジェクトモデルをORMフレームワークに縛り付けてしまうのです。

mypyについても以前から知っていて、その魅力も理解していました。ただ、1年ほど前に試したときは、自分のプロジェクト（その大半はPython 2.7でした）で動かすのに苦労したので、諦めてしまいました。知らない人のために説明すると、mypyはPython用の静的型チェッカーです。コード中のPEP 484の型ヒントを読み取り、それに違反している箇所を教えてくれます。

この講演では、mypyが丁寧に紹介され、mypyを使うことで得られる、非常に広範なメリットにも光が当てられました。具体的には、過度な手間や負担をかけずに自分でデータのシリアライズとデシリアライズを実装できるということです。Thomasは、型チェッカーを大いに活用して、よくあるシリアライズエラーを防ぐ方法を実演しました。

ほかに気に入った点：

• 解決しようとしている問題が明確に説明されていた
• シンプルなライブコーディングで、追いやすかった
• コードが洗練されていて明快だった

Booleanだけでは足りないとき……ステートマシン？

講演者：NetflixのHarrington Joseph

スライド

アプリケーションでは、オブジェクトの状態を追跡するためにBooleanを使うことがよくあります。HarringtonはNetflixに所属しているので、動画プレーヤーを例に使っていました。これが問題をうまく浮き彫りにしていました。動画は再生中、一時停止中、停止中のいずれかです。単純な実装では、is_playingやis_pausedのようなBooleanでこれを管理するでしょう。

このように状態を管理すると、開発者の負担が大きくなります。状態を推論するために、多くの作業が必要になるからです。「停止中」という状態を導き出すには、is_playing == False and is_paused == Falseを確認しなければならず、まわりくどい方法です。また、不正な状態遷移をチェックする作業も開発者に大きくのしかかります。たとえば、すでに停止している動画を一時停止することはできません。その制約を強制するためのコードが、コードをいたずらに複雑にしてしまいます。

Harringtonは、pytransitionsライブラリがこの問題をどのように洗練された形で解決するかを実演しました。状態を単純なリストで定義すれば、あとはライブラリがすべての状態遷移を管理してくれます。現在どの状態にいるかを確認できますし、不正な状態遷移があればライブラリが例外を発生させます。手作業でチェックするコードを書く必要はありません。

ほかに気に入った点：

• 美しいスライド
  • 暗いテーマがうまく機能していた
  • 構文ハイライト付きのコードスニペットが全画面表示され、読みやすかった
  • ステートマシンの図がわかりやすく、素晴らしかった
• 明快なコード例
  • 本題に関係のないコードを省略していて、考えるべきことが整理されていた

そのほかの注目すべき学び

文章にもコードレビュー用のツールがある

これはPythonとはまったく関係ありませんが、別の参加者と話していて偶然知ることができた、価値ある発見でした。

将来のプロジェクトとして、コードではなく文章コンテンツを対象にしたReviewableのようなものを作りたいと考えていました。そういうツールを探したことはありますが、大手出版社向けの大がかりなツール（新聞社向けで、承認者が多い複雑なワークフローに最適化されたツールなど）しか見つかりませんでした。Caitlin Rubinと話していたとき、彼女はPenflipという、まさにそのようなツールを知っていると教えてくれました。

Penflipに初めてアクセスした日は、何度も再試行したのに502ゲートウェイエラーが表示されました。翌日にはページが読み込まれましたが、動作が極端に遅く、最終的には復旧不能なサーバーエラーになりました。どうやら、もう活動しているプロダクトではないようです。

それでも、プロダクト名を1つ知れたことで、ほかのサービスを探す足がかりにはなりました。調べてみると、「コンテンツ向けのコードレビュー」のようなプロダクトは、失敗したものも含めて、かなりたくさん存在していたようです。

• Draft：今でも機能している数少ない編集アプリの1つですが、レビューはあまりうまくサポートしていないようです。
• Editorially：無料ツールで、利用者からはとても好評だったようですが、2014年に終了しました。サービス終了を惜しむ記事をたくさん見つけました。
• Typewrite：サイトはまだ存在していますが、サインアップすらできないほど機能が壊れています。Twitterへの最後の投稿は2014年なので、もう終わっているのだと思います。
• Poetica：言及されているのを見たことはありますが、今は終了しています。特に人気があったようにも見えませんでした。

Pythonの禅

何人かの講演者が、Pythonの指針となる原則をまとめた有名なリスト、The Zen of Pythonに触れていました。私はこのリストを見たことがありませんでしたが、知っておいて損はありません。Pythonインタープリターでimport thisと入力すれば、いつでも表示できます。

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

PyConは一大イベント

何人もの人がPyConについて熱く語っていました。PyTexasは小規模な地域カンファレンスですが、PyConは全国規模で、いわば大リーグです。プレゼンテーションの質が高く、出会える有益な人も多いようです。私はこれまで、今後開催されるカンファレンスをPaperCallに頼って探していました。しかしPyConはPaperCallを使っていなかったようで、講演応募の締め切りを逃してしまいました。来年のカレンダーには追加しておかなければなりません。

効果的なプレゼンテーションを作るもの

• 講演者の落ち着き
  • 最もよかった講演は、講演者がリラックスしていて、時間をかけて話しているものでした。
  • その最たる例が、Adrienne Loweの基調講演「The Zen of Python Teams」です。
• 個人的な経験
  • 講演者自身が話の中に登場する講演のほうが、私は興味を持って聞けました。どんな問題を解決しようとしていたのか。どんな困難に直面したのか。何を学んだのか。こうした問いに答えるほうが、「問題Yを解決するツールXがあるのを知っていますか？」という無味乾燥な紹介より、はるかに引き込まれます。

プレゼンテーションを弱めるもの

• マイクの問題
  • プレゼンテーションから私の意識をそらしたものの中で、音質というあまりにも基本的で退屈な問題が最も多かったのは残念でした。
  • カンファレンスではTony Robbins風の耳掛けマイクが使われていましたが、多くの講演者が正しい位置に装着するのに苦労していたため、音声が聞こえたり聞こえなくなったりすることがよくありました。
  • ハンドマイクを選んだ講演者もいましたが、口元に十分近づけて持つことや、マイクが拾える音量で話すことに苦労していました。
• スライドの停滞
  • 最も優れた講演者は、スライドをきびきびと動かしていました。少なくとも30秒に1回はスライドを進めるか、新しい箇条書きを表示していました。講演者が同じスライドを何も変えずに60秒以上表示し続けると、「行き詰まっている」ように感じたのを覚えています。
• 台本の読み上げ
  • ライブカンファレンスに参加する楽しさの一部は、参加者自身が講演の一部になることです。講演者は観客の反応に応じて、プレゼンテーションを調整しています。講演者が台本を長い区間にわたって一字一句読み上げると（ましてプレゼンテーション全体が静的な台本になっていると）、ライブで聞く楽しさが失われます。
• アニメーションGIF
  • 私はこれが気を散らすと感じました。特に、画面上で数秒以上ループし続けている場合はそうです。
  • 安っぽいジョークが、講演者の主張を台無しにしていると感じることもよくありました。
• 「これは古いスライドです」
  • 以前のカンファレンスから使い回したために、1、2年前の情報が含まれているプレゼンテーションがいくつかありました。講演者は「このスライドは古いので」と弁解していましたが、事前に一度通して確認していれば気づけたはずの問題を、講演者が見直すほど自分の講演を大切にしていないのだと感じ、いつもがっかりしました。

自分の講演を振り返る

講演者：Michael Lynch（私）

スライド

• うまくいった点

  • 準備：講演までの数週間で5～8回リハーサルをしたので、内容には自信を持てました。
  • スライドのテンポ：動画を見返すと、スライドの停滞を避け、よいペースでプレゼンテーションを進められていたように思います。
  • Javaへの皮肉（16:15）では、よい笑いが取れました。

• 改善が必要な点

  • もっとゆっくり話す：話すスピードが速すぎました。タイマーを表示しておくのを忘れたので、時間内に終えようと焦っていました。リハーサルでは27分ほどかかっていたのに、本番ではあまりに急いだため、30分の持ち時間のうち22分しか使いませんでした。
  • もっと顔を上げる：観客とやり取りする代わりに、画面を見て内容を読む時間が長すぎました。
  • 「テストコードではマジックナンバーを使ってもよい」（19:58）
    • この発言には、もっと根拠を説明する必要がありました。幸い、Q&Aで質問してくれた人がいたので説明できましたが、本来はプレゼンテーションの中で説明しておくべきでした。

そのほかの考え

一般参加者よりも講演者として参加するほうが価値がある

今後さらにカンファレンスに参加するか考える中で、講演者ではなく一般参加者として参加するべきかどうか悩みました。しかし、講演者として参加するほうが、得られる価値は桁違いに大きいと感じます。

講演者のほうが、話しかけてもらいやすいのです。講演をする前でさえ、「ああ、この人は何かが得意なんだな」と思ってもらえます。そして講演後には、話しかけたいと思った人も、講演者が少なくとも1つ、情熱を持っているものを知っているので、話題に困りません。

また、ほかの参加者よりも、講演者のほうが私の印象に長く残ることにも気づきました。興味深い人たちとはたくさん話しましたが、数日たっても覚えているのは講演をした人たちです。

何か頼めばよかった

講演者は皆、プレゼンテーションの中で、実質的に無料の「行動喚起」を1回使えます。多くの講演者にとって、それは自社への応募や自社製品の利用を促す呼びかけです。私は採用をしていませんし、プロジェクトとプロジェクトの合間にいたので、行動喚起という発想がありませんでした。

講演の約1時間後、私は「そうだ、企業に困っていることを送ってもらえばよかった！」と思いました。PyTexasの参加者の多くは、日々の仕事の中に「これをやるのは本当に嫌だ。なぜ、これを代わりに処理してくれるマネージドサービスがないんだろう？」と思うような作業を抱えているはずです。満たされていないニーズを持つ中小企業と、プロダクトを作る人がつながるのは難しいため、そうした問題の多くは解決されないままです。PyTexasは、「ねえ、話を聞かせてください。もしかしたら、そのサービスを私が作るかもしれません」と伝えるには、よい場だったのかもしれません。

単一トラックのカンファレンスには独特の雰囲気がある

今回が、私にとって初めて参加する単一トラックのカンファレンスでした。ここでいう単一トラックとは、どの時点でも行われているプレゼンテーションが1つだけで、参加者がどの講演を聞くか選ぶ必要がない、常に選択肢が1つしかない形式のことです。

単一トラックのよい点は、全員が同じ講演を見るため、誰とでもどのプレゼンテーションについて話せることです。相手もおそらくその講演を見ています。講演者としても、自分の講演を観客全員に見てもらえるのはうれしいことです。

一方で、単一トラックのイベントには、複数トラックのカンファレンスで自然に生まれる人の入れ替わりがありません。複数トラックのカンファレンスでは、各講演の後にほとんどの人が別の部屋へ移動するため、結果的に新しい人と出会います。PyTexasでは、一日中同じテーブルに座り続ける人が多く、ほかのカンファレンスで見たほど交流がありませんでした。

費用

このカンファレンスへの参加には、予想以上にお金がかかりました。

金銭面だけでなく、時間の面でも高くつきました。2日間のカンファレンスですが、約5日間にわたって私を疲れさせました。往復の移動でそれぞれおよそ1日を失い、留守中にできなかった仕事以外の用事を片づけるのに、さらに1日ほどかかりました。そのほかに、スライドの作成とリハーサルに20～30時間を費やしました。

結論：戦略的に参加し続ける

年の初めに、私は2019年に3つのカンファレンスで講演するという目標を立てました。PyTexasが2つ目だったので、今年はあと1つあればちょうどよいと思います。

私にとってのメリットは、新しい人と出会えること、そうでなければ知る機会のなかったツールや技術について聞けること、そして人前で話す練習ができることです。最大の収穫の1つは、Penflipについて知ったことでした。まったく予想していなかった発見でしたが、彼らの失敗を避けることで、時間とお金を大幅に節約できるかもしれません。