「それ本当にMVP？」 AI時代にプロダクトが巨大化する理由をふりかえる
「それ本当にMVP？」AI時代にプロダクトが巨大化する理由をふりかえる おはようございます。シャトレーゼに入ったときのいい匂いの根源がなにか気になっている daipresents です。あれ、ほんとなんの匂い？ この1年、AIがとてつもないスピードで進化しており、活用するエンジニアもどんどん進化しているように感じています。 僕は「カミナシ 教育」と「カミナシ 従業員」の2プロダクトにかかわっているのですが、「小さく作ったつもりが、結果的に大きくなっちゃった」というケースが、立て続けでありました。 もしかしたら「AIの登場によって、MVPも巨大になってしまっているのではないか？」と感じたので、ふりかえってみようと思います。 AIの登場によってわかったこと カミナシ社内でも開発に置けるAI活用は進んでいます。これはデータにも現れていて、今年に入ってからはAIによるコード生成量は格段に増えています。 あきらかに増加しているAIのコード貢献 去年はまだ「試し試し」だった部分が、今年に入って「使うべき存在」になり、開発の流れも大きく変わっています。 特に「コードの量」は格段に増えており、開発に大きく影響を与えています。 MVP開発でおきたこと カミナシの開発では一般的に、小さく作ってどんどんリリースしながらプロダクトを育成してく形を取っています。 参考： カミナシと、質とスピード - MVP にこだわり、アジリティを獲得する 今回の事例でも同じくMVPを定義し、開発を進める形を取っていました。 しかし、成果物をレビューするときに「思った以上にいろいろできる」というフィードバックが多数でてきました。 エンジニアは、AIが開発に十分使えることがわかってきて、AIを使った開発を試していました。予想通り、AIは賢くなっており、たくさんのコードを生成してくれます。気がつけばスコープが広がっていました。 エンジニアとのふりかえりの場において、「もし、開発前にもどれるなら何をするか？」と問いかけディスカッションしましたが、以下の点がポイントとしてでてきました。 MVPを「ちゃんと」定義する 最初に決めたスコープを守る必要があります。 AIがいろいろ配慮して作ってくれるのはありがたいのですが、「何をやるべき」で「何をやらないべき」かを決めるのは「まだ」人間の役割です。 逆に「AIに全部作らせて、あとで削ればいいじゃん！」という考えもあります。 pic.twitter.com/YCmWPDlGOT— mrdoob (@mrdoob) 2026年4月5日 上記の図は、JavaScriptの3Dライブラリ「Three.js」の開発者である @mrdoob さんのポストです。ウォーターフォールやアジャイルのMVPの図はよくみかけるものですが、「AI」という項目が今回の現象をとても良く表しています。 この図のように、AIに作ってもらい、そこから削るのはどうでしょうか？ エンジニアとも話しましたが、この作戦も難しく感じています。 まず、AIの出力の良し悪しを考えるためには、すべての出力を人間が読み込まなければなりません。機能が多くなると人間が理解するのに時間がかかってしまい、アジリティが落ちます。AIの認知能力と人間の認知能力では圧倒的に差があるため、人間がボトルネックになってしまいます。 さらに、機能が増えるということは、検証材料が増えるということです。検証したい項目が増えれば増えるほど、やっぱりアジリティは落ちます。 最後に、機能が存在すると心理的にも「なんか全部いりそうだな・・・」となりがちです。AIの労力とはいえ「作った時間や使ったトークンがもったいない」という心理が働き、捨てる勇気が持てず「使ってくれるはず」と思いこんでしまうかもしれません。 こういった「たくさん作ったときの難しさ」を考えると、「スコープを守る」という行為は、「タイムボックスを決める」に近しいのかもしれません。制約を設けないと、制約を超えてどんどん機能が作られます。タイムボックスという制約をつけることで、できる範囲がしぼられます。 まとめ AIが開発に与える影響は大きくなっています。特に「コード量」は確実に増加傾向にあります。 AIのそのまま任せてしまうと、開発も「大きく」なってしまう可能性があります。しかしながら、人間は大きなものを認知するのに時間がかかり、結果アジリティが落ちます。 そうなると、AI時代であれどアジャイル開発のMVPの考え方や、スプリント・イテレーションを使った漸進的な開発（インクリメンタルな開発）のほうが「まだ」今はいいのかもしれません。
- 生成AI
- アジャイル
- プロダクトマネジメント
AI 評価ワークショップを実施して見えてきたこと—— AI エンジニアだけに任せない、チームで育てる AI 品質改善の文化
2026年4月、「カミナシ 教育」開発チームのオフサイト。 エンジニア・プロダクトマネージャ（PM）・プロダクトデザイナー（PD）が3人ずつのチームに分かれ、「カミナシ 教育」のAI機能をいじりながら、ある特殊なケースを探していました。 機能のバグでしょうか？いえ、もっと厄介なものです。「出力結果はおかしいのに、評価指標は問題なしと判定してしまうケース」——AI機能を評価する仕組みそのものの盲点です。 これが私たちのチームで実施したAI評価改善ワークショップの一場面です。 AI評価改善ワークショップの様子 こんにちは、カミナシでAIエンジニアをしている井上です。カミナシではプロダクトのAI機能の検証や開発、プロダクト横断のAI機能運用の基盤作りなどに携わっています。現在は「カミナシ 教育」のAI機能の評価基盤構築に取り組んでおり、本記事でご紹介するワークショップもその一環です。 なぜ、わざわざチーム全員を巻き込んでこんなことをしているのか。AI機能の品質を継続的に維持・改善していくためには、人間の目や顧客の声に基づく定性評価だけでは限界があり、開発時やデプロイ前の自動化された定量評価の仕組みが欠かせません。しかし、評価指標そのものがプロダクトの本質的な価値や人間の感覚とズレていれば、スコアが高くても品質は低いままになってしまいます。 つまり、AI機能の改善と並行して、評価の仕組みそのものも継続的に改善していく必要があるのです。 LLM機能の精度改善の基本サイクル。機能を改善するループと、評価そのものを見直すループは表裏一体です。うまくいかないケースを評価が拾えていなければ、プロンプトより先に評価方法の見直しが必要になります。 そしてこの評価の仕組みを育てる営みは、AIエンジニアだけで完結させられるものではありません。何を良いアウトプットとするかの判断基準は、PMが見ているユーザーの期待値や、PDが描くプロダクトの方向性など、多様な視点を統合してこそ磨かれていきます。AIエンジニア1人の感覚よりも、チームが持つ集合知の方が、顧客の感覚により速く・より正確に近づける——これが私たちの考える、AI品質改善をチームで取り組む価値です。 だからこそ私たちは、評価指標と実際の品質の乖離が顕在化する前に先回りしてAI品質改善をチーム全員の取り組みにする文化づくりに着手しました。今回のワークショップは、その第一歩です。 文化として根付かせるために、ワークショップという形を選んだ チーム全員でAIの品質改善に取り組む——と言葉にするのは簡単ですが、実際にやってもらうとなると障壁があります。それは「AIの改善って、なんだか難しそう」という先入観です。 例えばLLMを活用した機能の改善なら、LangfuseのようなLLMOpsツールを使う必要がありますし、「データセット」「評価指標」「LLM-as-a-Judge」といった専門用語も登場します。こうした要素が実際の作業以上に難しい印象を与え、チームメンバーの心理的ハードルを必要以上に高くしていると思います。やってみると「案外自分たちでもできる」と感じられる部分が多いのですが、その感覚は外から眺めているだけでは伝わりません。 だからこそ、チーム全員が手を動かしてAI機能の品質改善を体験する場が必要だと考え、ワークショップを実施することにしました。 なお、本来は評価の改善とAI自体の改善（プロンプトや処理の改善）の両方を体験してもらいたかったのですが、時間の都合で今回は評価の改善にフォーカスしています。良い評価は良いAI機能を作るための前提条件であること、そしてAI機能自体の改善に比べて「何をやるのかイメージしにくく、1人だととっつきにくい」領域であることが理由です。ワークショップという"みんなで一緒にやる"形は、ハードルが高く感じられがちな評価改善の導入にこそ向いていると考えました。 ワークショップの設計 今回のワークショップは、LLMを活用した1つの機能を対象に、その評価の仕組みを改善していく形で設計しました。複数の機能を扱うと論点が散らばってしまうため、最初の取り組みとしては1機能に絞ってチーム全員で深く向き合える構成にしています。 チーム編成 開発チームをエンジニア・PM・PDが混在した3人ずつの小チームに分割しました。職種をあえて混ぜることで、評価の視点が一面的にならないようにしています。 当日の流れ 苦手なケースの収集（15分） 評価を実行して観察する（10分） 評価方法を改善する（30分） 共有と発表（20分） 1. 苦手なケースの収集（15分） 各チームで、プロダクト上のAI機能がうまく動かないケース（入力テキスト）を集めます。単にうまくいかないケースを探すのではなく、「評価をすり抜けそうなケース」を意図的に探すのがポイントです。既存の評価指標がどんな観点で動いているかを眺めながら、「この指標だと拾えなさそうな入力ってどんなものだろう？」とチームで仮説を立て、プロダクト上でさまざまな入力を試していきます。 実際の運用では、こうしたケースは既存顧客が日々使う中で自然に上がってきたり、新規顧客の新しい使い方で見つかったりするものですが、ここではそれを凝縮した形で体験してもらいました。 2. 評価を実行して観察する（10分） 集めたデータセットで評価を実行します。私たちのチームでは、PRに紐づいてGitHub Actions上で評価が自動実行され、結果がLangfuseに蓄積される仕組みになっています。評価指標は単一のスコアではなく、「文体に一貫性があるか」「読みやすい文章になっているか」など観点別に複数用意されているのが特徴です。 ここでの判断基準は以下のとおりです。 スコアが低いデータ → 問題なし（苦手なケースを定量評価が正しく検出できている） スコアが高いデータ → 問題あり（本来検出すべきケースを評価の仕組みがすり抜けている） 3. 評価方法を改善する（30分） 評価ですり抜けてしまったケースに対して、各チームで原因を議論し、評価の仕組みそのものに手を入れていきます。コードベースの評価指標の追加・修正、LLM-as-a-Judgeの新しい評価指標の追加、既存の評価プロンプトの修正といったアプローチから選んで改善します。 ここが一番議論が白熱するフェーズで、「このケースって結局何が問題なんだっけ？」という問い直しから、「お客さんの望む"精度"ってどんな指標で測れば良いんだっけ？」といったプロダクトの本質的な価値まで話が広がることもしばしばありました。 4. 共有と発表（20分） 最後に各チームが、見つけたエッジケース・評価の改善内容・議論の過程を発表します。発表を聞くうちにチーム横断で共通するAI機能の課題が浮かび上がってきたり、「こんな観点、自分たちでは思いつかなかった」という発見があったりしました。そして何より、評価の改善って、案外自分たちでもできるんだという手応えを持ってもらえたのが、私としては一番嬉しい瞬間でした。 発表の様子 やってみてわかったこと 最大の発見は、「評価指標がすり抜けてしまうケース」を自分の手で見つけることで、初めて定量評価の限界と重要性を腑に落ちる形で理解してもらえるということでした。「スコアが高くても品質が低いことがある」という事実を、自分が収集したデータで目の当たりにすることで、PMやPDも含めたチーム全員が評価改善の当事者になれました。また、職種をまたいだ議論の中で、AIエンジニアだけでは気づけなかった「ユーザー視点での違和感」が評価指標に反映されるようになったのも大きな収穫です。 このワークショップは一度きりで終わりにするつもりはありません。いくつかのAI機能について、また小チームを結成し、チーム全員が関わる形で評価改善とAI機能そのものの精度改善に継続的に取り組んでいく予定です。 AI機能の品質は、AIエンジニアだけが守るものではありません。開発チーム全員で育てていくものだと、私たちは考えています。同じような課題感を持つチームの参考になれば嬉しいです。 おわりに 最後に、カミナシでは現在AIエンジニアを募集しています。本記事の通り、カミナシのAIエンジニアは実装だけではなく、AIを道具として適切に扱うための活動を文化として開発チームに根付かせる役割も担っています。興味のある方はぜひ一度カジュアル面談でお話ししましょう！ herp.careers
- 生成AI
- LLMOps
- 品質管理
AI時代こそスケールしないことをしよう — ボトルネックを追ってコードの外へ
はじめに カミナシで新規プロダクトの開発をしているShimmy(@naoya7076)です。 現在、新規プロダクトをプロトタイプとして開発しており、顧客に提供しながらフィードバックを得ています。Claude Codeをはじめ、開発の全工程でAIを活用しており、開発アイテムは予定以上のスピードで実装できています。 「AIでコーディングが速くなった。ではその空いた時間で何をやるのか？」 この問いに対して、自分が新規プロダクト開発で実践してきたことを書きます。 「もっと作る」はアンチパターン AIで実装速度が上がると、「もっと作ろう」という方向に引っ張られがちです。しかし、むやみに作るものを増やすのはアンチパターンです。理由は2つあります。 コードの意図の希薄化 AIによってコードを爆速で書けるようになりましたが、それを続けていると人の理解を超えた「意図が希薄なコード」が増えてしまいます。プロトタイプは本番プロダクトの土台であると同時に、顧客のドメイン理解の記録でもあります。なぜそのコードが存在するのかを読み取れなければ、プロダクションに活かせるドメインを発見することや、フィードバックを本番コードに活かすことが難しくなり、その両方の機能を失ってしまいます。 翻訳記事「AIコーディングツールによって加速するコード生成に品質保証活動はどう立ち向かうか」 - ブロッコリーのブログ 作るコスト <<< 取り下げるコスト 作るのが簡単になった一方、リリースしたものを取り下げるコストは変わらず高いままです。B2Bではこれがより深刻で、ほとんど使われていない機能でも、一社でもその機能で業務を回していれば取り下げコストは大きくなります。特にカミナシのお客様は製造業の現場であり、会社ごとに業務フローの差異が大きく、プロダクトが業務に深く食い込むためこの非対称性はさらに大きいです。「何を作るか」の精度を上げないまま作る量を増やすと、メンテナンスコストだけが積み上がります。 AIで空いた時間は何に使うか AIで空いた時間は、新機能を増やすのではなく 何をどこまで作るかの精度 作ったものが「顧客に届くまで」の速度 を上げることに使うべきだと考えています。コーディングだけが速くなっても、顧客検証まで含めた開発フロー全体に詰まりがあれば、顧客に価値が届くスピードは変わりません。速さを価値のスループットに変えるには、ボトルネックをコーディングから段階的に遠いところへ広げ、顧客に価値が届くまでの全体として捉える必要があります。 「点として速い」だけでは意味がない。AI時代のプロダクト開発で本当に大事なこと【Bet X】｜LayerX ボトルネックを追う 自分が実践してきたことは、次のステップの繰り返しです。 ボトルネックを見つける — コーディングが速くなった今、ボトルネックはコーディング以外にある スケールしないところに自ら入る — 入ることで初めて、何がボトルネックで何がスケールの余地なのかがわかる 得た知見をプロダクトに還元し、スケールできるところは技術で解決する ここからは、コーディングから始まり、徐々に遠いところへボトルネックを追っていった流れを話します。 コードレビューのボトルネックを解消する AIでコーディングが速くなった後、最初に直面したのはコードレビューのボトルネックでした。 Claude Codeで実装速度が上がった結果、コードのフィードバックやレビューが追いつかなくなりました。1人エンジニアの体制なので、レビュアーは自分自身とチームメンバーです。AIが書いたコードの品質担保が課題になっていました。 AIが生成したコードをレビューしてみると、指摘点が多く、レビュー自体に想定以上の時間がかかっていました。そこで、静的解析やAIレビューを導入し、コードレビューの負荷を下げました。設計ルールをdependency-cruiserなどで機械的に強制し、AIが生成したコードの品質をプロセスで担保する仕組みを作りました。詳しくは以下のブログに書いてます。 kaminashi-developer.hatenablog.jp 顧客理解のボトルネックを解消する コードレビューのボトルネック解消と合わせて、次に顧客理解のボトルネックに取り組みました。 私(エンジニア)やデザイナーが後からチームに入ったため、顧客やプロダクトについての知識がありませんでした。「なぜこの機能を作りたいのか」「顧客がどういう仕事をしているのか」がわからず、詰め切れていないところを都度他の人に聞く必要がある。顧客理解の薄さが、コミュニケーションコストと判断の詰まりとして現れていました。 そこで私やPM、デザイナーなど含めて顧客訪問やヒアリングに自ら行きました。多い時には週1〜2回ペースで訪問しました。 補足 カミナシには「現場ドリブン」というカルチャーがあり、プロダクト開発に関わる人も積極的にお客様の現場に行く土壌があります。昨年は会社全体で3900回訪問しました。 カミナシの現場訪問回数は3900回/年 エンジニアが現場に行く意味 「AIで二次情報はいくらでも取れるようになった今、差別化できるのは現場でしか取れない一次情報です。」 PMやセールスを通じた伝聞では、情報は「要望」や「課題」として整理された形で届きますが、大事なのはその裏にある背景です。なぜその機能が欲しいのか、どんな業務でどんな事情があって出てきた声なのか。綺麗に整理された要望から背景を組み立て直すのは難しいので、エンジニア自身が現場で「なぜ」を聞いてはじめて、複数の要望を抽象化したり、もっとシンプルに実現できると判断できるようになります。 実際に新規プロダクト開発チームでヒアリングに行ったことで、顧客ごとに異なるプロダクトの重要な値が、実は設定値の組み合わせで表現できるとわかりました。その定義を体系化し、ドメイン知識の勉強会を行ったことで、チーム全体の資産にできました 顧客検証に開発を従属させる 顧客理解が進んで開発が動き出すと、次に見えてきたのは顧客検証そのものがボトルネックだということでした。 たくさん作っても、お客様にヒアリングできるのは一部です。検証のタイミングや範囲には上限がある一方、開発はAIで速く動く。全体のスループットは顧客検証で決まるため、開発をそれより速く動かしても、仕掛かり品のように検証されない機能が溜まるだけです。そこで顧客検証に開発を従属させるため、次の2つを組み合わせました。 1. 作るものを、検証で聞くべきことに絞る 限られた検証機会は「正解がわからず、お客様に聞かないと判断できないもの」に集中させます。具体的にはプロダクトのコア機能や、お客様の業務課題を本当に解決できるかに関わる部分にフォーカスしました。逆に、設定画面のような一定のベストプラクティスがある部分は、検証も実装もせず、設定に必要なデータは自分が直接投入することで代替しました。 2. 作るタイミングを、検証のサイクルに合わせる チームで「次の検証で何を聞きたいか」を合意し 事前ヒアリング → 開発 → お客様に使ってもらう → フィードバック持ち帰り のサイクルに開発スケジュールを合わせました。余った開発リソースは他のボトルネック解消などにあてました。 この2つの判断により、開発と検証が同じリズムで回り、「作ったのに検証してない」機能を溜めず、本当に必要な機能だけを開発できる状態になりました。 顧客訪問をスケールさせる 検証サイクルが回り始めると、顧客訪問そのもののスケールしにくさが次の課題になりました。さらに人と人とのコミュニケーションや移動が発生するため、訪問に多く行く人の周辺業務の負荷も大きくなっていました。ここで次の2つに取り組みました。 一次情報をチームで共有 & 活用する 一次情報をチームで共有、活用するための基盤は、カミナシのUXリサーチャーが以前から整えてくれていました。Centouというサービスを使って顧客訪問で得たインサイトを蓄積・検索できる仕組みが、会社全体で運用されています。新規プロダクト開発チームにもリサーチャーが入ってくれていて、この基盤の上にインサイトを貯めていくことで、現場に行かなかった人もいつでも一次情報を取得できる状態が作れました。訪問自体がスケールしない以上、得た情報をスケールできる形で蓄積して活用することが、チームとして一次情報の解像度を上げることにつながっています。 centou.jp 周辺業務をAIで楽にする 日々の仕事が忙しい人こそAIを活用したいのに、仕事に追われて導入が進められていない。そんな状況がありました。エンジニアへの導入とは違った観点が必要で、具体的には以下の取り組みをしました。 AI活用の主導: チーム全員のAI活用状況を事前アンケートで把握した上で、ClaudeやConnectの導入、セキュリティ面を含む運用設計、既にAIを活用している人からのユースケース共有までをまとめて実施しました。結果としてエンジニア以外のロールへのAI活用展開につながりました。 Google Docs/Drive/Slides連携MCPの自作: 公式のGoogle MCPがうまく動作していなかったので、自作して社内展開しました。以前なら公式の修正を待つしかありませんでしたが、AIを使えば1日足らずで実装できたのはAI時代ならではの変化です。 一次情報の基盤を整えたこと、AIで周辺業務を軽くしたことで、スケールしない顧客訪問そのものに時間を使い、そこで得た情報をチーム全体で活用できる状態になりました。 補足 別チームのPMも似たようなことを試行錯誤しているようです。こちらもぜひ読んでください: プロダクト開発を加速させる ー ビルドトラップの向こう側へ｜migi 商談獲得のボトルネックに飛び込む ここまでのボトルネックが軽減されて実際に使っていただいた数社から高い評価を得られると、次は「価値の確からしさを、より多くのお客様で検証する」フェーズに入ります。ただ、狙っているセグメントで十分な数のお客様に触れてもらうには、手前の「顧客獲得」自体が足りていませんでした。顧客に価値が届くまでの全体を視野に入れたとき、顧客獲得はその一番元にあるボトルネックです。コーディングから始まった動きが、ここまで遠いところに辿り着きました。 展示会に乗り込む 新規プロダクトの顧客獲得には既に、既存顧客へのアプローチ、マーケメール、ハウスリストへの架電などの施策が動いていました。それでも理想としている商談獲得数には届いていませんでした。追加の打ち手として、既存サービスが出展する展示会で新規サービスも一緒に紹介させてもらうことになり、私もここにコミットすべく乗り込みました。 展示会に行くのは、商談獲得のためだけではありません。ここも一次情報の現場です。どんなサービスが世の中にあり、顧客がどんな課題を抱えて何に興味があるのかを大量にインプットできる場でもあります。エンジニアなどサービス側の人間が顧客獲得に関わりたい場合、展示会は最も良い機会だと考えています。 ただ「エンジニアが来ました」だけでは意味がありません。1戦力として活躍するため、事前にマーケの人に話を聞き、社内の展示会ドキュメントを読み込み、疑問点を解消した上で当日に臨みました。 行ってみてわかったこと 結果として複数件の商談を獲得できました。それに加えて どういう課題を抱えている顧客がこのサービスに興味を持つのか どういう機能の話をするとお客様が「使ってみたい」となるのか を実感を持って理解できました。Salesからの「こういうことを言われているので、この機能が欲しい」という要望に対して背景から理解できるようになりました。 一方で、展示会ではカミナシのサービス全体での商談獲得という目標もあり、自分たちのプロダクトにマッチしない顧客には他のプロダクトの話をする必要があったり、かけた時間に対してプロダクトへのフィードバック量は顧客訪問ほどではありませんでした。展示会自体も技術でスケールさせづらく、エンジニアリングを活かすのも難しい領域です。 それでも行ったことで「ここはどの程度自分が入る価値があるのか」を判断できるようになりました。スケールしないところに自ら入ることの価値は、大きな成果が出たときだけにあるわけではありません。入った上で次のボトルネック選定の精度を上げられること自体が価値で、一度もやらずに選択肢から外すのは勿体ないです。 まとめ 目指していたのは冒頭で書いた2つでした。 何を作るかの精度を上げる 作ったものが顧客に届くまでの速度を上げる サイクルの順序は計画して決めたわけではなく、目の前のボトルネックを一つ減らすと次のボトルネックが自然と見えてくる、という繰り返しでした。 エンジニアの価値は、コードの外にも広がっている ヒアリングも商談も、エンジニア以外ができることです。しかしエンジニア自身がそこに入ったからこそ、顧客の課題やどんな機能がどんな顧客に響くかを実感として持てるようになり、その理解がプロダクトに還元されました。一次情報を持ったエンジニアが、他のロールと並んで意思決定に加わる。というところにエンジニアの価値が移りつつあると感じています。 作ることが簡単になった今、エンジニアの価値はコードの中だけでなく外にも広がっています。スケールしないことを自ら選んでボトルネックを見つけに行くことが、AI時代のエンジニアに求められるようになると考えています。 今後やりたいこと 人と人との情報共有は依然としてボトルネックになりやすい領域です。周辺業務や情報共有を技術でスケールさせましたが、まだ「人が情報を整理して共有する」構造は変わっていません。 今後取り組みたいのは、AIを軸にした情報設計です。Slack、顧客訪問記録、商談記録といった一次情報からAIがドキュメント（PRD等）を生成し、さらにそのドキュメントから元の一次情報にいつでも辿れる状態にする。情報の流れそのものを設計することで、情報共有のボトルネックを人の努力ではなく仕組みのレベルで解消したいと考えています。 参考書籍 ザ・ゴール ― 企
- 生成AI
- プロダクト開発
- エンジニア
- 顧客理解
プロダクトマネージャやデザイナがAIでプルリクエストを作成できるプロセスを作ろう
プロダクトマネージャやデザイナもAIでプルリクエストを作成できるプロセスを作ろう こんにちは。息子と『ドラベース』を読みはじめた daipresents です。トンボール投げたい！ カミナシでは「カミナシ 教育」と「カミナシ 従業員」のマネージャを担当しております。 前回、月1回のオンサイトにおける取り組みを紹介させていただきました。 参考： エンジニアじゃない人でもAIを使えば開発貢献できるんじゃないの？イベントを開催してみた こちらについては、プロダクトマネージャやプロダクトデザイナの評価はとても高く、「もっとやりたい！」、「リリースしたい！」と、みんな開発に対する意気込みを表明してくれました そこで、翌月のオンサイトでは、今回はさらに一歩進んだ取り組みとして、「イベントでやるだけでなくて、開発フローに組み込めないか」を実験してみました。 しかし、実際にプロセスに組み込んでみようとなると、課題が出てきます。 オンサイトの様子 課題1： 動作確認環境をどうするか？ AIの登場によって「作る」はとても簡単になりました。ひとつめの課題は「作ったものをどうやって確認するか」です。 僕のチームの場合、環境としてローカル環境や開発環境等を活用していますが、プロダクトマネージャやプロダクトデザイナはこれまでブラウザで開発環境や本番環境にアクセスするぐらいで十分でした。 しかし、自分が作ったものを動作確認するとなると、共有で利用している開発環境は使えませんし、本番環境に反映するのも難しい。 よって、今回はローカルでの動作確認ができるように、環境構築を進めました。 エンジニアが用意してくれた非エンジニア向けの開発環境手順書 必要なソフトウェアやGitの初期設定までを解説したドキュメントによって、環境構築がどんどん進みました。 また、プロダクトマネージャやプロダクトデザイナのやる気もすごく、忙しい間をぬって環境構築に時間を割いてくれたのも勝因のひとつだと感じています。 次のチャレンジとしては コマンド一撃で環境構築される仕組みを作る プルリクエストごとのプレビュー環境を用意する クラウド環境にログインしただけで開発できる・・・ といったアイデアもでてきています。 課題2： プルリクエストまでの開発お作法をどう教えるか？ こちらに関しては、前のオフサイトでやったように、翌月のオフサイトで時間を取って、エンジニアとペア作業を行いながら、開発開始、修正、プルリクエスト作成までを学んでいただきました。 前回で開発の流れをだいたい掴めているので、プロダクトマネージャやプロダクトデザイナの理解度はとても高かったように思います。 ここで問題になったのは、非エンジニアが出したプルリクエストをどう処理するか？です。 通常の開発の流れだと、 修正者が修正の意図と、修正したコードをセットにしてPRを作成する 別のエンジニアがプルリクエストを確認して、フィードバックを行う 問題がなければプルリクエストはマージされる となりますが、非エンジニアに対して難しいフィードバックをすると・・・ プロダクトマネージャやプロダクトデザイナがプルリクエストを作成してエンジニアにレビュー依頼する エンジニアが「このループ、計算量が $O(n2)$ になっているので、$O(n)$ に落とせませんか？」みたいな小難しいフィードバックをしたとする プロダクトマネージャやプロダクトデザイナは、レビューのフィードバックをClaude Codeに投稿して対応する エンジニアがさらに小難しいフィードバックをする プロダクトマネージャやプロダクトデザイナは、レビューのフィードバックをClaude Codeに投稿して対応する ・・・ こうなってくると、フィードバックの反映に「人間を挟む意味とはなにか？ 」を人類代表として考えこんでしまいます。 よって、現在は、 プルリクエストを作成するところまでをプロダクトマネージャやプロダクトデザイナの責務とする ただし、プロダクトマネージャやプロダクトデザイナ視点で必要なフィードバックはコメント等で行う プルリクエストのレビューからマージはエンジニアが担当する という形で実験運用しています。 プロダクトマネージャやプロダクトデザイナがコードベースに貢献する世界線の誕生 まずはオフサイトで作成したプルリクエストが翌週以降、ぞくぞくとリリースされました。 PRの一覧にプロダクトマネージャやプロダクトデザイナのアイコンが並び、どんどんApproveされていく。 その後も継続的にプルリクエストが投稿されるようになってきました。 今回の実験を通して感じたのは、軽微な修正はプロダクトマネージャやプロダクトデザイナ主体のプルリクエストで十分プロダクト改善できることです。 上記のように「ちょっと不便だな」と感じる部分は、やることリストの優先度が低くなりがちです。一発目のリリースに入れられなければ、二度と優先度が上がることなく、永遠の優先度低としてやることリストの下の方に残り続けがち。心理的にも「なんだかなぁ」という気持ちになります。 しかし、AIの登場で開発のハードルが低くなったことから、エンジニア以外が戦力としてコードベースを改善できる世界線が実現しました。 もしかしたら、カスタマーサポートやカスタマーサクセスが同じ動きをすると、CRE(Customer Reliability Engineer) に近い存在になるのかもしれません。 最後に、この企画を考えてくれたエンジニアからのコメントがこちら。 プロダクトマネージャやプロダクトデザイナに使ってほしいのは、こうした環境でプロトタイピングしたりデザインや企画の叩きを作って考えてもらうことです。 その後、プロダクトデザイナによる体験向上の提案がプルリクエスト上で出てきました。そのデザイナはローカルで実装をすませ、実際の動きを見せながらチームに説明。採用されたものはそのままリリースへと進み出しています。なによりもこの貢献が 「楽しい」 そうです。 AIとの付き合い方はまだまだ実験が必要そうですが、開発を「楽しい」と思ってくれる人が増えたのは、AIのおかげかもしれませんね。
- 生成AI
- プルリクエスト
- 開発プロセス
23歳、平凡なエンジニアワイ。AIと不安で眠れない夜。決意の朝に。
AIと不安で眠れない夜。 あ〜〜〜〜〜今日もTwitterのタイムラインはAI、Claude、OpenClaw、エーアイ、Codex、Gemini、ハーネスの話題で持ち切りだわ。なんだよハーネスって。自意識過剰なホモサピエンスがAI様をコントロールできると考えているのか！？奴らの成長速度を考えたら、数年以内に制御できる範囲なんてとっくに飛び出して二足歩行でコンビニ行ってオハヨーのブリュレアイス買って食っとるわ。あれうますぎだろ。 あ〜〜〜〜〜わかってるよ。Twitter呼びは時代遅れだって？そのツッコミも飽きたわ！俺は死ぬまでTwitterって言うからいちいち気にしないでくれ！ ジュニアやミドルエンジニアは不要？そうかもね！日々開発して身に染みてるよ。 と思ったらなに！エンジニア自体不要？SaaSも is dead？まだ俺は生きてんの！勘弁してよ〜〜〜〜〜〜〜。 漠然とした焦燥感と、描いていたキャリアプランが夢のまた夢となりそうな不安で、毎日押しつぶされそう。なんとなく寝れない。なんだったら日中もそのことがよぎる。 無駄に頭の稼働率が高い。生産的なわけではなく、鞭打って動かされてる感。俺の脳こそハーネスつけてレースさせられてんじゃね。誰か俺を、人々を助けてくれ〜〜〜〜。 オス！オラりくう。カミナシでソフトウェアエンジニアをやってる。23歳。実は大学を中退して就職したのでエンジニア歴は3年。石の上にもってヤツ。 AIと差別化するためにM-1グランプリに出たりしてる。笑いのセンスはまだギリ人間が勝ってるらしい。なんとか大学の研究でなんか証明されてた。 （左：かわりく。右：文章後半で登場する強いエンジニア） M1出たときの写真 一般的には経験年数3年以下はジュニアエンジニアに分類されるらしい。もちろん年数なんて本質的じゃない。転職活動ではミドルだと言い張って、都合が悪いときにはジュニアということにする。 オラと同世代は新卒か年数的にはまだジュニアな人が多いと思う。だから漠然と同じような不安とか悩みを抱えてんじゃないかと思って、今日はその悩みをみんなと共有したい。共感したい。慰め合いたい。傷を舐め合いたい。安心して！この文章は100%オーガニックライティングだから、SDGsへの配慮もバッチリだ。 徒労感 インザスカイ 今自分が身につけようとしてるあらゆる技術や知識が、明日には陳腐化してるんじゃないかと考えてしまう。AIの進化速度の前では、相対的に全ての営みが差別化にならなくてゼロになってしまうという不安。徒労感。タイパとか言いたいわけじゃなくて、バイブでできるなら俺の努力意味なくね？と思うのは自然な感情だと思う。 さらば自己効力感 最近は仕事でうまくいかない事があると、AIをうまく使いこなせていないせいなんじゃないか？という思考に陥る。それもある側面では正しいが、AIの応用ばかりに目がいって、そもそもの問題の本質に向き合う機会が減ってしまっている気がする。自分の頭を働かせるよりもAIに考えさせたほうが確度や効率が良いのでは？と思ってしまう。 ちょっとSNSを覗くと、バイブで完璧にサービスを開発して提供しています！みたいな極端な成功例が多くて、日々の仕事のインクリメンタルな成果が陳腐に見えてしまう。 AIは強いヤツを更に強くする。 AIは確かに強いヤツを更に強くする。べき乗的なバフをもたらす。 周りを見ると、元からめちゃくちゃ強かったエンジニアがAIによって半端なく強くなっている。とある知り合いはAIと共にOSSにコミットしまくり（AIスロップ的なやつじゃなくて、ちゃんとマージされてる）、CVEを取得しまくり、バグバウンティで稼いでる。かっけえ。 それを見て卑屈になるなど。 キャリアプラン？目標設定？そんなのわかんないよ！！！ 今まで当たり前に思い描いていた、先輩の背中を追うんだと思っていた未来は知らぬ間に波にさらわれた... ど、どうなるんだ？俺は。俺達は。エンジニアは。そして人類は... 全てはLLMのモデルの進化が解決する。全ての問題と俺はその時が来るのを指を咥えて待っているだけなのでは...? 5年後にどうなりたいか？わかるわけないじゃん！5年後に何が残る？ 目標設定？今はLLMモデルの進化そのものの影響がでかすぎて、適切な目標もよくわかんないよ！ でも、そんな俺にも快眠できる夜があったのさ... 自分の門外の技術領域・言語（画像処理・C++）に触れる機会があった。 よ〜わからんなという感想で終わってしまいそうだったが、今の俺には最強のバディがいる。ヤツに質問しながら、時には図解してもらったり、呪術廻戦で例えてもらったり、完全オーダーメイドマンツーマンを施してもらった。 わかる...!!!着実にわかるようになっている...!!!を実感した。一昔前なら相当苦労しただろう。まずは言語の文法から押さえ、数冊のデカくて高い専門書を読み漁り、ようやく出発点に立てただろう。しかも忍耐がないと中途半端に手放すことになる。 ヤツはどこまでも寄り添って教えてくれる。結果的にめちゃくちゃ素早くキャッチアップし、新機能を開発できた。素早くアウトカムを出せた。 自分が今まで得意だと思っていた技術領域をAIと開発しているとき、無力感に襲われていたが、新しい領域に踏み出したとき、その可能性と純粋な知の喜びを思い出した。 また、最近は半端ない速度でプロトタイピングができるようになった。それこそバイブで。でも明らかにソフトウェアエンジニアだから出せる速度だと感じる。 技術の直感がないと、そもそも問題の切り分けが難しい。 要求や仕様の前提が複雑すぎるのか、技術的に難しすぎるのか。とりあえず作る。の前段階で整理ができる。結果としてまともに動く状態に達するまでが早い。 結果的に素早くフィードバックを得られるし、その回数を増やせるので、最終成果物のクオリティが高くなる。ニンマリホッコリした。 決意の朝に（かわりくの場合） 気づいた。俺は、AIを、自分の成長速度の鈍化の言い訳にしている！！！！！ AIは本当にすごい。Bet AIすべきだ。ただ、そのことと自分の成長を諦めることとはなんの関係もない。 自分のフットワークの重さをAIのせいにして、頑張ることを諦めている。コンフォートゾーンに留まっている。 負けるな！負けるな！でも戦う相手はAIじゃない。自分自身だ。 そして23歳はまだ若い。というかあまりに若すぎる。いくら17,18のインフルエンサーが活躍していて卑屈になる夜があっても大丈夫。まだ若い。 だからサンクコストを恐れるな！今まで積み上げたもの？少なすぎる！たかが10年とかの積み上げを大事に守るな！これから生まれる無限の新しいチャンスに挑戦しよう。悲観的な未来を想像することには意味がない。AIといっしょに楽観的な未来を創造しようじゃないか。 宣伝 と、ここまでAIに対する不安を爆発させつつ、カミナシのエンジニアがどうやってAIと仲良くやってるかトークするイベントを開催しますので、ぜひご参加ください。AIすげぇ…怖い…と僕と一緒に怯えましょう。 https://kaminashi.connpass.com/event/387233/
- 生成AI
「AIと一緒に開発する」を本格始動して 1ヶ月の振り返り
「カミナシ レポート」の開発・運用をしている furuya です。最近我が家では成長してきた子どもたちのことを考えて寝室含めて部屋の配置換えを検討しており、そのパズルに頭を悩ませています。それはさておき今回は「カミナシ レポート」の開発において AI Agent を主軸にした開発スタイルを取り入れたお話です。 背景 近年の AI Agent の進化は目覚ましいですね。日々情報がアップデートされる中、カミナシのエンジニアリング組織としてもこの流れについていかなければならない、ということで各チームいろんなことにトライしており、組織的にもそれが推奨されています。もちろん、前提として以前から GitHub Copilot や Claude Code などの Coding Agent を開発に取り入れています。そんな中で個人的に感じた課題と同時期に得た学びがカチッとはまる出来事がありました。 課題 以前の開発スタイルはこうでした。 1週間スプリントのスクラム PdM、デザイナー含めて PBI をリファインメントする ここでおおよその実装方針の合意やフロントエンド・バックエンドそれぞれでチケットを作成し、ストーリーポイントを見積もる ストーリーポイントをもとに1スプリントで捌くチケットを決め、おおよそ1チケット1担当者で分担して開発を進める フロントエンドは xx さん、バックエンドは yy さんといった具合 それぞれが自分の進め方（AI Agent の使い方含めて）で進める Copilot Instruction 等チームで共有すべきコンテキストは随時整備している 2025年12月頃、しばらく私が重めのインフラ構築をやっており久しぶりに開発に戻ってきました。今までの進め方自体に大きな問題はなかったのですが、あらためて1人で開発を進めているときに以下の課題・違和感を覚えました。 リファインメントの段階では見えていなかった詳細な要件が、実装フェーズに入ってから顕在化することがある Slack 上で非同期で PdM やデザイナーに確認するだけではありつつ、待ちやラリーが発生するため結局同期で話すことも Agent が出してきたコードをレビューしきれない 一度に多く出てくると目が滑るのと、個人的にはフロントエンドの引き出しが少ないのでセルフレビューに不安が残る Agent によってコード生成は早くなったが、レビュー依頼を出したあとアンコントローラブルになる・待ちが発生する スプリントゴールに紐づくアイテムの場合はもちろんみんな優先して見てくれるものの、それぞれタスクを持っているのもありいつ終わるかは明確ではない AI-DLC という考え方との出会い ちょうど同じ頃、AWS re:Invent 2025 への参加をきっかけに AI 周りの解像度が高くなった中、AI Builders Day というイベントで AI-DLC という手法に出会いました。 speakerdeck.com 詳細は上記 AWS 金森さんの資料などをご覧いただければと思うのですが、この話を聞いた瞬間に「チームでやってみたい！」と思いました。先程の課題は AI-DLC の考え方を適用することで解決できるのでは？と感じたからです。もちろんいきなりスクラムをやめるまでいくと混乱しそうなので、「AI Agent 主体で進める」「ペア・モブプロで進める」というあたりだけでも取り込むことで以下の効果が期待できるのではないか、と思いました。 AI による観点が加わることで要件のヌケモレに気づきやすくなる 要件を人間 + AI で決め、そのままドキュメント（requirements.md）に落とし込むため 熟練者のレビュー観点・引き出しを盗める みんなで AI Agent の出したコードをその場でレビューすることのメリット PR作成からマージOKのリードタイムが短くなる みんなでレビューするので、待たなくてよさそう チームに持ち込む AI-DLC の解像度はあまり高くないままではありましたが、上記の課題感およびこんな手法があってね、という話をチームに持っていき、やってみよう、ということになりました。チームとしてもメンバーの入れ替わりや長期離脱の予定があるなど変化の激しいタイミングであり、生産性を落とさないため & AI への投資ということで意見が一致しました。 やってみた 本来の AI-DLC のやり方、というよりはスクラムの形を保ったままとりあえずやってみるということで、どちらかというと仕様駆動開発として AWS の AI-DLC workflow を使う、というほうがイメージに近そうです。 github.com Agent には主に kiro（kiro-cli）を使っています。スタートアップ向けのクレジットをいただいたので、使わないと損だなと個人的に思っているからです。workflow 自体はいわばプロンプトでありどの Agent にも組み込めるため、 Claude Code でやってみるターンもあってもいいかもしれません。 まずはペア or モブで進め、スクラムの形は変えない、というところからスタートします。ここから少し長いですが、4スプリント分のゴール設定・結果・振り返りについて共有します。 1週目 ちょうど直近大きめの開発アイテムがあったため「リファインメント + ちょっと実装まで進んでいる」をゴールにしてトライしました。 結果として、リリース順序やデータベースの変更等も考慮して Phase を4つに分割し、それぞれの設計までできました。また Phase 1 の実装は PR の作成まで完了しました。以下振り返りです（以降同様のフォーマットです）。 Phase ごとにわけて「設計だけやる」はイマイチかも 設計を進めるには前の実装が終わっていることが前提で、かつ設計のみ進めた場合前の Phase の実装がまだないので Agent が混乱する 開発体験としてはポジティブ、workflow に則って設計開発進めること自体はよさそう PR の粒度や Design Doc の渡し方など改善ポイントが見えてきた このアイテムに関してはいったんこの進め方で最後までやってみる が、見積もりをしないのでいつ終わりそうか、みたいなのが言いづらくなる懸念も もちろんダメそうだったらすぐ止めるということも合意する 2週目 前週とは別のアイテムを対応する必要があり、そちらで引き続き workflow に則って実施しました。 設計 & 実装は1日で完了（フロントエンド、バックエンドともに）し、2日目にガッツリレビューをするという流れで難なく完了まで持っていけました。 1日ガツっと実装して次の日別れてレビューなどに回すのはアリかも やっぱりずっとやり続けるのはちょっとしんどい 真の AI-DLC を実践してるところは永久にペアプロしてるらしいけど… GitHub Copilot が PR でいっぱい指摘くれるので修正する時間や、次のアイテムの下準備の時間が必要 3週目 1週目で分割したアイテムの続きに取り組みました。また、新たなトライとして以下を検証しました。 Figma MCP サーバーを使ってフロントエンドの実装を楽にできるか検証する フロントエンドとバックエンドのリポジトリが別れているが、いい感じにまとめて設計実装できないか試行錯誤する 最終的にモノレポがいいのであればそれも視野に入れる トライ多めだったので実装は思ったところまでは進みませんでしたが、その分収穫がありました。 Figma MCP サーバーを使って実装してもらうとデザイナーが作ったものがそのまま反映できてよい（それはそう） Figma に情報がある場合はデザイナーと一緒にフロントエンド実装できるとよさそう なんならデザイナーがドライバーになって進めてもらった（実装できるデザイナー！） 設計をフロントエンド・バックエンド両方いっぺんにやると設計のターンが長くなりがち デザイナーと一緒にモブしたいのは、UXにまつわる要件の整理とフロントエンドの実装タイミングなのでうまいことできないか考える（待ち時間の削減） 4週目 引き続き Phase 3 の実装を進めます。この週は kiro の steering の整備をしました。steering は Claude Code でいうところの Claude.md のようなもので、チームで共有すべき永続化したい知識をまとめたドキュメントです。 あと一歩のところでゴール未達となりましたが「1週間でこれくらいまで進めることができる」というラインをまたひとつ得ることができました。 steering を整えることでセルフレビュー観点の質が向上した 開発側でも活用できるように引き続き育てていく 1ヶ月を振り返って やり方についてはポジティブ もちろん課題・伸びしろはいくつもあるのですが、それをよくしていけばなんだかよさそうである、というのがメンバーの総意です。 最初に狙っていた効果は？ AI による観点が加わることで要件のヌケモレに気づきやすくなる これは実際救われたケースがあります。重複するのですが、UX観点ではやはり AI による視点 + デザイナーと一緒に作業することで効率よく体験を決定できました。 デキる人のレビュー観点・引き出しを盗める PR作成からマージOKのリードタイムが短くなる その場でのレビューも行うもののやはりガッツリレビューするのは落ち着いて次の日にやる、といったスタイルが今のところチームにあっていそうです。もちろん会話する中での気づきもあったりその場でコードやテストを Agent に直してもらったりすることもあるので、この点については中長期的に見ていくものになりそうです。 生産性あがったの？ AI-DLC が狙うのは生産性を数倍に引き上げるというものですが、今回はその一部を取り入れてみた、というものになったのと今までのスタイルと単純な比較ができないので正直なところ不明です。ただ、チーム外から見た感覚だと「思ったより早く進んでいる」「ケイパビリティが上がったように見える」とのことで、ちゃんといい方向で効果が出ていそうです。おそらく以下のようなことだと推測しています。 明確に仕様駆動開発に寄せることで AI Agent の使い方を統一でき、効率があがった 今までだと、コンテキストとしてのコーディング規約などは整備していたものの、実際に実装するときは各自 Agent に要件のプロンプトを渡してどちらかというと Vibe Coding チックに進めていた ペア・モブでも捌くチケット量は変わっていなさそう（か、少し増えた） 1つめの要因のこともあり、2人で進めても今までの2人分くらいがきちんとできている = 人によるばらつきが減って安定して速度を出せていそう ペア・モブの時間だけで今までのチケットを捌けているので、それ以外の時間でやれることが増えた 逆にレビューDayはレビューと修正に集中できるので、時折やってくる他チームからのレビューなどにも応えやすくなった = ケイパビリティが上がったように見えていそう これから AI-DLC という考え方に出会い、一部ながらもチームに取り入れて1ヶ月取り組んでみました。実際どれくらい効果があったのか定量的には判断しがたいのですが、AI Agent を主体にした新しいスタイルを採用したことで安定して開発速度をキープできていそうであり、これはチームの状況が変わったとしても価値を提供し続けることができる基盤が整ったと言えそうです。 まだ課題・伸びしろはあるのでこれらを良くしていきたいですし、あるいはこれを突き詰めていけばひょっとすると「真の AI-DLC にしないとダメだ！」といってスクラムをやめる日が来るかもしれません。大事なのは振り返って改善することと、まだまだ AI に投資していくことだと思うので、自分たちのペースで取り組んでいきたいです。
- 生成AI
- 開発プロセス
- ペアプログラミング
デブサミ2026 Day2 初参加レポート
はじめに 「カミナシ レポート」を開発しているかわりくです！ 日本最大級のテックカンファレンス、Developers Summitに初参加してきました。 2日目のセッションの感想や持ち帰れそうなことをメモっております。 会場の雰囲気は、デデデデカイ！規模がデカい！今まで参加したどのカンファレンスよりも人の数と会場のキャパシティと、ブースの数が桁違い...！スタッフさんも多い...!ありがとうスタッフさん...! タダでサンドイッチもらってごめんなさい...!スタッフさんの分まで楽しみます！ 興奮しながらの入場となりました。 （2026/2/19終了後、最速レポとして投稿されたものです。） beyond the code（デブサミ26のキャッチコピー） セッションレポート LLM利用率80%への道筋：ピクシブが実践した「People・Process・Technology」三位一体の変革とは？ 登壇者: bash（ピクシブ） 川口 修平（GitLab） セッション詳細 ざっくりまとめ ピクシブさんが自社の開発者向けにLLMの利用を推進していく中で、組織にどんな変化が起きたか？という話。Technology、Process、Peopleの3つの要素が相互に変化を起こし続けるのがポイント。 (Technology)開発プロセスをツールチェーンで構築するのではなく、AIによる開発支援の強力なパイプラインを持つプラットフォーム(GitLab)を採用。ツールの選定やアップデート、チーム間の知見共有のコストをごっそり削減した。 (Technology)リリース前にセキュリティ診断を「一方通行で」やるんじゃなくて、GitLabの基盤で常にセキュリティ診断が回り続ける仕組み（DevSecOps）を作った。 (Process)開発プロセスに対する健康診断の仕組みでボトルネックを特定する。経営層もAI推進にコミットする。 (People)開発プロセスの全てを行うWhole Teamとしてチームを設計する。AIをチームメンバーと考えてチーム設計をする。 クローズアップ 「エンジニアリングとは、再現可能なプロセスを確立して継続することである。」ピクシブさんの社内Docに書かれた言葉らしい。AIによってエンジニアは不要になる・何を作るか？だけが重要になる。といった言説が増えたが、エンジニアの価値は再現性とそれを持続すること。そう考えると、AIが爆速でコードを書いてくれることと、エンジニアの本質的な価値はバッティングしないどころか、互いに補完しあう存在だと思った。 統合開発プラットフォーム（GitLab）に組織横断的なAIパイプラインを敷くことで、ツールや開発プロセスのサイロ化を防ぐ。一方で、コーディングツール（Claude CodeやCodexなど）やハードウェア（PC）といった手足の部分には一定の選択の自由度を残す。全てをトップダウンで強制しない、このバランス設計が良いと思った。 持ち帰り 再現性が高く、持続的な仕組みを作る。短期的な再現できない成果"だけ"を求めない。 自チームだと、QAフェーズをもっと開発チームが主体的に取り組むことができるはずなので、Whole Teamとして、QAフェーズにもオーナーシップを持って進められる仕組みをつくる。 意志を実装するアーキテクチャモダナイゼーション 登壇者: nwiizo セッション詳細資料 ざっくりまとめ 書籍からの引用と、登壇者の考えを交えながら、レガシーシステムをモダナイゼーションするためのhowとマインドセットの話。 実装はAIがこなせる時代になったが、組織や事業ドメインを織り込んだアーキテクチャ設計はできない。人が意志を持ってアーキテクチャを設計する。 AIが進化しても、組織の構造や人間の感情など、人の性質は変化しない。組織（人）と技術が相互作用しながら開発を進めるための技術がこれからも必要。 コンウェイの法則（システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう）は避けられない。むしろ利用する。そのためにはドメイン境界をうまくモデリングすることが重要。 技術的負債は事業課題になる。変化に耐えられないシステムは競合に負ける。 クローズアップ ソシオテクニカル。俺たちはコーディングから逃げられたとしても人間からは逃げられない... モダナイゼーションは派手な技術選定より、地味な現状把握。説明しやすい嘘より、説明しにくい真実を話す。 技術負債は開発者体験やデリバリー速度が低下するだけじゃない...!プロダクトが...会社が終わる...! 持ち帰り 技術的負債について議論する時、技術的な課題に閉じずに、組織的な課題をセットで考えます。はい。やります。 人と向き合う時を増やす。 短期的で派手な成果よりも、地道な本質と向き合う。 2重リクエスト完全攻略HANDBOOK 登壇者: 三谷 昌平 セッション詳細資料 ざっくりまとめ フィンテック（2重リクエストが起きたら洒落にならない領域）の開発者が、Webサービスにおける2重リクエストの問題と対策をフロントからバックエンドまで段階的に解説してくれた。 まずフロントで発生頻度を下げる。submitボタンのdisabled化、PRGパターンでリロード対策。これはやらない理由がない。 バックエンドではDBのユニーク制約や状態遷移のバリデーションで、仮にリクエストが到達しても不整合なデータを作らせない。 さらに排他制御（悲観的ロック）やAPIレスポンスキャッシュで、並行リクエストやリトライにも対応する。 意図的なリクエストと事故を区別するために、idempotency-keyヘッダという選択肢もある。 クローズアップ 技術の概要だけでなく、実例が多く、ユースケースがイメージしやすかった。実例があると取り入れやすい。 2重リクエスト対策はめちゃくちゃ手段があって、それぞれのメリデリがあるので、パターンを知っておいて、適切に選択できる必要がある。人が意思を持って選ぶんだ！ 持ち帰り 自分のプロダクトで2重リクエストが起きたら何が困るか、一度洗い出してみる。プロダクトの性質に合わせて優先度を整理して、なんらか解消してみます。やるゾス。 Claude Codeで実践するスペック駆動開発入門 登壇者：吉田 真吾(ジェネラティブエージェンツ/セクションナイン) セッション詳細 ざっくりまとめ 実践Claude Code入門の 著者によるスペック駆動開発（SDD）の話。仕様書を信頼できる唯一の情報源として、コード生成はAIが行うというアプローチとAI-DLCを比較しながら解説。 AIエージェントとは、目標に向けて環境と相互作用しながらタスクをこなす知能システム。ツールを実行し続けるループで目標を達成する。 SDD（Spec-Driven Development）では、spec（要件定義書・実装の設計・タスクリスト）を整備して、AIに実装させる。作業単位で永続的なドキュメントを作ってメンテしていく。 コーディングスタイルだけでなく、spec駆動のやり方自体もclaude.mdでポリシーとして定義しておく。 さらにAI-DLC（AI Development Life Cycle）という概念も紹介されていた。（ちょっと時間内だとSDDとAI-DLCの違いが理解しきれなかった...出直してきます） 簡素なSDDだと、laude.mdの肥大化によるコンテキスト消費、監査ログが残らない、ユーザーとのやり取りの詳細が不十分、といった課題もある。 クローズアップ 「Spec駆動開発は試してみるというフェーズを終えて、当たり前になりつつある」 持ち帰り AI-DLCを理解して、開発プロセスに取り入れます。 コードが物理世界を動かす興奮と責任 ～フィジカルAIの最前線でソフトウェアエンジニアは何と戦っているのか～ 登壇者：梅田 弾(ティアフォー)、山田 勲(T2) 司会：森崎 修司(名古屋大学) セッション詳細 ざっくりまとめ 自動運転業界がどのようにAI開発をしているのか、というパネルディスカッション。 自動運転といっても、センサーやハードだけじゃなく、ソフトウェアもクラウドもめちゃくちゃある。 ハードウェアの制約（計算資源、電源、センサーのタイムスタンプ同期...）がある中での最適化が必要。泥臭い。 あらゆるパーツが壊れても安全に動作する冗長なシステム設計が求められる。（人命かかりすぎてる。尊敬します。すごい。） 以前は技術導入すると後戻りできなかったが、今はシミュレーション環境が整ってきて、新しい技術もスピーディーに試して導入判断ができるようになった。 クローズアップ 「泥臭くやる」を登壇者が何度も強調していたのがカッコ良かった。最先端のAIも、データのタイムスタンプ合わせや電源の接続不良みたいな地味な問題と戦っている。華やかさの裏にある泥臭さ。 ソフトウェア開発を支えるためのソフトウェア。みたいなものをたくさん開発している。（データ不整合に気づく仕組みなど） 持ち帰り webシステムの開発でも「ソフトウェアのためのソフトウェア」（データ品質の自動検出、開発プロセスの自動化）という発想はもっと取り入れられるはず。開発を支える仕組みに投資する意識を持つ。 おわりに day2はサミットの熱量を最速で届けるレポートでしたが、day2,3の通しのレポートは日を改めて公開いたしますので、そちらもチェックお願いします！ 弊チーム積極採用しております！来年はご一緒にデブサミいきましょう！ herp.careers
- 生成AI
- アーキテクチャ
- セキュリティ
- SRE
- 開発プロセス