Timee Product Team Blog

タイミー開発者ブログ

DroidKaigi 2025 参加レポート〜Part 1〜

はじめに

タイミーでAndroidエンジニアをしているみかみです。

2025年9月10日から12日にかけて、Androidの技術カンファレンスである「DroidKaigi 2025」が開催されました。タイミーからはAndroidチームをはじめとする複数のメンバーが現地に参加し、今年も昨年に続いてゴールドスポンサーとしてブースを出展しました。

セッションでは最新の知見に触れる機会が多く、日々の業務にもつながる具体的な学びを得ることができました。また、会期を通しては立ち話や展示をきっかけに参加者同士が議論を深める場面も多くあり、交流の広がりも強く感じました。そのような様子は会場にとどまらず、XなどのSNSを通じて、オンラインでも盛り上がりをみせていたのが印象的です。

Part1、Part2の2記事に渡り、エンジニアメンバーによるセッションレポートと、ブース出展の様子をお届けします。

本記事（Part 1）では、エンジニアメンバーによるセッションレポートをご紹介します！

エンジニアによるセッションレポート

まずは、DroidKaigiに参加したエンジニアメンバーによるセッションレポートを紹介します。

Hunachi（@_hunachi）

紹介するセッション：Androidライブラリアンの手引き：堅牢なライブラリとSDKの構築

私はライブラリを公開した経験はないのですが、このセッションはライブラリ開発者だけでなく、マルチモジュール構成で開発している人、そしてライブラリを利用する人にも多くの学びがある、非常に有益な内容でした。

このセッションで特に印象的だった、新しく学べた点をいくつかご紹介します。

  • 公開範囲の制御の重要性について

internalを正しく使うことはもちろん、Explicit API mode を有効にすることで、意図せずパブリックAPIが公開されてしまうのを防げると知りました。これによって、モジュールの責任範囲が明確になり、APIの健全性を保つことができます。

  • 親切なAPIの非推奨化ついて

クラスや関数を非推奨（Deprecated）にする際、@Deprecated アノテーションのmessageや replaceWith 引数に具体的な説明を記述することで、利用者がスムーズに新しい実装に移行できる配慮が大切だと学びました。

  • 破壊的変更の自動検知について

パブリックAPIを変更、特に削除する際には、binary-compatibility-validator を導入して自動的にチェックをかける手法が紹介されていました。うっかり互換性を壊してしまうミスを防ぐための仕組みは、特にライブラリのメンテナンスにおいて非常に重要だと感じました。ライブラリを作成する機会があったら利用するようにしたいです。

また、ライブラリとそれを利用するプロジェクト間でリソース名が衝突するという問題についても話がありました。マルチモジュールでの問題においては弊社でも対応は済んでいるものの、ライブラリ使用者として予期せぬ挙動に悩まされた経験が何度かあるので自分がライブラリを作る側になった時は気をつけようと思いました。

ライブラリの裏側で何が起きているのかを知ることで、利用者としてもより賢く付き合っていくことができると再認識しました。今後、マルチモジュールでの開発やライブラリを利用する際に、今回学んだ知識を活かしていきたいです。

tick-taku

紹介するセッション：EncryptedSharedPreferences が deprecated になっちゃった！どうしよう！

タイトルの通りで、なぜ deprecated になったかなどの背景を含め紹介し覚悟を決めさせてくれる素晴らしいセッションでした。

タイミーでは KeyStore + Cipher + DataStore を利用していましたが、別のブログで Tink を利用するといい感じに wrap されて、複雑な暗号化周りをライブラリに任せつつ実行速度が速くなると知りました。特定端末でのみクラッシュしてそうな気配を Crashlytics から観測しており、「もしや自前の実装が悪く Tink であれば Google 提供だしその辺も対処してくれているのでは…?」と思い移行しようとちょうど DroidKaigi 直前に Issue を作成して検討していたところ、このセッションの存在を知りました。

結論からですがやめた方がいいとのことです😇

どうやら観測していたクラッシュは OEM デバイスの KeyStore のバグでどうしようもないとバッサリでした。これは security-crypto が deprecated になった要因の1つらしく、Tink に移行したところで解決せず、むしろアプリ側でのハンドリングが難しくなるそうです。こうなったらどうしようもないのでデータは捨てましょうと割り切るしかないとのことでした…

また、クラッシュの要因としてもう1つバックアップ設定の話がありました。allowBackup=false に設定しているため大丈夫と考えていたのですが、Android 12 からメーカーによっては device-transfer によるバックアップは allowBackup の設定を無視するようになっているそうです。おかげでデータは移行されるのに key が異なるので復号に失敗するというものでした。

本当にちゃんと作ってくれメーカー…

また EncryptedSharedPreference が存在してしまうが故に我々はなんでもかんでもデバイスのストレージに保存してしまうという思想のもと deprecated にした背景もあるらしく、「そもそもそのデータをデバイスに保存する必要があるのか？」は設計時に常に意識したい事項だと感じました。

紹介するセッション：OAuthを正しく実装する：Androidアプリのためのセキュアな認証

OAuth を導入するための基礎知識や歴史が理解できる内容でした。

一度実装したり触れたりしたことがある人はそうだよねとなる内容も多く OAuth の入門として非常に勉強になると思います。

気になった点としては、多くのアプリでは access token をデバイス上に保存していると思いますが、その際は変に暗号化せずにシンプルに SharedPreference を使ってデバイスを信頼しましょうといった趣旨の内容が話されていて、Android は root 化したら引き抜けると思ったのですが大丈夫なんでしょうか…

また、PKCE がベストプラクティスらしいですが、そこまで実装しているアプリはどれだけあるのか気になります。

haru

紹介するセッション：スマホ新法って何？１２月施行？アプリビジネスに影響あるの？

DroidKaigi初の公正取引委員会の人による発表で、主にこれから施行される新しい法律に関する話でした。

対象になるのは基本的にAppleやGoogleなどのプラットフォーム事業者で、In App Biilingなどの機能に対して影響があるようでした。

とはいえ、一般デベロッパーに開放していない機能を開放して欲しいなどのリクエストを送ることもできるようになるらしいので、今後どうなっていくか目が離せない法律の1つでもありますね。

みかみ

紹介するセッション：Be a Business-Driven Android Engineer

DroidKaigi 2025に参加して、特に印象に残ったセッションの1つが、ohzonoさんの「Be a Business-Driven Android Engineer」です。Androidエンジニアがどのようにビジネスの成長に貢献できるのかを解きほぐした内容で、今の自分が所属するストリームアラインドチーム（価値提供チーム）の状況とも重なり、とても心に残りました。

特に共感したのは「越境」という考え方です。現在所属するチームは少人数のため、エンジニアがデータ分析を担ったり、専門外の実装に挑戦したりと、役割の垣根を越えた働き方が自然に行われています。そのため、「越境」という言葉はもともとチーム内でもキーワードになっていました。今回のセッションは、そうした取り組みを価値あるものとして肯定してくれる内容であり、大きな励みになりました。AIの進化によって専門外の領域に踏み込みやすくなっている今、「越境」はこれからますます重要になると感じます。

また、開発チームが売上を直接的なKPIとして持つという話も新鮮でした。私はこれまで、パフォーマンス改善やエラー率の低減、ユーザー行動に基づく指標といったプロダクト内部の成果に注目することが多かったのですが、このセッションではそれに加えて、自分たちのアウトプットを事業全体の成果と結びつけて考える視点が提示されました。自分の仕事がどうビジネスインパクトにつながるのかを意識することで、エンジニアとしてもっと広い視野で取り組んでいきたいと感じました。

さらに、この考え方を技術面から支える手段として、Kotlin Multiplatform (KMP) の存在感も改めて実感しました。副業や別プロジェクトでKMPを利用してきた経験からも、その有効性を強く感じています。もちろん、ビルド速度やKMPそのものの複雑さ、iOSとAndroidエンジニア間の連携といった課題はまだあります。ドメインレイヤーの共通化によるメリットは大きく、KMPはAndroidエンジニアがiOS開発へと「越境」する後押しとなり、チーム全体の生産性を高める現実的な選択肢だと思います。今後も注目していきたい技術です。

syam

紹介するセッション：KotlinでのAI活用による開発

JetBrains の Sebastian Aigner さんと Márton Braun さんによる「KotlinでのAI活用による開発」というセッションが気になったので聴講しました！

Kotlin と AI の関わり方を「コード補完のような軽い支援」から「エージェントに任せる自動実装」まで段階的に紹介しており、JetBrains の AI エージェント Junie を使ったデモでは、新しい画面追加や UI の改良を自動で行っていて、既存コードのパターンも踏まえた修正が印象的でした。

また、Kotlin 製のフレームワーク Koog も紹介され、マルチプラットフォームで AI エージェントを組み込める仕組みとして活用できるとのことでした。

nshiba（@nshiba310）

紹介するセッション：ユーザーも開発者も悩ませない TV アプリ開発 - Compose の内部実装から学ぶフォーカス制御

AndroidTVアプリを Compose を使って実装方法を紹介するセッションでした。

Compose 以前の時代に存在していた leanback library という Google 製のライブラリがありましたが、これは Compose には対応していません。

Compose で AndroidTV を実装しようと思ったら、どういったライブラリを使ったら良いかと行った基礎的なことから始まり、leanback library ではデフォルトでライブラリが対応してくれていた、フォーカス周りの制御やいまどのUIにフォーカスがあったているかがわかりやすくなるUIの制御などを Compose では自前で実装する必要がありどういった対応が必要かについても詳しく解説されていました。

また AndroidTV アプリでは、スクロールの制御についても通常のモバイルアプリとは異なる実装方法が必要になり、これについても詳しく解説されていました。

セッションタイトルの通りどのセクションでも Compose の内部実装までちゃんと処理を追って説明されていてとてもわかりやすく、これから Compose で AndroidTV アプリを作成する方にとって必見の内容がつまっていました！

続きはPart 2の記事で！

引き続き、Part 2の記事にて他のエンジニアメンバーによるセッションレポートと、ブース出展の様子をお届けします。

ぜひ読んでください！

tech.timee.co.jp

EKS × ARCでつくるGitHub Actions Self-hosted Runner基盤

こんにちは、タイミーでエンジニアをしている徳富です。

今回は、EKS上にGitHub Actions Self-hosted Runner基盤を構築した話をお届けします。

背景：GitHub Actionsへの移行と、新たに見えてきた課題

2024年10月に公開したCI基盤をGitHub Actionsへ移行した記事で紹介したとおり、

CircleCIからGitHub Actionsへの移行によって、私たちのCI体験は大きく改善しました。

しかし、開発者やテストケースが増え、時間が経つにつれて新たな課題も見えてきました。

  • 実行回数の急増によるコスト高騰
    • 2025年2月頃からDevinをはじめとしたAIエージェントの利用が進み、PRやpushの回数が一気に増加
    • 開発者数の増加も重なり、ワークフロー実行回数が比例して伸びていった
    • GitHub-hosted Runnerは料金や安定性の面である程度最適化されているため、Self-hostedに切り替えれば必ずしもコスト削減につながるとは限らない。しかし、割引オプションが少なく、コストコントロールが難しいという課題もある
    • 一方AWSならSavings PlansやSpotインスタンスなどの仕組みを活用でき、柔軟に最適化が可能。開発者やエージェントの利用増加で実行回数が急増するタイミーのユースケースにおいては、この「柔軟に最適化できる」という点が大きなメリットであることがわかってきました
  • テスト時間のじわじわとした増加
    • テストケース数の増加により、全体の実行時間も長くなってきている
    • apt install などのセットアップ処理にも時間がかかっている
    • 「ランナーイメージに事前インストールしておけばもっと速くできるのでは？」という声も出始めた

「コストをコントロールしながら、テストももっと速くしたい」

そんな思いから、私たちはSelf-hosted Runner基盤の構築を検討し始めました。

最初のアプローチ：ECS + Lambda構成

当初は ECS + Lambda + API Gateway を組み合わせて、ランナー基盤を構築しようとしました。

しかし実際に検証してみると、すぐにいくつかの課題に直面しました。

  • レートリミットの考慮

    1回のCI実行で最大35並列のランナーを起動してます。 　日中は多いときで 1時間に60回以上 実行されることもあり、GitHub API の レートリミットを意識した設計が必要になります。

    → これを Lambda 側で考慮して実装するのはかなり複雑。

  • ランナーは30秒以内に立ち上がってほしい という要件がある。

  • Lambda のコードを継続的にメンテナンスするコストも無視できない。

「長期的に運用するには、この構成は少し複雑すぎるかもしれない」

そう判断し、よりシンプルに運用できる別のアプローチを探すことにしました。

選んだのは EKS(auto mode) × Actions Runner Controller

そこで目をつけたのが、GitHub公式が提供する **Actions Runner Controller(ARC)**。

ARCはGitHub ActionsとKubernetesをつなぎ、必要なときだけランナーPodを動的に起動してくれます。

さらにクラスタ基盤には EKS Auto Mode を採用しました。

ノード管理やスケーリング設定をほとんど自前で持たずに済むため、運用の手間を大幅に減らせるのが魅力です。

「EKS Auto Mode × ARC であれば、管理コストを抑えつつ柔軟なSelf-hosted Runnerが作れるのでは？」

そう考え、この構成で進めることにしました。

アーキテクチャ概要

ざっくりとした構成はこんなイメージです。

アーキテクチャー図

  • ARC: GitHub APIと連携し、ランナーPodを自動的に作成・削除
  • EKS Auto Mode: クラスタ管理を最小限に抑えつつ、柔軟なスケーリングが可能
  • Karpenter: Auto Modeの裏側で働くプロビジョナー。従来のCluster Autoscalerよりnode起動が速い

特にCIのように時間帯によって必要リソースが大きく変動するワークロードでは、

Auto Mode＋Karpenterの組み合わせが非常に相性が良く、メンテナンス性・柔軟性の両立ができました。

導入時に直面した課題と解決策

ここからが本番です。

実際に導入を進めていくと、次々と問題が発生しました。

1. Spotインスタンスの安定性問題

当初はコスト削減を狙って、停止率の低いインスタンスタイプの Spotインスタンス を採用していました。

しかし、弊社のCIは 35並列で高頻度に実行されるため、必要なインスタンス数が多くなり、停止確率が低いタイプでも 1日あたり5〜10回ほどノードが落ちることがありました。

その結果、CIが途中で失敗するケースが頻発し、開発者体験を大きく損ねる要因となってしまいました。

対策

そこで思い切って オンデマンドインスタンスに切り替え、必要に応じて Savings Plans を適用する方針にしました。

  • オンデマンドにしたことで、ランナーが突然落ちるリスクがなくなり、安定してCIを回せるようになった
  • 安定性が向上したことで、CIだけでなく デプロイなど他のワークフローもSelf-hosted Runnerに寄せる ことが可能に
  • これによりEC2のアイドル時間を減らし、稼働率を高めることでコスト効率も改善できました

2. スケールインでランナーPodが強制終了する問題

次に直面したのは「EC2のスケールインによって、ランナーPodがCI実行中に突然落ちる」という問題です。

原因は、Karpenterの設定でした。

デフォルトでは disruption.consolidationPolicy が WhenEmptyOrUnderutilized になっており、

ノードのリソース使用率が低いと、Podが稼働中でも容赦なくノードを落としてしまうのです。

(参考: https://karpenter.sh/docs/concepts/disruption/)

対策

  • consolidationPolicy を WhenEmpty に変更
  • Podがないノードのみスケールイン対象とするよう設定
spec:
  disruption:
    consolidationPolicy: WhenEmpty

これでランナーPodが実行中に消える問題は解消しました。

3. ノードが全然スケールインしない問題

しかし、ここで別の問題が発生します。

「一度スケールアウトすると、ノードがほとんど減らない」という現象です。

原因は Kubernetes のスケジューリング。

Kubernetes のスケジューラには、Pod をできるだけ均等に配置しようとする仕組みがあります。

そのため Pod が複数のノードに分散して配置されやすく、ノード上の Pod が 0 になるケースが少ないため、スケールインがなかなか進まなくなります。

対策

  • Pod Affinityを利用し、ランナーPodはなるべく同じノードに詰めるよう設定
  • Pod配置の断片化を防ぎ、スケールインしやすくしました
affinity:
  podAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              actions.github.com/scale-set-namespace: arc-runners
          topologyKey: kubernetes.io/hostname

これによりリソース効率が大きく改善されました。

4. 夜間にリソースを最適化する作戦

リソース効率をさらに高めるため、日中は安定性を優先し、夜間だけ段階的にノードを整理する仕組みを導入しました。

具体的には、disruption.consolidationPolicy を WhenEmptyOrUnderutilized に設定したうえで、夜間に 一定間隔で15分だけpodが存在するノードのスケールインを許可 → その後は再び禁止 というサイクルを繰り返します。

これにより、ノード上にPodが残っていても一気に消されることはなく、「急にPodが落ちてCIが止まる」といったリスクを避けながら、少しずつリソースを最適化できるようになります。

spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m
    budgets:
      - nodes: "0"
        reasons:
          - Underutilized
        schedule: "0 0 * * *"     # 0:00〜11:45 UTC 禁止 (JST 9:00〜20:45)
        duration: "11h45m"

      - nodes: "0"
        reasons:
          - Underutilized
        schedule: "0 12 * * *"    # 12:00〜15:00 UTC 禁止 (JST 21:00〜翌0:15)
        duration: "3h15m"

      - nodes: "0"
        reasons:
          - Underutilized
        schedule: "30 15 * * *"   # 15:30〜17:00 UTC 禁止 (JST 翌0:30〜翌2:15)
        duration: "1h45m"

      - nodes: "0"
        reasons:
          - Underutilized
        schedule: "30 17 * * *"   # 17:30〜20:00 UTC 禁止 (JST 翌2:30〜翌5:15)
        duration: "2h45m"

      - nodes: "0"
        reasons:
          - Underutilized
        schedule: "30 20 * * *"   # 20:30〜24:00 UTC 禁止 (JST 翌5:30〜翌9:00)
        duration: "3h30m"

この仕組みによって、日中は安定してCIを回しつつ、夜間は少しずつノードを整理してリソースを効率的に活用できるようになりました。

5. コールドスタート問題をランナープールで解消

弊社では35並列のランナーを利用しています。

そのため、完全なオンデマンド起動では間に合わず、

ランナー起動待ちが発生してしまうこともありました。

そこで、ARCの minRunners 設定を活用し、ランナープールを作成。

あらかじめ一定数のランナーを起動しておくことで、

要求があればすぐに割り当てられるようになり、

GitHub-hosted runnerと同じ快適な使い心地を実現しました。

5 Runner PodでDockerを使う工夫

最後のハードルは「ランナーPodでDockerをどう使うか」です。

私たちのCIではMySQLやRedisなどのservice containerを多用しているため、RunnerコンテナからDockerを操作できる仕組みが必要でした。

選んだ方法

RunnerでDockerを扱う方法は大きく分けて DooD (Docker outside of Docker) と DinD (Docker in Docker) の2種類があります。(参考:GitHub Actions の self-hosted runner で Docker を使う際のパターン整理)。

今回は DinD を採用しましたが、その中でもさらに実現方法が2パターン存在します。

  1. Runnerコンテナ内で直接Dockerデーモンを起動する方式
    • Runnerコンテナ自身が dockerd を立ち上げ、docker build や docker run を自己完結的に実行する。
    • シンプルですが、Runnerコンテナに 特権モードや大量の権限 を付与する必要があるため、セキュリティ面での懸念が残ります。
    • また、RunnerコンテナとDockerデーモンが同居することでリソース管理が複雑化しやすく、トラブルシュートもしづらいという課題があります。
  2. Dockerデーモンをサイドカーとして起動する方式
    • Pod内で Runner と dockerd を分離し、emptyDir などを介して ソケット通信 させる。
    • Dockerの実行環境はサイドカーに閉じるため、Runnerコンテナは通常権限で動かせる。
    • CIジョブ終了とともにPodごと削除されるため、イメージやボリュームなどの作業痕が自動的に掃除される点もメリットです。

私たちは Runnerコンテナに強い権限を持たせないことを重視し、後者の DinDサイドカー方式 を選択しました。

まとめと次回予告

今回、EKS × ARC を使ってGitHub Actions Self-hosted Runner基盤を構築し、

コスト・パフォーマンス・柔軟性のいいバランスで実現できました。

ただ、これで終わりではありません。

次回は、この基盤の上でテスト実行時間をさらに短縮するために行ったチューニングについて詳しく紹介する予定です。

「GitHub-hosted runnerで限界を感じている」

「EKSでSelf-hosted Runnerを検討している」

そんな方の参考になればうれしいです。

ながらRuby 会議01に行ってきました！

こんにちは！
タイミーでBackendEngineerをしている志賀(@akitoshiga)です！

2025年9月6（土）に開催された「ながらRuby会議01」に行ってきましたので、その様子を振り返りたいと思います！
ながらRuby会議には、「Kaigi Pass」という社内制度を利用して参加しました。

「Kaigi Pass」とは、世界中で開催されているすべての技術カンファレンスに無制限で参加できる制度です。

productpr.timee.co.jp

会場の様子

当日は長良川沿いにある「長良うかいミュージアム」というとても素敵な場所で開催されました。

会場内にはスポンサーノベルティや展示などもありました。

セッションの様子

refinementsのメソッド定義を4000倍速くした話

alpaca-tcさん

Ruby3.2以降、refinementsにおけるメソッド定義は約1万倍低速化していました。
社内サービスの開発でこの事態に直面した際に、原因の究明からRubyへのコントリビュートまでを行った過程をお話しされていました。
refinementsとはRuby2.0から導入された安全にRubyを拡張する仕組みのことで、モンキーパッチを当てたクラスのスコープを限定させることが可能です。
きっかけは、社内サービスのRubyのアップデートの際にRuby on Railsのアプリケーションの起動に数十秒かかるようになってしまったことでした。　　
VernierとMiddlewareを利用して計測を行ったところ、ボトルネックとなっている処理が判明しました。
そこにrefinementsのメソッドModule#refineが存在していました。
Ruby3.3では、Module#refineを呼び出した際にrefineのcallcacheがクリアされる処理が追加されます。
このcallcacheが削除されたことが低速化の原因でした。 これをRuby Issue Tracking Systemで報告したところアドバイスをもらいました。
しかし、alpaca-tcさんはRubyの実装であるC言語には馴染みがありませんでした。
この問題に対してはChat-GPTやko1/rubyhackchallengeを活用したりコミュニティでアドバイスを得ることで解決していきました。
最終的にプルリクエストを作成してRuby本体へのマージが実現したそうです。
技術的なギャップを埋めるためにAIを活用したのは素晴らしい解決方法ですし、粘り強く取り組みRubyへのコントリビュートを実現する姿は素晴らしいと思いました！  

知っているようで知らないrails newの世界

luccafortさん

speakerdeck.com
  Ruby on Railsではプロジェクトの初期化の際にrails newというコマンドを実行します。
しかし、このコマンドの裏側でどのような処理が行われているかは多くは知られていません。
そこで、コマンドはどのような実行フローを行っているか、また使われている技術がどのような設計の組み合わせによって実現しているかについて深掘りしてお話しされていました。
luccafortさんの今回の発表の動機の一つには、オーガナイザーを務められた「関西Ruby会議08」での体験から、個人開発以外の成長の選択肢を模索したかったという想いがあったそうです。

rails newで実行される処理は以下の流れになっています。

  1. コマンド解析
  2. ジェネレータ初期化
  3. オプション処理
  4. ディレクトリ作成
  5. ファイル生成
  6. bundle install

これだけでも長大な処理なので、本発表ではコマンドの解析からジェネレータの初期化まで中心に説明していました。

rails newを実行するとRails::Commandによってargの解析やエラーチェックが行われます。
その後、Rails::Command.invokeによって入力したコマンドの内容からRails::Commandの適切なサブクラスが呼び出されます。
今回の場合はRails::Command::ApplicationCommandが読み込まれます。
Rails::Command::ApplicationCommand#performによって無効なコマンドチェックなどが行われた後、Rails::Generators::AppGenerator.startで定義された各種ファイルの生成タスクが実行されます。
その後、Rails::Generators::AppGenerator#bundle_commandによってbundle installが実行され最終的にコールバックが呼び出されます。
rails newに関する説明は以上です。
この取り組みを通してluccafortさんは仕組みを理解する重要性について気づきがあったそうです。
仕組みを理解していなくてもRuby on Railsは使えるものの、深く理解することで新しい発想や新たな気づきのきっかけになるとお話しされていました。

Ruby × iOSアプリ開発：共に歩んだエコシステムの物語

Tomoki Kobayashiさん

speakerdeck.com

Kobayashiさんは普段は主にモバイルエンジニアとして活動されています。
RubyはiOS開発の歴史において過去大きな役割を担っており、またiOS開発コミュニティもRubyに大きく貢献しています。
iOS開発とRubyが今までどう関わってきたかの歴史をお話しされていました。
2010年ごろのiOSアプリ開発はObjective-Cが使用されていましたが、サードパーティのライブラリのインストールが大変だったそうです。
ライブラリによってインストールの仕方が異なっており、Xcodeのビルド設定を行う際にもAppleの非公開の独自仕様のために保守性が非常に低いものでした。
この問題を解決するためにCocoaPodsというパッケージマネージャーが登場しました。
これによりライブラリの依存性解決・ダウンロード・Xcodeへのプロジェクト統合まで自動できるようになりました。
CocoaPodsはRubyでライブラリ管理に使用されるRubyGemsとBundlerを参考に作成されており、本体の実装もRubyで書かれています。
その他もnomad-cliやfastlaneといったRubyを参考にしたツールが登場してきました。
この背景はツールの作成者が元々RubyやRuby on Railsのエンジニアが多かったことにあるそうです。
そして、CocoaPodsの依存関係リゾルバーであるMolinillo（モリニージョ）はBundler1.9, RubyGems2.9に搭載されるようになりました。
しかしながら、iOS開発とRubyの関わりは薄れつつあるそうです。
2014年のSwiftの登場を機にSwiftが公式のパッケージマネージャーを発表したりBundler2.4でMolinilloが引退しています。

Ruby Mini Language作成記 〜ハンズオンで学ぶインタプリタの世界〜

haruguchiさん
Rubyを用いてインタプリタを作成した経験をもとに、字句解析、構文解析、評価とった処理の実装方法や設計上の注意点についてお話しされていました。
インタプリタを作ろうと思ったのはharuguchiさんがRubyKaigi2025に参加したことがきっかけだそうで、RubyKaigiでよく発表される言語処理の話の理解を深めたいと思った時にインタプリタの実装を思いついたそうです。
haruguchiさんが参加されている勉強会でこの話を持ち込み、他のメンバーと実装していくことになりました。
インタプリタはFizzBuzzが動くものをゴールとして、単純な2項演算の実装からはじめることにしました。
最初は単純なパーサーのみで実装することとし、インタプリタの機能を追加していくにつれてレキサーを実装したり構文解析方法を工夫したりと実装を進めていきました。
自身で実装することを面白くするポイントとしてif文の条件式の区切りを< >にしたりとオリジナルの要素を追加していったそうです。
5ヶ月ほどでFizz Buzzの実装まで完了して、途中デモで実践していました。

当初のゴールとしては達成したのですが、ここから配列やハッシュといったデータ構造も行ってみたいとのことでした。
言語処理の話題はRubyではよく出てくるのですが、その理解のためにインタプリタを自前で実践するところに尊敬しました。また、自分も挑戦してみたいと思いました。

💡Ruby（ひかるびー） 川辺で灯すPicoRubyからの光

bashさん

speakerdeck.com

PicoRubyという組み込み向けの軽量なRubyを使ってLEDを点灯させるところから、音声や加速度といったセンサーを追加して様々なことに挑戦することでRubyで組み込み開発をする楽しさについてお話しされていました。
最初の機材は「ATOM Matrix」という開発ボードで、内蔵のLEDを点灯させるところから始まりました。
また、基本的なアーキテクチャは「Super Loop Architecture」というものを用いていました。
Super Loop Architectureとは、初期化の後に発生させた無限ループの中でLEDに対しての操作を行うものです。
LEDの点灯に成功させたあとは、ランダムに点灯させたり自分の動きに合わせて点灯させたりといった試みを行っていきました。
最終的には棒状のLEDやMIDIシンセサイザーといった他の機材と連携させる試みを行っていました。

365日のOSS開発を続ける舞台裏

Koichi ITO(Koic)さん

speakerdeck.com
  RuboCopのコミッターであり、365日OSSにコントリビュートを行っているITOさんの普段の開発環境やOSSに対する心構えについてお話しされていました。
開発環境は業務のコードとOSSのコードを透過的に扱えるようにすることをテーマとしていました。
そのためのツールとしてghqやgem-srcの使用を推奨されていました。
OSS活動をするとローカルリポジトリが大量に増えるのですが、その点についてはpecoやfzfを用いた対策を紹介されていました。 印象的だったのは、gitコマンドの扱い方でコミット権のないリポジトリとリポジトリでの振る舞いを合わせるためにFork先のリポジトリをoriginとして、upstreamをForkした方のリポジトリとすることを推奨されていた点です。
これによってどの環境にプッシュする際もgit push upstream headと同一のコマンドにできる利点について強調されていました。 心構えについては、コードの内容だけではなく発言やレビューについても恥ずかしくない振る舞いをしようという「ソーシャルコーディング」という考え方や、OSSを地球全体での非同期開発と捉えて自己完結したコードのみのPRを出さずにコンテキストを文章化して伝えることの重要性にも触れられていました。 　

アフターイベント

懇親会の後にはアフターイベントとして鵜飼漁の観覧がありました！


残念ながら自分は参加できなかったのですが、大変盛り上がったみたいです。

まとめ

スポンサーLTも含めてどのセッションも大変面白かったです。
発表者の「これがやりたいからやる！」といった気持ちに基づいた発表が多かったのですが、その姿勢をとても尊敬しました。
また小規模の開催だったこともあり、アットホームで参加者間でのコミュニケーションもとりやすくたくさんの方と交流できました。
また、自身は今回初めて岐阜に行ったのですが、自然と人々の生活が調和したとても素晴らしい場所でした。
大変心に残る素晴らしい会だったので、次回開催される際はまたぜひ伺いたいなと思いました！  

関西データエンジニア/アナリティクスエンジニアMeetup 参加レポート

はじめに

こんにちは。タイミーでデータエンジニアをしている chanyou です。

先日、おそらく関西圏で初めてのデータエンジニアリング・アナリティクスエンジニアリングをテーマとしたイベント、 関西データエンジニア/アナリティクスエンジニアMeetup に参加してきました！

https://monotaro.connpass.com/event/360460/monotaro.connpass.com

このミートアップは、株式会社MonotaRO主催のもと、「関西に住みながらデータ関連の仕事をしたい」「関西で同じ職種の仲間と繋がりたい」という想いを持つデータ専門職向けに開催されました。 当日は株式会社10X、株式会社MonotaRO、ダイハツ工業株式会社、そして当社タイミーの4社の発表と、最後にパネルディスカッションがありました。

非常に熱量あるイベントでしたので、内容をまとめてお伝えします。

会社にデータエンジニアがいることでできるようになること

まずは株式会社10X 吉田さんの発表です。

speakerdeck.com

マネージドサービスが普及し、誰でもある程度のデータ基盤を構築できるようになった現代において、改めて「なぜデータエンジニアが必要なのか」という問いに、具体的な事例で答えていく内容でした。

特に印象的だったのは、以下の2つの取り組みです。

  • アセスメントの実施とデータ品質の改善
    • DMBOKを拠り所にデータ品質を定義し、データセットごとに可視化する仕組みを構築されているとのこと。
    • 正直データ品質の継続的なモニタリングまでされていて、見習っていかねばと思いました。
  • Data Contractによるデータソース仕様の確立
    • データの生産者とデータの消費者の橋渡し役として、連携のプロトコルを取り決めて運用されているとのこと。
    • これもまたマネージドサービスだけでは実現できない、人間に残された仕事のうちのひとつだなと思いました。

セッション全体を通して、「データエンジニアの本質とは何か？」という問いを突きつけられたような感覚で、身が引き締まる思いでした…！！

組織的データ活用をスケールさせる、アナリティクスエンジニアリングの実践

続いて株式会社MonotaRO 小谷さんの発表です。

アナリティクスエンジニアリングに特化した部署を立ち上げ、組織的なデータ活用をスケールさせている実践例が共有されました。

今回発表された小谷さんは、営業専門のアナリティクスエンジニアとして、営業組織にフルコミット。深く入り込んで課題の特定からソリューションの実装・運用までされているそうです。

印象的だったのは営業組織に本当に深く入り込んでいる点で、営業管理部署の定例に参加するのはもちろん、作業も同じ部屋で行うなど、徹底的に現場に寄り添っていました。これにより真の課題を特定して、成果につながったとのことでした。

さらに 縦に伸ばして横に広げる という、アナリティクスエンジニアが深さを探求して、データエンジニアがそれを横展開する思想が語られており、非常に共感できる考え方だなと思いました！！

具体的なソリューションについても、セマンティックレイヤーを整備したり、生成AIによる議事録作成の自動化をしたりと、踏み込んだデータ活用をされていて勉強になりました。

AnalyticsEngineeringがもたらした実インパクトと未来のロードマップ

当社 okodoon さんによる発表です。

speakerdeck.com

タイミーにおけるアナリティクスエンジニアリングを「データ活用UXの改善」と定義し、これまで行ってきたデータモデリングやデータアプリケーション開発が、実際にどのようなインパクトをもたらしたかを紹介しました。具体的には以下の事例を紹介しました。

  • Looker整備によるアナリストの負荷軽減と指標統一
  • 個人情報を含むデータのアウトプット申請フローのセルフサービス化

また、後半ではさらにデータ活用体験を向上させるために行っているヒアリング活動についても触れました。

データ利用者の業務理解には、ジョブ理論とユーザーストーリーマッピングを組み合わせた独自のフレームワークでヒアリングを実施。いざモデリングを行うとなった際にはアジャイルデータモデリングを実践しています。

またアナリティクスエンジニアリングの魅力に注目して語っていて、okodoonさんは 飽きないことも重要 と話していたのが同僚ながら面白かったです。

製造業におけるデジタル人材の活躍ポイント

ダイハツ工業株式会社 太古さんによる発表です。写真NGのスライドでしたので文章のみでお伝えします！

自動車メーカーということで他の3社とは、データを取り巻く環境が全く異なっていました。AI、BI、アプリ開発の3軸で、トップダウンとボトムアップの両面で変革を推進しているとのことでした。

AI に関しては、スキルあるメンバーが現場に入り込み、たった2ヶ月でリリースして回っているとのことでした。スタートアップ顔負けなスピード感に驚きました…！

BI に関しては、ちょっとダッシュボード作れるレベルの方を増やすのではなく、人に教えられるレベルの方を増やすことに注力した戦略を取られているとのことでした。

アプリ開発軸に関しては、手を挙げたキャリアチェンジしたい方などにプログラミング教育を実施して、元の部署や異動後の部署で現場の課題を解決する動きを取ってもらっているとのことでした。実際に人手で行っていた作業を自動化する内製アプリがポツポツと開発されていて、現場の課題をそのまますぐに解決できる環境が実現されているんだなと思いました…すごい。

パネルディスカッション

セッション後は、登壇者全員によるパネルディスカッションが行われました。多岐にわたるテーマで議論が交わされ、特に印象に残った点をいくつかご紹介します。

Q. ジョブ理論の活用といった知識のインプットや、チームでの議論はどう進めている？

okodoon(タイミー): 「プロダクト開発の知見を参考にしている。社内のプロダクトマネージャーが実践しているジョブ理論やユーザーストーリーマッピングの手法を、データ基盤の利用者ヒアリングに応用した。」

吉田さん(10X): 「X(旧Twitter)など外部からの情報収集に加え、ソフトウェアエンジニアリングの知見を参考にすることが多い。ただし、単に新しい技術を導入するのではなく、自分たちの組織のフェーズに合っているかが重要。経営陣にも年単位で繰り返し伝え続ける粘り強さも必要。」

Q. 大人数がデータを触る中でのガバナンスや管理体制はどのように担保してる？

太古さん(ダイハツ): 「まずはセキュリティを固めたセキュアな環境を構築し、その中で自由に使えるようにしている。新しい技術を試すためのSandbox環境を用意するなど、目的で使い分けている。」

Q. データ品質改善の副作用や、他部署への説得はどう乗り越えた？

吉田さん(10X): 「オペレーション部門などとの連携は課題になりやすい。まずは現状の定義がなぜ正しくないのかを紐解き、あるべき姿(to-be)を考える。元データの作りが良くないなら、データ基盤側で吸収するアプローチも取る。」

小谷さん(モノタロウ): 「営業組織などは特に指標が変わることに敏感だが、丁寧に説明することで理解を得やすい文化がある。」

Q. 何を作るかの意思決定、どこにベットする？

okodoon(タイミー): 「投資しても腐らない領域にベットする。AEが担う指標の定義などは、やればやるだけ人間もAIも喜ぶ領域。」

吉田さん(10X): 「ビジネスプロセスをどう定義するか。枯れたフレームワークはLLMも解釈しやすい。」

Q. アナリティクスエンジニアというロールはどうやって生まれた？

okodoon(タイミー): 「アナリストが闇堕ちして誕生した（笑）。『分析テーブルが汚い』といった憎しみを解決したいという想いが原動力。」

吉田さん(10X): 「ロールはなんでもよくて、執念をどこに捧げられるかの違い。」

おわりに

今回のミートアップを通じて、関西のデータコミュニティの熱量を肌で感じることができました。

各社の発表が刺激になったのはもちろん、パネルディスカッション後の懇親会では様々な領域の企業の方とお話できて、本当に西日本における盛り上がりを感じました…！

このような素晴らしい場を設けてくださった運営・登壇者の皆様、そして当日お話しさせていただいた参加者の皆様、本当にありがとうございました！

今回得た学びを日々の業務に活かし、タイミーのデータ活用をさらに前進させていきたいと思います。

Devin にインラインコメントでレビューさせたい

Devin

こんにちは、タイミーでバックエンドのテックリードをしている新谷 (@euglena1215) です。

タイミーでは、開発効率を向上させるため、Devin や Claude Code Action といった AI ツールを活用してコードレビューの自動化を進めています。

Claude Code は「インラインコメントでレビューして」と伝えるとインラインでのレビューをしてくれるのですが、Devin は同じ指示をうまく解釈できずインラインでレビューしてくれません。

この能力の差は GitHub MCP が使えるかどうかの差ではあると思うのですが、Devin と Claude Code Action でのレビュー内容の精度を比較しようとした際に、レビューフォーマットが異なっていると純粋な性能比較が難しくなります。

そこで、今回は Devin でもインラインコメントによるレビューを実現するための方法を調べてみたので紹介したいと思います。

方法

方法は簡単で、以下の GitHub API を使ってインラインコメントを投稿する方法を記したドキュメントを Devin の knowledge として登録するだけです。

トリガー設定は登録時に Devin が提案してくるデフォルトの内容で問題なく動作しました。

How to post comments with code embedded:
1. Create JSON file for each comment you want to post.
Example 1: 
    {
        "body": "Security Issue: Hardcoded API key. Recommendation: Use environment variables",
        "commit_id": "954...12312",
        "path": "file.py",
        "line": 11,
        "side": "RIGHT"
}

Example 2:
{
"body": "Multiple issues found:\n1. Hardcoded API key should be in environment variables\n2. Inconsistent class naming (userAccount vs Product)\n3. Inconsistent parameter casing (Password vs username)\n4. Missing docstrings and type hints\n5. Inconsistent spacing around operators",
"commit_id": "323......87686",
"path": "code.py",
"start_line": 11,
"start_side": "RIGHT",
"line": 25,
"side": "RIGHT"
}

body: The text of the review comment. Include markdown code blocks for snippets
commit_id: SHA of the commit you're reviewing. Not using the latest commit SHA may render your comment outdated if a subsequent commit modifies the line you specify as the position.
path: Relative file path in repo
line (integer): Specifies the exact line in the pull request’s diff view to which your comment should attach. Required unless using subject_type:file. The line of the blob in the pull request diff that the comment applies to. For a multi-line comment, the last line of the range that your comment applies to.
side: In a split diff view, the side of the diff that the pull request's changes appear on. Can be LEFT or RIGHT. Use LEFT for deletions that appear in red. Use RIGHT for additions that appear in green or unchanged lines that appear in white and are shown for context. For a multi-line comment, side represents whether the last line of the comment range is a deletion or addition.
subject_type: The level at which the comment is targeted. Either "line" or "file". Use "line" for inline comments. Use "file" for file-level comments.
start_line (integer): Required when using multi-line comments unless using in_reply_to. The start_line is the first line in the pull request diff that your multi-line comment applies to.
start_side: Required when using multi-line comments unless using in_reply_to. The start_side is the starting side of the diff that the comment applies to. Can be LEFT or RIGHT. 

A pull request diff may not match the original file's absolute line numbering. That is, if the PR contains additions or deletions before the line you’re commenting on, the line indices shown in the “Files changed” tab can shift from the original file’s line numbers.
For example: In the pre-PR state, line 231 might refer to a completely different section of code than line 231 in the post-PR diff (because code added or removed above it shifts everything down or up).
Therefore, you must use the line numbers as shown in the PR diff rather than the original file’s line numbers.

If you have issues, visit the docs: https://docs.github.com/en/rest/pulls/comments?apiVersion=2022-11-28#create-a-review-comment-for-a-pull-request

2. Use gh api command.
            gh api \\
--method POST \\
-H "Accept: application/vnd.github+json" \\
/repos/owner/repo/pulls/4/comments \\
--input comment.json

owner: the account owner of the repository. The name is not case sensitive.
repo: The name of the repository without the .git extension. The name is not case sensitive.
pull number: The number of the pull request.

Key points: use "line" instead of "position", include code snippets in body using markdown, , set side="RIGHT" for additions

この knowledge を登録することで Devin に「インラインコメントでレビューして」と一言伝えると、安定して正しくインラインコメントでレビューしてくれるようになりました！ 🎉

実は、上記の knowledge の内容は Devin の開発元である Cognition 社の記事にそのまま掲載されています。

cognition.ai

公式ドキュメントを読みましょう、以上。の内容ではありますが、あまり日本語の文献が見つからなかったので記事にしてみました。

この記事が、同じように AI コードレビューに取り組む方々の助けになれば幸いです。

亀井がスクラムフェス仙台2025に行ってきました

はい、亀井です。 インターネット上では、yykamei（わいわいかめい）という名前で活動しています。所属はタイミーです。

Kaigi Pass を利用してスクラムフェス仙台2025に行ってきましたので、参加レポートという形でこちらに投稿しています。

まずは、スクラムフェス仙台の運営の皆さん、スポンサーの皆さん、会場提供をしてくださったenspaceさん、そして、登壇者や参加者を始めとする関わってくださった皆さん、ありがとうございます。皆さんのおかげで終始楽しめました。

1日目はキーノートが行われます。今回はモンテディオ山形の相田さんがキーノートスピーカーとして登壇されました。モンテディオ山形に入ってから相田さんが実施した取り組みを中心に、今後の展望についても話されていました。もともと楽天イーグルスやヴィッセル神戸などに関わっていたこともあり、クラブ運営についての知見などがあったと思うのですが「色々と変えてくれ」というオーダーを受けてモンテディオ山形にジョインされ、「色々」されたようです。たとえば、オフィスがあまりにも「オープン」すぎるがゆえに情報が筒抜けになっているので「これ、チームとしてまずいね」ということでオフィスの改善をしてセキュリティーレベルの向上をされたり、クラブも結局は売上が大事なので「試合をしていないときにどのようにして売上をあげていくか？」ということを考えてスタジアムの周辺の環境を整備されたりしたようです。印象的だったのは「地域にあってくれてよかった！」と言ってもらえること、そして、「このチームに入りたい！」と選手に思わせることを目指している、ということでした。スクラムフェスのように各地域で行われているスクラムフェスはそれぞれの地域で運営メンバーが異なりますし、同じスクラムフェスという名前を冠していても特色が異なります。そのような独自性をもつ地域スクラムフェスですが、みんな「地域に貢献したい」という思いがあるのではないかと私は思っています。そうした中で、スクラムフェス仙台で相田さんをキーノートにお招きしたのは何か感じるものがありますね。また、相田さんの話をよくよく聞いているとたくさんの改善をされたのですが、その改善の裏には丁寧な観察があったのではないかと推察します。というのも、先ほどのオフィスの話にしても現場に入ってよくよく見てみないと状況はわからないですからね。そのうえで対策を行うという話がまさにスクラムでいうというところの検査と適応なのだなと。

キーノートのあとにネットワーキングパーティーがありました。ここで写真を撮っておかなかったことを後悔していますが、とにかくわいわいやらせていただきました。特に印象に残っているのは、おーのAさんに「お、これは... 『かめり』さんですか？」といういじりですかね。ひらがなで「かめい」と書いたつもりなのですが、字が汚かったようで「い」が「り」に見えたようです。どうですかね？そんなに「り」ですか？

「かめり」？「かめい」？

2日目はいろいろと登壇セッションがありますね。初回は我らが ShinoP の登壇ということで聞いておりました。私はいわゆる「中の人」なので知っている内容ではあったのですが、あらためて聞いてみるとよくまとまっている話でしたね。さっそく資料もアップロードしていただいたみたいです。面白かったのはこれまでの行動を改めて言語化して、「共感性」「透明性」「一貫性」というものにまとめたところですね。誰かがその後質問をされていたのを盗み聞きしたところ、実際に行動を行っていた時はその言語化したことを意識してやっていたわけではない、とのことでした。改めてふりかえって言語化してみた結果、そうした概念にたどりついた、ということのようです。おもしろいですね。もちろん、内容自体の学びもあるのですが、登壇をきっかけに深いふりかえりによる内省が行われ自身の行動が明確化された、というところにも学びがありますね。別に登壇する機会がなくてもこういう内省自体には価値がありそうです。こういう気づきを与えてくれた盗み聞きの会話があるのもカンファレンスの醍醐味ですね。

続いて、りんさんのどうやら人って変われるらしい。一年半コーチングを受けて見つけたコンフォートゾーンの超え方。という登壇を拝見しました。個人的に最近コーチングに興味があって学んでいる最中なのですが、クライアント視点でどう行動変容が行われたのか？という話は非常に学びがあります。コーチ視点だとクライアントの話を聞きながら適切なコーチングのスキルを活用していくことが求められるのではないかと思うのですが、そのコーチのあり方がクライアント側からはどう見えるのか？が垣間見えました。コーチングは共同関係だと思うのですが、まさにコーチだけではなくクライアントの努力があってこその行動変容なんだなと思いました。

お昼の時間帯は「はじめまして！」な方々とランチに行きました。厳密にはみんながみんな「はじめまして！」ではないのですが、まあいいでしょう。たまたま同じグループに地元の方がいらっしゃいましたので「いい感じの」ラーメン屋さんに行きました。おいしかったですね。その後、鯛きちというおみせに行ってずんだ餅のたい焼きを食べました。

午後の時間帯はやはり登壇が行われるのですが、登壇と並行してコーチズクリニック、ワークショップ、フォトブース、OSTが行われます。なお、ワークショップは午前中からありました。本当はでたいワークショップがあったのですが、1日目の時点でほとんどのワークショップが定員に達してしまったので諦めました。私はほとんどOSTを行う部屋で過ごしていましたが、OSTとはいいつつもずっと誰かが話したいテーマを熱く語り合っていたり、たまにリーンコーヒーで構造的に話題を切り替えながら話をしていました。ここではかなりディープな内容を話していたのかなと思います。それこそ登壇では言えないような話とかがあるので、実は結構学びになる場だったかもな、と。

そういえば、スクラムフェス仙台が開催された会場である enspace さんについて話していませんでした。もともと最初のオーガナイザーだった天野さんが「スクラムフェス仙台やりたいなー」という構想段階で「じゃあうちでやりなよ！」と声をかけてくれたのが enspace さんだそうです。場所も日程も決まっていないし、なんならどういうコンセプトで何をやるのかすら決まっていない状態で声をかけてもらった感じみたいですね。 enspace さんはこのように初回からかなり協力的なのですが、実際のスクラムフェス仙台当日の動きについてもかなり協力的です。スクラムフェス仙台ではだいたい運営の方が紫色のTシャツをきていらっしゃるのですが、 enspace のスタッフの皆さんも同じ運営のTシャツをきています。つまり、 enspace のスタッフの方々もスクラムフェス仙台の運営として全面的に協力されていました。 enspace のスタッフさんお二人と話す機会がありました。一人目の方は大学4年生だとのことで、 enspace には大学1年生の頃からインターンとしてお仕事をされているとのことでした。「ここのお仕事はものすごく楽しい」と言っていたのが印象的です。来年からは新社会人として東京の会社に就職されるそうで enspace から離れるのを名残惜しそうに話しておりました。もう一人の方は大学3年生で enspace には大学2年生の頃から関わっているようです。こちらの方も「もうすごく楽しくてくるのが楽しみなんです」ということを言っていました。そして、スクラムフェス仙台が開催される日程が決まると、自分のシフトをそこに合わせるようにしたとのことでした。いわく、「スクラムフェスは楽しい」とのことです。会場を提供しているスタッフの方がこういう風に言ってくれるのは、ただの参加者である私にとってもとてもうれしいですよね。そして、そういう協力を惜しみなく提供する enspace のスタッフの皆さんにも本当に感謝したいです。

ここまでつらつらとスクラムフェス仙台の感想を書いてみました。もちろん、それぞれの登壇にも学びがありましたが、この場自体に存在することそれだけでも学びがありました。スクラムフェス仙台は今回が初めての参加でしたが、また来年も機会があれば行きたいですね。最後に、タイミーのメンバーで撮った写真をはっておわろうと思います。

タイミーからきた参加者の皆さん

【イベントレポート】「AIで変わるPdMの役割 - 思考する力が武器になる」

8月6日、タイミー、UPSIDER、カケハシの3社共催による「生成AI時代のPdM - 活用と未来戦略」と題したイベントが開催されました。本イベントでは、プロダクトマネジメントにおける生成AIの活用と、それに伴うPdMの役割の変化に焦点が当てられました。本レポートでは、タイミーのプロダクトマネージャーである柿谷 樹の講演「AIで変わるPdMの役割 — 思考する力が武器になる」を書き起こし形式でお伝えします。

はい、株式会社タイミーの柿谷と申します。よろしくお願いします。 本日は『生成AI時代のPdM』というテーマで、『AIで変わるPdMの役割 — 思考する力が武器になる』という、少々仰々しいタイトルでお話しします。今回は『思考』をテーマにしたいと思います。

改めまして自己紹介をさせてください。株式会社タイミーでプロダクトマネージャーをしている柿谷です。バックグラウンドとしては、リクルートで新規事業開発を経験後、主にtoB領域のプロダクトマネジメントを5年ほど経験しました。昨年タイミーにジョインし、現在はバーティカルな市場での売上拡大を担当しています。タイミーは2-side-platformですが、toB担当・toC担当のように線を引かず、バリューストリーム（ユーザーに価値が届く一連の流れ）を単位に開発チームを組成しています。そのため、1人のPdMがプラットフォームの両面を横断して見ることが多いです。

それでは本題に入ります。このテーマを考えるにあたり、プロダクト開発の前提が大きく変わる中で、結局PdMに何が残るのかを突き詰めた結果、PdMの価値は『思考』へシフトするのではないかという結論に至りました。本日はその点について重点的にお話しできればと思います。

アジェンダは『思考する』『思考を止めない』『思考環境を整える』の3つです。

1. 思考する ── 文脈を設計し、出力を見極め、対話で共有する

まず『思考する』についてです。『思考とは何か』という話ですが、デカルトの『我思う、故に我あり』といった話ではなく、私が読んだ本の中で非常に的確だと感じた説明を引用します。『思考とは、思考対象に対して何らかの意味を得るために、頭の中で情報・知識を加工すること』です。これは関数的な処理と捉えることができ、事象と知識というインプットからメッセージや意味合いというアウトプットを出すプロセスです。

この構造はAIの処理と似ていますが、本質的に異なる点があります。AIは不完全な入力に対しても、ハルシネーション（もっともらしい嘘）によってそれらしい出力を生成してしまいます。そのため、結局は人間による品質担保が不可欠です。ここに人間の価値が残ると考えており、プロダクトマネージャーには『コンテキスト設計能力』と『出力に対する審美眼』が求められるようになります。

この変化に伴い、ドキュメントの位置づけも変わってきます。アジャイル開発宣言では『ドキュメンテーションよりも対話』とされていましたが、AIに読み込ませるコンテキストが重要になる今、ドキュメントがAIへの重要なインプットとなり、PdMには『Why』を構造化するスキルが求められるようになります。これはPdMの役割が『コンテキストデザイナー』に変わることを意味します。ただ、これはドキュメント主義への回帰ではなく、コミュニケーションの重要性は普遍です。最終的にPdMには『思考の構造化』と『納得を生む対話力』が求められるようになると考えています。

2. 思考を止めない ── 継続的ディスカバリーが競争力の源泉に

次に『思考を止めない』についてです。これからの時代、継続的なディスカバリーこそが競争力の源泉になると考えています。一次情報が非常に重要になります。開発のデリバリー速度が爆発的に向上する中で、ディスカバリーも同じ速度で回す必要があります。そのためには、高速で一次情報に触れられる環境を構築し、そこから得た情報をもとに思考を常にアップデートし続ける仕組みが不可欠です。

では、何が大事かというと、これもAIとは直接関係ない部分もありますが、インタビューのリードタイムを極限まで短縮することです。明日インタビューしたいと思ったら、明日実行できるようなオペレーションを構築することが重要です。その上で、議事録の下書き作成などはAIに任せ、人間は考察に集中できる環境を作ります。そして『オポチュニティ・ソリューション・ツリー（OST）』のような思考フレームワークを活用し、論点を常にアップデートし続けることが重要です。

3. 思考環境を整える ── Bullshit Jobを減らし、意味ある仕事に集中する

最後に『思考環境を整える』についてです。PdMの仕事は『意味を作る仕事』へとシフトしていきます。AIの進化により、議事録作成や会議要約といった戦術的な労働から解放され、PdMは『意味の創造』という、より本質的な価値に時間を充てられるようになります。そのためには、いわゆる『ブルシット・ジョブ（無意味な仕事）』を減らし、思考しやすい環境を整えることが重要です。

チームや組織でAIを活用する方向性は、大きく2つに分けられると考えています。一つは、個人の成功事例を横展開し、チーム全体の生産性を底上げする試み。もう一つは、AI前提のオペレーションを抜本的に設計し直す試みです。まずは個人がアドホックにAIを活用し、そこで得たコンテキストや優れたプロンプトをチームで共有するなど、ボトムアップで進めていくのが現実的でしょう。

まとめ

まとめになりますが、これからのPdMに求められることは、『思考する』『思考を止めない』『思考環境を整える』という3点です。 タイミーは積極採用中です。ご興味のある方は、カジュアル面談からでもぜひお声がけください。ありがとうございました。

hrmos.co

本講演のアーカイブはこちら

本講演の登壇資料はこちら

speakerdeck.com