「アジャイルなんて、製造業のうちには無理だ」——ISO規格や品質保証プロセス、ハードウェアと同期した長期計画。堅牢なものづくりを支えてきた統制の文化は、そのままではソフトウェアの高速な試行錯誤とぶつかります。しかし、変化の速い市場で世界中の顧客に応えるには、開発組織そのものを変えざるを得ない。いま製造業各社が、この難題に正面から取り組んでいます。
2026年6月30日、ファインディ株式会社は「製造業におけるアジャイルシフトの実践知 〜スクラム推進・内製化・AI開発のリアル〜」をオフライン・オンラインのハイブリッドで開催しました。
登壇したのは、島津製作所・リコー・村田製作所という日本のものづくりを代表する3社。全社へのスクラム推進、外注依存からの内製組織立ち上げ、そして生成AI駆動開発の商用適用まで、現場で起きた「壁」と「乗り越え方」が語られました。
本レポートでは、3社の取り組みを単なるセッション要約ではなく、開発組織の課題解決ストーリーとして整理します。
「なぜ今このテーマが重要なのか」「自社ならどう置き換えられるか」を考えるヒントとして読んでいただければ幸いです。
イベント概要
- タイトル：製造業におけるアジャイルシフトの実践知 〜スクラム推進・内製化・AI開発のリアル〜
- 公式サイト：https://jp.findy-team.io/events/manufacturing-agile-shift-260630/
- 開催日：2026年6月30日（火）
- 形式：ハイブリッド（オフライン・オンライン）
- 主催：ファインディ株式会社
- 登壇者：
- 株式会社島津製作所 総合デザインセンター 設計推進ユニット 開発プロセス変革グループ／冨澤 京介 氏（スクラム推進）
- 株式会社島津製作所 分析計測事業部 ITソリューションBU／内林 光優 氏（スクラム実践）
- 株式会社リコー デジタルビジネスイノベーション事業部 アセット開発センター トレードエコシステム開発室 室長／小林 寛 氏
- 株式会社村田製作所 共通基盤技術センター システムデザイン部 シニアマネージャー／森 悠介 氏
セッション① 株式会社島津製作所｜「推進」と「実践」を二人三脚で——全社にスクラムを”選択肢”として根づかせる
セッション概要
創業150年を超える島津製作所。分析計測やヘルスケアなど広範な事業を持つ同社では、全社の開発を支援する立場（総合デザインセンター）と、実際に製品を開発する事業部（分析計測事業部）が二人三脚で登壇しました。第1部は冨澤氏による「推進」、第2部は内林氏による「実践」。
全社に広げる側と現場で回す側の両視点を一つのセッションで示した点が特徴です。
課題・背景
同社がアジャイルを推進した動機は明快です。「世界中のお客様の課題に素早く対応したい」。そのためにはグローバル拠点との連携と、開発の試行錯誤のスピードアップが欠かせません。目標は、社内のソフトウェア開発でアジャイル（スクラム）を”選択できる”状態にすることでした。
ただし、前提には二つの特殊性がありました。すでに一定の内製開発が行われていたこと、そして新技術を獲得・展開する役割の組織（総合デザインセンター）がもともと存在していたことです。ゼロから推進組織を立ち上げた話ではなく、既存の役割の中から広げていった点が実態に近いといいます。
推進側の障壁は二つ。
ひとつはスクラムの知見不足という「よくある話」。もうひとつが製造業で特に顕著な、ISO規格との対応が不明確という問題でした。
規格はアジャイルを否定してはいないものの、ウォーターフォール前提のプロセスに見えるため、導入前に足が止まりやすいのです。
実践側（第2部）の課題はさらに具体的でした。Webアプリ開発において「アジャイルのスピード感で開発できない」。
要因は3つ——(1) 対象業界・ユースケースが多様でドメインが複雑、(2) オフショア・分散開発で認識ズレが起きやすい、(3) 新規開発で設計判断が多い。
結果として仕様確認の往復が増え、レビュー指摘が多発し、スプリント内で完了しない状態に陥っていました。
取り組み内容
推進側の工夫①：伴走支援とガイドライン整備を”並行”させる 知見が少ない状態では「何から始めればいいか」も「どんなルールの説明が必要か」も分かりません。
そこで、事業部への伴走支援（社外の力も借りた勉強会、スクラムイベントへの同席）と、ISO要求事項とスクラムイベントの対応関係を整理したガイドライン整備を、同時進行で回しました。活動そのものをアジャイルに進める——初版をすぐ公開し、現場のフィードバックで改善する。
この繰り返しで、開発者の迷いを払拭しつつ実態に合ったガイドラインへと育てていきました。
推進側の工夫②：関係部門を早期に、広く巻き込む 品質保証部の参加タイミングは、ウォーターフォールなら逐一決まっています。
しかしアジャイルでは内容が逐次変わる。そこで品証の担当者と一緒に「変化に対応できるやり方」を設計しました。
契約・インフラなど観点ごとに10以上の部門を巻き込み、コンプライアンスや品質に関わる重要点は責任部門と共に進めています。
実践側の解決：PBI（プロダクトバックログアイテム）を”設計”する 内林氏が採ったのは、開発判断を最適化するためのPBI設計でした。一般的な基本4要素（ユーザーワークフロー／完了条件・受入条件／要件定義の背景／機能仕様案）に加え、追加で3要素を展開したのです。
- 業務ドメインと既存SWの知見（各業界の条件・制約、データの意味、共通用語）
- 他アプリの仕様や使用するAPIの知識（整合すべき仕様、データ受け渡しルール）
- 設計上の注意点（本アプリが担うロジックの範囲、共通コンポーネントの扱い方）
これにより、複雑なドメインの理解、認識ズレの抑制、スムーズな設計判断が可能になりました。ただしPOの負荷が跳ね上がるため、GitHub Copilotに各リポジトリのドキュメントやIssueを読み込ませ、PBIの叩き台を素早く生成。最終判断はPOが担う形にしています。さらに直近では、この知見自体をAI化。
copilot-instructions.md（全体原則）、.instructions.md（領域別ルール）、SKILL.md（手順）、.agent.md（役割）、Knowledge（知識）を役割ごとに混ぜずに分けて展開し、実構成でagents 5／skills 28に達しています。
もうひとつの課題「振り返りで改善点が出ない」への解は、「振り返る前に観測できる状態をつくる」でした。計測したいメトリクス（完了率、バグ件数など）を選定し、GitHub Projectsのフィールド（Sprint、ストーリーポイント、バグの原因カテゴリ）をカスタマイズ。GitHub Insightsで可視化することで、レトロスペクティブの場で「前スプリントより何が悪かったか」がデータで見えるようになりました。
成果・学び
推進側では、約2年で16プロジェクトがアジャイル開発を実践できる「選べる土台」が完成。実践側では、PBI設計によって仕様確認の往復とレビュー指摘が減少し、スプリント内で動くものができる状態に。知見のAI化により、別の開発でもストーリーポイント基準で数倍速で回るようになったといいます。アジャイル開発の実践知が、他プロジェクトへ横展開できる状態に到達しました。
印象的なコメント
「（活動自体も）並行して進めることで、開発する方の迷いは払拭しつつ、実態に合ったガイドラインも作れる」——冨澤 氏
「振り返る前に、観測できる状態を作ることで解決しました」——内林 氏
このセッションから得られる示唆
- 推進（全社支援）と実践（事業部）を分けて役割を明確化すると、抽象論と現場論の両輪が回る。
- ISOなど規格対応は「規格がアジャイルを否定しているか」ではなく「どの活動で要求を満たせるか」を地道に対応づけると突破口になる。
- PBIは”チケット”ではなく”設計対象”。ドメイン知識・連携仕様・設計注意点まで載せると、分散開発の認識ズレが激減する。
- 生成AIはPBI作成の叩き台生成に効く一方、最終判断はPOが持つ——役割分担の線引きが重要。
- 振り返りを機能させたければ、まず「観測できる状態」をメトリクスで先に用意する。
セッション② 株式会社リコー｜「境界線が消えた世界」で、品質責任を1ミリも軽くせずにアジャイルを回す
セッション概要
リコーの小林氏は2004年入社。約12年、MFPやプロジェクターの組込ソフトウェア開発に携わり、QCD推進部署による強力な全体統制、ハードウェア計画と同期したV字型ウォーターフォールという「統制された世界」を原点に持ちます。2018年、同社のデジタルサービス企業への変革の中で新設組織へ異動。帳票起点の取引業務をDXするSaaS群を、開発チームリーダーとしてアジャイルにシフトしながらローンチしました。現場視点での「壁」と「乗り越え方」、そして生成AI活用の展望までを語りました。
課題・背景
小林氏が繰り返し強調したのは、変化の本質は手法ではなく前提だったという点です。「変わったのは手法ではなく、前提となるすべての境界線が消えた」。閉じたドメイン開発は顧客価値を横断する継続改善へ、HW同期の長期計画は「まず出して学ぶ」へ、開発と営業の部門分業は「製販一体」へ、得意技術の追求は「要件実現に必要なことは全部やる」へ。
一方で、変わらない命題もありました。「どれだけスピードを上げても、製造業としての品質責任は1ミリも軽くならない」。この両立こそが最大のテーマでした。
権限を集約して動き出すと、関連区からは至極まっとうな反応が返ってきます。「2週間ピッチではこちらのプロセスが回らない」「責任は誰が取るのか」。さらに軌道に乗った後には、「アジャイルだから途中で要件を変えていいよね」という誤解が忍び寄り、要件が曖昧化してリリース延期が多発。「名ばかりアジャイル」への転落という罠にもはまりました。
取り組み内容
最初の一歩：品質思想の”適材適所”な再定義 変更が容易でない組込（HW連携）はウォーターフォールが合理的で、手戻り防止を最優先する。一方、高頻度アップデートが容易なクラウド（SaaS）はプロダクトマーケットフィットと変化の許容を最優先し、途中の重厚なプロセスは削ぎ落とす。その代わり、E2E（シナリオ）テストの徹底的な自動化を「出口の強固なガードレール」とし、問題検知とHotFixプロセスを軽量化する。「出口さえ固めておけば、途中はどれだけ打席に立って打っても安全」という設計思想です。
権限（責任）集約のデザイン 事業責任者はビジネスモデル・大方針の変更を決裁し、PO（企画側）が機能要件と優先順位を決める。そして開発チームは「やり方は自分たちで決める代わりに、自発的に専門区を巻き込む責任を負う」。自分たちが作るものを一番わかっているチームを中心に、必要な専門区を能動的に巻き込む形へ転換しました。
統制から”信頼”への転換 ここで小林氏が最も気をつけたのは、「アジャイルでやる方針なんで」という言葉を使わないこと。相手のプロセスを否定するのではなく、「お互い品質を高めたい、知財を守りたいという目的は同じ。だったら短いスパン・オンデマンドで、負担なく回せる方法を一緒に考えさせてください」と共通目的に訴える。泥臭く味方を増やした結果、QA区は「都度チェック」から品質安定の実績を経て「開発側を信頼して任せる関係」へ、知財区は「必要な時だけオンデマンドで動く体制」へと変わりました。
アジャイルを既存会議体に”翻訳”する Sprint Planning＝変更計画会議、Sprint Review＝リリース決定会議、Sprint Retrospective＝振り返り会議。カタカナを押し付けず、社内の言葉に置き換えて説明することで「あれのことね」と受け止めてもらえた。単なる言葉の変換ですが、既存カルチャーへの接続点として大きかったといいます。
多能工化と「2週間の原則」 初期6名（1名のWeb経験者＋組込中心メンバー）で、得意領域の分業ではなく「一気通貫で担当」へ。Sprint 1-2は学習コストで速度が落ちるものの、約1ヶ月でベロシティが安定。移行期は「イニシャルコスト」と割り切り、全員で全領域をカバーしました。閉じこもりを防ぐため、イベントファシリテーターは強制的に輪番制に。リーダー自ら未経験のクラウド・フロントエンドに挑戦し「泥臭い背中」を見せることで、心理的ハードルを下げています。そして、要件曖昧化の負ループには「そのスプリントで決まった要件は期間中に変更・追加しない」という原則で対処。「できません」を「2週間後なら検討できます」に変え、次の打席がある安心感と良い緊張感を生みました。
成果・学び
品質ゲートは、E2E自動テストの完全パス／テストカバレッジの遵守／脆弱性診断のクリア／OSSライセンス確認の4点に明文化。従来の厳格なチェックの精神を、シャープかつ高速に、毎回通せる仕組みへ変えました。QA区・知財区との信頼関係が構築され、いまや若手が自律的な文化を「当たり前」として成長する好循環に。
生成AIについては、メンバーにGitHub Copilot/Claudeを配布しほぼ全員が「Must Have」と回答する一方、チームとしての最大化は道半ば——特に振り返りが弱いと率直に課題を共有しました。展望として、最新AIのキャッチアップ→業務適用→効果の自動計測・可視化→振り返り・改善という「自浄作用サイクル」を回せる状態を目指し、その計測負荷が自律性を殺さないようFindy AI+を一部チームで試行しています。
印象的なコメント
「変わったのは手法ではなく、前提となるすべての境界線が消えた。それでも、製造業としての品質責任は1ミリも軽くならない」——小林 氏
「『アジャイルでやる方針なんで』という言葉は使わない。目的は同じなので、そこに訴えかけて泥臭く味方を増やす」——小林 氏
このセッションから得られる示唆
- 「アジャイル化＝品質の妥協」ではなく「品質条件の徹底的な見える化」。出口（リリース基準）を固めれば、途中の自由度は上げられる。
- 相手のプロセスを否定せず、共通目的に訴えて設計を一緒に考える——摩擦を溶かすのは正論ではなく合意形成。
- 新しい思想は既存の会議体・文化に「翻訳」して接続する。言葉の変換が導入コストを大きく下げる。
- 変更を許容するアジャイルほど「変えない約束（スプリントの原則）」が規律として効く。
- AI活用の律速は、いまや個人ではなくチーム最大化と振り返りに移っている。
セッション③ 株式会社村田製作所｜外注依存からの内製立ち上げ、そしてSpec駆動開発で生産性57%改善
セッション概要
総合電子部品メーカーの村田製作所。森氏は、内製開発チームの立ち上げ（2018〜2023）から、現在推進する生成AI駆動開発までを担ってきました。デバイスまでは確実に作れる一方、新規事業領域ではクラウド/アプリのエンジニアがほぼいない——そんな状態から、どう組織を作り、いかにAI駆動開発を商用適用したのかを、定量・定性の両面から率直に共有しました。
課題・背景
かつての村田では、新規事業のクラウド/アプリ開発をほぼ外注に依存。PoCフェーズまで外注していたため、要件を出し、作ってもらい、受け入れ、また要件変更……と、ビジネスの立ち上げが遅くコストもかさみ、価値検証がスムーズにできないという大きな課題を抱えていました。加えて、ベンダーは「言われたものを確実に作る」ことに責任を持つため、開発側からビジネスへの提案が出にくく、成功のためのワンチームが作りにくい。
DX人材の確保も難しく、予算が潤沢でない新規事業で各職種を揃えるのは非現実的でした。
取り組み内容
内製開発チームの3フェーズ立ち上げ Phase 1のほぼ外注依存（ナレッジが蓄積されない・スピード・柔軟性・コストに課題）から、Phase 2で新規事業開発部内に小さくクラウド内製部隊を立ち上げ（2022年、2名スタート／PoCの仮説検証にフォーカス）。成果を上げて費用対効果を実証しながら規模を拡大し、Phase 3で共通基盤技術センターへ移設・組織化（2023年）。横断的にサービスを提供し、当初2名だった体制はいまや20名超、10件以上を並行対応、商用グレードのDevOpsまで担っています。組込ソフトからペアプロ・モブプロでスキルチェンジしたメンバーも戦力に。需要変動には協業ベンダーの準委任で体制の弾力性を確保しています。
生成AI駆動開発——現在の主戦場はStep2 森氏は生成AI駆動開発を3ステップで整理します。Step1「実装高速化」（個人・コード中心）、Step2「開発プロセス変革」（チームでAIが開発全体を駆動、要件以降の全工程、生成AI前提のプロセス・ドキュメント、ガードレール）、Step3「ビジネスプロセス変革」（企画・UX・運用の統合、アウトカム中心の指標）。同社の現在の注力はStep2です。
ソフトウェア開発ライフサイクルも、①コード生成 → ②Vibeコーディング（デモは爆速だが属人性が高くチーム適用が難しい） → ③Spec駆動開発（仕様が一次成果物、商用適用しやすい） → ④AI-DLC（AIが全体駆動）へと進化していると位置づけました。
Spec駆動開発の商用適用 2025年度下期、同社はSpec駆動開発ツールとしてKiro（AWS）を採用。AIと一緒に要件・仕様を定義し、仕様書・設計書・タスクリストを人がレビュー承認しながら、実装・テストをAIが実行していく手法です。
成果・学び
新規事業の商用向け開発（5名・半年、既存プロダクトへの新サブシステム）で、生産性57%改善を実現。世間の「数倍・数十倍」という数字と比べると控えめに見えるかもしれませんが、これは製造業特有の厳しい商用品質を守りながら、設計・実装だけでなく要件からリリース前までの全工程を含めた数字です。設計・実装だけならもっと大きな成果が出ているといいます。
森氏が最大の成功要因として挙げたのは、導入前にトップエンジニアが開発ルールやAIのステアリングをがっつり整備したこと（Sprint0）。「これが効いた」。並行して導入した別プロジェクトではそこまで整備できず、同等の向上は得られませんでした。これは近年語られる「ハーネスエンジニアリング」にも通じる示唆です。
定性評価も率直に開示されました。開発スピードは実装180%・バグ修正170%・調査設計165%・新技術立ち上がり157%と大幅改善する一方、レビューは100%（＝重い）。生成AIの成果物が爆増してレビュー量が膨らんでいる。開発者体験でも、新知識習得（6.7）は改善する一方、基礎力・達成感・「価値を出せている感覚」（3.3）は悪化。AIが優秀になったことで、実装の相対価値が下がり「自分は価値を出せていない」と感じるエンジニアが出ている——ただしドメイン知識、全体のトータルコーディネート能力、AIを使いこなす能力は今後も必要だと結びました。
現場の工夫も具体的です。skillsが登場した際にsteeringをskillsへ乗り換えたところ、context rot（AIへのインプット劣化）が減って動作が安定。Kiroに依頼する前にエンジニア間で実装を十分議論しておくと、頭の中の実装イメージとの差分だけを見ればよくレビューが楽に。さらにSuperpowersのbrainstormingスキルでAIとディスカッションしてから仕様をインプットすると、ドキュメントの精度・網羅率が上がりAIの出力が安定した——「brainstorming＋Spec駆動」がいま最も安定したプロセスだといいます。
印象的なコメント
「57%だけか、と思われるかもしれません。しかし製造業特有の厳しい品質を守りながら、要件からリリース前までのすべてを含めての数字です」——森 氏
「導入前にトップエンジニアが開発ルール・AIのステアリングを整備した。これがかなり効いた」——森 氏
このセッションから得られる示唆
- 外注依存からの脱却は「小さく試して成果→投資対効果を実証→組織化」の順で進めると移行が滑らかになる。
- 生成AI駆動開発の生産性は、対象工程を明示して測る（設計・実装だけか、要件〜リリースまでか）と誤解が生まれない。
- Spec駆動の成否はツールより「Sprint0のルール・ステアリング整備」で決まる（ハーネスエンジニアリング）。
- AI活用の新たな律速はレビュー（量の爆増）。振る舞い駆動（BDD）やE2Eの整備と合わせた品質保証の再設計が要る。
- 生成AI時代のエンジニアの価値は、実装からドメイン知識・全体設計・AIの使いこなしへシフトする。
Q&A｜3社が本音で語った論点
論点1：製造業でアジャイルは無理、をどう打破したか
島津・冨澤氏は「打破というより、地道に対応づけていった」と表現。企画・法規対応でどんな要求があり、それをスクラムのどの活動で満たせるかを一つずつ紐づけ、ソフトウェア単体からスモールスタートして成功事例を積み上げた。「前例があるだけで違う」。現場の内林氏は「推進側が整えてくれたので、現場ではあまり意識せずに機能できた」と、二層構造の効果を裏づけました。
論点2：品質保証を巻き込む際に受けたフィードバック
島津・内林氏：動くものから始めるため「これって最終版なの?」という指摘を受ける。最終イメージへの近づけ方に課題。
村田・森氏／リコー・小林氏：セキュリティ面の担保が論点。小林氏は「『信じてください』だけでは信頼されない。カバレッジで客観性を持たせ、開発から説明責任を果たせる形にした」。
論点3：組込ソフトへのアジャイル適用は難しいのか
3社の見解はほぼ一致。組込/HW連携はウォーターフォールが相性がよく、クラウド/アプリはアジャイルという棲み分けです。小林氏は「ハードと連携するAPIを疎結合に切り、クラウド側を速く回すのがポイント。組込は今でもウォーターフォールが向いている」。森氏も「HWと一緒に動く部分はインターフェースを固めて要件を作る必要があり、現状はウォーターフォールが相性がいい」と回答しました。
論点4：ビジネスオーナーのアジャイル理解は変わったか
村田・森氏：「POによりけり。ただ価値を提供し続ける中で、事業価値につながると見えてくると、ビジネスパートナーとしての意識が育つ。ギブファーストの気持ちで」
島津：発注側の意識はもともと根深くなく、一緒に議論して作る文化が広がっている。
リコー・小林氏：「理解はしていただいている。重要なのはどこまでビジネスオーナーに頼るか。負荷が集中しないよう、最近は開発側から生成AIなどの価値を提案する『持ちつ持たれつ』が大事」
論点5：E2Eテストの重さと品質の線引き
3社とも「E2Eは重い」という実感を共有。島津・内林氏は「E2Eの並列自動化は、フィードバックでコロコロ変わるため一度断念。単体・結合・API単位のテストは生成AIで高速化できている」。リコー・小林氏は「夜間に並列で回して朝には終わる状態だが、安定性の維持自体が本末転倒気味の技術負債になっている」。村田・森氏は「品証がアジャイル向けのデザインレビューの仕組みを作ってくれた。今後は振る舞いを定義してE2Eを整備するBDD的アプローチを進めたい」。
論点6：分散・オフショア開発の言語・時差の壁
島津・内林氏は「言語の壁は”伝わるまで喋る”しかない。疑問を徹底的に突き詰めるコミュニケーションで壁が消えていく。時差は5時間以内で助かった。むしろ海外側はアジャイル経験が豊富で、こちらが勉強になった」とリアルに語りました。
Q&Aから共通して見えたこと
品質保証部門の巻き込みは「客観性による説明責任」が鍵であり、組込/クラウドの棲み分けは3社で一致。ビジネス側との関係は「価値を提供し続けることでパートナーへと育つ」という点で共通していました。
イベント全体のまとめ
共通課題
3社に共通していたのは、次の点です。
- 製造業の統制・品質文化とアジャイルのスピードの緊張関係。そして「品質責任は軽くならない」という不変の命題。
- 品質保証部門（品証）をいつ・どこまで巻き込むかという難しさ。
- 組込/HWはウォーターフォール、クラウド/アプリはアジャイルという棲み分け。
- E2Eテストの重さ・肥大化・安定性劣化への苦労。
- 生成AIは個人には浸透済みだが、チームとしての最大化・レビュー爆増・振り返りが次の壁。
各社のアプローチの違い
- 島津製作所：全社支援組織と事業部POの「二層構造」。ISO対応の明文化と、分散開発向けのPBI設計が核。GitHub Copilotで叩き台生成、知見をinstructions/skills/agentsとしてAI化。
- リコー：文化・組織・言葉の「翻訳」で摩擦を溶かす現場ストーリー。品質ゲートの適材適所、権限集約、2週間の原則。AIは「自浄作用サイクル」構築へ。
- 村田製作所：組織立ち上げそのものから語り、生成AI駆動を最も先鋭的に商用実践。Spec駆動開発（Kiro）で全工程57%改善。成功要因はSprint0のステアリング整備。
AI活用の成熟度で見ると、リコー（個人浸透→チーム化はこれから）→ 島津製作所（PBI・知見のAI化で実務に組込）→ 村田製作所（Spec駆動を商用適用し57%実証、AI-DLCへ）という、リアルなスペクトラムが浮かび上がりました。
成功要因
3社の話を貫く成功要因は、以下に集約できます。
- 既存文化への”接続”：カタカナ思想を押し付けず、既存の会議体・規格・部門の言葉に翻訳して接続する。
- 権限と責任の再設計：やり方を現場チームに集約し、専門部門はオンデマンドで連携する。
- 品質の”見える化”：出口のガードレール（自動テスト・カバレッジ・脆弱性・OSS）を固め、客観性で説明責任を果たす。
- 土台づくりへの投資：スクラム推進のガイドライン、AI駆動のステアリング（Sprint0）——最初に土台を作った側が伸びる。
今後重要になるテーマ
生成AIは「コードを書かせる」段階から「開発プロセス全体を駆動する」段階へ移りつつあります。その中で問われるのは、レビューと振り返りをどう機能させるか、そして人間の価値をどこに置くか（ドメイン知識・全体設計・AIの使いこなし）です。生産性は定量（ストーリーポイント/工数）と定性（開発者体験）の両面で見る必要があります。
読者へのメッセージ
「製造業だからアジャイルは無理」という前提は、乗り越えられます。
3社に共通していたのは、正論で押し切るのではなく、既存の文化と品質責任をリスペクトしながら”適材適所”で接続・進化させる姿勢でした。
自社の統制文化を敵ではなく味方にできるか——その問いこそが、変革の出発点になるはずです。
この記事の要点
- 製造業のアジャイルシフトの鍵は、統制・品質文化を否定せず「適材適所で接続・進化させる」こと。
- 組込/HWはウォーターフォール、クラウド/アプリはアジャイル——3社ともこの棲み分けで一致。
- 品質保証部門の巻き込みは「客観性（カバレッジ等）による説明責任」で信頼を獲得する。
- アジャイル化は品質の妥協ではなく「品質条件の徹底的な見える化」。出口のガードレールを固める。
- 権限（責任）を現場チームに集約し、専門部門とはオンデマンドで連携する。
- 生成AIはコード生成 → Vibe → Spec駆動 → AI-DLCへ進化。商用適用にはSpec駆動が現実的。
- Spec駆動開発の成否は、導入前のルール・ステアリング整備（Sprint0＝ハーネスエンジニアリング）で決まる。
- 村田製作所は全工程で生産性57%改善を実証。ただし律速はレビュー量の爆増に移っている。
- AI活用は個人には浸透済み。次の壁はチーム最大化・振り返り・品質保証の再設計。
- 生成AI時代のエンジニアの価値は、実装からドメイン知識・全体設計・AIの使いこなしへシフトする。
