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

2018/06/15にJaSST関西で講演した際の講演資料です
2024/06/20にSlideshareから移行しました

Transcript

1. 老舗メーカーに アジャイル型要求開発を 導入してみました コニカミノルタ株式会社 IoTサービスプラットフォーム開発統括部 中原 慶 2018/06/15
2. 中原 慶 (41歳、大阪市出身) 2 IT系アプリ開発 クラウドサービス開発 全社SW開発力強化 教育・コンサルティング、 ツール開発 2000年 2004年 2012年 • WEBアプリ開発 • DB管理アプリ開発 • Java、モデリング、SPL、仕様記述 • TRICHORD, astah*の開発 • 講演、執筆 • クラウドサービス開発 • アジャイル型開発の展開 • ICT技術者育成 ソフトハウス
3. Kent Beck
4. 全てのモノには寿命がある デジタルカメラ カメラ フィルム 創業事業 からの 撤退 2006年 次世代に向けた準備 創業 1873年
5. ビジネスを支えるコア技術 コア技術
6. 事業領域 ヘルスケア 産業用光学システム オフィスサービス 商業・産業印刷 機能材料
7. 特にこれからは・・・ 業界、分野を超えた 大規模な変革期に 入ろうとしている。
8. 本 編
9. 今日のお話しが弊社の 「アジャイル」の 全て ではありません
10. 対象 事業会社の方 # できれば老舗の # できれば製造業
11. 老舗メーカー アジャイル型 要求開発
12. 今日のお話しの背景 ITを駆使し、データを活用した 価値あるサービスを迅速に提供 AI / Robotics Agile Agile Lean Startup Design Thinking
13. 儲かる 新規サービスを 開発しなさい
14. 新規サービス開発 何が売れるか不明 儲かるか不明 2つの不確実性 顧客提供価値仮説 (P/S Fit) 成長(戦略)の仮説 (P/M Fit) 迅速に仮説を検証しながら サービスを育てていく進め方がマッチ 今日のターゲット
15. リンスタ/アジャイル やん
16. 老舗メーカーでは 何が課題か？
17. 組織構造と文化
18. 変えたらええやん
19. 本日は組織構造と文化を 変革するために 私が行ったことの１つ、 「アジャイル型要求開発」の 導入事例を ご紹介いたします 参考になれば幸いです
20. 本日お伝えしたいこと 1.チーム構成と マインドセット(文化) 2.開発の進め方 3.品質保証方法 迅速な仮説検証を行うために 私が行った
21. 本日お伝えしたいこと 1.チーム構成と マインドセット(文化) 2.開発の進め方 3.品質保証方法 迅速な仮説検証を行うために 私が行った
22. なぜ組織構造と文化が課題か Market ビジネスを 考える人 SWを 作る人 運用を する人
23. 【ゴール】 売れる企画を考えること SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 役割によってゴールが違う ビジネスを考える人 SWを作る人 【ゴール】 要求通りのSWをQCDを守って 開発すること
24. SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 情報劣化/誤解が起こる 言わなくても わかるだろ！！ ビジネスを考える人 SWを作る人 聞いてない！！ 書いてない！！ ココ 誰が考えるの？
25. 誰の責任？ 開発が悪い！ 企画が悪い！
26. 言わなくても わかるだろ！！ SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 組織構造と文化を変える ビジネスを考える人 SWを作る人 聞いてない！！ 書いてない！！ ココ 誰が考えるの？ 儲かる企画を 考えることが仕事 細かいことは開発 でよきに計らってね 売れるかどうか は企画次第 言われたものを QCDを守って開 発するのが仕事
27. ゴールを共にし 全員で立ち向かえる チームが必要
28. 組織の壁を取っ払う
29. Ops Biz Customer DevOps cycle Dev Scrum Team Product Owner （企画部門） Dev/Scrum Master （開発部門） 部門を超えたチームを構築
30. 部門を超えたチームを作る事例は 下記をご参照下さい https://www.slideshare.net/keinakahara3/ss-81883094
31. スプリント Product Backlog デイリースクラム プロダクトインクリメント スプリントプランニング スプリントレビュー 2～4週間 毎日 スプリントバックログ スプリント レトロスペクティブ Product Backlogの リファインメント インペディメント リスト 開発チーム Product Owner (PO) スクラムマスター 凡例 作成物 役割 イベント スクラムの成立に責任を持つ プロセスの番人/サーバントリーダー 開発チームの作業と製品の価値に 対するROIを最大化する Scrum
32. Ops Biz Customer DevOps cycle Dev Scrum Team Product Owner （企画部門） Dev/Scrum Master （開発部門） 部門を超えたチームを構築
33. 文化(心の壁)を 取っ払う
34. これまでの開発 ビジネスを 考える人 SWを 考える人 他社の〇×サービスは あ～だこ～だ 要求を受けてQCDを守って開発する 御用聞き OK！ どうやって作ろう かなぁ～ あ～だこ～だ Product Owner （企画部門） Developer （開発部門）
35. チームで要求を開発する ビジネスを 考える人 SWを 考える人 • 前も同じような機能を作っ たけど誰も使ってないよ • 〇×より、△▪な解決がで きるよ 他社の〇×サービスは あ～だこ～だ 開発者も要求を提案、却下する 脱御用聞き ビジネス観点 技術観点 Product Owner （企画部門） Developer （開発部門）
36. ビジネスの仮説検証サイクルの中で ゴールを共有するために チームで要求を開発する アジャイル型要求開発 ビジネスを 考える人 SWを 考える人 Product Owner （企画部門） Dev （開発部門） 企画/ ビジネス要求 要件定義 設計 テスト 実装
37. チームでビジネスの 仮説検証の状況を 共有 ビジネス状況の共有 仮説検証 KANBAN 仮説の目標値、検証方法、時期の共有 リリースの狙いボード
38. チームで 「ヤッター！」を 共有する ビジネス状況の共有 仮説検証 KANBAN 仮説の目標値、検証方法、時期の共有 リリースの狙いボード
39. アジャイル型要求開発で チーム構成とマインドセットを 変革する ＆ 1. チーム構成とマインドセット(文化) まとめ
40. で、具体的に どうやってるの？
41. 本日お伝えしたいこと 1.チーム構成と マインドセット(文化) 2.開発の進め方 3.品質保証方法 迅速な仮説検証を行うために 私が行った
42. チームで要求を開発する とは、どういうことか
43. 誰の どんな課題を どのように解決し どんな効果を 狙っているのか 1. これをチームで共有
44. そのために 何を どこまで作るか 2. これをチームで考える
45. リリース計画 スプリント計画 開発 スプリントレビュー ふりかえり リリースふりかえり Product Backlog Scrum 開発の進め方 Product Owner （企画部門） Dev (開発部門) アジャイル型 要求開発 ビジネスビジョン/マイルストン そのために 何を どこまで作るか 製品
46. アジャイル型要求開発の手順 利害関係者の特定 ターゲットユーザーの共有 顧客課題の共有 提供価値（ソリューション）の共有 最小限の価値と実現範囲の特定 誰の どんな課題を どのように 解決するか 何をどこまで 作るか
47. 「アジャイル型要求開発」の進め方と手法 ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いられる手法 誰の どんな課題を どのように 解決するか 何をどこまで 作るか
48. 「アジャイル型要求開発」の進め方と手法 ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いられる手法 誰の どんな課題を どのように 解決するか 何をどこまで 作るか？
49. 誰の どんな 困り事を どのように解決 するのか ペルソナ Customer Journey Map
50. 「アジャイル型要求開発」の進め方と手法 ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いられる手法 誰の どんな課題を どのように 解決するか 何をどこまで 作るのか？
51. 引用:https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909 User Story Mapping ユーザーの 活動(ワークフロー) Option Rich ここまで作る
52. 最も重要な価値仮説を検証できる 最小限のものを作る(作らないかも) 少しずつ検証して育てる ∵価値仮説だから
53. 優先順位の高い 顧客提供価値仮説を検証する 初期の要求が定義できた
54. ちょっと待った！
55. ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いられる手法 「アジャイル型要求開発」の進め方と手法 これだけでは不十分！ 何をどこまで 作るか？
56. 引用:https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909 サービスとアクターの インタラクション しか表現できていない
57. 非機能要求は？
58. 非機能要求が 決まらなければ 最適なアーキテクチャは 決定できない
59. 誰の どんな課題を どのように 解決するか ステイクホルダーリスト プラグマティックペルソナ As-Is Customer Journey Map To-Be Customer Journey Map User Story Mapping よく用いられる手法 「アジャイル型要求開発」の進め方と手法 運用体制/コスト面も含む サービスの保証範囲（サービ スレベル）の検討と共有 サービスレベルを満たす 非機能要求と 実現範囲を特定 何をどこまで 作るか？
60. 最小限の価値と実現範囲の特定 非機能要求特定 評価方法と目標値 設定 ユーザータスクの 洗い出し 受け入れ基準 設定 見積もり 優先順位付 見積もり 優先順位付 User Story Mapping 非機能検討 要求項目(User Story) 非機能要求評価項目 サービスの 保証範囲の ビジネス要求 どんな観点を どんな優先順位で どの程度保証するか 非機能要求の観点 参照： ・IPA非機能能要求グレイド ・JIS X 25010:2013 製品品質モデル Product Backlog リリースまでに絶対にやらないとい けない項目(ex. セキュリティテスト、 負荷テスト)は最優先に配置 非機能要求対応項目 非機能要求も含む実現範囲の特定
61. 2.開発の進め方まとめ 最小限の価値を提供する 要求を非機能要求も含めて チームで開発する
62. これで優先順位の高い 顧客提供価値仮説を 検証する初期の要求が 非機能要求も含めて 定義できた
63. ちょっと待った！
64. 価値提供に値する 品質か？
65. 本日お伝えしたいこと 1.チーム構成と マインドセット(文化) 2.開発の進め方 3.品質保証方法 迅速な仮説検証を行うために 私が行った
66. 価値は リソース(ex.時間,お金) と交換可能
67. 品質とは何か？
68. 引用：JSTQB ソフトウェアテスト標準用語集 価値に値する能力を 満たしているか？
69. 同様な他製品の 品質に精通している人 にも協力してもらおう
70. お待たせいたしました 出番です
71. QA(品質保証部門)
72. Ops Biz Customer DevOps cycle Scrum Team Product Owner （企画部門） Dev/Scrum Master （開発部門） 部門を超えたチームを構築 QA (品証部門) Dev
73. 価値に値する品質か？ 価値が仮説なので品質の妥当性も仮説 ビジネス観点、技術観点、そして 社内外の同種他製品の品質の観点で 価値に値する品質レベルをチームで決める 品質の満足度合はテストで計測 要求を開発する際に、テスト計画、テスト 分析・設計、受け入れテストを作成する 受け入れテストを考えることで外部から観 察可能な振る舞い（仕様）を検討できる
74. 3つの観点で要求と品質を開発する ビジネスを 考える人 SWを 考える人 • 前も同じような機能を 作ったけど誰も使って ないよ • 〇×より、△▪な解決 ができるよ 他社の 〇×サービスは あ～だこ～だ 他の製品では こんな問題が起こったよ あ～だこ～だ ユーザー視点で 品質を 考える人 要求項目と 保証範囲
75. リリース計画 スプリント計画 開発 スプリントレビュー ふりかえり リリースふりかえり Product Backlog Scrum • 品質レベル決定 • テスト計画/テスト要求 分析/テスト設計 • 受け入れ基準の決定 • 受け入れテスト作成 PBI毎の受け入れ基準の決定 テスト要求分析、設計、および、 テスト設計に従った要求項目 ごとの受け入れテスト作成 テスト実施状況の確認 テスト結果(プロダクト品 質)の確認 開発の進め方 Product Owner （企画部門） Dev/Scrum Master (開発部門) QA (品質保証部門) 品質観点での プロセス改善提言 (プロセス品質) 品質観点での プロセス改善提言 (プロセス品質) 注)PBI:Product Backlog Item
76. 受け入れテストでゴールを合意 受け入れテスト作成 自動テスト作成/ テスト実施 テスト結果確認 スプリント計画 スプリント スプリント レビュー テスト管理ツール PO QA Dev [ 受け入れテスト All Green ] リリース計画 リリース レビュー [All Green ]
77. 受け入れ基準（自然言語） (Acceptance Criteria) テストケース （自然言語） テストコード テスト結果 （自然言語） PO QA Dev リンク リンク リンク
78. 品質レベルも仮説 品証部門だけに 押し付けない
79. ビジネス、技術、 ユーザ視点の 3つの観点で チームで品質を担保する
80. 3.品質保証方法 チームで品質レベルを決定する チームで品質を担保する 受け入れテストでゴールを共有する
81. まとめ
82. 誰の責任？ ではなく チームの責任
83. ビジネスの仮説検証サイクルの中で ゴールを共有するために チームで要求を開発する アジャイル型要求開発 ビジネスを 考える人 SWを 考える人 Product Owner （企画部門） Dev （開発部門） ユーザー視点で 品質を 考える人 QA （品質保証部門）
84. 2018/06/15 ありがとう ございました
85. テストの状況 プロジェクト憲章 （インセプションデッキ） 全てのプロセス 時間単位のタスク計画 （時間割） 設計を可視化 設計のルール 共通認識を形成するため徹底的可視化
86. 顧客の To Be ワークフロー 利害関係者一覧 定型タスク メンバのモチベーション チームの掟（ルール） 見積もり基準 共通認識を形成するために暗黙知を形式知へ
87. 引用：IPA 非機能要求グレイド https://www.ipa.go.jp/sec/reports/20180425.html IPA非機能要求グレイド システム及び ソフトウェア品質モデル 引用：http://www.discovertodeliver.com/ 引用： JIS X 25010:2013システム及びソフトウェア製品の品質要求及び評価 （SQuaRE）−システム及びソフトウェア品質モデル Discover to Deliver
88. 何をもって完成か？ • Done(完成)の定義(DoD: Definition Of Done) • 各スプリントで開発するインクリメント(製品)の完成の 定義をチームで決定し、共通理解にする • 完成したインクリメントは実際に利用可能で、Product Ownerはいつでもリリースができる • Undone work • インクリメントをリリース可能とするために各スプリントで絶対に やらなければならないが、毎スプリントはできていないこと。 リリースに対するリスク。 • ex. ベンダーを使ったセキュリティの脆弱性テスト 参照:Scrum Guide 2017 https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf#zoom=100 https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf