こんにちは！人材紹介開発グループでSRE活動をしている大上です。 私は2026年1月から、心機一転SRE領域に挑戦しています。SWEとして約7年のキャリアはありますが、AWSやインフラの世界ではまだ3か月目の初心者です。 そんな私が、人生初のオフラインイベント「JAWS DAYS 2026」に飛び込んできました。 本記事では、インフラ初心者かつイベント初参戦の私が、会場の熱気に揉まれながら何を感じ、どんな景色を見てきたのかを等身大でお伝えします。 参加に対する不安 正直なところ、参加が決まってから当日を迎えるまでは、期待よりも落ち着かない気持ちの方が大きかったように思います。SRE活動を始めてまだ日が浅い自分が、この大規模なイベントから何を持ち帰れるのか。その具体的なイメージを、当時は全く描けていなかったからです。 弊社ではこうしたイベントへの参加を業務の一環として認めてくれていて、交通費や宿泊費も会社がサポートしてくれます。とても恵まれた環境だなと感じる一方で、その手厚さから「しっかりと実務に役立つ成果を持ち帰らなければいけない」というプレッシャーがありました。 そんな中、周囲から「まずはイベントの雰囲気を知って、モチベーションを上げるだけでも十分価値があるよ」というアドバイスをもらって、少し気持ちが楽になりました。技術を身につけるのは時間がかかりますが、マインドは自分次第ですぐに切り替えることができます。今回はとにかく経験を積む場にしようと割り切ったことで、ようやく純粋な気持ちで会場に向かうことができました。 関心に沿ったセッション選び 当日は会場で迷子にならないように、「気になるセッションを片っ端から視聴する」というシンプルな作戦を立てました。タイムテーブルを見て事前に予定を組みましたが、その際に1つ自分の中で決めたルールがあります。それは、セッションの難易度を示すLevelを一切気にしない、ということでした。 SRE活動3か月目という状況から、高Levelのセッションは避けてしまうかもしれませんが、今回は今の自分自身の興味を優先しました。もちろん全てを完璧に理解できたわけではありません。しかし、SWEとして7年間システムを作ってきた経験があったからこそ、語られている設計思想や「なぜその構成にするのか」という論理的な部分は、自分なりのフィルターを通して解釈することができました。自分の関心に素直に従ったことで、最後まで集中力が途切れず、自分の引き出しにはなかった考え方を知るたび、視野が広がっていくような感覚がありました。 漠然としたAIへの不安 今、多くのエンジニアがそうであるように、私も「生成AIとどう向き合うべきか」という点には漠然とした不安を感じていました。特に新しい領域にチャレンジしている最中だと、「自分が今必死に覚えていることは、すぐにAIに取って代わられるんじゃないか」なんて考えてしまうこともあります。 しかし、今回のイベントを通じてその不安はかなり解消されました。第一線で活躍するSREの方々の見解に触れることで、SREとしての視点でAIをどう捉え、どう向き合うべきかという解像度が大幅に向上しました。特に印象に残ったのは、AIを「アンプ」に例えた考え方です。AIは人間の強みも弱点もそのまま増幅させてしまう性質があるため、ただ導入するだけではリスクも大きくなります。だからこそ、AIが踏み外さないための「ガードレール」や仕組みを整えるSREの役割は重要となってきます。 これまでは漠然とした不安を感じることもありましたが、今ではその輪郭がはっきりし、不安は期待へと書き換わっています。 会場の温度感 私は普段、福岡でフルリモート勤務をしています。リモートワークは集中できるし大好きな働き方ですが、今回のイベントで改めて「対面の温度感」の大切さを再認識しました。 参加前は、「堅苦しい講義」のようなものなのかなと考えていたのですが、現地で感じるお祭りのような空気感によって、一気に楽しいイベントへと上書きされていきました。情報はオンラインでも十分に手に入りますが、現場の空気はやっぱり別格でした。1000人以上ものエンジニアが同じ場所に集まって、同じ熱量で技術を語り合っている。そんな空間にただ身を置いているだけで、自分のモチベーションが内側からじわじわと底上げされていくのを感じました。 物理的な収穫も、オフラインならではの楽しみです。会場でいただいたノベルティは、作り込まれており、手に取るだけで嬉しくなるものばかりでした。こうした「モノ」としての思い出が手元に残ることも、デジタルな情報収集だけでは得られない、現地参加のご褒美のように感じます。 最後に 振り返ってみれば、参加前にあんなに悩んでいたのが嘘のように、前向きな気持ちでいっぱいです。 もし、今の私と同じようにイベント参加を迷っているという方がいたら、私は全力で参加してみることをおすすめします！経験年数や技術力は一旦置いておいて、その場の熱狂に身を任せてみることも大変貴重な経験となるはずです。 そして、最後になりますが、この素晴らしいイベントを企画・運営してくださった運営メンバーと当日スタッフの皆様、本当にありがとうございました！

.entry .entry-content .table-of-contents > li > ul { display: none; } はじめに こんにちは、WEAR開発部バックエンドブロックのブロック長を務めている伊藤です。普段は弊社サービスである WEAR のバックエンド開発・組織運営を担当しています。 WEARのバックエンドブロックは約10名のエンジニアで構成されています。組織としてはマトリックス型を採用しており、各メンバーはバックエンドブロックに所属しながら、複数の職種で構成されるスクラムチームにも1〜3名ずつ配置されています。スクラムチームにはPdM（プロダクトマネージャー）やデザイナー、フロントエンドエンジニア、QAなど他職種のメンバーが集まります。加えてリモートワークが基本の環境です。 この体制ではコードレビューのリードタイムが長期化しやすいという課題がありました。本記事では、PRオープンからマージまでの平均時間を約26時間から約11時間へと短縮した取り組みを紹介します。 目次 はじめに 目次 抱えていた課題 コンテキストの分断 レビューのボトルネック化 構造的に後回しになるレビュー 課題を解決したアプローチ 5名ずつの2グループ制 全体朝会＋グループ朝会の二段構成 段階的にたどり着いた「もくもくレビュータイム」 Gatherを活用する理由 Findy Team+による指標の可視化と週次改善 コードレビューガイドラインとAIレビューの活用 効果と得られた知見 段階的な施策でリードタイムが半減する コンテキストの把握範囲を狭めることでレビュー速度が上がる 「仕組みだけ」では不十分、同期の時間が文化を変える メトリクスの可視化が「感覚」を「共通言語」に変える AIレビューは「人間のレビューの質」を高める おわりに 抱えていた課題 コンテキストの分断 マトリックス組織では、バックエンドエンジニアが複数のスクラムチームに分散して配置されます。WEARのバックエンドブロックでは約10名が1〜3名ずつ別々のチームに所属しており、隣のメンバーが何を開発しているかが見えにくい状態でした。 PRが作成されても、レビュアーにとってはまず「このPRの背景にある仕様は何か」を理解するところから始まります。コンテキストが共有されていないため、レビューの入口でつまずくことが頻繁に起きていました。 レビューのボトルネック化 WEARのバックエンドブロックでは品質担保のため、2名以上のApproveを必須としています。しかしコンテキストがない状態でのレビューは仕様理解から始まるため、1件あたりの負荷が大きくなります。 改善に取り組む前はレビュアーをランダムに2名アサインしていましたが、得意領域や所属チームがバラバラで、忙しさも人によって異なります。結果として、レビューが後回しになりやすく、PRオープンからマージまでに24時間を超えるケースが多々ありました。 構造的に後回しになるレビュー チーム全員がレビューの重要性は理解していました。しかし、自身のスクラムチームの開発タスクとレビュー依頼が常に競合する状態では、レビューは「割り込みタスク」として後回しにされがちです。 リモートワーク環境では、オフィスで自然に発生する「ちょっと見てほしい」という一声が生まれません。PRを出しても反応のないまま放置される状況が常態化していました。 これは個人の意識の問題ではなく、仕組みで解決すべき構造的な課題でした。 課題を解決したアプローチ 5名ずつの2グループ制 まず、10名を5名ずつの2グループに分けました。グループの編成にあたっては、以下の点を考慮しています。 同じマトリックスチームのメンバーを同一グループにまとめる 関連度の高いチーム（似た領域を触るチーム）やドメインが近い人を同じグループにする ベテラン社員が偏らないようにし、レビューや設計レビューの質にむらが出ないようにする 5名という規模は、全員の作業状況を把握できるギリギリのサイズです。この単位にすることで、「何の仕様に取り組んでいるか」が自然と共有される状態をつくりました。 各グループにはグループリーダーを立て、グループ単位でPDCAを自走できる体制にしています。リーダーがグループ内の課題を拾い、改善施策を回しています。そこで得られた知見はもう一方のグループにも共有し、チーム全体の底上げにつなげています。 全体朝会＋グループ朝会の二段構成 毎日の朝会は、全体朝会（30分）とグループ朝会（30分）の二段構成で運用しています。 全体朝会（30分） では、バックエンドブロック全員が集まり、以下の内容を共有します。 小話やLT（チームの雑談・学びの共有） タスク共有（各メンバーの作業状況） 案件共有（お問い合わせ対応のアサインなど） 共有・相談（曜日ごとに担当者が議題を持ち寄る） グループ朝会（30分） では、各グループに分かれて以下を行います。 各スクラムチームから現在の作業状況を報告する チームメンバーのOpen PRを確認し、レビュー依頼をリマインドする 新規PRはPR作成者が画面共有しながらメンバーに内容を説明する 朝会後はそのまま「もくもくレビュータイム」としてレビューに取り組む（詳細は後述） 週1回、Findy Team+のチーム比較を確認し、1週間の振り返りと改善点を話し合う グループ朝会の司会は1週間交代で担当します。特定の誰かに運営が偏らないようにすることで、全員が主体的に関わる仕組みにしています。 ポイントは、グループ朝会で「未レビューのPR」を毎日確認する仕組みにしていることです。これにより、PRが誰の目にも触れずに放置されるという事態を構造的に防いでいます。 段階的にたどり着いた「もくもくレビュータイム」 実は、最初からレビュー専用時間を設けていたわけではありません。取り組みの初期はグループを分けて朝会でPRを確認するところから始めました。 それだけでもリードタイムは改善しましたが、新たな課題が見えてきました。朝会でPRの内容を共有しても、レビューに取り組む時間が仕組みとして確保されていなかったため、結局は各自の開発タスクが優先されがちでした。 そこで、グループ朝会の後にそのまま「もくもくレビュータイム」を設けることにしました。朝会が終わったらそのまま Gather （仮想オフィスツール）に残り、レビューに取り組みます。 もくもくレビュータイムの運用ルールは以下の通りです。 Gatherに集まり、各自が黙々とレビューする 必須でレビューしてほしい人がいる場合は、PR内でその人をメンションしておく メンションされたPRを優先的に確認し、メンションされた人のレビューは必須とする メンションは任意とし、各自の判断で行う（例：その機能に詳しい人へ仕様チェックを依頼したい場合など） この「朝会→もくもくレビュータイム」の流れを毎日のリズムとして定着させたことで、レビューが「空いた時間にやるタスク」から「毎日の習慣」に変わりました。 さらに、朝会後のレビュータイムとは別に、午後にも30分のもくもくレビュータイムを設けています。午前と午後の2回、同期的にレビューする接点をつくることで、1日を通してPRを素早くキャッチできるようになっています。 以下は、1日の流れを図にしたものです。 Gatherを活用する理由 もくもくレビュータイムにGatherの仮想オフィスを使っているのには明確な理由があります。 まず、レビュー中に聞きたいことがあればその場ですぐに声をかけられます。MTGをセットしたりSlackで非同期にやりとりしたりする必要がありません。さらに、他のメンバーが質問している内容も一緒に聞こえるので、自然と共通認識が形成されます。 リモートワークでは「ちょっと聞く」のハードルが高くなりがちですが、Gatherで同じ空間にいることで、オフィスの隣の席で気軽に質問するような感覚を再現できています。 Findy Team+による指標の可視化と週次改善 チームの開発パフォーマンスを Findy Team+ で継続的に計測しています。設定している目標値は以下の通りです。 PRオープン〜マージ：16時間以内 PRオープン〜1人目のレビュー：3時間以内 レビュー〜マージ：13時間以内 以下は実際にチームで確認しているレビューサマリの画面です。 週1回のグループ朝会で、2つのグループ間でリードタイムを比較し、「どこにボトルネックがあったか」を具体的に議論しています。以下はグループ間の比較画面です。 数値があることで「なんとなく遅い」ではなく「今週は1人目のレビューまでが遅かったのはなぜか」という建設的な振り返りができるようになりました。 Findy Team+の計測対象からの除外漏れがないかも毎週確認しています。具体的には、Dependabotによる自動PR、他部署の作業待ちが発生するPR、検証が必要でやむを得ずマージを保留するPRなど、チームのレビュープロセスの実態を反映しないものを除外しています。正確な数値を維持することで、指標の信頼性を保ち、チーム全体が同じデータを見て議論できる状態を担保しています。 グループ間の比較は健全な競争意識にもつながっています。「今週は相手グループの方がリードタイムを短縮できていた」という事実は、翌週の改善アクションを自発的に生み出す原動力になっています。この仕組みによって、改善が一時的な取り組みではなく、継続的に回り続けるサイクルとして定着しました。 コードレビューガイドラインとAIレビューの活用 レビュー観点を明文化したガイドラインを整備しました。以下の観点を体系的に定義し、レビュアーごとの品質のばらつきを低減しています。 Railsのベストプラクティス（RESTfulなAPI設計、Strong Parametersの適切な使用など） セキュリティ（SQLインジェクション対策、JWT認証、環境変数による機密情報の管理など） パフォーマンス（N+1クエリの検出、 nolock スコープによるロック回避、バッチ処理など） API設計（バージョニングの整合性、エラーレスポンスの統一フォーマットなど） テスト（RSpecのベストプラクティス、FactoryBotによる適切なテストデータ生成など） プロジェクト固有の規約（設計思想ドキュメントへの準拠、既存パターンとの一貫性など） 加えて、GitHub ActionsとClaude（Anthropic）を組み合わせたAIレビューの仕組みを導入しました。PRのコメントで @claude-review と呼びかけるだけで、上記ガイドラインに沿った自動レビューが実行されます。PRの差分を読み取り、インラインコメントと全体のまとめを日本語で返すため、人間のレビュアーが着手する前の一次スクリーニングとして機能しています。 実際のレビューでは、以下のフィードバックが返ってきます。 まとめコメント（抜粋） 🟡 Important N+1クエリ対策 : preload ではなく includes の使用を推奨 nolock スコープの使用 : 読み取り専用クエリでのパフォーマンス最適化 🟢 良い点 適切なバッチ処理: find_in_batches を使用してメモリ効率を考慮 充実したテストカバレッジ: 網羅的なテストケースで品質を担保 インラインコメント（抜粋） パラメータの型定義が既存のAPIと一貫していません。他のエンドポイントでは integer で定義されているため、一貫性を保つために型を変更することを推奨します。 注目すべきは、単に一般的なベストプラクティスを指摘するだけでなく、プロジェクト固有の設計思想ドキュメントや既存の実装パターンを踏まえた指摘をする点です。これは、AIレビューのプロンプトに「まずCLAUDE.mdと設計思想ドキュメントを読んでからレビューせよ」と指示しているためです。 また、PR作成前の段階でもClaude CodeやCursor、Codexなど、各メンバーがそれぞれのAIツールを使ってセルフレビューしています。AIのセルフレビュー → @claude-review を使った機械レビュー → 人間によるレビューという多段構成を取っています。これにより、人間のレビュアーが設計判断やビジネスロジックの妥当性に注力できる環境を整えています。 効果と得られた知見 段階的な施策でリードタイムが半減する 以下は、約2年間のリードタイム推移です。グループ制の導入（2024年4月）、生成AIによるPR数増加（2025年8月頃）、もくもくレビュータイム導入（2025年10月）の前後で変化が見て取れます。 各フェーズの平均時間は以下の通りです。 改善前（〜2024年3月） ：約26時間 グループ制導入後（2024年4月〜） ：約16時間まで短縮 生成AIによるコーディング普及後（2025年8月頃〜） ：PR数が週4〜6件から週8〜12件へ約2倍に増加し、約18時間へ上昇 AIレビュー・もくもくレビュータイム導入後（2025年10月〜） ：約11時間まで短縮 グループ制だけでも約10時間の改善がありましたが、生成AIの活用でPR数が約2倍に増えた際、一時的にリードタイムが上昇しました。そこにもくもくレビュータイムとAIレビューを組み合わせることで、PR数が増えた状態でもさらに短縮できています。 コンテキストの把握範囲を狭めることでレビュー速度が上がる チームを分けてレビューすることで、各メンバーが把握すべきコンテキストの範囲が大幅に狭まりました。10名全員の状況を追うのではなく、5名の動きだけ把握すればレビューに入れる状態をつくったことが、最も効果の大きかった施策です。 グループ朝会で毎日Open PRを確認する運用と組み合わせることで、「誰がどんなPRを出しているか」が常に頭に入っている状態になります。レビューに着手する際のコンテキストスイッチのコストが大幅に下がりました。 「仕組みだけ」では不十分、同期の時間が文化を変える グループ分けと朝会での情報共有だけでは、レビューのリードタイムは十分には改善しませんでした。転機となったのは「もくもくレビュータイム」の導入です。 情報を共有しても、レビューする「時間」が確保されていなければ結局後回しになります。午前と午後に同期的な接点を設け、「みんなが同じタイミングでレビューする」という習慣を作ったことで、レビューが日常のリズムの一部に変わりました。 重要なのは長い会議を増やすことではなく、短い同期時間を毎日の習慣として組み込むことです。 メトリクスの可視化が「感覚」を「共通言語」に変える Findy Team+の数値とグループ間比較により、改善が「個人の頑張り」ではなく「チームの仕組み」として回るようになりました。 特に週1回のFindy Team+チェックを定例化したことで、数値が悪化したときに早く気づき、翌週の改善アクションにつなげるサイクルが定着しています。ボトルネックを感覚ではなくファクトで議論できることが、継続的な改善を支えています。 AIレビューは「人間のレビューの質」を高める AIレビューの効果は、リードタイム短縮だけではありません。コーディング規約への準拠やN+1クエリの検出といった機械的に判断できる指摘をAIが担うことで、人間のレビュアーがそれらを一つひとつ確認する必要がなくなりました。その分、設計判断やビジネスロジックの妥当性といった、より本質的な観点へ集中できるようになっています。 また、PR作成者自身がAIツールでセルフレビューしてからPRを出すことで、レビュー時の指摘事項が減り、レビュー1件あたりの負荷が下がっています。結果として、レビューの「速度」と「質」を両立できる状態に近づいています。 おわりに レビューのリードタイム改善は、個人の意識改革ではなく仕組みの設計で実現できます。本記事で紹介した施策をまとめると、以下の4点に集約されます。 認知範囲の縮小 ：グループを分けることで、把握すべきコンテキストを絞る 同期の接点の設計 ：朝会でPRを共有し、もくもくレビュータイムで実行する。午前と午後に接点を分散させることで情報のキャッチアップを早める 指標の可視化 ：Findy Team+で数値を計測し、週1回振り返る。数値で語れる文化をつくり、改善を仕組み化する AIによるレビュー品質の底上げ ：AIレビューとセルフレビューで定型的な指摘を自動化し、人間は設計判断に集中する 私たちのチームも最初からうまくいったわけではありません。グループ分けだけでは足りず、レビュー専用時間の追加やFindy Team+での振り返りの定例化、AIレビューの導入など、段階的に改善を重ねてきました。結果として、PRオープンからマージまでの平均時間は約26時間から約11時間へと短縮しています。 マトリックス組織×リモートという環境は、コードレビューにとって不利な条件が揃いやすい構造です。しかし適切な単位でチームを分割し、同期と非同期のバランスを設計し、指標で振り返る仕組みを整えれば、質を落とさずに速度を上げることは十分に可能です。 約11時間まで短縮できましたが、改善の余地はまだあると考えています。AIレビューのプロンプトを磨いてレビュー精度を高めることや、AIレビューの品質向上を前提に2名Approveのルール自体を見直すことなど、取り組みたいテーマは尽きません。今後もチームの変化に合わせて仕組みをアップデートしていきます。 同様の課題を抱えるチームにとって、本記事が何かの参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

Geminiが社内ナレッジを直接参照可能に Googleは2026年1月27日、Google Workspace Updates公式ブログにて以下の発表を行いました。