Backlogを始めてみよう！フリープランでハンズオン #JBUG #JBUG東北

JBUG東北 #1 + JAWS-UGいわて コラボ開催
仕事の"うまい"進め方をシェアしよう！で発表した資料です。
https://jbug.connpass.com/event/326951/

ハンズオン1. Backlogを始めてみよう！フリープランでハンズオン
セッション2. リスクを見分けてBacklogで視える化しよう

Transcript

1. Backlog　ハンズオン！ フリープランでBacklogを使い倒そう！ JBUG札幌 巻　宙弥（まき　みちや） JBUG東北 #1　JAWS-UGいわて コラボ開催 仕事の"うまい"進め方をシェアしよう！ 2024/10/19 Sat.
2. Backlogで抑えておきたいキーワード スペース・プロジェクト・課題 https://backlog.com/ja/blog/backlog-framework-task-mangement-beginner/
3. Backlog利用時に必ず行いたいこと
4. 単語の定義
5. 課題とはなにか？
6. 問題 現状 目指す 状態 課題 課題とは ギャップ 打ち手 目指す状態と現状のギャップが問題、問題を解決するための取り組みが課題 注）絶対にこの考えが正しい！と主張するものではありません
7. Backlogでプロジェクトマネジメントするために 抑えておきたい3つの基礎 課題を構造化する 文章の客観性を保つ リスクを見分ける
8. Backlogでプロジェクトマネジメントするために 抑えておきたい3つの基礎 課題を構造化する 文章の客観性を保つ リスクを見分ける
9. 課題を構造化しよう ゴールからつくる あきらかな問題からつくる 結論からつくる
10. ゴールからつくる ゴール 小さなゴール 小さなゴール もっと小さなゴール 施策 施策 施策
11. あきらかな問題からつくる 問題 要因・原因 要因・原因 要因・原因 要因・原因 要因・原因 要因・原因
12. 結論からつくる 結論 小さな結論 小さな結論 小さな結論 根拠 根拠 根拠
13. 結論 小さな結論 小さな結論 根拠 根拠 根拠 問題 要因・原因 要因・原因 要因・原因 要因・原因 要因・原因 ゴール 小ゴール 小ゴール 施策 施策 施策 論点が混ざらないように注意する
14. 課題 背景 Backlogでわかりやすく表現する それがなに？ なぜ？ 親課題 子課題 TODO
15. 課題 背景 Backlogでわかりやすく表現する それがなに？ なぜ？ 親課題 子課題 TODO フリープランだと使えない
16. シンプルにまとめる ### 概要 ◆◆◆◆◆（要約を載せる） ### 解決したい課題 本来◯◯◯だが、XXXなので□□□としたい ### 具体的なアクション - [ ] ••までに▲▲を行う - [ ] ••までに▲▲を行う
17. Backlogでプロジェクトマネジメントするために 抑えておきたい3つの基礎 課題を構造化する 文章の客観性を保つ リスクを見分ける
18. 客観性ってなに？
19. 主観 共感 客観 わたし あなた ほかの誰か 客観性のイメージ
20. 主観 共感 客観 わたし あなた ほかの誰か 客観性を保つために重要な４つの問い 事実と意見の区別　 （ほんとのこと？　思っていること？） 客観的な分析では、確かな証拠やデータに基づいた事実と、 それに対する個人的な解釈や意見を明確に区別する必要があります。 証拠の確認　 （どうしてそう思うの？） 提示された情報やデータが正確で信頼性のあるソースから得られたものであること を確認します。 複数の視点の検討　 （いろんな人の考えが元になっているの？） 一つの視点だけに依存せず、異なる視点や意見を考慮に入れることで、より全面的 な理解を目指します。 透明性と開放性　 （いつでも誰でもわかる状態になってる？） 判断や分析のプロセスを透明に保ち、批判的なレビューや他者の意見を受け入れる ことで、偏見の可能性を低減します。
21. 客観性を評価するアプローチ 客観性とは、 「個人の感情や偏見を排除して物事を公平に評価すること」です。 一般的に客観性は定量的に示さないといけない。と思われがちですが、 客観性は定量でも定性でも示すことができます。 定量 定性
22. 5W2H 説明 What (何を) 何が行われるのか、または何が問題なのかを指します。目的や課題の内容を明確にします。 Why (なぜ) なぜそれを行うのか、またはなぜその問題が存在するのかを問います。 目的や理由を明確にすることで、行動の正当性を確立します。 Who (誰が) 誰がそのタスクを実行するのか、または誰が関係者であるのかを指します。 担当者や責任者、利害関係者を特定します。 When (いつ) いつその活動が開始され、終了するのか、またはいつその問題が発生したのかを問います。 タイムラインや期限を設定します。 Where (どこで) どこでその活動が行われるのか、または問題が発生しているのかを指します。場所や環境を特定します。 How (どのように) どのようにしてその活動を実行するのか、またはどのようにしてその問題を解決するのかを問います。 方法や手順、プロセスを明確にします。 How much (どれくらいの) どれくらいのコストがかかるのか、またはどれくらいのリソースが必要なのかを指します。 量や規模、予算を概算します。
23. Backlogでプロジェクトマネジメントするために 抑えておきたい3つの基礎 課題を構造化する 文章の客観性を保つ リスクを見分ける
24. リスクを見分けてBacklogで視える化しよう JBUG東北 #1　JAWS-UGいわて コラボ開催 仕事の"うまい"進め方をシェアしよう！ 2024/10/19 Sat. JBUG札幌 巻　宙弥（まき　みちや）
25. 目次 本セッションの概要 1. リスクとはなにか？ 2. ２つのリスクを見分ける 3. 事例紹介 4. まとめ 5.
26. 本セッションの概要 品質マネジメント 品質保証 品質コントロール 「品質コントロール」と「品質保証」を包括 ※一般に使われている品質管理と概ね同義と考えています ※
27. 本セッションの概要 品質マネジメント リスクマネジメント ? ? 「リスクマネジメント」における2つのリスクの見分け方を紹介します。
28. ? ? なぜ、リスクを見分けることが大事なのか？ 品質マネジメント リスクマネジメント プロジェクトの成功 製品の品質 影響 影響
29. 3.リスクとはなにか？ 私は、マネジメントと名のつく活動には、根本に必ず「リスク」があると考えています。 普段から何気なく使っている言葉ですが、改めてリスクの意味を整理してみましょう。
30. リスクとはなにか？ 顕在化すると悪影響をもたらす潜在的な事象、 ハザード、または脅威のこと 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf ※JSTQB（Japan Software Testing Qualifications Board）とは？ 日本国内におけるソフトウェアテストに関する資格認定を行う組織です。 国際的なソフトウェアテストの資格認定団体であるISTQB（International Software Testing Qualifications Board）の日本支部として、ソフトウェアテストの知識体系を普及させています。
31. リスクとはなにか？ 目的に対する不確かさの影響 引用）ソフトウェア品質知識体系ガイド （第3版） －SQuBOK Guide V3－ 不確実なイベントや状態で、発生すると プロジェクトの目標にプラスまたはマイナスの影響を 与える可能性があるもの 引用）プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版
32. リスクとはなにか？ 目的を達成する上での不確かさがもたらす影響 ふ たし
33. リスクの例
34. 予期せぬ問題 解決までの時間 リリース日が守れない リスクの例 新しい機能をリリースする際、開発途中 で予期せぬ技術的な問題が発生 計画外のバグ修正や追加のテストが必要になる 開発のスケジュールが遅れ、 リリース日が守れない可能性が出てくる
35. 予期せぬ問題 解決までの時間 リリース日が守れない リスクの例 新しい機能をリリースする際、開発途中 で予期せぬ技術的な問題が発生 計画外のバグ修正や追加のテストが必要になる 開発のスケジュールが遅れ、 リリース日が守れない可能性が出てくる プロジェクトの進行に 悪影響を与える潜在的なリスク
36. 4. 2つのリスクを見分ける 2つのリスクについて、JSTQBの定義を引用しながら、説明します。
37. プロジェクトリスク プロダクトリスク リスクには2つの側面がある 2つのリスクを見分けることがリスクマネジメントの第一歩
38. プロジェクトリスクとは プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 要件の増加 スケジュール遅延 コスト増加 要因 影響
39. プロダクトリスクとは 以下のようなさまざまな負の結果をもたらす可能性がある。 ⚫ ユーザーの不満足 ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 機能不足 不十分な応答時間 使いづらさ 脆弱性
40. プロジェクトリスク プロダクトリスク 2つのリスクは相互に影響し合う 相互影響 重要なのは、この2つのリスクが相互に影響し合うという点
41. プロジェクトリスク プロダクトリスク 2つのリスクは相互に影響し合う 相互影響 片方のリスクにだけ対処すると もう片方のリスクが顕在化する可能性がある 重要なのは、この2つのリスクが相互に影響し合うという点
42. 2つのリスクを見分けるプロセスが重要 プロジェクトリスク プロダクトリスク どっちに対処？ このような状態を防ぐには、リスクを見分けるプロセスが重要
43. 現在の取組
44. テックタッチの開発プロセス プランニングから参加
45. テックタッチのリリースサイクル テックタッチのリリースサイクルは3ヶ月に一度
46. プランニ ング QA 情報共有会 スプリン トレビュ ー QAがリスクを見分けるプロセス 昨年
47. QA プランニング プランニ ング QA 情報共有会 スプリン トレビュ ー QAがリスクを見分けるプロセス 現在 開発プロセスや体制変更のタイミングでQAプランニングを追加
48. QA プランニング プロジェクトリスクを見分ける テストに必要なドメイン知識が不足する テストに必要なスキルが不足する スケジュールに対しQAのリソースが不足する 要件定義や設計に時間がかかりそう 3ヶ月に一度のリリースに影響を与える可能性はあるか？ リスク要因
49. QA 情報共有会 機能性・使用性・テストプロセスに影響を与える可能性はあるか？ リスク要因 「〜」という表現は顧客が誤解しそうだ 「〜」の手順は使用性を損なう可能性がある 「〜」のようなケースは検討されているか？ この機能はテスト設計が難しそうだ プロダクトリスクを見分ける
50. 最近の事例 開発スケジュール延伸 コードフリーズ延伸
51. 不具合分析によるリスクの特定
52. プロジェクトリスクの最小化を図る 潜在している不具合を検出 テスト戦略 既存機能の不具合や修正機能のデグレードを発見。 リリース直前のプロジェクトリスク顕在化を低減
53. 5.まとめ
54. プロジェクト リスク プロダクト リスク まとめ 品質マネジメント リスクマネジメント 2つのリスクを適切に見分け、Backlogの種別で表現します。 相互に影響するリスクも考慮して対処することが重要です。
55. リスクを見分けてBacklogで視える化しよう テックタッチ株式会社 巻　宙弥（まき　みちや） JBUG東北 #1　JAWS-UGいわて コラボ開催 仕事の"うまい"進め方をシェアしよう！ 2024/10/19 Sat. ご清聴ありがとうございました