Timee Product Team Blog

タイミー開発者ブログ

亀井がスクラムフェス仙台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

その情熱に心打たれて〜スクフェス大阪2025での気付き〜

タイミーQAEnablingチームの松田(@yoshi_engineer_)です。

先日、私の地元で開催されたスクフェス大阪に参加してきました!

スクラムフェスに初めて参加したのは去年のスクラムフェス大阪24でして、その時の感動と熱が忘れられず、25年度も参加することに決めました。

www.scrumosaka.org

去年は個人で参加したのですが、今回は弊社のTED10というエンジニアの成長を支える制度を利用して参加させていただきました。 productpr.timee.co.jp

今年のスクラム大阪は去年とはまた違った取り組みも多く、参加者としてはとても満足しておりその取り組みも紹介できればと思います。

コーチーズクリニック~経験豊富なコーチに相談してみよう~

今回スクフェス大阪初の試みのコーチーズクリニック。

他のスクフェスでは何度か開催され、大変好評だったことから今回大阪でも採用されたとのことです。

そして今回はありがたいことにyoh nakamura(@yohhatu) さんとのコーチーズクリニックを受けることができました。

以前から個人的に知っており、大変尊敬するお方でもあったので、とてつもなく緊張していたのですが、温かな笑顔で迎えてくださり、安心して対話し始めることができました。

私のスクラムに関する悩みを傾聴していただき、温かな空気の中、自分でも驚くほど話すことができました。

yohさんが寄り添いながら相槌を重ね、「どうして松田さんはそう思ったのかなー?」「松田さんの中でどうやったらもう少し良くできるだろう?」私が悩みを伝える中で、的確なタイミングで問いをいただきました。その答えも「あ,,,,じゃあ、こうしたら良いかも…!」と1人では気付けなかった(確信が持てなかった)仮説に自分から気づき言葉にすることができました。

ほとんど私の話だけで終えてしまったコーチングの時間でしたが、yohさんから「スクラムをする時、大事なのは、強い情熱持つことだよ。」と一言いただきました。

その言葉を聞いて、私はグーっと体の芯から力が湧き起こるような感覚になりました。

自分が困難な時、挫けそうになった時、yohさんからもらった言葉をお守りに頑張ろうと思います。

yohさん、有意義なお時間いただき本当にありがとうございました!

私の心を打ったsession

アジャイル、諦めなかった10年 JTC,SIer,受託で挑んだリアル

confengine.com

JTC,SIer,受託会社の3社でアジャイル開発を推進を試みてきたOshikata(@oshikata200)さん。この登壇はまさに理想と現実の中で泥臭く実践を行ってきたOshikataさんの10年間の軌跡を赤裸々に語っていただきました。

このセッションで話された内容は一言で言えば「組織改革への実践知」です。

「置かれた場所で咲く」よりも「咲ける場所を探す」べきなのか

Oshikataさんはこれまで組織にアジャイルを導入すべく何度も奮闘してこられたのですが、組織の習慣や形態により導入するにあたって何度も壁にぶつかりました。

しかし、Oshikataさんの気づきはこうでした。

ソリューションやプラクティスを導入することを重視するのではなく、まずチーム、そして組織文化へのアプローチが必要。また、それは長い時間をかけて少しずつ行うことが重要。

失敗を恐れず、「増やす」から、「手放す」へ

企業の特性上、ドキュメントやルールが加速度的に増える現状があります。その背景には「過剰な失敗への回避」がそうせてる可能性があります。

しかし、そこで増えたドキュメントやルールは逆にメンバーやチームへの足枷になり速度と自立性を失わせます。

資産と思い積み重ねたものは、いつの間にか負債に変容。

現状を打破するためにも、形骸化されたルールやドキュメントを減らすことを推進されました。

負債を大きくするよりも、動きやすくするために手放すことを実践されました。

詰め込みすぎた制度,ルールがあるとそこから試行錯誤する姿勢が損なわれていきます。

“人を囲う”より,”みんなで空気を耕す”

「メンバーへの執着を手放す。そうではなく組織の空気を耕す」メンバーに執着することで自分のチームだけを囲うことは、長期的に見れば組織の衰退を助長します。

そうではなく、できる人材こそどんどん他の部署やチームに手放す。そしてまた新たなメンバーと対話し、組織の空気を耕していく。

それを体現するためにも、個人への信頼関係の構築が肝になる。

信頼関係の気付けた組織を耕し、メンバーがある範疇の制度の中でワークすることで工夫が行わられる。

「“強い個”を集めるのではなく、“みんな”で空気を耕す。

少しずつ、一歩一歩確実にみんなで進むことから風土が醸成されていく」

一朝一夕で組織は変わらないが、その一つ一つの積み重ねを愚直に行うことで芽が開く。とてつもなく大きい情熱を持って歩んでこられたOshikataさんのsessionは大きな学びと気づきを与えてくださいました。

困難な状態も、組織の実態もマイナスな要素をあげればキリがない状態であったとしても、少しずつ改善を重ね進まれていく姿が、今度は自分も頑張ろう!と心に火が灯るような感覚を覚えました。

おわりに

今回のスクラムフェスでも大変大きな気づきと学びを得ることができました。

この気づきと学びを活かして、より精進していきたいと思います!

いつか私も聴講者としてではなく、登壇者としてスクラムフェスに寄与できればと思います!

部署横断で学びを加速する。タイミー物流業界勉強会レポート

こんにちは。データアナリストのtomitaです。
先日、社内のPdM(プロダクトマネージャー)とアナリストが中心となり、当社にとって重要な業界の一つである物流業界に関する勉強会を開催しました。
今回は、その内容と、そこで見えてきた当社の魅力についてご紹介したいと思います!

生成AIを駆使した『AI駆動勉強会』

今回の勉強会で最も特徴的だったのが、生成AIを活用した新しい学習スタイル『AI駆動勉強会』です。
これは、参加者各自がリサーチクエスチョンを設定し、それに対して生成AIを使って調査を行い、アウトプットと深掘りを行うスタイルです。
生成AIを使うことで、これまで何時間もかかっていた情報収集を短縮し、より本質的な議論に時間を割けるようにしました。

勉強会の様子

『AI駆動勉強会』の進め方

  1. リサーチクエスチョンを立てる (5分):各自が知りたいテーマについて具体的な問いを立てます。
  2. AIで調査する (15分):生成AIを使い、設定した問いについて効率的に情報を収集します。
  3. アウトプット&質問深掘り (2分):調査結果を簡潔にまとめ、参加者と共有。疑問点やさらなる深掘りについて議論します。

このセッションを1.5〜2時間で2〜3回繰り返すことで、短時間で多くの学びを得ることができました。

参加者からの声

  • 「リサーチクエスチョンを先に立てることで、集中して学習できた!」
  • 「アウトプットと質問深掘りの時間で、学習内容がより深く定着した」
  • 「AI活用の練度が上がり、効果的なプロンプトなどの知見が共有されたのが良かった」
  • 「他の人のリサーチクエスチョン自体に学びがあり、視野が広がった」

部署を超えたメンバーとの交流

今回の勉強会には、アナリストだけでなく、PdMや元CSM(カスタマーサクセスマネージャー)で物流業界に詳しいメンバーまで、幅広い職種のメンバーが参加しました。
例えば、元CSMのメンバーからは、物流現場でのリアルな課題が共有され、AIによるリサーチだけでは得られない学びがありました。
多角的な視点からの議論は、私たちデータアナリストがデータから導き出したインサイトを、プロダクト改善やビジネス戦略に繋げる上で不可欠です。異なる専門性を持つメンバーと気軽に意見交換できる環境は、当社で働く大きな魅力の一つだと改めて感じました。

リモート参加も可能な柔軟な働き方

今回の勉強会では、多くのメンバーがオフィスに集まりました。私自身は家庭の事情でリモートでの参加でしたが、オフィスにいるメンバーと変わらず、活発な議論ができました。
当社のプロダクト組織では、働き方の柔軟性を担保する観点から、リモートワークOKとなっています。場所や時間にとらわれずに質の高いインプットとアウトプットができるのは、非常にありがたい環境です。

終わりに

今回の物流業界勉強会は、当社のPdMとアナリストが中心となり、生成AIを駆使した独自のスタイルで実施しました。AIで調査を進め、その結果をアウトプット・深掘りすることで効率的に物流業界への理解を深めることができました。
また、部署を超えて様々な職種のメンバーが参加することで、AIだけでは得られない物流現場でのリアルな課題が得られたり、多角的な視点からの議論ができたりしました。

We’re Hiring!

私たちは、ともに働くメンバーを募集しています!!
カジュアル面談も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。

GitHubマージキューのエラー通知

こんにちは、タイミーでPlatform Engineerをしている近藤です。

マージキュー上のエラー通知について

GitHubのマージキューは、チームが効率的かつ安全にコードをリリースするために欠かせない仕組みです。特に、大規模なチームや頻繁にコードをデプロイするプロジェクトでは、マージキューがCI/CDプロセスの核となります。しかし、マージキュー上でエラーが発生した際、その通知を迅速に受け取ることが極めて重要です。通知が遅れたり、見落とされたりすると、次のような問題が生じる可能性があります。

リリースの遅延

エラーが発生すると、問題のある変更は差し戻されます。
その結果、後続のPRのベースが変更されるため、マージキュー上でのCI処理を再実行する必要が生じます。
これにより、本来スムーズに進むべきリリースサイクルが停滞し、開発スピードが著しく低下します。

開発者体験(DX)の低下

マージキューでのエラー通知が適切に行われないと、開発者が混乱したり、不要な手戻り作業を強いられたりします。これにより、開発者のモチベーションや生産性の低下を招くことにもなります。

以上の理由から、GitHubのマージキューでエラーが発生した際の通知を確実に行うことは、開発効率を保ち、迅速な問題解決を促すために不可欠です。通知の仕組みを整備し、チーム全体が即座に問題に対処できる環境を整えることが求められます。

エラー通知の課題

単にワークフロー中にエラー通知のジョブを入れるだけでは、先行してマージキューに積まれたPRにCIエラーが発生する内容が含まれている場合、後続の人にも不要なエラー通知が届いてしまいます。これを回避するために、GitHubのconcurrency機能を活用してCIを適切にキャンセルする仕組みを導入しました。

sequenceDiagram
    autonumber
    participant DevA as 開発者 A
    participant DevB as 開発者 B
    participant Queue as マージキュー
    participant CI as CI (GitHub Actions)
    participant Master as master ブランチ

    DevA->>Queue: PR A をキューに追加
    DevB->>Queue: PR B をキューに追加

    par
        Queue->>CI: PR A + master のテスト
        Queue->>CI: PR B + PR A + master のテスト
    end

    CI--x Queue: PR A + master でテストエラー

    Queue->>DevA: PR A がテストエラーになりました
    Queue->>DevB: PR B がテストエラーになりました

    Queue->>Queue: PR B + master の再エンキュー
    Queue->>CI: PR B + master のテスト
    CI-->>Queue: PR B のテスト合格

    Queue->>Master: PR B を master にマージ

PR AとPR Bがマージキューに積まれた状態で、先行するPR Aでエラーが発生すると、PR Bは自動的にPR Aの内容を除外した状態で再度マージキューに入れられます。 この際、マージキューの実行時に作成されるブランチ名は都度変化します。よって単純にブランチ名をキーとした以下の設定では、期待通りに動作しません。

concurrency:
  group: ${{ github.ref_name }}
  cancel-in-progress: true

そこで、マージキュー上で作成されるブランチ名の規則性を利用します。ブランチ名にはPR番号が含まれているため、ワークフロー内でブランチ名からPR番号を抽出するジョブを追加しました。 最終的に採用したワークフローは以下の通りです。意外と知られていませんが、concurrencyキーワードはジョブレベルでも指定可能です。

name: ci

on:
  push:
    branches:
      - '**'
      - '!master'
      - '!gh-readonly-queue/**'
    tags-ignore:
      - '*'
  merge_group:

permissions:
  id-token: write
  contents: read
  pull-requests: write

jobs:
  concurrency_key:
    runs-on: ubuntu-latest
    outputs:
      key: ${{ steps.extract_pr.outputs.key }}
    steps:
      - id: extract_pr
        name: Extract PR number from branch name
        shell: bash
        run: |
          if [[ ${{ github.event_name }} == 'merge_group' ]]; then
            full_ref="${{ github.ref_name }}"
            pr_number=$(basename "$full_ref" | cut -d- -f2)
            echo "key=$pr_number" >> "$GITHUB_OUTPUT"
          else
            echo "key=${{ github.ref }}" >> "$GITHUB_OUTPUT"
          fi

  ci:
    needs: concurrency_key
    concurrency:
      group: ${{ github.workflow }}-${{ needs.concurrency_key.outputs.key }}
      cancel-in-progress: true
    uses: ./.github/workflows/_ci.yml
    with:
      skip: ${{ github.event_name != 'merge_group' }}
    secrets: inherit

  merge_group_notify:
    needs: ci
    if: ${{ failure() && github.event_name == 'merge_group' }}
    uses: ./.github/workflows/_merge_group_notify.yml
    with:
      role_to_assume: arn:aws:iam::012345678901:role/example
      notification_type: failure
    secrets: inherit

上記の仕組みを導入することで、先行するPRでテストエラーが発生しても、その影響で後続PRに対して不要なエラー通知が送信されることを防げます。

sequenceDiagram
    autonumber
    participant DevA as 開発者 A
    participant DevB as 開発者 B
    participant Queue as マージキュー
    participant CI as CI (GitHub Actions)
    participant Master as master ブランチ

    DevA->>Queue: PR A をキューに追加
    DevB->>Queue: PR B をキューに追加

    par
        Queue->>CI: PR A + master のテスト
        Queue->>CI: PR B + PR A + master のテスト
    end

    CI--x Queue: PR A + master でテストエラー

    Queue->>DevA: PR A がテストエラーになりました

    Queue->>Queue: PR B + master の再エンキュー
    alt 失敗通知をキャンセル
        Queue -x DevB: PR B がテストエラーになりました (キャンセル)
    end
    Queue->>CI: PR B + master のテスト
    CI-->>Queue: PR B のテスト合格

    Queue->>Master: PR B を master にマージ

ただし、PR AとPR Bがほぼ同時にマージキューへ投入された場合など、極めて稀なタイミングによっては、キャンセル処理が間に合わず後続のPRに対して不要なエラー通知が送信されてしまうケースが残ってしまいます。 こうしたエッジケースまで完全に抑制しようとすると、ワークフロー全体の実装が大幅に複雑化し、運用・保守コストも増大してしまう懸念があります。 そのため、今回は「不要な通知の発生を現実的な範囲で最小化しつつ、実装のシンプルさを優先する」という方針を選択しました。

まとめ

本仕組みによって、マージキュー運用時の不要なエラー通知を大幅に削減しつつ、チーム全体の開発効率と安心感を両立できるようになりました。 今後も、より良い開発体験を目指して、現場の実情やフィードバックを取り入れながら、継続的な改善を進めていきます。

GitHubマージキューTIPS:キューの詰まりを可視化し、デプロイフローを最適化する

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

GitHubマージキューTIPSシリーズ、前回までに、マージメソッドの制約やCIの高速化といったTIPSを共有してきました。今回は、マージキューのポテンシャルを最大限に引き出すためのパラメータチューニングと、そのために不可欠なキューの状態の可視化について解説します。

デプロイ効率と安定性のトレードオフ

マージキューには、その挙動をコントロールするためのいくつかのパラメータが存在します。

  • Build concurrency:マージキューのCIを同時に実行する並列数。
  • Minimum/Maximum pull requests to merge:一度のデプロイ(マージ)に含めるPRの最小数と最大数。

これらのパラメータは、効率性と安定性という、二つの相反する要素を調整するために使用します。

  • 効率性(デプロイの速さ):開発者の待ち時間を短縮するため、PRを迅速にマージすることが求められます。
  • 安定性(変更の分離):問題発生時の影響範囲を限定し、原因特定を容易にするため、一度にマージする変更は少なくすることが望ましいです。

例えば、Maximum pull requests to merge を10に設定するとデプロイのスループットは向上しますが、障害発生時には10個のPRの中から原因を特定することが困難になります。逆に1に設定すると、原因特定は容易になりますが、PRが多数待機している場合に待ち時間が増加します。

キューの長さを計測する必要性

この関係を考慮してパラメータを調整するには、「現在のマージキューで待機しているPRがどの程度あるか」というデータが必要です。キューに待機しているPRがなければ設定を変更する必要はありませんが、常に多数のPRが待機している場合は、CIの並列数を増やすなどの対策を検討する必要があります。

しかし、キューの長さや待ち時間といった情報は、GitHubの標準機能では提供されていません。このため、キューの長さを計測し、可視化する仕組みを構築しました。

キューの長さを計測する方法

私たちのチームでは、GitHub Actionsを利用してキューの長さを計測し、Datadogへ送信しています。

その実装で利用している方法を紹介します。

ghコマンドによるキュー長の取得

GitHubマージキューの現在の長さは、GitHubのGraphQL APIを通じて取得できます。ghコマンドを使えば、これを1行のコマンドで簡単に行えます。

使用するコマンドは以下の通りです。

QUEUE_COUNT=$(gh api graphql -f query='
  query {
    repository(owner: "THIS_IS_ORG_NAME", name: "THIS_IS_REPO_NAME") {
      mergeQueue(branch: "DEFAULT_BRANCH_NAME") {
        totalCount: entries {
          totalCount
        }
      }
    }
  }
' --jq '.data.repository.mergeQueue.totalCount.totalCount')

このコマンドは、GraphQLクエリで必要なデータ (totalCount) を指定し、ghコマンドの--jqフラグでレスポンスから値を直接抽出しています。

このコマンドを、on.merge_group(PRがマージキューに追加された時)をトリガーにしたGitHub Actionsで実行します。その結果をモニタリングツール(私たちの場合はDatadog)に送信することで、キューの長さを時系列グラフとして可視化できます。

マージキューに入っている Pull Request の数の時系列グラフ

このダッシュボードによって「どの時間帯にマージが集中するのか」「現在のパラメータ設定でキューが効率的に処理されているか」といった状況を把握できるようになりました。

データに基づくパラメータ調整の実際

このダッシュボードを2週間運用した結果、私たちのチームでは同時にマージキューに積まれていたPRは最大でも3件であることが分かりました。

この実績データに基づき、安定性をさらに高めるため、パラメータを以下のように調整しました。

  • Maximum pull requests to merge: 変更前 5 → 変更後 3
  • Build concurrency: 変更前 10 → 変更後 6

一度にマージするPR数を実績値(3件)に合わせ、ビルドの並列数(Build concurrency)をその2倍に設定しました。これにより、リソースを効率的に使いつつ、より安定した運用を目指しました。

まとめ

マージキューは導入するだけでも一定の効果がありますが、その効果を高めるには、開発の規模や状況に応じてパラメータを継続的に調整することが重要です。その調整は、勘や感覚ではなく、今回紹介したような可視化されたデータに基づいて行うことが推奨されます。

今回はキューの可視化とパラメータ調整について解説しました。次回以降も、マージキューをより効果的に活用するための情報をお届けします。

GitHubマージキューのRulesetsの非互換性:bypass機能が使えなくなる問題

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

このシリーズでは「モノリスRailsにマージキューを導入してデプロイフローを安定させる」の続編として、導入時のTIPSを紹介しています。前回は「GitHubマージキューTIPS:CIの実行を最適化し、障害対応を10分高速化する」について解説しました。

本記事では、GitHubのマージキュー導入後に発生した、ブランチ保護機能(Ruleset)のbypass list機能との非互換性について解説します。

これまでのコードフリーズ運用

タイミーでは、主に年末年始やGWといった開発者が少ない期間にコードフリーズ期間を設けています。この運用を実現するため、我々はGitHubのRulesetsと、そのbypass list機能を活用していました。

これは非常に便利な機能で、以下のような運用を可能にしています。

  • 通常時: 開発者は自由にマージできる。
  • コードフリーズ期間中: Rulesetを有効化し、原則マージを禁止する。
  • 緊急時: ただし、bypass listに登録された開発者のみ、チェックボックス一つでこのルールを回避し、緊急の修正をマージできる。

この仕組みで、コードフリーズ期間中の安全性と、緊急時の柔軟な対応を両立していました。

マージキュー導入後に発覚した問題

マージキューを導入し、順調に運用が始まったかのように思えたある日、コードフリーズ期間直前に問題が発覚しました。

bypass listに登録されているにもかかわらず、ルールを回避してマージすることができなくなっていたのです。

コードフリーズ期間中にコードを変更することは基本ありませんが、例えば障害対応で緊急の修正が必要になった際に、これまでのように特定の担当者が即座にマージできなくなる、という影響が考えられます。これは、柔軟な対応を期待していた開発者にとっては意図しない仕様変更でした。

原因と対応

仕様上の非互換性

調査の結果、マージキューとRulesetのbypass機能は併用できないGitHubの仕様であることが分かりました。この件はGitHubの公式Discussionでも報告されています。

ref. https://github.com/orgs/community/discussions/45208

この仕様に対する直接的な解決策は見つからなかったため、bypass listを使用しない運用への変更が必要になりました。

新しい運用への変更

代替案として、以下の運用を構築しました。

  1. コードフリーズ期間中、常に失敗するCIジョブをワークフローに追加する。
  2. ただし、このCIジョブはブランチ保護ルールの必須チェックには設定しない

これにより、開発者はCIの警告表示からコードフリーズ期間中であることを認識でき、意図しないマージの抑止につながります。

まとめ

GitHubのマージキューは有用な機能ですが、Rulesetのような既存の機能と組み合わせる際には、意図しない動作をしないか注意が必要です。(この記事は2025年7月時点のGitHubの仕様に基づいています。)

私たちのケースでは、導入後にこの問題が判明し、コードフリーズ直前の対応が必要となりました。

マージキューの導入を検討する際は、通常のデプロイフローだけでなく、コードフリーズのような特定の運用条件下でも意図した通りに動作するか、事前に検証することを推奨します。

特に、ご自身のチームが以下の点に当てはまるか、一度確認してみてください。

  • ブランチ保護(Rulesets)で、特定の担当者やチームにマージの例外(Bypass)を許可しているか?
  • その例外的なマージは、緊急時の対応など、今後も必要な運用か?

私たちのケースでは、導入後にこの問題が判明し、コードフリーズ直前の対応が必要となりました。

さて、次回はマージキューのポテンシャルを最大限に引き出すための「詰まり具合の可視化」と、パラメータチューニングについてご紹介します。