Timee Product Team Blog

タイミー開発者ブログ

言語処理学会第30回年次大会(NLP2024) 参加レポート

はじめに

こんにちは、株式会社タイミーの貝出と申します。データサイエンティストとして働いており、直近はカスタマーサポートの業務改善に向けたPoCやシステム開発など行っております。

さて、今回は2024年3月11日(月)~3月15日(金)に開催された「言語処理学会第30回年次大会(NLP2024)」にオンラインで参加してきましたので、参加レポートを執筆させていただきます。

言語処理学会年次大会について

www.anlp.jp

言語処理学会年次大会は言語処理学会が主催する学術会議であり、国内の言語処理の研究成果発表の場として、また国際的な研究交流の場としての国内最大規模のイベントとなっています。

今回の年次大会は第30回を迎え、発表件数が599件、参加者数(当日参加者は除く)が2045人と大会の規模も過去最大となっており、年々大会が盛り上がっていることが伺えます。
※ 下のグラフは大会のオープニングで共有されたものです。

言語処理学会第30回年次大会に参加できなかった方でも、こちらから発表論文が閲覧できます。

興味深かった研究

初日のチュートリアルから最終日のワークショップまで興味深い発表がたくさんありましたが、個人的に気になった発表をいくつかピックアップします。

[C3-4] InstructDoc: 自然言語指示に基づく視覚的文書理解

概要

こちらの研究では、自然言語指示に基づいて文書を視覚的に理解するための基盤データセット「InstructDoc」が提案されています。InstructDocは、12種類の視覚的文書理解(VDU)タスクから構成され、多様な自然言語指示を提供する最大規模のデータセットとなっています。

研究チームでは、大規模言語モデル(LLM)の推論能力を活用し、文書のレイアウトや視覚要素を同時に理解することが可能な新しいモデル「Instruction-based Document reading and understanding model(InstructDr)」を提案し、実験を通じてその性能を検証しています。InstructDrは、自然言語指示を基に未知のVDUタスクに適応し、従来のマルチモーダルLLMの性能を超えることが確認されました。また、指示チューニング済みのモデルの重みを初期値としてFine-Tuningすることで、複数のVDUタスクで世界最高性能を達成しました。

感想

こちらの研究では視覚的文書理解の汎化性能の向上に貢献されています。自然言語指示を用いて文書画像からタスクを汎用的に実行できる技術は、社内オペレーションの様々なタスクを容易にする可能性を秘めており、今後の研究にも期待です。

NTT人間情報研究所の方による以下の過去発表資料と今回の研究はリンクする内容だと感じており、合わせて読むことで全体像がイメージしやすかったです。

Collaborative AI: 視覚・言語・行動の融合 - Speaker Deck

[A6-1] Swallowコーパス: 日本語大規模ウェブコーパス

概要

オープンな日本語言語大規模モデルの学習には、CC-100、mC4、OSCARなどのコーパスの日本語部分が用いられてきました。しかし、これらはあくまで海外で開発されたものであり、日本語テキストの品質を重視して作られたわけではありません。

そこで、研究チームは商用利用可能な日本語コーパスとしては最大のウェブコーパスを構築しました。Common Crawl のアーカイブ(2020 年から 2023 年にかけて収集された 21スナップショット分、約 634 億ページ)から、日本語のテキストを独自に抽出・精錬し、最終的には約3,121 億文字(約 1.73 億ページ)からなる日本語ウェブコーパス(Swallowコーパス)を構築しています。

Swallowコーパスは、「(1) Common Crawl の WARC ファイルから日本語テキストを抽出する。(2) 品質フィルタリングおよび重複除去で日本語テキストを厳選する。(3) テキスト内の正規化を行う。」の手順により構築されました。

Swallowコーパスを用いて Llama 2 13B の継続事前学習を行ったところ、既存のコーパスを用いた場合と比べて同等かそれを上回る性能の LLM を構築できたと報告されています。

感想

業務上LLMの日本語大規模コーパスを作ることはありませんが、自然言語処理のデータセットを作成するうえでのTipsとして大変勉強になりました。例えば、日本語判定をするためにサポートベクターマシンを学習させ fastText より高速化させた話や、MinHash による文書の重複判定など。

また、 [A8-5] では Swallow コーパスを利用した継続学習について詳しい内容が発表されており、そちらも面白かったです。

[A7-6] AmbiNLG: 自然言語生成のための指示テキストの曖昧性解消

概要

大規模言語モデル(LLM)の登場により自然言語の指示を用いた指示によって様々な言語処理タスクが実行可能になりました。しかし、これらの指示の曖昧性によりユーザの意図と異なるテキストが生成されることが問題となっています。

こちらの研究は、自然言語生成(NLG)タスクでの指示テキストの曖昧性を解消するためのベンチマークデータセットとして「AmbiNLG」が提案されました。AmbiNLG でのデータセットの作成に LLM を用いてアノテーションを行い、幅広い29のNLGタスク2000事例からなるデータセットを構築されています。また、実験により曖昧性補完の手法については、実験により複数の曖昧性カテゴリを明示的かつ組み合わせで与えることが重要であると示唆されました。

感想

LLMを使いこなすためにはプロンプトを適切に調整することが重要だと言われていますが、指示テキストの曖昧性を能動的に指摘 or 修正できるような仕組みがあれば、よりユーザーフレンドリーなLLMを構築することが可能かと思われます。個人的にも欲しい機能です!

今後の展望では、曖昧性認識・追加指示の生成・推論をend-to-end で行う対話システムの構築について言及されていたので、実際にユーザの意図をどのようにシステム側で汲み取っていくかが気になります。

おわりに

NLP2024では、他にも多数の魅力的な研究が発表され、5日間という期間が非常に充実したものとなりました。特に、大規模言語モデル(LLM)に関連する研究が目立ちましたが、その範囲はデータの構築から事実性や安全性の検証に至るまで広がっており、多様な角度からの研究成果を見ることができたのが印象的でした。

現在、タイミーでは、データサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています!

また、気軽な雰囲気でのカジュアル面談も随時行っておりますので、ぜひお気軽にエントリーしてください。↓

hrmos.co

hrmos.co

【イベントレポート】try! Swift Tokyo 2024

こんにちは、iOSエンジニアの前田(@naoya_maeda) 、早川(@hykwtmyk)、三好、岐部(@beryu)、Androidエンジニアのみかみ(@mono33)です。

2024年3月22-24日に渋谷で開催されたtry! Swift Tokyoに、タイミーもGOLDスポンサーとして協賛させて頂きました。
私達もイベントに参加したので、メンバーそれぞれが気になったセッションを紹介します。

特に気になったセッション(前田編)

僕が特に気になったセッションは、リルオッサさんによる「SF Symbolsの芸術的世界:限りない可能性を解き放つ」です。

リルオッサさんは、iOSDC Japan 2022でもSF Symbolsアートの可能性についてお話されており、今回のセッションでは、アニメーションを交えたダイナミックなSF Symbolsアートを紹介されていました。

  • SF Symbolsとは

SF Symbolsは、Appleが提供するアイコンおよびシンボルのセットです。

WWDC 2019で初めて開発者に公開され、iOS 、macOS、watchOSで使用可能になりました。

SF Symbolsは、定期的にアップデートが行われ、新しいアイコンやシンボルの追加、パフォーマンスの改善が行われています。

  • SF Symbols 5とは

SF Symbols 5では、5000を超えるアイコンおよびシンボルが提供されています。さらに、わずか数行のコードでアニメーションエフェクトを実現することができるようになりました。

「SF Symbolsの芸術的世界:限りない可能性を解き放つ」では、さまざまなアイコンやシンボル、そしてSF Symbols 5で追加されたアニメーション機能をフルに活用し、ダイナミックなSF Symbolsアート作品が紹介されています。

www.youtube.com

普段何気なく使用しているSF Symbols達が組み合わされていき、一つのSF Symbolsアート作品になる様は圧巻でした!

また、SF Symbols 5には、様々なアニメーションエフェクトが用意されていると知ることができ、タイミーアプリ内でもSF Symbolsを活用していきたいと感じました。

今回ご紹介しきれなかった作品はGitHubで公開されているので、ぜひ一度ご覧ください!

github.com

ご登壇資料

www.docswell.com

特に気になったセッション(早川編)

今回、自分が気になったセッションは「コード署名を楽しく乗り切る方法」です。

このセッションではCertificate、Provisioning Profile、Application Identifierなど、アプリをリリースする上で必要なコード署名の要素を分かりやすくパズルに見立てて解説していました。

また、パズルに見立てることによってどこにエラーが起きているのかが分かりやすくなり解決するための要素の推測も容易になったかなと思います。

下の図で言うとProvisioning ProfileはCertificateとは問題なく結びついていますが、Application Identifierと正しく結びついていないためエラーが起きています。

解決するには「Provisioning Profileに結びついているApplication Identifierと一致するようにアプリ側のApplication Identifieを設定しなおす」か、「Provisioning Profileをアプリ側に設定されているApplication Identifierに合わせて作成しなおす」かになります。

各要素をパズルのピースに見立てることで、相互の結びつきが視覚的に解像度高く理解できました。

登壇者のJosh Holtzさんの発表内容も相まってコード署名を楽しく感じることができました笑

特に気になったセッション(みかみ編)

特に印象に残ったセッションは「マクロをテストする」です。今回のtry! Swiftでも注目を集めていたTCAを開発する、Point-FreeのStephenさんとBrandonさんによる発表です。

github.com

  • 発表ざっくりまとめ

マクロはSwift 5.9から導入されたコンパイル時にソースコードの一部を生成する機能です。主にボイラープレートを減らすことを目的に利用されます。iOSアプリ開発の世界ではSwiftUIのプレビューを簡潔に行う「#Preview」や新しいデータ永続化のフレームワークであるSwiftDataのモデル定義を簡略化する「@Modelマクロ」などの標準のマクロが数多く用意されています。

マクロは有益ではあるもののマクロによって生成されるコードが多ければ多いほどエラーが発生する可能性は高まります。特にマクロを実装する場合は生成されるコードも対象に、Swiftの文法のあらゆるエッジケースを考慮して多くのテストを行うことが望ましいです。

しかし、マクロのテストも多くの課題があります。例えばマクロで生成されたコードのエラーや警告がXcode上からわかりにくく、 Apple標準のマクロのテストヘルパーの文字比較の判定がシビアでフォーマットなどの本質的ではない部分でテストが落ちてしまうという問題があります。また、マクロの実装が変わった場合はテストを修正する必要がありメンテナンスも大変です。

そこでPoint-Freeがswift-macro-testingというテストライブラリを公開しています。swift-macro-testingは検証したいマクロのソースコードをassertMacro()に書き込むだけでどのように展開されるかを自動でテストコードに反映します。

  • 感想

途中でライブデモがあったり、黒魔術的に生成されるテストコードを披露されたりとなんとなく会場も賑わっていた気がします。Androidにおいて自動生成を行うコードはたまに書くのですが、自動生成のコードをテストするというのは個人的に盲点で面白いなと思いました。

特に気になったセッション(三好編)

今回気になったセッションは、平和に大規模なコードベースを移行する方法です。

数あるセッションの中では、割と実用的ですぐに活用できるような内容でした。

セッション資料はこちら

drive.google.com

  • 破壊的変更を避ける方法
    • デフォルトパラメータを利用
      • メソッドを拡張するときに、パラメータを増やすとそれを利用する側すべての修正が必要になる
      • デフォルトパラメータを利用することで、利用する側の変更なく機能拡張することができる
    • protocol extensionを利用
      • プロトコルのメソッドを増やすと、それに準拠したclassやstructではそのメソッドを必ず実装する必要がある
      • protocol extensionを利用し、デフォルトの実装を定義することで、利用する側は変更なく機能拡張することができる
    • @availableの利用
      • 命名変更も破壊的変更になるため
      • Diagnosticのwarningを利用
    • enumの利用
      • caseが増えると、利用側でdefault実装がない場合変更が必要になる
      • non-frozen enumだと、@unknown defaultの定義が必要なので、破壊的変更は避けられる
      • しかし、non-frozen enumは開発者に提供されておらず利用できない
      • enumのcaseそれぞれをstatic letで利用できるようにする
    • Disfavoured Overload
      • @_disfavoredOverloadを使う
      • デフォルトパラメータを減らすなど
      • 機能削減での破壊的変更を避ける目的で使えそう
    • Finding Problem
      • swift package diagnose-api-breaking-changes [ブランチ名]
      • 上記コマンドで、指定したブランチの間で破壊的変更があるか教えてくれる
  • いつ破壊的変更を行うのか
    • 技術的負債とユーザーのイライラを天秤にかけた際に大きな偏りが生まれたとき

@_disfavoredOverload等存在自体知らなかったので、とても勉強になりました。

来年の開催すると思うので、ぜひ皆さんも参加してみてください。

特に気になったセッション(岐部編)

try! Swiftは4回目(2016,2018,2019,2024)の参加でした(2017年の記憶が曖昧なので、5回目かもしれない…)。

どのセッションも有意義でしたが、私は特に「Accessibility APIを使ってアプリケーションを拡張する」のセッションが非常に興味深く、サンプルアプリまで作りました。

1分にまとめたショート動画を用意したのでご覧ください。

時間の関係で動画中では詳細に触れていませんが、Accessibility APIを通して取得できる AXUIElement インスタンスには大きな可能性を感じました。このクラスのインスタンスには起動中の全アプリについての以下のようなウィンドウ情報が詰まっています。

  • アプリ名
  • ウィンドウのXY座標
  • ウィンドウサイズ

他のアプリのUIに自分のアプリが直接的に作用できるこの考え方は、Sandboxのcapabilityを取り除けるmacOSならではでとても面白いと感じました。

実際にユーティリティアプリ作る際は、以下のような手順で行いました。

  1. Xcodeプロジェクト新規作成、macOSアプリを選択
  2. まずはスライドにある設定を実施
    • capabilityからSandbox設定削除
  3. ContentViewを開いて雑に実装
    • 他ウィンドウの情報を埋める構造体と配列
    • 他ウィンドウの情報を集めるメソッド
    • 指定したウィンドウをアクティブにするメソッド
    • ウィンドウの背景を透明にするView
    • ホットキーを監視するメソッド
  4. これらを組み合わせて完成

以下のGitHubリポジトリで公開してあるので、ぜひ触ってみてください。
(あくまで検証用で作ったので粗は多いと思います…。PRもお待ちしております)

github.com

最後に

try!Swiftは世界中からiOSエンジニアが集まるイベントなので久しい友人に会えるのはもちろん、タイミーのエンジニアはフルリモートで働いているので普段WEBカメラ越しにしか話していない同僚とも対面で会話できて非常に楽しい期間でした。 この場を用意してくださった運営チームの皆さん、および会場でお話ししてくださった皆さんに心から感謝します。

上記で紹介したセッション以外にも非常に興味深いセッションが多くありました。 記事にある内容や、その他の内容についても、もしタイミーのエンジニアと話したいという方がいらっしゃればぜひお気軽にお話ししましょう!

product-recruit.timee.co.jp

JaSST'24 Tokyoに参加しました

タイミーの矢尻、須貝、razです。

ソフトウェアテストに関する国内最大級のカンファレンス「JaSST (Japan Symposium on Software Testing) ‘24 Tokyo」が2024/03/14、15の2日間にわたって開催されました。

jasst.jp

登壇時の様子

今回は我らがGo AkazawaとYorimitsu Kobayashiも登壇!その応援も兼ねてQAコーチ、エンジニア、スクラムマスターの3名が参加。世界中で開催されるすべての技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を利用しました。

productpr.timee.co.jp

本レポートでは、印象に残ったセッションの内容を中心に、2日間の会の様子をお伝えします。

噛みしめるほどに味わい深い「Making Quality Tangible」

今年の1月に入社したばかりの駆け出しQAコーチの矢尻です。

毎年楽しみにしているJaSST Tokyoに今年もオンライン視聴で参加しました。

視聴したすべてのセッションが示唆に富んだ学び多きものでしたが、中でもインパクトの大きかったGojko Adzic 氏による基調講演「Tangible software quality」の感想をお話します。

「Tangible software quality」を直訳すると、「具体的なソフトウェア品質」となります。

このセッションでは直接的にテストできないソフトウェア”品質”をプロダクトに”作り込む”ためのマインドセットやモデルが紹介されました。

セッションの最後に紹介された5つの「Making Quality Tangible(品質を具体化するためのガイドライン)」は、哲学的で難解ですが、噛みしめるほどに味わい深いものでしたので私なりに意訳して感想に代えさせていただきます。

  1. MEASURE PRESENCE, not absence(意訳:不在ではなく存在を測定せよ) 欠陥や問題点ではなく、実現された価値に焦点を当てることの重要性を強調されました。ポジティブな側面や魅力を評価することが、価値や魅力を感じるための鍵であると感じました。
  2. Describe multiple QUALITIES(意訳:複数の質を記述せよ) 内容に忠実な感想ではありませんが、例えば生活の質(QOL)のように健康・経済的安定・教育・職業・家族関係・文化的充足感など様々な指標で構成され、どれか一つが満たされていれば幸福というわけではないということに似ていると感じました。 ソフトウェアも同様に、使うひとが幸せであるための多様な構成要素を要求される水準で満たすことが重要と受け取りました。
  3. Trade-offs are a PRODUCT DECISION(意訳:トレードオフは製品の意思決定の一環である) 誰もがt_wada氏の「質とスピード」を想起したのではと思っています。 もちろん「質とスピード」の間のトレードオフは解決可能と私も思っていますが、ここでは網羅的なテストでリスクをゼロに近づけることではなく、どの品質特性がどの程度重要なのか重み付けをして、重要なものからバランス良くリソースを配分するのが重要と受け取りました。(「要はバランス」ですね)
  4. Shape priorities with a MODEL(意訳:モデルを用いて優先度を形成せよ) 製品の意思決定の一環として生じるトレードオフを判断する基準として勘は通用しません。ここでシンプルで有用なモデルとして「有用性」「差別化」「飽和点」から成るQUPER Modelと「マズローの5段階欲求モデル」が紹介されていました。

    QUPER model for better requirements

    Redefining software quality

  5. VISUALISE and ACT(視覚化して行動せよ) もうこれは字面通り「収集したメトリクスを根拠に行動せよ」ということかと思います。 (そういえば最近「見える化」って聞かなくなりましたね)

まさにタイミーでも価値あるソフトウェアを最速でデリバリーするためにチームトポロジー型の組織戦略を採用しています。価値に着目している点で同じ方向性のセッションだと感じましたので、今回紹介されたモデルやメトリクスは折に触れてチームで紹介し試していけたらと考えています。

異業種の品質保証から得られた学び

自動テストが好きなバックエンドエンジニアの須貝です。

JaSSTは初参加(オンライン視聴)でして、弊社の赤澤と小林の登壇を応援しようというのがきっかけでした。

全体を通して一番印象に残ったのはトヨタ自動車の長尾洋平氏による「自動車のソフトウェア品質に関する現場の試行錯誤」です。

自動車を制御するソフトウェアは数千万から数億行のコードからなっており、まずその規模と複雑さに驚きました。また、テストコードの品質にも規格があり、その質を担保するためにミューテーション分析などを活用しているそうです。

一方で実機テストの制約の多さに苦労されているとのことでこれは自動車ならではの悩みだなと思いました。テストのアプローチとしてQAが要件定義段階から関与するいわゆるシフトレフトを実践されている点も非常に興味深かったです。

また他のセッションですと「音楽の世界から学ぶ、ソフトウェア品質」は、プロ演奏者を招いて音楽とソフトウェアという無形のプロダクトの質について探る野心的な試みでした。

私はソフトウェアエンジニアという立場ですが、日々の開発では自身でもテストを行っているため、大変学びの多いイベントでした。

「アジャイル」「スクラム」が多く出てきたことに驚き

QAやテスト界隈がどんな感じなのか気になったので参加しましたスクラムマスターのrazです。

私もJaSSTに初参加(オンライン)でした。正直なところ、社内で参加希望者を募るまで、存在も知らなかったのですが、参加できてよかったです。

私も印象に残ったのは、トヨタ自動車の長尾洋平氏による「自動車のソフトウェア品質に関する現場の試行錯誤」なのですが、須貝さんが感想を書いてくださってるので割愛しておきます笑。

色々な発表を見させていただきましたが、全体的な感想として「アジャイル」や「スクラム」といったキーワードがたくさん出ていたのが驚きでした。ソフトウェアエンジニアがアジャイルなプロダクト開発に変化していった中で、QA組織やQAエンジニアがその変化へ適応していこうとしているように感じました。

その中でも「品質」について「誰のなんのための品質なのか」を考えているのが、とても良かったです。発表の中には「本当にその考えでいいのか?」という議論の余地はあったかもしれませんが、顧客中心に品質を議論する活動、それを継続するのは素晴らしいことだと思います。

弊社でも「顧客のための品質」について、もっと考えていければと思います。

おわりに

弊社は今回ゴールドスポンサーとして初めてJaSST Tokyoに協賛させていただきました。次回以降もなんらかの形で貢献して一緒にコミュニティを盛り上げていければと思います。

また、弊社ではQA、SETの採用も積極的に行っております。

hrmos.co

hrmos.co

タイミーのQA、ソフトウェアテストについてもっと知りたいという方はぜひカジュアル面談でお話しましょう。

product-recruit.timee.co.jp

dbt exposureによるデータ基盤アウトプットの登録を自動化しました

はじめに

こんにちは。okodooonです!!
データ基盤を参照したアウトプットが社内に溢れかえっていませんか?
弊社は追いきれていないLookerStudioやConnectedSheetがめちゃくちゃ溢れかえっていました。
そんな折、yoshidaさんの以下の記事を拝読いたしまして、今回の実装に至った次第でございます。

LookerStudioの記事 ConnectedSheetの記事
www.yasuhisay.info www.yasuhisay.info

面識ないですがこの場を以て感謝の意を表させていただきます!ありがとうございます!

課題感・背景

使用しているBIツールについて

弊社ではBIツールを数種類利用して、BigQueryデータ基盤上のデータを活用しています。
以下がその一覧とざっくりとした役割です。

  • Looker: 社内の主要な分析プロセスをカバーするセマンティックレイヤーを提供
  • LookerStudio: アドホックなレポーティング、Lookerでカバーしきれていない指標を用いたダッシュボード構築
  • GoogleスプレッドシートのConnectedSheet: スプレッドシート上でビジネスメンバーが作業する際のデータソースとしての使われ方
  • Redash: 元々LookerStudio同様の使われ方をしていた。ガバナンス向上とSSoT実現のために廃止作業中

Looker経由のアウトプットであれば、ソースデータに変更が発生したり社内の指標出力ロジックに修正が発生した場合に、ディメンショナルモデリング層で吸収したりLookerのContentValidator機能などでガバナンスを効かせることができます。
しかしBIツール側に直接クエリを書く形となるLookerStudioとConnectedSheetを用いたアウトプットの保守とガバナンスが問題となっていました。

BIツールの使用ボリューム感について

こんな感じのクエリで調査しています。

SELECT
    DISTINCT
    JSON_VALUE(protopayload_auditlog.metadataJson, "$.firstPartyAppMetadata.sheetsMetadata.docId") AS sheet_id,
FROM
    `example-project.bq_usage_logs.cloudaudit_googleapis_com_data_access_*`
WHERE
    protopayload_auditlog.serviceName = "bigquery.googleapis.com"
    AND JSON_VALUE(protopayload_auditlog.metadataJson, "$.firstPartyAppMetadata.sheetsMetadata.docId") IS NOT NULL
SELECT
  DISTINCT
  label.value AS report_id,
FROM `example-project`.`region-xx`.`INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION`,
UNNEST(labels) AS label,
WHERE label.key = "looker_studio_report_id"
  • 過去半年にクエリが走ったConnectedSheetの数: 600個強
  • 過去半年にクエリが走ったLookerStudioの数: 400個強

前述したロジックやソースシステム側の破壊的な変更への対応工数の観点以外にも、もう使われていないConnectedSheetに配信し続けている可能性などが考えられるため、まずはアウトプットを管理できる体制が必要であると考えました。

やったこと:概要

以下のような処理の流れを構築しました。

  • exposure登録情報を出力するviewをdbtで構成
  • 以下の処理をweeklyで実行
    • viewの結果を取得してexposureのyaml形式に変換
    • アウトプット単位でexposureのyamlファイルを作成
    • 未登録と変更があったexposureを登録するpull requestを作成

参考にしたブログから、弊社の運用に合わせて変更した点は以下です。

  • exposure単位でyamlファイルを作成する方針に変更しました
  • referenced tableにテーブル名ではなくdbtモデル名が入るようにしました
  • 各種アウトプットの公開設定をmeta情報として付与する方針としました
  • tagを追加してexposureの検索性を向上させました
  • exposureのnameにシートとダッシュボードのタイトルを反映する方針にしました

今回の実装によって以下のような形式のexposure用のyamlファイルが自動生成されます。

version: 2
exposures:
- name: {{ConnectedSheetタイトル}}_{{ConnectedSheetId}}
  label: {{ConnectedSheetId}}
  type: dashboard
  tags:
  - shared_externally
  - spreadsheet
  url: https://docs.google.com/spreadsheets/d/{{ConnectedSheetId}}
  owner:
    name: test@example.com
    email: test@example.com
  depends_on:
  - ref('hogehoge_model')
  - ref('foo_bar_model')
  - ref('chomechome_model')
  meta:
    visibility: shared_externally

やったこと:詳細

説明があるとわかりやすそうな部分の詳細を記載していきたいと思います。

referenced tableにテーブル名ではなくdbtモデル名が入るようにしたことについて

弊社はdbtモデル名とBigQuery上のテーブル名が一致しないため、INFORMATION_SCHEMAやaudit_logから取得したテーブル名をref関数化してもリネージュを作成できません。

そのため、dbtモデル名とBigQuery上の対応関係を取得するためにdbt-elementary実行時に生成されるdbt_modelsテーブルを活用しました。
このテーブルは

カラム名 内容
dbt_models.name dbtモデル名
dbt_models.alias BQテーブル名
dbt_models.schema_name BQデータセット名
dbt_models.database_name BQプロジェクト名

このような情報を持つカラム群を保持しています。
このテーブルを活用することでINFORMATION_SCHEMAが保持するBQテーブル名をdbtモデル名に変換してref指定することができています。

各種アウトプットの公開設定をmeta情報として付与する方針としたことについて

https://support.google.com/a/answer/9079364?hl=ja

google workspaceのactivityログを使うことで、LookerStudio,SpreadSheetの公開設定とタイトルを取得することができるので、それらを取得しています。

SELECT
    data_studio.asset_id AS report_id,
    data_studio.asset_name AS report_name,
    data_studio.visibility AS visibility
FROM example-project.google_workspace.activity
WHERE activity.data_studio.asset_type = 'REPORT' AND activity.event_name = 'VIEW'
SELECT 
    drive.doc_title AS sheet_title,
    drive.doc_id AS sheet_id,
    drive.visibility
FROM `example-project.google_workspace.activity` 
WHERE drive.doc_type = 'spreadsheet'

tagを追加してexposureの検索性を向上させたこと

dbt exposureはmeta, owner, typeなどの情報を使って、dbt lsコマンドなどでアウトプットを一覧することができません
dbt ls --resource-type exposure --type dashboard --owner example@example.com
みたいなことがしたいのですができないです。

そのため、exposureに対して適切なtagを付与することで絞り込みができるようにしました!

今回は公開設定,アウトプット種別の二つをtagとして持たせました。
これによって
「xxx_modelを参照しているshared_externally設定にしているスプレッドシート一覧を出したい」という要望に対して
dbt ls --select xxx_model+,tag:shared_externally,tag:spreadsheet --resource-type exposure
このようなコマンドで出力ができるようになります

exposureのnameにシートとダッシュボードのタイトルを反映する方針にしたこと

Add Exposures to your DAG | dbt Developer Hub

こちら公式Docにexposureのnameに指定するのはスネークケースにしてくださいという記載がありますが、なんとスネークケースにしなくても日本語名でも通ります!(名前をユニークにする必要はあります)
そしてexposure.nameがリネージュ上で表示される名前なので、データリネージュの可視性を高めるためにLookerStudioとコネクテッドシートのタイトルをnameに含む形で設定している状態です。

LookerStudioID, SpreadSheetIDだけをnameにすると、このようにデータリネージュ上でどのアウトプットのexposureかぱっと見判断がつかないのですが {{タイトル}}_{{ID}}の形式にすることでデータリネージュ上の可視性を確保した形です。

今後の発展

保守運用の設計

アウトプットが全件自動で管理されるようにはなったことで、「ソースシステムに影響が起きた場合」や「算出ロジックに変更が生じた場合」の影響範囲は迅速に把握できるようになりました。

しかし使われていないことがわかったアウトプットに対してどのようにアクションしていくのか、フローが組めていない状態です。
管理ができるようになった上でどのように運用改善に繋げるのか。どのように削除やdeprecatedにしていくのか。あたりのフローはしっかりと組んで、ユーザーの目に触れるアウトプットの品質の最大化に努めていきたいです。

カラムレベルリネージュ ✖️ exposure

dbt cloud enterpriseではカラムレベルのリネージュがexplore上で確認できるようになりました。
docs.getdbt.com 重要なアウトプットはBIツール側にクエリを書くのでなく、dbt側にそのアウトプット専用のマートを作成することで、カラムレベルでの影響範囲調査が可能となるのではと考えています。

before after

この図でいうbeforeからafterの構成に変えることでマートまではdbtで管理されるようになるため、dbt exploreのcolumn level lineageで可視化することで、カラムレベルでのアウトプットへの影響範囲を確認可能です。
こうすることで、「このテーブルに何かしら変更を加えたら最大でどのくらいの数のアウトプットに影響があるんだろう」から「このテーブルのこのカラムを消したらどのアウトプットに影響があるんだろう」まで影響調査の解像度を上げることができます。

こういった理由から、アウトプット専用マート作成の取り組みを始められたらなと思っております。
(column level lineageは現状dbt exploreで見ることができるだけですが、もうちょっと使いやすくなって欲しいです)

おわりに

yoshidaさんの記事を参考に少しだけカスタマイズしただけで、課題となっていたアウトプット管理の問題を解決することができました!
運用面などまだまだ磨き込んでいきたい部分は多分にありますが、この実装を通して社内ユーザーのデータ活用体験の最大化に繋げていきたいです!

アウトプットがいっぱい登録されました。(オレンジ色がexposure)

We're Hiring!!

タイミーではデータ基盤を一緒に開発してくれる仲間を募集しています!
お力をお貸しいただける方いらっしゃいましたらご応募お待ちしております!

データエンジニア hrmos.co

アナリティクスエンジニア hrmos.co

タイミーでデータアナリストとして働いた1年を振り返る

こんにちは!タイミーのデータアナリストの@yuyaです。

2020年にスマホゲームを運用する企業へ新卒入社をし、イベントプランナー兼データアナリストとして活動。2社目にECサイトを運用する企業でデータアナリストとして従事した後、2023年3月に3社目となるタイミーへ入社しました。入社からちょうど1年が経ったので、タイミーでのデータアナリストとしての働き方をこれまで自分が所属した企業と比較して、どうだったかについて振り返りたいと思います。

タイミーでの役割

まずは、私がタイミーでどのような役割を担っているデータアナリストなのかを記載したいと思います。

タイミーのデータアナリストチームは、大きく以下の3つの役割に分かれております。

  • プロダクトアナリティクス:プロダクトの機能開発に関わる分析
  • マーケティングアナリティクス:マーケティングに関わる分析
  • ビジネスアナリティクス:経営・事業活動に関わる分析

私は、ビジネスアナリティクスに所属しており、営業周りのデータ分析や店舗周りのデータ分析を主に行っております。

タイミーでの1年を振り返る

オンボーディング期

入社直後のオンボーディング期は、社内のデータ構造を理解しながら、データ抽出を行う依頼をこなしておりました。

タイミーでは、前述した3領域に関わらず、全社的にデータ抽出や簡単な分析をデータアナリストに依頼できるフローが存在しており、そこの依頼を担当することで、アプリ関連のデータ、マーケティング関連のデータ、営業関連のデータなど、タイミー内に存在する様々なデータ構造を理解し、使いこなせるようになるよう努めていました。

個人的に、これまで営業が存在する企業に所属したことがなかったため、営業関連のデータに触れることが新鮮で、分析領域としても1つ広がっていく感覚があり、非常に面白みを感じていました。

また、多くのデータが分析しやすいように整備されており、クエリを書くのが楽だったのも印象的でした。

ビジネスアナリティクス領域に配属

オンボーディング期が終わると、ビジネスアナリティクス領域に配属となりました。

私が配属された直後は、すでに社内での連携部署が定まっており、連携部署との間で分析テーマを決めて分析に取り組んでおりました。

当初取り組んでいたテーマとしては、「店舗の流入経路別のLTVの分析」や「新規導入に至るまでのファネル分析」、「CPの効果検証」などのように、課題の特定や戦略に関わる部分の分析から施策の効果検証まで幅広く様々な分析を行っておりました。

初めて営業関連の分析に着手する中で一番苦戦したのが、「どのデータが使えるのか?」を明確にするところでした。

前職と前々職では、アプリやマーケティングのデータを分析しており、基本的に自動でデータ収集されている状況でした。しかし、営業関連のデータは、営業の方が手動でデータを入力しないといけないため、たとえデータとしてカラムが存在していたとしても、データを入力している人としていない人が存在していたり、チームによって若干運用方法が違っていたりしていたため、現場への確認が必要でした。

今あるデータからどんなインパクトが出せそうかを考えるのも大事ですが、そもそもどのようなデータをきちんと収集していくと良さそうなのか、それをどうやったらきちんと収集できるようになるのかを考えていくのも重要そうだなという気づきを得ました。

営業組織が変革し、連携部署を再検討する

ビジネスアナリティクス配属から約半年後、営業組織が変革されるイベントが発生しました。

これを機に、改めて「データアナリストとして、どのような動き方をすると価値を最大限発揮できるのか?」を考えていくことになります。

こちらについて、まだ明確な結論は出ていないものの、現状の営業組織の解像度を上げる(どこでどのような人が関わり、どのように意思決定が行われ、どのように影響していくのかなどを明確にする)ことで、データアナリストとしてインパクトを与えていける動きができそうかの仮説を一定立てられるところまでは来たかなと思っております。

これまで所属していた企業(チーム)が、20名程度と100名程度であったため、特に意識しなくてもどこで誰が何をしているか理解できていたのですが、タイミーのように組織も急成長を遂げ、規模も1,000人を超えてくるような大きな組織になってくると、きちんと現場の状況をキャッチアップしにいく動きをすることが重要なのだなと改めて気付かされました。

最後に

これまで、時系列的にどのようなことを行っていたのかを簡単に紹介してきました。

タイミーは、現在サービスも組織も急成長中であり、環境が目まぐるしく変わっていっており、都度都度その変化に適応していく必要があります。そのため、チームとしても明確な型のようなものが存在しているわけではなく、常に「どのように動くことが一番インパクトが出せるのか?」を考え、状況に合わせて柔軟に動き方を変えていく必要があるなと感じています。

これまで所属した企業では、良くも悪くも、データアナリストとしての動き方がすでに固まっており、教えられた動き方をするだけで、自然とインパクトも出せるような環境でした。そのため、組織として自分がどのように振る舞うことが一番インパクトが出せるのかを考える機会があまりありませんでしたが、タイミーでは、日々そのようなことを考えるため、視野を広げる良い機会になったかなと思っております。

組織が急拡大する中で、カオスなことも多いですが、これまでにない経験から得られる学びや気付きが多く、タイミーに転職して良かったなと感じております。

We’re Hiring!

私たちは、ともに働くメンバーを募集しています!!

カジュアル面談も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。

【イベントレポート】チーム分割においていかれたアラートをチームで責任を持てる形に再設計した

イベント概要

2023年12月5日に「Next Year Con for SRE〜来年の登壇を応援する勉強会〜」と題してSREに関するトピックでタイミー、ココナラ、ビットキー、マジックモーメントの4社合同で勉強会を開催しました。 その中でタイミーバックエンドエンジニアの岡野さん(@Juju_62q)の講演をイベントレポートにまとめてお届けします。

チーム分割においていかれたアラートをチームで責任を持てる形に再設計した

自己紹介&想定聴衆

2020年にタイミーに入社し、現在では3年半ほどエンジニアをしている岡野と申します。 主にストリームアラインドチームの機能開発を担当しており、その一方でサイトリライアビリティエンジニアリングも行っています。

想定聴衆

  • 「よくあるアラート」に困っているエンジニア
  • 組織分割を考えているEMやCTO
  • EnablingをやっていきたいSREs

今日お話しないこと

  • どのようなアラートを設定すべきなのか
  • アラートから繋がるオンコール対応周辺の話

アラートとFBサイクルとチーム

私が最も優れていると考えるアラート(右の図)は、問題が発生したら、エンジニアが問題を解決すると宣言し、リカバーするアラートです。理想的には、問題が自動的に解決することが望ましいですが、今回の話の範囲では、アラートの責務を超えていると捉え、理想的なアラートの形をこのように考えています。

次によくあるアラート(左の図)は、CPU使用率がN%を超えると、エンジニアが介入せずとも時間と共に回復したり、500エラーがy回を超えると何もせずとも回復するようなアラートです。このようなアラートは、時間が経過すると自然に解決し、次第に無視されがちです。

本来アラートはアクションを要求するための通知であるべきであり、アクションなしにアラートが鳴ることは無意味です。実際にタイミーにも、このような無駄なアラートが長期間存在していました。

現状、完全な解決には至っていませんが、タイミーがアラートを少しずつ改善した話を共有していきます。

タイミーではどのようにして「よくあるアラート」ができたのか

前提条件
1. 開発と運用を同じチームでやっていること
タイミーでは、CTOが開発と運用を一つのチームで行うことを重視しています。CTOが好んでいるチームトポロジーの書籍では、「運用は開発への最大のフィードバック源である」と述べられており、私たちの組織でもこれを大切にしています。

2. エンジニアはアラートがなっていることを好ましく思っていないこと
エンジニアはアラートが鳴る状況を好ましく思っていません。行動を起こすかどうかは別として、アラートが鳴っていること自体は好まれていませんでした。

3. エンジニアは機能開発以外にある程度の時間が使えること
タイミーのエンジニアは、10%から20%の時間を技術改善に充てることができます。実際には、少なくとも10%の時間をこれに割り当てることが求められています。

2〜3年前、我々のチームは以下のような横割りの構造でした。

  • バックエンドチーム
  • Webフロントエンドチーム
  • モバイルチーム

これらのチーム間では、バックエンドチームがアラートの設定を行い、障害経験を基にアラートシステムが構築されました。この時期には、ユーザー数も少なく、アラート対応の難易度も低めでした。赤く表示されるアラートに対しては、チーム文化として積極的に対応していました。

しかし、この横割り組織では、一つのチームだけで機能を完全に提供することが難しく、これが課題となりました。そのため、職能を横断する縦割りの組織構造への移行を進めました。この新しい形では、モバイルやWebフロントエンドなど、異なる専門分野のメンバーが同一チームに所属するようになりました。

ただし、この組織変更の際に、アラートシステムの見直しは行われず、バックエンドエンジニアが引き続きアラートの責任を担うことになりました。

アラートが鳴った際の反応はどうだったかというと、以下のような反応が一般的でした。

Aチーム「アラート鳴ってるけど、よくわからんな」 Bチーム「アラート鳴ってるけど、うちのチームとは関係無さそう」

チーム間で分断されていると、特定の機能についてどのチームが対応すべきかの判断が難しくなります。特に、人員が増加するにつれて、過去の経緯も失われ、このような問題は増えていきます。

いつも鳴ってるし今日も大丈夫だろう

『いつも鳴ってるし、今日も大丈夫だろう』という感覚が常態化すると、アラートが頻繁に鳴るようになります。アラートが放置され、対応が行われないため、アラートの数は増加の一途をたどります。

改善したいけどハードルが高そう

仮に意欲的なエンジニアが現れても、「何とかしたいが、どう変えればいいかわからない」という状況に陥りがちです。Aチームの同僚は協力的ですが、Bチームは相対的に距離があるため、意見を述べるのが難しいと感じることがあります。同じ会社に属していても、日常的に顔を合わせていない人に対し、合意を得る必要があるかもしれないという懸念が生じます。

なぜこのようなことが起こるのか

なぜこのような状況が発生したのか、その原因を考察します。

アラートの作成は元々、バックエンドチームが責任を持って設定していました。当初、アラートに対するフィードバックはバックエンドチームに集中しており、このチームだけでアラートの削除や修正が行われていました。しかし縦割り組織への移行後、アラートに関するフィードバックは複数のチームに分散し、単一のチームだけでの削除や修正が難しくなりました。アラートに対する対応が不明確になり、長期間勤務している経験豊富なメンバーに相談することや、アラートに関する変更の承認を得るまでのプロセスが必要になることもありました。このように、フィードバックが機能しなくなった結果、アラートの数は増加し、特に新入社員にとっては理解しづらいものとなりました。この状況が、「よくあるアラート」の誕生に繋がったのです。

「よくあるアラート」を改善するためにしたこと

結論を述べると Aチーム・Bチームそれぞれにフィードバックと意思決定権を与えました。

具体的な行動

  • 各チームで対応の必要があると思われるアラートを選んでもらう
  • アラートに対してチームメンションをつける
  • アラートはメンションのある単一チームで変更していいと周知する
  • アラート対応に関する振り返りを実施

各チームで対応の必要があると思われるアラートを選んでもらう

すべての問題を即座に解決するのは難しいため、Slackに「問題なし」または「問題あり、オンコール対応が必要」というコメントを残すことを最低限行うことにしました。このとき、多くのアラートのうち、選ばれなかったアラートは一旦すべて削除しました。

アラートに対してチームメンションをつける

次に、アラートに対してチームメンションをつけることにしました。以前はアラートにメンションがなく、全てのチャンネル通知をオンにする運用でしたが、これではどのチームが対応すべきか不明確でした。そこで、アラートにメンションを付与し、「このメンションのチームがオーナーです」と伝えるようにしました。

メンションのある単一チームで変更していいと周知する

次に、バックエンドのアラートに関しては、バックエンドチーム全体の許可がなければ変更できないと考えられていました。しかし、メンションのある単一チームでの意思決定による変更を推進しました。これにより、各チームは素早く意見を反映できるようになりました。

アラート対応に関する振り返りを実施

最後に、アラート対応に関する振り返りを実施しました。最初の改善はできるだけサポートするため、メンション付きのアラート対応について1ヶ月後に第1回の振り返りを各チームで行いました。これは、必要に応じて2回、3回と続けました。この流れで、チーム内での改善が少なくとも1回行われるところまで改善できました。

今、どのような変化があったのか

現在、アラートシステムにおいて以下のような変化が生じています。

アラートに反応する人やチームの増加

アラートに反応する人数やチームが明確に増えました。

アラートの定期的な変更や見直し

アラートに対応しないと自分たちが困難な状況に陥るため、変更や見直しを定期的に行うようになりました。

Runbookの整備

チームごとにRunbookが整備され、アラート対応のプロセスが民主化されています。この分野にはまだ改善の余地があると感じていますが、良い変化が見られていると思います。

これらの変化により、「よくあるアラート」から徐々に脱出していると感じています。ただし、不要なアラートが多いことや、復旧の自動化がまだ十分ではないことは、今後の大きな改善ポイントです。

まとめ

  • アラートは組織構造とFBを受ける人が不一致の場合に機能しなくなっていく
  • アラートは単一チームで変更の意思決定ができないと硬直化する
  • 組織が変わった際に、アラートの組織に合わせて変更するのが大切

最後に、アラートシステムのまとめです。アラートは、チームの構造とフィードバックが不一致になると、効果を失ってしまう可能性があります。フィードバックを受ける人々が明確でない場合、アラートの機能性が低下する傾向があります。またアラートに関しては、「単純接触効果」のとおり、日常的に顔を合わせる人々に対して意見を伝えやすいことが多いです。そのため、単一のチームで意思決定ができない場合、アラートシステムは硬直化しやすいと思われます。

結論、組織が変化した際には、アラートシステムの構造も組織の形態に合わせて変更することが重要です。

その他の方の発表も気になる方はこちら!

www.youtube.com

少しでも興味を持っていただいた方は是非こちらからカジュアルにお話しましょう!

devenable.timee.co.jp

【イベントレポート】YAPC::Hiroshima 2024に参加しました

はじめに

こんにちは、タイミーでバックエンドエンジニアをしている新谷須貝難波です。

2月10日に広島国際会議場YAPC::Hiroshima 2024 が開催されました。タイミーはGold Sponsorとしてブース出展をしており、エンジニアが3名とDevEnable室が3名の総勢6名で参加させていただきました。

どのセッションも興味深かったのですが、この記事では我々が拝見したセッションのうち特に印象に残ったものをいくつかピックアップしてご紹介します。

なお、タイミーには世界中で開催されている全ての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、エンジニアはこれを使って参加しております。詳しくは下記のリンクをご覧ください。

productpr.timee.co.jp

経営・意思・エンジニアリング

speakerdeck.com

普段我々が行なっているソフトウェア開発の延長線上に CTO の仕事があるよ、という発表でした。経営者が物事をどう捉えているのかを垣間見ることができ、個人的にはベストトークでした。

ソフトウェア設計と組織設計が相似的なアーキテクチャであるということはコンウェイの法則などもあることから直感的に理解できましたが、事業設計とも相似的なアーキテクチャであるという話はまだピンときていないのでまたどこかのタイミングでお伺いしたいと思っています。

また、意思が重要という話はプロジェクトを成功するためには強い意思を持つ推進者が必要不可欠という点で共感していました。ただ、プロジェクトが短期間で終わるものであれば良いのですが、ある程度期間のかかる類のものは個人の意思では難しいこともあるかと思っていて、そういったものはどう対処しているんだろうとも気になりました。

短期的成果の重力に負けないよう、これからのプロダクト開発を行なっていきたいと思います。

(新谷)

関数型プログラミングと型システムのメンタルモデル

speakerdeck.com

コンピュータアーキテクチャに近い手続き型プログラミングから関数型プログラミングへメンタルモデルを変えていこう、という発表でした。私は普段 Ruby on Rails でアプリケーション開発をしていて関数型プログラミングとは距離があるのでとても興味深く聞かせていただきました。

オニオンアーキテクチャは DI ができるとかモックが可能とかが重要なのではなく、手続き型言語の考えに引き摺られがちな I/O の部分を業務ロジックから切り離し、業務ロジックに対して別のパラダイムを適用できるようにするのが本質という話を聞き、なるほどと勉強になりました。

一方、関数型プログラミングが Web アプリケーションのバックエンドに本当に適用できるのかはまだイメージが湧いていないのが正直なところではあります。質疑応答で質問をさせていただいて RDB の書き込みに相当する I/O の部分は Repository 層に閉じ込めるという話は納得したのですが、Web アプリケーションは本質的に並行処理だと思っていて、リクエストを処理している最中に状態が書き換わることをどうやって純粋な関数で表現するのかが気になっています。

懇親会で確定申告の話と一緒に質問しようと思っていたのですが残念でした…

(新谷)

変更容易性と理解容易性を支える自動テスト

speakerdeck.com

自動テストの目的は

信頼性の高い実行結果に
短い時間で到達する状態を保つことで、
開発者に根拠ある自信を与え、
ソフトウェアの成長を持続可能にすること

という結論からスタートし、その結論に向かって一つずつ解説していく内容でした。

この目的は極限まで削れば「ソフトウェアの成長を持続可能にすること」だと私は思います。これだけだと飛躍があるので一つずつ順を追っていくと、まずソフトウェアの持続可能な成長には変更容易性(変更しやすい)と理解容易性(わかりやすい)が必要です(ないとツラい)。そして変更による既存機能への影響を知る手段のひとつに自動テストがあります。また、自動テストには既存コードの理解を助ける役割もあります。もちろんただ自動テストがあればよいわけではなく、良い自動テストが必要です。

ではどうすれば良い自動テストを書けるのかという話になるわけですが、ここで私が思い出したのは「単体テストの考え方/使い方」(Vladimir Khorikov 著、須田智之 訳)です。

この本の「4.1 良い単体テストを構成する4本の柱」で以下の4つの要素が挙げられています。

  • 退行(regression)に対する保護
  • リファクタリングへの耐性
  • 迅速なフィードバック
  • 保守のしやすさ

目的で挙げられた「信頼性の高さ」は「退行に対する保護」(偽陰性からプロダクション・コードを守るもの)と「リファクタリングへの耐性」(偽陽性の数を最小限に抑えるもの)であり、「短い時間で到達する状態」は「迅速なフィードバック」に相当します。そして「信頼性の高い実行結果に短い時間で到達する状態を保つ」ためには「保守のしやすさ」が欠かせません。つまり冒頭の二行に良いテストの条件がすべて凝縮されていたのです。

発表にあった「実行結果は情報」という指摘には良いフィードバックの重要性も感じました。また、Googleのテストサイズの話なども非常に勉強になりました。今回のセッションをきっかけに改めて自動テストの目的に立ち返り、自分たちがより根拠のある自信を持ってコードを書けるようにしていきたいと強く感じています。

最後に余談ですが、発表の中で気になったことを懇親会でtwadaさんご本人に直接質問できたのはオフラインイベントの醍醐味だなとしみじみ感じました。

(須貝)

非同期な開発体制を支えるドキュメント文化

speakerdeck.com

時差のあるメンバー同士でも適切にコミュニケーションを行うために Launchable, inc.で実際に行われているドキュメンテーションの事例を紹介頂く内容でした。

発表の中で特に印象に残ったものを3つほど挙げさせていただきます。

  • フィードバックの平等性
  • 検索性の意識
  • ドキュメントの型化

まず「フィードバックの平等性」についてです。組織にいるメンバーは多様であり聞いた話について素早く考えて話すことが得意な人もいればじっくり考えたい人もいます。また組織内公用語として使われている言語が第一言語でない人もいます。そういった場合に同期的なMTGでやり取りすると議題に対するフィードバックを行う人が偏る傾向があり、またフィードバックの観点も偏りがちです。非同期にフィードバックをもらうようにすることでこの課題の対策としているというのは良い視点だと思いました。なお、タイミーでも参加者が多い一部のMTGでは議事録のドキュメントにフィードバックの欄があり、またMTGの録画を行うことで非同期にフィードバックを行いやすい運用をしていたりします。

次に「検索性の意識」についてです。ドキュメントをしっかり残すことは非同期か否かに関わらず非常に良い文化であり実践している組織も多いと思いますが、ドキュメントが増えると必然的に起きるのが検索性の悪化です。タイミーではドキュメンテーションにNotionを使用しているのですが、閲覧したいドキュメントがなかなか見つからなかったり、見つかったドキュメントが実は古いものだったといったことはどうしても発生します。その対策としてまず部門ごとにConfluenceのspaceを分けているとのことでした。他部門の情報が簡単に閲覧できるという透明性は重要ではあるものの、それは権限管理をしっかりやれば解決できることです。また積極的にアーカイブ(≠ 削除)を行うことでデフォルトの検索設定では検索にヒットしないようにするという話もあり、これはその通りだと思う一方でそれを組織文化とするのは一朝一夕では無いなと感じます。

最後に「ドキュメントの型化」についてです。ドキュメントが一定のフォーマットに準じて作られていれば書き手にとっては書くべき情報が漏れにくいですし、読み手にとっても慣れれば慣れるほど要点を理解しやすくなります。また適切なフィードバックを受けるための30/60/90% framework for feedbackについても勉強になりました。これはドキュメントのフェーズに対して適切なフィードバックを行おうというもので、普段から意識してはいたもののそういった名前が付いていたことは知らなかったので今後のコミュニケーションの際に使おうと思います。そして関連資料のドキュメントへの記載です。ドキュメントを書く際は何かしら参考にした別のドキュメントというものがある場合が多いですし、書き手にとっては自明でも読み手にとってはそうでない場合も多いです。こういった資料のリンクを書き手だけでなく、読み手も積極的にドキュメントに残していこうというのは今後より意識していきたいです。

(難波)

杜甫々さんのキーノート

あの日あの場にいたことを自慢し続けようと思います。

(須貝)

おわりに

YAPCは長く続いているイベントですが、今回エンジニアで参加したメンバーは初参加だったり9年ぶりの参加という感じでした。それでもYAPCの和やかな雰囲気とPerlに関係するテーマもそうでないものも受け入れている包容力で皆大変楽しむことができ、また勉強になったカンファレンスでした。

来年以降もまたスポンサーや参加ができればと思います。

最後にランチとして配られた広島名物のあなごめしの画像を貼って終わりとします。