少人数制でLookerの講習会をやってみた話

はじめに

こんにちは！タイミーでデータアナリストをしているhatsuです。

私は普段、タイミーの営業戦術などについての分析に携わるほか、社内でのデータ利活用を推進する取り組みを行っています。

今回は、社内のデータ利活用推進に取り組む中で、これまで定期的に開催していたBIツールの社内講習会の運営方法を見直した話をご紹介したいと思います。

従来のLooker講習会における問題点

タイミーでは、社内のデータ利活用推進のため、LookerというBIツールを導入しています。

このLookerというツールをより多くのメンバーに活用してもらうため、これまでにも社内でLookerの使い方をレクチャーする講習会、通称「Looker講習会」を定期的に実施してきました。

従来のLooker講習会はオンラインのウェビナー形式で、40~90人ほどの人数を対象に実施していました。

しかし、講習会実施時にとったアンケートや、社内メンバーとの会話の中で、従来のLooker講習会には以下のような問題点があることがわかりました。

• 受講者側の問題
  • 大人数（40~90人程度）の前だと質問しにくい
  • 講習会の内容についていけない
  • 説明の途中に質問をしにくい
• 講師・運営側の問題
  • 受講メンバーからのリアクションや質問が受け取りにくく、説明が伝わっているかがわからない

Looker講習会はLookerの基本的な使い方をマスターするための講習会であり、受講者もLookerをほとんど使ったことがないメンバーが大半を占めます。

そのため、講習会の内容が基礎的なものであってもつまずく受講者は多く、それゆえ「質問しにくい」という現状は看過しがたいものでした。

少人数制のLooker講習会の概要

これらのLooker講習会の問題点を解消するために、参加人数を10人以内に絞った少人数制のLooker講習会を開催してみることにしました。

参加者の人数を少なくすることで質問する際のハードルが下がり、講習会の内容についていけない受講者のサポートをしやすくすることが狙いです。

また、参加人数以外にも、開催方法をオンラインからオフライン（対面）に変えました。

講習会をオフラインに変えることにより、受講者のリアクションを汲み取りやすくなるほか、講習会に付いていけていない受講者を講師側のサポートメンバーが個別にサポートできるようになると考えたためです。

さらには、従来の講習会用の資料に沿って進めるのではなく、実際にLookerの操作画面を見せながら操作方法を説明するように講習会の内容も少し変更しました。

これにより、受講者は自分のLooker操作画面と講師のLooker操作画面とを見比べながら操作を覚えることができます。

少人数制Looker講習会をやってみた結果

新しい方式でLooker講習会を実施したところ、講習会の途中にも質問が飛び交い、従来のオンラインでの講習会よりも講師と受講者のコミュニケーションをとりながら講習会を進めることができました。

また、オフラインでの開催だったため、隣の座席の受講者同士で教え合う様子なども見られ、置いてけぼりの受講者が従来より生まれにくくなった手応えを感じました。

実際、講習会後にとったアンケートでも「ちゃんと初心者向けでついていけた」「初歩的な質問でもすぐに回答頂けたので、とても理解できた」などの感想が多く見られました。

Looker講習会の今後

今回実施した少人数制のLooker講習会にも、まだまだ課題は残っています。

例えば、現在の方式では一度に少ない人数しか参加できないので、社内全体へLookerの使い方を広めるには講習会の回数を重ねる必要がありますし、講習会をオフライン開催のみにしてしまうと、地方支社に所属するメンバーにLookerの使い方を学ぶ機会はなかなか提供できません。

これらを解決していくため、今回の少人数制のLooker講習会の取り組みを踏まえ、今後も継続してLooker講習会の運営方法の改善を続けていこうと考えています。

We’re hiring!

タイミーでは、一緒に働くメンバーを募集しています。

https://hrmos.co/pages/timee/jobs

カジュアル面談も実施していますので、少しでも興味を持っていただけましたら気軽にご応募ください！

学生向けに講演する中で考えた、データサイエンティストの仕事像と未経験就職

こんにちは、タイミーでデータサイエンティストとして働いている小栗です。

先日、群馬大学にご招待いただき、大学生向けにキャリアに関する講演を行いました。

講演や学生との交流を行うにあたり、データサイエンティストの仕事やキャリアについて考える時間が自然と発生しました。

この記事では、学生からいただいた以下の質問をテーマに据えて、私やタイミーの事例を紹介しつつ考えてみます。

• 大企業とベンチャー企業のデータサイエンティストはどう違う？
• 未経験からデータサイエンティストを目指すには？

「チームで育てるAndroidアプリ設計」の輪読会を行いました

はじめに

こんにちは、タイミーでAndroidエンジニアをしているsyam(@arus4869)です

昨年、「チームで育てるAndroidアプリ設計」という本について、計10回にわたって輪読会を実施しました。本書は「アーキテクチャとチーム」に焦点を当てた一冊になっており、タイミーのAndroid組織の技術顧問としてさまざまなサポートをしてくださっている釘宮さん（@kgmyshin）が著者として名を連ねている本になります。

この記事では、技術顧問の釘宮さんとAndroidメンバーでの輪読会で得た学びをシェアできたらと思っています。

輪読会の説明

週に1回テーマを設けてAndroid会という勉強会を実施しています。

勉強会の中では、miroを利用した輪読会を実施しています。

輪読会は参加者の「感想」や「勉強になったこと」を共有し、「わからなかったこと」、「話してみたいこと」について議論しながら深掘りをし、学びを得ています。

学びと実践への応用

セクションごとに学びがありましたが、特に実践へ応用された部分について抜粋して紹介しようと思います。

アーキテクチャを図にしてREADMEに見える化しました。

第2章の中にある多層アーキテクチャの例が非常に参考になったので、今のタイミーのアーキテクチャはどうなっているかも気になり、miroを利用した輪読会ならではの「その場で図にする」というワークを行いました。

下記は輪読会中に実際に図を描いた様子です。

Miroのワークの様子

タイミーでは、４層アーキテクチャから３層アーキテクチャに変遷した歴史があり、今もレガシーコードとして残っているので、新旧のアーキテクチャをREADMEに記載することにしました。この時に明確にできたおかげで、新規参画者への説明のハードルが下がり、輪読会の議論がとても良いきっかけになりました。

下記は輪読会で図にしたものを改めて整理して、READMEに記載したものです。

アーキテクチャの構成図

モジュールごとにREADMEを用意することにしました。

本書の第３章ではアーキテクチャの理解と適用を促進し、チームの生産性向上にどう貢献するか紹介されていました。特に理解の促進のためには、アーキテクチャの概要図やパッケージ構成、各層、クラスの説明をドキュメント化することが推奨されており、チームでもREADMEに記載することになりました。 また輪読会の中では、モジュールにも説明が必要ではないか？と議論が発展しモジュールの説明も各モジュールごとに用意することになりました。

モジュールについての議論

タイミーのAndroidアプリでは、Featureごとにモジュールを分割しているので、モジュール数が多岐に渡っており、モジュールの解釈に認識齟齬が発生するリスクがありました。モジュールに対してもREADMEを記載するアプローチを生んだのは、良い議論に発展したおかげだと思います。

また、モジュールの書くべきことについては、本書に書いていない内容だったので、筆者の釘宮さんに改めて確認することができたのは、筆者が参加する輪読会ならではでとても有り難かったです。

終わりに

タイミーでは定期的に輪読会を開催しております。

輪読会では、本を読んでただ学ぶだけでなく様々な議論がおこなわれ新しい洞察を発見する場となっています。

本輪読会で取り扱った「チームで育てるAndroidアプリ設計」についても新しい洞察が得られ実際に実務への応用に発展しました。是非一度よんでみてください！

少しでもタイミーに興味を持っていただける方は、ぜひお話ししましょう！

product-recruit.timee.co.jp

Ruby 3.3.0+YJIT本番運用カンパニーになりました

こんにちは。バックエンドエンジニアの須貝（@sugaishun）です。

今回はタイミーが本番運用しているRailsアプリケーションに対してRuby3.3.0へのアップデートを行った（YJITは引き続き有効なまま）のでその結果をご紹介したいと思います。

昨年弊社のid:euglena1215が書いたエントリーのRuby3.3.0版です。

tech.timee.co.jp

前提

タイミーのWebアプリケーションとしての特性は基本的には昨年と変わりありません。ですので、昨年の内容をそのまま引用させてもらいます。

タイミーを支えるバックエンドの Web API は多くのケースで Ruby の実行よりも DB がボトルネックの一般的な Rails アプリケーションです。JSON への serialize は active_model_serializers を利用しています。

今回の集計では API リクエストへのパフォーマンス影響のみを集計し、Sidekiq, Rake タスクといった非同期で実行される処理は集計の対象外としています。

今回はRuby3.2.2+YJITからRuby3.3.0+YJITへアップデートを行い、パフォーマンスの変化を確認しました。

結果

以下のグラフはAPIリクエスト全体のレスポンスタイムの50-percentileです。

グレーの点線がアップデート前の週で、青い線がアップデート後の週になります。集計した期間ではアップデート前後の平均でレスポンスタイムが10%高速化していました。

今回も前回にならってレスポンスが遅く、時間あたりのリクエスト数が多いエンドポイントに注目し、タイミーのWeb APIのうち3番目に合計の処理時間が長いエンドポイントへのパフォーマンス影響を確認しました。

以下のグラフは3番目に合計の処理時間が長いエンドポイントのレスポンスタイムの50-percentileです。こちらも同様にグレーの点線がアップデート前の週で、青い線がアップデート後の週になります。集計した期間ではアップデート前後の平均でレスポンスタイムが約12%高速化していました。

またECSの起動タスク数にも良い変化がありました。

タイミーではCPU使用率が一定の割合になるようにタスク配置する設定をしているのですが、リリース後は起動タスク数が減りました。リリース前後1週間の比較で下記のように変化しています。

• 平均で33.1 tasks → 30.36 tasks
• 最大値で58.6 tasks → 53.0 tasks

このあたりはYJITの効果でリクエストに対するCPU負荷が下がった影響ではないかと推測しています。メモリ上に配置した機械語を実行するJITならでは、という感じがします。コスト的にどれだけインパクトがあるか具体的な数値は出せていませんが、パフォーマンス以外のメリットもありそうです。

と、ここまでは良かった点です。

以降では自分たちが遭遇した事象について述べたいと思います。

一部のAPIでメモリ使用率が増加

タイミーのRailsアプリケーションはモノリスですが、ECS上ではネイティブアプリ向けのAPIとクライアント様の管理画面向けのAPIはそれぞれ別のサービスとして稼働しています。前者のネイティブアプリ向けAPIでは特に問題なかったのですが、後者の管理画面向けAPIではメモリ使用量の最大値が約3倍超（20%弱→65%程度）になりました。以下のグラフの赤いラインがRuby3.3.0にアップデートしたタイミングになります。

さすがに3倍超は困ったなと思い、YJITのREADMEを読んだところ下記のようにありました。

Decreasing --yjit-exec-mem-size

The --yjit-exec-mem-size option specifies the JIT code size, but YJIT also uses memory for its metadata, which often consumes more memory than JIT code. Generally, YJIT adds memory overhead by roughly 3-4x of --yjit-exec-mem-size in production as of Ruby 3.3. You should multiply that by the number of worker processes to estimate the worst case memory overhead.

We use --yjit-exec-mem-size=64 for Shopify's Rails monolith, which is Ruby 3.3's default, but smaller values like 32 MiB or 48 MiB might make sense for your application. While doing so, you may want to monitor RubyVM::YJIT.runtime_stats[:ratio_in_yjit] as explained above.

メタデータ(yjit_alloc_size)の増え方が想定以上なのではと思いつつ、ddtrace*1ではyjit_alloc_sizeは送信していないようなので、code_region_size を確認。実際、YJITのcode_region_size(JITコードのサイズ)とメモリ使用率はほぼ同じ動きをしていました。以下のグラフの左がcode_region_sizeで、右がメモリ使用率です。

というわけで--yjit-exec-mem-sizeをデフォルトの64MiBから32MiBに減らしたところ、メモリ使用量はアップデート前より少し増えた程度の水準まで抑えることができました。なお、この変更によるパフォーマンスへの影響は見られませんでした。

以下の右のグラフがメモリ使用率で、赤いラインが--yjit-exec-mem-sizeの変更をリリースしたタイミングになります。実際にメモリ使用率が下がっているのが見て取れます。

今回のメモリ使用量の大幅な増加は完全に予想外で、ステージング環境でもメモリ使用量の変化はウォッチしていましたが、特に大幅な増加は見られず本番環境で初めて発覚する事態になりました。すでにRuby3.2系でYJITを有効にしているプロダクトでも、Ruby3.3.0+YJITにアップデートされる際には--yjit-exec-mem-sizeの値には注意したほうが良さそうです。

まとめ

Ruby3.2ですでにYJITを有効にしているプロダクトでもRuby3.3.0にアップデートしてパフォーマンスの改善が見られました（YJITの影響なのかそれ以外の最適化による恩恵なのかまでは検証しておりません）。

すでにYJITを有効にしていた場合でもRuby3.3.0へのアップデートでメモリの使用量が大幅に増加する可能性があるので注意しましょう。

調査の際には下記の（主にk0kubunさんの）ドキュメントに非常に助けられました。この場を借りてお礼を申し上げます。

github.com

k0kubun.hatenablog.com

gihyo.jp

本エントリーがこれからRuby3.3.0+YJITへアップデートされる方のお役に立てば幸いです。

*1:タイミーはDatadogを使っています。ddtraceはDatadogにメトリクスを送信するgemです

【Front-End Ops／イベントレポート】「いつか来たる大改修のために備えておくべきn個のこと」

イベント概要

2024年2月21日に「GENBA #2 〜Front-End Opsの現場〜」と題してタイミー、Sansan、ココナラ、X Mileの4社でFront-End Opsに関する合同勉強会を開催しました。 今回はそちらの勉強会からタイミーフロントエンドエンジニアの西浦太基さんの発表をイベントレポートでお伝えします。

こんにちは、西浦 太基です。家族で北海道札幌市で暮らす33歳です。 Javaでキャリアをスタートし、今はフロントエンドエンジニアとして3年目になります。趣味はカレー作りとゲームです。

本日は「いつか来たる大改修のために備えておくべきこと」について、実際に大きな改修を経験して学んだこと、泥臭い現場の話や反省点を、エピソードベースでシェアします。

1. どんな大改修だったか

店舗向けの管理画面をシングルページアプリケーション（SPA）へ移行する改修でした。もともとサーバーサイドレンダリング（SSR）で構築されていたシステムを、ReactとNext.jsを使用したSPAに段階的にリプレイスしていきました。改修した機能は大きく下記3つです。

1. 求人機能（作成/編集）
2. 求人ひな形機能（作成/編集）
3. メッセージ機能（一覧表示／送信）

2. 泥臭かったこと

既存機能の仕様調査に苦労 既存のSSR画面の詳細なドキュメントが残っておらず、非常に苦労しました。これは、タイミー入社前のSler時代もよく経験したことで、 “あるある” なのですが、状況を打開するためには非常に泥臭い調査が必要です。もちろんドキュメントが全く残っていないわけではなく、Figma や Notion に部分的に残されてはいたのですが、完全にはカバーされていません。おまけにソースコードの情報が必ずしも正確でないこともあり、かなりの時間と労力をかけ、調査を行いました。

E2E自動化の仕組みがなく、431件のE2Eテスト項目に自動テストを実施した

ユニットテストはコンポーネント単位で存在していましたが、E2E自動化の仕組みが存在しませんでした。VRT（Visual Regression Testing）は、Storybook を用いて行われていたのですが、今回のプロジェクトの規模や顧客への影響を考えると、軽い検証を行うだけではリスクが大きいと判断し、結果的に 431件の E2Eテストを手動で泥臭く実施する道を選びました。

レビュー体制がなく、レビューコストが大きくなった

当時のフロントエンドチームはレビュー体制の整備が不十分で、メンバーも限られており、レビューコストが高くなってしまいました。チームは僕を含めてわずか2人と、非常勤の業務委託1人。レビューに十分な時間を確保するのが難しく、プロジェクトの進行に影響が出ていました。そのため、レビューを効率的に進めるために、一人のエンジニアの時間をまとめて確保し、一気にレビューを完了させる方法を取りました。本来は、フルリモートでの非同期レビューを行える体制が理想的だと思います。

3. 備えておくべきと感じたこと

機能の仕様は背景込みで残しておく 詳細なソースコードコメントや定義書があれば、将来の改善に役立ちます。特に複雑な機能や多くの入力項目を持つ場合、実装の背景を理解することで、後々の改善が容易になり、属人化を避けることができます。最近は、Figma や Notion に仕様と背景を含めて記録するよう心がけています。

自動化テストの仕組みを導入する

これまでUTやVRTが充実していれば、そこまでE2Eは重要ではないと考えていました。しかし、今回のリプレイスを経て、自動化テストの重要性を再認識しています。E2Eによって、UTで検知できない問題をリリース前に特定できることがあり、改めてE2Eの重要性と自動化の利点を実感しました。

レビュー時の観点を整備

• レビューの文化を根付かせておく
• 同時にレビュー時の観点や視点に関してチーム内で明文化
• ドキュメント化することで普段からレビューコストを下げておく

レビュー文化をしっかり根付かせつつ、レビューのポイントをチーム内でしっかりドキュメント化しておくことが大事です。ドキュメント化してないと、都度のすり合わせで時間を取られ、レビューコストが増えます。その結果、リリースサイクルも遅れたりするわけです。現在はフロントエンドチームの拡大もあり、レビュールールを明文化する作業を進めています。

まとめ

私がSler時代に直面した、「ソースコードを見なければ仕様が理解できない」といった “あるある” な内容も含め、日頃から大きなリプレイスに向けた心構えや備えが必要性を共有できたら嬉しいです。泥臭い作業を発見したら、悲観的になるのではなく「これは考え直すタイミングだな」というマインドを持つことも大切かと思います。

• n個と言いつつそこまで数は挙げられなかった
• 日頃から大規模リプレイスに備えた心構えをしておくことは大事
• （何が起こるかもわからないので）かもしれない運転
• あるあるな内容になったと感じている
• Timee以外のプロジェクト（SES就業時代）でも直面した事が多かった
• 泥臭いこと゠備えておくべきこと、に繋げるマインドが大事に感じた

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

www.youtube.com

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

devenable.timee.co.jp

言語処理学会第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