はじめに
こんにちは、タイミーでバックエンドエンジニアをしている新谷、須貝、難波です。
2月10日に広島国際会議場で YAPC::Hiroshima 2024 が開催されました。タイミーはGold Sponsorとしてブース出展をしており、エンジニアが3名とDevEnable室が3名の総勢6名で参加させていただきました。
どのセッションも興味深かったのですが、この記事では我々が拝見したセッションのうち特に印象に残ったものをいくつかピックアップしてご紹介します。
なお、タイミーには世界中で開催されている全ての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、エンジニアはこれを使って参加しております。詳しくは下記のリンクをご覧ください。
経営・意思・エンジニアリング
普段我々が行なっているソフトウェア開発の延長線上に CTO の仕事があるよ、という発表でした。経営者が物事をどう捉えているのかを垣間見ることができ、個人的にはベストトークでした。
ソフトウェア設計と組織設計が相似的なアーキテクチャであるということはコンウェイの法則などもあることから直感的に理解できましたが、事業設計とも相似的なアーキテクチャであるという話はまだピンときていないのでまたどこかのタイミングでお伺いしたいと思っています。
また、意思が重要という話はプロジェクトを成功するためには強い意思を持つ推進者が必要不可欠という点で共感していました。ただ、プロジェクトが短期間で終わるものであれば良いのですが、ある程度期間のかかる類のものは個人の意思では難しいこともあるかと思っていて、そういったものはどう対処しているんだろうとも気になりました。
短期的成果の重力に負けないよう、これからのプロダクト開発を行なっていきたいと思います。
（新谷）
関数型プログラミングと型システムのメンタルモデル
コンピュータアーキテクチャに近い手続き型プログラミングから関数型プログラミングへメンタルモデルを変えていこう、という発表でした。私は普段 Ruby on Rails でアプリケーション開発をしていて関数型プログラミングとは距離があるのでとても興味深く聞かせていただきました。
オニオンアーキテクチャは DI ができるとかモックが可能とかが重要なのではなく、手続き型言語の考えに引き摺られがちな I/O の部分を業務ロジックから切り離し、業務ロジックに対して別のパラダイムを適用できるようにするのが本質という話を聞き、なるほどと勉強になりました。
一方、関数型プログラミングが Web アプリケーションのバックエンドに本当に適用できるのかはまだイメージが湧いていないのが正直なところではあります。質疑応答で質問をさせていただいて RDB の書き込みに相当する I/O の部分は Repository 層に閉じ込めるという話は納得したのですが、Web アプリケーションは本質的に並行処理だと思っていて、リクエストを処理している最中に状態が書き換わることをどうやって純粋な関数で表現するのかが気になっています。
懇親会で確定申告の話と一緒に質問しようと思っていたのですが残念でした…
「スマンな！確定申告の話はまた今度！」 と、便の都合で先にかえるnaoya氏 #yapcjapan pic.twitter.com/drogfb5b5Q
— 941 (@941) 2024年2月10日
（新谷）
変更容易性と理解容易性を支える自動テスト
自動テストの目的は
信頼性の高い実行結果に
短い時間で到達する状態を保つことで、
開発者に根拠ある自信を与え、
ソフトウェアの成長を持続可能にすること
という結論からスタートし、その結論に向かって一つずつ解説していく内容でした。
この目的は極限まで削れば「ソフトウェアの成長を持続可能にすること」だと私は思います。これだけだと飛躍があるので一つずつ順を追っていくと、まずソフトウェアの持続可能な成長には変更容易性（変更しやすい）と理解容易性（わかりやすい）が必要です（ないとツラい）。そして変更による既存機能への影響を知る手段のひとつに自動テストがあります。また、自動テストには既存コードの理解を助ける役割もあります。もちろんただ自動テストがあればよいわけではなく、良い自動テストが必要です。
ではどうすれば良い自動テストを書けるのかという話になるわけですが、ここで私が思い出したのは「単体テストの考え方/使い方」（Vladimir Khorikov 著、須田智之 訳）です。
この本の「4.1 良い単体テストを構成する4本の柱」で以下の4つの要素が挙げられています。
- 退行（regression）に対する保護
- リファクタリングへの耐性
- 迅速なフィードバック
- 保守のしやすさ
目的で挙げられた「信頼性の高さ」は「退行に対する保護」（偽陰性からプロダクション・コードを守るもの）と「リファクタリングへの耐性」（偽陽性の数を最小限に抑えるもの）であり、「短い時間で到達する状態」は「迅速なフィードバック」に相当します。そして「信頼性の高い実行結果に短い時間で到達する状態を保つ」ためには「保守のしやすさ」が欠かせません。つまり冒頭の二行に良いテストの条件がすべて凝縮されていたのです。
発表にあった「実行結果は情報」という指摘には良いフィードバックの重要性も感じました。また、Googleのテストサイズの話なども非常に勉強になりました。今回のセッションをきっかけに改めて自動テストの目的に立ち返り、自分たちがより根拠のある自信を持ってコードを書けるようにしていきたいと強く感じています。
最後に余談ですが、発表の中で気になったことを懇親会でtwadaさんご本人に直接質問できたのはオフラインイベントの醍醐味だなとしみじみ感じました。
（須貝）
非同期な開発体制を支えるドキュメント文化
時差のあるメンバー同士でも適切にコミュニケーションを行うために Launchable, inc.で実際に行われているドキュメンテーションの事例を紹介頂く内容でした。
発表の中で特に印象に残ったものを3つほど挙げさせていただきます。
- フィードバックの平等性
- 検索性の意識
- ドキュメントの型化
まず「フィードバックの平等性」についてです。組織にいるメンバーは多様であり聞いた話について素早く考えて話すことが得意な人もいればじっくり考えたい人もいます。また組織内公用語として使われている言語が第一言語でない人もいます。そういった場合に同期的なMTGでやり取りすると議題に対するフィードバックを行う人が偏る傾向があり、またフィードバックの観点も偏りがちです。非同期にフィードバックをもらうようにすることでこの課題の対策としているというのは良い視点だと思いました。なお、タイミーでも参加者が多い一部のMTGでは議事録のドキュメントにフィードバックの欄があり、またMTGの録画を行うことで非同期にフィードバックを行いやすい運用をしていたりします。
次に「検索性の意識」についてです。ドキュメントをしっかり残すことは非同期か否かに関わらず非常に良い文化であり実践している組織も多いと思いますが、ドキュメントが増えると必然的に起きるのが検索性の悪化です。タイミーではドキュメンテーションにNotionを使用しているのですが、閲覧したいドキュメントがなかなか見つからなかったり、見つかったドキュメントが実は古いものだったといったことはどうしても発生します。その対策としてまず部門ごとにConfluenceのspaceを分けているとのことでした。他部門の情報が簡単に閲覧できるという透明性は重要ではあるものの、それは権限管理をしっかりやれば解決できることです。また積極的にアーカイブ（≠ 削除）を行うことでデフォルトの検索設定では検索にヒットしないようにするという話もあり、これはその通りだと思う一方でそれを組織文化とするのは一朝一夕では無いなと感じます。
最後に「ドキュメントの型化」についてです。ドキュメントが一定のフォーマットに準じて作られていれば書き手にとっては書くべき情報が漏れにくいですし、読み手にとっても慣れれば慣れるほど要点を理解しやすくなります。また適切なフィードバックを受けるための30/60/90% framework for feedbackについても勉強になりました。これはドキュメントのフェーズに対して適切なフィードバックを行おうというもので、普段から意識してはいたもののそういった名前が付いていたことは知らなかったので今後のコミュニケーションの際に使おうと思います。そして関連資料のドキュメントへの記載です。ドキュメントを書く際は何かしら参考にした別のドキュメントというものがある場合が多いですし、書き手にとっては自明でも読み手にとってはそうでない場合も多いです。こういった資料のリンクを書き手だけでなく、読み手も積極的にドキュメントに残していこうというのは今後より意識していきたいです。
（難波）
杜甫々さんのキーノート
あの日あの場にいたことを自慢し続けようと思います。
（須貝）
おわりに
YAPCは長く続いているイベントですが、今回エンジニアで参加したメンバーは初参加だったり9年ぶりの参加という感じでした。それでもYAPCの和やかな雰囲気とPerlに関係するテーマもそうでないものも受け入れている包容力で皆大変楽しむことができ、また勉強になったカンファレンスでした。
来年以降もまたスポンサーや参加ができればと思います。
最後にランチとして配られた広島名物のあなごめしの画像を貼って終わりとします。
