2026/1/7 クラスメソッド株式会社 産業⽀援グループ 製造ビジネステクノロジー部 上⼾鎖保幸 製造業から学んだ 「本質を守り、現場に合わせる アジャイル実践」 

⾃⼰紹介 2 ● 会社 ○ クラスメソッド株式会社 Classmethod, Inc. ● 部署 ○ 製造ビジネステクノロジー部 ● 名前（ニックネーム） ○ 上⼾鎖 保幸 (かみと) Kamitokusari Yasuyuki (kamito) ● 出⾝‧住まい ○ 北海道‧ニセコ Hokkaido / niseko ● 家族構成‧趣味 ○ 4⼈家族 + ⽝2 ○ スノーボード ● 1998~2016 ⽇本タイムシェア株式会社 札幌⽀店 →ソラン北海道株式会社 →TIS北海道株式会社 ○ 業務アプリ開発 (VB、Java、C) ※もちろんWF ○ ⾦融系ソフトウェア開発保守 ※ガチのWF ● 2016~2020 フリーランス ○ ⾦融系ソフトウェア開発保守 ※ガチのWF ○ 物流系ソフトウェア開発 ※ふつうのWF & ゆるめのAgile ● 2020~現在 クラスメソッド株式会社 ○ 製造系ソフトウェア開発 ※ガチのAgile ○ ピープルマネージャー 

クラスメソッドとは 3 

会社概要 4 名称 クラスメソッド株式会社 本社所在地 東京都港区⻄新橋1-1-1 ⽇⽐⾕フォー トタワー 代表者 横⽥ 聡 従業員数 820⼈（2025年7⽉ グループ全体） 売上 950億円（2025年6⽉末） 設⽴ 2004年7⽉7⽇ (第22期) 国内 8拠点 東京 / 札幌 / 仙台/ 上越 / 名古屋 / ⼤阪 / 福岡 / 那覇 海外 5拠点 ベルリン（ドイツ） / バンクーバー （カナダ） /バンコク（タイ） / ソウル （韓国） /ダナン（ベトナム） 拠点 プリズマティクス株式会社 ネクストモード株式会社 クラスメソッドオペレーションズ株式会社 プロパゲート株式会社 クラスメソッドテクノロジーズ株式会社 グループ会社 クラウド（AWS等）の技術コンサル ティング、開発、運⽤ データ分析基盤の技術コンサルティン グ、開発、運⽤ アプリケーション（モバイルアプリ、 IoT等）の開発、運⽤ SaaS導⼊⽀援、運⽤⽀援 企業向けIT⼈材育成、内製化⽀援、⼈ 材派遣 ⽣成AIを活⽤した業務の効率化コンサ ルティングとシステムの導⼊⽀援 事業内容  

クラスメソッドの経営理念 5 オープンな発想 広い視野を持ち、何事にも積 極的に取り組んでいくのがク ラスメソッドのスタイルで す。作り⼿視点のプロ意識と 消費者視点のセールス意識を 軸に、社員の1⼈ひとりが現場 提案とスピード決裁をモッ トーとした課題解決を⾏って います。柔軟かつ⾏動的な姿 勢で、現在は4,000社を超える 企業への⽀援実績がありま す。 オープンな発想と⾼い技術⼒により、 すべての⼈々の創造活動に貢献し続ける ⾼い技術⼒ 私たちは常に興味と関⼼を持 ち、新技術に取り組むチャレ ンジを続けています。先進的 かつ専⾨性の⾼い技術⼒は AWSクラウド活⽤において最 上位企業のみが認定される 「AWSプレミアティアサービ スパートナー」や、国内初と なる「GitHub Enterprise」 パートナーシップ認定といっ た形で評価されました。 すべての⼈々へ 技術⼒でお客様の売上に貢献す るために、私たちはビジネス視 点とコンシューマー視点を兼ね 備えた柔軟な思考を⼼がけてい ます。それらを下⽀えするのは フラットな組織と個⼈裁量で す。クラスメソッドは学びを欲 するクリエイティブな⼈材を積 極的に採⽤し、より多くのお客 様にサービスをご提供します。 創造活動への貢献 クラスメソッドはお客様から 常に必要とされる付加価値を 提供し、社会から必要とされ る存在であり続けることを⽬ 指しています。そのために市 場へ⽿を傾け、技術情報やノ ウハウを⾃ら創造、発信、改 善し続け、お客様や技術コ ミュニティなど幅広い分野へ の貢献に努めます。 代表 横⽥ 聡 

クラスメソッドの強み 技術⼒×発信⼒ 6 憶測やセオリーだけでなく、実地検証に基づ く「やってみた」記事を公開。ユーザに有益 な情報であれば社内のノウハウも余すところ なく記事化。現在40,000本以上の記事を掲 載。 ⽉間300万PV 100万UUを誇る技術ブログ DevelopersIO https://dev.classmethod.jp/ エンジニア技術発信プラット フォーム Zenn Zennは、技術者にとっての知⾒獲得や学びの 機会を創出しご利⽤の皆さまとスポンサーと の融和的な接点を設ける、”三⽅よし”による ご⽀援を⽬指しています。 https://zenn.dev/ AWS関連ビジネスにおける収益‧販売実績 ‧技術者育成など、国内トップの貢献が評 価 Consulting Partner of the Year ‒ APJファイナリ スト 2025 

クラスメソッドの組織図 7 クラウド事業本部 データ事業本部 アライアンス事業部 業務⽀援グループ 経営企画グループ 海外グループ 情報システムグループ 管理グループ クラスメソッド オペレーションズ プリズマティクス プロパゲート ネクストモード 関連会社 ⼈事グループ クラスメソッド テクノロジーズ 営業統括本部 製造ビジネステクノロジー部 産業⽀援グループ ゲームソリューション部 リテールアプリ共創部 ⼩売流通ソリューション部 SBJソリューション部 

産業⽀援グループ 製造ビジネステクノロジー部 とは 8 

「クラウドとリアルの融合により 製造業の新しい可能性を切り開く」 をミッションに、 主に製造業のお客様と 並⾛しながらの開発を通して 新しい価値を提供する部署 産業⽀援グループ 製造ビジネステクノロジー部とは 9 

産業⽀援グループ 製造ビジネステクノロジー部とは 10 https://classmethod.jp/cases/category/iot/ 

産業⽀援グループ 製造ビジネステクノロジー部とは 11 アジャイル導⼊で製造業のビジネス価値を最⼤化 急速に変化するビジネスシーンでは迅速な市場変化への対応⼒と継続的なビジネス価値の最⼤化が求められ ています。組織にアジャイルを導⼊して企業の競争⼒を維持し、イノベーションを創出しましょう。 クラスメソッドだからできるアジャイル⽀援 ● 多数のアジャイル案件実績 ● エンジニアと協働する実践的な開発体験 ● 経験に基づいたリアルなアジャイル⽀援内容 製造業で⾼まる ソフトウェアの価値 アジャイルで変化へ柔軟に対応  さらなる価値を⽣み出す IoT データベース AI 

産業⽀援グループ 製造ビジネステクノロジー部とは 12 伴⾛型開発 伴⾛型開発は、お客様と⼀体となったチーム開発を実現するサービスです。両社のエンジニアが協働するこ とで最新の開発⼿法やワークフローのノウハウを段階的に移転し、プロジェクト完了後もお客様⾃⾝で継続 的な改善や開発が可能となります。 お客様 クラスメソッドが培って きた経験をお客様のエン ジニアと共有 プロジェクト完了後もお 客様⾃⾝で継続的な改善 や開発が可能 協同開発 クラスメソッド エンジニア プロダクトオーナー スクラムマスター エンジニア ● 伴⾛型開発で、⾼度な技術を効率的に習得 ● 開発⼿法やノウハウを他のプロジェクトにも展開可能 

産業⽀援グループ 製造ビジネステクノロジー部とは 13 技術スタック 種別 採用技術スタック（左から多い順）　赤字はほぼ全ての案件で使われているもの 言語 TypeScript(JavaScript), Python, Go デザイン Figma フロントエンドフレームワーク React.js, Next.js, Flutter CI/CD GitHub Actions, GitLab Runner, CodePipeline 開発プラットフォーム GitHub, GitLab IaC CDK, Terraform, CloudFormation コンピューティング Lambda, ECS on Fargate, EKS on EC2, EKS on Fargate データベース DynamoDB, Aurora, TimeStream 認証基盤 Auth0, Firebase, Cognito その他（AWS関連） IoT Core, Step Functions, WAF, SQS, API Gateway, SNS, EventBridge, AppSync, etc… 

私たち製造ビジネステクノロジー部が、 製造業のお客様と共に向き合ってきた中で アジャイルをどう適応させてきたか 14 

製造業から学んだ 「本質を守り、現場に合わせる アジャイル実践」 

本セッションの目標 16 • アジャイル実践につきまとう
 
 「こんなんでいいのかな？」
 「まちがったやり方なのでは？」
 
 という気持ちを、
 
 「正解かどうかはわかんないけど、やってみて少しずつ改善し ていこう！」
 
 という前向きな自信に変えられたら嬉しいです
 

アジャイルに対する、あの「モヤモヤ」 17 いろんな場⾯で、こんな⾔葉を⽿にし ませんか？ 「アジャイルって⼿段でしょ？ 向く現場と向かない現場があるよ ね。」 この⾔葉を聞くたびに、少しモヤッとした感覚 を覚えて返答に詰まってしまいます。 このモヤモヤの正体はなんだろう？ このセッションではそこを深堀ってみたいと思 います。 

まずはGeminiに聞いてみた アジャイルに対する、あの「モヤモヤ」 18 アジャイルが
 向いてる現場と
 向いてない現場の
 違いを教えて！
 

アジャイルが向く現場 アジャイルが向かない現場 要件（仕様） 曖昧、変化することを前提とする 明確、確定している ⽬的 価値の最⼤化（ユーザー満⾜） 計画の完遂（納期‧予算遵守） チーム構成 ⾃⼰組織化、多能⼯型 役割分担、指揮命令型 品質確認 頻繁なデモとフィードバック 最終⼯程での⼀括テスト リスク 常に変化し続けるリスク 最後に不具合が発覚するリスク アジャイルが向いている現場‧向かない現場 19 Geminiの回答 判断基準の比較表 どちらの手法を選ぶべきか、以下のチェックリストを参考にしてください。 

特に製造業ではアジャイル適応に対するハードルは少なくない 20 ● ハードウェアの仕様確定との同 期や、やり直しコスト ● 安全性‧法規制の壁 ● 分業化された組織体系 ● 歴史‧⽂化‧企業⾵⼟ ● etc… 

⽴ち返るべきアジャイルの本質とは？ 21 

22 ー アジャイルソフトウェア開発宣⾔：https://agilemanifesto.org/iso/ja/manifesto.html 

⽴ち返るべきアジャイルの本質 23 マインドの本質 ”「私たちは、ソフトウェア開発の実践
 あるいは実践を手助けする活動を通じて、
 よりより開発方法を見つけ出そうとしている。」” つまりアジャイルとは、「特定の型」を守ることではなく、「状況に応 じて進化し続ける姿勢 そのもの」
 ー アジャイルソフトウェア開発宣⾔：https://agilemanifesto.org/iso/ja/manifesto.html 

⽴ち返るべきアジャイルの本質 24 プラクティスの本質 XPによる ”フィードバックループの短縮” 「隠れた前提」の早期発見 ● ドキュメント上では合意できていても、実装してみないと判明しない技術的制約や矛盾を早 期に炙り出す。 変化への適応力の向上 ● 突発的な計画変更に対して、柔軟に適応する考え方があれば、被害を最小限に抑えられ る。 チームの心理的安全性の確保 ● 「最後にまとめて報告」ではなく「こまめに現状を共有」することで、問題が発生した際に隠 蔽されず、早期に対策を打てるようになります。（透明性） 
 ーエクストリームプログラミング https://commons.wikimedia.org/wiki/File:XP-feedback.gif 

これらの本質は ソフトウェア開発全般に通じる話で、 アジャイルとかウォーターフォールとか 関係なくね？ 25 

もっと⾔うと、 これって、当たり前のことしか ⾔ってなくね？ 26 

では視点を変えて ウォーターフォールの本質とは？ 27 

ウォーターフォールの原典 ウィンストン‧W‧ロイス博⼠の論⽂ 28 ー Managing the development of large software systems : https://www.praxisframework.org/files/royce1970.pdf 意訳 (ChatGPT < 初⼼者向けにわかりやすく説明して)： 私は⼿順に従ったソフトウェア開発というコンセプトが良い と考えていますが、この⽅法にはリスクもあり、失敗の可能性 も含まれています。 （〜中略〜） もしテストでこれらの要件を満たせなかった場合、要件の⾒ 直しか⼤幅な設計変更が必要となり、最悪の場合、プロジェク トが最初からやり直しになり、スケジュールやコストが⼤幅に 超過する可能性があります。 （〜中略〜） このリスクを減らすためにはさらに5つの要素を追加する必要 があります。 1. 最初に設計をしっかりやる 2. 設計をドキュメント化する 3. 2回やる 4. テスト計画‧設計をちゃんとやる 5. 顧客を関与させる 

ウォーターフォールにも当然 ソフトウェア開発に必要な本質的な要素は 詰まっている 29 ウォーターフォールとアジャイルは 相反関係にない 

アジャイルをやってみたけど うまくいかなかったケースとは？ 実体験をもとに２つの例 30 

⼀つの極端な例：「なんちゃってアジャイル」をやっていた 31 ● 「忙しいから」を理由に、都合の悪いプラクティスを省略する ● 目的が不明確なまま、朝会だけ、ふりかえりだけ、といった部分的な導入に留まる ● アジャイルだからという理由で全体設計や必要なドキュメンテーションを行わない 形式だけを真似て、目的が失われた状態・・・ 現場の声 問題点 ● 情報の⾮対称性が⽣じる。 ● フィードバックや学びが⽣まれず、改善が停 滞する。 ● プロダクトの基本設計や⾮機能要件が曖昧。 ● コアな業務ドメインが属⼈化する。 「毎⽇朝会をやってるけど、ただの進 捗報告でこれって意味あるのかな」 「直近のタスクは⾒えるけど、プロダ クトの全貌が⾒えない」 

32 ● スクラムのルールを絶対視 ● 役割、イベント、作成物を厳格に守ることを最優先する スクラム原理主義的なアプローチ・・・ 現場の声 問題点 ● 現場の複雑な制約（組織構造、⽂化、契約） を無視し、チームを疲弊させる。 ● 形式にフォーカスするあまり、本来の価値が 得られない。 ● プロジェクトの進め⽅に対する顧客との期待 値のズレ。 「POが不在なのはスクラムのルールに 反している」 「スプリントレビューに全員参加でき ないなら、やる意味がない」 もう⼀つの極端な例：「教科書通りのスクラム」をやろうとした 「アジャイルは失敗だった」 「スクラムはうちには合わない」 

33 プロダクトの特性や現場の制約など さまざまなパラメータを柔軟に考慮しつつ、 本来の⽬的を落とさない 「現場に適応したアジャイル」 とは 

34 ● プラクティスやイベントの目的を理解しつつ ● 現場に合わせた負荷の少ない小さな適応を繰り返す 現場に適応したアジャイル なんちゃってアジャイルとの違い 「現場に適応したアジャイル」とは スクラム原理主義との違い なんちゃって 現場適応 原理主義 現場適応 妥協と省略 本質を守るための 工夫と最適化 フレームワークを 厳格に守る フレームワークを ベースにしつつ、本 質を損なずに現場 に合わせる 

案件での実践例 35 

実践例①：プロダクトオーナーやキーマンが多忙な現場 36 課題 ● プロダクトオーナーが多忙で、意思決定が遅れがち。 ● プロジェクトのキーマンが複数案件を掛け持ちしていてまとまった時間が取れない。 陥りがちな罠 現場適応アジャイル ● PO不在のまま開発を進め、仕様の確認が遅 延する。 ● 情報連携のタイミングが合わず、情報の非対 称性が生じる。 ● POの役割をチーム内外で定義し、補完する。例えば 顧客側のキーマンと、UXデザイナー、開発チームの リーダーが協調してバックログを管理する。 ● 週の中での稼働時間を合わせる。例えば、⽕‧⽔‧ ⽊を案件稼働⽇とチームメンバーで決める。 意思決定のボトルネックを解消し、作るべきものの優先順位と透明 性を確保。 ⽬的 

37 課題 ● 品質保証、生産技術、営業など多数の部署が関わるため、スプリント毎のレビューに全員が参加 できない 陥りがちな罠 現場適応アジャイル ● 「どうせ全員集まらないから」とレビューを省略す る。 ● 開発チームだけの内輪のデモで終わってしま う。 ● 結果、ステークホルダーからのフィードバックが 得られない。 ● レビューの頻度や形式を調整する。 ● スプリントを2週間、関係部署を巻き込むレ ビューは⽉1回に集約。 ● スプリント毎の成果物は動画デモなどで⾮同期に 共有する。 形を変えてでも重要なフィードバックを得る機会を確保する。 ⽬的 実践例②：関係者が多く、レビューへの参加調整が困難 

38 課題 ● 厳格な品質保証部門のプロセスがあり、スプリント内で完結させることが難しい 陥りがちな罠 現場適応アジャイル ● QAプロセスを外部のものとして割り切り、見て見 ぬふりをする。 ● プロジェクトの最後にまとめてQAに依頼をし、膨 大な手戻りを発生させる。 ● スプリントレビューやリファインメントの段階か らQA担当者を巻き込み、早い段階で品質要件を 確認。 ● テスト可能な⼩さな単位で連携する。 フィードバックループを短くし、問題が小さいうちに起動修正できる よう適応のサイクルを回す。 ⽬的 実践例③：品質保証のプロセスが重く、スプリントに収まらない 

アジャイルの柔軟な現場適応を成功させるための６つのポイント 39 1. イベントの⽬的を維持する 形式を変えても、⽬的が達成でき る代替⼿段を考える。 2. 変更の理由をチームで合意 する 3. ステークホルダーの期待値 を揃える 「なぜ変えるのか？」の共通認識 がなければ、チームメンバーに とっての⾃分事にならずただの改 悪になる。 組織が複雑な場合、期待値のズレ は致命的。関係者間で共通認識を 持ちながら進める。 4. “忙しいから省略”をしない 省略の理由が「忙しいから」にな ると、本来的な⽬的を⾒落とすこ とになりがち。 5. チームの成熟度に応じて段 階的に広げる 6. やり⽅を定期的に⾒直す いきなり⾼度な適応はしない。ま ずは型から学び、徐々に適応の幅 を広げる。 適応は⼀度決めたら終わりではな い。 常に「今のやり⽅が最適か？」を 問い続ける。 

ただし、このアプローチには 「チームがそれなりに成熟している」 ことが前提になっている 40 

「チームの成熟度」という前提条件 41 経験の浅いチームがいきなりアレンジすると・・ ● 守るべき本質を見失い、単なる「なんちゃって」に陥ったり ● 役割が曖昧になり、混乱を招いたり 
 現場適応アジャイルは「経験の浅いチームの逃げ道」ではなく、「成熟し たチームがより価値を出すための方法
 アジャイルの現場への柔軟な適応は、そもそもプラクティスやイベ ントの価値と目的を理解しているからこそ効果がある。 

「チームの成熟度」という前提条件 42 いきなりフルセットでスクラムを導入するのが難しくても、アジャイルの価値に ふれる「小さな実践」はたくさんあるはず。 「小さなアジャイル実践」の例： ● 短い朝会で状況を共有する ○ 情報の非対称性をなくし、助け合いの文化を醸成する。 ● 月に１回でも軽いふりかえり（KPTなど）を行う ○ 課題を放置せず、継続的に改善する習慣をつける。 ● 作業を時間で区切り、定期的に見直す習慣をつくる ○ 計画とふりかえりのリズム（検査と適応のサイクル）を体験する。 ● XPのプラクティスを導入してみる ○ TDD、CI、ペアプログラミング、テストの自動化などの改善をすこしずつ導入する。
 
 「より良い開発方法」を見つけるための大切な第一歩
 では、経験の浅いチームは何から始めるべきか？ 

まとめ 43 

チームのコンテキストにおいて、改善によりチームが進化し続け、プロダ クトのフィードバックループを回し、「透明性・検査・適応」のサイクルを効 果的に回せる形があればそれが「正解」なのだと思います。
 アジャイルが合うのか合わないのか、ではなく、どうすればソフトウェア 開発をうまくやることができるのか？本質を守りながら私たちの現場に 合わせられるのか？を問い続けること。
 それがアジャイルの本質的な実践ではないでしょうか。
 まとめ 44 アジャイルは、「より良い方法を見つけ出そうとする」旅路そのもの 

ありがとうございました 45