老舗メーカーにアジャイル型要求開発を広めてみました

2019/01/31 要求開発アライアンスでの講演資料

Transcript

1. 老舗メーカーに アジャイル型 要求開発を 広めてみました コニカミノルタ株式会社 IoTサービスプラットフォーム開発統括部 中原 慶 2019/01/31 要求開発アライアンス 1
2. © KONICA MINOLTA 中原 慶 (42歳、大阪市出身) 2 IT系アプリ開発 クラウドサービス開発 全社SW開発力強化 教育・コンサルティング、 ツール開発 2000年 2004年 2012年 • WEBアプリ開発 • DB管理アプリ開発 • Java、モデリング、SPL、仕様記述 • TRICHORD, astah*の開発 • 講演、執筆 • クラウドサービス開発 • アジャイル型開発の展開 • ICT技術者育成 ソフトハウス
3. © KONICA MINOLTA 3
4. © KONICA MINOLTA 4
5. © KONICA MINOLTA 5
6. © KONICA MINOLTA 全てのモノには寿命がある デジタルカメラ カメラ フィルム 創業事業 からの 撤退 2006年 次世代に向けた準備 創業 1873年 6
7. © KONICA MINOLTA ビジネスを支えるコア技術 コア技術 7
8. ヘルスケア 産業用光学システム オフィスサービス 商業・産業印刷 機能材料 8
9. © KONICA MINOLTA 特にこれからは・・・ 業界、分野を超えた 大規模な変革期に 入ろうとしている。 9
10. © KONICA MINOLTA 本 編 10
11. © KONICA MINOLTA 今日のお話しが弊社の 「アジャイル」の 全て ではありません 11
12. © KONICA MINOLTA 対象 事業会社の方 # できれば老舗の # できれば製造業 12
13. © KONICA MINOLTA 老舗メーカー 要求開発 13
14. © KONICA MINOLTA 今日のお話しの背景 データを収集/分析/活用した 価値あるサービスを迅速に提供 AI / Robotics Agile Agile Lean Startup Design Thinking 14
15. 何が売れるか不明 儲かるか不明 2つの不確実性 顧客提供価値仮説 (P/S Fit) 成長(戦略)の仮説 (P/M Fit) 迅速に仮説を検証しながら サービスを育てていく進め方がマッチ 今日のターゲット 新規サービス 15
16. © KONICA MINOLTA 老舗メーカーでは 何が課題か？ 16
17. © KONICA MINOLTA 組織構造と文化 17
18. © KONICA MINOLTA 本日は 老舗メーカーの組織構造と 文化を変革するために 「アジャイル型要求開発」を 普及しようとしている事例を ご紹介いたします。 参考になれば幸いです 18
19. © KONICA MINOLTA 本日お伝えしたいこと 1. 組織構造と文化の変革 2. アジャイル型要求開発の進め方 3. 全社展開 19
20. © KONICA MINOLTA 本日お伝えしたいこと 1. 組織構造と文化の変革 2. アジャイル型要求開発の進め方 3. 全社展開 20
21. © KONICA MINOLTA なぜ組織構造と文化が課題か Market ビジネスを 考える人 SWを 作る人 運用を する人 21
22. © KONICA MINOLTA 【ゴール】 売れる企画を考えること SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 役割によってゴールが違う ビジネスを考える人 SWを作る人 【ゴール】 要求通りのSWをQCDを 守って開発すること 1. 組織構造と文化の変革 22
23. © KONICA MINOLTA SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 情報劣化/誤解が起こる 言わなくても わかるだろ！！ ビジネスを考える人 SWを作る人 聞いてない！！ 書いてない！！ ココ 誰が考えるの？ 1. 組織構造と文化の変革 23
24. © KONICA MINOLTA 誰の責任？ 開発が悪い！ 企画が悪い！ 24
25. © KONICA MINOLTA 言わなくても わかるだろ！！ SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 組織構造と文化を変える ビジネスを考える人 SWを作る人 聞いてない！！ 書いてない！！ ココ 誰が考えるの？ 細かいことは開発で よきに計らってね 売れるかどうか は企画次第 言われたものを QCDを守って開 発するのが仕事 儲かる企画を 考えることが仕事 1. 組織構造と文化の変革 25
26. © KONICA MINOLTA ゴールを共にし 全員で立ち向かえる チームが必要 1. 組織構造と文化の変革 26
27. © KONICA MINOLTA 組織の壁を取っ払う 27
28. © KONICA MINOLTA まずはチームから 28
29. © KONICA MINOLTA Ops Biz Customer DevOps cycle Dev Scrum Team Product Owner （企画部門） Dev/Scrum Master （開発部門） 部門を超えたチームを構築 1. 組織構造と文化の変革 29
30. © KONICA MINOLTA 文化(心の壁)を 取っ払う 30
31. これまでの開発 ビジネスを 考える人 SWを 考える人 ユーザが◦◦な時に××でき る機能があると 70%までシェアが伸ばせる 要求を受けてQCDを守って開発する 御用聞き どうやって作ろ うかなぁ～ あ～だこ～だ Product Owner （企画部門） Developer （開発部門） 31
32. チームで要求を開発する ビジネスを 考える人 SWを 考える人 • 前も同じような機能を 作ったけど本当にいる？ • 〇×より、△▪な機能が トレンドだよ ユーザが◦◦な時に××で きる機能があると 70%までシェアが伸ばせる 開発者も要求を提案、却下する 脱御用聞き ビジネス観点 技術観点 Product Owner （企画部門） Developer （開発部門） 32
33. ビジネスの仮説検証サイクルの中で ゴールを共有するために アジャイル型要求開発 ビジネスを 考える人 SWを 考える人 Product Owner （企画部門） Dev （開発部門） 企画/ ビジネス要求 アジャイル型 要求開発 設計 テスト 実装 33 チームで要求を開発する
34. POは要求を作る Devはソフトを作る みんなで要求を作る POは最終決定者
35. チームでビジネスの 仮説検証の状況を 共有 ビジネス状況の共有 仮説検証 KANBAN 仮説の目標値、検証方法、時期の共有 リリースの狙いボード 35
36. チームで 「ヤッター！」を 共有する ビジネス状況の共有 仮説検証 KANBAN 仮説の目標値、検証方法、時期の共有 リリースの狙いボード 36
37. © KONICA MINOLTA アジャイル型要求開発で 組織構造（チーム構成)と 文化を変革する 1. 組織構造と文化の変革 まとめ ＆ 37
38. で、具体的に どうやってるの？ 38
39. © KONICA MINOLTA 本日お伝えしたいこと 1. 組織構造と文化の変革 2. アジャイル型要求開発の進め方 3. 全社展開 39
40. © KONICA MINOLTA チームで要求を開発する とは、どういうことか 40
41. © KONICA MINOLTA 誰の どんな課題を どのように解決し どんな効果(価値)を 狙っているのか 2. アジャイル型要求開発の進め方 41
42. © KONICA MINOLTA そのために 何を どこまで作るか 2. アジャイル型要求開発の進め方 42
43. リリース計画 スプリント計画 開発 スプリントレビュー ふりかえり リリースふりかえり Product Backlog Scrum Product Owner （企画部門） Dev (開発部門) ビジネスビジョン/ マイルストン 製品 アジャイル型 要求開発 43
44. © KONICA MINOLTA 2. アジャイル型要求開発の進め方 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何をどこまで 作るか 44
45. © KONICA MINOLTA ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いる手法 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何をどこまで 作るか 手順 2. アジャイル型要求開発の進め方 45
46. © KONICA MINOLTA ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いる手法 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何をどこまで 作るか 手順 2. アジャイル型要求開発の進め方 46
47. © KONICA MINOLTA 誰の どんな 困り事を どのように解 決するのか ペルソナ Customer Journey Map 47
48. © KONICA MINOLTA ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いる手法 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何をどこまで 作るか 手順 2. アジャイル型要求開発の進め方 48
49. © KONICA MINOLTA 引用:https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909 User Story Mapping ユーザーの 活動(ワークフロー) Option Rich ここまで作る 49
50. © KONICA MINOLTA 最も重要な価値仮説を検証できる 最小限のものを作る(作らないかも) 少しずつ検証して育てる ∵価値仮説だから 50
51. © KONICA MINOLTA 優先順位の高い 顧客提供価値仮説を検証する 初期の要求が定義できた 51
52. © KONICA MINOLTA ちょっと待った！ 52
53. © KONICA MINOLTA 引用:https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909 User Story Mapping 53 サービスとアクターの インタラクション しか表現できていない
54. © KONICA MINOLTA 非機能要求は？ 54
55. © KONICA MINOLTA 非機能要求が 決まらなければ 最適なアーキテクチャ は 決定できない 55
56. © KONICA MINOLTA 2. アジャイル型要求開発の進め方 ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いる手法 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 解決策と提供価値の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何をどこまで 作るか 手順 運用体制/コスト面も含む サービスの保証範囲（サー ビスレベル）の検討と共有 サービスレベルを満たす 非機能要求と 実現範囲を特定 56
57. © KONICA MINOLTA 最小限の価値と実現範囲の特定 非機能要求特定 評価方法と目標値 設定 ユーザータスクの 洗い出し 受け入れ基準 設定 見積もり 優先順位付 見積もり 優先順位付 User Story Mapping 非機能検討 要求項目(User Story) 非機能要求評価項目 サービスの 保証範囲 どんな観点を どんな優先順位で どの程度保証するか 非機能要求の観点 ex. ・IPA非機能能要求グレイド ・JIS X 25010:2013 製品品質モデル Product Backlog リリースまでに絶対にやらない といけない項目(ex. セキュリ ティテスト、負荷テスト)は最優 先に配置 非機能要求対応項目 2. アジャイル型要求開発の進め方 非機能要求も含む実現範囲の特定 57
58. © KONICA MINOLTA 最小限の価値を提供する 要求を非機能要求も含めて チームで開発する 2. アジャイル型要求開発の進め方 まとめ 58
59. © KONICA MINOLTA これで優先順位の高い 顧客提供価値仮説を 検証する初期の要求が 非機能要求も含めて 定義できた 59
60. © KONICA MINOLTA ちょっと待った！ 60
61. © KONICA MINOLTA 価値提供に値する 品質か？ 61
62. © KONICA MINOLTA 価値は リソース(ex.時間,お金)と 交換可能 62
63. © KONICA MINOLTA 品質とは何か？ 63
64. © KONICA MINOLTA 引用：JSTQB ソフトウェアテスト標準用語集 価値に値する能力を 満たしているか？ 64
65. © KONICA MINOLTA 同様な他製品の 品質に精通している人 にも協力してもらおう 65
66. © KONICA MINOLTA QA(品質保証部門) 66
67. © KONICA MINOLTA Ops Biz Customer DevOps cycle Scrum Team Product Owner （企画部門） Dev/Scrum Master （開発部門） 部門を超えたチームを構築 QA (品証部門) Dev 2. アジャイル型要求開発の進め方 品質担保 67
68. 価値に値する品質か？ 価値が仮説なので品質の妥当性も仮説 ビジネス観点、技術観点、そして 社内外の同種他製品の品質の観点で 価値に値する品質レベルをチームで決める 品質の満足度合はテストで計測 要求を開発する際に、テスト計画、テスト 分析・設計、受け入れテストを作成する 受け入れテストを考えることで外部から観 察可能な振る舞い（仕様）を検討できる 68
69. © KONICA MINOLTA 3つの観点で要求と品質を開発する ビジネスを 考える人 SWを 考える人 • 前も同じような 機能を作ったけ ど本当にいる？ • 〇×より、△▪ な機能がトレン ドだよ ユーザが◦◦な 時に××できる機 能があると 70%までシェア が伸ばせる 他の製品では こんな問題が起こったよ あ～だこ～だ ユーザー視点で 品質を 考える人 要求項目と 保証範囲 2. アジャイル型要求開発の進め方 品質担保 69
70. リリース計画 スプリント計画 開発 スプリントレビュー ふりかえり リリースふりかえり Product Backlog Scrum • 品質レベル決定 • テスト計画/テスト要 求分析/テスト設計 • 受け入れ基準の決定 • 受け入れテスト作成 PBI毎の受け入れ基準の決定 テスト要求分析、設計、およ び、テスト設計に従った要求項 目ごとの受け入れテスト作成 テスト実施状況の確認 テスト結果(プロダク ト品質)の確認 Product Owner （企画部門） Dev/Scrum Master (開発部門) QA (品質保証部門) 品質観点での プロセス改善提言 (プロセス品質) 品質観点での プロセス改善提言 (プロセス品質) 注)PBI:Product Backlog Item 70
71. © KONICA MINOLTA 受け入れテストでゴールを合意 受け入れテスト作成 自動テスト作成/ テスト実施 テスト結果確認 スプリント計画 スプリント スプリント レビュー テスト管理ツール PO QA Dev [ 受け入れテスト All Green ] リリース計画 リリース レビュー [All Green ] 2. アジャイル型要求開発の進め方 品質担保 71
72. © KONICA MINOLTA 受け入れ基準（自然言語） (Acceptance Criteria) テストケース （自然言語） テストコード テスト結果 （自然言語） PO QA Dev リンク リンク リンク 72
73. © KONICA MINOLTA 品質レベルも仮説 品証部門だけに 押し付けない 73
74. © KONICA MINOLTA ビジネス、技術、 ユーザ視点の 3つの観点で チームで品質を担保する 74
75. © KONICA MINOLTA • チームで品質レベルを決定する • チームで品質を担保する • 受け入れテストでゴールを共有する 2. アジャイル型要求開発の進め方 品質担保 75
76. © KONICA MINOLTA 誰の責任？ ではなく チームの責任 76
77. © KONICA MINOLTA 本日お伝えしたいこと 1. 組織構造と文化の変革 2. アジャイル型要求開発の進め方 3. 全社展開 77
78. © KONICA MINOLTA 3. 全社展開 組織構造や文化を変えるには トップマネジメントへの訴求 が必須 78 最後に私が社内に展開した例をご紹介します • アジャイル型要求開発の展開 • アジャイルの展開
79. © KONICA MINOLTA 79 3. 全社展開 ~アジャイル型要求開発の展開~ 2018年 社内課題収集 世の中調査 自社の課題に 合ったメソッド 構築 研修作成 試行 人事施策 として 全社展開 各事業部門の トップへ 説明行脚 2016年 2017年 賛同者作り 話を大きく する コミュニティ発足 トップの巻き込み 仲間づくり 「アジャイル型要求開発」の構築から社内展開までの経緯 展開のカギ 仲間を作る事と、影響力と決定権を 持つ人(トップマネジメント)を巻き 込み話を大きくする事
80. © KONICA MINOLTA 80 3. 全社展開 ~アジャイル型要求開発の展開~ 2018年 社内課題収集 世の中調査 自社の課題に 合ったメソッド 構築 研修作成 試行 人事施策 として 全社展開 各事業部門の トップへ 説明行脚 2016年 2017年 賛同者作り 話を大きく する コミュニティ発足 トップの巻き込み 仲間づくり 「アジャイル型要求開発」の構築から社内展開までの経緯
81. © KONICA MINOLTA 81 3. 全社展開 ~アジャイル型要求開発の展開~ SW開発 企画 ア イ デ ア ( 要 望 ) SW 要 求 SW 要 件 要望検討/ 商品検討 市場 動向 利用 状況 市場展開 受け入 れ(評価) 開発 • 社内のソリューション領域で起こった問題事例を収集 • 問題事例の対策となる世の中の方法論、手法を調査 • メソッドを構築し、研修として展開 問題
82. © KONICA MINOLTA 82 掲載していませんが、 対応にかかった 金額も明らかにし、 リアルな問題事例を 多数収集し、 問題の深刻さと影響を 説明しました 3. 全社展開 ~アジャイル型要求開発の展開~
83. © KONICA MINOLTA 83 3. 全社展開 ~アジャイル型要求開発の展開~ 2018年 社内課題収集 世の中調査 自社の課題に 合ったメソッド 構築 研修作成 試行 人事施策 として 全社展開 各事業部門の トップへ 説明行脚 2016年 2017年 賛同者作り 話を大きく する コミュニティ発足 トップの巻き込み 仲間づくり 「アジャイル型要求開発」の構築から社内展開までの経緯
84. © KONICA MINOLTA 84 3. 全社展開 ~アジャイル型要求開発の展開~ 既存企業はデータ分析技術を活用した ソフトウェアシステムを競争力の中心に切替 ▪ 世の中の動向 橋渡し 仮説検証サイクルを効果的にまわすために、ビジネスと技術の両方に精通 し、 開発チームの作業とプロダクトの価値を最大化する人財が必要性 • 人事部門に重要人財として提案 • 社内の定例開催研修として人事予算で実施 • 客観的なスキルの把握状況を可視化すべく、社内認定制度化 • 各事業部門のトップに説明 • 部門内で広く告知、教育体系への織り込み
85. © KONICA MINOLTA 3. 全社展開 ~アジャイルの展開~ 「アジャイル」を 魔法の言葉にしない 実践事例をもって有効性を示す 外部有識者から、世の中、他社の状況、 あるべき姿を説明頂く 85 正しい理解を広げる(Why/How/What)
86. © KONICA MINOLTA 3. 全社展開 多数の役員、事業部長を招き アジャイルの理解を揃える会を毎年開催 FY2016 自部門向け講習会 FY2017 全社向け共有会 FY2018 全社向け共有会 新規事業開発部門を対象 に、外部有識者によるア ジャイルの基礎知識につ いての講習会 社内事例の共有と外部有識 者によるビジネスとアジャ イルにいての講演 社内事例のナレッジ共有と 他事業会社の実践者による 実践における勘所の講演 (参加者： 6拠点, 200名) (参加者： 11拠点, 450名) (参加者： 12拠点, 620名) 86
87. © KONICA MINOLTA 3. 全社展開 ~アジャイルの展開~ 社内横断的な全社活動の立ち上げ • ナレッジや課題の蓄積、共有 • 現場レベルのコミュニティ(気軽に相談できる場) 事業領域 3部署 10部署 22部署 2016 2017 2018 活動への参加人数と参加部署 開発以外も参加 海外も参加 事業部門 が参加 87
88. © KONICA MINOLTA 3. 全社展開 全社横断のアジャイルナレッジ展開活動 社内SNS 課題共有、議論の場の構築 社内版Qiita ナレッジ共有、課題共有の場 88
89. © KONICA MINOLTA まとめ 89
90. ビジネスの仮説検証サイクルの中で ゴールを共有するために チームで要求を開発する アジャイル型要求開発 ビジネスを 考える人 SWを 考える人 Product Owner （企画部門） Dev （開発部門） ユーザー視点で 品質を 考える人 QA （品質保証部門） 90
91. 91 組織構造や文化を変えるには トップマネジメントへの訴求 が必須
92. ありがとう ございました 92