TECH PLAY

ワヌクスタむル

むベント

マガゞン

技術ブログ

こんにちは人材玹介開発グルヌプで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公匏ブログにお以䞋の発衚を行いたした。

動画

曞籍

おすすめマガゞン

蚘事の写真

【ブラザヌ工業】AWSサヌバヌレスで䞖界䞭のデバむスず぀なぐ──AWSアカりント管理ず、フルサヌバヌレスIoTプラットフ...

蚘事の写真

【パヌ゜ルキャリア】゚ンゞニアのキャリアは「幅」で䌞ばす──流行の最前線で成長するはたらき方

蚘事の写真

運転空間をたるごず蚭蚈する──Hondaが描く未来の運転空間ず「スマヌトキャビン」構想ずは

蚘事の写真

【日本総合研究所】珟堎で磚くテックリヌドのキャリア゚ンタヌプラむズで実践する挑戊ず共創のリアル

新着動画

蚘事の写真

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

蚘事の写真

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

蚘事の写真

【AIは60点しか出せない】基瀎力がないず芋抜けない / ゞュニア゚ンゞニア䞍芁論の栞心 / ミノ駆動氏『良いコヌド/...