村田製作所×SHIFT Scrum Fest Osaka 登壇レポート
2026年7月31日から8月1日にかけて、スクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なるさまざまな人々が集まる学びの場「Scrum Fest Osaka」が開催されました。
SHIFTからは髙橋 直規が、株式会社村田製作所 中矢 博巳氏とともに、「AIは実装を速くする。では、私たちは何を今作るべきか？立場を越えてリリースに向き合ったチーム開発の実践」というタイトルで登壇。
「AIを使って実装スピードを上げたはずなのに、手戻りや無駄が発生してしまう」と悩む開発現場は少なくありません。
圧倒的なスピードでコードを生成できるようになったからこそ、そのはやさが思わぬ技術的負債を生む罠になることがあるのです。
本記事では、村田製作所とSHIFTの合同チームが、短納期プロジェクトで直面した「AI開発における先回り実装の失敗」と、そこから再認識したソフトウェア開発の鉄則「YAGNI（You Aren’t Gonna Need It）の原則」の重要性について迫ります。
-
株式会社村田製作所 中矢 博巳氏
SIerにて通信キャリアの共通基盤システム開発（スクラム）や、自社プロダクトであるネットワーク監視ツールの開発を経験。その後、2023年10月に株式会社村田製作所へ入社。現在は、新規事業創出支援やWebアプリ開発に携わっており、プロジェクトではテックリードおよびDev（開発者）の役割を担っている。
-
株式会社SHIFT 髙橋 直規
エンジニアやPM、サービスマネージャー※として、さまざまなシステム開発案件などに携わった後、アジャイルを専門的に扱うために、3社目として2023年3月SHIFTに入社。現在は、SHIFTの「アジャイル」にまつわるさまざまな案件に入り、プロジェクトマネジメントから実務となるエンジニアリングまで、幅広い領域でアジャイルサービスの浸透／普及に従事している。
※複数案件を管理し、滞りなくサービス提供ができるよう責任を担う立場。
目次
AI活用を前提とした短納期プロダクト開発の幕開け
村田製作所 中矢氏：AIを活用した新規プロダクト開発は、チャレンジングな状況でスタートしました。というのも、私たちが越えなければならない高いハードルが同時に3つ存在していたんです。
1つ目は、半年後にはリリースが求められるというビジネス上の要求があったことです。決められた期間内でのリリースが求められていました。
2つ目は、村田製作所内でも事例の少ない、商用向けWebシステムの開発だったこと。確立された正解がないなかで、走りながら学習し、プロダクトを形にしていく必要がありました。
そして3つ目のハードルが、AI活用を前提とした新しいチーム開発への挑戦です。そのために、村田製作所の内製開発メンバーと、SHIFTのメンバーによるスクラムチームを結成しました。
村田製作所はAI駆動開発に力を入れて実装速度向上を狙い、SHIFT側には、村田製作所の別システムを開発した知見を活かして要求分析での支援を行ってもらう。これらを掛け合わせることで、短納期を乗り切ろうと考えました。
また、このプロジェクトでは、AIを使ってはやくつくるための環境も用意していました。内製チームには「開発速度を1.5倍以上向上する」という目標が課せられていたため、AIと親和性の高い技術スタックを採用しました。
例えば、AIがプロジェクト全体を横断して参照しやすいようにソースコードを単一のリポジトリで管理するモノレポ構成を採用しました。
また、責務や関心を分離するクリーンアーキテクチャを取り入れ、AIが構造を理解しやすく、制御しやすい状態をつくりました。
さらに、開発者の意図したコードをAIが高い精度で出力できるよう、仕様駆動開発（SDD）を取り入れたり、AI用のハーネス（実行環境）を整備したりと、生成速度と品質をコントロールする機構を初期段階でつくり込みました。
この仕組みが功を奏し、プロジェクトが走りはじめると、開発初期から目標としていた「開発速度の1.5倍以上の向上」をあっさりと達成できたんです。
人間の手による従来の開発と比べて、スプリントごとに生み出される成果物（インクリメント）の量は目に見えて増えました。
このスピード感には、プロダクトオーナー（PO）やステークホルダーからの評価も上々で、短納期のプロジェクトの達成も見えてきました。
スピードを追求した“先回り実装”は、すべて無駄になった
SHIFT 髙橋：AIの圧倒的な速さに刺激され、私たちは「もっと開発速度を上げられるのではないか」と考えるようになりました。そこで、従来の進め方を変える、新たな挑戦をしました。
それまでは、画面とAPIをセットでつくって動作検証しながら進めていました。しかし、AIを使えばコードがあっという間に書けてしまう。
それなら、「先のフェーズで必要になるであろうAPIを、いまのうちに全部つくってしまおう」と考えたのです。
我々は最初から用意されたデザインを見て、「将来必要となるAPIであれば、簡易的なものであれば、AIで一気につくれば効率的だ」と捉えてしまったのです。
最初は、この試みが成功したかのように見えました。5本ものAPIを一気につくり上げることができたからです。
しかし、その後に要件がなくなったり、仕様が変わったり、そもそもそれまでつくってきたAPIで十分代用ができることがわかり、先行してつくった5本のAPIは、すべてが使われなくなりました。
さらに、ただ無駄になっただけではありません。コードベースには使われないソースコードや、これまでと違う形式での仕様記述が残ってしまいました。人間にもAIにも読みづらい技術的負債となってしまったのです。
失敗から気づいた「YAGNI」原則の重要性。そしてアプローチの転換へ
SHIFT 髙橋：この失敗から、AIでどれだけはやくコードが書ける時代になっても、ソフトウェア開発の原則は変わらないと痛感しました。
それが「YAGNI（You Aren’t Gonna Need It）」原則、つまり「それはいまつくる価値があるのか？」という問いです。
「最初からデザインがあるからつくる」のではなく、「スプリントごとに、いまつくる必要があるものを吟味し、一つずつ確認しながら進める」という当たり前の進め方の重要性をあらためて学ぶことができました。
村田製作所 中矢氏：私たちの失敗の要因は、PO とデザイナーが作った初期デザインを、確定仕様のように扱ってしまった点にありました。
実際には、初期デザインはPOの頭の中のイメージを具現化しただけの“初期仮説”に過ぎなかったのです。
プロダクトの中心となるコア機能については比較的確度が高かったものの、その周辺機能に関しては、ビジネスの状況やユーザー理解が進むにつれて変動しやすい特性をもっていました。
先回りしてつくった5本のAPIは、まさにこの「変動しやすい周辺機能」に関するものでした。
この失敗を通して、私たちはリファインメントの進め方を根本から見直しました。これまでは、「この仕様をシステムとしてどうつくるか」「機能の振る舞いをどう実装するか」を主に議論していました。
しかし、この失敗を経てからは「これは本当に必要な機能なのか？」「ユーザーに届けたい価値は何か？」をチーム全体で問い直す場へと再定義しました。
問い直すことで掴んだ、短納期リリースの成功
村田製作所 中矢氏：POを交えたリファインメントの結果、初期デザインに従うだけではなく、以下のような判断をPOとともにすることができるようになりました。
・価値の不確かな機能のスコープアウト：主要な業務フローから外れる、ユーザー価値が曖昧な機能は思い切ってスコープから除外する。
・管理機能の廃止と既存機能での代替：管理者用の特別な制御や画面を重厚に開発するのをやめ、既存の運用フローや簡易的な機能で充足させる。
・簡易スクリプトによる代替：利用頻度やユーザー価値が低い機能については、システムとしての作り込みを行わず、バッチスクリプトなどでの代替を採用する。
「いま必要のないものはつくらない」「つくるにしても、もっともシンプルかつ最適な形を探る」。リリースするプロダクトのあるべき姿をチーム全体で考えることができたことが、その後の開発における大きな転機となりました。
一連の経験を通して、私は「AIは増幅器である」という言葉の意味を身をもって知りました。AIは、開発速度を増幅してくれる反面、私たちが目的を見失えば「本来あるべき姿とのズレ」まで増幅してしまうんです。
今回、私たちはAIの速さに流されず、プロダクトのあるべき姿を問い直しました。その結果、不要なものをつくる時間を削り、短い期間のなかで本当に価値のある形に洗練させてリリースすることができました。
AI時代にこそ求められる、人間がプロダクトに向き合う価値
SHIFT 髙橋：今回のプロジェクトを振り返ると、もし従来通りの人間の手による開発だったなら、求められていた半年という短納期のリリースには間にあわなかったと思います。
AIの速さは、間違いなくプロジェクトを支える巨大な力でした。 しかし、速さを追い求めるあまり、無駄なものまでつくってしまった。
実装速度を上げるのはAIの役割ですが、「いま何をつくるべきか」「価値あるプロダクトとは何か」に向き直り、軌道修正するのは人間の役割なのだと強く実感しました。
また、DevとPO、内製とベンダーといった立場を超えて、いっしょにプロダクトのあるべき姿を考え、対話できたからこそ、最適な形でのプロダクトのリリースを迎えられたと思っています。
AIによって誰もが簡単に、高速にモノをつくれる時代になりました。だからこそ、コードを書く前の対話が何よりも重要になります。
立場を超えて「これは本当に必要なのか？」と問い直せるチームの文化。それこそが、これからのAI時代にいままで以上に求められることになると信じています。
（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）
