製造業界の人と アジャイルをやってみたよ クラスメソッド株式会社 製造ビジネステクノロジー部 スマートファクトリーチーム 野村 敏昭 

このパートは技術的な話はないので リラックスして聞いてください 技術面で、うまく進めることができた話を聞きたい人は、 この後の懇親会でエンジニアを捕まえてこっそり聞いてください 

野村 敏昭 製造ビジネステクノロジー部 スマートファクトリーチーム ・メーカー系子会社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などなどコミュニケーションや情報共有に使える ものはすべて使う •ふりかえりをコミュニケーションの場として利用 • 気軽に雑談の言える関係 • 感謝を伝える場 

うまく行った理由（組織文化） •顧客がアジャイルやスクラムの進め方にアジャスト •顧客の職場文化がよかった • 和気藹々な雰囲気 • チャレンジングな精神 

うまく行った理由（人） •顧客側エンジニアも含め、開発することが好きだった • 好きな人が好きな人に支援するので、うまくいかないわけがない •情シス部門に工場をよく知っている人がいた • サイロ化せずにプロジェクトが進められた • 想像以上に良い効果が出てくる •案件の潤滑油になってくれる人がいた • ふりかえりなどでギスギスならない立ち振る舞い 

うまく行った理由 自画自賛 お客さんもすごかったが、 案件に参加したクラスメソッドの デザイナー、エンジニアも とても優秀だった！！！ 

さいごに 「うちにはエンジニアがいないから」とか 「内製化してみたいけど、そこまでスキルがないから」とか やらない理由を見つけるのは簡単ですが せっかくなのでクラスメソッドのエンジニアと １チームになって楽しい開発をしてみませんか？