Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
製造業界の人とアジャイルをやってみたよ
Search
Toshiaki Nomura
October 22, 2025
Business
1
590
製造業界の人とアジャイルをやってみたよ
工場の方々とアジャイルでプロジェクトをした時の話です。その時の成功要因なかと思ったポイントをまとめています。
Toshiaki Nomura
October 22, 2025
Tweet
Share
Other Decks in Business
See All in Business
自らを強いエンジニアにするための3つの習慣 2025/ Fitter happier more productive
shinyorke
PRO
0
170
株式会社ドリコム_事業計画及び成長可能性に関する説明資料
drecom_hr
0
6.6k
株式会社Branding Career_採用デック資料
20251024
0
530
エムスリーキャリア エンジニア採用資料 / M3C Engineer Guide
m3c
1
100k
Biz/Dev二刀流からの実践知 - 大企業で挑むプロダクト開発における思考と判断 -
ryo_k
1
270
merpay-Overview
mercari_inc
8
190k
採用ピッチ資料|SBペイメントサービス株式会社
sbps
0
34k
メドピアグループ紹介資料
medpeer_recruit
10
140k
生成AI活用戦略 自社サービスや業務に生成AIを組み込むには
ncdc
1
110
Mercados eléctricos y almacenamiento con BESS en España
neuroenergia
PRO
0
150
【Omiai】リアーキ LT_202510
enito
PRO
1
1k
Hubble Company Deck
hubble
2
220
Featured
See All Featured
RailsConf 2023
tenderlove
30
1.3k
BBQ
matthewcrist
89
9.9k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1k
How STYLIGHT went responsive
nonsquared
100
5.9k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Thoughts on Productivity
jonyablonski
73
4.9k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Music & Morning Musume
bryan
46
6.9k
Rails Girls Zürich Keynote
gr2m
95
14k
jQuery: Nuts, Bolts and Bling
dougneiner
65
8k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Unsuck your backbone
ammeep
671
58k
Transcript
製造業界の人と アジャイルをやってみたよ クラスメソッド株式会社 製造ビジネステクノロジー部 スマートファクトリーチーム 野村 敏昭
このパートは技術的な話はないので リラックスして聞いてください 技術面で、うまく進めることができた話を聞きたい人は、 この後の懇親会でエンジニアを捕まえてこっそり聞いてください
野村 敏昭 製造ビジネステクノロジー部 スマートファクトリーチーム ・メーカー系子会社2社を経て、2023月1日 クラスメソッド入社 ・元組み込み屋で、DTP専用機・プリンタ・デジタルカメラの開発を経験 ・マシンビジョン、OPC UA、温度管理システムなどで製造業関連を経験 SNS,ブログ
・Xアカウント:@toshiaki0315 ・Qiita:https://qiita.com/Toshiaki0315 ・その他SNSもtoshiaki0315で活動 資格 ・2014年に認定スクラムマスターを取得 コミュニティ活動・登壇 ・PM保護者会メンバー ・Jasst Tokyo ・ISACA(旧 情報システム監査コントロール協会) ・Regional Scrum Gathering Tokyo ・Agile Japan プレイベント
製造業とアジャイル トヨタ生産システム(TPS)の思想からLeanが産まれ Leanなどの思想をソフトウェア開発の文脈でアジャイルに発展 現在はアジャイルがソフトウェア開発から ビジネスなどの文脈などにも使われる様になっています 今回は、ソフトウェア開発の文脈のアジャイルを 大元の製造業の人たちと一緒に実施した話となります
製造業とアジャイル https://f.hatena.ne.jp/wayaguchi/20130420081831
トヨタ生産システムに どんな印象を持ってますか?
その実施効果は理解していても 作業員への過度な負荷とストレス を気にされる方もの少なからずいるのでは
トヨタ生産システムは 人間尊重を土台とし、ムダをなくすことで 作業を楽にすることを目指すもの その理念が忘れられたり、現場に伝わらなかったり そもそもTPSを実現できる土台がなかったりして 単なる効率化やコスト削減の道具として 使われてしまうケースが多々あります
カイゼン疲れ していませんか?
気持ちに余裕がないときに カイゼンなんてできませんよ
カイゼン疲れしているような職場で TPSを源流としたアジャイルをやろう! って言われても、 またカイゼンか、これ以上何をやらされるんだ! って人も多いはず
トヨタ生産システムに どんな印象を持ってますか?
TPSでカイゼンできているぜって職場の方は よりよくするためのヒントになれば カイゼン疲れしている職場の方は まずはメンバー回復を
アジャイル/スクラムの文脈だと トヨタ生産システム(TPS)よりも トヨタマネジメントシステム(TMS)の方が 参考になることが多いかなと考えています https://amzn.asia/d/eIlEafq https://www.tms-tps-certification.jp/learning-tool/
スクラムマスターとして 製造業の内製化支援で 気をつけていること
•アジャイルに馴染みのない人へのフォロー •スクラム導入時にPOへのフォロー •お互いの「あたりまえ」について
アジャイルに馴染みのない人へのフォロー 失敗して改善することを認識 小さく失敗することの意味を理解 「失敗することがわかったのでOK」 「改善するところがわかったのでOK」 「損害が小さかったのでOK」 失敗したことを隠さない文化
アジャイルに馴染みのない人へのフォロー コミュニケーションの重要性 コミュニケーションの場は多くある •開発のわいがや •要件の明確化 •見積りの認識合わせ •ふりかえり
小さな失敗に寛容になり 多くのコミュニケーションが 日常になると 改善のサイクルも向上 (質もスピードも) チャレンジも多くなる
注意点 失敗する方は、てへぺろで許されるサイズで 失敗することが求められます さすがに100億円損失が出ました「てへっ」は 許されません
スクラム導入時にPOへのフォロー 一番辛いロールなのでできるだけ寄り添う •ステークホルダーの説得 •要件の優先順位づけ •要件の取捨選択 やったことがない仕事が多いはず
スクラム導入時にPOへのフォロー POに限らず意識改革してもらう必要がある 失敗した時にチーム全員がこう考える 失敗しても1week戻るだけ (1weekも無駄にしたって考えだとスクラムはうまく行かない)
注意点 PBIをスプリント内で終わるサイズにする PBIの依存関係をできるだけなくする ここでも失敗を小さくする工夫がされています
お互いの「あたりまえ」について 業界が違うので常識が違うことをお互い理解 同じ単語でも意味が違う可能性もある 「あたりまえ」だと思って伝えなかったことが 重要なポイントになることもある 「あたりまえ」の上に成り立っている透明化は、 透明化されている部分が氷山の一角のことがある 前提条件なしに話し合うことが大事
お互いの「あたりまえ」について 「そんなことは知っていると思っていた」 「最近のWebの流れは、こんな感じだから」 「現場ではそんなことしないですよ」 「言わなくてもわかるでしょう」 あとからこんな言葉が出てこない様にしましょう
みんな聞きたい 事例
スクラムチームの例 スクラムマスター クラスメソッド 開発チーム プロジェクトマネージャー 専門分野エキスパート 利害関係者 プロジェクトオー ナー プロダクトオーナー
スクラムチーム クラスメソッド お客様 お客様 開発チーム
役割分担と想定工数 所属 ロール名 やること 想定する週あたりの時間 お客様 ステークホルダー (プロジェクトオーナー) プロダクトオーナーとのコミュニケーション プロダクト成果物のレビューとフィードバッ
ク プロジェクト進行に必要な時間(成果物に 対して主体的に関わりフィードバックする 重要な役割となります) お客様 プロダクトオーナー プロダクト要件の明確化 実装の優先順位付け 作成物の受入基準の明確化 作成物の評価とフィードバック 開発者とのコミュニケーション ステークホルダーとのコミュニケーション 週8時間想定(関わるステークホルダーの 人数や実施内容により、これより上回る可 能性があります) クラスメソッド スクラムマスター 開発プロセスの遵守 開発チームの課題や障壁の除去 アサイン時間全て クラスメソッド プロジェクトマネージャー 顧客フロント・クラスメソッド側責任者 アサイン時間全て お客様& クラスメソッド 開発チーム プロダクトの作成における計画と実装 アサイン時間全て
注意!!! ここからは、スクラムマスターという立場から見た、 このプロジェクトの成功要因についてお話しします エンジニアやプロダクトオーナー、 ステークホルダーから見たら違うよってところもあると思いますが ご了承ください
うまく行った理由(ロール) •POがステークホルダーへの説明を主体的に実施 • 開発者が開発に専念できる環境を作っていただけた •POが要件の取捨選択を実施 • 無駄な開発をしないことができた(スコープ調整) • 常にPBLを綺麗に保ってくれた •ステークホルダーがスクラムイベントに参加
• スプリントレビューでのフィードバックが開発者のモチベー ションになった
うまく行った理由(ロール) •プロダクトオーナーを中心に 開発・情シス・ステークホルダーがいい関係を築けた • ステークホルダーが参加しないけど口をだす、 情シスと開発が連携がとれない、 POが丸投げ みたいな状況に一回もならなかった 開発 ステーク
ホルダー 情シス PO
うまく行った理由(コミュニケーション) •リモートだったが、MTGでみんな顔出し • 表情を見ながら、誰も置き去りにされずにMTGが進行 •コミュニケーション重視 • Slack、Miro、Figmaなどなどコミュニケーションや情報共有に使える ものはすべて使う •ふりかえりをコミュニケーションの場として利用 •
気軽に雑談の言える関係 • 感謝を伝える場
うまく行った理由(組織文化) •顧客がアジャイルやスクラムの進め方にアジャスト •顧客の職場文化がよかった • 和気藹々な雰囲気 • チャレンジングな精神
うまく行った理由(人) •顧客側エンジニアも含め、開発することが好きだった • 好きな人が好きな人に支援するので、うまくいかないわけがない •情シス部門に工場をよく知っている人がいた • サイロ化せずにプロジェクトが進められた • 想像以上に良い効果が出てくる •案件の潤滑油になってくれる人がいた
• ふりかえりなどでギスギスならない立ち振る舞い
うまく行った理由 自画自賛 お客さんもすごかったが、 案件に参加したクラスメソッドの デザイナー、エンジニアも とても優秀だった!!!
さいごに 「うちにはエンジニアがいないから」とか 「内製化してみたいけど、そこまでスキルがないから」とか やらない理由を見つけるのは簡単ですが せっかくなのでクラスメソッドのエンジニアと 1チームになって楽しい開発をしてみませんか?