概要

先週末、PyTexasから、テキサス州オースティンで開催された年次カンファレンスでの登壇に招待されました。

楽しい旅で、多くのことを学べました。一方で、費用も時間もかかりました。この記録は、学んだことを共有するとともに、カンファレンス参加で得られるメリットがコストに見合うのかを自分なりに判断するために残しています。

お気に入りのトーク

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

スピーカー: Caitlin Rubin（Optimizely）

フィーチャーフラグを使うと、ソフトウェアチームはまったく新しいデプロイをプッシュするのではなく、実行時にアプリケーションの挙動を変更できます。大きな変更では、しばしば段階的なロールアウトを行いたくなります。たとえば1%のユーザーにだけ有効にし、次に5%、そして25%へと広げていくことで、もし本番環境で問題が起きても被害を最小限に抑えられます。チームはこのような緩やかなロールアウトをフィーチャーフラグで実現することがよくあります。

フィーチャーフラグはコモンズの悲劇の問題を抱えています。個々の開発者にとっては新しい機能のためにフラグを追加するのは簡単ですが、誰もが次々とフラグを追加していくと、アプリケーションには膨大な数の実行パスが生まれ、プログラムの挙動を把握するのが難しくなります。さらに、チームが機能を全体に有効化した後、開発者には分岐ロジックを取り除きフラグを削除するという地味な作業を行うインセンティブがほとんどなくなってしまいます。

このトークでは、フィーチャーフラグとは何か、なぜ問題を引き起こすのかが簡潔に説明され、問題を防ぐための具体的なステップが共有されました。特に印象に残ったのは、ケイトリンが提案した「WIP制限」——Work In Progress limit（仕掛かり制限）です。チームでWIP制限を2に設定すれば、同時に存在できるフィーチャーフラグは2つまでになります。これにより、開発者はいつフィーチャーフラグを使うべきかを慎重に考えるようになり、アプリケーションが分岐ロジックを必要としなくなったときにフラグを確実に削除するようになります。

ほかによかった点：

• スライドがすっきりしていて、文字で聴衆を圧倒することがなかった
• 数秒ごとにスライドが切り替わり、テンポよく進行した
• ケイトリンは舞台上で落ち着いており、はっきりと穏やかに話していた
• プレゼン全体にユーモアがほどよく散りばめられていた

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

スピーカー: Thomas Stephens（uStudio）

私はこれまでずっと、オブジェクト関係マッピング（ORM）フレームワークに苦手意識がありました。ORMは、大量のシリアライズ／デシリアライズのロジックを手作業で実装しなくても、アプリケーションのオブジェクトをデータストアに出し入れできるようにしてくれます。トーマスは、私がずっと抱えながら言語化できずにいたORMの問題点を的確に言い表してくれました。それは、オブジェクトモデルがORMフレームワークに縛られてしまうということです。

私はmypyについても以前から知っていて魅力は理解していたのですが、1年ほど前に自分のプロジェクト（そのほとんどがPython 2.7でした）で動かそうとしてうまくいかず、諦めてしまいました。ご存じない方のために説明すると、mypyはPython用の静的型チェッカーです。コード中のPEP 484の型ヒントを読み取り、違反があれば教えてくれます。

このトークでは、mypyへのやさしい入門が提供され、その利用による大きなメリットが強調されました。つまり、あまり手間をかけずに、自前でデータのシリアライズ／デシリアライズを実装できるということです。トーマスは、型チェッカーに大きく頼ることで、よくあるシリアライズのエラーを防げることを実演しました。

ほかによかった点：

• 解決しようとしている問題が明確に説明されていた
• シンプルで追いやすいライブコーディング
• コードがエレガントで分かりやすかった

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

スピーカー: Harrington Joseph（Netflix）

スライド

アプリケーションでは、オブジェクトの状態を追跡するのに真偽値（boolean）がよく使われます。ハリントンはNetflix所属ということもあり、ビデオプレーヤーを例に使っていて、問題点がよく伝わりました。動画は「再生中」「一時停止中」「停止中」のいずれかの状態を取り得ます。単純なやり方では、これをis_playingやis_pausedのような真偽値で管理しようとします。

このように状態を管理すると、開発者に大きな負担がかかります。状態を推測するために多くの作業が必要になるからです。「停止」状態を判定するにはis_playing == False and is_paused == Falseをチェックしなければならず、回りくどいやり方です。また、不正な状態遷移をチェックするのも開発者の仕事になります。たとえば、すでに停止している動画を一時停止することはできないため、その制約を守るためのコードでごちゃごちゃしてしまいます。

ハリントンは、pytransitionsライブラリがこの問題をいかにエレガントに解決するかを示しました。アプリケーションの状態遷移をシンプルな状態のリストで定義するだけで、あとはライブラリがすべての遷移を管理してくれます。今どの状態にいるかを確認でき、不正な状態遷移があればライブラリが例外を送出してくれるため、手動でチェックするコードを書く必要がありません。

ほかによかった点：

• 美しいスライド
  • ダークテーマがよく合っていた
  • 全画面のシンタックスハイライト付きコードスニペットで読みやすかった
  • ステートマシンの図が分かりやすく優れていた
• 明確なコード例
  • 本筋に関係ないコードは省略されており、考えやすかった

その他の印象的な学び

文章のためのコードレビューツールがある

これはPythonとはまったく関係ありませんが、別の参加者とたまたま話したことで得られた貴重な発見でした。

将来のプロジェクトとして、Reviewableのようなものをコードではなく文章コンテンツ向けに作るというアイデアを温めていました。そのようなツールを探してみたのですが、見つかったのは大手出版社向けのヘビーウェイトなものばかりでした（たとえば新聞社向けで、多数の承認者を含む複雑なワークフローに最適化されたツールなど）。ケイトリン・ルービンと話したとき、彼女はPenflipというまさにそういったツールを知っていると教えてくれました。

最初にPenflipにアクセスしてみた日は、何度再試行しても502 Gateway Errorが返ってきました。翌日はページが表示されたものの、動作は極端に遅く、最終的には回復不能なサーバーエラーになりました。どうやら、もうアクティブなプロダクトではないようです。

それでも、一つ製品名が分かったことで、他を探す手がかりができました。どうやら「コンテンツ版コードレビュー」のような製品は世の中にたくさんあり、その多くが失敗に終わっているようです：

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

Zen of Python（Pythonの禅）

何人かのスピーカーが、The Zen of Pythonという、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はそこに掲載されていなかったようで、応募締切を逃してしまいました。来年はカレンダーに登録しておく必要があります。

プレゼンを効果的にしたもの

• 話し手の落ち着き
  • 最もよかったトークは、スピーカーが落ち着いて時間をかけて話していたものでした。
  • その最たる例が、Adrienne Lowe氏による基調講演、「The Zen of Python Teams」でした。
• パーソナライゼーション
  • スピーカー自身が物語の一部になっているトークの方が、より引き込まれました。どんな問題を解決しようとしたのか、どんな困難に直面したのか、何を学んだのか。こうした問いに答える語りは、「問題Yを解決するツールXがあるのをご存じですか？」という乾いた要約よりもはるかに魅力的でした。

プレゼンを弱めたもの

• マイクの問題
  • プレゼンに集中できなくなる最も多い要因が、音質という基本的でつまらないことだったのは残念でした。
  • カンファレンスではトニー・ロビンズ風の耳掛け式マイクが使われていましたが、多くのスピーカーが正しい位置にセットするのに苦労し、音声がしばしば途切れ途切れになりました。
  • ハンドマイクを選んだスピーカーも、マイクを口元に十分近づけなかったり、十分な声量で話せなかったりして、音を拾えていないことがありました。
• スライドの停滞
  • 優れたプレゼンターはスライドを軽快に進めていました。少なくとも30秒に一度はスライドを進めるか、新しい箇条書きを表示していました。60秒以上同じスライドが何も変わらず表示され続けると、「停滞している」という感覚を覚えました。
• 原稿の棒読み
  • ライブのカンファレンスに参加する楽しみの一つは、参加者である自分自身もトークの一部になることです。スピーカーは聴衆の熱量に反応し、それに合わせてプレゼンを調整します。スピーカーが長い部分を原稿から一字一句読み上げたり（さらに悪いことに、プレゼン全体が固定的な原稿だったり）すると、ライブならではの楽しさが失われてしまいます。
• アニメーションGIF
  • 特に数秒以上ループして画面に表示され続けると、気が散ってしまいました。
  • 安っぽいジョークがスピーカーの主張を損なっていると感じることがよくありました。
• 「これは古いスライドです」
  • いくつかのプレゼンでは、過去のカンファレンスからの使い回しのため、1〜2年古い情報が含まれていました。スピーカーは「このスライドは古いんです」と弁明していましたが、事前に通しリハーサルをしてそうした問題に気づくほど、自分のトークに気を配っていないのだなとがっかりさせられました。

自分のトークを振り返る

スピーカー: Michael Lynch（筆者）

スライド

• うまくいったこと

  • 準備：トークまでの数週間で5〜8回通し練習をしたので、内容に自信を持てました。
  • スライドのペース：動画を見返すと、スライドの停滞を避け、よいテンポでプレゼンを進められているように感じます。
  • Javaいじり（16:15参照）がうまく笑いを取りました。

• 改善が必要なこと

  • もっとゆっくり話す：早口になりすぎました。タイマーを表示し忘れたため、時間内に終わらせようと焦ってしまいました。リハーサルでは27分ほどかかっていたのに、本番ではあまりに早く話したため、30分の持ち時間のうち22分しか使いませんでした。
  • もっと顔を上げる：聴衆と向き合うのではなく、画面を見下ろして内容を読む時間が長すぎました。
  • 「テストコードではマジックナンバーを使ってもよい」（19:58）
    • この一言にはもっと裏付けが必要でした。幸いQ&Aで質問が出たので補足できましたが、本来はプレゼン本編で説明すべきでした。

その他の考察

スピーカーとして参加する方が一般参加者として参加するより価値が高い

今後もっとカンファレンスに参加すべきかを考える中で、スピーカーとしてではなく一般参加者として行くべきか迷っていました。スピーカーとして参加する方が、得られる価値は桁違いに大きいと感じています。

スピーカーの方が、人は話しかけてきてくれます。これは登壇前でも同じで、「何か得意なことがある人に違いない」という印象を持たれるからです。トークの後であれば、会いたいと思ってくれた人は、あなたが情熱を注いでいることを少なくとも一つは知っているので、話すきっかけにも困りません。

また、私自身も、他の参加者よりもスピーカーの方が強く印象に残りました。興味深い人たちとたくさん会話しましたが、数日経っても記憶に残っているのは、登壇していた人たちです。

何かをお願いすればよかった

どのスピーカーも、プレゼンの中で実質的に無料の「コール・トゥ・アクション（行動喚起）」の機会を得られます。多くのスピーカーにとって、それは自社への応募や自社プロダクトの利用への誘いです。私は採用もしておらず、プロジェクトの合間でもあったので、コール・トゥ・アクションという発想自体がありませんでした。

トークの約1時間後、「ああ、企業の人たちに『困りごとを教えてください』とお願いすればよかった」と思いつきました。PyTexasの参加者の多くは、日々の仕事の中で「こんな作業は嫌だ。なぜこれをやってくれるマネージドサービスがないんだ」と思っている部分を抱えているはずです。そうした問題の多くは、プロダクトを作る側と、満たされていないニーズを抱える中小企業とをつなぐのが難しいために、未解決のままになっています。PyTexasは、「ねえ、ぜひ私に話しかけてください。もしかしたら、そのサービスを作りますよ」と言うのに良い場だったかもしれません。

シングルトラックのカンファレンスは雰囲気が違う

これは私が初めて参加したシングルトラックのカンファレンスでした。つまり、どの時間帯にも一つのプレゼンしか行われないため、参加者はどのトークを聞くか迷う必要がなく、選択肢は常に一つだけという形式です。

シングルトラックの良い点は、誰もが同じトークを見ているので、どのプレゼンについても他の誰とでも語り合えることです。スピーカーとしても、聴衆の100%に自分のトークを見てもらえるのは嬉しいことです。

一方で、シングルトラックの欠点は、マルチトラックのカンファレンスで自然に生まれる人の入れ替わりがないことです。マルチトラックでは、トークごとに多くの人が別の部屋に移動し、結果として新しい人と出会うことになります。PyTexasでは、ほとんどの人が一日中同じテーブルに座りっぱなしだったので、他のカンファレンスで見られたような交流は少なめでした。

かかった費用

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

金銭的なコストに加えて、時間的にもコストがかかりました。2日間のカンファレンスでしたが、約5日間は潰れた感覚でした。行き帰りの移動でそれぞれ約1日を失い、さらに不在の間に溜まった仕事以外の用事を片付けるのに約1日かかりました。その上、スライドの作成とリハーサルに20〜30時間を費やしました。

結論：参加は続ける、ただし戦略的に

年初に、2019年は3つのカンファレンスで登壇するという目標を立てました。PyTexasは2つ目だったので、年内にもう一つ登壇すればちょうどよい数になると思います。

私にとってのメリットは、新しい人と出会えること、そうでなければ触れることのなかったツールやテクニックについて聞けること、そして人前で話す練習になることです。最大の収穫の一つはPenflipの存在を知ったことで、まったく予想外でしたが、彼らの失敗から学ぶことで多くの時間とお金を節約できるかもしれません。