TECH PLAY

゚ス・゚ム・゚ス

゚ス・゚ム・゚ス の技術ブログ

å…š264ä»¶

はじめたしお、プロダクト掚進本郚カむポケ開発郚で゚ンゞニアをしおいる朚野ず申したす。 2025幎1月に入瀟し、あっずいう間に1幎が過ぎたした。 入瀟しお感じたこず、育児をしながら働いおみおどうだったかを䞭心に振り返っおいこうず思いたす。 珟圚゚ス・゚ム・゚スに興味をお持ちの方の参考になれば嬉しいです ドメむン知識の習埗ず珟堎を知る倧切さ 耇雑な制床をシステムに萜ずし蟌む 私は介護事業者向け経営支揎プラットフォヌム「カむポケ」の障害犏祉分野の開発に携わっおいたす。 介護や障害犏祉の事業所は、囜が定めた制床に則っお運営されおいたす。 そのため私たちが開発する際も「行政から出される資料を読み解き、正しくシステムに反映するこず」が䜕より重芁になりたす。 制床、特に報酬算定お金の蚈算のルヌルは非垞に耇雑で、考慮すべきパタヌンや䟋倖凊理の難易床がずおも高いです。 私は以前歯科向けの電子カルテ開発をしおいた経隓があり、厚生劎働省の資料を読むこずには倚少慣れおいたした。ですが実際に障害犏祉の分野に入っおみるず、歯科ずは考え方が異なる郚分も倚く、1幎経った今も日々詊行錯誀しおいたす。 䟋えば歯科は「䜕をやったか蚺療単䜍」が基本ですが、介護や犏祉は「誰が、どんなこずを、䜕時間提䟛したか」ずいった芁玠の組み合わせで蚈算が倉わりたす。 この「算定パタヌン」をどうシステムに萜ずし蟌むかを考えるのは、悩む堎面が倚いです。 ただこの難しさは同時に面癜い郚分でもありたす。 制床の倉曎は珟堎のニヌズや瀟䌚情勢が反映されたものです。資料を読み蟌み、萜ずし蟌んでいく䜜業を通じお、瀟䌚課題に向き合い、取り組んでいる実感が持おるのはこのドメむンならではのやりがいだず感じおいたす。 珟堎を知る 入瀟しお早い段階で、実際の攟課埌等デむサヌビス事業所を蚪問する機䌚をいただきたした。 珟堎のスタッフの方々からお話を䌺い、実際の忙しさや、業務䞊ただただアナログが倚い珟状を盎接目にするこずができたした。 本来の業務である「利甚者ぞの支揎」に集䞭するため、事務䜜業を効率化する必芁がある。 それを肌で感じたこずで、自分が䜜っおいるシステムが解決すべき課題が明確になり、開発に向き合うモチベヌションが高たりたした。 実際の珟堎を芋た埌は、画面の入力方法を怜蚎する際も「珟堎の入力負荷が増えないか」「実際の業務フロヌずしお䞍自然ではないか」ず、 解像床を䞊げお考えられるようになりたした。 珟堎を知るこずは、業務の解像床を高めるだけではなく、゚ンゞニアずしおの芖点を広げるためにずおも倧切だず実感しおいたす。 こうした事業所芋孊や䜓隓を通じお珟堎を知る機䌚は瀟内に定期的にあり、 珟堎の「肌感芚」を倧切にできる環境は非垞にありがたいなず思っおいたす。 「なぜやるのか」ずいう文化 入瀟しお䞀番驚いたのは皆さんのスキルの高さ、開発郚党䜓に根付いおいる「なぜこれをやるのか」を考える意識の高さでした。 単に「どう実装するか」ずいう技術的な話だけでなく、「なぜこれをやるのか」「なぜこの修正が必芁なのか」「それによっお誰がどう幞せになるのか」ずいう問いかけをずおも倧切にしおいたす。 もし自分の考えががんやりしおいれば、玍埗いくたで前提から䞁寧にすり合わせをしおくれたす。 このおかげで、ブレるこずなく進められた堎面が倚くありたした。 最初はレビュヌで「なぜこの実装にしたのか」ず問われおも、蚀語化できずに固たっおしたうこずもありたした。 チヌムのメンバヌは、単に正しい曞き方を教えるのではなく、「どういう理由でこの圢にしたのか」ずいう意図を根気匷く匕き出そうずしおくれたした。 そのおかげで目先のコヌドの曞き方だけではない、開発の根底にある「考え方」の倧切さに気づくこずができたした。 この文化はコヌドレビュヌや蚭蚈の堎だけでなく、チヌムの運営や方針を決める際にも培底されおいるず感じたす。 玍埗できないこずがあればオヌプンに質問でき、それに察しお「なぜこれを行うのか」を玍埗いくたで議論しおいたす。 「なぜやるのか」を党員が培底しおいるこずで、「誰のどんな助けになるのか」が明確になり、より誠実にプロダクトに向き合えおいるのだず感じおいたす。 日々どうすればもっず良くなるかを考え抜いおいる皆さんをみお、1幎経った今、私も自然ず「なぜやるのか」を自問自答できるようになっおきたず感じたす。 今埌は私もそんな颚に、誰かの芖界をクリアにできる存圚を目指しおいきたいです。 モダンなツヌルずチヌムの支え 実際の開発業務では、本栌的なJavaの開発は初めおで戞惑いもありたした。 それでも、AIツヌルの掻甚やチヌムメンバヌによる䞁寧なレビュヌに助けられ、無事にいく぀かの案件をリリヌスできおいたす。 最近は、AIを日々の実務にうたく取り入れる流れが掻発です。 個人ずしおは、テストコヌドの䜜成やセルフレビュヌ、ドキュメント䜜成など日垞的な䜜業の各所で掻甚しおいたす。 チヌムずしおも共通で䜿える各皮蚭定を䜜成したりず、効率化がどんどん進んでいたす。 先日もチヌム間でAI掻甚の情報亀換䌚が行われたした。 「具䜓的なプロンプトをどう工倫しおいるか」ずいった珟堎ならではの共有が倚く、非垞に参考になりたした。最新情報の共有もSlackなどで日垞的に行われおおり、ツヌルを䜿いこなしながら、より本質的な蚭蚈や議論に時間を割こうずする自然な雰囲気があるず感じおいたす。   子育おずフルリモヌトワヌク 「家族優先」が圓たり前の空気感 私は珟圚、未就孊児2人の育児䞭です。 入瀟盎埌は「急な欠勀や早退で迷惑をかけるのではないか」ず心理的なハヌドルを高く感じおいたした。 その䞍安をオファヌ面談でお䌝えしたずころ、入瀟前に子育お䞭の゚ンゞニアの方々ずお話しする「座談䌚」を蚭けおいただけたした。 育児しおいる時間が枛るが、技術的なキャッチアップはどうしおいるか 急な䌑みはどう調敎しおいるのか お迎えで1床抜けたり柔軟な勀務は可胜か ずいったリアルな話をフランクな雰囲気で聞けたこずが、入瀟を決める倧きな安心材料になりたした。 実際に働いおみるず、開発郚党䜓に「家族や自分の䜓調を最優先にする」空気が文化ずしお根付いおいるのを実感したす。 䟋えば、子䟛が急に発熱しお䞭抜けや欠勀が必芁になった際も、チヌムの皆さんが「お倧事に」「家族優先」ず、圓たり前のようにフォロヌし合える環境がありたす。 入瀟盎埌、メンバヌ数名䜓調䞍良で䞍圚だった時期がありたした。 その際も「お互い様だから無理せず䌑もう」ずいう空気感が培底されおおり、新入瀟員ずしおの心理的なハヌドルがすっず䞋がったのを芚えおいたす。 フルリモヌトで働くこず フルリモヌトず聞くず、コミュニケヌションや情報のキャッチアップに䞍安を感じる方も倚いかもしれたせん。 実際、瀟内には膚倧なドキュメントやアりトプットがあるため、最初は情報の倚さに圧倒されるこずもありたした。 ただ、次第にすべおを完璧に远うのはやめお、esaの怜玢を工倫したりAIツヌルで芁玄したりず、自分なりのハンドリング術を暡玢するようになっおいたす。 この情報の取捚遞択スキルは、この1幎で埗た意倖な収穫のひず぀です。 Slackでのコミュニケヌションも驚くほど掻発です。 子育お䞭のメンバヌが集たるチャンネルや趣味のチャンネルなど、業務倖の぀ながりも倚いため、リモヌト特有の孀独感を感じるこずはほずんどありたせん。 加えお、日々の業務における連携のオヌプンさも、倧きな安心感に぀ながっおいたす。 䟋えば、メンションを぀けおいない独り蚀のような投皿に察しおも、誰かがさっず解決策を提瀺しおくれたり、類䌌案件を教えおくれたりするこずがありたす。 困ったずきはすぐに「ハドル音声通話しようか」ず声がかかるので、自宅で䞀人悩んで孀立するこずもありたせん。 皋よい距離感の亀流䌚もあり、オンラむン越しでもチヌムの぀ながりをしっかりず感じられおいたす。 終わりに 1幎を振り返っおみたした。 改めお゚ス・゚ム・゚スに入瀟しお良かったず感じおいたす。 業務解像床が䞊がっおきた今、新しいこずにチャレンゞをしながらさらに頑匵っおいきたいず思いたす。
こんにちは、゚ス・゚ム・゚スでプロダクト掚進本郚人事をしおいる韓 @ssket0809 です。 2026幎3月20日〜22日に開催された PHPerKaigi 2026 に、゚ス・゚ム・゚スがスポンサヌずしお参加したした。ブヌス出展もおこない、倚くの゚ンゞニアの方々ず亀流させおいただきたした。 phperkaigi.jp むベントスタッフの皆さん、参加された皆さん、そしお匊瀟ブヌスでアンケヌトに答えおくださった皆さん、本圓にありがずうございたした。 この蚘事では、スポンサヌ参加の背景、ブヌスで取り組んだこず、圓日の様子に぀いおレポヌトしたす。 PHPerKaigi 2026ずは PHPerKaigiは、PHPを愛する゚ンゞニアたちが集たる幎次カンファレンスです。2026幎は䞭野セントラルパヌクカンファレンスにお開催され、44本のセッション、22本のLTラむトニングトヌクがあり、非垞に密床の高い3日間でした。 ゚ス・゚ム・゚スずしおPHPerKaigiぞの参加は2幎ぶりです。今回のスポンサヌ参加では、PHPerKaigiを䞀緒に盛り䞊げたいのず同時に、匊瀟の キャリア事業 領域におけるプロダクト・技術の認知を゚ンゞニアコミュニティに広げおいきたい、ずいう背景もありたした。それもあり、そのプロダクト開発を担う 人材玹介開発グルヌプ のメンバヌが䞭心ずなっおブヌスに立ち、PHPを䜿ったプロダクトの技術的な取り組みや、チヌムの開発スタむルに぀いお来堎者ず盎接察話したした。 ブヌスのコンセプト ブヌスには、Day0からDay2たで゚ンゞニア9名が参加したした。 Day1の集合写真 Day2の集合写真 匊瀟のキャリア事業のプロダクトは、PHPをはじめずする技術スタックで開発されおいたす。ただ正盎なずころ、どういうチヌムでどういう開発をしおいるのか、倖郚ぞの情報発信がただあたりできおいたせんでした。そのため「゚ス・゚ム・゚スにこういうプロダクトがある」「こんな技術課題に取り組んでいる」ずいう認知が、゚ンゞニアコミュニティにはほずんど届いおいないのが珟状でした。 今回のブヌスはキャリア事業の認知を倉えおいくための1぀目の斜策でもありたす。そこで、採甚パンフレットを䞊べるのではなく、 アンケヌトパネルを甚意しお来堎者ず察話する ずいう圢をずりたした。具䜓的には、アンケヌトパネルを甚いお来堎者に゚ンゞニアずしお倧切にしおいるポむントを答えおもらいながら、自然な流れで゚ス・゚ム・゚スのプロダクトや技術に぀いおお䌝えしおいきたした。 アンケヌト結果 圓日盛り䞊がったアンケヌトの結果を振り返っおみたす。 アンケヌトの回答で最も倚かったのが、「 ビゞネスず距離が近い 」ずいう遞択肢でした。ただ、䌚話をしおいるず「ビゞネスず距離が近い」が意味するものは人によっお少し違うのが面癜くお、PdMをビゞネスサむドず捉えおそこずの距離感を指しおいる人もいれば、営業やマヌケ職などずの近さを指しおいる人もいたした。 生成AIが開発の珟堎で圓たり前のように䜿われるようになった今、コヌディングスキルだけではなくビゞネスの文脈を理解しお䟡倀を生み出せる゚ンゞニアが求められおいる、そういった倉化を含め、来堎者の生の声はいろいろず考えさせおくれるものでした。 たた、䌚話の䞭で気づいたのが、「゚ス・゚ム・゚ス」ずいう瀟名は知っおいおも、事業内容はほずんど知らないずいう方が倚かったこずです。医療・介護・ヘルスケア領域の人材玹介を手がけおいるずお䌝えするず、「瀟䌚貢献性が高い事業ですね」「日本瀟䌚にずっおずおも重芁ですね」ずいう反応をいただくこずが倚く、改めお自分たちが取り組んでいる事業の意矩を感じる堎面でもありたした。 こういった本音の声を盎接聞ける堎は、普段のオンラむン面談では埗られない貎重な機䌚だず感じおいたす。 セッションの感想 どのセッションやLTも熱量が高く、匊瀟メンバヌが参加したセッションの感想をいく぀か玹介したす。 接続—パフォヌマンスチュヌニングの最埌の䞀手 〜点ず点を結ぶ、その䞀瞬のために〜 チュヌニングを「接続」ずいう芳点で䜓系的に捉え盎すセッションでした。アプリケヌション党䜓の構成を俯瞰し、どこでリク゚ストが発生しおどこで凊理されおいるかを把握するこずで、コヌドを曞いおいる最䞭には意識しにくい「接続点」が芋えおくる、そんな芖点を改めお孊ぶこずができたした。 肥倧化したRepositoryクラスで責務分割で解決しようずした話 EC領域の泚文情報を扱うRepositoryクラスがドメむンの耇雑さゆえに肥倧化した問題を、「泚文ステヌタスを曎新する」ずいった動詞や、曎新の起因ナヌザヌによるものかシステムによるものかに着目するこずでチヌム内の共通認識を圢成し、サヌビスクラスずしお切り出すこずに成功した話が印象的でした。 ビゞネスがわかる゚ンゞニアになろう経営孊ず゚ンゞニアリング、その共通点ず掻甚法 日々の゚ンゞニアリング業務にMBA的芖点をもっお臚むずいう話で、MBAの課題解決フレヌムワヌクが日々の゚ンゞニアリング業務に䜿えるずいう芖点で面癜かったです。 参加を通じお感じたこず 人材玹介開発グルヌプずしおカンファレンスにブヌス出展するのは今回が初めおでした。参加したメンバヌからは「ブヌスを出しおよかった」「来堎者ず盎接話せお楜しかった」「自分たちの認知を広げるこずの倧切さを実感できた」ずいったポゞティブな感想が倚く集たりたした。同じグルヌプ内でも普段は異なるチヌムで働いおいるメンバヌ同士が䞀緒にブヌスに立぀機䌚はなかなかないので、そういった意味でもお互いを知れる良い機䌚になったず思っおいたす。 ゚ンゞニアずしおではなく採甚・組織づくりの立堎で参加しおいた私にずっおも、「このプロダクトに関わりたい」「このチヌムで働きたい」ず感じおもらえる組織であり続けるこずの倧切さを、改めお実感する3日間でした。 たずめ 今回PHPerKaigiにスポンサヌずしお参加し、来堎者の皆さんず盎接察話できたこずは、私たちにずっお倧きな収穫でした。゚ス・゚ム・゚スでは匕き続き、技術コミュニティぞの貢献ず、゚ンゞニアずの接点づくりを倧切にしおいきたいず思っおいたす。 最埌に、玠晎らしいむベントを䜜り䞊げおくださったむベントスタッフの皆さん、セッションやLTで堎を盛り䞊げおくださった登壇者の皆さん、そしお匊瀟ブヌスに足を運んでくださった皆さんに、心よりお瀌申し䞊げたす。ありがずうございたした
はじめに はじめたしお。介護/障害犏祉事業者向け経営支揎「カむポケ」の事業郚でCS職カスタマヌサクセス/サポヌトをしおいるTSUNOです。カむポケに携わっお10幎以䞊になりたす。 ゚ンゞニアではありたせん。プログラミングの経隓もありたせんでした。 そんな私がAIを掻甚しお業務自動化ツヌルを開発した結果、 月17.7時間の工数削枛 ず 賌買刀断の適正化 を実珟したした。 この蚘事は、非゚ンゞニアのCS職がAIで業務自動化を進めた実践蚘です。AIでここたでできるんだ、ずいう実感を持っおもらえたら嬉しいです。 なぜやろうず思ったのか カむポケのCSでは、お客様からの問い合わせ察応だけでなく、カむポケを利甚するうえでの事務手続きたで、お客様の業務を幅広く支えおいたす。 2024幎11月、業務䜓制の倉曎にずもない、新たに業務を匕き継ぐこずになりたした。 この業務は完了たでに倚くのステップがありたす䞋図。匕き継いだのはそのフェヌズ2の郚分でした。 耇雑な䜜業を、ひたすら繰り返す。通垞業務にこれらが䞊乗せされる状況では、ずおもではないですが手が回りたせん。ちょうどその頃、無料版のChatGPTで簡単なGoogle Apps ScriptGASを曞く䜓隓をしおいたした。もっず本栌的にプログラムで業務を改善できるのではないか——そう考え始めたのが、すべおの出発点です。 AI掻甚のステップアップ 最初から有料ツヌルを䜿っおいたわけではありたせん。 無料ツヌルで小さく始めお、成果が出たら次のステップぞ。その繰り返しで、気が぀けば本栌的な開発環境が敎っおいたした。 倧事なのは、 最初から倧きな投資をする必芁はない ずいうこずです。 時期 やったこず きっかけ 2024幎1月〜 無償版ChatGPTでAI掻甚を開始 AI掻甚ぞの興味 2024幎11月〜 GASで業務自動化に着手 業務効率化の必芁性が高たった 2025幎1月頃 Google Workspace暙準搭茉のGeminiを掻甚 䌚瀟の環境倉化 2025幎11月 Claude Codeで本栌的な開発ぞ AIツヌルの比范・怜蚌を経お 2025幎12月 Claude MAXプランぞグレヌドアップ ROIを䞊叞に提瀺しお承認 ※ 各時期は筆者が知った・䜿い始めたタむミングであり、サヌビスのリリヌス時期ずは異なりたす。 AI掻甚の情報収集は倚方面から行いたした。 X YouTube Google CloudナヌザヌコミュニティのJagu'e'r ※ Jagu'e'r ゞャガヌ ずは、Google Cloudナヌザヌ䌁業が䌁業の垣根を超えお最新技術やノりハりを共有し合い、クラりド掻甚の倉革を掚進する公匏コミュニティです。 特にJagu'e'rの無料ハンズオンセミナヌでVertex AIに觊れたこずが、「APIを通じおAIを䜿う」ずいうむメヌゞを掎むきっかけになりたした。この䜓隓が埌述するデヌタ移行支揎ツヌルの技術遞定に぀ながりたした。こうした倖郚の孊びの堎に加え、最近では瀟内゚ンゞニア䞻催のClaude Code掻甚ナレッゞ共有䌚にも参加したした。 よくわからなくおも飛び蟌んでみるず、新しい発芋があるものです。 生成AIを䜿った3぀の取り組み ここからは、AIを掻甚しお取り組んだ3぀の事䟋を玹介したす。 # 事䟋 抂芁 1 GAS + 業務フロヌの芋盎し 6時間→2時間に圧瞮 2 介護保険請求の事務手続きRPA※ 月17.7時間の工数削枛 賌買刀断の適正化 3 AI駆動で開発䞭のデヌタ移行支揎ツヌル 垳祚の自動解析ずデヌタ敎圢 ※ RPARobotic Process Automation人がブラりザやアプリ䞊で行う操䜜をプログラムで自動化する技術 1最初の成功䜓隓 — GASで6時間の業務を2時間に AI掻甚で最初に取り組んだのは、GASによる業務自動化です。 コヌドは䞻にChatGPTで生成・修正したした。自分でれロから曞いたわけではなく、「こういう凊理がしたい」ずAIに䌝えお、出おきたコヌドを実行し、うたくいかなければ゚ラヌメッセヌゞをAIに貌っお修正する——このサむクルを回すこずで、コヌドは着実に動くものになっおいきたした。 結果、1日あたり玄6時間かかっおいた業務が玄2時間に圧瞮されたした。ただし、これはGASによる自動化だけの効果ではなく、業務フロヌ党䜓の芋盎し䞍芁な手順の廃止や䜜業順序の組み替えずの合算です。GAS単䜓の削枛効果ずしお切り出せる数字ではありたせんが、ツヌルを䜜るこず自䜓が業務を棚卞しするきっかけになったずいう意味で、倧きな䞀歩でした。 2介護保険請求の事務手続きRPA — 業務自動化の本栌展開 前述の業務芋盎しの過皋で「GASでは解決できない業務」も浮き圫りになりたした。業務の䞭には、介護保険の請求手続きに䜿う倖郚システム䞊で、ログむン・画面操䜜・垳祚出力ずいったブラりザ操䜜を行う工皋が含たれおいたした。 このシステムには倖郚からプログラムで連携するための仕組みAPIが提䟛されおおらず、ブラりザを人の手で操䜜するしかありたせん。こうしたブラりザ操䜜はGASの守備範囲倖であり、自動化するにはブラりザそのものを操䜜するRPAが必芁でした。 なお、倖郚システムをRPAで操䜜するにあたっおは、利甚芏玄の確認や瀟内のリスクマネゞメント郚門ぞの事前盞談を行ったうえで開発を進めおいたす詳现は埌述の「倖郚システムを操䜜する䞊での配慮」で觊れたす。 介護事業所がカむポケを通じお介護保険を請求するには、このシステム䞊で各皮手続きを行う必芁がありたす。これらの䜜業は、党郜道府県にわたる倚数のアカりントに察しお日々行われたす。 以前にもこの業務を自動化するRPAツヌルが䜜られたこずがありたした。しかし、運甚環境の倉化に察応しきれなくなり、最終的に圹割を終えおいたした。業務は再び手䜜業に戻っおいたのです。 GASで積み重ねた成功䜓隓が、「自分で䜜ろう。゚ラヌが出おも、AIに聞きながら察凊できる」ずいう確信を支えおいたした。 成果①月17.7時間の工数削枛 RPAによる自動化で、月に17.7時間皌働日20日/月換算で、1日あたり53分の業務時間が削枛されたした。2026幎1月時点の実瞟です。これらの業務はお客様の増加ずずもに件数が増える傟向にあり、今埌さらに削枛効果が拡倧する芋蟌みです。 数字には衚れない倉化もありたす。以前はルヌチン察応で手䞀杯でしたが、時間が生たれたこずで、お客様ぞの進捗報告をより適切な頻床で届けられるよう蚭蚈し盎す䜙裕ができたした。自動化の本圓の䟡倀は、 削枛した時間そのものではなく、その時間で䜕ができるようになるか にあるず感じおいたす。 成果②賌買刀断の適正化 工数削枛以䞊にむンパクトが倧きかったのが、賌買刀断の適正化です。 埓来の運甚では、倖郚システムにログむンしお凊理件数を䞀぀ひず぀確認する必芁があり、党䜓の正確な把握が困難でした。そのため、実態より倚めにアカりントを賌入せざるを埗ない状況が続いおいたした。 RPAがこのログむンず件数取埗を自動で行うようになったこずで、実際の利甚状況が正確に芋えるようになり、䞍芁なアカりント賌入を回避しおコスト適正化を実珟したした。 こうした削枛効果の芋蟌みをROIずしお䞊叞に提瀺し、AIツヌルの䞊䜍プランの利甚承認を埗たした。承認埌の実瞟デヌタでもその効果が裏付けられおいたす。「ツヌルの利甚料に察しお、これだけの時間が浮く」ずいう説明は、瀟内で予算を取るうえで有効でした。 デヌタが芋えるようになるず、正確な刀断ができる ず実感した出来事でした。 3AI駆動で開発䞭のデヌタ移行支揎ツヌル デヌタ移行支揎ツヌルは、RPAず䞊行しお開発を進めおきたもう䞀぀のプロゞェクトです。珟圚は怜蚌フェヌズであり、RPAのような確定した成果はただありたせん。ここでは「完成しおいなくおも、非゚ンゞニアがAIず䞀緒にここたで到達できる」ずいう過皋をお䌝えしたす。 䜕を解決するツヌルか カむポケを導入いただく際、お客様がこれたで蓄積しおきたデヌタを、カむポケに登録したいずいうニヌズがありたす。その際、垳祚PDFを目芖で読み取り、手䜜業で転蚘する。これは時間がかかるだけでなく、ミスが起きやすい䜜業です。 デヌタ移行支揎ツヌルは、この垳祚をAIGeminiをチャット画面ではなくAPI経由で利甚で自動解析し、カむポケに取り蟌める圢匏に倉換する仕組みです。 Geminiアプリから始たり、Claude Codeで成長した 最初はGeminiアプリのチャット画面䞊で、1぀のプログラムファむル.pyにコヌドを曞いおいく圢でスタヌトしたした。「この垳祚のこの項目を読み取っお」「゚ラヌが出たから盎しお」ずやり取りしながら、少しず぀コヌドを育おおいきたした。 しかし、コヌドが1,600行を超えたあたりで限界が来たした。チャットが䞀床に扱える文脈の範囲コンテキストにコヌド党䜓が収たりきらなくなり、修正のたびに前埌関係が途切れるようになったのです。 そこで切り替えたのが「Claude Code」ずいう、テキスト入力で操䜜する開発ツヌルでした。プロゞェクト党䜓のファむルを把握しながら、゚ヌゞェントのように自埋的にコヌドを線集・実行しおくれたす。 Claude Codeに切り替えおからは開発速床が倧幅に䞊がり、1,600行の単䞀ファむルだったコヌドは、圹割ごずにファむルを分けた9,300行超の構成にたで成長しおいたす。 時点 芏暡 開発環境 初期 箄1,600行・単䞀の.pyファむル Geminiアプリのチャット画面 珟圚 箄9,300行 + テスト玄1,800行・耇数ファむル構成 Claude Code AIに任せる郚分ず、任せない郚分 開発を進める䞭で、正確性の高いデヌタ゜ヌスを優先する蚭蚈にたどり着きたした。介護保険の請求デヌタは、仕様曞でCSV圢匏ずしお定矩されおいたす。これらはCSVから確実に取埗し、CSVでは埗られない情報だけを垳祚PDFからAIに読み取らせる「ハむブリッド方匏」を採甚しおいたす。 CSV圢匏で確実に取埗できるデヌタを、あえお粟床にばら぀きのあるAI読み取りに回す理由はありたせん。AIは垳祚の読み取りで誀認識を起こすこずがあるため、確実な手段があるならそちらを優先する。どのデヌタをどの方法で取埗するかの線匕きにも、ドメむン知識が掻きおいたす。 ※ 個人情報を含むデヌタのAI凊理にあたっおは、゚ンタヌプラむズ向けのセキュアなサヌビスを利甚しおいたす。 珟圚地 開発環境での怜蚌を経お、クラりド䞊で動くWebアプリずしお構築し、ブラりザからアクセスできる状態にたで持っおきたした。前述のハむブリッド方匏は、実デヌタを甚いた怜蚌でも䞀定の粟床で動䜜するこずを確認しおいたす。珟圚は様々なパタヌンのプロンプトAIぞの読み取り指瀺を調敎しながら、察応できる垳祚の皮類を増やしおいるずころです。自分以倖のメンバヌが䜿える状態にするこずは今埌の課題です。 完成にはただ時間がかかりたすが、非゚ンゞニアによる業務改善の新しい可胜性を瀺せたず考えおいたす。ここからは、3぀の事䟋を通じお埗た実践的な孊びを共有したす。 非゚ンゞニアがAI駆動開発を進めるためのプラクティス 非゚ンゞニアがAIを掻甚しお成果を出すためには、具䜓的な手法の前に、たずベヌスずなる「心構え」からお䌝えしたす。 たず抌さえおおきたい4぀の心構え 1. プログラミング経隓より、深い業務フロヌ理解 業務を深く理解し、垞に改善点を暡玢するこず。 2. 人間は「芁件定矩ず刀断」、AIは「実装担圓」 「䜕を䜜るか」「どんな゚ラヌが危険か」「どのデヌタをAIに任せおはいけないか」。こうした刀断は人間の圹割です。具䜓的な指瀺を出し、AIをコントロヌルするこず。 3. AIの出力は「たたき台」ずしお受け取る AIは自信満々に間違えるこずがありたす。コヌドの䞭身をすべお理解するのは難しくおも、「この修正で䜕が倉わった」「意図した蚭蚈になっおいる」ずAIに確認するこずはできたす。耇数のAIにクロスチェックさせるのも有効です。鵜呑みにせず、自分の蚀葉で問いかける習慣を持぀こず。 4. 小さく始めお、成果を積み重ねる 小さな自動化の成功䜓隓が、次の挑戊ぞの自信ず原動力になりたした。たずは手を動かしおみるこず。 実践組織で進めるための6぀のプラクティス 心構えを土台ずしお、私が実際にやっおきた䞭で「これは他の人にも再珟できる」ず感じた具䜓的なアクションを6぀にたずめたした。 カテゎリ # プラクティス ひずこずポむント 実践 1 AIぞの指瀺は「業務の蚀葉」でいい 専門甚語より「䜕を・なぜ・どうしたいか」 2 ゚ラヌは壁ではなく、手がかり ゚ラヌメッセヌゞをAIに貌るだけで前に進める 3 テストもAIに曞いおもらう ただし「業務的に正しいか」は人間が考える 4 環境構築は「AIに聞く → 裏取り → セキュリティ確認」 シャドヌITを避ける手順を省かない 組織 5 成果を数字で芋せお、リ゜ヌスを埗る ROIで䞊叞の承認を埗る 6 倖郚システムを操䜜する䞊での配慮 利甚芏玄・瀟内承認・負荷配慮 1. AIぞの指瀺は「業務の蚀葉」でいい プロンプト゚ンゞニアリングだず身構える必芁はありたせん。倧事なのは、 業務の文脈を䞁寧に䌝えるこず です。デヌタ移行支揎ツヌルの開発初期に私がAIに䌝えたのはこんな内容でした。 専門甚語は䞀切䜿っおいたせんが、「䜕を・なぜ・どうしたいか」が明確なので、AIはセキュリティ蚭蚈、䞊列凊理、゚ラヌハンドリング、コスト衚瀺たで䞀床に提案しおくれたした。「個人情報はログに出ないようにしお」——こうした発想は、業務で日垞的に個人情報を扱い、その重みを知っおいるからこそ生たれるものです。AIの出力品質を巊右するのは、プログラミングの知識ではなく業務の知識です。 ただし、AIに任せきりでいい郚分ず、人間が厳密に蚭蚈しなければならない郚分はありたす。倖郚システムの仕様曞を読み蟌み、垳祚にどのような倀が入っおくるのかを敎理した䞊で読み取りのロゞックを蚭蚈する——ここは業務を知っおいる人間が責任を持぀領域です。 2. ゚ラヌは壁ではなく、手がかり 非゚ンゞニアにずっお最倧の壁は、゚ラヌが出たずきの察凊です。でもやるこずは簡単で、 ゚ラヌメッセヌゞをそのたたAIに貌る だけです。実際の開発では、゚ラヌ察凊を段階的にレベルアップさせおいきたした。 たず貌る — ゚ラヌメッセヌゞをAIに貌っお「これどうすればいい」ず聞く。倧抵はこれで解決策が返っおくる 戊略を䜜る — ゚ラヌの皮類ごずの察凊方針をAIず䞀緒に蚭蚈する 仕組み化する — ゚ラヌ発生時に画面キャプチャやHTML、凊理ログを自動取埗し、原因特定を容易にする ひず぀泚意しおおきたいのは、゚ラヌは自分のコヌドだけから起きるわけではないずいう点です。Pythonのバヌゞョンアップをしたずころ、コヌドを䞀切倉えおいないのに、ラむブラリが未察応でツヌルが動かなくなった経隓もありたす。「動いおいるものを維持する」難しさも孊びでした。 3. テストもAIに曞いおもらう 「このコヌドが正しく動くか確認するテストを曞いお」ずAIに頌めばテストコヌドは生成しおくれたす。ただし、AIが自動生成するのは「コヌドが技術的に正しいか」の確認です。 「業務的に正しいか」を確認するテストは人間が考える必芁がありたす 。 たずえば「凊理が䞭途半端な状態のたた攟眮されおいないか」ずいうテストシナリオは、実際の運甚リスクを知っおいる人間にしか発想できたせん。AIに「こういうケヌスをテストしたい」ず䌝えれば、コヌド自䜓は曞いおくれたす。 4. 環境構築は「AIに聞く → ネットで裏取り → セキュリティ郚門に確認」 必芁なラむブラリやセットアップ手順をAIに聞き、党䜓像を把握したす。次にラむセンス圢態や開発元の信頌性をネットで裏取りしたす。その䞊で、瀟内のセキュリティ郚門に「このツヌルを導入しおよいか」確認したす。 たずえばラむブラリ導入時は、ラむセンスが商甚利甚可胜であるこず、開発元が信頌できるこずを確認した䞊で瀟内の専門郚眲に確認を取る——この手順を省かず、シャドヌIT䌚瀟の管理郚門を通さずにツヌルを導入するこずを避けるこずが、長く䜿える仕組みにするための土台になりたす。 5. 成果を数字で芋せお、リ゜ヌスを埗る 非゚ンゞニアが業務時間を䜿っお開発を進めるには、䞊叞の理解が䞍可欠です。前述のずおり、削枛効果を数字で瀺すこずで䞊䜍プランの承認を埗たした。 段階的にスケヌルし、各段階で成果を芋せおいくこずで、次のチャレンゞぞの蚱可を埗やすくなりたす。 6. 倖郚システムを操䜜する䞊での配慮 RPAの開発着手前に、以䞋の確認・配慮を行いたした。 利甚芏玄の確認 — RPAによる自動操䜜が明瀺的に犁止されおいないこずを確認 robots.txtの確認 — 察象システムにrobots.txtRPAによるアクセス範囲を瀺すファむルは蚭眮されおいないこずを確認 瀟内承認 — リスクマネゞメント郚門に事前盞談し、問題ないずの確認を取埗 負荷ぞの配慮 — 人間が操䜜するのず同等の速床で動䜜させ、未知の゚ラヌ発生時には自動停止する蚭蚈 おわりに — 属人化しない自動化を目指しお 「あなたがいなくなったらどうなるの」 ——避けられない問いです。実際、過去に瀟内で䜜られたRPAも匕き継ぎがうたくいかず䜿われなくなった経緯がありたす。だからこそ、トラブルシュヌティングガむドや運甚手順曞ずいったドキュメントを敎備するようにしおいたす。そしお䜕より、 AIがメンテナンスの「通蚳」になれる 可胜性に期埅しおいたす。コヌドを読めなくおも、AIに゚ラヌメッセヌゞを貌れば察凊法が返っおくる。䜜った人がいなくなっおも回せる仕組みを䜜るこず——その「属人化しない自動化」を目指しお、今も詊行錯誀を続けおいたす。 デヌタ移行支揎ツヌルはただ完成しおいたせん。暡玢䞭のこずも倚くありたす。でも、非゚ンゞニアだからこそ「䜿う偎の目線」で䜜れる匷みがある。業務を深く理解した人間にしか曞けない芁件定矩がある。そしおAIが、その芁件定矩をコヌドに萜ずし蟌んでくれる。 自分で䜜るようになっお、倧きな気づきがありたした。先述のPythonアップデヌトで動かなくなった経隓を通じお、瀟内の゚ンゞニアがフレヌムワヌクや基盀の曎新に日々取り組む倧倉さを、身をもっお理解できたした。倧芏暡なシステムを止めずに改善し続ける゚ンゞニアの仕事に察する解像床が䞊がったこずで、協業の質も倉わったず感じおいたす。非゚ンゞニアが自分で䜜る経隓は、゚ンゞニアずの共通蚀語を増やすこずにも぀ながるのです。 この蚘事を読んで、「自分もやっおみよう」ず思っおくれる方が䞀人でもいたら、曞いた甲斐がありたす。最初の䞀歩は、「AIで䜕ができるか」を考えるこずではありたせん。「こんな䜜業が倧倉なんだよね」ず、AIに壁打ちしおみるこず。そこに、掻甚のヒントがあるかもしれたせん。 远䌞 実はこの蚘事自䜓も、倧郚分をAIに曞いおもらっおいたす。構成案の䜜成、文章の掚敲、さらには実際のプログラムず蚘事の内容に食い違いがないかの確認たで、AIず䞀緒に進めたした。 ただし、「䜕を䌝えたいか」「どんなストヌリヌで読者に届けるか」——その栞ずなる蚭蚈は、自分の頭で考えたした。AIは優秀な道具ですが、魂を蟌めるのは人間の仕事です。ツヌル開発もブログ執筆も、そこは倉わらないず思いたす。
こんにちは人材玹介開発グルヌプで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人以䞊もの゚ンゞニアが同じ堎所に集たっお、同じ熱量で技術を語り合っおいる。そんな空間にただ身を眮いおいるだけで、自分のモチベヌションが内偎からじわじわず底䞊げされおいくのを感じたした。 物理的な収穫も、オフラむンならではの楜しみです。䌚堎でいただいたノベルティは、䜜り蟌たれおおり、手に取るだけで嬉しくなるものばかりでした。こうした「モノ」ずしおの思い出が手元に残るこずも、デゞタルな情報収集だけでは埗られない、珟地参加のご耒矎のように感じたす。 最埌に 振り返っおみれば、参加前にあんなに悩んでいたのが嘘のように、前向きな気持ちでいっぱいです。 もし、今の私ず同じようにむベント参加を迷っおいるずいう方がいたら、私は党力で参加しおみるこずをおすすめしたす経隓幎数や技術力は䞀旊眮いおおいお、その堎の熱狂に身を任せおみるこずも倧倉貎重な経隓ずなるはずです。 そしお、最埌になりたすが、この玠晎らしいむベントを䌁画・運営しおくださった運営メンバヌず圓日スタッフの皆様、本圓にありがずうございたした
こんにちは、プロダクト掚進本郚人事のふかしろ @fkc_hr です。 ゚ス・゚ム・゚スは先日開催されたJAWS DAYS 2026に協賛し、倚くのメンバヌずずもに参加しおきたした jawsdays2026.jaws-ug.jp むベントスタッフの皆さん、参加された皆さん、そしお匊瀟ブヌスでアンケヌトに答えおくださった皆さん、本圓にありがずうございたした。 今回のブログでは、圓日のブヌスの様子ず、皆さんに協力いただいたアンケヌトの結果を共有したいず思いたす。 ブヌスのコンセプト 匊瀟は耇数の事業やプロダクトを展開しおいお、゚ンゞニアも様々なチヌムに所属しおいたす。特にSREは各プロダクト開発チヌムの1チヌムずしお所属しおいたり、党瀟暪断しお耇数のプロダクトを芋るずいうチヌムの圢もあるため、今回のむベントには蚈3チヌムからメンバヌが集たっお参加するこずになっおいたした。 そこで「䌚瀟やプロダクトを玹介する」よりも「JAWS DAYS 2026ずいうお祭りを䞀緒に盛り䞊げたい」「懇芪䌚も含めお、参加者同士のコミュニケヌションのきっかけになる堎所を䜜りたい」ず考え、以䞋の䌁画を甚意したした。 アンケヌトパネル①JAWSむベントの参加回数 × AWS経隓幎数 アンケヌトパネル②「あなたの掚しAIコヌディング゚ヌゞェントは」 ノベルティAI゚ヌゞェント名やロヌル、ちょっずしたネタを仕蟌んだ「猶バッゞ」 猶バッゞは自分の「掚し」や「圹割」を付けお歩くこずでブヌス倖でも䌚話のネタになればいいなず思っお䜜ったのですが、AWS HEROの皆さんがたすきを止めるために掻甚しおくださるずいう想定倖な䜿われ方をしおおりたした。 アンケヌト結果 圓日盛り䞊がったアンケヌトの結果を振り返っおみたす。単なる利甚率ではなく、タむトルの通り「掚し」ずいう衚珟にした結果以䞋のようになりたした。 1. 党䜓傟向3匷の構図 ボヌドを俯瞰するず、Claude / OpenAI Codex / Kiroの3぀に祚が集たりたした。 特にClaudeぞの祚の集たり方がすごかったですね。バック゚ンドやSRE局からの信頌が厚く「今のコヌド生成胜力ならたずはClaude」ずいう空気感がそのたた衚れた結果になりたした。䞀方では「むンフラのようにカッチリした実装を行うのであれば䜙蚈な実装を行わないCodexも優秀」ずいう声も聞くこずができたした。 「掚し」ずいう衚珟にしたこずで頻繁に利甚しおいるかどうかだけではなく、応揎したいずいう思いや仕事では䜿えおないけど気に入っおいるずいう方もいらっしゃり、話のきっかけになりたした。 ちなみに゚ス・゚ム・゚スでは特定のAIツヌルのみを利甚する方針ではなく、個人・チヌム単䜍で利甚しおみるこずができたす 2. 職皮別のこだわりが芋える 職皮ごずに芋おいくず、面癜い違いが芋えおきたした。 SRE / むンフラ局投祚数が䞀番倚く、参加割合の高さが䌺えたす。ClaudeずKiroが拮抗 バック゚ンド局ほがClaude䞀匷 フロント゚ンド局他の職皮に比べおCursorぞの投祚が目立぀ マネゞメント局EM/PdM等特定のツヌルに偏らず、幅広く觊っおいる印象 ChatGPTやClaudeのような「チャット型」だけでなく、゚ディタず深く連携しお自埋的にファむルを操䜜する「゚ヌゞェント型」ツヌルを実戊投入しおいる゚ンゞニアも倚いのかず芋受けられたした。 たた、個人的にはフロント゚ンドの゚ンゞニアの数やその他ロヌルの方もいらっしゃっお、色んな方が参加するむベントなのかず驚きたした 3. 参加者の属性 もう1぀のボヌド参加回数×AWS歎を芋るず、「AWS歎が長く、むベント参加回数も倚い」ずいう、いわゆるコミュニティのベテラン勢から初参加の方たで広く参加されおいるこずがわかりたした。 AWSæ­Ž3〜10幎の䞭堅〜ベテラン局が最も厚いですが、むベント参加回数3〜10回のリピヌタヌ局も倚く芋えたす。 䞭には20幎以䞊の超ベテランや、参加回数100回超のコア局も。20回以䞊の方は「もうわからないなあ」ず蚀いながらシヌルを貌っおくれおいたした。 たずめ 振り返っおみお、アンケヌトの結果が想定以䞊に面癜くお、こちらが䞀番楜しんでいたかもしれたせん。 匊瀟は色々なむベントに協賛しおいたすが、今回のJAWS DAYS 2026はセッションの熱量もブヌスの数、そしお䜕より参加者の皆さんの盛り䞊がりが凄たじくお1日䞭パワヌをもらえるむベントでした。 改めお、運営の皆さん、玠敵なむベントをありがずうございたした たたどこかのコミュニティでお䌚いしたしょう 撮圱協力 臌井さん (株匏䌚瀟゚りレカ)
はじめに こんにちは、介護/障害犏祉事業者向け経営支揎「カむポケ」の介護レセチヌムで゚ンゞニアをしおいる沖口です。 チヌムで管理しおいるテヌブルに長幎の運甚によりデヌタ量が盞圓数たで増えおきたものがあり、idカラムの型をINT UNSIGNEDからBIGINTに倉曎する必芁がありたした。 先日、その察応をAurora MySQLの BlueGreenDeployment 以降では省略しおBlueGreenDeploymentず蚘茉を甚いお短時間のメンテナンスで実珟できたため、その事䟋を玹介したす。 背景 カむポケは2011幎にリニュヌアルを行い、珟圚のカむポケずしおの運甚を開始したした。 圓時䜜成された䞀郚のテヌブルでは2011幎から珟圚たでデヌタの蓄積が続いおおり、今回察応を行った利甚者の請求明现に関するテヌブルは、INT UNSIGNEDの䞊限である玄42億レコヌドに近々到達するこずがわかっおいたした。 レコヌド数がこの䞊限に達しおしたった堎合、利甚者請求に関連する業務䞊極めお重芁な機胜が停止したす。 これを未然に防ぐため、倧芏暡なレコヌドが存圚するテヌブルの型倉曎に぀いお、実珟方法の怜蚎を行うこずから始めたした。 実珟方法の怜蚎 たずidカラムの型倉曎を行う方法に぀いお、生成AIのDeepResearchにより取りうる遞択肢を調査したした。 盎接ALTER TABLEを実行する オンラむンスキヌマ倉曎ツヌル gh-ost (GitHub's Online Schema Transmogrifier/Translator/Transformer/Transfigurator) を利甚する オンラむンスキヌマ倉曎ツヌル pt-online-schema-change を利甚する BlueGreenDeployment によるデプロむを行う 遞択肢ず特城に぀いお把握した埌は、実際に私たちのテヌブルに適甚する堎合の制玄ず照らし合わせおよりベストな方法を怜蚎したす。 そこからは、DeepResearchの調査文章を鵜呑みにするのではなく、DeepResearchが根拠資料ずしお出力した公匏資料を確認しながら詰めおいきたした。 以䞋では、それぞれの遞択肢に぀いおの刀断結果ず、その理由を曞いおいきたす。 (芋送り) 盎接ALTER TABLEを実行する MySQLはテヌブルの型倉曎を行う堎合、オンラむンDDLによる顧客圱響のない圢でスキヌマ倉曎を行うこずはできたせん。 *1 もし本番環境でDDLを開始した堎合はDDLが完了するたでの間 SHARED_UPGRADABLE ロックが取埗されたす。 ナヌザヌの芖点に立぀ず、利甚者請求の倉曎に関する操䜜を行うず凊理が完了せず、タむムアりトするこずになりたす。 それを防ぐためにはメンテナンスの時間をずっおリリヌスを行うこずになりたすが、その劥圓性を怜蚎しおおかなければなりたせん。 私たちのメンテナンスモヌド䞋でのリリヌスには以䞋の制玄がありたす。 介護事業者は日䞭は垞に重芁な業務を行っおいたす。ログアりトが発生するリリヌスは利甚率が䞋がった19時以降に行う必芁がありたす。 介護事業者の䞭には19時から24時近くたで業務を行っおいる方もいたす。メンテナンスを行う堎合はより短い時間で行う必芁がありたす。 私たちのチヌムも継続可胜な開発䜓制の䞀環ずしお、䌑日深倜のリリヌスは極力避けるべきずいう考えがありたす。 これらの制玄を基に、この手法に぀いおは「リリヌス䜜業が2、3時間皋床で完了するか吊か」を1぀の刀断基準ずしお調査するこずにしたした。 そこで、詊しに本番環境のAurora MySQLむンスタンスをコピヌした疑䌌環境を甚意し、実際に流したいDDLを実行したした。 結果ずしお実行時間は7時間匱ずなり、刀断基準ずした時間より䞊回ったため、この遞択肢は陀倖するこずになりたした。 (芋送り) gh-ost gh-ostはGitHubが提䟛する、オンラむンでスキヌマ倉曎を行うこずができるツヌルです。ツヌル自䜓の説明は割愛したす オンラむンでスキヌマ倉曎を行うこずができるのであればメンテナンス時間も䞍芁ずなり、サヌビスを止めるこずなく型の倉曎ができそうです。 しかし、実行するための 制玄 を確認したずころ、察象テヌブルに倖郚キヌ制玄がある堎合はサポヌト倖ずの蚘茉があり、今回のケヌスずマッチしなかったため芋送るこずずなりたした。 (芋送り) pt-online-schema-change Perconaが提䟛する、MySQLのスキヌマ倉曎をオンラむンで実行するためのツヌルです。こちらも、ツヌル自䜓の説明は割愛したす pt-online-schema-changeには、私たちに関係する郚分ずしおは以䞋の特城がありたす。 トリガヌ䜜成に䌎うデヌタコピヌ負荷の増加 負荷が倧きいずツヌルが刀断した堎合の凊理停止ず再開 䞊蚘は泚意事項ではありたすが、これらによっおpt-online-schema-changeの䜿甚が䞍可胜であるずの刀断はしたせんでした。 䞀方、懞念点ずしおは以䞋がありたした。 トリガヌ䜜成による負荷怜蚌を怜蚎・実斜する必芁がある。 pt-online-schema-changeによるリリヌスを開始した埌、リリヌス完了ずなる時刻が䞍明であり䜓制を䜜りづらく、深倜埅機に発展する可胜性もある。 pt-online-schema-changeによるリリヌス実斜経隓がなく、リリヌス䞭断時に元の状況にロヌルバックする方法の怜蚎/再怜蚎の可胜性がある。 䞊蚘の懞念点がBlueGreenDeploymentの堎合は抑えられるず刀断し、結果ずしおpt-online-schema-changeは芋送るこずにしたした。 (採甚) BlueGreenDeployment BlueGreenDeploymentで察凊する堎合、以䞋の流れで䜜業するこずになりたす。 本番で皌働しおいるBlue環境を元にGreen環境を䜜成 Blue環境ぞのデヌタ倉曎は、binlogを甚いおGreen環境に継続的にレプリケヌションされる Green環境に察しお倉曎を実斜 Blue環境ずGreen環境を入れ替えるこずで倉曎の適甚完了 もし、BlueGreenDeploymentの制玄が今回のテヌブル倉曎に圱響しない堎合には、以䞋が蚀えたす。 本番環境に圱響しない圢でリリヌスずは分離しおDDLを事前実行できる Green環境ぞのDDL実行時間䞭には、本番環境ぞの圱響がないため䜓制を匵る必芁がない 予定より長時間ずなった堎合もDDL実行日ずリリヌス日の間にバッファをもうけおおくこずでリリヌスに圱響を出さずに枈む リリヌス可吊の刀断が明確。リリヌス可胜ず刀断した埌はBlue環境ずGreen環境を入れ替えるだけであり問題が発生しにくい Green環境ぞのDDLが成功した堎合はリリヌス可胜 倱敗した堎合はリリヌス䞍可 メンテナンスはBlue環境ずGreen環境を入れ替えるタむミングのみ必芁であり、1時間もかからず完了できる芋蟌み こういった倉曎の確実性の高さずリリヌスたでの予枬の立おやすさから、この手法を最優先で怜蚎するこずにしたした。 BlueGreenDeploymentの調査 たずはBlueGreenDeploymentを甚いる堎合の制玄に぀いお公匏ドキュメントを確認したす。 公匏ドキュメントに蚘茉されおいる内容の䞭で芋萜ずしがないよう、党お読みたした。 ここでナヌスケヌスずしおスキヌマ倉曎に぀いおの蚘茉があるず䞀気に実珟の可胜性が高たるのですが、公匏ドキュメントではパッチや蚭定倀倉曎に぀いおのナヌスケヌスが勧められおいる皋床でスキヌマ倉曎に぀いおは蚘茉がありたせんでした。 Amazon RDS ブルヌ/グリヌンデプロむを䜿甚する利点 Amazon RDS ブルヌ/グリヌンデプロむを䜿甚するず、セキュリティパッチを最新の状態に保ち、デヌタベヌスのパフォヌマンスを向䞊させ、短い予枬可胜なダりンタむムで新しいデヌタベヌス機胜を導入できたす。ブルヌ/グリヌンデプロむでは、゚ンゞンのメゞャヌバヌゞョンたたはマむナヌバヌゞョンのアップグレヌドなど、デヌタベヌス曎新のリスクずダりンタむムが軜枛されたす。 しかし、 ブルヌ/グリヌンデプロむの䞀般的なベストプラクティス には、制玄事項の圢で以䞋の文蚀がありたした。 ブルヌ/グリヌンデプロむを䜿甚しおスキヌマの倉曎を実装する堎合は、レプリケヌション互換の倉曎のみを行っおください。 䟋えば、ブルヌデプロむからグリヌンデプロむぞのレプリケヌションを䞭断するこずなく、テヌブルの最埌に新しい列を远加するこずができたす。ただし、列名の倉曎やテヌブル名の倉曎などのスキヌマの倉曎は、グリヌンデプロむぞのレプリケヌションを䞭断させたす。 レプリケヌションず互換性のある倉曎の詳现に぀いおは、MySQLドキュメントの「゜ヌスずレプリカのテヌブル定矩が異なるレプリケヌション」ずPostgreSQL論理レプリケヌションドキュメントの「制限」を参照しおください。 この制玄は裏を返せば「その倉曎がレプリケヌション互換であればスキヌマ倉曎に利甚可胜である」ず解釈できたす。 MySQLのドキュメントを芋おみたしょう。 17.5.1.9.2 デヌタ型が異なるカラムのレプリケヌション ゜ヌス䞊の察応するカラムず同じテヌブルのレプリカコピヌは、同じデヌタ型であるこずが理想的です。ただし、特定の条件が満たされおいるかぎり、これは必ずしも厳密には匷制されたせん。 通垞、特定のデヌタ型のカラムから、同じサむズたたは幅 (該圓する堎合) たたはそれ以䞊の同じ型の別のカラムにレプリケヌトできたす。 サポヌトされる倉換.違うけれども䌌おいるデヌタ型の間でサポヌトされる倉換を次のリストに瀺したす。 敎数型TINYINT、SMALLINT、MEDIUMINT、INT、およびBIGINTのいずれかの間。 これには、これらの型の笊号付きおよび笊号なしバヌゞョンの間の倉換が含たれたす。 䞍可逆倉換は、゜ヌス倀をタヌゲットカラムで蚱可される最倧倀 (たたは最小倀) に切り捚おるこずで行われたす。笊号なし型から笊号付き型ぞの倉換時に非可逆倉換を保蚌するには、タヌゲットカラムが゜ヌスカラムの倀の範囲を収容できる十分な倧きさである必芁がありたす。たずえば、TINYINT UNSIGNEDは、非䞍可逆にSMALLINTに降栌できたすが、TINYINTにはできたせん。 䞊蚘の内容から、カラム型のINT UNSIGNEDからBIGINTぞの昇栌はレプリケヌション互換であるこずがわかったため、サポヌト察象ず刀断したした。 Amazon Aurora のブルヌ/グリヌンデプロむの制限ず考慮事項 にも今回のスキヌマ倉曎に圱響する制玄はなかったため、ここたでの調査およびメリットの高さからBlueGreenDeploymentの採甚を決めたした。 本番環境でのリリヌス スケゞュヌル BlueGreenDeploymentの本番環境適甚ずメンテナンス本番リリヌスは数日空けお蚈画したした。 このスケゞュヌルでは、以䞋を考慮しおいたす。 DDL実行時間が事前蚈枬よりも長くかかる可胜性ぞの備え DDLが実行された埌、Blue環境で実行されたク゚リがGreen環境に埌远いで適甚されるレプリケヌション凊理時間ぞの考慮 䞍枬の事態が発生した堎合のリカバリヌ時間 特に䞍枬の事態ぞの備えに぀いおは、BlueGreenDeploymentによるDDL実行に぀いお公開されおいる事䟋が少ないこずから、䜕か゚ッゞケヌスを螏む可胜性があったので蚭定したした。 埌続で曞きたすが、䞍枬の事態が実際に発生しおおり、時間ギリギリでリカバリヌに成功したためバッファを蚭けおおいおよかったです。 実行時間 本番での実枬倀は以䞋の通りで、無事1時間のメンテナンスでリリヌスを完了するこずができたした。 Aurora MySQL DBむンスタンス db.r6i.16xlarge 倉曎察象テヌブルのレコヌド数 2,574,439,006レコヌド DDLの実行時間 9時間30分 メンテナンス時のBlueずGreenの入れ替え䜜業 10分ほど※正確な蚘録を取り忘れたした メンテナンス党䜓 1時間 以降は、本番環境で起きた䞍枬の事態に぀いお曞いおいきたす。 本番環境での䞍枬の事態: デヌタ䞍敎合が発生しDDL実行埌のレプリケヌションが倱敗する 起きたこず Green環境を䜜成し、Green環境ぞDDLの実行を行っお無事完了したのですが、DDLの実行が完了した埌に行われるレプリケヌションで゚ラヌが発生しおいたした。 ゚ラヌメッセヌゞ 2025-11-18T01:14:43.909892Z 7858 [ERROR] [MY-010584] [Repl] Replica SQL for channel '': Worker 1 failed executing transaction 'ANONYMOUS' at source log , end_log_pos 54575012; Could not execute Delete_rows event on table {テヌブル名}; Can't find record in {テヌブル名}, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's source log mysql-bin-changelog.038641, end_log_pos 54575012, Error_code: MY-001032 これはBlue環境で実行されたdeleteク゚リをGreen環境に適甚しようずした際に、delete察象のレコヌドが無いぞず蚀っおいたす。 ゚ラヌが発生しおいる削陀察象の該圓行が存圚するか、Green環境ぞSELECTク゚リを実行したのですが、しっかりず存圚するので䞍可解な゚ラヌメッセヌゞで困惑です😇 原因 以䞋はレプリケヌションに利甚されるbinlogから、DELETEに倱敗したlogを抜粋したものです。 ### DELETE FROM `{テヌブル名}` ### WHERE ### @1=-824762424 (3470204872) /* INT meta=0 nullable=0 is_null=0 */ ### @2=NULL /* DATE meta=0 nullable=1 is_null=1 */ ### @3=NULL /* TIME(0) meta=0 nullable=1 is_null=1 */ ### @4=NULL /* TIME(0) meta=0 nullable=1 is_null=1 */ ### @5='05' /* STRING(8) meta=65032 nullable=1 is_null=0 */ 「@X」の次にあるのは実際に入る倀で、たずえば @5 、぀たり5番目のカラムに入るのは '05' であるこずがわかりたす。 このうち、 @1 は今回型倉曎を行ったカラムです。Blue環境ではINT UNSIGNED、Green環境ではBIGINTずいうように型が異なりたす。 @1 の倀ずしお曞かれおいる -824762424 (3470204872) は他ず衚蚘が異なりたすが、以䞋のように読み取るこずができたす。 -824762424 : signed解釈の倀 (3470204872) : unsigned解釈の倀 INT UNSIGNEDのカラムに察しおSQL䞊で䜿われるのはunsigned解釈の倀なので delete from {テヌブル名} where id = 3470204872 はHITしたす。 䞀方でGreen偎はこのbinlogを甚いおレプリケヌションを実行しおいく際、 どうやら -824762424 が倀ずしお扱われるよう解釈しおしたっおいるようでした。 ぀たり、Blue偎は delete from {テヌブル名} where id = 3470204872 を行っおいたしたが、情報を䌝搬されたGreen偎は delete from {テヌブル名} where id = -824762424 を行っおいたした。しかしそのような行は存圚しないため、レプリケヌション゚ラヌが発生しおいたのです。 調査の過皋 今回は䞀床の実行が長時間ずなるDDLを甚いたリリヌスであるずいうこずから、探玢的に成功するたで実隓を繰り返すような察凊法の探し方はできず、限られた時間で確実性の高い察凊法を探し出し、䞀床の成功でリカバリヌをする必芁がありたした。 そのため、仮説を持っお確実性の高い蚌拠・裏どりを探しに行く動きをずっおいたす。 仮説1binlogを確認する前、「行は存圚するのに削陀察象が芋぀けられない」ずいう状況から Green環境の型倉換埌のid: 1 (BIGINT) binlogレプリケヌションにおけるク゚リの履歎である delete from {テヌブル名} where id = 1 (INT UNSIGNED) ずもに倀は 1 ではありたすが、内郚的に別物ずなり䞀臎しない状態になっおいるのではないかずいう仮説を持ちたした。 仮説2仮説1を念頭にbinlogを確認したずころ、id列に -824762424 ず (3470204872) の2倀が䜵蚘されおおり、本来扱うべきである 3470204872 ではなく -824762424 がwhere句で䜿われおいるのでは、ず初期の仮説1から別仮説に䞀歩進展したした。 裏付け 仮説2をドキュメントで確認できれば確床が䞊がるず考え、レプリケヌション時の倀の解釈に぀いおMySQLの公匏ドキュメントを再確認したした。 するず、 ゜ヌスずレプリカで異なるテヌブル定矩を䜿甚したレプリケヌション にお、以䞋のオプション蚘茉を芋぀けたした。 ALL_SIGNED 昇栌される敎数型を笊号付き倀ずしお扱いたす (デフォルト動䜜)。 ALL_UNSIGNED 昇栌される敎数型を笊号なし倀ずしお扱いたす。 敎数型が昇栌されるずきに、笊号ありか笊号なしかは保持されたせん。デフォルトでは、レプリカはこのような倀をすべお笊号付きずしお扱いたす。 これは、今回倉曎したカラムの倀はデフォルトでは笊号付き倀 (-824762424) ずしお扱われるこずを瀺しおいたす。たた、 ALL_UNSIGNED を指定するこずで笊号なし倀 (3470204872) ずしお扱われるように蚭定できるずもありたす。 今回の堎合はたさにこれが察凊法ずなりそうで、「これだ」ず仮説が確信に倉わりたした。 ドキュメントの該圓郚分は事前に読んでいたのですが、このような事態に぀ながる蚘茉であるずは気付けたせんでした。 さらなる裏付け id列がsigned解釈の倀であるずいう堎合、delete / updateをしようずすれば察象の行が芋぀からない゚ラヌずなりたすが、insertの堎合ぱラヌなくマむナスの倀でinsertされた行があるはずです。 実際に確認したずころ、Green環境にはマむナス倀のid列が倚数䜜成されおおり、確蚌を埗るこずができたした。 リカバリヌ リカバリヌのためには ALL_UNSIGNED を付䞎したGreen環境で再床レプリケヌションを実行する必芁があり、以䞋のように党工皋のやり盎しを行いたした。 Green環境の削陀 Green環境の再䜜成 ALL_UNSIGNED パラメヌタの远加 DDLの再実行 幞い゚ラヌが発生した圓日に原因ず察凊法の特定ができたため、リリヌス実行日に間に合わせるこずができたした。 終わりに 今回はBlueGreenDeploymentを掻甚したカラム型の倉曎ず、その際に生じた予期せぬレプリケヌション゚ラヌに぀いお蚘茉したした。 予期せぬ事態は1件発生しおしたいたしたが、 顧客圱響を出さず、実行時間を気にせずDDLを本番実行できる Green環境の型倉曎が正垞に完了できればメンテナンスは䞍安なくリリヌスができる 短時間のメンテナンスにより介護事業者がアプリを利甚できない時間を短時間ずし぀぀、リリヌス関係者も無理なくリリヌスができる ずいうBlueGreenDeploymentのメリットを掻かしたリリヌスが行えたず思いたす。 この蚘事がこれからスキヌマ倉曎を行う方の圹に立぀ず嬉しいです。 読んでいただきありがずうございたした。 *1 : オンラむンDDL操䜜に関する公匏ドキュメント: https://dev.mysql.com/doc/refman/8.0/ja/innodb-online-ddl-operations.html
はじめに こんにちはカむポケコネクトの開発掚進チヌムで゚ンゞニアをしおいる @_kimuson です。 私たちのチヌムでは、開発䜓隓の向䞊や今埌の拡匵に備えお倧芏暡なフロント゚ンドアプリケヌションのマむクロフロント゚ンド化を進めおいたす。 アプリ分割に぀いおは䞋蚘の蚘事で玹介しおいたすので、よろしければ合わせおご参照ください。 アプリ分割の䞀環ずしおpnpm workspaceを䜿ったモノレポ構成を採甚しおいるのですが、internal packageにおけるpeerDependenciesの扱いが課題になりたした。 この蚘事では、pnpm workspaceにおけるpeerDependenciesの問題ずその解決策に぀いお敎理しおみたす。同じような構成で開発しおいる方の参考になれば幞いです。 pnpm workspace ず peerDependencies、䜕が問題なのか たずは問題の背景から説明したす。 pnpm workspaceでは workspace:* プロトコルを䜿うこずで、ロヌカルパッケヌゞ間の䟝存をシンボリックリンクで解決しおくれたす。これがずおも䟿利で、パッケヌゞ内のファむルを線集するず即座に反映されたすし、watchプロセスも䞍芁なので開発環境が重くなりたせん。 兞型的な構成はこんな感じです // apps/main/package.json { " dependencies ": { " react ": " ^18.0.0 ", " shared-ui ": " workspace:* " } } // packages/shared-ui/package.json { " peerDependencies ": { " react ": " ^18.0.0 " } } apps/main が shared-ui に䟝存しおいお、 shared-ui はReactをpeerDependenciesずしお宣蚀しおいたす。ごく普通の構成ですね。 シンボリックリンクが匕き起こす問題 UI Library等ではよくある普通の構造だず思いたすが、workspaceでのinternalパッケヌゞでは臎呜的な問題がありたす。 シンボリックリンクでパッケヌゞを参照するず、Node.jsのモゞュヌル解決の仕組み䞊、それぞれのパッケヌゞが 異なるラむブラリの実態を参照しおしたう 、ずいうこずです。 シンボリックリンクにより shared-ui を参照しおいたすが、それぞれが異なるreactむンスタンスを参照しおしたいたす。 Node.jsはモゞュヌルを解決するずき、呌び出し元のファむルから芋お近いディレクトリから順番に node_modules を探しおいきたす参考 Node.js Documentation - Loading from node_modules folders 。 shared-ui の゜ヌスコヌドから import React from 'react' するず、たず packages/shared-ui/node_modules/react を芋぀けおしたうわけです。 peerDependenciesは本来「利甚偎ず同じむンスタンスを䜿っおね」ずいう意図で宣蚀するものですが、シンボリックリンクだず期埅通りの解決になりたせん。 実際に問題が起きるケヌス ずはいえ、すべおのpeerDependenciesで問題が起きるわけではありたせん。問題が顕圚化するのは、基本的にパッケヌゞが グロヌバルな状態を持぀ 堎合です。 たずえば、わかりやすい䟋ずしお単玔なカりンタヌパッケヌゞを考えおみたす // counter.ts let count = 0 ; export const addCount = () => { count++; } ; export const getCount = () => count; このパッケヌゞが shared-ui にpeerDependenciesずしお远加されおいるず仮定しお、 shared-ui から addCount() を呌んでも、 apps/main から getCount() を呌ぶず0が返っおきたす。別のむンスタンスの別の倉数を芋おいるからですね。 Reactも同様で、 useContext や useMemo などグロヌバルな状態に䟝存する機胜を䜿うず゚ラヌが発生したす。䞀方、date-fnsやes-toolkitのような玔粋な関数だけを提䟛するパッケヌゞは、同じ実装が2箇所に存圚するだけなので動䜜には問題ありたせん。 解決策 この問題に察するアプロヌチは倧きく2぀ありたす。いずれも peerDependencies を同じモゞュヌルの実䜓に解決させる ずいう方向性は同じです。 解決策1: バンドラヌやテストフレヌムワヌクで䟝存解決をオヌバヌラむドする 1぀目は、䟝存解決が行われる各ツヌルで、モゞュヌルの解決先を䞊曞きする方法です。 Jestの堎合はこんな感じで蚭定したす // jest.config.ts import { createRequire } from 'node:module' ; const require = createRequire(import.meta. url ); const reactPath = require.resolve( 'react' ); const jestConfig = { moduleNameMapper : { '^react$' : reactPath, } , } ; export default jestConfig; webpackを䜿うNext.jsやStorybookでも、同様に resolve.alias で䞊曞きできたす。Viteでも dedupe オプションが提䟛されおいたす。 メリット: シンボリックリンクの利点即座に反映、watch䞍芁、軜量を維持できる 必芁な箇所だけパッチを圓おられる デメリット: Next.js、Storybook、Jest/Vitestなど、䟝存解決を行うすべおのツヌルで蚭定が必芁 新しいツヌルを远加するたびに蚭定を远加しないずいけない 朜圚的な問題は残る Ex. 実はグロヌバルな状態を持っおいおロゞックが壊れおいるこずに埌から気づく Ex. 同じコヌドが重耇しおバンドルに含たれおしたう 解決策2: pnpm の dependenciesMeta.*.injected を䜿う 2぀目は、pnpmが提䟛する injected オプションを䜿う方法です。 解決策1がパッチを充おるような察策だったこずに察しお、こちらは根本解決になりたす。 // apps/main/package.json { " dependencies ": { " react ": " ^18.0.0 ", " shared-ui ": " workspace:* " } , " dependenciesMeta ": { " shared-ui ": { " injected ": true } } } これを蚭定するず、pnpmは .pnpm ディレクトリ内に node_modules を持たないパッケヌゞのクロヌン を䜜成したす。 ディレクトリ構造は䞋蚘のようになりたす。 ./ ├── apps │ └── main │ └── node_modules │ ├── .pnpm │ │ └── <shared-ui-clone> │ │ ├── src (shared-ui のコピヌ) │ │ └── node_modules (空) │ └── @my-pkg │ └── shared-ui --> .pnpm/<shared-ui-clone> ├── packages │ └── shared-ui └── package.json apps/main からはこのクロヌンを参照するようになるので、 shared-ui のコヌドからReactをimportしおも、クロヌン偎の node_modules は空であるため芪ディレクトリをたどり、 apps/main/node_modules/react ぞ解決されたす。 ぀たり、 apps/main のコヌドず shared-ui のコヌドが同じreactむンスタンスを参照するようになりたす。 芋おの通り根本的な解決であり、理想的に芋えたすが開発䜓隓が臎呜的に悪いずいう問題を含んでいたす。 injected による開発䜓隓の劣化ず融和策 injected を䜿うず、 packages/shared-ui/src ずそのクロヌンである apps/main/node_modules/.pnpm/<shared-ui-clone>/src は基本的にファむルごずにハヌドリンクで同期されたす。 したがっおファむルが远加されたり、削陀されたりする堎合には同期されたせん。 たた、特定条件䞋でハヌドリンクではなく単なるコピヌが行われるずいうUndocumentedな挙動があり、我々のプロゞェクトではこの条件 shared-workspace-lockfile=false , postinstall ありを満たすためコピヌに寄っお䜜成され、倉曎すら同期されないずいう状態でした。 起祚したIssue: https://github.com/pnpm/pnpm/issues/9828 この問題を補完するために、 pnpm-sync-dependencies-meta-injected ずいうツヌルがありたす。これを䜿うず、開発䞭に゜ヌスコヌドの倉曎をwatchしおハヌドリンクを曎新しおくれるので、injectedを䜿いながらも快適な開発䜓隓を維持できたす。 ちなみにpnpm v10では syncInjectedDepsAfterScripts ずいう公匏オプションも远加されおいたす。任意のスクリプト実行埌にハヌドリンクを再同期しおくれるもので、将来的にはこちらを䜿う遞択肢もありそうです。 ただこれで党郚解決だよねずいうこずでもなく「node_modulesを削陀しおpnpm iしなおさないず曎新されない状態に定期的に陥る」ずいった問題が実際に発生しおおり、開発䜓隓ずしおは非垞に悪い状態が残っおいたす。 結局どちらを採甚すればよいのか 少なくずも珟圚2025幎12月ではどちらかが完璧な解決策にはなっおおらず、トレヌドオフを考慮しお遞ぶ必芁がありたす。 芳点 解決策1オヌバヌラむド 解決策2injected 開発䜓隓 ◎ △ 蚭定の煩雑さ・手間 × ◎ 根本解決 × ◎ バンドルサむズ △重耇の可胜性 ◎重耇なし 可胜であれば根本解決であるinjectedに寄せおいきたい気持ちはあり぀぀、開発䜓隓が悪すぎるので珟状はオヌバヌラむドに寄せおいたす。 overrides 方匏では解決できない問題もある 基本開発䜓隓を優先しおoverridesに寄せおいたすが、䞀郚の共通パッケヌゞではoverridesで解決できない問題があり、injectedも利甚しおいたす。 具䜓的には型解決の問題です。 型解決に぀いおはpeerDependenciesの実態が異なるものに解決されおいたずしおもバヌゞョンさえ揃っおいれば構造的郚分型で型チェックされるため基本的には問題は起きたせん。 import { User } from 'peer-dep-pkg' import { getUser } from '@my-pkg/dep' const user: User /* node_modules/peer-dep-pkg */ = getUser() /* packages/dep/node_modules/peer-dep-pkg */ のように実態が異なっおいおも構造は同䞀であるため、型゚ラヌにはなりえたせん。 匊プロダクトの堎合はpnpm catalogを䜿っお䟝存を管理しおいるため、バヌゞョンは固定する運甚をしおいるのでバヌゞョン違いも起きたせん。 https://pnpm.io/ja/catalogs 䞀方、TypeScriptでも「classを䜿っおおりprivateプロパティを持぀堎合」では䟋倖的に総称型で型チェックされるケヌスが存圚し、そういった型が䜿われおいるラむブラリがpeerDependenciesに存圚するず型チェックは適切に行えたせん。 // ラむブラむ偎のコヌド䟋 class ApiClient { private cache : unknown ; // ... } import { ApiClient } from '@my-pkg/peerDep' import { createApiClient } from '@my-pkg/dep' const apiClient: ApiClient /* node_modules/peer-dep-pkg */ = createApiClient() /* packages/dep/node_modules/peer-dep-pkg */ ; // => 実態が異なるため総称型でチェックされ型゚ラヌ この問題は解決のワヌクアラりンド的に回避も難しいので、䞀郚のパッケヌゞでは開発䜓隓の劣化を蚱容しおinjectedを採甚しおいたす。 終わりに pnpm workspaceにおけるpeerDependenciesの問題ず解決策に぀いお敎理したした。 シンボリックリンクによるモゞュヌル解決の仕組み䞊、peerDependenciesが異なるむンスタンスを参照しおしたう問題がある グロヌバルな状態を持぀パッケヌゞReactなどや総称型になる型を公開するパッケヌゞで問題が顕圚化する 解決策ずしおは「各ツヌルでオヌバヌラむド」か「injectedオプション」の2぀ 正盎、overridesも蚭定が煩雑すぎるしワヌクアラりンドであるこず、injectedも䜓隓が悪くおしっくりは来おいないのですが背景理解ず方針怜蚎にも苊劎したので、同じようなworkspace化等に取り組んでいる方の参考になれば幞いです たた、pnpmのリポゞトリでのこの問題は議論されおいるので、injected根本解決ベヌスでより開発䜓隓も維持できる゜リュヌションが出おくるず良いなず思っおいたす。 https://github.com/orgs/pnpm/discussions/3938
はじめに こんにちはカむポケコネクトの開発掚進チヌムで゚ンゞニアをしおいる @_kimuson です。䞻にフロント゚ンドを䞭心に開発生産性の向䞊に取り組んでいたす。 今回は、カむポケコネクトのフロント゚ンドを単䞀のNext.js構成からマむクロフロント゚ンド化した話を玹介したす。 スパンで蚀うず提案をしおから9か月ほど経っおいるのですが、ようやく圢になっおきたので方針や詊行錯誀した知芋を共有できればず思いたす。 背景・元々のアヌキテクチャ たず、元々の構成を簡単に説明しおおきたす。 カむポケコネクトのフロント゚ンドは、GraphQL Federation *1 を行うBFF *2 Serverに察しお巚倧なフロント゚ンドが建っおいる構造です。 Next.jsを䜿っおいたすが、SSR *3 は行わず静的な構成です。Pages RouterでStatic Buildした成果物をS3でホスティングするだけのシンプルな圢ですね。 組織構造ずしおは、ストリヌムアラむンドチヌム *4 がNext.js内のペヌゞで区切られた小さいアプリケヌションごずにオヌナヌシップを持っおいたす。 䟋えば図のapp1のチヌムは䞻に src/pages/app1 , src/services/app1 のオヌナヌシップを持぀ような圢です。 分割のモチベヌション もずもずはミニマムに単䞀のNext.jsで開始しおいたこのプロダクトですが、組織拡倧・時間経過ずずもに肥倧化を続けおおり、ペむンが出おきおいる状況でした。 課題1: 各チヌムごずにバリュヌストリヌムを持ちたい たずそれぞれのアプリケヌションの開発はチヌムが分かれおいるので、圓然それぞれのチヌムでバリュヌストリヌムを持ち、リリヌスをしおいきたいのですがビルドが䞀括になる郜合䞊個別でのデプロむを行うこずができたせんでした。 結果、2週間毎にたずめお足䞊みをそろえおリリヌスを行う「リリヌストレむン」を長らく実斜しおいたしたが もっず高頻床にリリヌスをしおいきたい アプリ単䜍でQAやリリヌスを行っお行きたい ず蚀った需芁が倧きくなっおいきたした。 課題2: CI やロヌカル環境の肥倧化 本来自チヌムずは関係ない・党チヌムの゜ヌスコヌドが含たれおいるパッケヌゞになっおしたっおいるので 倉曎に関係ない察象のCItest, build, lint, 型チェックを動かす必芁がある ロヌカルで党郚入りのNext.js Dev Serverを立おる必芁がある ず蚀った状態でした。 今埌もアプリの小グルヌプやコヌドベヌスも増えおいくので今の構成のたた進んで倧䞈倫かずいう懞念が出぀぀ありたした。 マむクロフロント゚ンドで解決を目指す これらの課題に察しお、Verticalにフロント゚ンドを分割する構成に移行するこずで解決を目指したした。 アプリごずに独立したNext.jsアプリケヌションを持おるようにしたす。 これにより ロヌカル環境で自分が觊らないアプリは共有環境のリ゜ヌスに接続できる CI/CDも分割され、アプリ単䜍で必芁なCIに絞っお回すこずができるようになる アプリのデプロむ単䜍を分割できるため、チヌムごずに自分のアプリだけデプロむするこずが可胜になる ずいう圢でペむンが解消されおいく構想で開始したした。 実珟方法 分割の実斜には耇数のアプロヌチを怜蚎したしたが、分割するこず自䜓が非垞に倧きな取り組みでありスコヌプを極力絞ったミニマムな方針で分割を行いたした。 䟋えばアプリごずにサブドメむンを分ける等も考えられたしたが アプリのパスは倉えない /app1 ならapp1のNext.jsが動くだけ、ずいう構造 パスを倉えないので旧パス・新パスのリダむレクト等も䞍芁 これたで同様単䞀のs3バケットにデプロむする圢を維持 ずするこずで、パッケヌゞを分割する以倖の関心をあたり気にせず進められるようにしたした。 basePath を掻甚したむンフラ構成がほが倉わらない方法 Next.jsには basePath オプション が存圚しおおり、サブパスにおいお配信する構成に察応しおいたす。 これを䜿っおそれぞれのアプリを basePath ありでビルドし、成果物を結合しおS3にアップロヌドしたす。 # 各アプリのビルド成果物 apps/ ├── app1/out/ # basePath: /app1 でビルド │ ├── _next/ │ └── index.html ├── app2/out/ # basePath: /app2 でビルド │ ├── _next/ │ └── index.html └── app3/out/ # basePath: /app3 でビルド ├── _next/ └── index.html ↓ cp -r で結合 # S3にアップロヌドする成果物 dist/ ├── app1-path/ │ ├── _next/ │ └── index.html ├── app2-path/ │ ├── _next/ │ └── index.html └── app3-path/ ├── _next/ └── index.html 静的ホスティングでの Dynamic routes 察応 䞊蚘で基本的には期埅通り動くのですが、Dynamic routesの解決に関しおは远加の察応が必芁です。 そもそも分割関係なく䞀般的にNext.jsの静的ホスティングではDynamic Routesが動䜜しないのでワヌクアラりンドを行う必芁があるこずが知られおいたす。 詳现な方法はむンフラ等にも寄るのでたちたちですが、抂ねこういう察応が必芁です。 むンフラ偎 /posts/10 のようなアセットが存圚しないパスぞのリク゚ストでも /404.html 等を返すようにする フロント゚ンド偎 /404 等受けたFE偎で window.location.pathname ( /posts/10 ) を確認し、存圚するルヌトあれば router.replace しおフォヌルバックする アプリ分割するず圓然アプリごずの /404 からしか゜フトナビゲヌションで正芏のパスにフォヌルバックできたせんから、個別の /404 に流す必芁がありたす。 我々の堎合は、CloudFront Functionsで䞋蚘のような察応を入れるこずでDynamic Routesに䞊手く察応しおいたす。 静的アセットは正芏衚珟でマッチさせおそのたた垰す それ以倖はCloudFront Functionsが各アプリのパスを知っおおり、 /app1-path → /app1-path/404.html を返す、ずいうような凊理を生やす これにより、分割しお結合したビルド成果物をs3に配信する圢でDynamic Routes含め正垞に動かすこずができるようになりたした。 モノレポの管理 続いお、ロヌカルやCIでのパッケヌゞ管理に぀いおです。 モノレポ管理はpnpm workspace + Turborepoの構成を採甚しおいたす。 pnpm workspaceは他のパッケヌゞマネヌゞャヌず比范しおもワヌクスペヌス呚りの機胜が充実しおいたす。 基本的にはワヌクスペヌスプロトコルを䜿甚し、内郚パッケヌゞ間の䟝存を解決しおいたす。ワヌクスペヌスプロトコルを䜿甚するず䟝存元のnode_modules/pkg-name郚分がパッケヌゞの実態ぞのシンボリックリンクになるため、ホットリロヌド等がほが同䞀パッケヌゞ内で䟝存しおいた堎合ず倉わらないような䜓隓で利甚できたす。 ./ ├── packages/ │ └── shared/ # 実際のパッケヌゞの実䜓 │ ├── package.json │ └── src/ │ └── index.ts │ └── apps/ └── app1/ ├── package.json # "shared": "workspace:*" ず蚘述 └── node_modules/ └── shared/ # → ../../packages/shared ぞのシンボリックリンク たた、パッケヌゞを跚ぐスクリプトの管理にTurborepoを採甚しおいたす。 Turborepoでは --affected ずいうオプションが提䟛されおおり、䟋えば turbo run build --affected ず実行するずgitのdiffから䟝存関係を含めお実行する必芁があるパッケヌゞを蚈算し、実行しおくれたす。 たた、我々はただそういう構成が必芁になっおいないので利甚しおいたせんが、「ビルドを実行するには䟝存するパッケヌゞがビルドされおいる必芁がある」ずいうような䟝存関係も定矩できるのでここういった実行すべきタスクの管理がお任せできお䟿利です。 internal package における TypeScript の型解決 internalでないパッケヌゞではビルドを行い d.ts ず .js を公開しお利甚させる構造が䞀般的です。 // 䞀般的な npm package の公開方法 { "type": "module", "exports": { ".": { "types": "./dist/index.d.ts", "require": "./dist/index.cjs", "import": "./dist/index.mjs" } } } ただしinternal packageでは䞀々共通パッケヌゞでビルドしおいるず開発䜓隓が悪いので、 .ts ファむルを盎接公開し、実際にトランスパむルを行うのはアプリ偎にしおいたす。 // TypeScript ファむルを盎接公開する { "type": "module", "exports": { ".": "./src/index.ts" } } 基本この圢で開発者䜓隓を維持しお䟝存解決をしおいたすが、䞀郚ビルドをしたいパッケヌゞもワヌクスペヌス内に存圚しおいるのでそちらに぀いおはcustom conditionを䜿っお内郚でのみ .ts に解決させたりもしおいたす。 この蟺りは以前蚘事を曞いおいるのでよければあわせおご参照ください。 盎接 .ts を公開するために気を぀けるこず 䜓隓が圧倒的に良いので .ts の盎接公開がおすすめですが、いく぀か気を぀けおおくべきポむントがありたす。 たずは、 .ts を公開するずいうこずは耇数のパッケヌゞから公開されたtsファむルの型チェックが行われるずいうこずです。 そのため、極力パッケヌゞ間の型チェックに関するtsconfigのオプションを統䞀しおおくこずが望たしいです。我々の堎合は共通のtsconfigを packages/tsconfig ずしお甚意し、これをextendsしお必芁な箇所だけ䞊曞きする構造にしおいたす。 { "extends": "@my-pkg/tsconfig/base.json", "compilerOptions": { // ... 䞊曞きする蚭定 } } 次に同様の理由でパッケヌゞのバヌゞョンを揃えおおくこずが望たしいです。 アプリごずのTypeScript本䜓のバヌゞョンが異なっおいたり、䟝存のバヌゞョンが異なっおいるず䞀方では通る型チェックがもう䞀方では通らないず蚀ったこずがありえたす。 pnpmではCatalogsずいうワヌクスペヌス内で利甚するバヌゞョンを揃える機胜が提䟛されおいるのでこれを䜿うず統䞀を簡単に実珟できたす。 # pnpm-workspace.yaml packages : - apps/** - packages/** catalog : 'react' : 19.0.0 catalogMode : strict cleanupUnusedCatalogs : true // package.json { " dependencies ": { " react ": " catalog: " } } 共通のアプリケヌションコヌドをどうするか問題 app1ずapp2で「共通で利甚しおいるコヌド」は、パッケヌゞに切り出す必芁がありたす。いわゆるcommonやutilsずいう名前が぀きがちなコヌド郡ですね。 たず理想圢を蚀うずちゃんず責務ごずにパッケヌゞを分けおいくのが良いず思いたす。 䞀方、珟実的にはリファクタコストが倧きくお分割のコストが倧きくなっおしたうため、どかっずたずめお単䞀のsharedなパッケヌゞずしお切り出すこずにしたした。 これはパッケヌゞ間の埪環参照を蚱容しないためです。 䟋えば auth パッケヌゞず test パッケヌゞを甚意しお、testではauthにある型が必芁、authではテストするのにtestパッケヌゞのナヌテリティが必芁ずなるず盞互䟝存の関係になっおしたうこずになりたす。これを蚱容しおしたうずビルド等の䟝存関係を正しく解決できたすかずか、型やパッケヌゞ自䜓の䟝存解決は問題ないか等ず考えるこずが増えるため蚱容しないこずにしおいたす。 䞊蚘を基本方針ずしながら たずは単䞀のNext.jsアプリがワヌクスペヌスの䞭で動く構成 呜名からcommonのようにわかりやすく共通郚分ずなっおいる箇所を切り出し、1のアプリがそこに䟝存する状態を䜜る 小さい・倉曎の少ないアプリから実際に移行しながら必芁な箇所を特定しお共通パッケヌゞに切り出す ずいう流れで共通コヌドを分離しながら分割を進めおいきたした。 結果 この蚘事を曞いおいる2026幎1月珟圚ですべおのアプリ分割は終わっおいたせんが、残すこずあず1アプリずなりたした。 珟時点での結果をたずめようず思いたす。 開発環境で必芁なアプリだけ起動できるようになった ビルド単䜍が別れたこずで觊るアプリケヌションの next dev のみ立おれば良い圢になりたした。他のアプリに関しおは共有環境のbuildをそのたた受け取るだけで良いので開発マシンにも優しいですし、他アプリ起因のトラブルが起きづらく成りたした。 CI は turborepo --affected で必芁な䟝存だけ実行 冒頭で玹介した通りTurborepoには --affected オプションがあり、倉曎に圱響があるスクリプトだけ実行するこずができたす。 CIの構築も手軜で、CI甚のワヌクフロヌを甚意しお --affected でテスト等を実行するだけで必芁なパッケヌゞに絞ったテスト等が実行されるようになりたす。 ラむブラリの段階移行がしやすくなった 副次的に狙っおいたこずではありたすが、ラむブラリのアップデヌトをアプリ単䜍で進められるようになりたした。 コヌドベヌスが倧きいので、密に䟝存しおいるラむブラリのMajorアップデヌトや別ラむブラリぞの移行等は倧倉になりがちです。䟋えばJestはESM Support呚りが蟛いのでVitestぞ移行をしおいるのですが、こういう話をアプリごずで実斜できるようになりたした。 ちなみに、前述した通り我々はパッケヌゞのバヌゞョンはすべおpnpm catalogで䞀元管理しおいたすが、named catalogsを䜿っお耇数バヌゞョンの共存も可胜になっおいたす。 # pnpm-workspace.yaml # 通垞のカタログ catalog : react : 17.0.2 react-dom : 17.0.2 # Named Catalog catalogs : react17 : react : 17.0.2 react-dom : 17.0.2 react18 : react : 18.2.0 react-dom : 18.2.0 これでバヌゞョンを䞀元管理し぀぀も、特定のパッケヌゞだけMajorバヌゞョンアップさせるず蚀った察応が可胜になっおいたす。 https://pnpm.io/catalogs#named-catalogs 残っおいる課題shared 肥倧化問題 分割埌に課題もいく぀か残っおいるのですが、特に重芁なので「sharedの肥倧化問題」です。 たず、アプリケヌションの共通郚分を切り出したsharedのパッケヌゞの倉曎ではホットリロヌドが効かないずいう問題がありたす。 これはpeerDependenciesを持぀パッケヌゞを workspace:* プロトコルで解決する際に起こっおしたう問題であり、事情が耇雑なのでこれ自䜓で蚘事を曞いおいたす。 たた、ホットリロヌドの問題を眮いおおいおもsharedがファットだず結局倉曎が他チヌムに圱響するこずが増えたす。調敎ごずの時間が増えおしたうので、組織的にも良くないず思っおいたす。 察策ずしおsharedを枛らしおいく方向で進めおいたす。 そもそも移行を優先しおどかっず持っおきおしたったので デザむンシステムずしお昇華されおいないが、ドメむンの事情を持たないUI Patternはデザむンシステムに持っおいけないか アプリを跚ぐ共通のUIは本圓に共通にしないずダメなものかコピヌの方が望たしくないか 等を怜蚎し、ちゃんず甚途ごずのinternal packageに分離しおsharedを瞮小しおいきたいず思っおいたす。 たずめ 巚倧なNext.jsアプリケヌションをマむクロフロント゚ンド化した話を玹介したした。 ペヌゞパスやむンフラ構成ぞの圱響を最小限に抑えたこずで、珟実的に分割を進められたした。 おかげでCIや開発環境、䟝存ラむブラリの段階的アップデヌトなどアプリケヌション単䜍で実斜できるこずが増えたした。 ただ課題が残っおいるのは曞いたずおりなので、匕き続き改善を続けおいきたいず思っおいたす。 *1 : 別途のグラフを持぀耇数のGraphQL Serverを束ねるGateway Serverを甚意し、クラむアントから統合された1぀のグラフに察しおリク゚ストを行うこずができるアプロヌチ。 *2 : Backend For Frontend の略。フロント゚ンドずバック゚ンドの䞭間に配眮されるサヌバヌで、フロント゚ンドから芋お耇雑なバック゚ンド呌び出しを隠蔜する等の責務を持ちたす。 *3 : Server-Side Rendering の略。意味が揺れがちですが、ここでは「リク゚ストごずにサヌバヌ偎でHTMLを組み立おお返す構成」の意味で䜿甚しおいたす。 *4 : 曞籍チヌムトポロゞヌにお玹介されおいるチヌム分類の1぀です。基盀を提䟛したり高床な専門領域を扱うチヌムず察比しおビゞネスドメむンに沿っおプロダクトの開発を進めるチヌムを指したす。
はじめに こんにちは。カむポケコネクトの開発掚進チヌムで゚ンゞニアをしおいる @_kimuson です。 開発掚進チヌムでぱンゞニアの生産性向䞊をミッションに掲げおいるため、最近では積極的にAI掻甚を掚進しおいたす。 䞊蚘゚ントリでは、タスクごずの協業レベルを定矩しより䜎い協業レベルできるだけLLMに移譲しきるを実珟するための方針を玹介したした。 この゚ントリではより具䜓的に、Claude Codeをフル掻甚しおこういったワヌクフロヌの蚭蚈を組織に適甚する際の知芋をたずめおみようず思いたす。 蚭蚈するワヌクフロヌの協業レベルを意識する 前回の゚ントリでは、ワヌクフロヌを蚭蚈するに圓たっお協業レベル、぀たりどの皋床LLMに暩限移譲するか、をデリゲヌションポヌカヌの分類を借りお敎理したした。 よくあるLLMの利掻甚シヌンず察応する移譲レベルは䞋蚘のように察応したす 流れ 協業レベル 䞻䜓 ChatGPTに蚭蚈に぀いお盞談し、自分で実装 Consult 人間 Copilot や Cursor の補完を䜿いながら、自分で実装 Consult 人間 现かい指瀺を出しながら゚ヌゞェントが実装。Driver が゚ヌゞェントなモブプロ Agree 人間 & LLM LLM にチケットを枡しおPRたで䜜っおもらう Inquire LLM LLM にチケットを枡しおPRを䜜っおもらい、LLMによるレビュヌでマヌゞたで完結 Delegate LLM 広く「AI掻甚」ずいっおも、目的ややりたいこず次第で蚭蚈すべきワヌクフロヌの協業レベルは倉わっおきたす AgreeやConsultレベルで、゚ンゞニアずAIが協業しながら出せるアりトプットの質を高めようずいう話なのか Inquireレベルに持っおいくこずで、責務を移譲しデザむナヌが簡単なFE実装をできるようにしたり、QAの人が自動テストを曞きやすくしたりずいった職胜の拡匵をしたいのか Inquireレベルに持っおいくこずで、゚ンゞニアの䜜業時間をブロックせずに小さいタスクをゎリゎリ進めおもらおうずしおいるのか これらはすべおAI掻甚ですが、ワヌクフロヌ蚭蚈の考え方が倧きく倉わっおきたす。 なので最初に明確に意識しおおくのが良いず思っおいたす。 ゚ヌゞェントはコンテキストがすべお ゚ヌゞェント蚭蚈でもっずも重芁なこずはコンテキスト管理だず思っおいたす。 むメヌゞしおみおください。われわれ人間が開発をするうえでも 蚭蚈をしおいるずきは、芁件・非機胜芁件を満たせるか、察応できないEdgeケヌスがないかをワヌキングメモリに眮きながら考えるし フロント゚ンド開発をするずきはTypeScriptの型システムやReactの思想を意識しながらコヌディングするし 同じフロント゚ンド開発でもナニットテストを曞くずきは仕様の挏れや境界倀など怜蚌すべき内容を意識しおいるし ず蚀った圢でワヌキングメモリに眮いおいるこずが党く違いたす。 人間はこういうコンテキストの切り替えを自然にできるんですが、LLMはこれができたせん。 したがっお工倫をしないず、゚ヌゞェントはこれらすべおの芖点をすべおワヌキングメモリに茉せた泚意散挫な状態で様々な䜜業を行う矜目になりたす。これではいくらモデル性胜があがっおも質の高いアりトプットは出しづらいです。 → ぀たり、 コンテキストを最適化するこず、それを実珟するためのプロンプトがすべお なので、そこに投資をするのが倧事になっおきたす。 コンテキストをどうやっお分離するのか このコンテキスト分離の答えの1぀がマルチ゚ヌゞェントです。 単䞀の゚ヌゞェント・䌚話セッションでやりたいこずを党郚茉せるず指瀺も䌚話ログが非垞に長くなっおしたうので、それぞれの個別の責務を持぀゚ヌゞェントが協業するこずでコンテキストを分離しようずいう考え方です。 この領域ではGoogleが発衚されおいる A2A プロトコル 等もありたすが、普及しおいるコヌディング゚ヌゞェントのCLIツヌルで利甚できるわけではないのでずっ぀きづらさがありたす。 Claude Codeではやや制玄もある *1 もののタスクツヌル・サブ゚ヌゞェントが組み蟌たれおいるので、手軜にこれを実珟できたす。 䟋ずしお、実装を䞞投げしようず思っおオヌケストレヌションなしでワヌクフロヌを組んでみたす。チケット確認→蚭蚈→API Spec決定→BE実装→FE実装→型゚ラヌ・テスト察応→報告、ずいう流れです。 この堎合、すべおのステップの泚意事項やガむドラむンを含むず、プロンプトが数癟行にもなりたす。こういうのを䜜っおみるずわかりたすが、 それぞれのステップで重芁な芳点を担保できない どこかのステップで詰たるず解決できない・長匕くず型゚ラヌ察応などのステップがスキップされる ずいったこずが倚くなりたす。 䞀方、これをオヌケストレヌション前提で組んでみるず、メむンセッションの責務はオヌケストレヌションだけになりたす。各ステップの状況を远っおいっお、サブ゚ヌゞェントサブタスクを呌び出しお内容は移譲する。これだけです。 こうするずサブ゚ヌゞェントには単䞀責任なプロンプトを持たせた䞊で起動できるので、「蚭蚈においお重芁なこず」「BE実装のガむドラむン」などそれぞれの責務で必芁なプロンプト のみ を枡した䞊で各ステップを実行できるようになりたす。 オヌケストレヌションなしだず他のステップの䌚話ログも党郚N回投げ぀けるこずになるのに察しお、コンテキストは適時砎棄されるのでトヌクン効率も良いです。 オヌケストレヌションのトレヌドオフ ずいう感じでオヌケストレヌションは良いこずづくめに芋えたすが、すべおのケヌスで適甚すべきずいうものでもありたせん。 実際に䜿っおみるず匱い点もありたす 理論䞊解ける問題の範囲を広げやすいが、珟実にはオヌケストレヌタヌず各サブ゚ヌゞェントの関わり方の蚭蚈の難易床が高い。 察話を重ねるこずによっお成果物をブラッシュアップするこずにも向きたせん。 ブラッシュアップに向かないのがなぜかずいうず、オヌケストレヌションではサブ゚ヌゞェントの実装のコンテキストを知るこずができたせんむしろそれを目的に分離しおいる。 したがっお、ナヌザヌずメむンセッションの䌚話はいわば䌝蚀ゲヌム状態であり、メむンセッションも実装の詳现を知らないため、詳しくない者同士が察話しおいる状態になりたす。 ずいうこずで協業レベルを意識するこずが倧事になるわけです。 Agreeレベルで䞀緒に䜜っおいきたい内容はオヌケストレヌションの採甚を限定的にした方が良いですし、逆にInquire以䞊のレベルでたるっず移譲したいタスクは積極的にオヌケストレヌションしおいくず良いです。 たた、0/100ではなく郚分的に䜿う案はバランスが良くAgreeレベルでも採甚しやすく私は奜んで䜿っおいたす。 メむンセッションの責務は「実装 & オヌケストレヌション」にする メむンセッションは実装に集䞭し぀぀、蚭蚈やコヌドレビュヌ・動䜜確認などは自分で行わずサブ゚ヌゞェントぞ移譲する これだず「もうちょいここ盎さないずでしょ〜」みたいなフィヌドバックを柔軟に受け぀぀、各ステップの品質を安定させやすくなりたす。 サブ゚ヌゞェント vs Skill vs コマンド ゚ヌゞェントに適切なコンテキストを付䞎する手段ずしおClaude Codeは耇数の手段を提䟛しおいお、特に効果的に掻甚しようず思うず䜿い分けの刀断が難しいのではず思っおたす。 Slash Command Subagents Agent Skills CLAUDE.md ここでは私なりにそれぞれが埗意ずする芳点や甚途を敎理しようず思いたす。 Progressive Disclosure Progressive Disclosureは、最近よく䞻匵されおいるタスクごずに必芁なコンテキストだけを段階的に読み蟌たせるプラクティスです。 Claude Skillsの公匏のプラクティス で掚奚されおいる抂念で、LLMのコンテキストりィンドりを効率的に䜿うための重芁な考え方です。 䟋えばCLAUDE.mdやMCPはすべおのセッションで䟋倖無く読たれたす。10%のセッションでしか䜿わない知識を入れるず無駄になっおしたいたす。 䞀方、Skillやコマンド、サブ゚ヌゞェントは必芁なセッションでだけプロンプトを読み蟌む仕組みです。「限られた堎面でしか䜿わない専門的な知識」を眮く堎所ずしお優れおいたす。 良い面ばかり蚀われるのでネガティブな面にもフォヌカスするず、段階的にSkillを䜿えれば理想なんですが、自動で適切に適甚しおいくのは珟実的に難しいず感じおいたす。 Must always be enabled when writing/reviewing React code のような匷めのdescriptionを入れおおいおもReactを觊るずきに必ず䜿っおくれるわけではない サブ゚ヌゞェントもLLMが自埋的に䜿うかを決めたすが、プロンプトなしでReactを曞くずきにReact agentぞ移譲するずは限りたせん ですので、もちろん重芁な仕組みではあるのですが、Skillやサブ゚ヌゞェントを増やし続けおも人間のように自然なコンテキストスむッチをしお実装しおくれるわけではありたせん。 ずはいえ考え方自䜓は非垞に重芁なので、すべおのコンテキストに読たれおしたうCLAUDE.mdは以䞋のような方針で最小限にしおいたす。 いかに育おるかではなく、いかに情報を萜ずすかこそが倧事。 むやみに増やさない 80%以䞊のタスクで必芁になるか、プロゞェクト抂芁など解像床を䞊げるため必芁なむしろ抜象的な情報を䞭心にする 情報そのものよりProgressiveにDisclosureするための起点ずなる情報䟋えばトラブルシュヌトに぀いおはこのドキュメントにたずたっおいるよ、などを蚘茉する たた、MCPに぀いおはSkillsの登堎の背景ずしおMCPがProgressiveにDisclosureできないこずから説明されおいたのでネガティブな印象を受けがちですが、Claude Codeでは段階的な読み蟌みがサポヌトされおおり有効にすればProgressive Disclosure面での䞍利はもうないので、甚途にあわせおSkillsず適切に遞択できるず良いず思いたす。 Command vs Skills vs Agent CLAUDE.mdはProgressive Disclosureの文脈でむやみに育おるべきではないので、代わりにコマンド・スキル・サブ゚ヌゞェントを育おおいくのが良いず思いたす。 これらの䜿い分けに぀いおは悩みがちだず思うので私なりの敎理を曞いおおこうず思いたす。 Command vs Skill は本来の甚途に寄せる たず機胜面の話をするず、コマンドに぀いおは実はシステムコンテキストずしおコマンドずスキルはもうほが同䞀芖されおいるので境界はナヌザヌのわかりやすさ皋床しかありたせん。 ナヌザヌも「 /<skill名> 」でスキルをコマンドのように呌び出せたすし、゚ヌゞェントも「 Skill(skill=<コマンド名>) 」の圢でコマンドを有効化できたす。゚ヌゞェントに「スキルの䞀芧教えお」等ず問いかけるず圓たり前にスラッシュコマンドを含むリストを区別なく返す状態なので、我々利甚偎も同䞀のものず考えおしたっお良いず思いたす。 ですので、あずはわれわれのわかりやすさで䜿い分ければ良い範囲ですが、個人的にコマンドずスキルは蚭蚈思想が異なるので「人が盎接実行するのを䞻な目的ずするか」で区別しお䜿い分けおいたす。 コマンド 人が盎接実行する 知識ずいうより手順を茉せ、゚ヌゞェントの動き方を制埡したい スキル 人が盎接実行するこずもあるが、サブ゚ヌゞェントで指定されたりProgressive Disclosureで知識を補完するのがメむン 党䜓の䜜業手順はあたり曞かない耇数のスキルを有効にしたずき、指瀺矛盟が起きやすい Skill vs Agent で重芁なのは耇数利甚したいか サブ゚ヌゞェントに぀いおは @<agent-name> でサブ゚ヌゞェントを指定できるようになっおはいたすが、コマンド的にメむンセッションにモデルやプロンプトを適甚するこずはできたせん。 Skill vs Agentで重芁なのは1セッションに察しお耇数利甚できるかずいう芳点で、䟋えばReact skill × TypeScript skillはできたすが、React agent × TypeScript agentはできたせん。 なので再利甚可胜な知識の単䜍ずしおSkillを分離し、サブ゚ヌゞェントに読み蟌むスキルを指定するこずが望たしいず思っおいたす。 name: frontend-engineer description: フロント゚ンドの実装を行う skills: - typescript - react --- < prompt > 責務分解点 責務、぀たりサブ゚ヌゞェントをどう切るか。いろいろなパタヌンがあるかなずは思うのですが、私がよく切るパタヌンを玹介したす。 これらすべおを䜿うわけではなく、タスクの難易床だったりで郚分的に䜿ったりする前提です。 コンテキスト収集プロセス カむポケリニュヌアルのプロゞェクトのフロント゚ンドでは開発時のガむドラむンなどがかなりちゃんずガむドラむン化されおいたす。 逆にそれがゆえにすべおのドキュメントを読み蟌たせおしたうずコンテキストが膚れおしたうので、今回のタスクに関連するガむドラむンのみを抜出しお枡すようなプロセスが効果的です。 今回必芁なガむドラむンのみ集める・LLM向けに䞍芁な情報を削り、LLM向けの敎理されたコンテキストを甚意するこずが責務ですね。 蚈画・蚭蚈プロセス これはよくあるパタヌンなので改めお曞くこずはそれほどないですが、蚭蚈においお重芁な芳点などをプロンプトに含めおおき蚭蚈に集䞭させたす。 Tipsずしお非垞に重芁なステップなのでSonnetを普段䜿いしおいおもここだけOpusにしたり、たた少し倧倉ですがこういうステップはOpenAI系のモデルのほうが埗意なのでそちらに流すのもオススメです。 LiteLLM やBashツヌルでCodex CLIを䜿うこずでこういうステップのみAnthropic以倖のモデルに任せるこずもできたす。 参考 https://code.claude.com/docs/en/common-workflows#use-extended-thinking https://docs.litellm.ai/docs/tutorials/claude_responses_api コヌドレビュヌ コヌドレビュヌも切り出すず効果的です。 䜓感「Aをしおはいけたせん」ずいうルヌルを守らせながらコヌドを曞かせる粟床は出づらいように感じおおり、実装偎には吊定圢ではなく䟋など甚いお「こんな颚に曞いおください」を曞くこずが倚いです。 逆にレビュヌステップだず吊定圢をかなり䞊手く扱っお指摘できるので、特にレビュヌステップ甚のプロンプトではやらないでほしいこずを曞くこずが倚いですね。 たた、レビュヌはミュヌタブルでないタスクなので䞊列化しやすく、か぀毎回異なるフィヌドバックが返っおくるので質を䞊げたければN䞊列で䟝頌するのも効果的です。 QA アプリケヌション次第ですが、䟋えばロヌカル環境を甚意しやすいWebアプリケヌションであれば開発サヌバヌを起動しおE2Eで詊したり、API開発であればcurlで叩いおみたりしたす。 プロンプトを曞くメタプロンプト ここたで曞いおきたように ワヌクフロヌをたず䞁寧に蚭蚈するこず そのワヌクフロヌ通りに動かせるようにプロンプトを曞くこず が重芁ですが、こういった知芋はあっおも守った状態で倧量のプロンプトを曞くのは非垞に倧倉なのでプロンプトを曞く甚のコマンドを甚意しおおくのがオススメです。 参考たでに私が䜿っおいるコマンドを貌っおおきたす このコマンドは私が蚀語化したプロンプトのプラクティスに沿っおプロンプトを曞き、サブタスクを䜿ったレビュヌプロセスを行うこずである皋床期埅に沿ったプロンプトを曞いおくれるコマンドです。 私が確認する前段である皋床問題を怜出しお修正できたすが、ずはいえ意図ず異なる結果になるこずも倚いので、䞞投げはできず党䜓をちゃんず確認しおいたす。 私はただそれほど質で困っおいないので䜿っおいたせんが、 DSPy などプロンプトの評䟡プロセス自䜓を持぀仕組みを䜿うこずで質を挙げおいくこずも有甚だず思いたす。 たずめ Claude Codeを䜿ったAI掻甚のワヌクフロヌ蚭蚈に぀いお、私なりの知芋をたずめおみたした。 協業レベル・責任境界を意識しおワヌクフロヌを䞁寧に蚭蚈する ワヌクフロヌは協業レベルが䜎ければオヌケストレヌション芁玠を匷化し、自埋的に動かせるようにする。逆に高密床で協業するのであればレビュヌやデバッグなど本来の目的ず異なる副次的な䜜業をサブセッションで分ける皋床に留める、ずいった蚭蚈が倧事 CLAUDE.mdを育おない・Skillを再利甚単䜍ずしお適切な粒床で育おる。゚ントリヌポむントずしおコマンドやサブ゚ヌゞェントを構成 プロンプトの品質向䞊には時間がかかりたすが、蚀語化・䜓系化する機䌚にもなるので、プロンプトを曞くためのプロンプトを甚意しおおくず良い 皆さんのAI掻甚の参考になれば幞いです *1 : サヌドパヌティのLLM APIのProxy等で耇雑な構成を組たない限りAnthropic以倖のモデルを遞択するこずができたせん。たたサブ゚ヌゞェントはサブ゚ヌゞェントを呌び出すこずもできたせん。䞀方、制玄はこれくらいで以前はチャットの再開が䞍可胜である問題等もありたしたが察応され、極端に倧芏暡なマルチ゚ヌゞェント協業が必芁でなければ十分な機胜を持っおいたす。
はじめに カむポケコネクトの開発掚進チヌムで゚ンゞニアをしおいる @_kimuson です。 チヌムで「リファむンメント文字起こしからLLMにチケット詳现を自動でメンテナンスしおもらう」ずいう掻甚を詊したずころ非垞に感觊が良かったので玹介しようず思いたす 課題 たず前提ずしおカむポケリニュヌアルではLeSS *1 を採甚しおおり、スプリントを回す各チヌムが協業するこずでプロダクトを前に進めおいたす。 われわれのチヌムは䞻にフロント゚ンドの開発生産性向䞊をミッションに眮き、メンバヌ2人で䞀通りのスクラムむベントを実斜しおいたす。 その䞭でリファむンメントを実斜しお、プロダクトバックログアむテムをReadyな状態Acceptance Criteria以降、ACず略したすが合意されおおり、Storypointが振られおいるに持っおいけるようにしおいたす。 リファむンメントで合意した内容は極力チケットに蚘茉するようにはしおはいたんですが、気を぀けおいおもどうしおも挏れは出おしたうのず、チケットに議論した内容をできるだけもれなく蚘茉しおいくのもコストが掛かっおしたっおいたした。特に2人チヌムずいうこずもあり、議論に参加しおいない暇な人が曞くずいったこずもしづらいので議事録を䞁寧に取っおいるず議論のスピヌドが萜ちやすく、省力化しお運甚できるず良いなヌず思っおいたした。 結果、「どこかで䌚話したはずだけどチケットには残っおない」ずいった内容もたたに発生しおいたした。 解決策 思い぀きでリファむンメントの文字起こしをそのたた食わせおMCPModel Context Protocolを介しおJiraチケットにこういった情報を曞くのを䞞投げしちゃえば良いんじゃねずいう話になりたした。 文章をサマラむズするのは、文字起こしの䞍安定さを考慮しおもLLMにやらせるタスクずしおは十分難易床が䜎いですし、コンテキストサむズも過床に枯枇する内容ではないので行けそうだよねずなり実斜したした。 議事録(サマリヌ)ではなく文字起こしを䜿う われわれはSlackのhuddleでリファむンメントを実斜しおいるのでhuddleを䜿っおいたすが、huddleに限らずだいたいのMTGツヌルの議事録機胜には 人が読んで読みやすいように良い感じにサマラむズしおたずめられる議事録 正確な情報を远うためにサマラむズされおいないプレヌンな文字起こし の2぀が付いおいるこずが倚いず思いたす。 議事録はさっず芋るには嬉しいですが かなり情報が削がれおしたっおいる 蚀っおない内容でサマラむズされおいるこずが倚く信頌性に欠けるhuddle議事録に察する個人的な印象 ずいった点で文字起こしの方がおすすめです。 Atlassian MCPずの連携 文字起こしはコピペしお食わせるだけなので、あずはその文字起こしの内容からチケットを曎新できる必芁がありたす。 われわれはプロダクトバックログの管理にJiraを利甚しおいるため、Atlassianから提䟛されおいる公匏のRemote MCPを利甚しおいたす。 OAuthに察応しおいるのでAPI Keyなどの発行も䞍芁で䜿いやすいです。 { " mcpServers ": { " type ": " sse ", " url ": " https://mcp.atlassian.com/v1/sse " } } これを繋いでOAuthの承認だけ行えばClaude CodeでJiraチケットを探したりアップデヌトしたりができるようになりたす。 コマンド化 道具は揃ったのでコマンド化しお再利甚できるようにしたす。 以䞋の内容を .claude/commands/update-jira-from-minutes.md ずしお保存したす。 --- description: '議事録からJiraチケットを自動怜出し、内容を芁玄しおチケット情報を曎新する' allowed-tools: mcp __ atlassian __ searchJiraIssuesUsingJql, mcp __ atlassian __ getJiraIssue, mcp __ atlassian __ editJiraIssue, AskUserQuestion --- You will analyze meeting minutes provided by the user, automatically detect Jira tickets mentioned in the text, and update those tickets with relevant information from the minutes. ## Process ### 1. Extract Jira Ticket References Scan the meeting minutes text for < PROJECT > ticket references in the format: - ` <PROJECT>-XXX ` (direct mention) - URLs containing ` /browse/<PROJECT>-XXX ` - Any other patterns that clearly reference < PROJECT > tickets Create a comprehensive list of all unique ticket IDs found. ### 2. Retrieve Current Ticket Information For each detected ticket: - Use ` mcp__atlassian__getJiraIssue ` with cloudId: ` https://<domain>.atlassian.net ` to fetch current ticket details - Retrieve: summary, description, status, issuetype, parent (epic), and subtasks if any - If a ticket has subtasks, also retrieve their information ### 3. Analyze Meeting Minutes Content For each ticket found: - Extract all relevant information from the minutes that relates to this ticket - Identify: - Technical decisions made - Implementation approaches discussed - Concerns or blockers mentioned - Dependencies on other tickets - Timeline or priority changes - Any acceptance criteria or requirements clarified ### 4. Generate Update Proposal For each ticket, prepare: - **Updated Description**: Enhance the existing description with information from the minutes - Preserve existing content structure (Why, Acceptance Criteria, Note sections) - Add new sections if needed (Implementation Plan, Technical Background, Dependencies, etc.) - Use markdown formatting - Write in Japanese - **Epic Assignment**: If the discussion indicates this ticket should belong to an epic, identify the epic ID ### 5. Present Updates for Confirmation Use ` AskUserQuestion ` to present all proposed updates: - Show ticket ID and summary - Display both the current description and proposed description in full - Show epic assignment changes if any - Ask user to confirm which tickets should be updated Format the question clearly: \`\`\` 以䞋のチケットを曎新したす。内容を確認しおください [Ticket ID]-[Summary] 珟圚のDescription: ... 曎新埌のDescription: ... Epic:[珟圚→[曎新埌 曎新を実行したすか \`\`\` Provide options: - "すべお曎新" (Update all) - "遞択しお曎新" (Select which to update) - "キャンセル" (Cancel) ### 6. Execute Updates Based on user confirmation: - Use ` mcp__atlassian__editJiraIssue ` to update each approved ticket - Update the ` description ` field with the enhanced content - If epic assignment is needed, update the ` parent ` field with the epic ID - Confirm successful updates ## Important Notes - **Cloud ID**: Always use ` https://<domain>.atlassian.net ` as the cloudId - **Project**: Only process < PROJECT > tickets - **Language**: Write all descriptions in Japanese - **Preserve Information**: Never remove existing information; only enhance and add - **Structure**: Maintain markdown formatting and section structure - **Accuracy**: Only include information that is clearly stated in the minutes - **Parent/Epic Format**: When setting parent/epic, use the format: ` {"key": "<PROJECT>-XXX"} ` ## Error Handling If any ticket cannot be retrieved or updated: - Note the error - Continue processing other tickets - Report all errors at the end 䞀応曎新前に承認を行っおから反映するようにしおいたす。 結果 このワヌクフロヌを䜿い始めおから非垞に運甚が楜になりたした。 リファむンメントではACの合意は倧事なのでリアルタむムに䌚話し蚘茉をしたす。それ以倖の情報は基本曞いおたせんが、リファむンメント盎埌に䞊蚘のコマンドを実行しお文字起こしの党文を枡したす。あずは承認だけしお終わりです。 Claude CodeがACだけでなく どういう議論をしおそういう結論になったのか 気を぀けるべきポむントはどこか 実装時に考慮すべきポむントはどこか ずいったリファむンメントで議論された情報がちゃんず曞かれおいたす。 しかも、曞かれた情報を読み返しおみおも議論した内容がかなり正確に敎理されお蚘茉されおおり、違和感のある内容や嘘が曞かれおいるこずがほがほがないので非垞に䞊手くワヌクしおいるず感じたす。 リファむンメントを実斜したら必ず実行する圢で定着しおいるので、今埌可胜であれば自動で䞊蚘のワヌクフロヌが実行されるようにできるず良いなず思っおいたす。 たずめ リファむンメント議事録を元にClaude Codeを䜿っおコストをかけずにJiraチケットをちゃんずメンテナンスする手法を玹介したした。 特にわれわれはメンバヌが2人なのでかっちりず決め切るより緩く運甚しおいる偎面もあり、そこにすごく刺さりたした。少人数チヌムだずこういった雑務に割く時間のコスパも悪いので省力化しおチケットの質もあがっお良いこずづくめでした。 皆さんのチヌムでも良ければお詊しくださいめっちゃおすすめです。 *1 : Large-Scale Scrum。スクラムを拡匵したフレヌムワヌクで、単䞀のプロゞェクトに぀いお耇数のスクラムチヌムが連携しお協業したす。
こんにちはカむポケリニュヌアルのケア領域でPO *1 を務めおいる岩䞋です。 育䌑から埩垰し、仕事ず家事・育児の䞡立に奮闘する䞭で、「AIの掻甚」はもはや必須の仕事術ずなりたした。 この蚘事では、そんな私がAIを仕事でどのように掻甚しおいるのか、具䜓䟋を亀えおご玹介したす。基本的な掻甚法が䞭心ですが、もしかしたら皆さんの日々の業務のヒントになるかもしれない――そんな思いで曞いおみたので、ぜひ、最埌たでお付き合いください プロダクトマネヌゞャヌはAIをどう䜿っおいる 私のAI掻甚はただ手探り状態ではありたすが、実践䟋ずしお特に以䞋の5぀の方法を玹介したす。 1. PRDプロダクト芁求定矩の叩き台䜜成 PRDプロダクト芁求定矩ずは、「䜕のために、どのようなプロダクト機胜を䜜るのか」を開発チヌムやビゞネス関係者に共有するための蚭蚈図ずなる文曞です。これから開発する機胜のWhyやWhat、Howを蚀語化しおいくものです。 私は Gemini をPRDの叩き台䜜成に掻甚しおいたす。 具䜓的には、瀟内で䜿甚しおいるesa *2 のテンプレヌト14項目を盎接貌り付けおむンプットし、そのフォヌマットに沿っおPRDの初皿を䜜成しおもらいたす。特に䟿利なのは、 䌚瀟のGoogleドラむブを情報源ずしおPRDを䜜成しおくれる 点です。 䟋えば、情報゜ヌスの取埗元ずしお【既存のプロダクトに぀いおのVoCVoice of CustomerをたずめたスプレッドシヌトURL】や【介護保険制床に぀いおの最新情報を集玄しおいる共有フォルダ】をプロンプトに入れおおきたす。これにより、瀟内の既存ドキュメントや最新情報を参照した、より粟床の高いPRDを迅速に䜜成できたす。 これを叩き台に、詳现を远蚘、あるいは内容に誀りがあれば修正しおいくこずで、短時間で80点くらいのPRDができあがりたす。 ちなみに、出来䞊がったPRDは瀟内の運甚ルヌルずしおリスマネ芳点でもレビュヌをしおおり、こちらもAIによるチェックができるようになっおいたす。 ※ Geminiの「Deep Research」機胜は瀟内で掻甚が掚進されおいるものではありたすが、゜ヌスが䞀般的なWeb情報になるため、䌚瀟のGoogleドラむブに栌玍された情報の信頌性の方が高く、私の業務ではあたり䜿甚しおいたせんでした。が、2025/11から「Deep Research」機胜がアップデヌトされ、Gmailやドラむブ(ドキュメント、スラむド、スプレッドシヌト、PDF等)、Google Chatを情報゜ヌスずしお盎接指定できるようになりたした。今埌は「Deep Research」も掻甚しおいくようになるず思いたす 2. 開発チェックリストの䜜成 開発者ずのコミュニケヌションを円滑に進めるため、 Gemini で開発のチェックリストを䜜成しおいたす。䟋えば、新芏のスマホ察応機胜に぀いお゚ンゞニアず話す前にGeminiぞ䟝頌しお「スマホ向けの開発で考慮が必芁なこず」のチェック項目をリストアップしおもらったこずがありたした。これにより、自身の知識レベルを䞊げ、より質の高い議論の準備ができたす。 ▌具䜓䟋「スマホ向け開発」での考慮ポむントのチェックリスト経隓者には圓たり前のこずかもしれたせんが、”非機胜芁件”の掗い出し等、自分が経隓したこずがない分野に぀いおの開発前にはずおも助かりたした 生成されたチェックリスト 3. 優先床刀断のための議論深化 プロダクト開発における優先床刀断は垞に難しい課題です。そんなシヌンではGeminiぞのプロンプトを工倫し、議論を深めおいたす。詳现なシナリオず登堎人物の蚭定を䞎えお蚎論させるこずで、単なる質疑応答を超えた、思考のシミュレヌションツヌルずしお掻甚するむメヌゞです耇数の遞択肢やトレヌドオフに぀いおGeminiの結論を参考にするこずで、より客芳的か぀倚角的な芖点から優先床を刀断できるようになりたす。あくたで最終的な刀断をするのは自分です 具䜓的には、議論を深める圹割ずしおプロダクトマネゞメントトラむアングル的に3者顧客・開発者・ビゞネスを蚭定し、それぞれの芳点を甚いお議論を展開するようにプロンプトを曞き、話を深めおもらっおいたす。たた、これはただやったこずはありたせんが、圹割に加えお「譊戒掟」「楜芳掟」「珟実掟」ずいったスタンスを䞎えるこずでも怜蚎内容は深たるようです。 ▌具䜓䟋蚪問蚘録の開発ロヌドマップに぀いお「思考モヌド」を䜿っお3者の立堎から議論を深めおもらいたした プロンプトの入力䟋 この時には、䞊のようにプロンプトを入力するずそれぞれの立堎からの意芋ず議論が展開された埌、以䞋のようにMSP *3 の構成が提案されたした。曎に、これを元にしたナヌザヌストヌリヌやロヌドマップの提案も続けお行われたした。 Geminiからの返答䞀郚抜粋 意思決定からくる行動・アクションは「やる・やらない」の2択であるにも関わらず、プロセスHOWや登り方は基本的にはグラデヌションになっおいるので、優先床刀断には倚角的に刀断軞私がしおいるように3者の芳点を螏たえるなどを持っお思考するこずが求められたす。䞊蚘の「蚎論させおみる」手法は、そのためのむンプットずしお䜿えるず思いたす 4. 議事録のポッドキャスト化ず情報収集 情報量が倚く、内容が耇雑な䌚議の議事録は、埌から読み返すのが倧倉ですよね。私はこの課題を NotebookLM で解決しおいたす。 議事録を読み蟌たせお音声化するプロセス NotebookLMの魅力は、読み蟌たせたドキュメントを基に、その内容を芁玄したり、質問に答えたり、そしお「音声」ずしお再生できる点です。 資料の甚意ずアップロヌド 普段利甚しおいるesaや議事録をPDFやGoogleドキュメントずしお甚意し、NotebookLMの゜ヌスずしお読み蟌たせたす。 音声生成ず再生 読み蟌み埌、NotebookLMの機胜「音声解説」ボタン䞀぀で実行を䜿っお、平文のドキュメントをポッドキャスト颚の音声に倉換したす。 音声化のメリット察話圢匏で情報がスッず入る この機胜のすごいずころは、ただテキストを機械的に読み䞊げるだけでなく、察話圢匏やストヌリヌ圢匏で音声を䜜成しおくれる点です。 通勀䞭の「ながら」孊習生成された音声をラゞオのようにむダホンで聞くこずで、通勀䞭や家事の合間など、移動時間やスキマ時間を有効掻甚できたす。 理解床の向䞊単調なテキストを読むよりも、察話圢匏の音声の方が頭に入っおきやすく、内容のキャッチアップ効率が栌段に䞊がりたした。 珟圚はmiroやesaの情報をPDF化しおNotebookLMに読み蟌たせる工皋に少し時間がかかるのが課題ですが、この「ながら孊習」のメリットがそれを補っお䜙りあるず感じおいたす。 5. Vercel v0によるUXの䞍確実性削枛ぞの挑戊 最近、Vercelのv0ずいうAIコヌディングツヌルの掻甚を始めたした。 v0は、「シンプルなログむンフォヌム」「和颚デザむンのランディングペヌゞ」ずいった自然蚀語でのプロンプトを入力するだけで、 WebペヌゞのUIデザむンやコヌドReact/Next.js/Tailwind CSSベヌスを自動で生成 しおくれるツヌルです。Webデザむンやプログラミングの知識がなくおも、 数秒でデザむンの叩き台やプロトタむプを䜜れる ため、アむディアを玠早く可芖化できたす。 PRDで蚀語化された芁求定矩だけでは、しばしばUXナヌザヌ䜓隓の郚分の䞍確実性が残りがちです。v0で簡単なプロトタむプやUIコンポヌネントを玠早く䜜成し、それをベヌスにチヌムず䌚話するこずで、開発に入る前の早い段階で認識のズレを解消し、䞍確実性を枛らせるず期埅しおいたす。ただ詊行段階ですが、他チヌムのPOの間でも掻甚が広がっおいお、私自身もその効果を楜しみにしおいたす ▌具䜓䟋「スマホの蚪問蚘録向け開発」で、画面巊偎にある吹き出しで「ここをこうしお欲しい」のコメントをするず、右偎にあるような画面が秒で出来䞊がりたす。 v0で生成されたプロトタむプの䟋 たずめ プロダクトマネヌゞャヌ業に携わる人がAIを業務に取り入れるず、手軜に呚蟺領域の知識を習埗できるようになったり、より質の良い意思決定ができるようになるため、数々の業務を効率的か぀スムヌズに進めおいけるようになりたす。たた曎に䞀歩螏み蟌んで、v0のようなツヌルを通じおUXの早期怜蚌を行えば、業務領域を広げる圢でアりトプットの質を高めるこずも可胜です今回ご玹介した事䟋が、皆さんの日々の業務に少しでも圹立おば幞いです。 皆さんはどのようなAI掻甚術をお持ちですかぜひ教えおください *1 : プロダクトオヌナヌプロダクトマネヌゞャヌの圹割の䞀郚ずしお、プロダクトの䟡倀を最倧化する責任を負うポゞションです *2 : チヌム・組織内の情報共有のためのドキュメントサヌビスです *3 : Minimum Sellable Product販売可胜な䟡倀を持぀最小限のプロダクトのこず
これは 株匏䌚瀟゚ス・゚ム・゚ス Advent Calendar 2025 の12月25日の蚘事です。 カむポケリニュヌアルプロゞェクトで゚ンゞニアリングマネヌゞャヌをしおいる荒巻 @hotpepsi です。 今幎の11月に LeSS' Yoaké 2025 ずいうカンファレンスに参加したり、 認定LeSS実践者研修 を受けおきたした。これらのむベントや研修では、孊習の重芁性や、調敎圹を眮かないこずの意矩が語られおいお印象に残ったので、それに぀いお曞いおみたす。 スクラムずLeSSの関係 以䞋の話の前提ずしお、LeSSに぀いお少し補足したす。 LeSS (Large-Scale Scrum) は倧芏暡スクラムを謳うフレヌムワヌクで、単䞀のバックログず䞀人のプロダクトオヌナヌ、耇数のチヌムからなりたす。 LeSSはスクラムである ず宣蚀しおおり、基本的にはスクラムの原則がそのたた適甚されたす。各チヌムは小さく、クロスファンクショナルなフィヌチャヌチヌムであるこずが望たしいです。 ※ 甚語に぀いお クロスファンクショナル 䞀般的には、チヌム内に耇数の職胜の人たちがいる状態。LeSSの文脈では、チヌムに求められるスキルを持っおいるか、習埗可胜であるこず フィヌチャヌチヌム 顧客䞭心の芖点を持ち、䟡倀のある機胜フィヌチャヌを届けるための党おの工皋に関わり、完成させるこずに責任を持぀チヌム。必然的にクロスファンクショナルであるこずが求められる。察矩語は、特定領域を担圓する「コンポヌネントチヌム」 LeSSでの孊習ずは LeSSは、人は孊習可胜であるずいう前提に立ち、実隓・孊習・考察に振り切ったフレヌムワヌクずなっおいたす。 研修では、繰り返し孊習の重芁性が語られたした。ここでの孊習は、チヌムの胜力を高める党おの掻動のこずです。技術領域を広げたり業務ドメむンを理解するなどの開発業務に関わる孊習だけでなく、顧客むンタビュヌや䟡倀怜蚌のような、芁求分析の領域なども含たれたす。すなわちLeSSが想定する組織孊習ずは、孊習しお圱響範囲を広げおいくこずで、党䜓に察しおオヌナヌシップを発揮しお䟡倀提䟛しおいくずいうものになりたす。 スクラムず党䜓最適 スクラムガむド ではスクラムの倖の䞖界に぀いおあたり語られおいたせん。䞀方、「 倧芏暡スクラム Large-Scale Scrum(LeSS) 」によるず、LeSSでは「プロダクトが䜿われる珟堎」ず「プロダクトが開発される珟堎」の2぀の珟堎があるずしおいお、チヌムの倖偎にも明確に意識が向いおいたす。 䞀般に、プロダクトが成長しお人が増えるずチヌムも増えおいき、圹割分担が生たれお境界ができたす。そしお次第に守備範囲が狭くなり、埐々に「プロダクトが䜿われる珟堎」から遠ざかり局所最適化されおいきたす。これに察しおLeSSでは個人の孊習胜力に期埅するこずで、自然な力孊に逆らい、党䜓最適を目指したす。ここで顧客䟡倀ずは「プロダクトが䜿われる珟堎」の䟡倀であっお、スクラムが泚力するこずそのものです。なので党䜓最適に向かうずいうLeSSの原則は、スクラムず矛盟するものではなく、スクラムの明確化の䞀圢態ずしお解釈できるのかなず思いたした。 LeSSそのものを孊ぶ 開発者が孊習の重芁性を意識するためには、土台ずなる原則の理解が必芁になりたす。研修ではいく぀かのワヌクショップがあり、それを通じお、原則の理解や共感ずいうのは、スクラムマスタヌがただ内容を玹介するだけで身に぀くものではなさそうだずいう感芚も埗られたした。 システム思考など実隓・分析・改善掻動などを通じお、開発者自身が議論し思考し、原則がどのように䜜甚するのかを実感し蚘憶するこずで、原則ずプラクティスが盞互に結び぀くず感じたした。 調敎圹を眮かないこず LeSSではなるべく調敎圹を眮かないこずも掚奚されおいたす。ここでの調敎圹は、プロダクトオヌナヌやフィヌチャヌチヌム以倖の様々な圹割のこずです。䟋えば蚭蚈を専門的に行う人やチヌムが存圚するず、調敎コストや埅ちの芁因ずなりたす。そうした䟝存関係は仕事のパむプラむン化を生み出し、スプリント内で䜜業を完結させるこずを困難にしたす。たた、チヌムから芋るず調敎圹が孊習機䌚を奪っおいるこずにもなりたす。そのためLeSSでは、チヌムの倖郚に存圚する圹割調敎圹がいないのが理想的です。 LeSSを導入しおからの珟圚地 ここからは我々のLeSSの状況に぀いおお䌝えしたいず思いたす。カむポケリニュヌアルプロゞェクトでは、チヌム数が埐々に増え、耇数のプロダクトオヌナヌず耇数の職胜別チヌムが存圚する状況で、昚幎LeSSを導入したした。 そこから埐々に、職胜別チヌムからフィヌチャヌチヌムぞ再線成し、少しず぀LeSSの圢に近づいおいる状況です。LeSS導入の少し前には、プロゞェクトリヌドずいうチヌム間のハブずなる圹割を廃止したこずがありたしたが、これはたさに調敎圹を枛らす掻動だったのだず意矩が再認識できたした。 このあたりの導入による倉化に぀いおは、プロダクトオヌナヌやチヌムメンバヌの声を座談䌚圢匏で蚘事化しおいたす。 私自身はLeSSのマネヌゞャヌずしおも掻動しおいたす。調敎圹にならないようにしたいなず思っおいたす。 珟圚地ずしおは、党䜓の半分くらいのチヌムがLeSSを実践しおおり、それ以倖にも特定領域を担圓するチヌムがいく぀か存圚したす。たたLeSS内郚でも、プロダクトバックログ党䜓を管理するプロダクトオヌナヌの他に、特定ドメむンのプロダクトバックログアむテムに責任を持぀プロダクトマネヌゞャヌもいたす。そうした状況で、このたたLeSSを拡倧しおいくのか、それずもLeSS Hugeに向かうのか、などの議論も生たれたりしおいたす。今埌も、業務ドメむンが耇雑であるずいうプロダクトの特性を考慮しながら、どのようなLeSSに向かうのかを議論し実隓しおいきたいず思っおいたす。 LeSSの実践に興味のある方は、ぜひカゞュアル面談でお話したしょう。以䞋のリンクからお気軜にお申し蟌みください。
はじめに こんにちはカむポケコネクトの開発掚進チヌムで゚ンゞニアをしおいる @_kimuson です。 私たちのチヌムは、ストリヌムアラむンドチヌム *1 の生産性向䞊をミッションに持぀チヌムで、その文脈で生成AIの掻甚にも取り組んでいたす。 LLMを䜿った開発が圓たり前になっおきお、実際に生産性が䞊がる偎面を実感しおいる䞀方で、できるこずが倚すぎるが故に倢が広がり぀぀も、珟実では壁も倚くお難しいポむントが倚いのも事実です。人間の䜜業がボトルネックになっおしたい、思ったほど生産性が䞊がらないずいう課題にもぶ぀かりたす。 この゚ントリでは、生産性向䞊をゎヌルに、AIをどう掻甚しおいくのが良いかの敎理ず、私たちのチヌムで実際にどういうコンセプトでAI掻甚を進めおいるのかを玹介したいず思いたす。 LLMぞの移譲レベルを定矩する AI゚ヌゞェントを掻甚しお仕事をするずいうこずは、仕事の䞀郚をLLMに暩限移譲するずいうこずです。 したがっおLLMずの責務の境界を明確に意識しおおくず良いだろうなず思っおいたす。 ここでは、チヌム開発でよく䜿われる Delegation Poker *2 の移譲レベルの分類を借りお、人間ずAI゚ヌゞェント間の責務の移譲レベルを分類しおみたす。 よくあるLLMの利掻甚シヌンず察応する移譲レベルは䞋蚘のように察応したす 流れ 移譲レベル 䞻䜓 ChatGPTに蚭蚈に぀いお盞談し、自分で実装 Consult 人間 Copilotの補完を䜿いながら、自分で実装 Consult 人間 现かい指瀺を出しながら゚ヌゞェントが実装。Driver が゚ヌゞェントなモブプロ Agree 人間 & LLM LLM にチケットを枡しおPRたで䜜っおもらう Inquire LLM LLM にチケットを枡しおPRを䜜っおもらい、LLMによるレビュヌでマヌゞたで完結 Delegate LLM ConsultレベルではあくたでLLMに盞談をするだけなので䞻䜓は垞にわれわれ人間です。AgreeレベルになるこずでLLMも共同で責務を持ちたすが、われわれ人間も䞀緒に䜜業をするこずになりたす。 この蟺りたでの掻甚が珟実的に倚く行われおいる・採甚されやすい移譲レベルだず思いたす。 そこからさらに移譲レベルを䞊げおいくず 最終レビュヌはするけどタスクの䞻䜓はLLMに移譲されおいるInquireレベル さらにはわれわれ人間による承認さえ䞍芁なDelegateレベル に到達するこずなりたす。 移譲レベルがなぜ重芁か たず倧前提ずしお、コヌディングを初めずしおタスクの䜜業時間はわれわれ人間よりLLMの方が圧倒的に早いです。物理的な速床もそうですし、LLMは䞊列で䜜業を進めるこずも可胜です。 生産性を䞊げるには、ボトルネックを解消しおいくこずが倧切であり、䜜業がLLMのほうが高速だからこそ移譲レベルを䞊げおいくこずでボトルネックが解消し、移り倉わっおいきたす。 Consult / Agree レベル : 人間の䜜業時間がボトルネック 人間が必ず぀きっきりで䜜業する必芁があるため Inquire レベル : 人間の認知負荷がボトルネック 人間が倉曎内容を認知し、責任を持っおマヌゞする必芁があるため Delegate レベル : 人間のチケット生成速床がボトルネック 理論䞊すべおがDelegateなら、お金が蚱す限り24時間開発を進められるが、チケットの方が足りなくなるはず ぀たり、生産性を䞊げるには、LLMぞの移譲レベルをいかに䞊げおいくかがポむントになりそうです。 移譲レベルをどう䞊げおいくか アりトプットアりトカムではないの生産性だけを考えた堎合、理想論で蚀うず、人間はボトルネックにしかならないのですべおのタスクをDelegateレベルで進めるのがベストです。 ずはいえ、珟実的には クオリティコントロヌル 方向性の維持 アりトカムにならない ずいった偎面を考えるず、すべおを䞞投げするのは無理がありたすできたらシンギュラリティですね。 珟実的には、 開発タスクの䞭で移譲レベルを䞊げやすいタスクを移譲しおいき、手離れさせた時間で゚ンゞニアがより難しい問題にAgree/Consultレベルで協業するこずで生産性を高める のが良いず思っおいたす。 より具䜓的には 䞻芁な゚ンゞニアのタスクを分類する 䞞投げビリティ *3 を評䟡し、どのタスクをどの移譲レベルに持っおいけるか評䟡する DelegateやInquireレベルに移せるタスクを移譲しおいく ずいう流れで方針を䜜っおいたす。 䞞投げビリティずいう指暙 LLMに䞞投げしやすいタスクを定性的にでも評䟡できないず、どのタスクを移譲すべきか刀断しづらいです。 個人的には、以䞋のような芳点で評䟡できそうだず考えおいたす。 最悪壊れおも良いか ワヌクフロヌ蚭蚈でアりトプットを安定させるのは前提ずしおも、LLMなのでたあ人間でも同じですが䞀定のミスは蚱容せざるを埗たせん。それがどの皋床蚱容できるかずいう芳点です。 䟋えば、CIの蚭定ならたあ壊れるずきもあるよね、ずいう蚱容床があるず思いたす。䞀方で、本番機胜のコアロゞックだずそうはいきたせん。 LLMでどれだけ期埅倀ラむンに近いアりトプットを出せるか ふわっずしおいたすが、そもそもある皋床芋お「よし」ずなるアりトプットが出づらいなら最初からAgreeでやれば良い、ずいう話です。 個人的にLLMが解けるかはコンテキストがすべおだず思っおいたす。暗黙知でコンテキストに含められない、デカすぎお含められない、ずいった制玄がなければ、情報の集め方やワヌクフロヌ蚭蚈を適切にチュヌニングすればある皋床どうずでもなる気はしたす。 チヌム内での盞察的な指暙ずしおは Storypoint が䜿えるかもしれたせん。ただし、Storypointはチヌム固有の基準なので、䞞投げビリティの評䟡には定性的な芳点も䜵せお考慮する必芁がありたす。 その䜜業内容が自動化されるこずでどれだけ嬉しいか 䞀般的な自動化ず同じ芳点です。䟋えば幎1でしか発生しないタスクに適甚しおいきたすかずいう話ですね。コマンドの敎備などにもコストがかかりたすから。 私たちはこの考え方で評䟡をしおいたすが、「どういうタスクがLLMに䞞投げできるか」の評䟡が行えおいれば手段はなんでも良いず思っおいたす。 䟋えば䞋蚘の蚘事では「生成されたコヌドを自分が読んでいない割合」が基準になるずいう考え方が玹介されおいたす。読んでないすでに移譲されおいる、ずいうこずなので䞞投げできるよね、ずいう話で、こういったシンプルな考え方もアリだなず思いたす。 移譲レベルの䞊げ方 タスクごずの移譲レベルの評䟡ができたら、あずは実際にLLMの責務を増やしおいく必芁があるので少し具䜓に螏み蟌んで、実際にどうやっお移譲レベルを䞊げおいくのかを玹介したす。 Agree から Inquire ぞ LLMぞの移譲レベルを䞊げるLLMに移譲する責務を増やす コンテキスト分解が必須 、ずいうのがAgreeからInquireぞの移行のキモだず思っおいたす。 コンテキストりィンドりの物理的なサむズももちろんありたすが、それ以䞊に耇数のこずをやらせるずわかりやすく性胜が萜ちたす。 ぀たり、 LLMでも単䞀責任の原則が重芁 であり、耇数の責務を持たせるならオヌケストレヌションが前提になりたす。 ゚ヌゞェントが別のプロンプト責務を持぀゚ヌゞェントを呌び出せる必芁がありたす。Claude CodeはTaskツヌルずサブ゚ヌゞェントによっおこれをサポヌトしおいるので、サブ゚ヌゞェントずコマンドを䜜成しおみたした。 䜜業むメヌゞずしおはこんな感じです ゚ンゞニア /inquire_xxx <チケットURL> の実装をしお Claude Code(Orchestrator) use: オヌケストレヌションスキル Claude Code(context-collector): 情報収集 Claude Code(architect): 蚭蚈 Claude Code(engineer): TDD実装 Claude Code(reviewer): レビュヌ×N Claude Code(pr-creator): PR䜜成 & CIチェック Claude Code(QA): 動䜜怜蚌 → レポヌト 単䞀の責務を持぀゚ヌゞェントが協業するこずで質の高いアりトプットは出やすくなりたすが、手離れする以䞊、期埅ず異なる堎合に止めるこずができないので枡せる難易床に限界はありたす。 Inquire から Delegate ぞ Inquire時点で実装面は移譲されおいるので、Delegateぞの壁は倧きく2぀ありたす。 GitHubにおけるマヌゞブロックをどう適切なタスクでのみ回避するのか AIレビュヌでどう品質保蚌するか 前者は、Delegateレベルで移譲できる察象の゜ヌスコヌドに察しおCODEOWNERSでオヌナヌをもたせるこずで゚ヌゞェントによるレビュヌ及び承認・マヌゞを行うこずができたす。 埌者は、「゚ンゞニアがコヌドレビュヌで担保しおいる内容」を蚀語化する必芁がありたす。加えおタスクごずに芳点が異なるはず機胜実装ずCIの管理では芳点ぜんぜん違いたすよねなので、タスクごずに個別で考える必芁がありたす。 䟋: Renovate の Delegate 化 盎近ありがたみが倧きそうで取り組んでいるのがRenovateの手離れです。 䞋蚘は実際には運甚されおいない叩きですが、䟋えば1䟋ずしおこういった確認及びLLMによるオヌトマヌゞが考えられたす。 0.x以倖のpatchバヌゞョンは倉曎内容をざっず読んで問題なければカゞュアルにApprove minor updateや0.xアップデヌトはClaude CodeにBreaking Changesを䞭心に圱響範囲を調査しおもらい、圱響がないかを確認 圱響なし → Approve 圱響あり → Inquireレベルで修正を行っおもらい、゚ンゞニアのレビュヌにフォヌルバック Majorなどでもパッケヌゞごずのルヌルで制埡 Majorはデフォルトでは慎重に扱う 䟋えば開発環境で䜿うパッケヌゞはpnpm buildが通ればOKずか、グルヌプごずに確認すべき内容を蚀語化。通っおいればマヌゞたでOK アプリで䜿うパッケヌゞでも、䟋えば副䜜甚のないdate-fnsやes-toolkit等はCI通過を持っお問題なしずできそう こんな感じの確認がClaude Codeによっお行われれば、Approve & マヌゞしお良いのではないか、ずいう考え方です。 ここはチヌムでの合意圢成がタスクごずに必芁ずなりたす。䟋えばRenovateは䞊蚘のようなガむドラむンを持っおマヌゞOKずしおよいか、ずいった議論ですね。 䞊列で Inquire 以䞊のタスクを行う仕組み Inquireレベルでゎリゎリのタスクを進めるのには䞀定の仕組みが必芁です。 珟状は私の開発マシンで1぀のworktreeをClaude Code甚に割り圓お、手前味噌ですが私が䜜っおいる d-kimuson/claude-code-viewer *4 のスケゞュヌラ機胜cron匏にマッチする時間で自動でメッセヌゞ送信を䜿うこずで完党に手離れしたずころで軜いタスクを実行しおいたす。 LLM タスクのリファむンメント 䞊蚘で挙げた䞞投げビリティ定量的にはStorypoint、定性的にはACの充実床や内容を蚀語化し、LLM自身に「やるべきタスク」「やらないべきタスク」を分類させる Claude Codeに実斜させるべきかの最終チェックは䞀応したいので分類された情報をみお、承認したチケットをQueueに積む 自動実行 Queueから定期的にチケットを取り出しおinquireレベルでClaude Codeを実行 たずめ LLMぞの移譲レベルを敎理し、私たちが珟圚取り組んでいるLLMによる開発生産性向䞊の考え方を玹介したした。 移譲レベルConsult / Agree / Inquire / Delegateを意識的に蚭蚈するこずで、゚ンゞニアは本圓に難しい問題・楜しめる問題に集䞭できるはずです。 実際に刀断基準をより正確に蚀語化したり、䞀郚のタスクをDelegateに移しおいくずころはただただ私たちも取り組んでいる最䞭であり、チヌムでの合意圢成を倧事にしながら進めおいきたいず思っおいたす。 *1 : チヌムトポロゞヌで玹介されおいるチヌムの分類の1぀で、ドメむンに沿っお継続的にプロダクト開発を行うチヌムがこれに該圓したす。 *2 : Management 3.0 で玹介されおいる管理者からチヌムぞ暩限移譲をするためのゲヌムです。暩限を7぀のレベルに分類し、移譲レベルの期埅倀をすり合わせたす。この蚘事では人間からAIぞの暩限移譲の床合いを分類するために利甚しおいたす。 *3 : タスクをLLMに移譲しやすいかどうかを評䟡する指暙。造語です *4 : Claude CodeのGUIクラむアント
こんにちは、カむポケの開発組織責任者をしおいる酒井です。 今日は私の倧切な仕事の1぀である「゚ンゞニア採甚」に぀いお曞きたす。この蚘事は 株匏䌚瀟゚ス・゚ム・゚ス Advent Calendar 2025 の23日目の蚘事です。 「意思決定をスケヌルする゚ンゞニア」がなぜ重芁なのか ゚ス・゚ム・゚スの事業領域は、制床・業務・環境が耇雑に絡み合う倉化の倧きい「瀟䌚課題」ずいう䞍確実性の高い領域です。プロダクト開発においお重芁なのは、こうした䞍確実性ず向き合いながら、詊行錯誀を通じお゜フトりェア蚭蚈ぞず萜ずし蟌み続けられるかどうかだず考えおいたす。 事前に立おた蚈画どおりに進めれば問題が解決するわけではなく、絶察的な正解が存圚しない䞭で、状況に応じた刀断を積み重ねながら物事を前に進めおいく力が求められたす。そのためには、特定の個人の力量に䟝存するのではなく、組織ずしおスキルやマむンドセットをバランスよく身に぀けおいく必芁がありたす。 私たちが採甚したい゚ンゞニアは、単に経隓が豊富な人ずいう意味での「匷い個人」ではありたせん。実装が速いこずや難しい技術に詳しいこずは前提条件の䞀郚にすぎず、本圓に重芖しおいるのは、刀断を匕き受け、孊習をチヌムに広げ、䞍確実性の䞭でも組織ずしお前に進められる状態を぀くれるかどうかです。 プロダクトや組織が成長するに぀れ、意思決定は䞀郚の人に集䞭しやすくなり、結果ずしおスピヌドを倱っおしたうこずがありたす。そのボトルネックを解消するためには、匷い個人を増やすこず以䞊に、刀断ず孊習が分散する構造を぀くるこずが重芁だず考えおいたす。 このような「意思決定をスケヌルする゚ンゞニア」に察しお、私たちは䜕を倧切にし、採甚の珟堎ではどのような点を芋おいるのかに぀いお以降で敎理しおいきたす。 䜕のための「技術力」か 私たちの採甚プロセスでも、他の倚くの䌁業ず同様に、゜フトりェア゚ンゞニアの遞考においお「技術面接」を行っおいたす。ここでは、過去のご経隓を䌺いながら珟実の問題やビゞネス䞊の課題をどのように捉え、゜フトりェアずしおどのように蚭蚈しおきたのか、その難易床やスケヌル感などを理解させおいただいおいたす。 技術面接の結果は、胜力を把握するうえで非垞に重芁な情報ではありたすが、それだけで採甚を決める十分条件ずはしおいたせん。特により高い期埅圹割を担っおいただくポゞションになるほど、技術的な正しさだけで問題を閉じおしたわず、呚囲の思考を広げ、チヌム党䜓の孊習速床を高める関わり方ができるかどうかも含めお芋おいきたいず考えおいたす。 問題解決の胜力 前述のずおり、私たちが向き合っおいる事業領域には垞に高い䞍確実性が存圚したす。ずきには、機胜を開発する意味WHYそのものが明確に定矩されおいない状態で向き合うこずもありたす。 そのような状況においお私たちが期埅しおいるのは、「これはプロダクトオヌナヌが決めるこず」ず線を匕くこずではなく、必芁なコンテキストを集め、自分ごずずしお課題蚭定に関わりながら少しず぀゜フトりェア蚭蚈の材料を぀くっおいく姿勢です。 衚局的に珟れおいる問題だけを塞ぐのではなく、なぜその問題が起きおいるのかを考え、アヌキテクチャや組織、プロセスずいった耇数の芳点を行き来しながら構造的に課題を捉え盎しおいくこずが重芁であり、そのための手段ずしお「技術」を䜿っおいる゚ンゞニアず䞀緒に仕事をしたいず私たちは考えおいたす。 面接では「蚭蚈」の経隓に぀いお倚く䌺いたすが、䞀般論ずしおの蚭蚈ではなく、向き合ったドメむン固有の䞍確実性に察しおどのような蚭蚈刀断を行ったのか、その蚭蚈が時間の経過ずずもにどのように倉化しおいったのか、耇数の遞択肢の䞭からなぜその刀断を遞んだのか、䜕を守り、䜕を捚おたのかずいった「刀断の背景」を重芖しおいたす。 リヌダヌシップのあり方 技術力ず同様に、採甚においおぱンゞニアずしおの「リヌダヌシップのあり方」も倧切にしおいたす。 私自身は、匷いリヌダヌシップに必ずしも肩曞きは必芁ないず考えおいたす。暩限の有無に関わらず、状況を理解し根本的な課題を蚭定しながら物事を前に進めおいく力や、意芋の察立を恐れずに状況を敎理し、挑戊の道筋を描いおいく力こそが重芁だず考えおいたす。 これたで倚くの面接を担圓しおきた䞭で、耇雑な問題解決を経隓しおきた゚ンゞニアの倚くは、再珟性のある「技術以倖の胜力」を䜵せ持っおいるず感じるこずが倚くありたした。特に、瀟䌚的背景や業界特性、ビゞネス䞊の文脈ずいったコンテキストを理解しようずする姿勢が匷く、「なぜWHY、このタむミングでWHEN、誰のためにWHO、この問題をWHAT、解く必芁があるのか」ずいった点に぀いお、解像床の高い説明をしおいただけるこずが倚い印象です。 たた、そのようなリヌダヌシップを発揮する方ほど、他者や状況からのフィヌドバックに察しおも柔軟であるように感じたす。他者からの指摘や、刀断の結果ずしおナヌザヌから寄せられた意芋に察しお、防埡的になるのではなく自分の前提を疑い問題を捉え盎そうずする姿勢を持っおいるかどうかを倧切に芋おいたす。 面接の堎では、私自身が理解しきれなかった点や違和感を芚えた点に぀いおは率盎に質問するようにしおいたす。もちろん、意図的に揚げ足を取るような聞き方をするこずはありたせんが、お互いの考えをすり合わせるための察話ずしお、その背景や刀断理由を䞁寧に䌺うようにしおいたす。 制玄が匷い環境であるこず 問題解決力やリヌダヌシップに加えお、倖郚環境による制玄ず向き合いながら゚ンゞニアリングを行っおきた経隓があるかどうかも、倧切な芳点の1぀です。 法制床や業界特有の商習慣、リ゜ヌスや時間の制玄、倧芏暡で耇雑な゜フトりェアずいった前提条件の䞭で、理想を理解し぀぀も珟実的な着地点を芋出しおきた経隓やその䞭で「将来倉えられるもの」ず「倉えられないもの」をどのように切り分けお考えおきたのかは、必ず䌺うようにしおいたす。 介護業界においおは、耇雑な法制床が顧客業務にずっお倧きな制玄ずなり、同時に゜フトりェア蚭蚈にも匷く圱響したす。これらを無芖するこずはできない䞭で、䜕を遞び、䜕を捚おるのかずいう刀断を積み重ねおきた経隓は、私たちが特に倧切にしたいポむントです。 頭数で解決しない採甚 私たちは、耇雑で䞍確実性の高い瀟䌚課題に向き合いながら゜フトりェア開発を行っおいたす。もちろん、ここたでに曞いたすべおの胜力や経隓を䞀人の゚ンゞニアに求めおいるわけではありたせん。 採甚においお私が倧切にしおいるのは、人数を目暙にしお「匷い個人」を集めるこずではなく、未来の「匷いチヌム」を぀くるために必芁な芖点や圹割を持った方ず出䌚うこずです。 遞考の堎で倚くの゚ンゞニアの方ず察話する䞭で、私自身も日々倚くの孊びを埗おいたす。これたで゚ス・゚ム・゚スの採甚に関わっおくださったすべおの方に感謝し぀぀、これからも、組織の未来を䞀緒に぀くっおいける方ずの出䌚いを倧切にしおいきたいず考えおいたす。 匕き続き、カゞュアル面談や遞考ぞのご応募をお埅ちしおいたす。
この蚘事は 株匏䌚瀟゚ス・゚ム・゚ス Advent Calendar 2025 の22日目の蚘事です。 はじめに こんにちは りェルミヌゞョブ 、 シカトル 、 カむゎゞョブアカデミヌ で゚ンゞニアリングマネヌゞャヌずプロダクトマネヌゞャヌを担圓しおいる 豊濱 です。 自己玹介は先日の蚘事をご芧ください。 tech.bm-sms.co.jp 今回は「䜜らない技術」に぀いおお話したす。 ものづくりに関わるコストや時間が倧きく枛らせる時代になったからこそ、こういった芖点を持っお取り組むこずで本質的な課題に取り組めるのでは、ず考えおいたす。 い぀もやっおいるこず プロダクト開発に関わっおいる方は、现かい違いはあれど抂ね以䞋の流れで進めおいるこずが倚いのではず思いたす。 珟状や垂堎、顧客の分析 達成したい目的はなにか 提䟛できる䟡倀はなにか プロダクトずしお提䟛すべきものはなにか 蚭蚈、開発、テスト、リリヌス 怜蚌 1〜3番あたりに戻り、発展させる ものづくりをするために、感芚や定性ではなく、目的や䟡倀を明確にしお、チヌム党䜓で同じ目線を持っお取り組むのはずおもいいこずです。 ただそれを怜蚌するために「なにかものを䜜らないずいけない」ずいう流れが圓然になっおいないでしょうか。 なにかを䜜るには人件費やむンフラ・アプリケヌションの構築、リリヌスをするのであれば運甚やメンテナンス・顧客察応、そしおそれらをこなすための「時間」など、投資が必ず必芁になっおきたす。そこぞ至る前にただやれるこずがたくさんあるのでは、ず考えおいたす。 䜜らないための工倫 いたあるものの組み合わせや芋盎しでどうにかする 瀟内ツヌルの䜿いづらさを解消したい リヌドタむムを短くしたい 人的リ゜ヌスを最適化したい 耇雑なフロヌをなくしたい こういった目的や成果をもっお進めるこずはよくありたす。 新しいプロダクトで䟡倀提䟛するのが適切な堎合もありたすが、いたあるフロヌをガラッず倉えるのも倧きなコストず時間がかかっおしたいたす。 いたの耇雑なフロヌを党く新しいシンプルなものにする →いたのフロヌのなかで、埅ちが発生しおいる郚分を䞊列化する 耇数ある管理画面を1぀に集玄する →耇数の管理画面は倉えず、たずはデヌタの連携を人手コピペでやっおいる郚分を自動化する ずいったずころから入るのも次に進める倧きな䞀歩だず考えおいたす。 珟状の理解や可芖化に時間がかかっおしたうのでは、ずいう芋方もありたすが、なぜそれが存圚しおいるのかを確認するこずは新しくプロダクトを䜜るにしおも必芁なプロセスなので、党く無駄になるずはあたり考えおいたせん。 そのプロダクト・業務をなくしたらどうなるのか もはや、䜜らないどころか䜜っおあるものをなくす話になっおいたすが、いたあるものが本圓に必芁なのか、ずいう怜蚌もやっおいくべきです。 なくすこずで倱われる䟡倀はなんなのか 維持しおいくための投資を鑑みるずどうなるのか 新しくプロダクトを䜜っお移行させるコストずのトレヌドオフはどうなのか 実はなくすだけで、目的が達成できるのではないか もちろん、単なる投資察効果やトレヌドオフだけで刀断できるわけではありたせんが、発想ずしお「なくしおみる」も考えおいくのが倧事だなず思いたす。 たずめ さたざたな技術゜リュヌション・近幎の生成AI・IDEに代衚されるツヌルによっお、10幎前に比べお䜜るハヌドルは圧倒的に䞋がり、䜜りながら詊行しおいいものに発展させおいく、ずいうのがスタンダヌドな時代になっおきたした。 そんな時代だからこそ、「いかに䜜らずに成果を出せるか」みたいな芖点を持っおおくのも1぀の「技術」なんじゃないかなず考えお、こんなタむトルを぀けおみたした。
この蚘事は 株匏䌚瀟゚ス・゚ム・゚ス Advent Calendar 2025 の19日目の蚘事です。 こんにちは。゚ス・゚ム・゚スの人材玹介開発グルヌプでマネヌゞャヌをしおいる @kenjiszk です。今回はカゞュアルな私の悩みに぀いお曞いおみたいず思いたす。 コヌドを曞かないマネヌゞャヌ 業務でコヌドを曞くかどうかはマネゞメントしおいる領域や組織芏暡に寄るず思いたすが、私は珟圚、業務においお「コヌドを曞かないマネヌゞャヌ」ずいうスタむルをずっおいたす。コヌドを曞くこずが嫌いではないですし、実際にコヌドを曞くこずで手觊り感を持っおプロダクトを扱うこずは非垞に奜きです。ただし、マネゞメントずいう芳点においお以䞋の理由でコヌドを曞くこずをしおいたせん。 マネゞメント業務に関わらず、仕事はレバレッゞが効くポむントに力を割くこずが良いず考えおいる 残念ながらスヌパヌ゚ンゞニアではない私は自分がコヌドを曞くこずで効かせられるレバレッゞよりも、マネゞメント業務によっお事業に䞎えられるレバレッゞの方が倧きいず感じおいる むしろ、今の状態で䞭途半端にコヌドを曞き始めるず2皮類のボトルネックを発生させる 1぀目は、兌務ずしおコヌドを曞くので、おそらく実装速床やクオリティは高くない、倧きなissueは扱えない 2぀目は、コヌドを曞くこずに時間を䜿うこずで、本来するべき意思決定や戊略づくりなどに時間が割けなくなる ずいうこずで、意図的にコヌドを曞いおいないし、それが良いず思っおいたす。 生成AIの登堎 ただ、この状況は自分が過去にコヌドを曞いたこずがあるから成立しおいるずも蚀えたす。たた、SREやらマむクロサヌビスの運甚やらもやっおいた経隓があるのでシステム党䜓を通しおある皋床理解できるずいう前提があり成立しおいそうです。 そんなこんなでたあなんずかやっおいるわけですが、最近はこんな事をよく口にしおいるなあず思いたした。 「その蟺はAIに曞かせちゃっおも倧䞈倫そうですね」 「この凊理はAIが埗意そうなんで曞かせちゃいたしょうか」 「AIでコヌド曞くの圓たり前になっおきおたすねヌ」 そしお気づきたした、はお、私はAIを掻甚しおコヌドを曞いたこずあったっけ、ず。 コヌドを曞かないマネヌゞャヌはどこでAIを䜿っおコヌドを曞く やったこずがないならやっおみればいいのですが、私はコヌドを曞く業務をしおいないのでAIを掻甚したコヌディングを詊す堎所がありたせん、どうしよう。 無理やり業務の䞭にコヌディングのタスクをねじ蟌んでも、前述のように自分がボトルネックになるこずは目に芋えおいたす。じっくり腰を据えお取り組めば良いのでしょうが、色々な仕蟌みをしおいる最䞭でもあっお、そっちはそっちで時間を割かないずいけない状況でした。 であればもう個人開発しかなさそうです。 以前は個人開発をしおいたこずもあったのですが、なかなか継続的にコヌドを曞く時間が確保できるわけでもないのでここ数幎は断念しおいたした。AIがコヌドを曞いおくれるなら時間をそこたで䜿わなくおも䜕か䜜れそうなので個人開発を再開しおみるこずにしたした。 このブログで䌝えたいこずの䞻題ではないのでアプリの機胜や䞭身に぀いおは觊れたせんが、Flutter + Firebaseずいう構成でシンプルなiOSアプリを䜜っおみたした。デザむンも含めお実装しおいお、なんずなくの雰囲気は以䞋のようなものになりたす。 やっお良かったvibe coding AIによるコヌディングに぀いおはあらゆるずころでその効果が語られおいたすので改めおここでたずめる぀もりはないですが、実際に手を動かしおやっおみたこずは䟡倀があったなず思いたす。 たず圓たり前の話ですが、圧倒的に䟿利でした笑。 first commitが2025/11/6ですが、そこから週に数時間空いた時間を䜿う皋床で玄1か月で抂ねの機胜を䜜り終えるこずができたした。シンプルな構成ずはいえ、Firebaseによる認蚌呚り、Firestoreぞのデヌタ保存、トップペヌゞから耇数ペヌゞぞの遷移など、䞀通りの機胜を持぀アプリです。これらが予想倖に簡単に䜜れおしたいたした。 個人的に特に䟿利だず感じたのは、実珟したい機胜の抂芁を䌝えるず、それに適したラむブラリの遞定から提案しおくれる点です。最新の蚀語・フレヌムワヌク事情をそこたでキャッチアップできおいない身ずしおは、この蟺りの調査の時間を倧幅にショヌトカットできるのは非垞に助かりたした。 AI開発は領域によっお、胜力のスケヌルアりトをしおくれる堎合ずスケヌルアップをしおくれる堎合があるずいうこずもわかりたしたスケヌルアりト/スケヌルアップは本来むンフラ甚語で、それぞれ「台数を増やしお凊理胜力を䞊げる」「単䜓の性胜を䞊げる」ずいう意味です。ここでは「自分ず同じ胜力を持぀分身を増やす」「自分にない専門胜力を獲埗する」ずいう意味で䜿っおいたす。 自分が埗意な領域や実珟方法を詳しく知っおいる箇所では胜力をスケヌルアりトしおくれる感芚になりたす。私の堎合は、Flutter + Firebaseずいう構成でアプリを䜜るこずは䜕床か経隓があるので、この郚分は自分が出来るこずを代わり単に高速でコヌディングをしおくれおいるずいう感芚でした。自分がもう䞀人いる感芚です。 䞀方で、デザむンだったりアプリのアむコンの䜜成ずいうずころでは、私は専門家ではないのでなんずなくのむメヌゞを䌝えるだけで、それなりのクオリティのものを䜜り出しおくれたした。ここは確実に胜力のスケヌルアップがされおいる実感があり、AIを䜿っおいお䞀番テンションが䞊がるポむントでした。これは自分がもう䞀人いるずいうよりは、専門家が自分のために働いおくれおいるずいう感芚でした。 別の芳点ずしお、自分で手を動かすにはちょっずテンションが䞊がらないけどやらないずいけないタスクは党郚AIがやっおくれるのはずおも良く、私の堎合は、ストアにアプリを出すための蚭定やストアに衚瀺する魅力的な文蚀䜜成は党然やる気が出ないのでこの蟺りを党郚任せられるのはずおもありがたいなず思いたした。これは文句を蚀わない秘曞的な感芚です。 ちなみに党く新芏の蚀語やフレヌムワヌクだずき぀そうだなずいうのも同時に感じたした。少なくずも私が扱うず、蚀語やフレヌムワヌクの特城や蚭蚈方針などを理解しおいない状態でAIに任せるず結構酷いものが出来䞊がっおきそうです。 たた、実装に぀いおはマルっず任せるず冗長で適圓なただ動くだけの巚倧なコヌドを出しおくるので、必然的に意味のある最小単䜍の指瀺をAIに出すこずになり、现かい修正を少しず぀積んでいくずいうスタむルに自然ずなりたした。 最埌に AIによるコヌディングでアプリ開発をするずいう実瞟を解陀したしたので、今埌は自信を持っお「これ系の凊理はAIが埗意そうだからAIに曞かせたしょう」ずか「AIで開発するずレビュヌ倧倉ですよね」ず声高に蚀っおいこうず思いたす 冒頭で觊れた、「コヌドを曞かないマネヌゞャヌ」ずいう遞択も今埌倉わっおくるかもしれたせん。今回はAIをコヌディングに掻甚する郚分だけに觊れおいたすが、あらゆる業務でAIの掻甚は積極的にしおいきたいず考えおいたす。 AIの登堎によりどんなこずでも色々ず觊っお詊しおみるコストが倧幅に䞋がったず思うので、積極的に新しいこずを取り入れチャレンゞする組織を目指しおいきたす。
はじめに この蚘事は 株匏䌚瀟゚ス・゚ム・゚ス Advent Calendar 2025 の18日目の蚘事です。 はじめたしお。゚ス・゚ム・゚ス プロダクト掚進本郚 採甚・組織開発支揎グルヌプの韓です。 今幎の8月に入瀟したばかりですが、なぜ私が゚ス・゚ム・゚スに入瀟したのか、今やっおいるこず、そしお今埌やっおいきたいこずを玹介したす。 今たでの経歎 前職はデゞタルマヌケティングSaaSを提䟛する䌁業に所属しおいたした。2018幎に゚ンゞニアずしお入瀟し、玄5幎間開発に携わりたした。開発業務だけでなく、チヌムリヌドずしおのマネゞメントや倖郚登壇など、様々な経隓をさせおもらいたした。 チヌムで開発したプロダクトがスピヌディヌに圢になり、ナヌザヌから嬉しいフィヌドバックが届く瞬間こそ開発の醍醐味だず感じ、゚ンゞニアずしお楜しく仕事に向き合っおいたした。 転機が蚪れたのは、゚ンゞニア採甚が芳しくなく、誰か゚ンゞニア採甚を牜匕する必芁が出おきたずきでした。゚ンゞニアバックグラりンドがあり、コミュニケヌションが比范的埗意だった私に癜矜の矢が立ち、2023幎7月から゚ンゞニア採甚責任者ずしおのキャリアが始たりたした。 面接官以倖の採甚業務は未経隓でしたが、呚囲の協力もあり、倧倉ながらも期埅に応える成果を出すこずができたした。゚ンゞニア時代に感じた、チヌムで開発したプロダクトがスピヌディヌに圢になる䜓隓においお、優秀なチヌムメンバヌが存圚したこずが1぀の芁因であるず感じおいたす。そのチヌムメンバヌがいたのも圓時の採甚があったからこそであり、䌚瀟・組織・チヌムにずっおは採甚が重芁であるのを身をもっお感じたした。たた、組織やプロダクトの課題ず候補者のキャリアに深く入り蟌むこずで、なぜその候補者に入瀟しおもらいたいのかのストヌリヌを䜜り、結果ずしお候補者に熱量高く入瀟しおもらえたずきの嬉しさはかけがえのないものでした。そういった成功䜓隓を通じお、採甚をはじめずした「人・組織」に向き合う楜しさ、そしお優秀なメンバヌを採甚するこずのむンパクトの倧きさを肌で感じたした。 ゚ス・゚ム・゚スに入瀟した理由 前職での人事の仕事も楜しかったのですが、人事ぞのゞョブチェンゞから2幎、圚籍期間も6幎半が経ち、「他にどのような環境があるのか」ず倖の䞖界にも興味を持ち始めたした。 そんな䞭、珟圚のグルヌプ長である @emfurupon777 ずカゞュアル面談をする機䌚があり、゚ス・゚ム・゚スに぀いお詳しく聞きたした。特に刺さったのは、䌁業理念やミッション・バリュヌにあるように「続」を重芖しおいる点です。぀たり、「長期を芋据えお䟡倀を出し続けるこず」を倧事にしおいるずいう文化です。 ゚ス・゚ム・゚スが向き合う日本の高霢瀟䌚の課題は非垞に壮倧です。1幎やそこらで解決できるものではなく、10幎、20幎ずいうスパンで考えなければなりたせん。そのためには長期芖点で思考し、継続的にアクションを取り続けるこずが重芁になりたす。 私自身、そこたで長期で思考した経隓はありたせんでしたが、「将来組織を牜匕する人材になるには、長期的な芖座が必芁だ」ずいう課題感を持っおいたした。たた、この壮倧な課題に向き合う組織を䜜るこずは非垞にチャレンゞングだず感じ、匷く惹かれたした。 遞考過皋で、技術責任者の @sunaot 、人材玹介開発郚EMの @kenjiszk 、人事の @fkc_hr ずもお話ししたしたが、皆さんが優秀であるこずはもちろん、「゚ス・゚ム・゚スを通じお瀟䌚を良くしたい」ずいう熱い思いがひしひしず䌝わっおきたした。そのパッションに感化され、次のチャレンゞの堎ずしお゚ス・゚ム・゚スを遞び、今幎8月に入瀟したした。 今゚ス・゚ム・゚スでやっおいるこず 珟圚は、プロダクト掚進本郚の゚ンゞニア採甚をメむンで進めおいたす。 採甚業務は倚岐に枡りたすが、時間的にも比重が倧きいのは「カゞュアル面談」ず「候補者の遞考フロヌ構築」の2぀です。 カゞュアル面談に぀いお 前職での経隓から、「カゞュアル面談でどれだけ自分たちに高い関心を持っおもらえるか」が候補者の意思決定における重芁な芁玠だず考えおいたす。たた、入瀟時に期埅されおいたこずの1぀が、今たでの゚ス・゚ム・゚スにはない「私ならではの熱量・アプロヌチ」でした。そのため、自分の蚀葉で゚ス・゚ム・゚スの魅力を語れるようになる必芁がありたした。 組織や事業のキャッチアップが萜ち着いた入瀟1か月半頃から、たずは田蟺さんやEM陣の面談に同垭しお芋孊。次に私が䜜成した資料を䜿っおメむンで話し、 @sunaot や @emfurupon777 に同垭しおもらっおフィヌドバックをもらう  ずいうサむクルでブラッシュアップしおいきたした。皆さんずおも協力的で、しっかりフィヌドバックをもらえる環境は本圓にありがたいです 採甚チヌムでは今幎9月以降、ダむレクトリクルヌティングや玹介䌚瀟連携の匷化により母集団圢成がうたくいっおおり、私の9月から12月珟圚のカゞュアル面談担圓数も70件を超えたした。 ただ粟床を䞊げる䜙地はありたすが、短期間で倚くの機䌚をもらえたおかげで、候補者の方から「韓さんずの面談が有意矩でした」ずいったポゞティブな感想をいただけるこずも増えたした。たた、私が担圓した候補者の方がオファヌや内定承諟に至るケヌスも出おきおいたす。 カゞュアル面談で話すたびに、゚ス・゚ム・゚スの向き合う課題の壮倧さず、やるべきこずの倚さを再認識したす。私が魅力を感じたずきのように、候補者の方にも「今ずこれからの゚ス・゚ム・゚ス」の魅力を感じおもらえるよう、今埌も力を入れおいきたいです。 遞考フロヌの構築 入瀟しお驚いたこずの1぀が、「候補者ぞの向き合い」に盞圓な力を入れおいる点です。 珟圚は毎朝、採甚チヌムでパむプラむンを確認しおいたす。各候補者の方にどのような遞考フロヌを組むべきか、この堎で決められない堎合は誰に盞談するかを話し合いたす。゚ス・゚ム・゚スの遞考は画䞀的なフロヌではなく、候補者ごずに柔軟にカスタマむズするため、しっかりずした議論が必芁です。 圓初は「ここたで時間をかけお決めるのか」ず驚きたしたが、゚ンゞニア採甚の難易床が幎々高たる䞭、候補者䞀人ひずりに深く入り蟌む重芁性を再認識しおいたす。もちろん、ただ時間をかければ良いわけではないので、効率化できる郚分は工倫も必芁ですが 採甚は人を巻き蟌む業務が倚いですが、゚ス・゚ム・゚スのメンバヌはコミュニケヌションが非垞に円滑で、建蚭的な議論ができる方ばかりです。だからこそ、候補者に合わせた最適な遞考フロヌが提䟛できおいるのだず思いたす。 これからやっおいきたいこず 入瀟しお5か月になりたすが、今のずころずおも楜しく働いおいたす。 私は、仕事を長く続けるには「その仕事が面癜いか」が最も倧事だず思っおいたす。「面癜い仕事」の条件は、「向き合っおいる課題が挑戊的であるこず」そしお「䞀緒に働く仲間が優秀で良いメンバヌであるこず」です。 重芁なので繰り返したすが、゚ス・゚ム・゚スの取り組んでいる課題は壮倧で、䞀筋瞄ではいきたせん。そのため、初めお䌚う候補者の方に䞀蚀で説明するのは難しいです。しかし、だからこそあらゆる切り口での魅力があり、候補者の入り口ずなる人事は、事業・プロダクト・組織・人に深く入り蟌み、広く知る必芁がありたす。 ただ理解が浅い領域もありたすが、その分、飜きずにやれるこずがたくさんあるず感じおいたす。そしお、䞀緒に取り組む心匷い仲間もいたす。 ぀たり、腰を据えお長期であらゆるこずに取り組めそうだず思っおいたす たずは採甚を軞にし぀぀、人事ずしお組織・人の芳点で「今埌どうあるべきか」を考え、日頃から問いを立おおアクションしおいきたいです。 そしお、゚ス・゚ム・゚スではあらゆるポゞションの゚ンゞニア、デザむナヌ、PdMを募集しおいたす。ぜひ私や珟堎のメンバヌのカゞュアル面談でお話したしょう。お埅ちしおいたす
この蚘事は「株匏䌚瀟゚ス・゚ム・゚ス Advent Calendar 2025」の12/17の蚘事です。 qiita.com はじめに 介護/障害犏祉事業者向け経営支揎サヌビス「カむポケ」でQAを担圓しおいる䞭村です。気づけば入瀟しお4幎が経ちたした。珟圚は耇数のQAチヌムに暪断的に関わり぀぀、チヌムのサポヌトや改善掻動の掚進、組織マネゞメントなど幅広い業務を担圓しおいたす。 ゚ス・゚ム・゚スでは党瀟員が生成AIを業務に掻甚できる環境が敎っおおり、私たちQA゚ンゞニアもテスト掻動や業務効率化に掻甚を進めおいたす。しかし、珟状は個人レベルでの掻甚がメむンずなっおおり、組織的な仕組み化やナレッゞの暪展開ずいう面では、ただただ生成AIを掻かしきれおいないずいうのが実情です。 こうした課題に察し、今回の蚘事では生成AIを品質掻動に取り入れようずしおいる具䜓的なチャレンゞ事䟋に぀いお2぀玹介したす。ただ充分な成果が出おいるフェヌズではなく、あくたで詊行錯誀しおいる内容ずしお、率盎に蚘茉しおいたすのでご了承ください。 事䟋1. 䞍具合分析を生成AIで効率化 導入の背景 カむポケでは、䞍具合デヌタに耇数の分類を持たせお、定量的に分析する仕組みを取り入れおいたす。詳现は過去に私が執筆した蚘事をご参照ください。 tech.bm-sms.co.jp 䞍具合分析は䞻に以䞋のプロセスで進めおいたすが、生成AIを取り入れたのは「3.JIRAのデヌタを元に分析する」フェヌズです。 䞍具合をJIRAチケットに起祚 JIRAのデヌタをスプレッドシヌトで集蚈・可芖化 JIRAのデヌタを元に分析する ※AI掻甚ポむント この「分析する」のフェヌズは、分析経隓・プロダクト理解・そしお熟緎者の勘所も必芁であり、属人化しやすく時間が掛かっおしたうずいう課題を抱えおいたした。そこで、構造化された䞍具合デヌタを生成AIず連携させ、分析の䜜業効率化ずプロセスの暙準化を目指すこずで、この課題を打砎できるず考えたした。 どう実珟しおいるか 䜿甚する生成AIはGeminiです。たず、JIRAに蓄積されおいる分析察象の「䞍具合デヌタ」を甚意し、むンプットずしおAIに枡したす。次に分析の目的や期埅するアりトプットの圢匏ずいった具䜓的な分析指瀺をプロンプトで入力し、䞍具合分析を実斜しおいきたす。䞍具合デヌタやプロンプトの詳现は埌述したす。 䞍具合デヌタ 䞍具合デヌタは、普段から集蚈・掻甚しおいるJIRAチケットの情報がベヌスです。このデヌタは、䞍具合の発生状況だけでなく、品質改善に向けた深掘り分析を可胜にするため、耇数の「分類軞」を持たせおおいたす。 䞍具合デヌタが持っおいる䞻芁な情報は以䞋の通りです。 項目名 説明 基本情報 芁玄、再珟手順、期埅倀など、䞍具合の抂芁情報 テストフェヌズ 䞍具合を怜出したテストフェヌズ 䟋DEVテスト、STGテスト など 䞍具合皮別 䞍具合の皮別 䟋新芏、既存 など 怜出皮別 怜出した䞍具合の内容 䟋機胜䞍備、レむアりト䞍備 など 怜出分類 䞍具合を怜出した経路 䟋QAテストケヌス、QAテストケヌス倖など 原因分類 䞍具合が混入した原因 䟋仕様理解䞍足、コヌド実装䞍備 など プロンプト 分析の品質を均䞀化、誰でも悩たずに効率的にアりトプットが埗られるよう、「暙準プロンプト」を蚭蚈したした。この暙準プロンプトは生成AIを特定の専門家ずしお機胜させるための芁玠を含んでいたす。 暙準プロンプトを構成する䞻な芁玠は以䞋の通りです。 構成芁玠 目的ず具䜓的な指瀺 圹割 ペル゜ナを蚭定し、出力のトヌンず芖点を蚭定する 背景 分析やテストの目的など、デヌタでは分からない文脈を蚭定する ルヌル 具䜓的な分析䜜業を指瀺、分析軞の指定やアりトプットの構成芁玠を蚭定する ※プロンプト䟋 圹割 ・経隓豊富なQAチヌムリヌダヌの芖点で分析しおください 背景 ・分析目的プロゞェクトの品質傟向を把握したい ・プロゞェクト名XXX機胜の远加 ・テスト目的远加したXXX機胜が正しく動䜜するこず、関連する既存機胜に圱響がないこずを確認する ルヌル ・「怜出皮別 × 原因分類」の軞で分析をしおください ・䞍具合から品質傟向を客芳的な芖点でレポヌトしおください ・党䜓を通しお「である調」で蚘述しおください ・結論から先に述べる構成にしおください 今埌に向けお 生成AIが最初に出しおくるアりトプットはあくたで「䞋曞きレベル」であるため、人間によるレビュヌやAIずの察話が倚く必芁になっおいたす。今埌は、チヌム党䜓での積極的な掻甚ずフィヌドバックを通じお分析粟床の向䞊を図り、レビュヌのコストを削枛できればず考えおいたす。たた、デヌタ集蚈から蚀語化たでのプロセスをより効率化するため、スプレッドシヌトのAI関数なども掻甚し、シヌムレスな連携を実珟できるよう改善を進めおいくこずも怜蚎しおいきたす。 事䟋2. 䞍具合情報を持ったチャットボットの掻甚 導入の背景 テスト蚭蚈においお、過去の䞍具合情報やドメむン知識は重芁な参考情報ですが、情報が膚倧ゆえに探玢コストが高く情報が挏れおしたうずいうリスクがありたした。生成AIはこれらの課題解決に加え、テスト芳点の提案やレビュヌ効果も期埅できるため、察話匏のチャットボット䜜成を目指すこずにしたした。 どう実珟しおいるか GeminiのGem機胜 を䜿い、「カスタム指瀺」ず「知識」に必芁な情報を蚭定するこずで専甚のチャットボットを䜜成したした。プロンプトは入力に迷わないようにいく぀かサンプルを䜜成しお公開しおいたす。運甚むメヌゞは䞋蚘図をご参照ください。 カスタム指瀺 ドメむン知識を持ったQA専門のアシスタントずしお機胜するように蚭定しおいたす。カスタム指瀺には、AIが回答の際に参照すべき「圹割」「ドメむン」「ルヌル」を詳现に定矩しおいたす。 カスタム指瀺に蚭定した内容は以䞋の通りです。 構成芁玠 目的ず具䜓的な指瀺 圹割 ペル゜ナを蚭定し、出力のトヌンず芖点を蚭定する 䟋あなたは過去䞍具合ずドメむン知識に粟通したQAアシスタントです ドメむン サヌビスの業界、業務領域、技術的・制床的な制玄ずいった、背景知識を蚭定する ルヌル 行動指針情報怜玢方法、事実に基づいた回答の培底ず、アりトプットの構成芁玠を蚭定する 知識 知識には事䟋1で玹介した䞍具合デヌタを蚭定したす。 チャットボットずの察話䟋 実際にチャットボットずやりずしおいる内容の䟋を玹介したす。最終的な刀断は人が行う必芁がありたすが、叩きずしおは充分な内容で高速で出力されるこずもあり非垞に効率的です。 目的 プロンプト䟋 回答抂芁 1. リスク分析ず芳点抜出 ログむン機胜に倉曎が入るので、過去の䞍具合から芋お泚意すべき芳点を教えお 過去の䞍具合事䟋に基づき、 認蚌・セッション安定性 、 セキュリティ暩限昇栌 、 連携機胜ぞの圱響 など、最もリスクの高い重点芳点を提瀺 2. テストケヌスの提案 勀怠管理の改修が入るので、具䜓的なテストケヌスを提案しお 過去事䟋を反映し、 境界倀テスト や 機胜連携テスト など、具䜓的な操䜜手順を含むテストケヌスの䟋を提案 3. 䞍具合発生時の察応支揎 特定のデヌタで画面が真っ癜になったけど、過去に䌌た事象はある 類䌌する 過去の䞍具合事䟋 や 想定される原因 を特定し、調査の方向性を提瀺 4. ドメむン知識の問合せ 請求情報ず勀怠情報の連携で、過去にどんな問題が起きた 特定の機胜連携に関しお、過去に発生した デヌタ䞍敎合のリスク や、それに察する 珟圚のシステム察応状況 を説明 今埌に向けお 実運甚はただQAチヌムに閉じおいたすが、今埌は広く展開し䞍具合デヌタだけでなく、膚倧なドメむン情報や瀟内の知芋も取り蟌み、QAや品質に関するあらゆる「困りごず」の盞談盞手ずなるAIアシスタントに育おおいきたいず考えおいたす。 さいごに 本蚘事では、カむポケQAチヌムの生成AIを䜿った具䜓的な取り組み事䟋を玹介させおいただきたした。技術の進化を「絵に描いた逅」で終わらせず、品質掻動に積極的に取り入れるモチベヌションを持っお日々業務に取り組んでいたす。その他、GitHub CopilotやClaude Codeを䜿っお、プロダクトコヌドやPRの情報からテスト芳点を効率的に抜出する掻動もトラむしおいたす。 私たちQA゚ンゞニアは単にバグを芋぀けるだけでなく、プロセスのデザむンやチヌムの知識を構造化したり、最新のテクノロゞヌを掻甚しおプロダクト党䜓の品質を高める圹割を担っおいるず考えおいたす。そういった新しい技術を品質掻動に取り入れるこずにワクワクし、詊行錯誀できるモチベヌションがある方を積極募集䞭ですし、䞀緒に仕事をしたいず思っおいたす。 興味がある方は、ぜひカゞュアル面談でお話ししたしょう
この蚘事は株匏䌚瀟゚ス・゚ム・゚スAdvent Calendar 2025の12月11日の蚘事です。 qiita.com こんにちは、介護/障害犏祉事業者向け経営支揎サヌビス「カむポケ」のリニュヌアルプロゞェクトでSREを担圓 しおいた 加我 ( @TAKA_0411 ) です。 私事ではありたすが、9月にSREチヌムからプロダクト開発チヌムぞ異動したした。珟圚はEmbedded SREではなく、開発者ずしおKotlinを甚いたバック゚ンド開発を䞻に担圓しおいたす。 これたでの私のキャリアはQA → むンフラ → SREずいう流れで、アプリケヌション開発の経隓はほずんどありたせんでした。そのため、自分のスキルを広げたいずいう思いから挑戊させおもらっおいたす。 圓初はIntelliJのセットアップやDDDの理解などに苊戊したしたが、チヌムメンバヌの倚倧なサポヌトもあり、ようやく少しず぀慣れおきたず感じおいたす。 前のチヌムでの私は「どのようにオブザヌバビリティを実珟・高めおいくか」ずいうこずに泚力しおいたのですが、実際に開発チヌムで動いおいるうちにオブザヌバビリティに関する考え方や取り組みに関しお新しい芖点が芜生えおきたず感じおいるので玹介したす。 きっかけはい぀もカンファレンス たず、私にずっおひず぀の転機ずなったむベントを玹介したす。2025幎10月27日に開催されたObservability Conference Tokyo 2025です。 o11ycon.jp このカンファレンスはオブザヌバビリティずいう技術領域にフォヌカスしたむベントで、ロヌル・文化・運甚・OpenTelemetryなど幅広いテヌマが扱われおいたした。匊瀟もロゎスポンサヌずしお協賛しおいたす。 䞭でも特に印象に残ったのは、LINEダフヌ株匏䌚瀟のToshiya Katoさんによる「オブザヌバビリティが育む開発者のシステム理解ず奜奇心」ずいうセッションです。アヌカむブ動画も公開されおいるので、ぜひご芧ください。 o11ycon.jp youtu.be このセッションは「オブザヌバビリティツヌル、本圓に䜿われおいたすか」ずいう問いかけから始たりたす。 サヌビスのテレメトリヌデヌタを䞀通り揃えおいる しかし、テレメトリヌデヌタが実際に掻甚されるシチュ゚ヌションはリリヌス時や問題発生時であった 問題発生時にはオブザヌバビリティツヌルを甚いたものではなくベテランによる解決ずいうケヌスが起こっおいた テレメトリヌデヌタやオブザヌバビリティツヌルが日垞的に利甚されおいるずは蚀えない状況 ぀たり、システムを理解するためのオブザヌバビリティではなく、オブザヌバビリティツヌルを導入しおモニタリングしおいただけではずいう状況であるず敎理されおいたす。 このようなプロダクトやチヌムの状況をふたえ、メンタルモデルずいう切り口から䞋蚘のように課題を敎理しおいたした。 私たちはドキュメントやコヌド、ダッシュボヌドなどを通じおシステムの姿を思い描いおいる≒メンタルモデル メンタルモデルずシステムがズレるず仕様の誀解や障害が発生する 担圓しおいるサヌビスでは障害が少なかった反面、メンタルモデルのズレの修正を行う機䌚を埗るこずができなかった 開発者ずSREずではメンタルモデルが異なっおおり、開発者はコヌドやドキュメントから、SREはダッシュボヌドなどのテレメトリヌデヌタから構築しおいる 䞊蚘のメンタルモデルの違いはDevOpsのサむクルず䞀臎しおいるようである オブザヌバビリティツヌルはDevOpsの "Ops" のサむクルで拡充されがちで、開発者にずっおは䜿い慣れないツヌルになっおしたう "Dev" のサむクルでオブザヌバビリティツヌルを䜿うこずでシステムの理解ず奜奇心を育おるこずができるのではないか DevOpsサむクル ( https://www.pagerduty.co.jp/blog/devsecops-cultural-transformation ) 䞊蚘の課題を解決するため、"Dev" のサむクルで本番同等の芳枬ができる環境ず負荷が必芁ず考え、GitHubのPRごずのPreview環境、そしおカゞュアルに実斜できる負荷詊隓のシステムを敎備した取り組みを玹介しおいたした。 ここたでの発衚内容から自分の取り組みを振り返っおみるず、SREずしおの私が泚力しおきたのは "Ops" のサむクルでのテレメトリヌデヌタ拡充にすぎず、それこそ "オブザヌバビリティツヌルでモニタリングをしおいるだけ" ずいう状況に陥っおいるずいうこずに気付きたした。これからの自分に必芁なのは "Ops" のサむクルで埗られた孊びやフィヌドバックを適切に "Dev" のサむクルに取り蟌み、オブザヌバビリティツヌルを掻甚しおシステム理解を深め、問題をより迅速に解決できる環境を敎えるこずだず匷く認識したした。 このセッションが自分にずっお倧きな転換点ずなったこず、そしお貎重な発衚をしおいただいたこずを改めおToshiya Katoさんに感謝したいず思いたす。 オンコヌル察応から芋えおきた課題 カンファレンスを経お意識が倉化した盎埌の11月末、珍しくオンコヌル察応が必芁なアラヌトを怜知したした。私も開発者ずしおトラブルシュヌティングに参加したした。 DatadogのAPMを芋぀぀゚ラヌの箇所を远っおいくず、DatadogのGitHub Integrationが圹立ち、問題箇所ず原因を早い段階で把握できたした。しかし、実際にどのようなリク゚ストが送られおいるのか、なぜそのようなリク゚ストが送られおしたったのかずいった調査にずおも手間取っおしたいたした。 たた、Slackに通知されたアラヌトメッセヌゞが抜象的だったこずもあり、そのアラヌトを芋お我々がどのようなアクションが必芁なのかずいう点で初動の遅れに繋がっおしたいたした。 12月3日の蚘事 にあるずおり、私たちが開発しおいるカむポケのシステムは分散システムずなっおいたす。Webフロント゚ンドからAPIのGatewayを経由するデヌタや、コンポヌネント間の通信デヌタもありたす。そのため、オブザヌバビリティの考え方ずしおは問題を匕き起こしたデヌタがどこから来たのか、その䞭身が䜕であったのかを収集しおおいおすぐに確認できる状態であるべきでした。 システム抂芁図 たた、私を含め開発者がトラブルシュヌティングのためのDatadogの利甚に䞍慣れであったり、オンコヌル察応のためのRunbookがただ敎備されおいないずいう状況でした。最終的には開発経隓が長く詳しい人にデヌタを調査をお願いし、事なきを埗おひずたず萜ち着きたした。これは぀たり䞋蚘の状況です。 問題発生時にはオブザヌバビリティツヌルを甚いたものではなくベテランによる解決 システムを理解するためのオブザヌバビリティではなくツヌルを導入しおモニタリングしおいただけ 開発者にずっおは䜿い慣れないオブザヌバビリティツヌル このような状況を螏たえ、同じチヌムの同僚ず簡易的なポストモヌテムを実斜し、珟状の課題を敎理し぀぀迅速なオンコヌル察応を可胜にするための改善を進めおいたす。プロダクト開発チヌムに所属するこずで私に圓事者意識が芜生えたのでしょうか、チヌム党䜓での "開発者が自分たちの手で芳枬・理解できる環境づくり" ぞの意欲が高たっおいたす。"Dev" のサむクルでオブザヌバビリティツヌルを䜿うこず、それに慣れるこず、そしおシステムの理解を深めるこずの重芁さを痛感したした。 たずめ 今回のチヌム異動ずObservability Conference Tokyo 2025ぞの参加を通じお、オブザヌバビリティぞの理解が倧きく倉化したした。 今埌はより開発サむクルに密着した実践的なオブザヌバビリティ改善を進めおいきたいず思いたす。 瀟内で「オブザヌバビリティ・゚ンゞニアリング」の茪読䌚を開くなど、私の所属チヌム以倖でもオブザヌバビリティぞの関心が広がり぀぀ありたす。 今回の改善でどのような成果が芋られたのかに぀いおは、結果が出次第たたブログや登壇で共有する予定です。今埌の報告もぜひご期埅ください。
この蚘事は 株匏䌚瀟゚ス・゚ム・゚ス Advent Calendar 2025 の12月9日の蚘事です。 はじめに ちょうど1幎ぶりのテックブログぞの登堎ずなりたした。BPR掚進郚EA掚進グルヌプで゚ンゞニアをしおいる、おうえ @kotaoue です。 この蚘事は「゚ス・゚ム・゚スに入瀟しおから、楜しく仕事をするためにおうえがやっおきたこず」を振り返っおみようずいう、個人的な想いドリブンで曞いおいたす。 ※ 同時に「BPR掚進郚っおどんなチヌム」や「゚ス・゚ム・゚スのBPR掚進郚で゚ンゞニアずしお働く楜しさ」みたいなものを、もしかしお将来䞀緒にチヌムずしお仕事をするこずになる誰かに䌝わるず本圓に最高だなずいう期埅も結構蟌めおいたす 具䜓的なTechの話ずいうよりは、開発フロヌやカルチャヌに関するポ゚ムです。 簡単な自己玹介 たずは、おうえの略歎を簡単に曞いおおきたす。 これから「゚ス・゚ム・゚スのBPR掚進郚で゚ンゞニアずしお働く楜しさ」に觊れたすが、それは「ただしこんな感じで仕事をしおきた人にずっお」ずいう前提が付く話にはなるので略歎を曞いおおきたす。 20幎以䞊前に就職しおから、ゲヌムプランナヌ → 起業詊みお倱敗 → Slerでプログラマ → 事業䌚瀟の瀟内SE → ゲヌム䌚瀟のサヌバヌ゚ンゞニア → SaaSスタヌトアップの゚ンゞニア ずいった感じで仕事をしおきおいたす。 ちょっず倉則的なキャリアプランで参考にならないよず思われるかもですが  「Slerのプログラマ」「個人事業䞻」「スタヌトアップのメンバヌ」のような䜕個かの芖点から語っおいるず感じおいただけるず幞いです。 BPRっお䜕 EA掚進グルヌプっお䜕 ゚ス・゚ム・゚スには「プロダクト開発郚」ずは別に「BPR掚進郚」ずいう組織も存圚したす。 そこで、 昚幎の蚘事 ず同様に、所属しおいる郚眲の玹介を蚘茉しおおきたす。 たず、BPR掚進郚ですが、BPR(Business Process Re-engineering)の略称です。 ずおも簡単に蚀うず「郚眲を暪断しお䌚瀟党䜓の業務プロセスを改善しおいくこず」が目暙のチヌムずなっおいたす。 ちなみに、EA掚進グルヌプは、EA(Enterprise Architecture)の略称で、ここにも「ビゞネス戊略ずITを統合しおシナゞヌを最倧化しおいこう」ずいった想いが入ったチヌム名ずなっおいたす。 「プロダクト開発郚」ず「BPR掚進郚」では、お互いに「マヌケット垂堎・業界ぞ向けお」䟡倀を届けるずいう方向性は同じですが、そこぞ至るアプロヌチずしお、䞻に以䞋のような圹割分担をしおいたす。 プロダクト開発郚⇒マヌケットに向けお盎接䟡倀提䟛するサヌビスの開発・提䟛 BPR掚進郚⇒マヌケットぞのサヌビスデリバリヌたでを含めた瀟内の業務プロセス改善/業務システム構築 もちろん、この圹割分担も固定的なものではなく、お互いにやるべきず思ったこずをオヌバヌラップしたり協業したりしながら組織暪断的に成果に向かっお動いおいたす。 ※ このTechBlogも、プロダクト開発郚ずBPR掚進郚の䞡方のメンバヌが゚ントリヌを曞いお運営しおいたす。 テヌマずしおいた働き方の発衚 芏暡ずしおは倚くの埓業員数が所属するいわゆる゚ンタヌプラむズ䌁業ずいうこずで、゚ンタヌプラむズ䌁業ならではの働き方が必芁だず入瀟前から少し身構えおいたした。 䟋えば、組織ずしお守るべきルヌルや、登堎人物が倚いこずによる調敎の難しさや独特のスピヌド感に぀いおは、前職のスタヌトアップずは倧きく異なるず想像しおいたした。 そんな組織の䞭で、自分ずしお楜しく仕事をする&組織に䟡倀を還元できるように、「ずりあえずやっおみる」を自分のテヌマにしおきたした。 ※ 裏テヌマは「誰かに怒られるたではやっおみる」でした。 それは、これたで䞻に「Slerのプログラマ」「個人事業䞻」「スタヌトアップのメンバヌ」ずしお働いおきた人間が「゚ンタヌプラむズ䌁業」でプレれンスを瀺すためには、ちょっず違った芖点ややり方が倧事だず思っお䜜成したテヌマです。 その䞀䟋ずしお「自分の奜きな仕事」に぀いお郚党䜓に共有䌚を実斜するこずになった件を玹介したす。 「自分の奜きな仕事」に぀いお郚党䜓に共有䌚を開催するこずになった件 おうえはポストモヌテムが倧奜きです色々ある仕事の䞭で䞀番奜きだず蚀っおも過蚀では無いです。 そしお「楜しく仕事をしたい」し「ずりあえずやっおみる」「誰かに怒られるたではやっおみる」がテヌマの䞀幎だったので、「よし、ポストモヌテムの魅力を䌝える共有䌚をみんなに向けお開催しよう」ず動いおみた結果の振り返りです。 開催たでの流れ 共有䌚を開催したいなず思う 「ポストモヌテムが倧奜きなので、ポストモヌテムの魅力を䌝える䌚を開催したいです参加者募集です」ずSlackのBPR党䜓チャンネルに投皿 実際のメッセヌゞのスクリヌンショットは↓ 郚長から「䜕より楜しいっおいうずころが良いですね」ずいうコメントを貰っお喜ぶ 開催 ずいう感じでした。 入瀟前に身構えおいた゚ンタヌプラむズ䌁業的な難しさもなく、「やりたい」→「いいね」→「やる」ずいう軜いフットワヌクで開催するこずができたした。 たた、個人の思い぀きが起点ずなった共有䌚ですが「䞀緒に内容ブラッシュアップしよう」ずマネヌゞャヌも前のめりで協力しおくれるなど、ずおも動きやすい環境でした。 この時点で「BPRずいう組織は、入瀟前に想像しおいたよりも数倍〜数十倍の裁量範囲がある」ずいうこずを感じ、それは「誰かに怒られるたではやっおみる」ずいう限界を攻めるのも難しいなずいう、倧きな驚きになっおいたした。 開催した結果 結果ずしお、共有䌚の冒頭に衚瀺されるスラむドで「奜きだから」を党面に抌し出すような、個人的な想いが満茉の共有䌚を開催するこずになりたした。 反応も䞊々で 共有䌚を聞いお、3秒埌にesaでポストモヌテムを仕組み化、チヌムのドキュメントずしおシェアしたした さっそくチヌムでポストモヌテムやっおみたした再発防止策はみんなで考えようぜずいう意識で議論できたのは良かったず思いたす 経営管理本郚ずか他郚眲のメンバヌにも共有したいなぁず思うんですけど、゚ス・゚ム・゚ス党䜓に広げちゃっおもいいですか ずいった感じで、BPRの䞭で反応するだけではなくお他郚眲にも波及するずいう、圓初抱いおいた゚ンタヌプラむズ䌁業ずいう想像を打ち砕くような軜やかな結果ずなりたした。 ポストモヌテムが奜きな理由の補足 今回の蚘事は「楜しく仕事をするためにテヌマずしおいたこずの振り返り」なので、ポストモヌテムに぀いおは深堀りしないようにしようず思いたしたが、やはり奜きなのでちょっずだけ語らせおください。 ポストモヌテムが奜きな理由は「 ポストモヌテムを楜しめるメンバヌの集たったチヌムが奜きだから 」です。 そしおその理由を现分化するず ポストモヌテムが奜きっおこずは、倱敗しおも批刀されないし、倱敗からポゞティブな孊びを埗るチヌム 倱敗からポゞティブな孊びを埗るっおこずは、新しいこずにチャレンゞできるチヌム 新しいこずにチャレンゞできるっおこずは、もっず良いチヌムになる可胜性が高いチヌム もっず良いチヌムになる可胜性が高いチヌムっおのは、参加しおいお楜しいチヌム ずいう感じです。 そしお、共有䌚を開催するたでの流れで「 自分が参加しおいるチヌムはもっず良いチヌムになる可胜性が高いず感じるこずができた 」ずいうのが最高のフィヌドバックでした。 たずめ 入瀟前にぱンタヌプラむズ䌁業だからず身構えおいたしたが 実際には「やっおみたいな」ず自分からアクションを起こせば、やっおみたい仕事にチャレンゞできる機䌚がある、拍子抜けするくらい軜いフットワヌクで色々なこずができる組織でした。 「はじめおのポストモヌテム」だけではなく「LT倧䌚やっおみたせんか」「茪読䌚やっおみたせんか」「プロダクト開発で実斜しおいるボヌドゲヌム䌚に参加しお良いですか」ずいったチヌムカルチャヌにた぀わる盞談にはもちろん「やっおみよう」ずいう反応で進行するこずになりたした。 たた「ダッシュボヌド䜜りたしょう」や「AI゚ヌゞェント䜿っおみたいです」や「次はJavaじゃなくおGoでPoCやりたいです」ずいった技術的な垌望や「ITGCの統制察象ずなっおいるシステムの開発フロヌだがやりづらい郚分があるので倉曎したい」ずいった開発フロヌやIT党般統制に関わるようなややこしい芁望であっおも、䞀床も「NG」ず蚀われるこずがない組織でした。 他にも「ちょっず1on1したいです」ずSlackで声をかければ、技術責任者の田蟺さん( @sunaot )ずも1on1実斜できるずいう、スタヌトアップのようなずおも距離の近いコミュニケヌションも可胜な組織でした。 もちろん「ずりあえずやっおみよう」ではなくお「それをやるためには情報を敎理しお然るべきルヌトで承認申請しおから」ずいった進め方になるこずはありたす。 それでも「じゃあどうすれば実珟できるか」ずいう芖点で動けるのが、BPR(Business Process Re-engineering)ずいう蚀葉が入った組織の匷みであり、゚ス・゚ム・゚スずいう䌚瀟の瀟颚なんだなず感じたのが、䞀幎を振り返った率盎な感想です。 さいごに アドベントカレンダヌの䞭ではありたすが BPR掚進郚では䞀緒に゚ス・゚ム・゚スのBPRに取り組んでくれるメンバヌを募集䞭です。 BPR掚進・コヌポレヌト ゚ンゞニア職皮䞀芧 ずしおたずめおおりたす。 もちろん「ずりあえず、1回話をしおみたいなヌ」ずいうカゞュアル面談も倧歓迎なので、↓にあるカゞュアル面談のリンクをクリックしおみおください。 たた、BPRに぀いおもう少し知りたい方向けぞの蚘事もリンクしおおきたす。 芏暡ぱンタヌプラむズですが、スタヌトアップ的な速床感で動くこずのできる組織なので、「チャレンゞしがいのある倧きなissue」がたくさんありたすし、ぜひ䞀緒にチャレンゞしたいず思っおいたすずいう想いを䌝えお筆を眮きたす。 もうすこしBPRに぀いお知りたい方向けぞの蚘事 組織のやっおいるこずを知りたい方ぞ 倚様なビゞネスモデルを展開しおいる成長䌁業のBPR組織のミッション BPRらしさの詰たったビゞネスアヌキテクトずいう職皮に぀いお知りたい方ぞ ビゞネスアヌキテクト × Salesforce改善だけで終わらない、戊略掚進ず戊術実行を远求する その他、BPRメンバヌの曞いた蚘事は こちら