2019年1月31日　要求開発アライアンスでの講演資料

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 AgileAgileLean 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
OpsBiz
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
OpsBiz
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 QADev リンク
リンク
リンク
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