Timee Product Team Blog

タイミー開発者ブログ

yykamei が Regional Scrum Gathering Tokyo 2025 に参加してきました

はい、亀井です。 yykamei という名前でインターネット上ではやらせてもらっています。所属はタイミーです。

今回、 Kaigi Pass という制度を利用して Regional Scrum Gathering Tokyo 2025 (RSGT 2025) にボランティアスタッフとして参加させていただきました。ShinoP さんと takakazu さんに「RSGT 2025 でボランティアスタッフをやるのですが、スタッフでも Kaigi Pass 使えます?」と相談したところ「いいね!」というお声がけをもらい、晴れて Kaigi Pass を利用して参加することができました。お二人に感謝。

Day 0

RSGT への参加自体は今回が2回目です。2回目の今回はスタッフとしての参加で「なんもわからん」という状態で若干の不安を抱えながら Day 0 を迎えました。

この Day 0 というのは、つまり「前日」の意味ですね。 RSGT 自体は 2025 年 1 月 8 日に始まりますが、その前日からいろいろと活動をするわけです。

Day 0 の日に会場についたところ、誰かから「ここはふわっと始まるんで」と言われ、たしかに、「ふわっと」作業が始まりました。到着時点ですでになんらかの作業をしていたメンバーが数人いたのですが、やることがわからないので観察するしかありません。観察していると、だんだんと「なるほど、これをここに持っていくのね」「ブースの荷物を持っていくのね」などがわかってきますし、「誰か◯◯をやってー」という感じのヘルプ(指示ではない)が発生するので慣れないながらもそういう作業をします。

とはいえ、今回のボランティアスタッフはそれなりの人数がいらっしゃったようで、すぐに誰かがなにかしらの作業をしてくれるので、やはり観察する時間が長かったです。

Day 0 のメイン作業といえばノベルティーの準備でしょうか。参加した方はわかるかもしれませんが、トートバッグみたいなものがそれぞれに配られます。

その中にステッカーだったりペンだったりが含まれていますが、そうした内容物をトートバッグに入れる、という単純な作業を行なっていました。これ、それなりに大変でして、現地参加者の数が結構いらっしゃいますので単純に量が多くて大変です。

ただ、そこはさすがというべきか、スタッフがこの単純作業の中で自分の役割を見出し、途中から流れるようにノベルティーが完成していきました。まさしく自己組織的な何かを垣間見たような気がします。

ノベルティー準備の様子

この単純作業の最中にトラブルもありまして、作業がいい感じにスムーズに進み始めたあとに「これもトートバッグに入れる必要がでましたー」ということになり、その時点まで完成させていたノベルティーをもう一度点検してやり直す羽目になりました。こういうスクラム関連のワークショップ、ありますよね。もう擦られ続けた VUCA というワードですが、こんなところにもその片鱗が見えました。

Day 0 では、夕方以降に Speakers Dinner というものが開催されました。こちらは登壇者とスポンサーの方々、そしてスタッフが和気藹々と話す場です。やはりここも「ふわっと」始まります。ただし、会場を借りている時間の関係もあるので終了時間はきっちり守ります。それが終わったら各々二次会などに行っているようでした。

Day 1

そして、いよいよ Day 1 を迎えます。ここからが本番ですね。 Day 1 での主な私の役割は Room B での部屋付きです。The way through data to quality “Measuring Quality”Untangle your team with a new approach. (プロポーザルの段階では "A new innovative way to manage the complexity of a team.” でしたが、タイトルを変更したようです))という二つの登壇を担当しました。

これらの登壇は海外から来てくれたスピーカーがやってくれたので、メイン言語は英語でそれを日本語に通訳してくれます。質疑応答についても日本語で質問をすれば英語に通訳され、英語で質問されれば日本語に通訳される、という感じで通訳の方々が大活躍する現場です。

また、通訳の皆さんは別の部屋で行うので、もしスピーカーや質問者がマイクを使わずに話してしまうと通訳の方々にオリジナルの音声を届けられず、部屋付きは意外と気を抜けません。当初は「のんびり登壇を聞いていようか」ぐらいに思っていたのですが、部屋付きに入ると「これは参加者や登壇者の満足度に影響しそうだ」ということに気づきました。

そのため、マイクに音が入っているか確認しながら会場の様子に気を配る、ということをしたので、登壇内容はほとんど理解できませんでした。あとで録画を見ようと思います。 Untangle your team with a new approach. という登壇をしてくれた Teemu に同じ部屋付きだった松下さんが「Last name はどうやって発音するの?」と聞いていてさすがだな、と思いました。その問いに対して Teemu は「そうなんだよ。みんな、このスペルからは発音の仕方がわかる人はなかなかいないよね」的なことを回答していました。部屋付きだと登壇者とこういう会話ができていいですよね。

Day 2

Day 2 も引き続き部屋付きでした。この日の担当は Cowtopia: Designing Agility Through Playful Innovation で、こちらはワークショップになります。 1 時間 40 分の時間を使ったワークショップでクネビンフレームワークを体験してチームを改善していくためにはどうすればいいのか?というような内容だったように思えます。部屋付きで見ていると参加者同士で交流をされていてとてもよかったですね。登壇を聞くのもいいですが、ワークショップに行くと半ば強制的に人と交流することになってそれはそれで Gathering ができてよいのではないでしょうか。

Day 2 にもなってくるとスタッフ業もだんだん慣れてきてようやく廊下を楽しむ、ということができるようになってきました。ただ、人と話している時にもトランシーバーの音声に注意していたので 100% 会話を楽しめたか?というとそこは課題がありそうです。

次回、チャンスがあればいかにうまくトランシーバーを扱っていくか?ということを研究したいと思います。そういえば、 Day 2 で正義さんに「30 秒ピッチやりたいんですけどどこに行けばいいですか?」と質問され「え!なにそれ!?」という感じで Confengine を見たところたしかに “Lunch Time (with 30 seconds pitch from anyone @ Terrace Room)” というのがあり、あわてて実行委員の永瀬さんに聞きに行きました。

そしたら永瀬さんも「え!なにそれ!?」という感じで急遽連携を取り合ってなんとか 30 秒ピッチを開催することになりました。スタッフの新さんがきっちり 30 秒はかって、肉声でドラを叩くということをやってくれて急ごしらえの割には面白いコンテンツになったのかもしれません。

Day 3

Day 3 はメインホールで Open Space Technology (OST))を行い、事前に募集している人たちは別の部屋でワークショップに参加する感じです。この日は特に私に役割があったわけではないのですが、とりあえず、 OST の部屋で入り口付近にみなさん座りがちだったので、奥のほうに誘導していました。

OSTが始まるときの様子 — 円形に並んで座ります

OST は始まるタイミングでは全員が円形に並んで座ってインストラクションを聞いて、各自持ち寄りたいトピックを書いていくのですが、その円形の並びがどうしても手前に偏ってしまったんですね。その偏りの修正をやっていました。 OST が始まる前に OST の寸劇があったのですが、私は廊下にいたので見られませんでした。あとで録画を見て楽しもうと思います。

OST では相変わらず熱量を持った参加者がテーマを持ち寄り、いたるところで活発な議論が行われていたようです。熱量が凄すぎてその日は寒かったはずですが、会場内は熱気が凄かったですね。私はなんとなくフラフラしていたのですが、途中から furoshiki.fm のテーマについてのテーブルにお邪魔しました。実はリスナーなのですが、ここぞとばかりに「お世話になっております」というフィードバックを出させていただきました。これが役に立つのかわかりませんがこれからもファンでいさせていただこうと思います。

Day 3 の OST とワークショップが終わるといよいよクロージングキーノートです。本間さんのお話です。最初の導入部で、現在、本間さんがされている子供たちとのお仕事の話をします。「ホンダの話じゃなかったっけ?」と思ったのですが、この導入部がないと実はホンダでのワイガヤの話がすっと入ってこないんです。ある意味焦らすような感じなのですが、全体を通して振り返ってみると「めちゃくちゃいい話だな!」という感想になります。さすがです。

ホンダの話になってくると City の開発の裏話?的なお話がされますが、とにかく「ワイガヤ」というのがキーワードですね。そして、本間さんは最後のほうで RSGT の OST に「ワイガヤ」を見出していただいたようで、ちょっと嬉しいですよね。そういえば、先日 Slack の Huddles を使ったプラクティスとその背後にある考え という記事を書きましたが、このワイガヤにも通じるな、と一人でにっこりしておりました。

まとめ

ということで、つらつらとボランティアスタッフとしての RSGT 2025 を書いてみました。ボランティアスタッフだとあまり RSGT を楽しめないかも?などと思っていたのですが終わってみるともう一度やりたいな、という気持ちになっています。

スタッフとしての仕事に慣れてくるとだんだんカンファレンス全体を俯瞰して見られるようになりわずか 4 日ながら自分の成長を実感しました。こんな感じで正統的周辺参加をしてコミュニティーに関わっていくのか、と実感しております。

オーガナイザーとスタッフの皆さんで最後に記念撮影

より信用できる効果検証のためにA/BテストとDIDの仕組みづくりをした話

こんにちは。タイミーのデータアナリティクス部でデータアナリストをしている亀山です。担当業務としては、主に営業部門のデータ分析を行っています。

今日はA/Bテストと※DIDの効果検証がより信用できるように仕組みづくりをした話を紹介したいと思います。

※DID(Difference in Differences、差分の差分法)は、ある施策の実施前後で、影響を受けたグループ(比較群)と影響を受けなかったグループ(対照群)の変化を比較することで、介入の効果を推定する手法です。

取り組んだ背景

以前同じ部署の夏目さんがブログで取り上げている通り、データアナリティクス部では過去に、効果検証の事前設計と結果を管理できるような仕組みを作成しました。その後、効果検証のテンプレートは多く使用されるようになり、知見も貯まってきましたが、残課題としては以下がありました。

  • 汎用性の高いシンプルなテンプレートを作成したため、A/Bテストなど特定の手法を駆使した効果検証では入力項目に不足がある
  • 特定の効果検証の手法も積極的に使っていきたいが、手法に関する知識が人によって差があるため、効果検証のクオリティにばらつきが出てきてしまう

やったこと

今回は、これらの課題を解消するために、よく使われる効果検証の方法論のドキュメント化とその手法に特化したテンプレートの作成を行いました。

  1. よく使われる効果検証の方法論のドキュメント化

社内でよく使われる効果検証としてA/BテストとDIDがあげられたため、それらの方法論のドキュメント化を行いました。

ドキュメントは以下のようにNotion上にデータベースを作成して、A/BテストとDIDが一覧ですぐに参照できる形式にしました。

A/BテストとDIDの方法論のデータベースの一部

これらのドキュメント整備で工夫した点は2点あります。一つ目は概論や設計方法だけでなく、社内事例を参照した解説まで記載したことです。ただの効果検証手法の説明であれば、ネット検索をすれば参照できますが、社内事例も含めることで、タイミーで行う効果検証だからこそ、考慮するポイントなどを記載しました。

二つ目は社内事例の解説の箇所で、Pythonなどのサンプルコードも記載したことです。説明だけでなくサンプルコードも載せることで、コードの転用につなげ、作業効率の向上を図りました。

  1. 特定の手法に特化したテンプレートの作成

A/BテストとDIDのそれぞれの手法に特化したテンプレートも作成しました。背景でもお話しした通り、それまでのテンプレートは汎用性が高くシンプルな形式でしたが、今回作成したテンプレートはそれぞれの手法ならではの入力項目を追加しました。

例えば以下の画像のように、A/Bテストならば「Randomizeの単位」や「割り当てタイミング」などA/Bテストで考慮すべきポイントをテンプレに含ませるようにしました。

まとめ

新しいテンプレートを作成してから2ヶ月弱経ちましたが、従来のテンプレートに加えて、今回作成したテンプレートも使ってもらえているようです。今後の展望としては、他の効果検証の方法の追加や既存のドキュメントのブラッシュアップも行っていき、より信用できる効果検証を行える仕組みを作っていきたいです。

また、個人的な感想ですが、私はDIDを担当することで、今までの知識の整理ができてとても良かったです。知識は入れるだけでなく、外に出すことも必要だなあと思います。今後もインプット・アウトプットを繰り返すことで、自身の分析スキルも引き上げていきたいです!

We’re Hiring!

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

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

カジュアル面談も実施していますので、少しでも興味を持っていただけましたら気軽にお申し込みください!

pmconf2024に参加してきました

タイミーのプロダクトマネージャー(以下、PM)の 柿谷(@_kacky)、 高石(@tktktks10)、吉池、大歳 です。

今回は、タイミーの「Kaigi Pass」制度を利用し、12/6にオンサイト開催されたプロダクトマネージャーカンファレンス(以下pmconf)のDAY2に参加してきました。

この制度を通じて、非常に有意義な学びを得ることができましたので、その内容を共有します。

2024.pmconf.jp

productpr.timee.co.jp

プログラム概要

  1. パネルディスカッション

    テーマ:「プロダクトマネージャーと仮説/戦略」

    登壇者:FoundX 馬田さん、Zen and Company 宮田さん

  2. OST(Open Space Technology)

    参加者持ち込みテーマでのディスカッション

  3. 懇親会

    他社のPMと交流するネットワーキングの場

パネルディスカッションからの学び

「プロダクトマネージャーと仮説/戦略」というテーマで行われたセッションでは、戦略の現状や仮説構築におけるポイントが深く掘り下げられました。

戦略のコモディティ化

宮田さんが指摘した「戦略のコモディティ化」という現状に対し、差別化の重要性が議論されました。タイミーにおいては、プロダクトマネジメントや戦略を担う立場でもあるため、プロダクトマネージャーがどこにエッジを立てるべきかを再考するきっかけとなりました。

仮説構築の重要性

宮田さんは、仮説は地道なインプットを重ねた結果として生まれるものであり、見栄えの良さを求めるべきではないと強調していました。また、日本のプロダクトマネージャーが海外事例を十分に収集せず、国内のプラクティスに偏っていることや、議論テーマが数年間変化していない点に警鐘を鳴らしていました。

近年は、ChatGPTのようなツールやX(Twitter)を活用して、海外の著名なPMの投稿や事例を簡単に収集できる環境が整っています。

私自身も、海外事例を意識的に取り入れる姿勢を持ちたいと感じました。

AI経済の構造改革

馬田さんからは、書籍『AI経済の勝者』のフレームワークを用い、AIを活用した3つのソリューションレイヤー(ポイントソリューション、アプリケーションソリューション、システムソリューション)についての説明がありました。特に、リスクを取りながらシステムソリューションレイヤーに挑戦し、構造的な変革を進めることの重要性が強調されていました。 AIを前提とした新しいルールや戦略については、まだ理解が浅い部分も多いため、該当の書籍を読み、知識を深めたいと思います。

productpr.timee.co.jp

OSTでのディスカッション

OSTセッションの開始に先立ち、pmconfスタッフから進行方法の説明がありました。その後、会場から話したいテーマを募り、16の分科会に分かれて合計3回のディスカッションが行われました。

それでは、実際に、我々が参加したOSTで取り上げられたトピックに触れたいと思います。

プロダクトマネジメントに関する海外事例や書籍について知りたい

このテーマでは、パネルディスカッションで取り上げられた海外事例をもとに議論が行われました。プロダクトマネジメントにおけるプロセスや役割の定義など、海外事例をどのように参考にし、実践しているのかが話題に上りました。しかし、参加者の環境や事業フェーズ、提供するサービス内容が異なるため、議論は各自の事例紹介にとどまりました。

さらに、プロダクトの海外展開時におけるPMの役割や、プロダクト開発体制、国内と海外のカルチャーの違いへの対応についても議論が広がり、非常に興味深い内容となりました。

LLMの活用事例

「LLMの活用事例」では、以下の点について議論が行われました。

  • AI投資の方向性:

    トップダウンで進める企業が多い一方、エンジニア主導でボトムアップに進めるケースも見られました。特にアーリーフェーズでは投資家の影響が強く、AIへの投資は手段が目的化しているように見える場合もありました。

  • ROIの課題:

    ROIの可視化が難しい中でも、AIへの投資は不可欠であるという意見が多く出ました。

個人的には、どんなユースケースで活用できるのか考える営みは、プロダクトマネージャーとして最低限要求されるべきなのかなと思いました。改めて、自社のプロダクトマネージャーや戦略部門のメンバーとも議論してみたいなと思いました。

リテンション施策の効果検証

「リテンション施策の効果検証がしづらい」というテーマでは、多くのPMが同じ課題を抱えていることが分かりました。他社のPMからは、データアナリストが充実している弊社の環境について羨ましいという声をいただき、自社の強みを改めて実感しました。

一方で、効果が測れない施策については、測定の努力を続けながらも「やるべきことを決める仕組み」が重要だと考えています。

BtoBtoCのプロダクトはCにどのように向き合うか

多くのBtoBtoCプロダクトにおいては、キャッシュポイントがBにあるためにCに対する体験改善がどうしても後回しになってしまう課題感について各社の意見交換が行われました。

各社の知見を寄せ集める中で「Cの声を現場までインタビューしにいく」ようなすぐできるアプローチから「Cの体験が良くなることでKPIが達成され、売上があがるようなビジネスモデルに変更する」といった根源的なアプローチまで、さまざまなアイデアが生まれました。

個人的には、顧客が満足するポイントとキャッシュポイントの距離の近さは、優秀なビジネスモデルを構築する上で重要な要素の一つだと考えています。今後自分がプライシングに関わることがあれば、意識したいですね。

メンバーへのスケジュール意識を高める

PMとしてはスピード感を持ってプロジェクトを進めていきたいと考えているが、その温度感・危機感のようなものがどうもチームメンバーに伝わらない….。そんな課題について掘り下げるグループでした。

会話の中では「そもそもどうしてスケジュール感が必要なのか」といった課題の発端について意見交換が行われ、

  • 経営陣がプロジェクトの進捗に不透明さを感じており状況を把握したいため
  • 顧客の不便を早期に解消したいため
  • 確定申告など、1年に1度しか訪れない外部イベントに間に合わせる必要があるため

など、多種多様なきっかけがあることが分かりました。

基本的なアプローチとしては、PMが情報を包み隠さずチーム全体で情報の非対称性を減らしていくことが大事そうです。しかし、元の課題によっては単にチームの計画をオープンにしたり、開発する機能のスコープを削ったりと、スケジュール意識を高める以外の解決方法もありそうだと感じています。

非エンジニアPMの生存戦略

「非エンジニアPMの生存戦略」では、以下の点について議論が行われました。

  • 活躍するために必要なケイパビリティについて

    まずは圧倒的に自身の強みであると言えるだけのスキルや経験、ドメイン知識を獲得すること。その自身の強み=ケイパビリティが顧客価値の拡大に寄与する実績を積み上げて深さを出すこと。そのあとに、抽象化と転用でケイパビリティをさらに広げていくと良い、という意見がその場の総論となりました。

  • 結局、エンジニア経験を積むべきか?

    主張の一つとしては、見積もりに対する妥当性評価をするためにも一定のエンジニア経験は積むべきという意見がありました。 しかし、その意見は内製の開発組織ではなく、発注元企業の企画担当と請負または準委任の受託企業の関係性を前提としているものでした。ビジネスパートナー関係による利害関係が発生する場合についてであったため、PM とエンジニアが同じ顧客に向かって利害関係なく動く組織においては、必ずしもエンジニア経験は必要ではないといった対比の意見も出ており、開発体制や文化、事業フェーズなどによるという結論となりました。

PM組織の構造

「PM組織の構造」では、以下の点について議論が行われました。

  • 事業部制における PM 組織のあり方

    事業部長がトップにいる中での PM 組織におけるレポートラインの妥当性 (CPO といった機能職種としてのトップより PL 責任を持つ事業部長のキャリアしか道がなさそう)と、その組織のマネージャーの振る舞いをどうするかといった議論がなされました。 事業フェーズや経営上、事業上の課題により適切な組織デザインが思考されるべきで、一義的なものはないという意見が多く出ました。

懇親会での交流

懇親会では、他社のPMとリアルに交流する機会がありました。Xで知っていた方々と直接話せたのは特に有意義でした。数年ぶりに再会する方もちらほらいたりして、楽しい時間でした。

異なる環境や課題を持つ企業の話を聞くことで、自社の環境や課題を相対的に捉え、視野を広げる良い機会となりました。

最後に

今回のカンファレンスを通じて、多くの刺激を受けると同時に、自分自身のキャリアや現在の課題について深く考える時間を持つことができました。特に、大量のインプットを通じて質の高い仮説を構築する重要性や、AI時代におけるプロダクトマネージャーの役割について再認識しました。

Kaigi Passを活用して得たこの学びを、今後の業務にしっかり活かしていきたいと思います。

【イベントレポート】Go See!で見つけるプロダクト開発の突破口

イベント概要

12月17日(火)にpmconf 2024のサイドイベントとして「Re:cycle〜pmconf 2024編〜」を開催しました! このイベントはReject Conライクなイベントとして通過しなかったプロポーザルをアップデートして発表することをコンセプトにIVRyさん、DMMさんとの共催で開催しました。

今回はこの勉強会からタイミーのプロダクトマネージャーである大嶋さん(@ta0o_o0821)の発表を書き起こしイベントレポート形式でお伝えします。

オープニング

お品書き

続きを読む

RBS に出会って変わった Ruby への向き合い方

目次

はじめに

こちらは Timee Product Advent Calendar 2024 の24日目の記事です。

前日は @beryu の iOSの職能チームが存在しない組織で、WWDCハッカソンを企画・開催しました でした。

こんにちは。バックエンドエンジニアの @dak2 です。

タイミーではバックエンドの Ruby on Rails アプリケーションに型定義情報(RBS)を記述して運用しています。

もう少し具体的に話すと、rbs-inline を利用して RBS ファイルを生成し、Steep によって型検査しています。後半で詳しく説明します。

自分はタイミーに Join するまで RBS に触れたことがなかったので、Ruby で型を記述するという体験が新鮮でした。

型を記述して運用する中で Ruby への向き合い方が変わってきたなあと感じているので、今回はそれを文字に起こしてみたいと思います。

RBS について

RBS とは Ruby のプログラム構造、いわゆる型を記述する言語のことを指します。

Ruby ファイルとは別に .rbs という拡張子のファイルにクラスやモジュールの型を記述します。

class Foo
  def bar(str)
      "#{str}"
  end
end
class Foo
  def bar: (String) -> String
end

簡単な例ですが、上記のように foo.rb のクラスに対して、foo.rbs ファイルに RBS を書いて型定義ができます。

*詳細は公式リポジトリを参照してください。

rbs-inline と Steep について

rbs-inline & Steep は、弊社のフルタイム Ruby コミッタである soutaro が開発している gem です。

rbs-inline はコメントとして型を記述できます。このコメントをもとに RBS ファイルが生成されます。

下記左のようにメソッド上部にコメントを追記して、rbs-inline コマンドを実行すると右のような RBS ファイルが生成されます。

class Foo
    # @rbs (String) -> String
  def bar(str)
      "#{str}"
  end
end
class Foo
  def bar: (String) -> String
end

*詳細は公式リポジトリを参照してください。

Steep は Ruby の型検査器であり、実装と型宣言に矛盾がないかをチェックします。

上記のような RBS を記述した上で steep check コマンドを実行すると型チェックをします。

Steep は VSCode での拡張機能もあり、関数ホバー時に型定義を教えてくれたり、メソッドの補完や型エラーになっているコードを赤の下線で示したりしてくれます。

メソッド補完

未定義メソッドのエラー

*詳細は公式リポジトリを参照してください。

ちなみに、弊社バックエンドのテックリードである shintani が Steep のエラーリファレンスをまとめた記事があるので、興味がある方はご覧ください。(自分もちょくちょく見ています)

RBS に出会ってからの Ruby への向き合い方

自分の所属している Working Relations Squad というチームでは Done の定義の一環として、インクリメンタルな差分に対しては必ず rbs-inline を記述するようにしています。

*Done の定義の話について詳しく知りたい方は、こちらの記事を参照してください。

rbs-inline を記述して型を意識することで、Ruby への向き合い方が変わったなあと思う点を下記に挙げてみました。

  • 単一の型を返す意識がついた
  • メソッドの戻り値の型だけを見て実装する機会が増えた
  • Ruby で型を書くのも良いなと思った

単一の型を返す意識がついた

自分は戻り値の型が単一の方が扱いやすいと考えています。

その方が呼び出し側で戻り値の型ごとにハンドリングしなくて良いし、メソッド自体の再利用性も高まると思っています。

rbs-inilne を書くまではぼんやりとそういった意識はあったものの、あまり意識できていなかったように思います。

rbs-inline を書くことで、自分が追加したメソッドの型を定義するようになり、自然と戻り値の型がどうあるべきかに対して明確に思考が向くようになりました。

メソッドの戻り値の型だけを見て実装する機会が増えた

Ruby を記述していると、このレシーバってこのメソッド使えるんだっけ?と思ってメソッドの中身を再度読みに戻った経験はありませんか?もしくはテストを見に行ったり、場合によってはコンソールで Object#class を実行して確かめたりなど。自分は何度もあります。

既存メソッドの中身を確認することはあるのですが、詳細まで深く確認するというケースは少し減ったかなと思っています。

メソッドなどの型情報を主なインターフェースとして捉え、呼び出し側で利用するみたいなケースが増えたなと。

Ruby で型を書くのも良いなと思った

良いか悪いかは別として、「メソッドの戻り値の型だけを見て実装する」ことで、余計な情報を知らずに済むようになってきて、本当に実現したい処理に集中しやすくなりつつあるなと思っています。

この状態は理想的で、やりたいことにフォーカスできると Ruby の高い表現力を活かして素早く価値提供できるんじゃないかと思います。

過去に TypeScript などで型を書いてはいましたが、型の意義が自分の中で腹落ちしていませんでした。デフォルトで型付けしないといけない世界線だとそれが当たり前だったので、Ruby の世界との差分が大きくてうまく解釈できていなかった感覚があります。

ですので、それまでは型を書くというのがただ退屈な作業に感じていましたが、“型のある” Ruby を書くことと、”型のない” Ruby を書く体験差分を通じて、上述したように型の意義が自分の中で腹落ちしてきたなと思っています。

「Ruby に型なんかいらないんじゃないかな?」と思ってた自分が、型の恩恵を受けた世界線はより Ruby の表現力にフォーカスできるんじゃないかと思い直していて、Ruby への向き合い方がまた一つ変わったような気がします。面白いなあ。

これからも型やっていき!の精神で書いていこうと思います。

明日は @naoya の 「【iOS】Live Textを活用した画像解析 です。」お楽しみに!

統計検定準1級(CBT)で、最優秀成績賞をいただいたので勉強法を紹介します

Timee Advent Calendar 2024 23日目の記事です。

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

先日、統計検定準1級に合格し、最優秀成績賞をいただきました🌸

弊社からは別のアナリストがすでに統計検定準1級の合格体験記を出してくれていますが、合格体験記はあればあるだけ良いと思うので、私も書こうと思います。

受験の動機

  • 社会人7年目で文系職からデータアナリストに転向しましたが、やはり専門性で周囲に後れをとっていると感じ、統計の知識を早急に身につけたいと考えていました。
  • 取得した資格は履歴書などにも書けるため、アナリストに転向してから早い段階で取得しておけば、自身のLearnabilityを証明する一助になる、という打算的な動機もありました。

学習開始時の状況

  • 文系職からデータアナリストに転向して2年目
  • 1年ほど前に統計検定2級を取得済み
  • 一応理系の学部卒だが、数学が苦手で、積分や行列の計算はほとんどできない状態に戻っていた

今回は、そんな自分の統計検定準1級対策についてご紹介します。

数学に苦手意識のある方の参考になれば幸いです。

具体的な学習方法

1. ワークブックを写経する(80時間程度)

統計検定準1級の勉強は「日本統計学会公式認定 統計検定準1級対応 統計学実践ワークブック」が主軸になると思いますが、こちらの内容をすべてノートにまとめ直しました(まとめ直すといっても、ほぼ丸写しです)。

ワークブックの内容は、数学や統計の知識が浅い自分には少しハードルが高く、軽く目を通しただけでは内容があまり入ってきませんでした。

このままワークブックを読むだけでは理解が深まらないと判断し、とりあえず手を動かしながら理解を深めることにしました。

ワークブックは300ページ以上あり、大変そうに思われるかもしれませんが、トータルで見るとコスパは良かったと思います。

1日1時間でワークブック3〜4ページ分を目安に、約3ヶ月かけてまとめ終えました。

あくまで自分が手を動かして理解することが目的であり、ノートを見返す必要はないと割り切って、綺麗さよりもスピード重視で進めました。

写経だけで内容を完全にものにできるわけではありませんが、この後の理解の進み方が大きく違ったように思います。

実際のノートの一部です。

2. 統計検定準1級に必要な前提知識のおさらい(10〜20時間程度)

  • 部分積分や行列式、固有値など、ワークブックに出てきたものでわからないものがあれば、ネットで例題を探して解いていきました。
    • ワークブックに取り掛かる前に予習しておく必要はなく、ワークブックの問題を解くうえでわからないものがあれば、その都度調べる程度で良いと思いました。
  • 最初はギリシャ文字の読み書きも怪しかったため、スマホの待ち受け画面をギリシャ文字の一覧表にしていました。
    • 読み方のわからない文字があると、内容もなかなか頭に入ってこないため、放置しない方が良いと思いました。

3. 問題集を解く(50時間程度)

  • 公式問題集(過去問)とワークブックの問題を2〜3周しました。
    • YouTubeにワークブックの解説動画を上げてくださっている方がいらっしゃり、大変理解が捗りました(URL)。
  • 試験では1問あたり3〜4分しかかけられないため、普段からスピーディーに解くことを意識しました。
    • まず問題を見て、どのジャンルからの出題なのか、計算量が多い問題なのかをぱっと見定めることが重要そうです。
  • 本番で使う電卓を問題演習中にも使用し、メモリ機能も含めて使い慣れておきました。
    • 私はこちらの電卓を使っていました。
  • 問題集に対して過学習が起きないよう、ときどきワークブック全体を読み返すようにしていました。

おわりに

ここまで、私の統計検定準1級の勉強法をご紹介しました。

  • 公式問題集やワークブックの問題を解くだけでなく、ワークブック全体の理解に力を入れたことが、好成績に繋がったのかなと思います。
  • 試験当日は、なるべく早い時間帯で受験した方がパフォーマンスが良いと思い、11:00開始の枠で受験することにしましたが、これも良かったのかもしれません。
  • 当日の問題群がたまたま自分に合っていた可能性もあります。
    • 1週間空ければ再受験できるそうなので、何回か受験してみるのも手かと思います。

何か一つでも、参考になっていれば幸いです。

ちなみに、弊社では合否に関わらず資格の受験費用を補助してもらえるため、思い切って受験しやすかったです。

We’re Hiring!

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

カジュアル面談も行っていますので、お気軽にお申し込みください 。

個人的にもアナリストやデータ関連職の方と繋がりたいと思っているので、よろしければXのフォローもよろしくお願いします。(弊社データメンバーとランチ会や合同勉強会のお誘いも……お待ちしております!)

iOSの職能チームが存在しない組織で、WWDCハッカソンを企画・開催しました

これはTimee Product Advent Calendar 2024の23日目の記事です。

こんにちは。タイミーでiOSアプリを作っている岐部(@beryu) です。
もうすぐクリスマスですね!月初から我が家のリビングに置いてあるクリスマスツリーもだいぶ見慣れてきました。

さて、今年も例年通りApple社による開発者カンファレンス「WWDC24」が夏に開催されましたね。
弊社の体制としては”iOSチーム”という単位のチームが存在せず、プロダクトを機能領域ごとに分割した職種横断チームで機能開発をしています。そのため、普通に業務をする上ではWWDCで得た知識についてiOSエンジニアが積極的に試したりする場はそれほど多くなく、得た知識を非エンジニアの社員に展開するかどうかも含めて個々人に任せられていました。

今年、初めてそれを社内ハッカソンという形で社内にアウトプットする機会を作ったので、それについてまとめたいと思います。

企画したきっかけ

WWDC開催期間中、弊社のiOSエンジニアは普段通り業務にあたりつつ、スキマ時間でセッションをキャッチアップする日々を送っていました。
そんな中、ふと思いつきでSlackに以下のつぶやきをしたのがことの始まりでした。

各チームのiOSエンジニアが参加しているSlackチャンネルの実際の書き込み

この時点で参加者数の見通しは私を含んで4名。小規模なハッカソンを開催するには十分な人数だと判断し、準備に取り掛かりました。

準備

前述した通り、弊社にはiOSチームという組織は無く、プロダクトを機能領域ごとに分割したチームで働いています。
したがって、一介のエンジニアがハッカソン用にリソースを自由に割けるような体制ではなく、ハッカソンに参加する社員が所属するチーム全てから許可を得る必要がありました。

今回のハッカソンは遊びではなく、魅力的なプロダクトを開発するために有効な仕事です。
しかし、万が一文脈を知らない方がこの活動を見て「遊んでいるのでは?」と思われたとしたら、それは誰の得にもならない悲しい誤解なので、そのような事態は必ず防がなければなりません。

この準備フェーズでは、そんな事態を防ぐために出来ることを考えながら動くことにしました。

非エンジニア向けの資料作成

まず、ハッカソンにかけたコストに見合うリターンが得られる論理を明文化しました。
誰かに資料作成を命じられたわけではありませんが、業務に割く時間を削って行う活動ではあるので「納得してもらえる材料があるに越したことはないだろう」という考えで用意しました。

ドキュメントには社外秘の情報を含んでいるので詳細はお見せできないのですが、主に以下のような内容を含めました。

  • 目的
  • タイミーが今WWDCハッカソンをやる意義
  • 期待されるアウトプット
  • ハッカソンのレギュレーション(ここ3〜4年のWWDCで発表された技術であれば何でも使って良い)
  • ハッカソンで消費するリソース量

iOS Chapterでの相談

弊社にはiOSチームが無い代わりに、各チームのiOSエンジニアが横軸で繋がるコミュニティのような存在として”iOS Chapter”という仮想組織が定義されています。
iOS Chapterでは毎週定例会議を開催しており、その場でハッカソンの開催形式や所要期間について相談しました。

各々が別チームに所属しているのでそれぞれに事情があり、直近での同期形式での開催は現実味が薄いと判断し、以下の枠組みで合意しました。

  • 1ヶ月弱の期間中で2営業日を割く
  • 任意参加扱いとする

マネージャーとの交渉

エンジニアリングマネージャー陣の定例会議の場で時間を拝借して、上述の資料をひっさげて開催させてほしい旨を交渉しました。
交渉とは言っても、私がこの話題を出した時点でその場が応援ムードになり、特に咎められることもなくスムーズにOKを頂けました。

自部署の全体定例での展開

共に現場で働くエンジニア・デザイナーの皆さんにも納得してもらった上で開催したかったので、対象のメンバーがほぼ全員集まるAll Handsという定例会議でも上述の資料を用いながら告知も兼ねて紹介しました。

ここでのリアクションも”わいわい”という形容がピッタリの、良い盛り上がりを感じるものでした。

ハッカソンの開発期間

参加者は定められた期間中の2営業日を使って、ハッカソンのための調査・開発を行いました。

このタイミングでも参加者はFixさせていなかったので、参加予定だった社員が途中で業務都合で参加できなくなったり、逆にこれまで参加表明していなかった社員が参加してくれたりすることもありました。
あくまで通常業務が優先であることを鑑みてこの形にしたのですが、結果的にはこの形にして良かったなと思っています。

成果発表会

弊社は(私も含め)リモートワークのメンバーが多く所属している事情もあり、成果発表会はオンラインで行いました。

発表順はその場でシャッフル関数で決めました

成果物

App Intentsの概要・実装方法の調査報告

発表の場では、WWDC24で発表されたApple Intelligenceとの統合を見据えながらApp Intentsの概要を説明しつつ、iOS版タイミーアプリにApp Intentsを組み込んだ例を実際のソースコードを添えて紹介していました。

タイミーのアプリ内部の構造が深く絡む内容だったのでここでは資料をお見せできないのが残念なのですが、App Intentsの実装の手軽さ、身近さを感じられる発表でした。

Live Activityによるリッチな通知機能の実現

これが私の発表です。

WWDC23で発表されたプッシュ通知経由での利用例を中心に、iOS版タイミーアプリにLive Activityを組み込んだらどんな体験になるかを紹介しました。
実際にデモで使用した動画は以下からご覧頂けます。
※ターミナル画面にはぼかし加工を加えています

www.youtube.com

パスキーによる認証の導入

現在タイミーで採用している電話番号認証とは別の認証方法として、パスキーを紹介していました。

認証はセキュリティが重要な要素になるので技術的な話題も多い発表で、正直なところ聞くだけでもやや難易度が高い内容でしたが、一方で動作デモの場面ではシンプルでわかりやすいUXに聴衆が感動している様子が印象的でした。
この日の発表の中で唯一、実際に操作できるデモアプリを配布できていたことでも大きなインパクトを残していました。

パスキーログイン

TipKitによるアプリ内ヒントの提供

WWDC23で発表された、機能のヒントを表示するためのフレームワークの紹介でした。
恥ずかしながら私はTipKitの存在を知らなかったのですが、画面の使い方を教えるようなUIを低い実装コストで実現できる、実用的なフレームワークでした。

動作デモでは、普段の開発で「この画面のUI、少しわかりにくいかもしれないね」と話に挙がっていつつ実装リソースを割くことが出来ないままになっていた箇所に、シンプルなコードでヒントを実装する様子が披露され、目立たない存在ながらその有用性を強く実感できる内容でした。

TipKitの動作デモ1 TipKitの動作デモ2

社内からの反応

成果発表会の最中にGoogle Meetのコメント機能で感想を述べて頂いたり、終了後にアンケートにご協力頂いたりして社内の反応を集めたのですが、非常に好評でした!
例えば、以下のような声が挙がっていました。

  • よかったですーで終わらせたくない内容でした
  • R&Dみが強い感じかと思ってたんですが、すぐにでも導入できそうな形に仕上がっていてすごい
  • iOSを業務で触っていない方がハッカソンに出られるところがスキルとマインドのダブルですごい
    • ※App Intentsについて発表したのは普段アナリストとして業務にあたっている社員でした
  • 取り組みに再現性持たせたいですね
  • 楽しかった!
  • 今日発表された機能のリリースはいつですか?

リリースされた機能

嬉しいことに、このハッカソンで披露された成果物のうち実際にリリースされた機能も存在します。

今年タイミーアプリに新設されたものの一つである”バッジ”という機能があります。ワーカー(タイミーを通して働くひと)が働き先で認定されると業務ごとのバッジを獲得でき、そのバッジ情報をもとに更にさらに自分のスキルに合った募集を受けることが出来るようになる機能です。

この機能で獲得したバッジはバッジ一覧という画面で一覧できるのですが、この画面にあるバッジ画像をタップ出来る事に気付けないという声が度々挙がっていた背景があり、そこに今回のハッカソンの成果物の一つだったTipKitを導入することになりました。
この機能はすでにリリースされており、iOS17以上のiPhone上で動作するタイミーアプリでご利用頂けます。

実際のバッジ一覧画面

また、他の発表された成果物に用いられていた機能についても実装に向けてPdMと相談し、優先度を付けて日々の開発に用いているバックログに追加しています。

やってみた感想

ハッカソンを実施するきっかけはSlackでの些細なつぶやきでしたが、周囲の応援もあってどんどん話が進んでいきました。賛同した社員が各々の発想と技術力をもって成果物を作成・発表し、非iOSエンジニアの興味を誘いつつ一部はスピーディにリリースまでされるという、理想的なハッカソンになったと感じています。

実施するにあたって社内のステークホルダーと丁寧に条件を握るステップも踏みましたが、その過程が終始ポジティブな空気だったことから、少なくとも弊社はこのような取り組みを快く思う人間性の方が多く所属しているのだと感じられて嬉しくもなりました。

弊社は組織の人数が日々増えているので開発力の高まりを感じる機会が多いですが、今回のように個の力を感じられる機会も非常に魅力的だったなと感じています。
こういった場を作ることを検討されている方にとって、この記事が少しでも参考になっていれば幸いです。