老舗企業のアジャイルトランスフォーメーションの旅の途中

2021/02/25に分散アジャイルチーム勉強会で講演した資料です
2024/06/20にSlideshareから移行しました

Transcript

1. 老舗企業の Agile Transformationの 旅の途中経過 コニカミノルタ株式会社 IoTサービスプラットフォーム開発統括部 中原 慶 2021/02/25 分散アジャイルチームについて考える会 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 コニカミノルタが考える「みたい」の変遷 見たい 観たい 視たい 診たい 看たい 見せる 観せる 視せる 診せる 看せる 光 学 画 像 材 料 微 細 加 工 コア技術 オフィス事業 プロフェッショナル プリント事業 ヘルスケア事業 産業用材料・機能事業 QoLソリューション事 業 プラネタリウム事業 人間にとって大切な「みたい」をベースに コア技術を活かした新たな価値を提供するデジタルカンパニーへと変化しています
7. © KONICA MINOLTA コニカミノルタが推進する画像IoT・AI構想 光学デバイス ・ 画像処理技術 × IoT／AI技術 課題解決 Cloud Edge AI 画像IoT プラットフォーム （リアルタイム処理） Input Recognition Output Analytics Prediction コニカミノルタの強み（光学デバイス・画像処理技術）と IoT／AI技術を掛け合わせ、 高度な “画像IoTソリューション” お客様に提供し、社会課題の解決を目指します
8. FORXAIは、お客様・パートナーと共に、 社会のDXを加速させる 画像IoTのプラットフォームです。 ネーミングには「未来を切り開く先見性：Foresight 」と「AI を社 会のために：For X AI」という２つの想いが込められています。変 革を意味する「X」で重なり合う矢印が、お客様やパートナー、そし て私たちの技術が融合し、未来志向で前進する姿を表しています。 私たちは、Go Beyond Human Vision をパーパスに、人とテクノ ロジーが意識せずに共存・協働し、発展し続ける安全・安心社会の実 現に挑戦していきます。
9. コニカミノルタの画像IoT 専用Webサイトと、 FORXAI Web サイト OPEN！ 下記URLよりアクセスください 【FORXAI Webサイト】https://FORXAI.konicaminolta.com/ 【画像IoT Webサイト】https://imaging-iot.konicaminolta.com/
10. Innovation Garden OSAKA Front Center ＠高槻 ＠梅田 Center高槻 全域を キャリア/ローカル５Gでカバー、 共創の場で新サービス創出
11. © KONICA MINOLTA 今日のお話しが弊社の 「アジャイル」の 全て ではありません 11
12. © KONICA MINOLTA 対象 事業会社の方 # できれば老舗の # できれば製造業 12
13. Kei Nakahara kei.nakahara3/ 老舗企業の Agile Transformationの 旅の途中経過 @keinakahara @Nakaharakei
14. ゴールの 共通化 ソフトウェア開発の 健全化 今日のお話し
15. 釈迦に説法ですが・・・ VUCAの時代と言われています V：Volatility（変動性）, U：Uncertainty（不確実性） C：Complexity（複雑性）, A：Ambiguity（曖昧性）
16. ゴールの共通化 コンピューター技術の進歩 ソフトウェアシステムがビジネスを牽引 ソフトウェアの特性を活かしたビジネス の進め方が競争力を高める
17. 短いフィードバックサイクルで 学びに基づき価値を育てる
18. 引用 https://ja.wikipedia.org/wiki/エクストリーム・プログラミング extreme programming のフィードバックサイクル
19. © KONICA MINOLTA ビジネスのフィードバックサイクル 構築 計測 学習 計画 検査 適応 ビジネス仮説一覧 Product Backlog ドメイン 社会課題 ビジネスモデル仮説 ミッション ビジョン Customer/ Problem fit Problem/ Solution fit Solution/ Product fit Product/ Market fit ①アイデアの検証 ②プロダクトの検証 継続、撤退、 ピボット判断 継続、撤退、 ピボット判断
20. © KONICA MINOLTA ビジネスのフィードバックサイクル 構築 計測 学習 計画 検査 適応 ビジネス仮説一覧 Product Backlog ドメイン 社会課題 ビジネスモデル仮説 ミッション ビジョン Customer/ Problem fit Problem/ Solution fit Solution/ Product fit Product/ Market fit ①アイデアの検証 ②プロダクトの検証 継続、撤退、 ピボット判断 継続、撤退、 ピボット判断
21. https://shiftup.work/innovation-vortex/
22. Scrumでは Scrum Teamを定義
23. 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
24. © KONICA MINOLTA 老舗メーカーでは 何が課題か？ 24
25. © KONICA MINOLTA 組織構造と文化 25
26. © KONICA MINOLTA ビジネスのフィードバックサイクル ビジネスを 考える人 SWを 作る人
27. SW要求 企画/ ビジネス要求 役割によってゴールが違う 27 SW要件 動くソフトウェア ビジネスを考える人 【ゴール】 売れる企画を考えること 【ゴール】 要求通りのSWをQCD を守って開発すること SWを作る人
28. SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 情報劣化/誤解に起因する ビジネスインパクト！！ 納期遅延、販売機会損失、市場クレーム ココ 誰が考えるの？ 28 ビジネスを考える人 言わなくても わかるだろ！！ 聞いてない！！ 書いてない！！ SWを作る人
29. © KONICA MINOLTA 誰の責任？ 開発が悪い！ 企画が悪い！ 29
30. © KONICA MINOLTA 誰の責任？ ではなく チームの責任 30
31. ゴールを 共通化 しよう！ 31
32. ゴールの 共通化 コニカミノルタに マッチした 要求開発の メソッドづくりと 浸透
33. これまでの開発 ビジネスを 考える人 SWを 考える人 ユーザが◦◦な時に××でき る機能があると 70%までシェアが伸ばせる 要求を受けてQCDを守って開発する 御用聞き どうやって作ろ うかなぁ～ あ～だこ～だ Product Owner （企画部門） Developer （開発部門） 33
34. チームで要求を開発する ビジネスを 考える人 SWを 考える人 • 前も同じような機能を 作ったけど本当にいる？ • 〇×より、△▪な機能が トレンドだよ ユーザが◦◦な時に××で きる機能があると 70%までシェアが伸ばせる 開発者も要求を提案、却下する 脱御用聞き ビジネス観点 技術観点 Product Owner （企画部門） Developer （開発部門） 34
35. ビジネスの仮説検証サイクルの中で ゴールを共有するために アジャイル型要求開発 ビジネスを 考える人 SWを 考える人 Product Owner （企画部門） Dev （開発部門） 企画/ ビジネス要求 アジャイル型 要求開発 設計 テスト 実装 35 チームで要求を開発する
36. で、具体的に どうやってるの？ 36
37. © KONICA MINOLTA ゴールを共有するとは どういうことか 37
38. 38 誰の どんな課題を どのように解決し どんな効果(価値)を 狙っているのか
39. 39 そのために 何を どこまで作るか
40. 40 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何を どこまで 作るか
41. ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いる手法 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の 特定 誰の どんな課題を どのように 解決するか 何を どこまで 作るか 手順 41
42. © KONICA MINOLTA 誰の どんな 困り事を どのように解 決するのか ペルソナ Customer Journey Map 42
43. 引用:https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909 User Story Mapping ユーザーの 活動(ワークフロー) Option Rich ここまで作る 43
44. © KONICA MINOLTA 非機能要求は？ 44
45. © KONICA MINOLTA 非機能要求が 決まらなければ 最適なアーキテクチャ は 決定できない 45
46. 46 ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いる手法 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何を どこまで 作るか 手順 運用体制/コスト面も含む サービスの保証範囲（サー ビスレベル）の検討と共有 サービスレベルを満たす 非機能要求と 実現範囲を特定
47. 最小限の価値と実現範囲の特定 非機能要求特定 評価方法と目標値 設定 ユーザータスクの 洗い出し 受け入れ基準 設定 見積もり 優先順位付 見積もり 優先順位付 User Story Mapping 非機能検討 要求項目(User Story) サービスの 保証範囲 どんな観点を どんな優先順位で どの程度保証するか 非機能要求の観点 ex. ・IPA非機能能要求グレイド ・JIS X 25010:2013 製品品質モデル Product Backlog リリースまでに絶対にやらないとい けない項目(e.g. セキュリティテス ト、負荷テスト)は最優先に配置 非機能要求対応項目 47
48. 何をもって できた とするか？
49. 受け入れテストでゴールを合意 受け入れテスト作成 自動テスト作成/ テスト実施 テスト結果確認 スプリント計画 スプリント スプリント レビュー テスト管理ツール PO QA Dev [ 受け入れテスト All Green ] リリース計画 リリース レビュー [All Green ] 49
50. リリース計画 スプリント計画 開発 スプリントレビュー ふりかえり リリースふりかえり Product Backlog Scrum • 品質レベル決定 • テスト計画/テスト要 求分析/テスト設計 • 受け入れ基準の決定 • 受け入れテスト作成 PBI毎の受け入れ基準の決定 テスト要求分析、設計、および、 テスト設計に従った要求項目ご との受け入れテスト作成 テスト実施状況の確認 テスト結果(プロダク ト品質)の確認 Product Owner （企画部門） Dev (開発部門) QA (品質保証部門) 品質観点での プロセス改善提言 (プロセス品質) 品質観点での プロセス改善提言 (プロセス品質) 注)PBI:Product Backlog Item 50
51. © KONICA MINOLTA 受け入れ基準（自然言語） (Acceptance Criteria) テストケース （自然言語） テストコード テスト結果 （自然言語） PO QA Dev リンク リンク リンク 51
52. 2018年 社内課題収集 世の中調査 自社の課題に 合ったメソッド 構築 研修作成 試行 人事施策 として 全社展開 各事業部門の トップへ 説明行脚 2016年 2017年 賛同者作り 話を大きく する コミュニティ発足 トップの巻き込み 仲間づくり 「アジャイル型要求開発」の構築から現在までの経緯 2019年 2020年 海外展開開始（研修開催） コミュニティメンバが研修に参画 コミュニティの自走 海外で研修、認定制度が自走 研修の運営が完全にコミュニ ティで自走(講師育成含む) さらなる 広がりと仲間づくり 文化として 定着
53. 2018年 社内課題収集 世の中調査 自社の課題に 合ったメソッド 構築 研修作成 試行 人事施策 として 全社展開 各事業部門の トップへ 説明行脚 2016年 2017年 賛同者作り 話を大きく する コミュニティ発足 トップの巻き込み 仲間づくり 「アジャイル型要求開発」の構築から現在までの経緯 2019年 2020年 海外展開開始（研修開催） コミュニティメンバが研修に参画 コミュニティの自走 海外で研修、認定制度が自走 研修の運営が完全にコミュニ ティで自走(講師育成含む) さらなる 広がりと仲間づくり 文化として 定着
54. 一緒に広めてくれる 仲間 が必要
55. © KONICA MINOLTA 共に広め、実践してくれる仲間づくり 55 コアメンバー アクティブメンバー 周辺メンバー コアメンバー（全体の10~15%） アクティブメンバー（全体の15~20％） 周辺メンバー（全体65~75%） コーディネーター コミュニティが領域に焦点を当て、さまざまな関係を維持し、 実践を開発することができるように手助けをする人 「実践コミュニティ」を発足 課題や事例、情報を共有、議論する場の構築 個人の成長、組織への貢献につながる場
56. 56 出典：書籍「コミュニティ・オブ・プラクティス」p33より 実践コミュニティとは あるテーマに関する関心や問題、 熱意などを共有し、 その分野の知識や技能を、 持続的な相互交流を通じて 深めていく人々の集団
57. 実践コミュニティでの活動が個人の成長をもたらす 実践コミュニティでの 活動 職場での 実践
58. 受講者 認定者全員参加 実践コミュニティ 研修 コアメンバー 研修講師・運営担当者 課題、事例共有 ナレッジ共有 講師育成 エコシステムを形成
59. チームが 状況に応じた 最良の一手を 都度選択できる 力をつける仕組み ソフトウェア開発の 健全化
60. 基準の無い プランニングポーカー プロダクトオーナーと その手下 リリース前に 品証さんが初めてテスト PBIがWBSの ワークパッケージ POが仕様を決める 開発者は作る 何でもアジャイル アジャイルなので ドキュメントは書かない アジャイルなので テストしない 色んな勘違い
61. 61 「アジャイル」を 魔法の言葉にしない 実践事例をもって有効性を示す 正しい理解を広げる(Why/How/What) 経営層から現場まで全てを巻き込む
62. 62 「アジャイル」を 魔法の言葉にしない 実践事例をもって有効性を示す 正しい理解を広げる(Why/How/What) 経営層から現場まで全てを巻き込む
63. 63 実践の開始
64. 64 「アジャイル」を 魔法の言葉にしない 実践事例をもって有効性を示す 正しい理解を広げる(Why/How/What) 経営層から現場まで全てを巻き込む
65. 社内横断的な 現場レベルの 仲間づくり 65
66. © KONICA MINOLTA 社内横断的な全社活動の立ち上げ • ナレッジや課題の蓄積、共有 • 現場レベルのコミュニティ(気軽に相談できる場) 事業領域 66 横断組織によるアジャイルのナレッジ流通
67. © KONICA MINOLTA 横断組織によるアジャイルのナレッジ流通 社内SNS 課題共有、議論の場の構築 社内版Qiita ナレッジ共有、課題共有の場 67
68. 68 「アジャイル」を 魔法の言葉にしない 実践事例をもって有効性を示す 経営層から現場まで全てを巻き込む 正しい理解を広げる(Why/How/What)
69. 69 組織構造と文化の変革には トップダウンと ボトムアップの 両方が必要
70. © KONICA MINOLTA 多数の役員、事業部長を招き アジャイルの理解を揃える会を毎年開催 70 横断組織によるアジャイルのナレッジ流通 FY2017 全社向け共有会 FY2018 全社向け共有会 社内事例の共有に加えて、日本のアジャ イルのパイオニアを外部講師に迎え、ビ ジネスとアジャイルの講演を開催。ア ジャイルの理解と効果を揃えた 社内事例の共有に加え、他事業会社 の実践者を外部講師に迎え実活用に 向けたアジャイル型開発定着の勘所 を共有した (参加者： 11拠点, 450名) (参加者： 12拠点, 620名) 全社向け共有会 サービスビジネス事例を含む社内事 例の共有に加え、外部講師からビジ ネス成果につながるアジャイル型開 発の効果を共有した (参加者： 13拠点, 620名) FY2019
71. © KONICA MINOLTA 71 引用：日経産業新聞 https://www.nikkei.com/article/DGXMZO4059836029012019X20000/ 横断組織によるアジャイルのナレッジ流通
73. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ Coaching PO Dev Scrum Master Coach Team （Agile CoE） 育成 経験者の参画 ➢ Agile Center of Excellence の狙い • ビジネスやチームの特性に適した体制や進め方を自分達で決め続け られるチームを醸成する仕組みの構築する ➢ FY20 活動方針 • 他チームをハンズオンで支援。経験者を増やすことで全社的に浸透 度を向上 • セルフアセスメントを展開することで、チームの自律的な改善を促 進する
74. © KONICA MINOLTA © 2018 Konica Minolta, Inc. 社内アジャイルコーチチームの立ち上げ Agile CoE 啓蒙・教育 コーチング エンジニアリング 支援 • 基礎教育の展開 • ナレッジの蓄積、展開 • 啓蒙、情報共有 • チームに伴走、コーチング • アセスメントの構築と展開 • 高速開発を支えるエンジ ニアリングプラクティス の展開(e.g. TDD, CI/CD, メトリクス) Agile Center of Excellence (Agile CoE) 現場のチームが自律的にアジャイル型開発を推進で きるように支援する、全社横断のコーチングチーム
75. © KONICA MINOLTA 75 社内アジャイルコーチチームの立ち上げ 活動事例 - セルフアセスメントの作成と展開 - 1.チームが定期的にセルフアセスメントを実施 2.チームが自分達の強みと弱みを把握する 3.アセスメント結果をもとにチーム内で 対話し、課題と改善案を明らかにする 4.チームで改善を実施する。必要あればAgile CoEがサポートを行う Good Bad Report 2 4 Conduct an assessment 1 improve 3 Analyze & select solution Agile CoE supports
76. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ 活動事例 - セルフアセスメントの作成と展開 - 全体俯瞰したレーダーチャート 役割ごとの乖離が大き い項目 世の中のセオリーに対し て下回っている（できて いない）項目 改善案 弱点の原因を関係者・チーム全員で対話し、 課題と改善計画を作成 チーム自身での改善が難しい場合はAgile CoEが支援
77. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ 活動事例 - セルフアセスメントの作成と展開 - Dimensions items Agility Evaluate organizational agility is based on "Enterprise Business Agility Model" from the agilityhealth and “Business Agility Competency” from the SAFe IT Service Management, and Leadership Viewpoints (concepts) 世の中のフレームワークや チェックリストを参考に作成 Evaluate of Team, roles, responsibilities and skills Evaluate Product Owner-ship Evaluate large scale Agile Team Evaluate portfolio management Agile Manifest Mind set and culture Evaluate of Team, roles, process and practices
78. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ Agile CoE 全員が Excellenceではない
79. © KONICA MINOLTA 社内アジャイルコーチチームの立ち上げ コーチング活動を通じて、コーチを育成 コーチ候補の名前 必 要 な コ ン ピ テ ン シ ー 現在のコン ピテンシー レベル 必要な人数 タスク（実務）の クライテリア スキル習得の方法 参照) コンピテンシーマトリクス Blog: 変化に強いチームの作り方 https://note.com/naka_3/n/na2f19d978979
80. 多くのチームから 支援要請あり Agile CoEで 手分けして対応 支援テーマリスト
81. まとめ
83. ビジネスの仮説検証サイクルの中で ゴールを共有するために チームで要求を開発する アジャイル型要求開発 ビジネスを 考える人 SWを 考える人 Product Owner （企画部門） Dev （開発部門） ユーザー視点で 品質を 考える人 QA （品質保証部門） 83
84. 自分のメソッドからみんなのメソッドに
85. 85 ソフトウェア開発の 健全化
86. 86 「自分はできる」から「みんなができる」に
87. • 参加人数：883名 (内、役員 15名) • 19年度 620名から大きく増加 • CTOはじめ各役員から共感、 および、継続的な活動への 期待の声が多数 アジャイルナレッジ共有会 FY20
88. 私がやったことは コンセプトを決めて 外部講師と繋いだだけ 全て Agile CoEの メンバーが担当
89. ありがとう ございました 89