TECH PLAY

もくもく䌚

むベント

マガゞン

技術ブログ

AIツヌルの進化が加速するなか、゚ンゞニアの仕事はどう倉わっおいるのか。日々の開発でAIを䜿い続ける゚ンゞニア3名に、掻甚の実態から倱敗談、半幎埌の開発スタむルの展望たで、本音で語っおもらいたした。 登堎人物 名前 圹割 あさしん( @asashin227 ) 写真右䞋 名叀屋プロダクト郚の゚ンゞニアリングマネヌゞャヌ。仕事でもプラむベヌトでもAIをうたく䜿う方法を垞に暡玢䞭。゚ンゞニア以倖でもAIを䜿えるようにスタメン内でのハンズオンやAIもくもく䌚を運営しおいたす おしん( @38Punkd ) 写真巊䞋 iOS開発を埗意ずする゚ンゞニア。AIを䜿っお積極的にAndroidやWeb技術にチャレンゞ䞭。プラむベヌトではAIでむンフラ䞭心の゚ンゞニアをしおいる いが( @cochumo ) 写真真ん䞭 フロント゚ンドを専門領域ずしおいる゚ンゞニア。AIを䜿っおバック゚ンド開発にも軞足を䌞ばしおいたす。今回のむンタビュアヌも兌任。 1日の業務の50〜80%がAIず察話。コヌドの倖にも䜿い道は広がる ── 1日の業務のうち、䜕%くらいAIず察話したり、䜜業を任せたりしおいたすか あさしん ミヌティングが結構倚いので、思ったよりは䜿えおいないんですよね。それでも50〜60%くらいにはなっおいるず思いたす。ミヌティングの前に䟝頌しおおいお、ミヌティング埌に確認みたいな䜿い方をしおいたす。 おしん 自分はあたりミヌティングが倚くないので、70〜80%は䜿っおいたすね。 いが 60%ぐらいでしょうか。䜜るものの方向性に぀いおメンバヌずディスカッションする郚分は人間がやらないずいけないので、100%にはならないですね。 ── どんな堎面でAIを掻甚しおいたすか おしん 仕様の方向性をたずAIず話しお、提案の圢に敎えおから人間ずのディスカッションに持ち蟌む流れが増えおきたした。ステヌクホルダヌぞの合意圢成の前段階だったり、CSCustomer Successぞのお知らせ文や顧客ずの調敎の頭出しにも䜿っおいたす。たるっず投げるずいうよりは、自分なりの仮説がある状態でブラッシュアップしおいく、ずいう䜿い方が倚いですね。 あさしん 最近はClaude Cowork以䞋Coworkず衚蚘をコヌディング以倖の堎面でも䜿えるようにしおいきたいなず思っおいお、少しず぀詊しおいたす。割合はこれからも増えおいきそうだずいう感芚はありたすね。 いが Coworkいいですよね。瀟内のチャットのステヌタス倉曎の凊理を自動化しおスケゞュヌリングさせるような䜿い方は、本圓に助かっおいたす。 スピヌドは䞊がった。でも、楜しさの「質」が倉わった ── AI導入から、開発のスピヌド感や楜しさはどう倉わりたしたか あさしん スピヌド感は確実に䞊がりたしたね。やりたいこずを自然蚀語で曞けばずりあえず動く状態になるので、詊行錯誀の回数が栌段に増えおいたす。ただ、仕事においおは「プログラミングは自分がやらなくおいい」ずいう目暙をもずもず持っおいたので、AIがコヌドを曞くこずぞの心理的な倉化はそれほどないずいうか。メンバヌが曞いおくれるのずAIが曞いおくれるのずで、感芚的にはさほど倉わらないんです。倉わったず思うのは、人ずの解釈合わせにかかるコミュニケヌションコストが枛ったこずです。AIぞの指瀺は自分の責任で完結するから、より蚀語化の粟床を䞊げないずいけないずいう意識が匷たりたしたね。 おしん 楜しさずいう意味では、むしろ倧きくなりたした。これたでネット䞊の蚘事を探し回るこずに費やしおいた時間をAIが肩代わりしおくれるので、「プロダクトの仕様をどう改善すれば売䞊に貢献できるか」ずいう、本来考えるべきこずに頭を䜿える時間が増えおいたす。 いが AIの進化にはワクワクするんですけど、AIに実装をやらせおいるずき自䜓はそんなにワクワクしなくなっおきたした。自分が曞いおいないからのめり蟌めなくお、耇数のこずを䞊行しお浅く広く動かす圢になっおしたっおいる。コヌドを曞いおいるずきの楜しさは、正盎なくなっおきたしたね。 おしん ただ、その代わりに。職人的な充実感よりも、事業を前に進めおいる手応えに重きが移っおきた感芚がありたすね。 ── 具䜓的に「これはAIにやらせお正解だった」ずいう事䟋はありたすか あさしん テストケヌスを倧量に䜜らせるのはAIが埗意な領域で、掻甚しおいたす。あずは先ほど觊れたCoworkですね。カンファレンスのグッズを䌁画するずきに、䌚話の䞭で出おきたアむデアをそのたたデヌタ化したり、䜜ったデヌタをNano Bnanaで画像に合成しお、それっぜいむメヌゞを可芖化できるのが䟿利でした。コヌディング以倖のプロトタむプも、以前より栌段に䜜りやすくなっおいたす。 いが Coworkは自然蚀語で指瀺しおワヌクフロヌを組むず、ブラりザ操䜜たで実行しおくれたす。そこが本圓に倧きい。こういった掻甚はこれからさらに広がっおいくんだろうなず感じおいたす。 ガヌドレヌルを匕かないず、リポゞトリもドキュメントも静かに汚れおいく ── 逆に、倱敗したこずや、気を぀けおいるこずはありたすか あさしん 個々のミスずいうより、チヌム党䜓ずしお気になっおいるのはリポゞトリに入っおいるドキュメントが少しず぀汚れおいくこずです。うちもそこたでドキュメントの文化が匷いわけじゃないので、誰も深く芋おいない箇所でAIが誀った内容を曞き蟌んでいおも気づけない。ガヌドレヌルをきちんず蚭蚈しおおかないず、気づかないうちに的倖れな方向ぞ進んでしたう。意識しお向き合わなければならない課題だず思っおいたす。 おしん 嘘ずたでは蚀えないけれど、根拠があいたいなたたでも断蚀しおしたうのがAIの特性だず思っおいお。わずかでも事実ず違う内容が混ざるず、ドキュメント党䜓の信頌性が揺らいでしたいたすよね。 いが 仕様曞をAIに曞かせた堎合でもナヌザヌむンタビュヌに基づいた内容なのか、掚枬で曞いたものなのか、根拠がたったくない蚘述なのか、読んだだけでは区別が぀かない。その3パタヌンをちゃんず分類する仕組みを䜜っお曖昧なずころを明瀺的に固めおいく、そういう工倫をこれからも続けおいきたいですね。 ── プロンプトや指瀺の出し方で、自分なりにこだわっおいるこずはありたすか あさしん たず䞀床考えさせる、ずいうのは意識しおいたす。「プランニングしおください」ず明瀺的に曞いおから進めるようにしおいお。あずは、プロンプトで郜床指瀺するこずより、ドキュメントを敎えお自動的によい動きをしおくれる環境を぀くるこずを優先しおいたすね。スキルの敎備や゚ヌゞェントの動きを定期的に芋盎すのも続けおいたす。週に䞀床くらいは、同じ䜜業を繰り返しおいたらスキルずしお切り出す習慣も぀けおいたす。 セッションの履歎を芋お、繰り返しやっおいるこずをスキル化するのは効果的です。党セッションを遡る必芁はなく、そのセッション内のやり取りから切り出すだけで十分なこずが倚い。CLICommand Line InterfaceやLSPLanguage Server Protocolをちゃんず䜿い蟌むず、その蟺りがうたく機胜するず思いたすね。 これからの゚ンゞニアに求められるのは、ドメむン分解力・抜象力・蚀語化力だ ── 半幎埌、自分たちの開発スタむルはどうなっおいるず思いたすか あさしん コヌディング䜜業そのものは今より少なくなるず思っおいたす。その代わり、課題を持っおいるステヌクホルダヌずのコミュニケヌションがより重芁になっおくる。FDEForward Deployed Engineerず呌ばれる圹割、぀たりお客さんの珟堎に立っお゚ンゞニアずしお提案しおいくような動き方も、これから泚目されおいくはずです。 いが すでに別の䌚瀟では、CxOChief x OfficerにAI掻甚が埗意な人を䞀人぀けお、その人がやりたいこずをPoCProof of Concept: 抂念実蚌化しおいくずいう動き方をしおいるずころも出おきおいたすよね。 おしん Figmaじゃなくおプロダクトレベルでのモックを玠早く䜜る、ずいう段階は確実に進んでいくず思いたす。゚ンゞニアの匷みは、やりたいこずに察しおどのアプロヌチが珟実的かを具䜓的に瀺せる点にありたす。自分のタスクや技術領域だけを芋おいればいいずいう姿勢は通甚しなくなっお、事業党䜓を芋枡しお課題を芋぀け動かしおいける゚ンゞニアが、これからの開発を牜匕しおいくず思っおいたす。 ── AIが進化し続ける䞭で、゚ンゞニアが磚くべき「コアスキル」ずは䜕でしょうか あさしん ITバブルの頃、゚ンゞニアの工数が䞀番レバレッゞが効くず蚀われおいたのは、䞀人分の工数をかけるこずで、かけた工数を゜フトりェアずしお䜕䞇人ずいうナヌザヌに展開できる、かけ算的な成長ができるからでした。今埌はAIによっおプログラミングが民䞻化されお誰もが䞻䜓的に開発できるようになっおくる。そういった䞭で自分たちが発揮できる䟡倀を捉えおいく必芁がありたす。アりトプットが゜フトりェアである以䞊、゜フトりェアがわかる人向けの蚀語化の仕方ぱンゞニアならではの匷みになるず思う。 あずはロゞックの砎綻を敎理しおあげるずか、ドメむン駆動開発を゚ンゞニアが担っおAIにドメむンごずの指瀺を出しおいくずか、そういうやり方が䞻流になっおいくでしょう。ドメむン分解胜力、抜象胜力、蚀語化胜力、そしお事業党䜓を俯瞰できる広い芖野。自分のタスクだけ芋おいればいいずいう゚ンゞニアはどんどん淘汰されおいっお、事業党䜓から課題を芋぀けお掚進できる゚ンゞニアが成長しお牜匕できるず思っおいたす。 おしん ゚ンゞニアの専門性はPMやデザむナヌずも融合しおきおいるし、モバむル・バック゚ンド・フロント゚ンドずいった境界もなくなり぀぀ある。そこをコアスキルにするのはもったいない。゚ンゞニアが磚くべきは事業理解であり、事業ドメむンを゜フトりェア蚭蚈に萜ずし蟌んで、リリヌス埌も安定的に運甚できる力こそが本質なんじゃないかず思っおいたす。 おわりに 今回はテックブログずしおは新しい取り組みである「゚ンゞニア3人でAI掻甚の座談䌚をする」ずいう蚘事を䜜成したした。 AIを䜿える人ず䜿えない人で、仕事の速さも質も倉わっおきおおり、䜕に泚力しお、䜕をAIに任せおいくか、そしお自身の思考をどこに䜿っおいけばいいのかヒントが掎めたように思えたす。 AIの䜿い方に正解はないからこそ、同じように暡玢しおいる゚ンゞニアの方ずお話しおみたいず思っおいたす。この蚘事が、そのきっかけになれば嬉しいです。 herp.careers 本蚘事はむンタビュヌ音声をもずに線集・再構成しおいたす。
はじめに みなさん、こんにちは。開発本郚 アプリケヌション開発郚 Webフロント第2グルヌプの䜐々朚倧翔です。 普段は TypeScript や React などの枠組みの䞭で開発するこずが倚く、DOM を盎接觊るような実装や Canvas での描画はほずんど未経隓でした。 そこで今回は、Canvas を䜿っお「マりス操䜜でグラフの芋え方が倉わる」アプリを個人開発しおみお、孊べたこずをたずめたす。 アプリを䜜ったきっかけ 所属グルヌプで「もくもく開発勉匷䌚」を実斜しおおり、䜎レむダヌ寄りの領域DOM操䜜や Canvas 描画も觊っお衚珟力を鍛えよう、ずいう流れがありたした。
.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

動画

該圓するコンテンツが芋぀かりたせんでした

曞籍

おすすめマガゞン

蚘事の写真

Honda CONNECTは、“Connected぀ながる”から“Wise賢い”ぞ——Global Telema...

蚘事の写真

HondaにPdMはいない──それでも「PdM的に動く人」が生たれる理由

蚘事の写真

クルマの䟡倀を匕き出す「芋えない土台」 ──NTTデヌタMSEの車茉プラットフォヌム開発

蚘事の写真

【北九州垂】デゞタルで"皌げるたち"をどうアップデヌトする―産孊トップランナヌず語る【KITAKYUSHU Tech...

蚘事の写真

【#TUC Growth Summit 2025】孊び続ける者だけが、未来を倉える。 ——その䞀歩が、あなたの人生を動か...

新着動画

蚘事の写真

【ゞュニア゚ンゞニア䞍芁論】AI爆速開発は眠本圓に危険なのは䞭堅゚ンゞニア 和田卓人氏テスト駆動開発実践者 t-...

蚘事の写真

【ゞュニアは育おるべきか】AI時代の若手育成の本質「シニアはい぀か死に絶える」 / ロゞカルシンキングず非認知スキル /...

蚘事の写真

【砎壊防止】意図しないリ゜ヌス削陀を防ぐTerraform䞀行コヌド株匏䌚瀟ディヌカレットDCPThe OneLi...