製造業のアジャイル導入でたどり着いたスクラムのちょうどいい現場適用
製造ビジネステクノロジー部のかみとです。
クラスメソッド発 製造業 Advent Calendar 2025 10日目のエントリーです。
製造ビジネステクノロジー部は『クラウドとリアルの融合により製造業の新しい可能性を切り拓く』をビジョンに掲げ、製造業界のお客様と並走するパートナーとしてソフトウェア開発に取り組んでいます。
この記事では、製造業のお客様とアジャイル開発に取り組んできた中で得た学びをご紹介します。
製造業アジャイル導入の難しさ
製造業のソフトウェア開発現場でも、アジャイルを取り入れる動きが少しずつ広がっています。
しかし実際に導入を進めようとすると、以下のような場面に直面することがよくあります。
- スクラムガイドどおりに回すのが難しい
- ウォーターフォールが前提の体制が長く続いている
- ステークホルダーが多く、お客様の役割（プロダクトオーナーなど）が整わない
- ハードウェア側の工程や制約が大きく影響する
- 決裁・承認プロセスが重い
- 変化しつづけることに慣れていない
これは製造業に限らず、様々なプロジェクトでこういった "スクラムの理想形がそのまま当てはまらない事情" はたくさんあります。
アジャイルって手段でしょ？に対するもやもや
アジャイルについて会話するとき、よく耳にする言葉があります。
それは 「アジャイルって手段でしょ？アジャイルが向く現場と向かない現場があるよね」 というものです。
私はこの言葉を聞くたびに、少しモヤっとした感覚を覚えます。
なぜなら、アジャイルソフトウェア開発宣言にあるように、
『よりよい開発方法を見つけだそうとする』
ことがアジャイルの本質だと思うからです。
アジャイルは特定の手段や型ではなく、状況に応じて進化し続ける姿勢そのものです。
だからこそ、「向く／向かない」の二元論にしてしまうと、本来の価値を見失ってしまうのではないかと感じます。
製造ビジネステクノロジー部で感じたこと
製造業のお客様とプロジェクトを進める中で実感しているのは、
『どの現場も一つとして同じではない』
という事実です。
状況を左右するパラメータの例としては、
- チームメンバーのスキルセット
- アジャイルやスクラムへの理解・成熟度
- 顧客側のソフトウェアエンジニアリングの知見
- 契約形態・開発プロセスの制約
- 既存システムやハードウェアとの関係性
などがあります。
こうした複数の要因を踏まえて、チームに合った形にテーラリングしていくこと がチーム開発を進める上でとても重要だと感じています。
この記事では、アジャイルやスクラムの価値を守りながらも状況にうまく適応するための考え方をまとめました。
Scrum-ish？
英語圏のアジャイルコミュニティでは、
スクラムガイドに完全に準拠してはいないものの、
- スクラムの価値を守りながら
- 現場に合わせて柔軟に運用する
という実践を “Scrum-ish（スクラムっぽい）” と呼ぶことがあるそうです。
正式なものではなく、実務者のあいだで自然発生的に使われてきた俗称のようなもので、複数の海外ブログや登壇資料で使われています。
「スクラムの本質を守りつつ、現場の制約に合わせて最適化する」
というのは、まさに私たちが目指してきたことだと感じました。
Scrum-ishの批判的な文脈
肯定的な捉えられ方がある一方で、Scrum-ishはスクラムの原則を完全に理解せずに形だけ真似ているチームへの批判的なニュアンスで使われることもあります。
批判的な文脈では、Scrum-ishは 「中途半端なスクラム」 「なんちゃってスクラム」 といったニュアンスで使われ、その場しのぎや形式主義に対する皮肉や不満を表現する言葉として使われます。
また、こうしたネガティブな変更はScrumButとも呼ばれます。
スクラムの価値を守るための “前向きな適応” ではなく、
目先の課題解決を優先して価値を置き去りにする “妥協” として使われると、スクラムは価値を損ない、「なんちゃって」 な状態へと向かうリスクが高くなります。
Scrum-ish を実践するときのポイント
自分たちのチームが良い意味での Scrum-ish として効果を発揮するためには、いくつか重要なポイントがあります。
単なる"省略"ではなく、"意図的な適応"として機能させるために要点を深堀りしてみたいと思います。
1. イベントの目的と価値を維持する
スクラムをプロジェクトに適応させようとしたときに、最初に見直しの対象となりやすいのが、スクラムイベントの実施方法ではないでしょうか。
イベントの調整時に注意したいのが、目的と価値を省略しない というところです。
例えばチームで次のような事情があるとします。
- レビューに関係部署が多く、毎スプリントで全員が集まれない
- デイリーは現場業務と兼務のため、時間確保が難しい
- レトロスペクティブに必要なメンバーが固定できない
こうした場合でも「目的」を維持する形で調整することが大切です。
例：
- レビュー
- 参加できるステークホルダーに関係のあるインクリメントのみレビューし、参加できないステークホルダーについてはアドホックでレビューを行うか、次のスプリントに回す。
- デイリー
- 開発チームがスプリントゴールに向かっていることが確認したいことなので、必要情報を事前にSlackで共有、直面している問題を見える化するなど非同期要素を増やすことで最低限の時間で実施する。
- レトロスペクティブ
- 月1回でも必ずチームの改善アクションを決める
ポイントは、イベントの実施形式は変えても、イベントの価値までは変えないことです。
2. 変更の理由をチーム全体で合意する
スクラムのイベントや役割を変更する際、
「なぜその変更が必要なのか？」をチーム全員が理解していること が重要です。
理由が共有されていない変更は、誤解を生みやすくなります。
例えば、「顧客レビュー（スプリントレビュー）の頻度を落としたい」という要求があったとします。
こうした事情に対して
- “なぜ”変更が必要なのか
- 変更することで“何が守られる”のか（価値や目的）
- “何を失う可能性”があるのか
を明確にします。
スプリントレビューの頻度を落としたい理由が 「顧客側の工数問題」 だった場合、
スプリントを1週間から2週間に変えることで「検査と適用」のリズムを崩さずに価値提供が可能となりますが、それと引き換えにリリースサイクルは長くなります。
しかし、スプリントレビューを減らしたい理由が 「品質がある程度担保されているのでそこまで綿密なレビューの必要性を感じない」 というものだった場合、リリースサイクルを落とすことは「価値を落とさない課題解決の方法」として適切ではありません。
この場合であれば、例えばデイリーミーティングの際に簡易な動作デモなどのレビューを入れることで、スプリントレビューでは詳細なレビューは行わず、最終確認のみの場として簡略化するなどの工夫が可能です。
このように、変更の理由によって対処方法も違ってきます。
こうした変更に対して、チーム全員が理由と目的を理解し、合意していることが重要です。
3. ステークホルダーの期待値を明確にする
製造業では、一般的な Web/IT プロダクトと比べて ステークホルダーの数が圧倒的に多い ことがあります。
- 管理部門
- 設計部門
- OT部門
- 品質保証
- 営業
これだけステークホルダーが多いと、期待値のズレがプロジェクトの遂行に多大な影響を与えることになります。
スクラムイベントの実施において、
- どのイベントを何のためにどこまでやるのか
- どのイベントには誰がどんな目的で参加するのか
- 各ステークホルダーがプロダクトに求める価値と優先順位
- 最終的にどのステークホルダーの意見を優先するか
などの期待値を早い段階で言語化し、合意しておく必要があります。
特に、ITとOTで前提・文化・制約が大きく異なるケースが多く、期待値を合わせないと議論が噛み合いません。
OT部門とIT部門がどのような形で連携できるかについては、私たちの部署のハマコーさんの記事に事例とともにまとまっていますので、ぜひご参照ください。
4. “忙しいから省略” という理由で崩さない
これは "妥協" と "意図した適応" を分ける最も大きいポイントです。
忙しい時はイベントの本来の意味を見失いがちです。こういう時こそ"なぜやるのか？"の目的に立ち返ることが必要です。
- 「忙しいから」
- 「今は余裕がない」
- 「進捗が遅れているから」
これらが枕詞に付く場合、ScrumBut、いわゆる"妥協"である可能性が高いです。
現場適応のためのScrum-ish はあくまで 価値を守りながら“意図的に調整”すること であり、
忙しさによる “省略” は本質的に真逆です。
忙しいときほど、透明性・検査・適応のループを止めてはいけません。
イベントを無くすのではなく、「短くする」・「形を変える」・「タイミングを変える」などの工夫が必要です。
5. チームの成熟度に合わせて調整する
現場適応のためのScrum-ishは、スクラムの価値やイベントの目的を理解している “成熟したチーム” において特に効果を発揮します。
なぜなら、これは 「価値を守った上で、必要な部分だけを意図的に適応する」 というアプローチであり、そもそもスクラムの価値や型を理解していない状態では、何を守り、何を調整すべきか判断が難しいためです。
その意味で、Scrum-ish が高度な実践であることは確かです。
未成熟なチームにいきなりアレンジを加えると、
- 役割が曖昧になる
- 進捗が見えない
- 改善が進まない
といった混乱を招くことがよくあります。
一方で、製造業のように専門性が高い現場では
“スクラム未経験者”が多いことも珍しくありません。
ではそういった未成熟なチームではアジャイルの恩恵を受けることができないのかというと、決してそうではないと考えています。
未成熟チームでも活用できる“小さなアジャイル”
スクラムをいきなりフルセットで適用するのが難しいチームでも、
次のような 小さなアジャイル実践 から取り組むことができます。
- 短い朝会で状況を共有する
- 月1回だけでも振り返りを行う
- TDDやペアプロなど、部分的な技術プラクティスを試す
- 作業を時間で区切り、定期的に見直す習慣をつくる
これらはスクラムそのものではありませんが、
より良い開発方法を見つけるための大切な入口 になります。
成熟度に応じて段階的に広げていく
小さな実践に慣れ、価値が理解されてくると、スクラムイベントを整えたり、現場に合わせた適応（Scrum-ish）を行ったりと、取り組みの幅を自然に広げていくことができます。
つまり、
- 未成熟なチーム：小さく始める
- 慣れてきたチーム：スクラムを実践してみる
- 成熟したチーム：価値を守りながら現場に合わせて調整する
という流れが自然で無理のないアプローチなのではないかと考えています。
6. やり方を定期的に見直す（Scrumとの差分を検査）
やり方は 「一度決めたら終わり」 ではありません。
むしろ、現場の状況に合わせて進化させ続ける必要があります。
プロジェクトの現場では、
- リリースサイクルの変化
- 部署間の調整方法の変化
- 顧客側の成熟度向上
- 品質保証プロセスの見直し
- 担当者の人事異動
- プロジェクトフェーズの変更
など、環境の変化が頻繁に起きます。
そのため定期的に、
- いまのやり方は価値を生んでいるか？
- アレンジ部分は本当に必要なのか？
- スクラムの要素を戻すことで推進力になる部分はあるか？
- ステークホルダーの期待値が変わっていないか？
を検査し、必要ならやり方を調整します。
アジャイルの本質は "より良い方法を見つける"こと
スクラムの本質も、検査・適応・透明性、つまりは “現場に合わせて適応し続ける”こと です。
これらが揃っていれば、プロジェクトの特性を問わず非常に強力な実践になります。
製造業のアジャイル移行に必要なのは“本質を守る柔軟性”
製造業の現場では、工程、文化、組織構造、品質基準など、すぐには変えられないものが多く存在します。
だからこそ、スクラムを“そのまま”当てはめるのが難しい場面も多いのが実情です。
しかし、アジャイルの目的は「型を守ること」ではなく、
価値を届け続けること です。
また、Scrum-ishのような現場適応型のアプローチで状況に合わせたとしても、それはゴールではなく、現場にフィットさせるための一つの手段です。
手段を固定化するのではなく、状況に合わせて進化し続けることが重要です。
この記事が複雑な現場でアジャイルを進めるためのヒントになれば幸いです。
