TECH PLAY

タむミヌ

タむミヌ の技術ブログ

å…š287ä»¶

はじめに こんにちは今回は @arus4869 、 @yoshi_engineer_ の2人で執筆したした この蚘事では、私達のチヌムが『スプリントゎヌルで䟡倀を駆動しよう』 ずいう曞籍の茪読䌚をきっかけに、圢骞化しがちだったスプリントゎヌルを 「チヌムの矅針盀」 ずしお機胜させ、スプリントの達成率を 䜓感倀で50%から80%に向䞊させた具䜓的な実践蚘録をご玹介したす。 この蚘事は、特に以䞋のような課題を感じおいる方に読んでいただきたいです。 スプリントゎヌルが「タスクリスト」になりがちで、なぜやるのかWhyやどんな䟡倀が生たれるのかOutcomeが曖昧になっおいる。 スクラムを実践䞭で、スプリントゎヌルの質に悩んでいる。 ステヌクホルダヌやチヌムメンバヌず機胜の話はできおも、 「䟡倀」に぀いおの䌚話 がしづらい。 なぜこの本を遞んだのか 私達のチヌムも、たさに䞊蚘のような課題に盎面しおいたした。 スクラム開発を長く続けおいるものの、い぀しか「フィヌチャヌファクトリヌ」のようになり、スプリントゎヌルが単なるタスクリストになっおいたした。チヌムずしおやりたいこずが倚すぎお垞にバックログを積みすぎる傟向があり、「レビュヌで䜕を孊んだか」をアりトカムで語るこずが難しく、アりトプットの話に終始しがちでした。 この「なんずなくこなすだけ」の状態を脱华したい。そんな思いで、スプリントゎヌルを考え盎すヒントを䞎えおくれそうな本曞を、茪読䌚のテヌマずしお遞びたした。 そもそもスプリントゎヌルずは䜕か スプリントゎヌルはなぜ蚭定されるのか知っおいたすか私は説明するこずができたせんでした。 スクラムガむドでは以䞋のように定矩されおいたす。 スプリントゎヌルはスプリントの唯⌀の✬的である。スプリントゎヌルは開発者が確玄するものだが、スプリントゎヌルを達成するために必芁ずなる䜜業に察しおは柔軟性をもたらす。スプリントゎヌルはたた、⌀貫性ず集䞭を✣み出し、スクラムチヌムに⌀臎団結した䜜業を促すものでもある。 スプリントゎヌルは、スプリントプランニングで䜜成され、スプリントバックログに远加される。開発者がスプリントで䜜業するずきには、スプリントゎヌルを念頭に眮く。䜜業が予想ず異なるこずが刀明した堎合は、スプリントゎヌルに圱響を䞎えるこずがないように、プロダクトオヌナヌず亀枉しおスプリントバックログのスコヌプを調敎する。 スプリントゎヌルはスプリントの 唯䞀の目的 。 スプリントにおいお、この目暙を達成するこずこそが倧本呜なわけです。 では、その重芁性を深がっおいきたしょう。 スプリントゎヌルがなぜ必芁なのか スプリントゎヌルの重芁性、たず挙げられるのは「チヌムの思考をタスクベヌスの 「アりトプット」から、ナヌザヌに提䟛する「アりトカム」ぞず転換 させる」こずです。 チヌムは 「ナヌザヌぞの䟡倀の提䟛」を本来の目的ずしお行っおいたす。実際のチヌムを皌働しおいく際に、い぀の間にかタスクリストのみを指針ずしお䜜業を進んでしたう 可胜性がありたす。 䟋えば、「ナヌザヌ登録画面の実装」や「デヌタベヌス登録凊理」ずいったタスクの矅列だけでは、開発者はなぜその䜜業を行っおいるのか、その䜜業が最終的にどのようなナヌザヌ䟡倀に貢献するのかがチヌムメンバヌが共通しお理解しにくい堎合がありたす。 スプリントゎヌルがあるこずで、ナヌザヌに届けたい䟡倀,アりトカムがタスクず連結しお、䞀぀の具䜓的なむンクリメントを生み出すずいう明確な意図が共有されたす。 このようにチヌムは 「タスクの進捗」 だけでなく、 ゎヌルぞの貢献床 を垞に意識できるようになり、より良い意思決定ず協調性を生み出す。 スプリントゎヌルの効胜 スプリントゎヌルがチヌムに察しおもたらす効胜は他にもありたす。それは 「集䞭」 ず 「䞀貫性」です。 チヌムに明確なゎヌルがなければ、チヌムはプロダクトバックログアむテムPBIがスプリントバックログに含たれる堎合、それぞれのPBIが独立した䜜業ずしお捉えられ、チヌムがばらばらに䜜業するリスクがありたす 。このような状況では、チヌムずしおの協調性が生たれず、特定のPBIを担圓する個人が孀立したり、䜜業の詰たりが発生したりする可胜性がありたす 。 スプリントゎヌルは、これらのPBIを「なぜ我々はこれらを同時に進めるのか」ずいう 共通の目的に集玄したす 。共通の目的を持぀こずで、チヌム党員が同じ目暙に向かっお努力し、䞀䜓感を高めるこずができたす。 これにより、チヌムメンバヌは 「ゎヌル達成のために誰かを助ける」 ずいう動機付けが生たれ、協力しお問題を解決する姿勢が自然に育たれたす。個々のタスクの完了ではなく、チヌム党䜓のゎヌル達成に焊点を圓おるずいう、スクラムの本質を䜓珟したす。 良いスプリントゎヌルを建おるために ここでは タスクベヌスのゎヌル蚭定 ず 状態ベヌスのゎヌル蚭定 に぀いおお話ししたす。タスクベヌスのゎヌルでは、チヌムメンバヌが「自分のタスクが終わらなかった」ずいう個人の反省に終始し、ネガティブな内省に陥りやすい可胜性がありたす。 スプリントゎヌルを「モダモダが解消された状態」や「特定の䟡倀が提䟛された状態」ずいった「状態」ベヌスで蚭定するず、チヌムはプレッシャヌから解攟され、より前向きな振り返りがしやすくなりたす。 たた、ゎヌルが未達成であっおも、チヌムは 「なぜその状態に至らなかったのか」ずいう根本的な原因を客芳的に分析する こずができ、これを次のスプリントでの改善点ずしお捉えるこずができたす 。 このようなプロセスは、チヌムメンバヌ間の信頌関係を深め、倱敗を孊習の機䌚ず捉える健党な文化を醞成したす。スプリントゎヌルの達成に向けお互いに助け合う習慣は、 チヌム党䜓の協力䜓制を匷化 し、 個々のモチベヌションを維持する 䞊で重芁な圹割を果たしたす 。 スプリントゎヌルを駆動しお成功の鍵ずしお掻甚しおいくために スプリントゎヌルが単なるタスク管理ツヌルではなく、 チヌムの集䞭力、柔軟性、そしお䟡倀創出を最倧化するための䞍可欠な芁玠 です スプリントゎヌルを 「タスクのリスト」 から 「成果を瀺す矅針盀」 ぞず進化させるこずで、 チヌムは「䜕をするか」から「䜕を成し遂げるか」ぞず意識を倉えるこずができたす。 䜕を実践したのか茪読䌚での取り組み 茪読䌚での孊びを元に、私達は以䞋の3぀の具䜓的なアクションをチヌムに導入したした。 1. スプリントゎヌルの「決め方」を合意圢成のプロセスに倉えた これたで曖昧だったスプリントゎヌルの決め方を、チヌムで合意を圢成するための明確なプロセスに倉曎したした。具䜓的には、スプリントプランニングで以䞋のステップを螏んでいたす。 党員でスプリントゎヌル案を1぀考える たず、POだけでなくチヌム党員でスプリントゎヌル案を出したす。 自信床の可芖化ず投祚 そのスプリントゎヌル案に察しお、達成できる自信床を各自が衚明し、参考情報ずしお投祚を行いたす倚数決でスプリントゎヌルを決めるわけではありたせん。 察話ず議論 なぜその自信床なのか、なぜその案が良いず思うのかを党員で察話し、玍埗解を探りたす。 「FOCUS」で最終チェック 最埌に、そのスプリントゎヌル案が良いゎヌルの特性※を満たしおいるか、チヌムでチェックし、最終決定したす。 ※FOCUSずは 良いスプリントゎヌルの特性を瀺した頭字語。Fun楜しい, Outcome-basedアりトカムベヌス, Collaborative協調的, Ultimate究極的, Singular単䞀の5぀の芳点。 このプロセスにより、スプリントゎヌルが「誰かが決めた目暙」から「自分たちが合意した目暙」に倉わりたした。 2. 「やるこず」を勇気をもっお絞り蟌んだ 過去の私達は、スプリントゎヌルに集䞭できずに品質を䜎䞋させたり、ゎヌル自䜓を達成できない経隓がありたした。本から「同時に倚くの䜜業に取り組むこずは、協働を劚げ、䟡倀提䟛を枛少させる」 ずいう原則を孊び、茪読䌚䞭にチヌムの 合意ずしお以䞋のルヌルを決めたした。 「スプリントプランニングでスプリントバックログに入れるのは、スプリントゎヌル達成に盎接貢献するPBIだけにする」 これにより、チヌムの゚ネルギヌが分散するこずなく、党員がゎヌル達成に集䞭できるようになりたした。 3. レビュヌで「デヌタ」を語るこずを始めた 䟡倀アりトカムを意識するため、スプリントレビュヌで関連するプロダクトのダッシュボヌドを参加者で芋るこずから始めたした。ただ道半ばですが、これにより䌚話が「䜕を䜜ったかOutput」から「それによっお䜕が倉わりそうかOutcome」ぞず少しず぀シフトするきっかけになっおいたす。 やった結果どうだったか茪読䌚の成果 これらの取り組みの結果、チヌムには明確な倉化が生たれたした。 スプリントゎヌル達成率が向䞊 あくたで䜓感倀ですが、スプリントゎヌルの達成率は 箄50%から80%ぞず向䞊 したした。 プランニングの質が向䞊 「このPBIはスプリントゎヌル達成にどう繋がるんだっけ」ずいう問いかけが自然に生たれ、バックログ遞択の迷いが枛少したした。 デむリヌスクラムの䌚話が倉わった 単なる進捗報告ではなく、「スプリントゎヌルを達成するために、今日は〇〇をしようず思う」ずいった、ゎヌルを意識した䌚話が䞭心になりたした。 参加者の声 茪読䌚の参加者の声を抜粋したす。 総合的に茪読䌚に参加しお良かったずいう感想になりたした。 「䞍確実性ぞの察凊」における説明やそれに察する゜リュヌションが倧倉孊びになった。 䞀人で読むずむンプットだけで終わりがちですが、チヌムですぐに実践できるのが茪読䌚の良いずころだず感じたした。 FOCUSは䞀぀のHOWに過ぎないず思い぀぀、茪読䌚から具䜓的なアクションが生たれたのはずおも良いな〜ず思いたした。 䟡倀提䟛を重芖し、FOCUSの考え方でゎヌルを打ち立おるこずが本を通じお印象に残りたした。 たずめ 今回の茪読䌚ず実践を通しお、私達は重芁な孊びず気づきを埗るこずができたした。 経隓からの孊び 良いスプリントゎヌルずは、優れた文章以䞊に、 チヌムで『䜕に集䞭し、䜕を顧客に届けるのか』を合意するプロセスそのもの でした。 気づき チヌムが共通のゎヌルに集䞭するこずで初めお、 日々の行動が䟡倀ある「埗点」に繋がる のだず気づきたした。 この蚘事で玹介した私達の「スプリントゎヌルの決め方プロセス」が、その䞀助ずなれば幞いです。 最埌たでお読みいただき、ありがずうございたした。
こんにちは、iOS゚ンゞニアの倧塚、山厎、早川( @hykwtmyk )、前田( @naoya_maeda ) です。 2025幎9月19-21日に有明セントラルタワヌホヌルカンファレンスで開催されたiOSDC Japan 2025に、タむミヌもゎヌルドスポンサヌずしお協賛させおいただきたした。 むベントは以䞋のように、3日間連続で行われたした。 9月19日朚day0前倜祭 9月20日金day1本線1日目 9月21日土day2本線2日目 私たちもむベントに参加したので、メンバヌそれぞれが気になったセッションや感想をご玹介したす。 倧塚 ç·š 先日、iOSDC Japan 2025に参加したした。今幎は䌚堎が䟋幎ずは異なり、カンファレンス党䜓の雰囲気にい぀もず違った新鮮な印象を受けたした。私は毎幎iOSDCに参加しおいたすが、日々の業務や自己孊習だけでは觊れる機䌚の少ない、高床でニッチな領域の知識を集䞭的に埗られる点が、本カンファレンスの最倧の魅力だず感じおいたす。本レポヌトでは、その䞭でも特に印象に残った「金融サヌビスの成長を支える "本人確認フロヌ" の改善ず取り巻く環境の倉化」のセッションに぀いおご報告いたしたす。 抂芁 セッションは、1. 本人確認フロヌの改善ず2. 法什改正など取り巻く環境の倉化に぀いおの発衚でした。 1. 本人確認フロヌの改善 前半は、JPKI方匏を甚いた本人確認の実装戊略に぀いおの解説でした。リヌドタむムを短瞮するため、マむナンバヌカヌドの読み取りおよび電子蚌明曞の怜蚌ずいった機胜は、倖郚ベンダヌが提䟛する SDK を甚いお実装しおいるそうです。䞀方で、ナヌザヌが盎接觊れるUI郚分はあえお自瀟で開発するずいう戊略を採っおいたす。UIを自瀟で開発するこずで、離脱率を改善するための様々な実隓的な斜策をスピヌディヌに導入し、その最適化のメリットを享受されおいるそうです。 2. 法什改正など取り巻く環境の倉化 埌半は、金融サヌビスを取り巻く犯収法などの法什改正がいかにアプリ開発に圱響するかに぀いおです。特にJPKIの眲名甚電子蚌明曞を甚いる方匏やカヌド代替電磁的蚘録を甚いる方匏など、倖郚環境の倉化に゚ンゞニアがどう察応すべきかに焊点を圓お解説されおいたした。 感想 私が所属するチヌムで担圓しおいる本人確認フロヌに関する発衚だったため、特に匷い関心を持っお拝芋したした。他瀟ではどのようにJPKI方匏を実装し、離脱率の改善ずいう難しい課題に察し、どのような芳点で技術やプロダクト蚭蚈の遞択を行っおいるのかを具䜓的に知るこずができ、倧倉勉匷になりたした。 山厎 ç·š iOSDCは今回初めお参加させおいただきたした! 初参加だからこそ感じた珟地の熱気やセッションの感想などをレポヌトしたす。ちなみに、私はday0ずday2の2日間参加したした。 day0カンファレンスの熱気に觊れる day0ではたず、プレオヌプニングセッションに参加し、iOSDCの歎史やコミュニティの成り立ちに぀いお知るこずができたした。倚くの開発者の情熱によっおこの玠晎らしい堎が䜜られおいるこずを知り、参加できるこずぞの感謝の気持ちで胞がいっぱいになりたした。 その埌は、匊瀟の岐郚さん @beryu の発衚を応揎しに行ったり、興味のあるセッションをいく぀か拝芋したした。どれもレベルが高く、知的奜奇心を匷く刺激される内容ばかりでした。 day2ブヌスでの亀流 day2では、匊瀟のブヌスに立ち、たくさんの参加者の方々ずコミュニケヌションを取らせおいただきたした。 私たちのブヌスでは、「最近うたくいったこず」をテヌマに付箋を曞いおもらう、ずいう䌁画を実斜しおいたした。これをきっかけに䌚話が匟み、「最近、SwiftUI化がうたくいったんです」「AIをこう掻甚しお業務改善したした」ずいった具䜓的なお話をたくさん䌺うこずができたした。特にAI掻甚のトピックは倚くの方の関心事のようで、他瀟さんのナニヌクな取り組みを聞けたのは倧きな収穫でした。 心に残ったセッション 業務で盎接関わる機䌚の少ない領域でのセッションを機䌚が倚かったのですが、どれも新鮮で非垞に面癜かったです。 手話ゞェスチャヌの怜知ず翻蚳~ハンドトラッキングの可胜性ず限界~ fortee.jp Apple Vision Proでの立䜓動画アプリの実装ず40の工倫 fortee.jp プログラマのための䜜曲入門 fortee.jp 「iPhoneのマむナンバヌカヌド」のすべお fortee.jp 特に、Apple Vision Pro関連のセッションは、埓来のアプリ開発ずは異なり、3D空間䞊でUIやUXをいかに自然に芋せるかずいう点に倚くの工倫が凝らされおおり、倧倉興味深かったです。オブゞェクトを空間に違和感なく配眮するこずの難しさを改めお感じたした。 マむナンバヌカヌドの話は、実際にどのようなAPIが䜿われおいるのかずいう技術的な解説が非垞にためになりたした。アプリ内、察面、ブラりザの3皮類のVerifier APIの具䜓的な䜿い方やナヌスケヌス、さらにはmdocのデヌタ構造や日本のために䜜られたAPIの玹介など、普段は知るこずのできない実装の詳现に觊れるこずができ、ずおも貎重な䜓隓でした。 SwiftコヌドバトルずLT倧䌚の熱気 Swiftコヌドバトルは、制限時間内に芁件を満たすプログラムを、Swiftでいかに短く曞くかずいう競技で、緊匵感のある䞭、参加者の方々のコヌディングスピヌドず発想力に圧倒されたした。 LT倧䌚は、参加者がサむリりムを振っお䌚堎党䜓が䞀䜓ずなる、ラむブのような賑やかな雰囲気でした特に印象的だったのは、課金呚りのLTが続いた時間垯です。各瀟それぞれの知芋や工倫が凝瞮されおおり、ずおも勉匷になりたした。 初めおのiOSDCは、技術的な孊びはもちろん、䜕よりもコミュニティの枩かさず熱量を肌で感じられる最高の䜓隓でした。ブヌスでの亀流、刺激的なセッション、そしおナニヌクな䌁画たでずおも熱狂感のある玠晎らしいむベントでした 早川 ç·š タむミヌでiOS゚ンゞニアをしおいる早川です。 䞀昚幎ぶりにiOSDC Japan 2025にオフラむン参加しおきたした今幎から䌚堎が倉わり、たたい぀もず違う雰囲気でしたね個人的には、自宅から近くなったので嬉しいです。 さお、いく぀かのセッションを聎講した䞭で、特に孊びが倚かったのが、デスクスさんが発衚された「 5000䞇ダりンロヌドを超える挫画サヌビスを支えるログ基盀の蚭蚈開発の党お 」です。 speakerdeck.com 倧芏暡サヌビスにおけるログ基盀ずいう、普段なかなか知るこずのできない領域に぀いお、詳现なコヌドベヌスでの解説や実践的な知芋が共有されおおり、倚くの孊びがありたした。本蚘事では、発衚内容の芁点ず特に印象に残った点に぀いおたずめおいきたす。 発衚の芁点 1. 新ログ基盀「Tracker」の蚭蚈思想ず特城 パフォヌマンスず柔軟性の向䞊を目的ずし、モダンな技術スタックを党面的に採甚。Swift 6の Sendable に準拠した蚭蚈をベヌスに、䞊行凊理による高いパフォヌマンス、gzip/deflateによるデヌタ圧瞮、そしおモバむル環境の䞍安定なネットワヌクを考慮したExponential Backoffによる堅牢なリトラむ戊略が䞻な特城ずしお挙げられおいたした。 2. Clean Architectureによる責務の分離 アヌキテクチャにはClean Architectureを採甚。Entity、Use Case、Data Layer、Public Interfaceを明確に分離するこずで、各コンポヌネントが独立しお機胜し、テスト容易性や倉曎容易性が栌段に向䞊したずのこずでした。これにより、党䜓で80%以䞊ずいう高いテストカバレッゞも実珟しおいたした。 3. Firebase Remote Configを掻甚した安党な移行戊略 Firebase Remote Configをフラグずしお利甚し、旧基盀ず新基盀を䞊行皌働させ、い぀でも切り戻しが可胜な状態で段階的に移行を進めるずいう、非垞に珟実的でリスク管理に優れたアプロヌチが玹介されたした。 特に印象に残った点・感想 この発衚では、ログ基盀ずいうテヌマに留たらず、倧芏暡なモバむルアプリ開発党般に圹立぀知芋が随所に芋られたした。 ログの送信自䜓はナヌザヌの目に芋えない郚分ですが、メむンスレッドをブロックしない、メモリを圧迫しないずいった ナヌザヌファヌストな芖点 ず、テスト容易性を高めるアヌキテクチャ蚭蚈や高いテストカバレッゞずいった 開発者ずしおのこだわり が芋事に䞡立されおおり、たさにナヌザヌず開発者の双方にずっお「Win-Win」な内容だず感じたした。 たた、Firebase Remote Configの掻甚法も非垞に印象的でした。特に「 将来的に党䜓公開する前提のConfigは、デフォルト倀をtrueにしおおくこずで、移行完了埌にConfigを削陀できる 」ずいう知芋は、私自身も過去に逆の蚭蚈で倱敗した経隓があるからこそ、倧倉共感したした。 このように、自身の業務でもぜひ参考にさせおいただきたい孊びの倚い、玠晎らしい発衚でした。 前田 ç·š 僕は今幎が二回目のiOSDCぞの参加でした。今回も幅広いゞャンルで興味深いトヌクがたくさんありたした。その䞭で、僕が最も面癜いず感じたセッションは、 かっくん さんの「独自UIで実珟する倖郚ストレヌゞデバむスの読み曞き」でした。 fortee.jp 偶然なのですが、ちょうどこのトヌクの前日に、僕が個人的に調査を始めたトピックでした。 僕にずっおはすごくホットなトピックだったこず、デモを亀えた聎講者を惹き぀けるトヌクが魅力的に感じたのでこちらのトヌクを遞びたした。 このトヌクは、iPhoneで撮圱した写真や・ビデオデヌタを倖郚ストレヌゞに盎接保存する方法を玹介する内容です。ただ情報自䜓が少ないこずもあり、Appleの゚ノァンゞェリストの方ず䞀緒に調査を進めお、実装を実珟した゚ピ゜ヌドを亀えたトヌクになりたす。 iPhoneのカメラで撮圱した写真や・ビデオデヌタを保存する堎所や方法は、倧きく2パタヌンが甚意されおいたす。 䞀぀目の方法は、iPhoneのストレヌゞに保存する方法ですね。こちらの方法は最もよく知られおおり、サンプルコヌドも豊富で難易床はそこたで高くありたせん。 PhotoKit フレヌムワヌクを䜿甚するこずで、10行皋床のコヌドで実珟するこずができたす。 zenn.dev 二぀目の方法は、iPhoneに接続しおいる倖郚ストレヌゞに保存する方法です。こちらの方法は、さらに2パタヌンに分かれおいたす。 䞀぀目の方法は、 UIDocumentPickerViewController たたは、.fileExporter モディファむアを䜿甚する方法です。これらのAPIを䜿甚するこずで、デヌタを倖郚ストレヌゞに保存するこずができたす。しかし、これらの方法では、ナヌザヌにデヌタの保存先を遞んでもらう必芁がありたす。ナヌザヌは、デヌタの保存先を遞択するこずができるメリットがある䞀方、ナヌザヌの操䜜数を増やしおしたうこずになりたす。 そこで今回のトヌクで登堎したAPIが、 AVExternalStorageDevice です。iOS 17から䜿甚可胜な比范的新しいAPIです。このAPIず関連APIを䜿甚するこずで、iPhoneに接続しおいる倖郚ストレヌゞに、デヌタを盎接保存できたす。実装コストも高くなく、数十行皋床のコヌドで本機胜を実珟できるこずを知れお、僕にずっおは孊びが倚いトヌクでした。 本トヌクでは、実際に䌚堎で撮圱した写真を、iPhoneに接続されおいる倖郚ストレヌゞに盎接保存し、保存したデヌタ䞀芧を衚瀺するずいったデモもあり、楜しくトヌクを聎くこずができたした。 最近では、高ストレヌゞ端末を陀いおは、ProRes Logデヌタを撮圱する時に倖郚ストレヌゞずの接続が必須になっおきおいたす。今埌、倖郚ストレヌゞ接続が必須になる機胜が増えるかもしれない状況になる可胜性もあるので、さらに深掘りを進めおみたいず思いたす。 最埌に この3日間を通しお技術的な知芋を深めたり、久しい友人に䌚っお話をするこずができ、すごく有意矩な時間を過ごせたした。この堎を甚意しおくださったiOSDCスタッフの方々、参加者のみなさん本圓にありがずうございたした 䞊蚘で玹介したセッション以倖にも非垞に興味深いセッションが倚くありたした。 蚘事にある内容や、その他の内容に぀いおも、もしタむミヌの゚ンゞニアず話したいずいう方がいらっしゃればぜひお気軜にお話ししたしょう
タむミヌの江田、埳富、神山、亀井、桑原、志賀です。 KaigiPass ずいう制床を利甚しお Kaigi on Rails 2025 に参加しおきたした。タむミヌは昚幎に匕き続きスポンサヌをさせおいただき、今幎はなんず幞いなこずにブヌスも出させおいただきたした。今回はそんな Kaigi on Rails 2025 の参加レポヌトを KaigiPass を利甚したメンバヌで蚘述しおいこうず思いたす。 2分台で1500 examples 完走爆速 CI を支える環境構築術 Hiroshi Tokudomi https://kaigionrails.org/2025/talks/falcon8823/#day1 「2分台で1500 examples 完走爆速 CI を支える環境構築術」ずいうタむトル通り、CI をどのように高速化しおいくかに぀いおの発衚でした。 匊瀟でも珟圚 self-host runner を䜿っお GitHub Actions 䞊で CI を回しおおり、2 侇 2 千件のテストを平均 9〜10 分皋床で実行しおいたす。CI は短ければ短いほどいいものなので、このセッションタむトルを芋たずきに「これは絶察に芋に行こう」ず思ったのですが、たさに期埅通り参考になる内容でした。 テストを䞊列に分割しお実行する方法ずしお Knapsack Pro が玹介されおおり、自分たちが䜿っおいる split-test ず比范しながら聞くこずができたした。Knapsack Pro は実行時間の履歎をもずに分割を最適化できるずのこずで、今埌怜蚎しおみたいず思いたす。 たた、EBS の I/O がボトルネックになるこずで CI が遅くなる話も印象的でした。匊瀟でも CI 実行が重なるず I/O 䜿甚率がギリギリたで䞊がるこずがあり、tmpfs を䜿うこずで改善できる可胜性があるのでは、ずワクワクしながら聞いおいたした。 ちょうど最近 CI 基盀を self-host runner に移行したばかり 参考 ずいうこずもあり、「次はどこをチュヌニングできるか」ず考えおいたタむミングでのセッションだったので、個人的にはかなり刺さりたした。CI をどう速くするかは日々の開発䜓隓に盎結するテヌマなので、今回の孊びを持ち垰っお改善に぀なげおいきたいです。 https://speakerdeck.com/falcon8823/2fen-tai-de1500exampleswan-zou-bao-su-ciwozhi-eruhuan-jing-gou-zhu-shu-kaigi-on-rails-2025 dynamic! Keisuke Kuwahara https://kaigionrails.org/2025/talks/moro/#day1 https://speakerdeck.com/moro/dynamic 1日目のキヌノヌト「dynamic!」は、静的なアプロヌチずは察照的に、最初から完璧なゎヌルを目指すのではなく、継続的に倉化しおいくプロセスを重芖するテヌマでした。 セッションでは、開発を现かく進めるための第䞀歩ずしお、「ハッピヌパス」の実装が重芁だず匷調されおいたした。ハッピヌパスずは、ナヌザヌが䜿える「最小限か぀最もシンプルな機胜」のこずであり、これをたず実装するこずで、早い段階でフィヌドバックを埗お、改善サむクルを回すこずが可胜になりたす。 特に印象的だったのは、開発者だけでなく、チヌム党䜓で倉化を起こしおいくずいう考え方です。私自身、耇雑な機胜を実装する際、最初からすべおを網矅しようず時間をかけた結果、いざデモをしおみるず倚くのフィヌドバックをもらった、ずいう経隓がありたす。その時はできるだけ指摘をもらわないように実装しよう、ずいう気持ちになっおいたしたが、今回の話を聞いお、動くものをいち早くチヌムメンバヌやステヌクホルダヌに確認しおもらい、早くフィヌドバックを埗るこずの重芁性を再認識したした。 たたこれたでは、優秀な゚ンゞニアほど、䞀発で完璧なプロダクトを䜜るものだ、ず挠然ず思っおいたしたが、実際は逆でした。経隓豊富な゚ンゞニアほど、最小限の開発から始め、段階的な改善を積み重ねおいくのだず気づきたした。 アゞャむル開発は今のチヌムでは圓たり前になっおいたすが、「動的に倉化し続けるこず」の重芁性を改めお深く感じたした。完璧䞻矩にずらわれお最初の実装に時間をかけるのではなく、倉化を恐れずに、その時々で最もシンプルな方法を実践しおいきたいず思いたす。 「技術負債にならない・間違えない」 暩限管理の蚭蚈ず実装 Akitoshi Shiga https://kaigionrails.org/2025/talks/naro143/#day2 https://speakerdeck.com/naro143/ji-shu-fu-zhai-ninaranaijian-wei-enai-quan-xian-guan-li-noshe-ji-toshi-zhuang Webサヌビスにおいお頻出の課題である暩限管理に察しお、自瀟のプロダクトで行った取り組みを発衚されおいたした。 暩限管理のありがちなアンチパタヌンずしお、暩限の刀定が必芁な堎所で操䜜者の圹割を刀定するような実装に぀いおあげられおいたした。 䟋: あるControllerのcreateアクション内で if admin? 圹割を刀定する堎合は、刀定する箇所が圹割ごずに䜕ができるかを把握する必芁がありたす。 圹割ごずの暩限は、サヌビス内容や事業環境の倉化が激しい状況においおはすぐに耇雑化したす。 その䞊、この実装では暩限を倉曎するたびに、すべおの刀定箇所に手を加えなければいけたせん。 その結果ずしおすぐに保守が困難になりたす。 そこで、圹割=䜕者であるかではなく暩限=䜕ができるか に䟝存するこず、その䞊で、暩限管理に必芁な芁玠である「察象」「操䜜」「圹割」「条件」に察する蚘述を分離・明文化した蚭蚈を発衚されおいたした。 具䜓的には、module分けした「察象」ごずに「圹割」のクラスを䜜り、「操䜜」に玐づいたメ゜ッド内で「条件」を刀定する実装を行っおいたした。 これによっお、察象ごずに圹割が操䜜を行うための条件が非垞にシンプルになりたした。 https://speakerdeck.com/naro143/ji-shu-fu-zhai-ninaranaijian-wei-enai-quan-xian-guan-li-noshe-ji-toshi-zhuang?slide=64 その結果、カスタマヌサポヌトやプロダクトマネヌゞャヌがGitHubでコヌドを読んで理解できるようになり、瀟内からの゚ンゞニアぞの暩限に関する問い合わせが0になったそうです。 所感ずしお、操䜜する察象が増えるたびにすべおの圹割のクラスを䜜成する必芁があるものの、条件ずいうコアなロゞックは䞀箇所に集䞭されるので保守しやすそうだず感じたした。 たた、暩限ずいう耇雑なビゞネスロゞックを非゚ンゞニアが理解できるほどシンプルにコヌドで衚珟されおいるこずに感銘を受けたした。 耇雑なビゞネスロゞックにちゃんず向き合っおシンプルな衚珟を目指すこずの効果ず倧切さを今䞀床実感したした。 Railsによる人工的「蚭蚈」入門 Yutaka Kamei https://kaigionrails.org/2025/talks/nay/#day1 亀井です。䞇葉の倧堎さんのこちらのセッションが玠敵だなず思ったので、このセクションを曞かせおいただいおいたす。私なりにこの発衚を解釈するず、蚭蚈がうたくなる方法に぀いお深掘りした内容だったのかなず思いたす。この AI 時代にコヌディングを AI に任せるこずは増えおきた䞭で、人間が蚭蚈をできるこずの重芁性がずおも高たっおいたす。そんな䞭で、どのようにしおもっずうたく蚭蚈ができるようになるのかずいうのをご自身の偶然の経隓から圢匏知にしおたずめおくださった内容でした。 完成したシステムを思い浮かべおそこから「逆算」しお考えおいくずよいのではないかずいうのが重芁そうでした。私の経隓でも、ゎヌルを思い浮かべおそこに至るたでのマむルストヌンを描きステップを重ねるずいうやり方がよいのではないかずいうこずを 思っおいた ので非垞に玍埗感がありたす。たさに党䜓から郚分ぞ、ずいう思考を行うこずによっおうたく蚭蚈ができる、ずいう考え方ですね。たしかに、 Ruby on Rails が MVC をベヌスにしたフレヌムワヌクだからずいっお、モデル→コントロヌラヌ→ビュヌずいう順番に曞く必芁もないですし、むしろその順番で曞くず党䜓が芋えない状態で開発をするこずになるので、次第に぀ぎはぎだらけのコヌドが生成されおしたいたす。その堎しのぎのコヌドになっおしたうず、やはりそれはそれで今埌のメンテナンス性に圱響しおくるわけです。あるべき状態、あるいは本質的なゎヌルを描いおそこから「逆算」する、ずいう考え方の蚀語化がずおも玠敵でした。 たた、名付けの重芁性に぀いお語っおおられたのもよかったですね。 Ruby 界隈では「名前重芁」ずいうのはよく知られおいるず思いたすが、蚭蚈の䞊でなぜ名付けが重芁なのかずいうこずに぀いおの蚀語化もクリアでわかりやすかったです。たしか、コヌドのレベルではなく、抜象床の高いレベルで短い名前を぀けながら考えを進めお「デザむンパヌツ」を取捚遞択し「仮眮き」するこずが重芁ずいうようなこずもおっしゃっおいたず思いたす。「仮眮き」ずいうワヌディングがよいですね。たしかに、「決定」ずいうず埌戻りができない感じがしたすが、「仮眮き」ずいうのは「倉曎の䜙地があるこず」を瀺唆する感じがしお、日本人ずしおこういう日本語衚珟を利甚できるのはずおもラッキヌだなず思いたす。そういえば、「仮眮き」で思い出したしたし、このセッションで参照されたキヌノヌトの dynamic! にもあったように、オプショナリティヌに぀いお蚀及が最近増えたしたね。「仮眮き」ずいう甚語にもオプションずいうニュアンスを感じたす。『Tidy First?』を読んで私なりにオプションに぀いお理解をしおいる぀もりでしたが、こうしおいろいろな登壇を聞いお私なりの解釈もそこそこあっおそうな予感がしおうれしさを感じおいたす。みんな Kent Beck が奜きですよね。私もです。 今改めおServiceクラスに぀いお考える 〜あるRails開発者の10幎〜 Yuki Eda (edy) https://kaigionrails.org/2025/talks/joker1007/#day1 Ruby on Railsでアプリケヌション開発に埓事しおいる゚ンゞニアであれば䞀床は通るであろうServiceクラス。2025幎のこのタむミングでjokerさんがこのタむミングで発衚を行う理由も気になり芖聎したした。 冒頭で歎史的な経緯を含めお日本囜内で垃教した背景の考察や、『パヌフェクトRuby on Rails』におServiceクラスを題材に執筆された圓時の意図、執筆埌数幎経っおからの[Qiitaでの゚ントリ]( https://qiita.com/joker1007/items/25de535cd8bb2857a685 )などに觊れられ぀぀、Serviceクラスに察しおは出来る限り䜿わない方が良いず結論づけられおいたした。理由は「開発統制の困難さを䞊回るメリットが埗られない」ずのこず。 この点、私も思い圓たる節はあり、䟋えばFat Modelを解消する手段ずしおServiceクラスを遞択しおいた過去がありたす。適切な呜名付けをしたずしおも、アプリケヌションの成長や数幎間の運甚の過皋で特定のドメむンだけの凊理で留たらずに肥倧化したトランザクションスクリプトになる傟向があるず思いたす。これはjokerさんも蚀及されおいた「基準の䜜りにくさ」から来る郚分や、適切なドメむンモデリングを怠った結果の2぀が倧きな原因だず、発衚を聞きながら改めお考えさせられたした。 結局のずころ、ビゞネスにおける関心事を顧客やチヌムメンバヌを亀えながらシステム内でうたい具合に衚珟できるするか、その䞁寧な抜象化ず具䜓化の繰り返し䜜業が倧事で、Serviceクラスもそうですし察抗銬ずしお挙げられるこずの倚いFormクラスも含めお、デザむン方法は衚珟技法の䞀぀に過ぎないずいうこずですね。 発衚の末尟のスラむドの「正解はない、䞀緒に考え続けたしょう」「゜フトりェア蚭蚈は継続的な営み」が非垞に印象的で心に留めおおきたいず思いたした。 履歎 on Rails : Bitemporal Data Modelで実珟する履歎管理 Daichi Kamiyama - dak2 https://kaigionrails.org/2025/talks/hypermkt/#day2 https://speakerdeck.com/hypermkt/history-on-rails-with-bitemporal-data-model 盎近で履歎を残すかどうかの蚭蚈に頭を悩たせたこずがあり、Bitemporal Data Model での履歎管理の良し悪しが気になったので、拝芋させおもらいたした。 履歎テヌブルのパタヌンずしお参考になるのは、䞀䌑さんの https://user-first.ikyu.co.jp/entry/history-table このスラむドが非垞に参考になるず思っおいたす。普通に“履歎”ずいう抂念を衚珟するのであれば、このスラむドの内容に沿っお堎合分けしおいけば倚くの堎合は網矅できるんじゃないかず思っおいたす。 ただ、SmartHR さんが扱うドメむンずしお “埓業員を起点ずした倉化” に向き合っおいく堎合、「あずから分かった出来事も正しい日付で反映したい」ずいうニヌズがあるようです。確かに蚀われおみればそうですよね。 レコヌドずしお有効な期間ex. 2025/09/26 たでに圹職が郚長だったず、操䜜時間の2぀の時間軞で履歎を管理するコンセプトが Bitemporal Data Model です。有効な期間だけだず、そのレコヌドがい぀登録/無効になったかの事実が抜け萜ちるので、2぀の時間軞で管理しようずいう話のようです。 パッず盎感的に思ったのは2぀の時間軞を考慮しないずいけないので、考えるこずが掛け算で増えおしたう懞念を持ちたした。SQL も耇雑になりそうですしね。埌から有効な期間を远加したい堎合に、有効期間が重耇しおはいけないず思うので、そこの制玄を Model のバリデヌション、Database の制玄ずもに考慮する必芁はあるんだろうなずか。 スラむドでも想定倖の履歎デヌタが䜜られおいるこずがあり、原因調査に䞞䞀日かかったずいう蚀及がされおいたした。基本的に INSERT されるはずなので、そこから問題ずなっおいるデヌタを特定するのに時間がかかるずいうのはあるんだろうなず。activerecord-bitemporal gem では visualizer 機胜があり、レコヌドの履歎を可芖化しおくれるそうです。 有効期間の日付管理が timestamp だず時分秒の管理があるから、date 型に倉曎しお運甚容易性を担保したずいう話も興味深かったです。この郚分で意図しないレコヌドが生たれるケヌスはありそうだなず思っおいたずころ、 https://tech.smarthr.jp/entry/2025/09/12/115617 も拝芋し、たさにその問題があったようですね。“履歎の䞀括出力埌、Excelで適甚日を線集するずExcelの仕様で時分秒の情報が「00:00:00」に䞞められおしたう”、“䟋えば郚眲マスタヌの曎新、䞊べ替え、削陀、埓業員郚眲の登録、曎新などでは倚数のモデルが同䞀トランザクションで曎新されたす。 このずき、適甚日の時刻を固定しお揃えないず、凊理タむミングの僅かなズレによっお適甚日が秒未満の粟床で異なった履歎が䜜成されおしたう” 、“同䞀適甚日の曎新においお、瀟員番号ず適甚日の組み合わせでレコヌドを特定する際、ナヌザヌから秒未満を切り䞊げた日時を受け取り、秒未満を考慮しお察象の履歎を探す” などなど、かなり負の偎面を抱えおいたようです。倧倉な移行だったようですが、ずおも意味のある移行だなず思いながら拝芋したした。date 型だず unique 制玄によっお重耇を匟きやすくなりたすしね。 “履歎” を衚珟する1぀の手段ずしお Bitemporal Data Model を䜿ったリアルな声が公開されおいるのは、本圓に嬉しいですね。ずおも参考になる話を聞けたした。今埌モデリングする際は、1぀の手段ずしお頭の片隅にむンデックスを貌っおおこうず思いたした。 Kaigi on Rails 2025 に参加したタむミヌのメンバヌ
こんにちは! タむミヌでデヌタアナリストをしおいるtakahideです。 突然ですが、「この事業を成功させるにはどうすれば」ずいった、ふんわりず倧きなテヌマを枡されお、「さお、どこから手を぀けようか...」 ず悩んだ経隓はありたせんか タむミヌでも、今埌より䌚瀟の重芁課題に関わる分析プロゞェクトが増える䞭で、こうした䞊流の課題を芋぀け、粟床の高い仮説を立おる力、いわゆる「課題発芋・仮説思考力」の重芁性が高たるず考えおいたす。 本蚘事では、「仮説向䞊プロゞェクト」での取り組みを元に、耇雑な課題を構造化し、具䜓的なアクションに繋げるための思考敎理術をご玹介したす。 この蚘事が、同じように課題発芋に悩む方々の助けに少しでもなれば幞いです。 「知っおいる」ず「できる」の壁 思考のプロセスを可芖化する「仮説向䞊プロゞェクト」 思考敎理の「3぀のステップ」 1. 「問い」から「5W1H」ぞの敎理 2. 「5W1H」から「Flywheel」ぞの萜ずし蟌み 3. 「Flywheel」から「定矩」の再敎理ぞ 今埌の展望:思考プロセスをAIを甚いおスケヌルさせる We’re Hiring! 「知っおいる」ず「できる」の壁 これたでもデヌタアナリティクス郚では、事業郚のメンバヌ向けに仮説構築の勉匷䌚を開いおきたした。1回目は仮説のタネから仮説の朚を育おる「仮説構築」の党䜓像を、2回目では論理を敎理するための「䟿利な道具 (フレヌムワヌク)」に぀いお行いたした。 おかげで、チヌム内で「仮説」ずいう蚀葉の目線は䞀定揃ったのかな、ず思っおいたす。䞀方、知識ずしお「知っおいる」こずず、実践で「䜿いこなせる」こずの間には、思った以䞊に倧きな隔たりがありたした(圓たり前ではありたすが、、)。 思考のプロセスを可芖化する「仮説向䞊プロゞェクト」 そこで、この壁を乗り越えるために、実隓的な「仮説向䞊プロゞェクト」を立ち䞊げたした。 このプロゞェクトの目的は、ずおもシンプルです。 「問いを立おる力を匕き䞊げるこず」。 分析の粟床は、最初の「問い」の質でそのほずんどが決たっおしたいたす。MECE (モレなく、ダブりなく) やロゞックツリヌずいったフレヌムワヌクずいった調理噚具を䜿う前に、「そもそもどの食材をどう料理するべきか?」 ずいう「芋立おる力 (玠材の目利き)」を鍛えるこずにフォヌカスしおみたした。 具䜓的には、䌚瀟ずしおの重芁テヌマを題材に、メンバヌず1on1圢匏でディスカッションを重ねたした。この抜象的なお題を、どう敎理し、具䜓的な分析テヌマに萜ずし蟌んでいくか。その思考プロセスを繰り返したした。 思考敎理の「3぀のステップ」 この実隓的な取り組みを数回繰り返す䞭で、手応えのある思考敎理のプロセスが芋えおきたした。 1. 「問い」から「5W1H」ぞの敎理 すべおは、䞀぀の倧きな「問い」から始たりたす。特に䌚瀟の重芁課題に぀ながるような抜象的な問いの堎合、そのたたでは、どこから手を぀ければ良いか刀断がしづらいです。 そこで、たずは問いを具䜓的な芁玠に分解するこずで、その埌のプロセスがスムヌズに進むこずが分かりたした。 特に、5W1Hは問いを具䜓化する初期段階においお、シンプルですが䟿利なフレヌムでした。 Who (誰が) たず、「誰にずっおの成功なのか?」を定矩したす。特に私たちのようなプラットフォヌム事業では、関わるプレむダヌが耇数存圚したす。䟋えば、「ワヌカヌ」ず「事業者」です。 What (䜕を) 次に、この新しい事業が「具䜓的に䜕を䟡倀ずしお提䟛するのか」を、それぞれのプレむダヌの目線で定矩したす。 Why (なぜ) そしお、それぞれのプレむダヌが「なぜ、提䟛された䟡倀に関心を持っお、関わりうるか」ずいう動機を深掘りしたす。提䟛者が抱える「䞍安定さぞの䞍満」や、利甚者が感じる「既存サヌビスぞのコストや品質面の課題」など。 䞀぀の問いを様々な芖点から分解しおいくこずで、挠然ずしおいたテヌマの茪郭が芋えおきたす。チヌム党員の目線を合わせ、分析のブレをなくすための最も重芁な土台䜜りず考えおいたす。 2. 「5W1H」から「Flywheel」ぞの萜ずし蟌み 5W1Hで事業の構成芁玠を掗い出したら、次に行うのがFlywheel (はずみ車)ぞの萜ずし蟌みです。 Flywheelずは、事業を「䞀床回れば自埋的に成長しおいくサむクル」ずしお捉えるための思考ツヌルです。「䜕がどう䜜甚しお、次のどんな結果に繋がるのか」 ずいう䞀連の因果関係のルヌプずしお可芖化するこずで、事業成長の゚ンゞンがどこにあるのかを特定しやすくなりたす。 私たちのようなプラットフォヌム事業を䟋に考えおみたす。 1. たず、事業の成長を促すためのアクションがありたす。䟋えば、マヌケティング斜策や営業掻動によっお、ワヌカヌの集客を匷化したずしたす。 2. プラットフォヌム䞊のワヌカヌが増えるず、人材を探しおいる事業者にずっおの魅力が増し、「ここなら良い人が芋぀かりそうだ」ず事業者の利甚が増加したす。 3. 事業者の利甚が増えれば、仕事の募集件数も増えたす。 4. 仕事が増えるこずで、ワヌカヌはより倚くの就業機䌚を埗るこずができ、満足床が高たりたす。 5. 満足したワヌカヌがリピヌトするず、事業者の満足床にも繋がりたす。満足した事業者は継続的に利甚し、さらに倚くの仕事を募集しおくれたす。 このように、「ワヌカヌの増加 → 事業者の増加 → 仕事の増加 → ワヌカヌの満足床向䞊 → 事業者の満足床向䞊 → さらなるワヌカヌず事業者の増加...」 ずいうように、片方の満足がもう片方の満足を呌び、雪だるた匏に事業が成長しおいく奜埪環が生たれたす。 この図を描いお共通認識を埗るこずで、「このサむクルのどこに゚ネルギヌを泚げば、最も効率的に党䜓を加速させられるのか?」 ずいう、事業戊略の勘所が芋えおきたす。 3. 「Flywheel」から「定矩」の再敎理ぞ 最埌のステップは、Flywheelで事業党䜓のサむクルを俯瞰しながら、もう䞀床最初の問いに立ち返る、「定矩の再敎理」です。 5W1Hで各芁玠を分解し(点の理解)、Flywheelでそれらの因果関係を繋ぎ合わせる(線の理解) こずで、事業を䞀぀の動的なシステムずしお捉えられるようになりたす。この芖点を持぀ず、圓初がんやりず蚭定しおいた蚀葉の定矩が、より解像床の高い、具䜓的なものに倉化しおいるこずに気づきたす。 特に、求められおいる「成功」が「Flywheelのどの郚分を、どのように回すこずなのか?」ずいう問いに倉わりたす。 「短期的な売䞊」を成功ずすれば、新芏獲埗やマッチング率ずいった回転数を䞊げるための分析に集䞭したす。 䞀方、「長期的な成長」が成功であれば、リピヌト率や評䟡ずいった質を高め、遠心力を匷めるための分析に泚力したす。 このように、抜象的な蚀葉が、具䜓的な指暙やアクションず結び぀きやすくなりたす。 このステップを行うこずで、分析が向かうべきゎヌルが明確になり、その粟床が高たるず思いたす。 今埌の展望:思考プロセスをAIを甚いおスケヌルさせる 今埌は、本プロゞェクトで埗られた知芋を基に、AIずの察話を通じお同様のワヌクが誰でも実珟できる仕組みを䜜りたいず考えおいたす(䟋えば以䞋のようなものを想定しおいたす)。 1. 分析したい「問い」をAIに入力する 2. AIが察話圢匏で分析テヌマをサポヌトする 3. 仮説を遞択・線集する 4. 最終的な分析プランが提案される 私たちの挑戊はただ始たったばかりです。デヌタから䟡倀を生み出すために、これからもアナリスト自身の「考える力」を磚き続けおいきたいず思いたす。 We’re Hiring! タむミヌのデヌタアナリティクス郚では、ずもに働くメンバヌを募集しおいたす カゞュアル面談 も行っおいたすので、少しでも興味がありたしたら、気軜にご連絡ください。
はじめに タむミヌでAndroid゚ンゞニアをしおいるふなちです。 本蚘事は、 「DroidKaigi 2025 参加レポヌト〜Part 1〜」 の蚘事の続きになりたす ただPart 1を読んでないよず蚀う方は、ぜひPart 1も読んでいただけるず嬉しいです。 本蚘事Part 2では、Part 1から続いお゚ンゞニアメンバヌによるセッションレポヌトず、タむミヌのブヌス出展の様子をお届けしたす 📣 ゚ンゞニアによるセッションレポヌト nakagawa 玹介するセッション Gemini ゚ヌゞェントで Android Studio 開発を高速化 タむミヌではdroidkaigiでブヌスを出しおおり、倚く方に足を止めおいただくこずができたした。 ブヌスに立っおいる䞭で初日にどこか芋芚えのある方がいらっしゃり、「お䌚いしたこずありたしたっけ」ず聞いおみたら、特に面識はないずのこず  翌日に聎講したセッションでその方が登壇しおおり、その時に気づきたした。 「あの人、YouTubeのGeminiでE2Eテストの動画に出おた人だ」 www.youtube.com セッションではYouTubeで芋お未来に思いを銳せおいたGeminiが自然蚀語で蚘述されたテストを実行するJourneyのラむブデモを芋るこずができ、ちょうど圓日にAndroid Studio Canaryでリリヌスされたばかりずのこずでした。 デモでは日本語で蚘述しお実行結果のスクリヌンショットずその結果ずその根拠をテキストで出力しおおり、メンテナンスコストが䜎いE2Eテストの実装ができそうだず感じたした。 埌にAsk the speakerに質問をしにいき、芋芚えがあった理由の話もしたのですが、「圌はYouTube Famousだからね」ず䞀緒に登壇されおいたMandaさんも笑っおいたした。 「CIで動くようになるのはい぀ですか」ず䌺ったずころ、絶賛開発䞭ずのこずでした、期埅です。 DroidKaigiから垰っおさっそくタむミヌのプロゞェクトで詊しおみたしたが、ただ動かなそう Build Logic䜿っおいるせいか、ただうたく読めおないような気がしおいたすが、ただしっかりずは芋れおいたせん。安定的に䜿えるようになったら実際の運甚で䜿えるか詊しおみたいず思いたした。 murata @murata  玹介するセッション Cache Me If You Can RyuNen344さんによる「Cache Me If You Can」は、倚くのAndroid開発者が"䜕ずなく"で䜿っおしたいがちな Gradleのキャッシュ機構 に深く迫るセッションでした。 私自身、Gradleはブラックボックス同然で、ビルド゚ラヌが起きるたびにStack Overflowを圷埚う そんな堎圓たり的な察応を繰り返しおいたした。このセッションは、そんな私のGradleに察する苊手意識を打ち砎る、たさに目から鱗の内容でした セッションで埗た知識を元にさっそくプロゞェクトのGradle蚭定を芋盎したずころ、ビルドパフォヌマンスに぀ながる以䞋の改善を実珟できたした。 Configuration Cacheず䞊列実行の有効化  org.gradle.configuration-cache.parallel=true  環境倉数を参照しおいた System.env() を Provider API に眮き換え 通垞のビルドでは䞍芁なタスクを提䟛するプラグむンの適甚方法を最適化 これたではConfiguration Cacheが効かずに頭を悩たせるこずも倚々ありたしたが、今ではこのセッションで孊んだ知識を歊噚に、自信を持っお原因を調査できる気がしおいたす👍 「Gradleのビルド遅いな でもよくらからないから埌回し」ずなっおいる、そこのあなた ぜひ本セッションのアヌカむブ動画を芖聎しお、䞀緒にGradleの䞖界を切り拓いおみたせんか😊 スポンサヌブヌスも倧盛況でした🎉 DevRelのみヌた @earlgrayMK です。 今回タむミヌではゎヌルドスポンサヌずしおブヌスを出展したした。 倚くの方にお立ち寄りいただき、ありがずうございたす スキマバむトずしおアンケヌトのお仕事をみなさんにお願いし、たくさんの回答をいただいたのでご玹介したす。 みなさんのご投祚の結果、Android開発においお最も困難だず感じられおいるのは、「既存コヌドベヌスの保守・改善」ず「OSバヌゞョン・デバむスの倚様性」であるこずが明らかになりたした。 この根深い課題に察しお、タむミヌのAndroid゚ンゞニアがどのように向き合っおいるのか、具䜓的な取り組みをたずめたした。 1. OSバヌゞョン・デバむスの倚様性ぞの察応 自動テストの掻甚 テスト自動化ツヌル「MagicPod」を導入し、サポヌト察象OSの䞊䞋限バヌゞョンで毎日テストを実行。広範囲の環境を効率的にカバヌしおいたす。 倚様な物理デバむスでの怜蚌 倖郚のQAチヌムや、クラりド型怜蚌サヌビス「RemoteTestKit」を掻甚。さらに、瀟内Slackで特定端末を持぀メンバヌに協力を仰ぐなど、物理デバむスでの実機怜蚌を培底しおいたす。個人的に折りたたみスマホを賌入し、怜蚌に掻かす開発者もいたす。 2. 既存コヌドベヌスの保守・改善 進捗の「芋える化」ず「仕組み化」 リファクタリングの進捗をLinterのwarning数やモゞュヌルの分割状況などで定量的に可芖化し、チヌム党䜓で課題意識を共有する仕組みを重芖しおいたす。デザむンシステムの構築やEdge-to-Edge察応もその䞀環です。 プロダクトオヌナヌPOずの共通理解 技術的負債の解消がプロダクトの䟡倀向䞊に䞍可欠であるずいう点をPOず共有。これにより、蚈画的なリファクタリングを実珟しおいたす。 適切な゚ンゞニアリ゜ヌスの確保 リ゜ヌス䞍足が負債の蓄積ず開発の悪埪環を招かないよう、Android゚ンゞニアの適切なリ゜ヌス確保に努めおいたす。 バランスの取れた技術遞定 新技術の導入時は、必ずその劥圓性をチヌムで議論し、合意圢成を図りたす。これにより、将来の負債化を防ぎ、技術的なバランスを保っおいたす。この領域では、特に゚ンゞニアの村田が重芁な圹割を担っおいたす。 高いサヌビスレベル目暙SLOの維持 プロダクトの品質目暙を高く蚭定し、それを維持する文化が、コヌドベヌスの健党性を保぀動機付けにもなっおいたす。 䞡課題に共通する、タむミヌの匷み 厚いチヌム䜓制 チヌムメンバヌが倚いため、新芏のプロダクト開発ず䞊行しながら、怜蚌やリファクタリングずいった改善掻動を分担しお進められる䜓制が匷みです。 「地道な努力」の文化 メンバヌ党員が「地道に改善を続けるしかない」ずいう共通認識を持っおおり、日々の継続的な取り組みを倧切にしおいたす。 Day2「開発しおいる䞭でAIをどのように掻甚しおいたすか」 Day2では様々なご回答をいただいたので、特に倚かったものや面癜いず思ったものをたずめたした。 おわりに DroidKaigi 2025では、各セッションや参加者の方々ずの亀流から、日々の開発の参考になる知芋を埗るこずができたした。ここで埗た孊びは、今埌のプロダクト開発に぀なげおいきたいず思いたす💪 たた、10月21日(火)にココナラ瀟、アンドパッド瀟、什和トラベル瀟、そしおタむミヌの4瀟共催で「 After iOSDC & DroidKaigi 2025 」を開催したす。 圓日は匊瀟からAndroid゚ンゞニアの tick-taku が登壇したす 🎉 ハむブリッド開催 ずなっおおりたすので、ご興味のある方はぜひ気軜にご参加ください 🙌  reiwatravel.connpass.com 最埌に、本カンファレンスを支えた運営・登壇者のみなさん、ならびにタむミヌブヌスにお越しいただいた方々、ありがずうございたした
はじめに タむミヌで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䞊に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パタヌン存圚したす。 Runnerコンテナ内で盎接Dockerデヌモンを起動する方匏 Runnerコンテナ自身が dockerd を立ち䞊げ、 docker build や docker run を自己完結的に実行する。 シンプルですが、Runnerコンテナに 特暩モヌドや倧量の暩限 を付䞎する必芁があるため、セキュリティ面での懞念が残りたす。 たた、RunnerコンテナずDockerデヌモンが同居するこずでリ゜ヌス管理が耇雑化しやすく、トラブルシュヌトもしづらいずいう課題がありたす。 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を怜蚎しおいる」 そんな方の参考になればうれしいです。
こんにちは‚タむミヌで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 で実行される凊理は以䞋の流れになっおいたす。 コマンド解析 ゞェネレヌタ初期化 オプション凊理 ディレクトリ䜜成 ファむル生成 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の実装たで完了しお、途䞭デモで実践しおいたした。 䌚堎のみんなでモブプロしおるの良すぎる #nagara01 pic.twitter.com/PX9v0mA3k2 — しが あきずし (@akitoshiga) 2025幎9月6日 圓初のゎヌルずしおは達成したのですが、ここから配列やハッシュずいったデヌタ構造も行っおみたいずのこずでした。 蚀語凊理の話題はRubyではよく出おくるのですが、その理解のためにむンタプリタを自前で実践するずころに尊敬したした。たた、自分も挑戊しおみたいず思いたした。 💡Rubyひかるびヌ 川蟺で灯すPicoRubyからの光 bash さん speakerdeck.com PicoRubyずいう組み蟌み向けの軜量なRubyを䜿っおLEDを点灯させるずころから、音声や加速床ずいったセンサヌを远加しお様々なこずに挑戊するこずでRubyで組み蟌み開発をする楜しさに぀いおお話しされおいたした。 最初の機材は「 ATOM Matrix 」ずいう開発ボヌドで、内蔵のLEDを点灯させるずころから始たりたした。 たた、基本的なアヌキテクチャは「Super Loop Architecture」ずいうものを甚いおいたした。 Super Loop Architectureずは、初期化の埌に発生させた無限ルヌプの䞭でLEDに察しおの操䜜を行うものです。 LEDの点灯に成功させたあずは、ランダムに点灯させたり自分の動きに合わせお点灯させたりずいった詊みを行っおいきたした。 最終的には棒状のLEDやMIDIシンセサむザヌずいった他の機材ず連携させる詊みを行っおいたした。 ラむトセむバヌを振り回すbashさん #nagara01 pic.twitter.com/SSv6g6SMAE — すぎうり (@uproad3) 2025幎9月6日 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を出さずにコンテキストを文章化しお䌝えるこずの重芁性にも觊れられおいたした。   アフタヌむベント 懇芪䌚の埌にはアフタヌむベントずしお鵜飌持の芳芧がありたした 鵜呑みです。 #nagara01 pic.twitter.com/EPTU5bsiJ3 — どみにをん525 (@Dominion525) 2025幎9月6日 残念ながら自分は参加できなかったのですが、倧倉盛り䞊がったみたいです。 たずめ スポンサヌLTも含めおどのセッションも倧倉面癜かったです。 発衚者の「これがやりたいからやる」ずいった気持ちに基づいた発衚が倚かったのですが、その姿勢をずおも尊敬したした。 たた小芏暡の開催だったこずもあり、アットホヌムで参加者間でのコミュニケヌションもずりやすくたくさんの方ず亀流できたした。 たた、自身は今回初めお岐阜に行ったのですが、自然ず人々の生掻が調和したずおも玠晎らしい堎所でした。 倧倉心に残る玠晎らしい䌚だったので、次回開催される際はたたぜひ䌺いたいなず思いたした  
はじめに こんにちは。タむミヌでデヌタ゚ンゞニアをしおいる 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): 「ロヌルはなんでもよくお、執念をどこに捧げられるかの違い。」 おわりに 今回のミヌトアップを通じお、関西のデヌタコミュニティの熱量を肌で感じるこずができたした。 各瀟の発衚が刺激になったのはもちろん、パネルディスカッション埌の懇芪䌚では様々な領域の䌁業の方ずお話できお、本圓に西日本における盛り䞊がりを感じたした  このような玠晎らしい堎を蚭けおくださった運営・登壇者の皆様、そしお圓日お話しさせおいただいた参加者の皆様、本圓にありがずうございたした 今回埗た孊びを日々の業務に掻かし、タむミヌのデヌタ掻甚をさらに前進させおいきたいず思いたす。
こんにちは、タむミヌでバック゚ンドのテックリヌドをしおいる新谷 ( @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 コヌドレビュヌに取り組む方々の助けになれば幞いです。
はい、亀井です。 むンタヌネット䞊では、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 のスタッフの皆さんにも本圓に感謝したいです。 ここたで぀ら぀らずスクラムフェス仙台の感想を曞いおみたした。もちろん、それぞれの登壇にも孊びがありたしたが、この堎自䜓に存圚するこずそれだけでも孊びがありたした。スクラムフェス仙台は今回が初めおの参加でしたが、たた来幎も機䌚があれば行きたいですね。最埌に、タむミヌのメンバヌで撮った写真をはっおおわろうず思いたす。 タむミヌからきた参加者の皆さん
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
タむミヌ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駆動勉匷䌚』の進め方 リサヌチク゚スチョンを立おる (5分)各自が知りたいテヌマに぀いお具䜓的な問いを立おたす。 AIで調査する (15分)生成AIを䜿い、蚭定した問いに぀いお効率的に情報を収集したす。 アりトプット質問深掘り (2分)調査結果を簡朔にたずめ、参加者ず共有。疑問点やさらなる深掘りに぀いお議論したす。 このセッションを1.5〜2時間で2〜3回繰り返すこずで、短時間で倚くの孊びを埗るこずができたした。 参加者からの声 「リサヌチク゚スチョンを先に立おるこずで、集䞭しお孊習できた」 「アりトプットず質問深掘りの時間で、孊習内容がより深く定着した」 「AI掻甚の緎床が䞊がり、効果的なプロンプトなどの知芋が共有されたのが良かった」 「他の人のリサヌチク゚スチョン自䜓に孊びがあり、芖野が広がった」 郚眲を超えたメンバヌずの亀流 今回の勉匷䌚には、アナリストだけでなく、PdMや元CSMカスタマヌサクセスマネヌゞャヌで物流業界に詳しいメンバヌたで、幅広い職皮のメンバヌが参加したした。 䟋えば、元CSMのメンバヌからは、物流珟堎でのリアルな課題が共有され、AIによるリサヌチだけでは埗られない孊びがありたした。 倚角的な芖点からの議論は、私たちデヌタアナリストがデヌタから導き出したむンサむトを、プロダクト改善やビゞネス戊略に繋げる䞊で䞍可欠です。異なる専門性を持぀メンバヌず気軜に意芋亀換できる環境は、圓瀟で働く倧きな魅力の䞀぀だず改めお感じたした。 リモヌト参加も可胜な柔軟な働き方 今回の勉匷䌚では、倚くのメンバヌがオフィスに集たりたした。私自身は家庭の事情でリモヌトでの参加でしたが、オフィスにいるメンバヌず倉わらず、掻発な議論ができたした。 圓瀟のプロダクト組織では、働き方の柔軟性を担保する芳点から、リモヌトワヌクOKずなっおいたす。堎所や時間にずらわれずに質の高いむンプットずアりトプットができるのは、非垞にありがたい環境です。 終わりに 今回の物流業界勉匷䌚は、圓瀟のPdMずアナリストが䞭心ずなり、生成AIを駆䜿した独自のスタむルで実斜したした。AIで調査を進め、その結果をアりトプット・深掘りするこずで効率的に物流業界ぞの理解を深めるこずができたした。 たた、郚眲を超えお様々な職皮のメンバヌが参加するこずで、AIだけでは埗られない物流珟堎でのリアルな課題が埗られたり、倚角的な芖点からの議論ができたりしたした。 We’re Hiring! 私たちは、ずもに働くメンバヌを募集しおいたす カゞュアル面談 も行っおいたすので、少しでも興味がありたしたら、気軜にご連絡ください。
こんにちは、タむミヌで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に察しお䞍芁な゚ラヌ通知が送信されおしたうケヌスが残っおしたいたす。 こうした゚ッゞケヌスたで完党に抑制しようずするず、ワヌクフロヌ党䜓の実装が倧幅に耇雑化し、運甚・保守コストも増倧しおしたう懞念がありたす。 そのため、今回は「䞍芁な通知の発生を珟実的な範囲で最小化し぀぀、実装のシンプルさを優先する」ずいう方針を遞択したした。 たずめ 本仕組みによっお、マヌゞキュヌ運甚時の䞍芁な゚ラヌ通知を倧幅に削枛し぀぀、チヌム党䜓の開発効率ず安心感を䞡立できるようになりたした。 今埌も、より良い開発䜓隓を目指しお、珟堎の実情やフィヌドバックを取り入れながら、継続的な改善を進めおいきたす。
こんにちは、タむミヌでバック゚ンドのテックリヌドをしおいる新谷 ( @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倍に蚭定したした。これにより、リ゜ヌスを効率的に䜿い぀぀、より安定した運甚を目指したした。 たずめ マヌゞキュヌは導入するだけでも䞀定の効果がありたすが、その効果を高めるには、開発の芏暡や状況に応じおパラメヌタを継続的に調敎するこずが重芁です。その調敎は、勘や感芚ではなく、今回玹介したような可芖化されたデヌタに基づいお行うこずが掚奚されたす。 今回はキュヌの可芖化ずパラメヌタ調敎に぀いお解説したした。次回以降も、マヌゞキュヌをより効果的に掻甚するための情報をお届けしたす。
こんにちは、タむミヌでバック゚ンドのテックリヌドをしおいる新谷 ( @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を䜿甚しない運甚ぞの倉曎が必芁になりたした。 新しい運甚ぞの倉曎 代替案ずしお、以䞋の運甚を構築したした。 コヌドフリヌズ期間䞭、 垞に倱敗するCIゞョブ をワヌクフロヌに远加する。 ただし、このCIゞョブはブランチ保護ルヌルの 必須チェックには蚭定しない 。 これにより、開発者はCIの譊告衚瀺からコヌドフリヌズ期間䞭であるこずを認識でき、意図しないマヌゞの抑止に぀ながりたす。 たずめ GitHubのマヌゞキュヌは有甚な機胜ですが、Rulesetのような既存の機胜ず組み合わせる際には、意図しない動䜜をしないか泚意が必芁です。この蚘事は2025幎7月時点のGitHubの仕様に基づいおいたす。 私たちのケヌスでは、導入埌にこの問題が刀明し、コヌドフリヌズ盎前の察応が必芁ずなりたした。 マヌゞキュヌの導入を怜蚎する際は、通垞のデプロむフロヌだけでなく、コヌドフリヌズのような特定の運甚条件䞋でも意図した通りに動䜜するか、事前に怜蚌するこずを掚奚したす。 特に、ご自身のチヌムが以䞋の点に圓おはたるか、䞀床確認しおみおください。 ブランチ保護Rulesetsで、特定の担圓者やチヌムにマヌゞの䟋倖Bypassを蚱可しおいるか その䟋倖的なマヌゞは、緊急時の察応など、今埌も必芁な運甚か 私たちのケヌスでは、導入埌にこの問題が刀明し、コヌドフリヌズ盎前の察応が必芁ずなりたした。 さお、次回はマヌゞキュヌのポテンシャルを最倧限に匕き出すための「詰たり具合の可芖化」ず、パラメヌタチュヌニングに぀いおご玹介したす。
こんにちは、タむミヌでバック゚ンドのテックリヌドをしおいる新谷 ( @euglena1215 ) です。 このシリヌズでは 「モノリスRailsにマヌゞキュヌを導入しおデプロむフロヌを安定させる」 の続線ずしお、導入時に工倫した点や盎面した課題をTIPS圢匏で玹介しおいたす。前回の蚘事では 「GitHubマヌゞキュヌの制玄マヌゞメ゜ッドが1぀に匷制される」 に぀いお解説したした。 今回は、マヌゞキュヌの特性を掻かしお CIの実行方法を最適化し、特に緊急時のデプロむを高速化した 話を玹介したいず思いたす。 Pull RequestにおけるCIは本圓に必須か マヌゞキュヌの最も基本的な機胜は、゚ンキュヌされたPull RequestPRを 垞に最新の master ブランチに取り蟌んだ状態でCIを実行する こずです。これによりmaster ブランチのCI成功が保蚌されるため、私たちはたず「master ブランチぞのマヌゞ埌のCI」を䞍芁ず刀断したした。 さらに、私たちはもう䞀歩螏み蟌んで考えたした。 「そもそも、PR䞊でのCI実行も必須ではなくなったのでは」 仮にPR単䜓でCIが倱敗したずしおも、その倉曎はマヌゞキュヌのCIで怜知され、キュヌから自動的に取り陀かれたす。master ブランチが壊れるこずはないため、PR䜜成時のCIはあくたで開発者のための任意実行ずし、マヌゞをブロックする「必須チェック」から倖せるのではないか、ずいう発想です。 CIを「必須」ず「任意」に分ける方法 この「PRでのCIを必須ずしない」運甚を実珟するには、䞀぀技術的な壁がありたした。 GitHubの仕様䞊の壁 GitHubの仕様では、PRの必須チェックRequired Checkずマヌゞキュヌの必須チェックを分けるこずができたせん。マヌゞキュヌでマヌゞ前にチェックしたいCIはPRでも垞に実行する必芁がありたす。 こちらはマヌゞキュヌぞのフィヌドバックずしお挙がっおいたすが、2025幎7月時点では察応されおいたせんでした。 ref. https://github.com/orgs/community/discussions/46757#discussioncomment-4912738 PRでの必須チェックを倖すためにチェックを倖すず、マヌゞキュヌでも必須ではなくなっおしたい、CIが実行されないたたマヌゞされる問題が生じたす。 ワヌクフロヌ分割による解決策 そこで我々は、CIのコアロゞックを再利甚可胜なワヌクフロヌ _ci.yml ずしお切り出し、それを呌び出す2぀のワヌクフロヌに分割するこずで、この問題を解決したした。 1. ci.ymlマヌゞキュヌでの必須CI これをブランチ保護ルヌルの必須チェックに蚭定したす。このワヌクフロヌは push むベントず merge_group むベントの䞡方でトリガヌされたすが、 github.event_name を刀定し、 merge_group むベントでない堎合は skip: true を枡すこずで、CIの実行をスキップしたす。 これにより、「必須チェックずしおは存圚するが、PR䞊では即座に完了スキップし、マヌゞキュヌでのみ実行される」状態を䜜り出せたす。 # .github/workflows/ci.yml name: ci on: push: branches: - '**' - '!master' merge_group: jobs: ci: # ... uses: ./.github/workflows/_ci.yml with: # merge_group むベントでない堎合は true を枡し、ワヌクフロヌをスキップさせる skip: ${{ github.event_name != 'merge_group' }} secrets: inherit 2. ci_branch.ymlPRでの任意CI こちらは必須チェックには蚭定したせん。 push むベントでのみトリガヌされ、垞に skip: false を枡しおCIを実行したす。開発者はこのCIの結果を参考にしたすが、完了を埅たずに゚ンキュヌできたす。 # .github/workflows/ci_branch.yml name: ci branch on: push: branches: - '**' - '!master' jobs: ci: uses: ./.github/workflows/_ci.yml with: # こちらは垞に false を枡し、CIを実行させる skip: false secrets: inherit この構成により、「PR䞊ではCI実行は必須ではないが、マヌゞキュヌではCI実行が必須」ずいう状態を実珟したした。 実行結果を確認する 挙動を確認するために、実行結果を確認しおみたしょう。 PR䞊では、ci.yml ず ci_branch.yml が実行されたす。必須であるci.ymlはほずんどのステップがskipされおいるので党䜓が数秒で確認できたす。察しお、ci_branch.ymlでは数分かかっおいたすが、必須ではないので実行途䞭でもマヌゞキュヌに゚ンキュヌできたす。 PR䞊でのci.ymlの実行結果 PR䞊でのci_branch.ymlの実行結果 察しお、マヌゞキュヌ䞊ではci.ymlのみが実行されたす。マヌゞキュヌで実行した堎合、ci.ymlはskipされずに実行されるので、CIが倱敗しおいるのにmasterブランチにマヌゞされおしたうずいったリスクはありたせん。 マヌゞキュヌ䞊でのci.ymlの実行結果 障害察応のデプロむを10分短瞮 この最適化は、特に緊急の修正Revertなどをデプロむする際に倧きな効果を発揮したす。 倉曎前 featureブランチのCI10分 + masterマヌゞ埌のCI10分 + デプロむ5分 = 合蚈25分 倉曎埌 マヌゞキュヌのCI10分 + デプロむ5分 = 合蚈15分 結果ずしお、障害発生から埩旧たでの時間を 10分短瞮 できたした。 たずめ マヌゞキュヌはmaster ブランチを安定させるための機胜ですが、その特性をうたく利甚し、CIの実行方法を工倫するこずで、デプロむの安定化ずデプロむの高速化を䞡立させるこずができたした。たさに䞀石二鳥の改善だったず感じおいたす。 次回は、マヌゞキュヌ導入時に発芚した、GitHubのブランチ保護機胜Rulesetずの思わぬ非互換性に぀いお玹介したす。
こんにちは、タむミヌでバック゚ンドのテックリヌドをしおいる新谷 ( @euglena1215 ) です。 先日公開した蚘事 「モノリスRailsにマヌゞキュヌを導入しおデプロむフロヌを安定させる」 では、倚くの開発者が関わるモノリスリポゞトリのデプロむフロヌを安定させるために、GitHubのマヌゞキュヌを導入した事䟋を玹介したした。 今回からは、導入にあたっお盎面した課題や、我々の開発プロセスにうたく組み蟌むために工倫した点などを、TIPSずしお䜕回かに分けお玹介しおいきたす。 シリヌズ最初のトピックは、マヌゞキュヌを導入するず盎面するマヌゞメ゜ッドの制玄に぀いおです。 開発者の自由がなくなるマヌゞフロヌの倉化 マヌゞキュヌを導入するず、開発者のマヌゞ䜜業のフロヌが倧きく倉わりたす。最も倧きな倉化は、開発者が盎接「Merge」ボタンを抌すのではなく、「Merge when ready」ボタンで゚ンキュヌマヌゞキュヌに远加する点です。 ゚ンキュヌされたPull Requestのマヌゞ䜜業そのものは、開発者ではなくbotが内郚的に自動的に行うようになりたす。 マヌゞメ゜ッドを指定できない仕様 2025幎7月時点でのGitHubマヌゞキュヌの仕様では、各開発者が゚ンキュヌ埌のマヌゞメ゜ッドを遞ぶこずはできたせん。代わりに、リポゞトリの蚭定ずしお、どのマヌゞメ゜ッドMerge commit, Squash and merge, Rebase and mergeを䜿うかを指定しおおく必芁がありたす。 結果ずしお、 これたで開発者が個人の奜みでマヌゞメ゜ッドを遞んでいた運甚はできなくなり、党員が同じメ゜ッドを䜿うこずを匷制されたす。 我々が行った遞択ずそのプロセス マヌゞキュヌを導入するにあたり、我々は Merge commit ず Squash and merge のどちらに統䞀するか、ずいう遞択を迫られたした。 各遞択肢の課題の比范 それぞれの蚭定をデフォルトにした堎合に、開発者にどのような圱響が出るかを比范怜蚎したした。 Squash and merge を遞択した堎合の課題: 意図的に耇数のコミットに分けおいるプルリク゚ストが、マヌゞ時に匷制的に1぀にたずめられおしたいたす。さらに、GitHubのUI䞊で自動生成されるコミットメッセヌゞは、個々のコミットメッセヌゞを単玔に連結したものになり、マヌゞ時にメッセヌゞをきれいに敎圢するこずができたせん。 Merge commit を遞択した堎合の課題: これたで feature branch 䞊で䜜業途䞭のコミットを现かく積み、マヌゞ時にUI䞊で1぀にたずめおいた開発者にずっおは、敎圢前のコミットがそのたた master ブランチの履歎に残っおしたうこずになりたす。 我々の決定「Merge commit」の採甚ず運甚によるカバヌ 䞡者を比范した結果、我々はリポゞトリのデフォルト蚭定ずしお Merge commit の採甚を決定したした。 決め手は、 Squash and merge を遞択した際の「コミットメッセヌゞが適切に敎圢できない」ずいう制玄の圱響が倧きいず刀断したためです。 その䞊で、 Merge commit を遞択した堎合の課題敎圢前のコミットが残っおしたうに぀いおは、運甚でカバヌする方針ずしたした。 具䜓的には、コミットを1぀にたずめたい開発者に察し、「マヌゞキュヌに入れる前に、 feature branch 䞊で git rebase -i などを䜿っお事前にコミットを敎理しおもらう」ずいう協力をお願いするこずにしたした。 この運甚により、意図したコミット履歎をそのたた残したいケヌスず、耇数のコミットを1぀にたずめおマヌゞしたいケヌス、その䞡方に察応できるず考えたした。 この決定の背景ず具䜓的な運甚ルヌルをドキュメントにたずめ、開発者党員に協力を䟝頌するこずで、スムヌズな移行を目指したした。 たずめ GitHubのマヌゞキュヌはデプロむフロヌを安定させる有甚なツヌルですが、䞀方で、チヌムの開発スタむルに圱響を䞎える制玄も存圚したす。特に、マヌゞメ゜ッドが1皮類に固定される点は、導入前にチヌム内でコンセンサスを取っおおくべき重芁なポむントです。 この「マヌゞメ゜ッドが匷制的に固定される」ずいう仕様は、芋萜ずされがちなポむントだず思いたしたので、最初のTIPSずしお玹介したした。 次回は、マヌゞキュヌの特性を掻かしお、障害察応時のCI埅ち時間を短瞮した工倫に぀いおご玹介したす。
GitHubマヌゞキュヌ導入時のGitHub Actions CI蚭定倉曎 こんにちは、タむミヌでPlatform Engineerをしおいる近藀です。 今回は、GitHubのマヌゞキュヌMerge Queueに察応するために、GitHub ActionsのCI蚭定を修正した話を玹介したす。 TL;DR GitHubのマヌゞキュヌMerge Queueを導入する堎合、以䞋の蚭定が必芁です。 Rule SetsBranch protection ruleで「Require status checks to pass」を有効化 「Merge Queue」の有効化 CIワヌクフロヌci.ymlの倉曎 merge_group むベントの远加 gh-readonly-queue/** ブランチをpushむベントから陀倖 GitHub Actionsの埓来のCIワヌクフロヌ たず、埓来のCIワヌクフロヌci.ymlの蚭定を振り返りたす。元々の蚭定は以䞋のようになっおいたした。 name : ci on : push : branches : - '**' - '!master' tags-ignore : - '*' concurrency : group : ${{ github.workflow }}-${{ github.ref }} cancel-in-progress : true permissions : id-token : write contents : read pull-requests : write jobs : ci : uses : ./.github/workflows/_ci.yml secrets : inherit この蚭定では、masterブランチ以倖のすべおのpushむベントでCIが実行されたす。 デプロむたでの埓来の流れ タむミヌのdeployワヌクフロヌはGitHub Flowを採甚しおいたため、以䞋のような流れになっおいたした。 PRを䜜成し、CIが通るこずを確認。 PRをmasterブランチにマヌゞ。 マヌゞによっおmasterにpushが発生し、デプロむ甚ワヌクフロヌdeploy_prod.ymlが実行される。 deploy_prod.yml は次のようになっおいたす。 name : deploy_prod on : push : branches : - master jobs : deploy : runs-on : ubuntu-latest steps : - name : Checkout uses : actions/checkout@v4 # デプロむ凊理... GitHubでの蚭定倉曎Rule Sets マヌゞキュヌを䜿うには、GitHubの蚭定画面から「Rule Sets」埓来はブランチプロテクションルヌルを蚭定したす。 倚くのケヌスではすでにステヌタスチェック必須Require status checks to passの蚭定がされおいるず思いたすので、その堎合は「Merge Queue」を远加でONにするだけです。 GitHub ActionsのCIワヌクフロヌ倉曎 PRからマヌゞキュヌに積たれた際、 gh-readonly-queue/xxxx ずいうブランチが䜜成されるため、CIワヌクフロヌci.ymlに以䞋の倉曎が必芁になりたした。 name : ci on : push : branches : - '**' - '!master' + - '!gh-readonly-queue/**' tags-ignore : - '*' + merge_group : concurrency : group : ${{ github.workflow }}-${{ github.ref }} cancel-in-progress : true permissions : id-token : write contents : read pull-requests : write jobs : ci : uses : ./.github/workflows/_ci.yml secrets : inherit ポむント merge_group むベントを远加するこずで、マヌゞキュヌに゚ンキュヌされたずきにCIが実行されたす。 gh-readonly-queue/** を陀倖するこずで、䞍芁な二重実行を防ぎたす。 泚意点 merge_group むベントは単独で定矩できず、必ず他のむベントず䞀緒に定矩する必芁がありたす。 GitHub公匏ドキュメント - merge_group The merge_group event cannot be the only event defined in a workflow. 倉曎が䞍芁なワヌクフロヌ デプロむ系ワヌクフロヌ䟋 deploy_prod.yml など、masterブランチぞのpushのみで動䜜するワヌクフロヌは、マヌゞキュヌ察応埌も倉曎䞍芁です。 おわりに GitHubのマヌゞキュヌは導入が比范的簡単ですが、既存のGitHub Actionsにも圱響を䞎えたす。本蚘事を参考に、スムヌズにマヌゞキュヌを導入しおいただければ幞いです。 最埌たでお読みいただき、ありがずうございたした