Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロダクトの品質とユーザ視点の品質を考えてみる/The_quality_of_the_product_and_the_quality_of_user's_perspective

 プロダクトの品質とユーザ視点の品質を考えてみる/The_quality_of_the_product_and_the_quality_of_user's_perspective

Scrum Fest Osaka 2021 において講演した資料その1です。

Muneyoshi Iyama

June 26, 2021
Tweet

More Decks by Muneyoshi Iyama

Other Decks in Technology

Transcript

  1. Copyright © NTT COMWARE CORPORATION 2021 NTTコムウェア Agileエバンジェリスト 伊山 宗吉

    (Iyama Muneyoshi) • 所属:技術企画部 技術SE部門 • 業務:社内のアジャイル推進 社内アジャイルコーチ(案件立ち上げ・改善の支援) Agileエバンジェリスト(2020年3月から) ミッション 1. アジャイル開発推進活動の牽引 2. 自社のプレゼンス向上 2
  2. Copyright © NTT COMWARE CORPORATION 2021 主な業務 3 • 社内アジャイルコーチとして、スクラムチームを支援

    • アジャイルのための社内ルール整備 スクラムチーム (事業組織) アジャイルコーチ (推進組織) 総務人事、財務、 知財、など (機能別組織) 現場支援 ルール整備 お客様 研修提供、 立ち上げ併走、 改善アドバイス 課題相談 課題共有 &改善
  3. Copyright © NTT COMWARE CORPORATION 2021 NTTコムウェアについて 5 役割 一般市場のお客様に対して

    NTTグループの一員として  ビジネスパートナー • 新規事業に関わる提案、ITを中心としたビジネス企画、 プロジェクト推進の支援  システムインテグレーター • お客様に合ったソリューション提供、システム開発、 運用、など  NTTグループ全体のIT最適化 • 企画・提案、システム開発  NTTグループ事業会社のCIO補佐役 • ソリューション提案、プロジェクト推進の支援  システムインテグレーター • グループ各社への最適なソリューション提供、 システム開発、運用、など お客様やNTTグループのビジネスをITで支援している会社
  4. Copyright © NTT COMWARE CORPORATION 2021 今考えるべき品質(1) SoEの開発に適したアジャイル開発では 「顧客満足」=「価値あるプロダクト」という価値観。 「動く」「繋がる」

    という信頼性は前提 参考:「アジャイル宣言の背後にある原則」より抜粋 https://agilemanifesto.org/iso/ja/principles.html(2021/06/21)
  5. Copyright © NTT COMWARE CORPORATION 2021 今考えるべき品質(2) 顧客満足に影響を与える品質として 「狩野モデル」が世界的にも広く知られている。 充足

    不充足 一般的な例 (スマートフォン端末) 魅力的 品質 満足 仕方が ない ハイレゾ音源対応、ブルーライト カット機能、など 一元的 品質 満足 不満 バッテリーの持ち、軽量さ、応答 速度、など 当たり 前品質 当たり前 不満 致命的な欠陥が無い、ソフトウェ アアップデートがある、など 満足 不満足 不充足 充足 満足 無くても 仕方ない 当たり前 不満 参考: 「魅力的品質と当たり前品質」 狩野紀昭; 瀬楽信彦、高橋文夫、辻新一. 日本品質管理学会会報 品質 14(2), 147-156, 1984.
  6. Copyright © NTT COMWARE CORPORATION 2021 充足 不充足 一般的な例 (スマートフォン端末)

    魅力的 品質 満足 仕方が ない ハイレゾ音源対応、ブルーライト カット機能、など 一元的 品質 満足 不満 バッテリーの持ち、軽量さ、応答 速度、など 当たり 前品質 当たり前 不満 致命的な欠陥が無い、ソフトウェ アアップデートがある、など 今考えるべき品質(3) SoEでのビジネス成功にはSoR以上に「魅力的品質」が重要。 開発者は「当たり前品質」だけでなく 「魅力的品質」との両立を考える必要がある。 ユーザのジョブ&ニーズに基づく (ウォーターフォールでは 要件定義に盛り込まれていた) 従来の品質管理でも 考慮されてきた
  7. Copyright © NTT COMWARE CORPORATION 2021 当たり前品質と魅力的品質 14 当たり前品質 魅力的品質

    プロダクトが違っても 共通項は多い 自社の立ち位置や プロダクトごとに様々 まずはNTTグループへのブランドイメージ低下を防ぐため、 「当たり前品質」を確保する方法に取り組んだ。
  8. Copyright © NTT COMWARE CORPORATION 2021 15 プロダクトの 「当たり前」って何だろう? プ

    ロ ダ ク ト の 品 質 と ユ ー ザ 視 点 の 品 質 を 考 え て み る
  9. Copyright © NTT COMWARE CORPORATION 2021 アジャイルで「当たり前品質」をどう確保するか 17 開発 開発準備

    企画 リリース ・・・ リリース スプリント 1 スプリント N 当たり前品質の 認識合わせ 開発前に関係者(案件によってはエンドユーザ)と品質モデル(次頁) をベースに「当たり前品質」の認識合わせをするようにした。 • インセプションデッキと合わせて実施 (プロダクトの背景、ビジョン、ロードマップ、などの理解も必要) • 開発前に決められない項目は、いつ頃までに決めるかを意識合わせしておく • あくまで開始時点での認識合わせなので、開発の中で適宜見直しを行う 無計画や過剰品質を防止
  10. Copyright © NTT COMWARE CORPORATION 2021 18 何について 意識合わせすればいいのか? プ

    ロ ダ ク ト の 品 質 と ユ ー ザ 視 点 の 品 質 を 考 え て み る
  11. Copyright © NTT COMWARE CORPORATION 2021 参考にしているモデル:SQuaRE 19 私たちはシステム及びソフトウェア製品の品質要求および評価 に関するISO/IECの国際規格の「SQuaRE」を参考にしている

    製品品質 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 性能効率性 資源効率性 容量満足性 共存性 適切度認識性 成熟性 機密性 モジュール性 適応性 相互運用性 習得性 可用性 インテグリティ 再利用性 設置性 機能完全性 機能正確性 機能適切性 運用操作性 障害許容性 (耐故障性) 否認防止性 解析性 置換性 ユーザエラー 防止性 回復性 責任追跡性 修正性 ユーザインタ フェース快美性 真正性 試験性 アクセシビリティ 利用時の品質 有効性 有効性 効率性 満足性 リスク回避性 利用状況網羅性 効率性 実用性 利用状況完全性 経済リスク緩和性 信用性 柔軟性 健康・安全リスク緩和性 快感性 環境リスク緩和性 快適性 特性 データ品質 固有 システム依存 正確性 〇 完全性 〇 一貫性 〇 信憑性 〇 最新性 〇 アクセシビリティ 〇 〇 標準適合性 〇 〇 機密性 〇 〇 効率性 〇 〇 精度 〇 〇 追跡可能性 〇 〇 理解性 〇 〇 可用性 〇 移植性 〇 回復性 〇 データ品質 特にこのモデル 出展:IPA 「つながる世界のソフトウェア品質ガイド」 https://www.ipa.go.jp/sec/reports/20150609.html (2020/11/20)
  12. Copyright © NTT COMWARE CORPORATION 2021 品質目標の認識合わせ 20 「製品品質」モデルをベースに非機能系の品質目標、 「やる/やらない/後で決める」(※)などを議論する

    動作保証対象とするOS・ブラウザの 組み合わせはこれで良いですか? 保守性を高めるためにログ出力の 方針を整理しておきましょう (※)インセプションデッキの「やらないことリスト」を作るのと同じ まずは最大100人の同時アクセスで レスポンスタイム3秒以内を目標に してみましょうか。処理が複雑な 機能については個別に定義しましょう。 ここで議論した内容をバックログ、設計、実装、テスト の内容に反映することで「当たり前品質」の考慮漏れを防ぐ
  13. Copyright © NTT COMWARE CORPORATION 2021 品質目標の認識合わせ 21 # 品質特性

    概要(意訳) 整理する内容のイメージ (一例) 1 機能適合性 機能がステークホルダのニー ズに適合しているか ・リリースに必要な機能が揃っていることをPOが確認している など 2 性能効率性 実行性能が問題ないか ・性能テストの結果が目標値 XX秒以内 など 3 互換性 他のシステムや環境と接続/ 共存できるか ・IN/OUTのファイル形式として 〇〇, △△を確認 など 4 使用性 製品がどの程度使いやすいか ・マニュアルやシステム上で各機能の操作方法を説明している ・各機能にUndoやエラーチェックを考慮している など 5 信頼性 不具合や障害が軽減されてい るか ・UTカバレッジが XX %以上 ・故障や障害発生時に XX 分以内に復旧 など 6 セキュリティ アクセス制御やデータの保全 を行っているか ・利用者の役割に応じたアクセス制御を行う ・セキュリティ脆弱性診断の指摘0件にする など 7 保守性 システム保守・修正が容易か ・ソースコードの複雑度が XX以内 ・〇〇毎にログ出力させる など 8 移植性 異なる環境に容易に移行でき るか ・ブラウザからiOS、Android版とのデータ連携に対応している など 現場での議論の際の参考にしてもらうために、 品質特性ごとに具体例を挙げてリストを作成。社内へ提供中。 合意形成 チーム 社内提供 利害 関係者
  14. Copyright © NTT COMWARE CORPORATION 2021 22 開発の中で品質目標を、 どうやって達成するのか? プ

    ロ ダ ク ト の 品 質 と ユ ー ザ 視 点 の 品 質 を 考 え て み る
  15. Copyright © NTT COMWARE CORPORATION 2021 参考:スクラムガイド2020より 23 スクラムにおいては『完成の定義』(Doneの定義)は品質を作りこみ、 品質基準を満たすための共通認識を表す重要な要素である。

    「スクラムの作成物」に関する記述 「スクラムチーム」のロールに関する記述 参考:「スクラムガイド 2020」より抜粋 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum- Guide-Japanese.pdf(2021/06/21)
  16. Copyright © NTT COMWARE CORPORATION 2021 アジャイルで「当たり前品質」をどう確保するか 24 開発 開発準備

    企画 リリース ・・・ リリース スプリント 1 スプリント N 目指す品質の 認識を合わせる 品質目標を満たすために必要な作業や確認内容を Doneの定義に反映する。 目標に沿ったプロセス設計 (Doneの定義)
  17. Copyright © NTT COMWARE CORPORATION 2021 参考:考え方の例 25 • 性能効率性

    レスポンスタイム 3秒以内(最大同時アクセス数 100) タスク バックログ スプリント リリース Doneの定義の全体イメージ 0% 100% スプリントのDoneの定義 リリースのDoneの定義 事前の合意内容 • 性能テストツールで 100 リクエスト/秒 の負荷をかけ、 テスト対象ページのレスポンスタイム測定結果が品質基準内(3秒以内)であること • 証跡:性能テスト結果ファイル 確認方法 Doneの定義 • 性能テストを実施し、合格していること • 性能テストを実施し、合格していること
  18. Copyright © NTT COMWARE CORPORATION 2021 参考:Doneの定義の例 26 スプリント ストーリー

    リリース • 以下作業を含む全ての対応 タスクがDoneになっている  C/UT  IT項目作成  ITコード作成  性能テストコード作成  IT実施 ※技術調査は必要に応じて実施 • 受入基準を満たしている • POの受入確認に合格している • 全てのストーリーがDoneに なっている • 以下作業が全てDoneになって いる  設計情報作成・更新済み • 業務仕様 • API仕様 • クラス設計 • DB設計  レビュー実施済み  レビューのフィードバック コメントをWikiに記録済み  メトリクスを集計済みで、 閾値をクリアしている  性能テスト結果に問題ない ことをPOが確認済み • 運用マニュアルを作成・更新 済み • POのリリース判定に合格して いる  リリースに必要なス トーリーが全てDone  リリース前の性能テス ト結果に問題がない • セキュリティ診断で深刻な リスクの指摘が0である • 判定①(各担当)承認済み • 業務主管への文書回覧済み • 判定②(全体)承認済み • 運用監視の仕組みを引き継ぎ 済み タスク タスク毎に 個別に定義 (割愛)
  19. Copyright © NTT COMWARE CORPORATION 2021 アジャイルで「当たり前品質」をどう確保するか 27 開発 開発準備

    企画 リリース ・・・ リリース スプリント 1 スプリント N 目指す品質の 認識を合わせる リリースのDoneの定義 を満たしていればリリース可 開発では、作成したDoneの定義に基づいて 状態確認&基準を満たすよう改善することで、品質を作り込む 目標に沿ったプロセス設計 (Doneの定義) Doneの定義に基づいて開発 (適宜見直し)
  20. Copyright © NTT COMWARE CORPORATION 2021 28 でもこれだけでは 足りません プ

    ロ ダ ク ト の 品 質 と ユ ー ザ 視 点 の 品 質 を 考 え て み る
  21. Copyright © NTT COMWARE CORPORATION 2021 大切なこと(1)テクニカルスキル 29 良い設計か、十分な試験かといった定義・評価は難しく、 開発者のスキルに依存する

    体制構築時のスキルマップ考慮、 有識者の参画 or 支援、 メンバの継続的なスキルアップ 「アジャイル宣言の背後にある原則」より抜粋 https://agilemanifesto.org/iso/ja/principles.html(2021/06/21)
  22. Copyright © NTT COMWARE CORPORATION 2021 大切なこと(2)自動化 30 Doneの定義を満たすために ・テスト等を繰り返し実施

    ・コードのメトリクスやチケットのデータを集計 ・継続的にビルド/デプロイ ↓ 手作業では時間がかかりすぎる 開発時間が減る or 試験を削る 自動化 自動化にもコストがかかるので、 初期から積み上げることが重要 「アジャイル宣言の背後にある原則」より抜粋 https://agilemanifesto.org/iso/ja/principles.html(2021/06/21)
  23. Copyright © NTT COMWARE CORPORATION 2021 当たり前品質と魅力的品質 31 当たり前品質 魅力的品質

    プロダクトが違っても 共通項は多い 自社の立ち位置や プロダクトごとに様々 ユーザにプロダクトを選択してもらうためには 「魅力的品質」にも取り組む必要がある
  24. Copyright © NTT COMWARE CORPORATION 2021 32 このプロダクトの 「魅力」って何だろう? プ

    ロ ダ ク ト の 品 質 と ユ ー ザ 視 点 の 品 質 を 考 え て み る
  25. Copyright © NTT COMWARE CORPORATION 2021 33 魅力的かどうかはユーザが判断するので、 ユーザに繰り返し提供し、フィードバックをもらう ただし、開発にも相応のコストがかかるので、

    見込みを立てないとムダなものを作るリスクが高くなる プ ロ ダ ク ト の 品 質 と ユ ー ザ 視 点 の 品 質 を 考 え て み る
  26. Copyright © NTT COMWARE CORPORATION 2021 「魅力的品質」に対するアプローチ 34 開発 開発準備

    企画 リリース ・・・ リリース スプリント 1 スプリント N 開発前にユーザを中心に据えた問題定義とアイデア検証を実施し、 ユーザのニーズとのギャップを防ぐ。 開発に入ってからも継続してアイデア検証と開発を連動させる。 開発前にユーザにとって魅力ある プロダクトになり得るか事前検証 検証し、見込みのある バックログを開発に回す
  27. Copyright © NTT COMWARE CORPORATION 2021 「魅力的品質」に対するアプローチ 35 私たちは、ユーザを中心に据えた問題探索と検証の方法として デザインシンキングを取り入れるようにしている。

    デザインシンキング 共感 定義 発想 試作 検証 Look Do Think スクラムでの開発 ユーザの立場になって 問題を定義 問題を解決する アイデアを創出 アイデアを形にしてユーザ に試し、ブラッシュアップ
  28. Copyright © NTT COMWARE CORPORATION 2021 参考:実践例 36 開発前に想定ユーザへのアイデア検証を行ってMVPを精査できた。 開発中も新たに得た情報から前提に立ち戻って見直すことで、

    アイデア創出や優先順位の判断にも繋がることもあった。 例:社内の技術者同士の交流により自己研鑽を図る仮想PJ デザインシンキング 想定ユーザの若手社員、 中堅社員へインタビュー 共感 定義 発想 試作 検証 Look Do Think ブラッシュアップ フィードバックもらう 繰り返す 分析&課題定義 Scrumでの開発 先輩の情報から学習に結びつけるには、 必要な事前知識や自分に合ったレベル感か などを知りたいニーズがあることが判明。 先輩社員が学んでいる技術、 書籍を紹介。若手が学習の参 考に出来る。情報交換の場も 提供する。 開発に入る前に MVPを精査 レビュー 開発で得たフィードバックから 内容を見直すことも
  29. Copyright © NTT COMWARE CORPORATION 2021 「魅力的品質」の評価 37 開発したMVPがユーザに魅力を提供できたか評価する際は、 SQuaREの「利用時の品質」を参考にしている

    デザインシンキング (ユーザ中心の設計思考) 例:SQuaRE(利用時の品質) 利用時の品質 有効性 有効性 効率性 満足性 リスク回避性 利用状況網羅性 効率性 実用性 利用状況完全性 経済リスク緩和性 信用性 柔軟性 健康・安全リスク緩和性 快感性 環境リスク緩和性 快適性 正解が無い領域での仮説検証による アプローチの組み合わせ 開発したプロダクトのユーザ評価 (設計においては、開発するプロダクトに期待するユーザ評価) リーンスタートアップ (ビジネスモデル検討) 有効性・効率性などの客観的評価と 満足性による主観的評価がある アジャイル開発 (プロダクト開発)
  30. Copyright © NTT COMWARE CORPORATION 2021 まとめ 40 • 「プロダクトの品質」≒「ユーザ視点の品質」

     「当たり前」と「魅力的」の品質の両立  ビジネスと開発の連携 • 弊社での品質アプローチ  一般的な品質モデルを参考に「当たり前品質」の認識を合わせ、 開発プロセスの中で品質を作り込む。  デザインシンキングでユーザの問題解決やニーズを探索・検証し、 「魅力的品質」の見込みを立てて開発する。