製造業でも、アジャイル開発は可能なのでしょうか。ISO規格への対応、品質保証のプロセス、ハードウェアと同期した長期計画など、ものづくりの品質を支えてきた統制の仕組みは、短いサイクルで試行錯誤を重ねるソフトウェア開発とぶつかりやすいものです。一方で、変化の速い市場で世界中の顧客に応えるには、開発組織のあり方を変えることが避けられません。いま製造業各社が、この課題に正面から取り組んでいます。
本記事は、2026年6月30日にファインディ株式会社が開催したイベント「製造業におけるアジャイルシフトの実践知 〜スクラム推進・内製化・AI開発のリアル〜」のレポートです。
島津製作所・リコー・村田製作所の3社が、ISO規格との両立、品質保証部門の巻き込み、組み込みとクラウドの棲み分け、内製化、AI駆動開発にどう取り組んできたのかを紹介します。
製造業でもアジャイル開発は可能
「製造業だからアジャイルは無理」という前提は乗り越えることができます。
3社に共通していたのは、正論で押し切るのではなく、既存の文化や品質責任をリスペクトしながら、アジャイルを”適材適所”で既存の仕組みにつなぎ、進化させていく姿勢でした。自社の統制文化を敵ではなく味方にできるかという問いこそが、変革の出発点になるはずです。
この記事の要点
- 製造業のアジャイルシフトの鍵は、統制・品質文化を否定せず「適材適所で接続・進化させる」ことにあります。
- 組み込み/HWはウォーターフォール、クラウド/アプリはアジャイルという棲み分けで、3社の見解は一致しています。
- 品質保証部門を巻き込むには、カバレッジなどの客観的な指標で説明責任を果たし、信頼を得ることが重要です。
- アジャイル化は品質の妥協ではなく、品質条件を徹底的に見える化する取り組みです。そのために、リリース前に必ず通す品質基準（出口のガードレール）を固めます。
- 権限（責任）を現場チームに集約し、専門部門とはオンデマンドで連携します。
- 生成AIの活用は、コード生成、Vibeコーディング、Spec駆動開発、AI-DLCの順に進化しています。商用に適用するなら、現時点ではSpec駆動開発が現実的です。
- Spec駆動開発の成否は、導入前に開発ルールやAIへの指示（ステアリング）を整えておけるかで決まります。これはハーネスエンジニアリングの考え方に通じます。
- 村田製作所は全工程で生産性57%改善を実証しました。ただし、ボトルネックはレビュー量の急増に移っています。
- AI活用は個人には浸透しています。次の壁は、チームとしての活用の最大化、振り返り、品質保証の再設計です。
- 生成AI時代のエンジニアの価値は、実装からドメイン知識・全体設計・AIの使いこなしへとシフトしていきます。
イベント概要
- タイトル：製造業におけるアジャイルシフトの実践知 〜スクラム推進・内製化・AI開発のリアル〜
- 公式サイト：https://jp.findy-team.io/events/manufacturing-agile-shift-260630/
- アーカイブ動画：https://jp.findy-team.io/events/manufacturing-industry_agile_archive/
- 開催日：2026年6月30日（火）
- 形式：ハイブリッド（オフライン・オンライン）
- 主催：ファインディ株式会社
- 登壇者：
- 株式会社島津製作所 総合デザインセンター 設計推進ユニット 開発プロセス変革グループ／冨澤 京介 氏（スクラム推進）
- 株式会社島津製作所 分析計測事業部 ITソリューションBU／内林 光優 氏（スクラム実践）
- 株式会社リコー デジタルビジネスイノベーション事業部 アセット開発センター トレードエコシステム開発室 室長／小林 寛 氏
- 株式会社村田製作所 共通基盤技術センター システムデザイン部 シニアマネージャー／森 悠介 氏
【セッション①】ISO規格とどう両立する？約2年で16プロジェクトに広げた島津製作所のスクラム推進
セッション概要
創業150年を超える島津製作所は、分析計測やヘルスケアなど幅広い事業を展開しています。本セッションでは、全社の開発を支援する総合デザインセンターの冨澤氏と、実際に製品を開発する分析計測事業部の内林氏が、二人三脚で登壇しました。第1部では冨澤氏が「推進」の立場から、第2部では内林氏が「実践」の立場から語っています。
全社に広げる側と現場で回す側の両視点を一つのセッションで示した点が特徴です。
課題・背景
同社がアジャイルを推進した動機は、「世界中のお客様の課題に素早く対応したい」という明快なものです。そのためには、グローバル拠点との連携と、開発の試行錯誤のスピードアップが欠かせません。目標は、社内のソフトウェア開発でアジャイル（スクラム）を”選択できる”状態にすることでした。
ただし、前提には二つの特殊性がありました。すでに一定の内製開発が行われていたこと、そして新技術を獲得・展開する役割の組織（総合デザインセンター）がもともと存在していたことです。そのため、ゼロから推進組織を立ち上げたのではなく、既存の役割の中から取り組みを広げていったのが実態に近いといいます。
推進側の障壁は二つありました。ひとつは、スクラムの知見不足という「よくある話」です。もうひとつは、製造業で特に顕著な、ISO規格の要求事項とアジャイルの進め方の対応関係が不明確という問題でした。
規格はアジャイルを否定してはいないものの、ウォーターフォール前提のプロセスに見えるため、導入前に足が止まりやすいのです。
実践側（第2部）の課題は、さらに具体的でした。Webアプリ開発において、「アジャイルのスピード感で開発できない」という問題を抱えていたのです。要因は、(1) 対象業界・ユースケースが多様でドメインが複雑なこと、(2) オフショア・分散開発で認識のズレが起きやすいこと、(3) 新規開発で設計判断が多いことの3つでした。
結果として仕様確認の往復が増え、レビュー指摘が多発し、スプリント内で完了しない状態に陥っていました。
取り組み内容
推進側の1つ目の工夫は、伴走支援とガイドライン整備を”並行”させることでした。知見が少ない状態では、「何から始めればいいか」も「どんなルールの説明が必要か」も分かりません。
そこで、事業部への伴走支援（社外の力も借りた勉強会、スクラムイベントへの同席）と、ISO要求事項とスクラムイベントの対応関係を整理したガイドラインの整備を、同時に進めました。推進活動そのものもアジャイルに進め、ガイドラインは初版をすぐに公開し、現場のフィードバックをもとに改善を重ねました。この繰り返しによって、開発者の迷いを払拭しつつ、実態に合ったガイドラインへと育てていきました。
推進側の2つ目の工夫は、関係部門を早い段階から広く巻き込むことでした。ウォーターフォールであれば、品質保証部が参加するタイミングはあらかじめ決まっています。しかしアジャイルでは、開発の内容が逐次変わります。そこで、品証の担当者と一緒に「変化に対応できるやり方」を設計しました。
契約・インフラなど観点ごとに10以上の部門を巻き込み、コンプライアンスや品質に関わる重要点は責任部門と共に進めています。
実践側の課題に対して内林氏が採ったのは、開発判断を最適化するための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が持ちます。この役割分担の線引きが重要です。
- 振り返りを機能させるには、まず「観測できる状態」をメトリクスで用意しておくことが必要です。
【セッション②】品質責任を軽くせずアジャイルを回すには？リコーの品質ゲートと権限の集約
セッション概要
リコーの小林氏は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名（Web経験者1名と組み込み中心のメンバー）で、得意領域で分業するのではなく、一人ひとりが「一気通貫で担当」する体制に切り替えています。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の仮説検証にフォーカス）。
その後、成果を上げて費用対効果を実証しながら規模を拡大し、2023年のPhase 3で共通基盤技術センターへ移設して組織化しました。現在は横断的にサービスを提供しており、当初2名だった体制は20名超に拡大しました。10件以上の案件を並行して対応し、商用グレードのDevOpsまで担っています。
組み込みソフトウェアの開発からペアプロやモブプロでスキルチェンジしたメンバーも、戦力になっています。需要の変動には、協業ベンダーへの準委任で体制の弾力性を確保しています。
森氏は、生成AI駆動開発を3つのステップで整理しています。
Step1は「実装高速化」で、個人のコーディングをAIで速める段階です。Step2は「開発プロセス変革」で、チームとしてAIが要件定義以降の全工程を駆動する段階です。生成AIを前提としたプロセスやドキュメント、ガードレールを整えます。Step3は「ビジネスプロセス変革」で、企画・UX・運用まで統合し、アウトカムを中心とした指標で評価する段階です。
同社が現在注力しているのは、Step2です。
また森氏は、AIを活用したソフトウェア開発ライフサイクルが、①コード生成 → ②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の使いこなしへとシフトしていきます。
FAQ：製造業のアジャイル開発について3社に聞いた質問
製造業で「アジャイルは無理」という壁は、どう打破できますか？
一気に打破するのではなく、規格や法規の要求とスクラムの活動を一つずつ対応づけ、スモールスタートで成功事例を積み上げるのが現実的です。
島津製作所の冨澤氏は「打破というより、地道に対応づけていった」と表現しました。企画・法規対応でどんな要求があり、それをスクラムのどの活動で満たせるかを一つずつ紐づけ、ソフトウェア単体からスモールスタートして成功事例を積み上げたといいます。「前例があるだけで違う」とも語っています。現場の内林氏は「推進側が整えてくれたので、現場ではあまり意識せずに機能できた」と、推進と実践の二層構造の効果を裏づけました。
アジャイル開発で品質保証部門を巻き込むと、どんなフィードバックを受けますか？
主な論点は2つあります。動くものから見せるため「これが最終版なのか」と受け取られやすいことと、セキュリティ面をどう担保するかです。
島津製作所の内林氏は、動くものから始めるため「これって最終版なの?」という指摘を受けると話し、最終イメージへの近づけ方に課題があるとしました。村田製作所の森氏とリコーの小林氏は、セキュリティ面の担保を論点に挙げました。小林氏は「『信じてください』だけでは信頼されない。カバレッジで客観性を持たせ、開発から説明責任を果たせる形にした」と語っています。
組み込みソフトウェアにアジャイル開発は適用できますか？
3社の見解はほぼ一致しており、組み込み・ハードウェア連携はウォーターフォール、クラウド・アプリはアジャイルという棲み分けが現実的だとしています。
リコーの小林氏は「ハードと連携するAPIを疎結合に切り、クラウド側を速く回すのがポイント。組み込みは今でもウォーターフォールが向いている」と回答しました。村田製作所の森氏も「HWと一緒に動く部分はインターフェースを固めて要件を作る必要があり、現状はウォーターフォールが相性がいい」と答えています。
ビジネスオーナー（事業側）のアジャイルへの理解は変わりましたか？
価値を提供し続ける中で、事業側がビジネスパートナーとしての意識を持つようになる、という点で3社は共通していました。
村田製作所の森氏は「POによりけり。ただ価値を提供し続ける中で、事業価値につながると見えてくると、ビジネスパートナーとしての意識が育つ。ギブファーストの気持ちで」と話しました。島津製作所では、もともと「発注する側・される側」という意識は強くなく、一緒に議論して作る文化が広がっているといいます。リコーの小林氏は「理解はしていただいている。重要なのはどこまでビジネスオーナーに頼るか。負荷が集中しないよう、最近は開発側から生成AIなどの価値を提案する『持ちつ持たれつ』が大事」と語りました。
アジャイル開発でE2Eテストが重くなる問題には、どう向き合っていますか？
3社とも「E2Eは重い」という実感を共有しており、それぞれ異なるアプローチで向き合っています。
島津製作所の内林氏は「E2Eの並列自動化は、フィードバックでコロコロ変わるため一度断念。単体・結合・API単位のテストは生成AIで高速化できている」と話しました。リコーの小林氏は「夜間に並列で回して朝には終わる状態だが、安定性の維持自体が本末転倒気味の技術負債になっている」と課題を挙げています。村田製作所の森氏は「品証がアジャイル向けのデザインレビューの仕組みを作ってくれた。今後は振る舞いを定義してE2Eを整備するBDD的アプローチを進めたい」と語りました。
オフショア・分散開発の言語や時差の壁は、どう乗り越えましたか？
島津製作所の内林氏は、疑問を徹底的に突き詰めるコミュニケーションで乗り越えたと話しました。
「言語の壁は”伝わるまで喋る”しかない。疑問を徹底的に突き詰めるコミュニケーションで壁が消えていく。時差は5時間以内で助かった。むしろ海外側はアジャイル経験が豊富で、こちらが勉強になった」と、リアルな実感を語っています。
3社の回答から共通して見えたこと
品質保証部門を巻き込む鍵は「客観性による説明責任」にあり、組み込みとクラウドの棲み分けについても3社の見解は一致していました。ビジネス側との関係については、「価値を提供し続けることでパートナーへと育つ」という点が共通していました。
イベント全体のまとめ
共通課題
3社に共通していたのは、次の点です。
- 製造業の統制・品質文化とアジャイルのスピードとの間には緊張関係があり、「品質責任は軽くならない」という命題は変わりません。
- 品質保証部門（品証）をいつ・どこまで巻き込むかに難しさがあります。
- 組み込み/HWはウォーターフォール、クラウド/アプリはアジャイルという棲み分けをしています。
- E2Eテストの重さ、肥大化、安定性の低下に苦労しています。
- 生成AIは個人には浸透しているものの、チームとしての最大化、レビュー量の急増、振り返りが次の壁になっています。
各社のアプローチの違い
- 島津製作所：全社支援組織と事業部POの「二層構造」で進めています。ISO対応の明文化と、分散開発向けのPBI設計が取り組みの核です。GitHub CopilotでPBIの叩き台を生成し、知見をinstructions/skills/agentsとしてAI化しています。
- リコー：文化・組織・言葉を「翻訳」して摩擦を解消した、現場発のストーリーです。品質思想の”適材適所”な再定義、権限の集約、2週間の原則を軸に据え、AI活用では「自浄作用サイクル」の構築を目指しています。
- 村田製作所：内製組織の立ち上げそのものから語り、生成AI駆動開発を最も先鋭的に商用で実践しています。Spec駆動開発（Kiro）で全工程の生産性を57%改善しており、成功要因はSprint0でのステアリング整備にありました。
AI活用の成熟度で見ると、リコー（個人に浸透し、チーム化はこれから）→ 島津製作所（PBIや知見のAI化を実務に組み込み）→ 村田製作所（Spec駆動開発を商用に適用して57%改善を実証し、AI-DLCへ）という、リアルなスペクトラムが浮かび上がりました。
製造業がアジャイル開発を進める4つの成功要因
3社の話を貫く成功要因は、以下に集約できます。
- 既存文化への”接続”：カタカナ用語や新しい考え方を押し付けず、既存の会議体・規格・部門の言葉に翻訳して接続します。
- 権限と責任の再設計：やり方を現場チームに集約し、専門部門とはオンデマンドで連携します。
- 品質の”見える化”：出口のガードレール（自動テスト・カバレッジ・脆弱性・OSS）を固め、客観性によって説明責任を果たします。
- 土台づくりへの投資：スクラム推進のガイドラインやAI駆動のステアリング（Sprint0）のように、最初に土台を作った側が伸びます。
今後重要になるテーマ
生成AIは「コードを書かせる」段階から「開発プロセス全体を駆動する」段階へ移りつつあります。その中で問われるのは、レビューと振り返りをどう機能させるか、そして人間の価値をどこに置くか（ドメイン知識・全体設計・AIの使いこなし）です。生産性は定量（ストーリーポイント/工数）と定性（開発者体験）の両面で見る必要があります。
製造業のアジャイル開発・AI駆動開発に関心のある方にオススメの記事はこちら
ホンダの「デジタルラボ」が挑む、AI駆動の内製開発プロセス【11/26開催・内製化をスケールさせるAI時代のアジャイル開発イベントレポート】
製造業の内製開発の事例として、本田技研工業のデジタルラボが取り組む、AIエージェントを活用したネイティブアプリ実装ワークフローを紹介したイベントレポートです。
【イベントレポート】金融アジャイルは「形骸化の罠」をどう超えたか──クレディセゾン・楽天カード・マルイユナイト3社の実践知
品質と統制が求められる金融業界で、アジャイルが形骸化する原因とその乗り越え方を、クレディセゾン・楽天カード・マルイユナイトの3社が語ったイベントレポートです。
AI駆動開発(AIDD)とは？メリット・デメリット、導入ロードマップを解説
AI駆動開発（AIDD）の定義やメリット・デメリットから、組織への導入・推進ロードマップまでを体系的に解説します。
