Backlogでプロジェクトマネジメントの基礎を抑えよう！〜フリープランの活用方法〜 #JBUG #JBUG札幌

5月30日にEZOHUB SAPPROで開催したJBUG札幌の発表資料です。
https://jbug.connpass.com/event/311440/

Transcript

1. Backlogでプロジェクトマネジメントの基礎を抑えよう！ 〜フリープランの活用方法〜 テックタッチ株式会社 QAエンジニア Michiya Maki JBUG札幌 #13
2. 自己紹介 焼き鳥が焼ける QAエンジニア 巻　宙弥（まき　みちや） プログラマ→システムエンジニア→マネージャ→ITコンサルタント 昨年、スタートアップのテックタッチ(株)にQAエンジニアとして転職 michiya.maki.1 makky_tyuyan 昨年から自分で串打ちして焼く「おうちやきとり」にハマってます。 #札幌串打同盟 マイブーム 北海道札幌からフルリモートで勤務中
8. Backlogでプロジェクトマネジメントするために 抑えておきたい3つの基礎 課題を構造化する 文章の客観性を保つ リスクを見分ける
9. 課題を構造化する
10. 課題を構造化しよう
11. 課題を構造化しよう ゴールからつくる あきらかな問題からつくる 結論からつくる
12. そのまえに
13. 課題ってなに？
14. 問題 現状 目指す 状態 課題 課題とは ギャップ 打ち手 目指す状態と現状のギャップが問題、問題を解決するための取り組みが課題 注）絶対にこの考えが正しい！と主張するものではありません
15. 課題を構造化しよう ゴールからつくる あきらかな問題からつくる 結論からつくる
16. ゴールからつくる ゴール 小さなゴール 小さなゴール もっと小さなゴール 施策 施策 施策
17. あきらかな問題からつくる 問題 要因・原因 要因・原因 要因・原因 要因・原因 要因・原因 要因・原因
18. 結論からつくる 結論 小さな結論 小さな結論 小さな結論 根拠 根拠 根拠
19. 結論 小さな結論 小さな結論 根拠 根拠 根拠 問題 要因・原因 要因・原因 要因・原因 要因・原因 要因・原因 ゴール 小ゴール 小ゴール 施策 施策 施策 論点が混ざらないように注意する
20. 課題 背景 Backlogでわかりやすく表現する それがなに？ なぜ？ 親課題 子課題 TODO
21. 課題 背景 Backlogでわかりやすく表現する それがなに？ なぜ？ 親課題 子課題 TODO フリープランだと使えない
22. シンプルにまとめる ### 概要 ◆◆◆◆◆（要約を載せる） ### 解決したい課題 本来◯◯◯だが、XXXなので□□□としたい ### 具体的なアクション - [ ] ••までに▲▲を行う - [ ] ••までに▲▲を行う
23. 要約はAIにサポートしてもらう フリープランで使える！
24. 文章の客観性を保つ
25. 客観性ってなに？
26. 客観性とは 客観性（Objective）とは 個人の感情、偏見、主観的な意見を排除して、事象を公平かつ中立的に観察、評価、分析す ること。客観性を保つことは、科学的研究、ジャーナリズム、ビジネス意思決定など多くの 分野で重要視されます。 逆に、 、 、客観性の対義語は主観性（Subjective）です。 主観性は、個人の経験、感情、信念、好みに基づいて物事を捉えることを指します。 主観的な見解は、個々の人に特有であり、他の人と考えを共有するのは難しいとされます。
27. 主観 共感 客観 わたし あなた ほかの誰か 客観性のイメージ
28. 主観 共感 客観 わたし あなた ほかの誰か 客観性を保つために重要な４つの問い 事実と意見の区別　 （ほんとのこと？　思っていること？） 客観的な分析では、確かな証拠やデータに基づいた事実と、 それに対する個人的な解釈や意見を明確に区別する必要があります。 証拠の確認　 （どうしてそう思うの？） 提示された情報やデータが正確で信頼性のあるソースから得られたものであること を確認します。 複数の視点の検討　 （いろんな人の考えが元になっているの？） 一つの視点だけに依存せず、異なる視点や意見を考慮に入れることで、より全面的 な理解を目指します。 透明性と開放性　 （いつでも誰でもわかる状態になってる？） 判断や分析のプロセスを透明に保ち、批判的なレビューや他者の意見を受け入れる ことで、偏見の可能性を低減します。
29. 文章をわかりやすくする
30. わかりやすい文章を書くための2つのコツ 単語の難易度を下げる 接続詞や接続助詞に頼らない
31. 人間が短期的に記憶できる量はある一定のキャパしかない。 長い文章を読むにつれて難しい単語やわかりづらい単語、知ら ない単語が多いと把握しきれず読み直すことになる。 単語の難易度を下げる 難しい単語 わかりづらい単語 知らない単語 難しい単語 わかりづらい単語 知らない単語 知 ら な い 単 語 ※人間が瞬間的に保持できる情報の数は「7±2」であるとするもの。 アメリカのハーバード大学の心理学者、ジョージ・ミラー教授（George Armitage Miller）による1956年の論文「The Magical number seven, plus or minus two」で登場 ※ 未知語 (あまり知られていない単語) 曖昧語 （意味がハッキリしない単語） 難解語 （理解しにくい単語）
32. 接続詞や接続助詞に頼らない ※ 転換（しかし、だが） 、因果（だから） 、選択（または） 、条件（なら）等の接続詞を乱用しない。 複文になりやすい、逆説（が） 、理由（ので） 、逆接（けれども） 、並列（と）を乱用しない。 例） 原因・理由を表す複文 「彼は疲れていたので、早く家に帰りました。 」 ※「彼は疲れていたので」が理由を表し、 「早く家に帰りました」が主文です。 対比を表す複文 「外は寒いけれども、部屋の中は暖かい。 」 ※「外は寒いけれども」が対比を表し、 「部屋の中は暖かい」が主文です。 結果を表す複文 「一生懸命勉強したので、試験で良い成績を取ることができた。 」 ※「一生懸命勉強したので」が理由を表し、 「試験で良い成績を取ることができた」が主文です。
33. リスクを見分ける
34. リスクの種類 プロジェクトリスク プロダクトリスク
35. プロジェクトリスクとは プロジェクトのマネジメントや統制に関連するものである。 プロジェクトリスクには、以下のようなものがある： ⚫ 組織的な問題（作業成果物の納期遅れ、不正確な見積り、コストダウンなど） ⚫ 人の問題（例：スキル不足、対立、コミュニケーションの問題、人手不足など） ⚫ 技術的な問題（スコープクリープ、ツールサポートの不備など） ⚫ サプライヤーの問題（例：第三者による納品の失敗、サポート企業の倒産など） プロジェクトリスクは、顕在化した場合、プロジェクトのスケジュール、予算、スコー プに影響を与え、プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf
36. プロジェクトリスクとは プロジェクトのマネジメントや統制に関連するものである。 プロジェクトリスクには、以下のようなものがある： ⚫ 組織的な問題（作業成果物の納期遅れ、不正確な見積り、コストダウンなど） ⚫ 人の問題（例：スキル不足、対立、コミュニケーションの問題、人手不足など） ⚫ 技術的な問題（スコープクリープ、ツールサポートの不備など） ⚫ サプライヤーの問題（例：第三者による納品の失敗、サポート企業の倒産など） プロジェクトリスクは、顕在化した場合、プロジェクトのスケジュール、予算、スコー プに影響を与え、プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf スプリントの機能開発が予定通りに進まず リリースサイクルに影響を及ぼすもの全てを指す
37. プロダクトリスクとは プロダクトの品質特性（例えば、ISO 25010 品質モデルに記述がある）に関連するもの である。プロダクトリスクの例としては、機能の不足や誤り、誤った計算、ランタイム エラー、貧弱なアーキテクチャー、非効率なアルゴリズム、不十分な応答時間、貧弱な ユーザーエクスペリエン ス、セキュリティの脆弱性などが挙げられる。プロダクトリス クが顕在化した場合、以下のようなさまざまな負の結果をもたらす可能性がある： ⚫ ユーザーの不満足 ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf
38. プロダクトリスクとは プロダクトの品質特性（例えば、ISO 25010 品質モデルに記述がある）に関連するもの である。プロダクトリスクの例としては、機能の不足や誤り、誤った計算、ランタイム エラー、貧弱なアーキテクチャー、非効率なアルゴリズム、不十分な応答時間、貧弱な ユーザーエクスペリエン ス、セキュリティの脆弱性などが挙げられる。プロダクトリス クが顕在化した場合、以下のようなさまざまな負の結果をもたらす可能性がある： ⚫ ユーザーの不満足 ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf プロダクトの設計・機能・仕様に関連し プロダクトそのものの評価に影響を及ぼすもの
39. 「何が課題なのか？」 プロジェクトリスク プロダクトリスク どっちに対処？
40. デモ
41. ご清聴ありがとうございました ご清聴ありがとうございました