老舗メーカーにみんなで アジャイルを導入してみました ~「俺がやる！」から 「みんなでやる！」 に至るまで~

2021/06/26 Scrum Fest Osaka 2021での講演資料です
2024/06/20にSlideshareから移行しました

Transcript

1. 老舗メーカーにみんなで アジャイルを導入してみました ~「俺がやる！」から 「みんなでやる！」 に至るまで~ コニカミノルタ株式会社 品質本部 共通品質保証センター 新規事業品質保証部 中原 慶 2021/06/26 Scrum Fest Osaka 2021 1
2. 中原 慶(44歳) 大阪市出身 東京在住 2 WEBアプリ開発 DWH開発 新規サービス開発 アジャイル推進・コーチ 教育・技術コンサル ツール開発 2000年 2004年 2012年 実行委員 ソフトハウス 実行委員 https://www.slideshare.net/keinakahara3 https://www.facebook.com/kei.nakahara3
3. © KONICA MINOLTA コニカミノルタの歩み 写真フィルム・カメラ事業撤退 2003年 経営統合 2007年 創業事業を撤退 写真・石板材料事業 1873年 コニカ創業 コニカミノルタ誕生 1928年 ミノルタ創業 カメラ事業 147年 新たな歴史の 始まり
4. © KONICA MINOLTA コニカミノルタの構成と売上
5. © KONICA MINOLTA コニカミノルタのコア技術と最新のICT技術 技術の融合 微細 加工 画像 材料 光学 ４つのコア技術 ICT Technologies Robotics AI IoT
6. © KONICA MINOLTA コニカミノルタが推進する画像IoT・AI構想 光学デバイス ・ 画像処理技術 × IoT／AI技術 課題解決 Cloud Edge AI 画像IoT プラットフォーム （リアルタイム処理） Input Recognition Output Analytics Prediction コニカミノルタの強み（光学デバイス・画像処理技術）と IoT／AI技術を掛け合わせ、 高度な “画像IoTソリューション” お客様に提供し、社会課題の解決を目指します
7. FORXAIは、お客様・パートナーと共に、 社会のDXを加速させる 画像IoTのプラットフォームです。 ネーミングには「未来を切り開く先見性：Foresight 」と「AI を社 会のために：For X AI」という２つの想いが込められています。変 革を意味する「X」で重なり合う矢印が、お客様やパートナー、そし て私たちの技術が融合し、未来志向で前進する姿を表しています。 私たちは、Go Beyond Human Vision をパーパスに、人とテクノ ロジーが意識せずに共存・協働し、発展し続ける安全・安心社会の実 現に挑戦していきます。 【FORXAI Webサイト】https://FORXAI.konicaminolta.com/ 【画像IoT Webサイト】https://imaging-iot.konicaminolta.com/
8. © KONICA MINOLTA 今日のお話しが弊社の 「アジャイル」の 全て ではありません 9
9. © KONICA MINOLTA 対象 事業会社の方 # できれば老舗の # できれば製造業 10
10. Kei Nakahara kei.nakahara3/ 老舗メーカーにみんなで アジャイルを導入してみました ~「俺がやる！」から 「みんなでやる！」 に至るまで~ @keinakahara @Nakaharakei
11. ゴールの 共通化 ソフトウェア開発の 健全化 今日のお話し
12. 釈迦に説法ですが・・・ VUCAの時代と言われています V：Volatility（変動性）, U：Uncertainty（不確実性） C：Complexity（複雑性）, A：Ambiguity（曖昧性）
13. ゴールの共通化 コンピューター技術の進歩 ソフトウェアシステムがビジネスを牽引 ソフトウェアの特性を活かしたビジネス の進め方が競争力を高める
14. 短いフィードバックサイクルで 学びに基づき価値を育てる
15. 引用 https://ja.wikipedia.org/wiki/エクストリーム・プログラミング extreme programming のフィードバックサイクル
16. © KONICA MINOLTA ビジネスのフィードバックサイクル 構築 計測 学習 計画 検査 適応 ビジネス仮説一覧 Product Backlog ドメイン 社会課題 ビジネスモデル仮説 ミッション ビジョン Customer/ Problem fit Problem/ Solution fit Solution/ Product fit Product/ Market fit ①アイデアの検証 ②プロダクトの検証 継続、撤退、 ピボット判断 継続、撤退、 ピボット判断
17. © KONICA MINOLTA ビジネスのフィードバックサイクル 構築 計測 学習 計画 検査 適応 ビジネス仮説一覧 Product Backlog ドメイン 社会課題 ビジネスモデル仮説 ミッション ビジョン Customer/ Problem fit Problem/ Solution fit Solution/ Product fit Product/ Market fit ①アイデアの検証 ②プロダクトの検証 継続、撤退、 ピボット判断 継続、撤退、 ピボット判断
18. Scrumでは Scrum Teamを定義
19. Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how. ・・・ The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. スクラムチームはクロスファンクショナルなチームやで。つまりメンバーはス プリント毎に価値を作るために必要な全てのスキルを持ってるんやで。 スクラムチームは、誰が、何を、いつ、どうやってやるのかをチーム内で決める、 セルフマネージングなチームなんやで。 ・・・ スクラムチームは製品に関する全ての活動（利害関係者とのコラボ、検証、 メンテ、運用、実験、リサーチ、開発とかその他求められるもの何でも）に 責任があるんやで。 引用：『The Scrum Guide 2020』 P.5 Scrum Team https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf 注）オレオレ翻訳です。間違えてたらごめんなさい Scrum Team
20. © KONICA MINOLTA 老舗メーカーでは 何が課題か？ 22
21. © KONICA MINOLTA 組織構造と文化 23
22. © KONICA MINOLTA ビジネスのフィードバックサイクル ビジネスを 考える人 SWを 作る人
23. SW要求 企画/ ビジネス要求 役割によってゴールが違う 25 SW要件 動くソフトウェア ビジネスを考える人 【ゴール】 売れる企画を考えること 【ゴール】 要求通りのSWをQCD を守って開発すること SWを作る人
24. SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 情報劣化/誤解に起因する ビジネスインパクト！！ 納期遅延、販売機会損失、市場クレーム ココ 誰が考えるの？ 26 ビジネスを考える人 言わなくても わかるだろ！！ 聞いてない！！ 書いてない！！ SWを作る人
25. © KONICA MINOLTA 誰の責任？ 開発が悪い！ 企画が悪い！ 27
26. © KONICA MINOLTA 誰の責任？ ではなく チームの責任 28
27. ゴールを 共通化 しよう！ 29
28. ゴールの 共通化 コニカミノルタに マッチした 要求開発の メソッドづくりと 浸透
29. これまでの開発 ビジネスを 考える人 SWを 考える人 ユーザが◦◦な時に××でき る機能があると 70%までシェアが伸ばせる 要求を受けてQCDを守って開発する 御用聞き どうやって作ろ うかなぁ～ あ～だこ～だ Product Owner （企画部門） Developer （開発部門） 31
30. チームで要求を開発する ビジネスを 考える人 SWを 考える人 • 前も同じような機能を 作ったけど本当にいる？ • 〇×より、△▪な機能が トレンドだよ ユーザが◦◦な時に××で きる機能があると 70%までシェアが伸ばせる 開発者も要求を提案、却下する 脱御用聞き ビジネス観点 技術観点 Product Owner （企画部門） Developer （開発部門） 32
31. ビジネスの仮説検証サイクルの中で ゴールを共有するために アジャイル型要求開発 ビジネスを 考える人 SWを 考える人 Product Owner （企画部門） Dev （開発部門） 企画/ ビジネス要求 アジャイル型 要求開発 設計 テスト 実装 33 チームで要求を開発する
32. で、具体的に どうやってるの？ 34
33. © KONICA MINOLTA ゴールを共有するとは どういうことか 35
34. 36 誰の どんな課題を どのように解決し どんな効果(価値)を 狙っているのか
35. 37 そのために 何を どこまで作るか
36. 38 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何を どこまで 作るか
37. ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いる手法 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の 特定 誰の どんな課題を どのように 解決するか 何を どこまで 作るか 手順 39
38. © KONICA MINOLTA 誰の どんな 困り事を どのように解 決するのか ペルソナ Customer Journey Map 40
39. 引用:https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909 User Story Mapping ユーザーの 活動(ワークフロー) Option Rich ここまで作る 41
40. © KONICA MINOLTA 非機能要求は？ 42
41. © KONICA MINOLTA 非機能要求が 決まらなければ 最適なアーキテクチャ は 決定できない 43
42. 44 ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いる手法 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何を どこまで 作るか 手順 運用体制/コスト面も含む サービスの保証範囲（サー ビスレベル）の検討と共有 サービスレベルを満たす 非機能要求と 実現範囲を特定
43. 最小限の価値と実現範囲の特定 非機能要求特定 評価方法と目標値 設定 ユーザータスクの 洗い出し 受け入れ基準 設定 見積もり 優先順位付 見積もり 優先順位付 User Story Mapping 非機能検討 要求項目(User Story) サービスの 保証範囲 どんな観点を どんな優先順位で どの程度保証するか 非機能要求の観点 ex. ・IPA非機能能要求グレイド ・JIS X 25010:2013 製品品質モデル Product Backlog リリースまでに絶対にやらないとい けない項目(e.g. セキュリティテス ト、負荷テスト)は最優先に配置 非機能要求対応項目 45
44. 何をもって できた とするか？
45. 受け入れテストでゴールを合意 受け入れテスト作成 自動テスト作成/ テスト実施 テスト結果確認 スプリント計画 スプリント スプリント レビュー テスト管理ツール PO QA Dev [ 受け入れテスト All Green ] リリース計画 リリース レビュー [All Green ] 47
46. 2018年 社内課題収集 世の中調査 自社の課題に 合ったメソッド 構築 研修作成 試行 人事施策 として 全社展開 各事業部門の トップへ 説明行脚 2016年 2017年 賛同者作り 話を大きく する コミュニティ発足 トップの巻き込み 仲間づくり 「アジャイル型要求開発」の構築から現在までの経緯 2019年 2020年 海外展開開始（研修開催） コミュニティメンバが研修に参画 コミュニティの自走 海外で研修、認定制度が自走 研修の運営が完全にコミュニ ティで自走(講師育成含む) さらなる 広がりと仲間づくり 文化として 定着
47. 2018年 社内課題収集 世の中調査 自社の課題に 合ったメソッド 構築 研修作成 試行 人事施策 として 全社展開 各事業部門の トップへ 説明行脚 2016年 2017年 賛同者作り 話を大きく する コミュニティ発足 トップの巻き込み 仲間づくり 「アジャイル型要求開発」の構築から現在までの経緯 2019年 2020年 海外展開開始（研修開催） コミュニティメンバが研修に参画 コミュニティの自走 海外で研修、認定制度が自走 研修の運営が完全にコミュニ ティで自走(講師育成含む) さらなる 広がりと仲間づくり 文化として 定着
48. 一緒に広めてくれる 仲間 が必要
49. 広く事業の現場に浸透するよう 海外にも展開
50. © KONICA MINOLTA 共に広め、実践してくれる仲間づくり 54 コアメンバー アクティブメンバー 周辺メンバー コアメンバー（全体の10~15%） アクティブメンバー（全体の15~20％） 周辺メンバー（全体65~75%） コーディネーター コミュニティが領域に焦点を当て、さまざまな関係を維持し、 実践を開発することができるように手助けをする人 「実践コミュニティ」を発足 課題や事例、情報を共有、議論する場の構築 個人の成長、組織への貢献につながる場
51. 55 出典：書籍「コミュニティ・オブ・プラクティス」p33より 実践コミュニティとは あるテーマに関する関心や問題、 熱意などを共有し、 その分野の知識や技能を、 持続的な相互交流を通じて 深めていく人々の集団
52. 実践コミュニティでの活動が個人の成長をもたらす 実践コミュニティでの 活動 職場での 実践
53. 受講者 認定者全員参加 実践コミュニティ 研修 コアメンバー 研修講師・運営担当者 課題、事例共有 ナレッジ共有 講師育成 エコシステムを形成
54. チームが 状況に応じた 最良の一手を 都度選択できる 力をつける仕組み ソフトウェア開発の 健全化
55. 基準の無い プランニングポーカー プロダクトオーナーと その手下 リリース前に 品証さんが初めてテスト PBIがWBSの ワークパッケージ POが仕様を決める 開発者は作る 何でもアジャイル アジャイルなので ドキュメントは書かない アジャイルなので テストしない 色んな勘違い
56. 60 「アジャイル」を 魔法の言葉にしない 実践事例をもって有効性を示す 正しい理解を広げる(Why/How/What) 経営層から現場まで全てを巻き込む
57. 61 「アジャイル」を 魔法の言葉にしない 実践事例をもって有効性を示す 正しい理解を広げる(Why/How/What) 経営層から現場まで全てを巻き込む
58. 企画 要件 定義 設計 開発 評価 出荷 プロジェクト計画 の提案/審議 第三者評価者が テストケース作成 関係者が出荷に納得し、 品証が出荷を承認 後工程になればなるほど影響が大きい • 納期遅延によるコスト増（Delay of Cost） • 品質問題の市場流出による信頼低下、販売機会損失
59. More Effective Agile https://www.amazon.co.jp/dp/B089KFKB5H/
60. アジャイルで開発すれば解決される！
62. アジャイルで開発すれば解決される！ 短周期で、品質が確保された 出荷可能な製品を開発するから
64. 短周期で、品質が確保された 出荷可能な製品を開発するから 何をもって出荷可能？ • 誰が判断？ • どうやって判断？ • いつ判断？
65. 企画 要件 定義 設計 開発 評価 出荷 プロジェクト計画 の提案/審議 第三者評価者が テストケース作成 関係者が出荷に納得し、 品証が出荷を承認 何をもって出荷可能？ • 誰が判断？ • どうやって判断？ • いつ判断？ →品証 →エビデンス →リリース前
66. 品証 Evidence 同じやん！
67. 計画 出荷 開発 リリースに必要な事と達 成方法、基準をチームと 共に定義 リリースに必要な事が満た されている事を常時確認 リリースに必要な事が満た されている事を示すエビデ ンスを確認し、出荷承認
68. 計画 出荷 開発 リリースに必要な事と達 成方法、基準をチームと 共に定義 リリースに必要な事が満た されている事を常時確認 リリースに必要な事が満た されている事を示すエビデ ンスを確認し、出荷承認 自動化 自動化
69. 73 実践の開始
70. 74 「アジャイル」を 魔法の言葉にしない 実践事例をもって有効性を示す 正しい理解を広げる(Why/How/What) 経営層から現場まで全てを巻き込む
71. 社内横断的な 現場レベルの 仲間づくり 75
72. © KONICA MINOLTA 社内横断的な全社活動の立ち上げ • ナレッジや課題の蓄積、共有 • 現場レベルのコミュニティ(気軽に相談できる場) 事業領域 76 横断組織によるアジャイルのナレッジ流通
73. © KONICA MINOLTA 横断組織によるアジャイルのナレッジ流通 社内SNS 課題共有、議論の場の構築 社内版Qiita ナレッジ共有、課題共有の場 77
74. 78 「アジャイル」を 魔法の言葉にしない 実践事例をもって有効性を示す 経営層から現場まで全てを巻き込む 正しい理解を広げる(Why/How/What)
75. 79 組織構造と文化の変革には トップダウンと ボトムアップの 両方が必要
76. 多数の役員、事業部長を招き アジャイルの理解を揃える会を毎年開催 横断組織によるアジャイルのナレッジ流通 80 FY2017 全社向け共有会 FY2018 全社向け共有会 社内事例の共有に加えて、日本のアジャ イルのパイオニアを外部講師に迎え、ビ ジネスとアジャイルの講演を開催。ア ジャイルの理解と効果を揃えた 社内事例の共有に加え、他事業会社 の実践者を迎え実活用に向けたア ジャイル型開発定着の勘所を共有し た (参加者： 11拠点, 450名) (参加者： 12拠点, 620名) 全社向け共有会 サービスビジネス事例を含む社内事 例の共有に加え、新規ビジネスの創 発を牽引する老舗製造業の有識者を 迎え、ビジネス成果につながるア ジャイル型開発の効果を共有した (参加者： 13拠点, 620名) FY2019
77. © KONICA MINOLTA 81 引用：日経産業新聞 https://www.nikkei.com/article/DGXMZO4059836029012019X20000/ 横断組織によるアジャイルのナレッジ流通
79. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ Coaching PO Dev Scrum Master Coach Team （Agile CoE） 育成 経験者の参画 ➢ Agile Center of Excellence の狙い • ビジネスやチームの特性に適した体制や進め方を自分達で決め続け られるチームを醸成する仕組みの構築する ➢ FY20 活動方針 • 他チームをハンズオンで支援。経験者を増やすことで全社的に浸透 度を向上 • セルフアセスメントを展開することで、チームの自律的な改善を促 進する
80. © KONICA MINOLTA © 2018 Konica Minolta, Inc. 社内アジャイルコーチチームの立ち上げ Agile CoE 啓蒙・教育 コーチング エンジニアリング 支援 • 基礎教育の展開 • ナレッジの蓄積、展開 • 啓蒙、情報共有 • チームに伴走、コーチング • アセスメントの構築と展開 • 高速開発を支えるエンジ ニアリングプラクティス の展開(e.g. TDD, CI/CD, メトリクス) Agile Center of Excellence (Agile CoE) 現場のチームが自律的にアジャイル型開発を推進で きるように支援する、全社横断のコーチングチーム
81. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ 活動事例 - セルフアセスメントの作成と展開 - 全体俯瞰したレーダーチャート 役割ごとの乖離が大き い項目 世の中のセオリーに対し て下回っている（できて いない）項目 改善案 弱点の原因を関係者・チーム全員で対話し、 課題と改善計画をチーム自身で作成 チーム自身での改善が難しい場合はAgile CoEが支援
82. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ Agile CoE 全員が Excellenceではない
83. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ 社外から経験豊富で優秀な 人員をハイアーしよう！ 社外の有識者をハイアーし つつ、社員を育てよう！
84. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ コーチング活動を通じて、コーチを育成 コーチ候補の名前 必 要 な コ ン ピ テ ン シ ー 現在のコン ピテンシー レベル 必要な人数 タスク（実務）の クライテリア スキル習得の方法 参照) コンピテンシーマトリクス Blog: 変化に強いチームの作り方 https://note.com/naka_3/n/na2f19d978979
85. 多くのチームから 支援要請あり Agile CoEで 手分けして対応 支援テーマリスト
86. まとめ
88. ビジネスの仮説検証サイクルの中で ゴールを共有するために チームで要求を開発する アジャイル型要求開発 ビジネスを 考える人 SWを 考える人 Product Owner （企画部門） Dev （開発部門） ユーザー視点で 品質を 考える人 QA （品質保証部門） 92
89. 自分のメソッドからみんなのメソッドに
90. 94 ソフトウェア開発の 健全化
91. 95 「自分はできる」から「みんなができる」に
92. コッター氏が提案している企業変革の8段階プロセス 1. 危機意識を生み出せ 2. 変革を進めるための連帯チームを結成する 3. ビジョンと戦略を作る 4. ビジョンを周知徹底する 5. 従業員の自発を促す 6. 短期的な成果を実現する 7. 成果を活かしてさらに変革を進める 8. 新しい方法を企業文化に定着させる 引用：「リーダーシップ論」 ジョン・P・コッター https://www.amazon.co.jp/dp/447801339X
93. 情報処理学会 デジタルプラクティス vol.11 No.2 「組織的なアジャイル開発活用の施策とその推進役の育成 ─コニカミノルタの施策に基づいて考える─」 https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=204353&item_no=1&page_id=13&block_id=8
94. • 参加人数：886名 (内、役員 15名) • 19年度 620名から大きく増加 • お客様およびコニカミノルタのDXを牽引す る国内外の新規事業テーマから事例を共有 • 外部講師から日本の弱点と克服に向けたDX 施策のご提案をご講演 • CTOはじめ各役員から共感、および、継続 的な活動への期待の声多数 アジャイルナレッジ共有会 FY20
95. 私がやったことは コンセプトを決めて 外部講師と繋いだだけ 全て Agile CoEの メンバーが担当
96. 俺がやる！
97. みんなでやる！
98. Agile CoEで支援したテーマが そして・・・ アジャイルのカンファレンスで発表するに至りました！ このあとすぐやん！！ 広島トラックで！！ 乞うご期待！！
99. ありがとう ございました 10 3