![© KONICA MINOLTA
受け入れテストでゴールを合意
受け入れテスト作成
自動テスト作成/
テスト実施
テスト結果確認
スプリント計画
スプリント
スプリント
レビュー
テスト管理ツール
PO QA Dev
[ 受け入れテスト
All Green ]
リリース計画
リリース
レビュー
[All Green ]
2. アジャイル型要求開発の進め方
品質担保
71](https://image.slidesharecdn.com/20190131requirementaliance-190206083233/85/20190131-requirement-aliance-71-320.jpg)
More Related Content
What's hot (20)
Similar to 20190131 requirement aliance (20)
More from Kei Nakahara (9)
20190131 requirement aliance
- 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
- 10. © KONICA MINOLTA 本 編 10
- 12. © KONICA MINOLTA 対象 事業会社の方 # できれば老舗の # できれば製造業 12
- 14. © KONICA MINOLTA 今日のお話しの背景 データを収集/分析/活用した 価値あるサービスを迅速に提供 AI / Robotics AgileAgileLean Startup Design Thinking 14
- 15. 何が売れるか不明 儲かるか不明 2つの不確実性 顧客提供価値仮説 (P/S Fit) 成長(戦略)の仮説 (P/M Fit) 迅速に仮説を検証しながら サービスを育てていく進め方がマッチ 今日のターゲット 新規サービス 15
- 18. © KONICA MINOLTA 本日は 老舗メーカーの組織構造と 文化を変革するために 「アジャイル型要求開発」を 普及しようとしている事例を ご紹介いたします。 参考になれば幸いです 18
- 19. © KONICA MINOLTA 本日お伝えしたいこと 1. 組織構造と文化の変革 2. アジャイル型要求開発の進め方 3. 全社展開 19
- 20. © KONICA MINOLTA 本日お伝えしたいこと 1. 組織構造と文化の変革 2. アジャイル型要求開発の進め方 3. 全社展開 20
- 22. © KONICA MINOLTA 【ゴール】 売れる企画を考えること SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 役割によってゴールが違う ビジネスを考える人 SWを作る人 【ゴール】 要求通りのSWをQCDを 守って開発すること 1. 組織構造と文化の変革 22
- 23. © KONICA MINOLTA SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 情報劣化/誤解が起こる 言わなくても わかるだろ！！ ビジネスを考える人 SWを作る人 聞いてない！！ 書いてない！！ ココ 誰が考えるの？ 1. 組織構造と文化の変革 23
- 25. © KONICA MINOLTA 言わなくても わかるだろ！！ SW要求 SW要件 企画/ ビジネス要求 動くソフトウェア 組織構造と文化を変える ビジネスを考える人 SWを作る人 聞いてない！！ 書いてない！！ ココ 誰が考えるの？ 細かいことは開発で よきに計らってね 売れるかどうか は企画次第 言われたものを QCDを守って開 発するのが仕事 儲かる企画を 考えることが仕事 1. 組織構造と文化の変革 25
- 26. © KONICA MINOLTA ゴールを共にし 全員で立ち向かえる チームが必要 1. 組織構造と文化の変革 26
- 29. © KONICA MINOLTA OpsBiz Customer DevOps cycle Dev Scrum Team Product Owner （企画部門） Dev/Scrum Master （開発部門） 部門を超えたチームを構築 1. 組織構造と文化の変革 29
- 32. チームで要求を開発する ビジネスを 考える人 SWを 考える人 • 前も同じような機能を 作ったけど本当にいる？ • 〇×より、△■な機能が トレンドだよ ユーザが○○な時に××で きる機能があると 70%までシェアが伸ばせる 開発者も要求を提案、却下する 脱御用聞き ビジネス観点 技術観点 Product Owner （企画部門） Developer （開発部門） 32
- 37. © KONICA MINOLTA アジャイル型要求開発で 組織構造（チーム構成)と 文化を変革する 1. 組織構造と文化の変革 まとめ ＆ 37
- 39. © KONICA MINOLTA 本日お伝えしたいこと 1. 組織構造と文化の変革 2. アジャイル型要求開発の進め方 3. 全社展開 39
- 41. © KONICA MINOLTA 誰の どんな課題を どのように解決し どんな効果(価値)を 狙っているのか 2. アジャイル型要求開発の進め方 41
- 42. © KONICA MINOLTA そのために 何を どこまで作るか 2. アジャイル型要求開発の進め方 42
- 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
- 53. © KONICA MINOLTA引用:https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909 User Story Mapping 53 サービスとアクターの インタラクション しか表現できていない
- 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
- 64. © KONICA MINOLTA 引用：JSTQB ソフトウェアテスト標準用語集 価値に値する能力を 満たしているか？ 64
- 67. © KONICA MINOLTA OpsBiz Customer DevOps cycle Scrum Team Product Owner （企画部門） Dev/Scrum Master （開発部門） 部門を超えたチームを構築 QA (品証部門) Dev 2. アジャイル型要求開発の進め方 品質担保 67
- 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
- 75. © KONICA MINOLTA • チームで品質レベルを決定する • チームで品質を担保する • 受け入れテストでゴールを共有する 2. アジャイル型要求開発の進め方 品質担保 75
- 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
- 92. ありがとう ございました 92