美味なるカレーは全て必然～成功要因（スパイス）を見つけ出せ～ / All delicious curry is inevitable

弥生株式会社　もくテク
弥生QAエンジニアと品質を考える会 ～カレーづくしの考察集～（2023/04/20）
https://mokuteku.connpass.com/event/275711/

Transcript

1. オンラインチーム 志田 拓也 2023年04月20日 弥生株式会社 志田 拓也 スパイス
2. 自己紹介 2 名前 入社日 所属 志田 拓也（しだ たくや） 2021年12月入社 弥生会計オンライン QA(品質保証)リーダー 経歴 自治体向けシステム開発SE⇒ソフトウェア品質保証 ポリシー 品質に限らず、組織全体を支えられる存在を目指す！ 好きなカレー マトンカレー 羊肉のクセがたまらない
3. 今回のテーマ 3 まずは以下のやり取りをご覧ください
4. とあるカレー屋の話 4 町で大人気のカレー屋 その人気からインタビューを受けることになったが… 「なぜ成功しているのか？」を聞かれたときに 上手く説明できなかった 「やあシェフ、今日も繁盛しているね。 この店の成功の秘訣は何だい？」 「うーん…なんだろうね、運かな はっはっは！」 （これじゃ取材記事は作れないな…）
6. 今回のテーマ 6 なぜこうなったのか？
7. 7 プロジェクトの成功要因を リスクベースドテストの考えで振り返る Today's theme 本日のテーマ
8. 8 弥生の開発プロセス
9. 本題 9 先ほどのカレー屋の例を 開発チームで例えると…
10. 課題 10 所属チームのプロジェクト運営は 毎回大きな問題もなく、成功できている が・・・ 「なぜ成功しているのか？」を聞かれたときに 上手く説明できなかった 「このチームって、なんで毎回成功してると思う？」 「うーん…なんでしょうね、運じゃないですか、ハハハ！」 PM 私 （このQAは本当に大丈夫なのか…？）
11. 目指す状態 11 プロジェクトが成功している要因を、 QAリーダーの立場から説明できる状態としたい
12. なぜ？ 12 ▪自身やチームが、品質保証のために十分な活動をしている という実績を伝えたい ▪成功要因を明確にし、次プロジェクトの成功にも活かしたい ▪他のチームにも成功要因を共有し、組織としての成功に繋げたい
13. やったこと 13 自身が開発プロセスの中で 実施している活動を ふりかえりしてみた JSTQBのシラバスを見直し 自身の実績を説明できる 言葉や活動が無いか考えてみた
14. 仮説 14 リスクベースドテストの考えに沿って、 プロジェクトを運営できているのではないか？
15. リスクベースドテストとは？ 15 リスク認識 リスクアセスメント リスク軽減 リスクマネジメント 上記考えを用いて、テストに優先順位をつけリスクを低減していくこと 参照：JSTQBテストマネージャ(ALTM) シラバス 2.3 リスクベースドテストとその他のテストの優先度付けと工数配分のアプロー チ https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J04.pdf
16. リスクベースドテストとは？（自身なりの解釈を交えた要約） 16 リスク認識 リスクを特定する リスクアセスメント リスクを重要度・発生確率から評価する リスク軽減 評価に応じてリスクを低減する活動を行う
17. リスクベースドテストとは？（自身なりの解釈を交えた要約） 17 リスクマネジメント 上記3つの活動を、プロジェクト運営中に随時コントロールする リスク認識 リスクを特定する リスクアセスメント リスクを重要度・発生確率から評価する リスク軽減 評価に応じてリスクを低減する活動を行う 上記考えを用いて、テストに優先順位をつけリスクを低減していくこと 「テスト」と言いつつも、「プロセス」に近い考え
18. 検証 18 プロジェクト運営中の活動に、リスクマネジメントの活動実績を当てはめてみた プロジェクト計画 要求・要件定義 外部設計・結合テスト設計 システムテスト実施 プロジェクト終結 プロジェクト計画書のレビュー プロジェクト目標に沿ったテスト計画 要求・要件レビュー 要求元との仕様のすり合わせ システムテストの作成・レビュー 設計書・結合テストのレビュー システムテストの実施 発生した障害の管理・修正確認 品質施策の検討・実施 KPTを用いた、次期プロジェクト目標の策定 プロジェクトのふりかえり 障害の分析による、プロジェクト状況の把握 結合テストの作成支援
19. 検証 19 プロジェクト運営中の活動に、リスクマネジメントの活動実績を当てはめてみた プロジェクト計画 要求・要件定義 外部設計・結合テスト設計 システムテスト実施 プロジェクト終結 プロジェクト計画書のレビュー プロジェクト目標に沿ったテスト計画 要求・要件レビュー 要求元との仕様のすり合わせ システムテストの作成・レビュー 設計書・結合テストのレビュー システムテストの実施 発生した障害の管理・修正確認 品質施策の検討・実施 KPTを用いた、次期プロジェクト目標の策定 プロジェクトのふりかえり 障害の分析による、プロジェクト状況の把握 結合テストの作成支援 各フェーズにおいて、リスクマネジメントを 『それなり』に実施できていたことがわかった
20. プロジェクト計画フェーズ 20 PMが中心に作成したプロジェクト計画書をレビュー QAの観点からの懸念事項や疑問点を提示 プロジェクト計画書のレビュー プロジェクト目標や、プロジェクトのマイルストーンに応じて テストフェーズの計画を作成 テストフェーズの計画
21. システムテスト実施フェーズ 21 テスト実施中に検出した障害を、BTSを用いて管理 また、修正された障害のテスト（修正確認）を実施 検出した障害の管理 テスト実施中に検出した障害を分析し、プロジェクトの状態を把握 分析結果に応じた品質施策を立案・実施 障害分析と施策立案
22. プロジェクト終結 22 プロジェクトの結果を、KPTを用いてふりかえる 広範囲のステークホルダーから意見を伺い、本質的なKEEP・TRYを思案 プロジェクトのふりかえり KPTの結果を、次期プロジェクトの目標や運営方法に反映 次期プロジェクトでは今回以上の成功を目指す 次プロジェクトの準備
23. これらの活動によって得られたもの 23 テスト計画を行うことによって、現在の開発スケジュールでは テスト実施計画に支障が生じることを発見。 計画の訂正を提案し、下流工程での後戻りを防ぐことに成功 プロジェクト計画書のレビュー 発生した障害を分析し、特定機能に障害の潜伏リスクが高いと判断 品質施策（追加のテスト実施）により潜伏していた障害を検出し、品質向上に貢献できた システムテスト実施フェーズ チーム全体でKPTによる振り返りを実施 次期プロジェクトでの目標を策定し、現在実践中 作業終了フェーズ
24. 新たに認識できた課題 24 プロジェクト計画段階でのリスクの洗い出しと評価が不十分であった 結果として、リアクティブな対応に偏重していた 初期段階でのリスク識別が不十分 障害分析で上がったリスクについて、ステークホルダーとの共有が不十分であった テストチーム内だけでなく、色々な視点から見ることで別のリスクも検知できた可能性あり 後半のリスクアセスメントが不十分
25. 25 カレー屋の話に戻ると…
26. カレー屋の場合 26 カレー屋の経営の活動にも、リスクマネジメントの活動があるはず 売上目標と戦略の定義 メニューの検討 材料の調達 調理 その日の売上のふりかえり 過去の実績をもとに、売上目標の設定 天気や曜日を踏まえた販売計画 メニューのターゲットや価格帯を検討 使用する材料の検討 材料の安心・確実な調達ルートの確保 レシピの再確認 明日に向けた改善点の検討 売上目標のふりかえり 調理スタッフへの教育 材料の品質チェック
27. とあるカレー屋の話のつづき 27 後日、再度インタビューを受けることになった 「成功要因」をしっかり把握することで 店のPRに繋げることができた めでたし、めでたし 「やあシェフ、相変わらず繁盛しているね。 この店の成功の秘訣は分かったかい？」 「カレーには秘伝のスパイスを使っているし、 スタッフは十分に教育しているし、 SNSのトレンドも考慮しているし、それから…」 （これはいい取材記事が書けそうだ…！）
28. 28 Summary of the day 本日のまとめ～この活動で得られたもの～ 再現性のある運営 プロジェクトの成功要因をしっかりと認識することで 次のプロジェクトや他プロジェクトの運営に生かせる リスクマネジメントによる品質向上 各工程でプロジェクト/プロダクトリスクを適切にコントロールし リスクを低減させることで、品質の更なる向上が図れる 弥生のQAリーダーは、テストをするだけではなく プロジェクト全体の品質を向上させるべく、活動しています！
29. ご清聴ありがとうございました 29