Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Backlogでプロジェクトマネジメントの基礎を抑えよう!〜フリープランの活用方法〜 #JBU...
Search
Makky
May 30, 2024
0
140
Backlogでプロジェクトマネジメントの基礎を抑えよう!〜フリープランの活用方法〜 #JBUG #JBUG札幌
5月30日にEZOHUB SAPPROで開催したJBUG札幌の発表資料です。
https://jbug.connpass.com/event/311440/
Makky
May 30, 2024
Tweet
Share
More Decks by Makky
See All by Makky
システムベンダーからSaasスタートアップに転職! 働き方改革を実現して札幌に定着した話 #seb_sapporo
makky_tyuyan
0
57
技術コミュニティLT #JBUG札幌 の紹介 #JBUG #CNDS2024
makky_tyuyan
1
39
JBUG札幌 #13 仕事の"うまい"進め方をシェアしよう!
makky_tyuyan
0
120
テストプロセスで大事にしていること #jasstnano
makky_tyuyan
0
270
#jiraMeetup 課題管理ツールを使いこなす!抑えておきたい5つのTips.pdf
makky_tyuyan
0
51
#JBUG札幌 プロジェクトテーマパークでチームビルディングを学ぼう
makky_tyuyan
0
210
QAエンジニアに転職して得た体験とこれから #GWD_Nulab
makky_tyuyan
0
110
#JiraMeetup プロジェクトの全体像を把握しよう!ダッシュボードのすゝめ
makky_tyuyan
0
320
JBUG札幌 10回 #JBUG札幌 #Backlogボドゲ
makky_tyuyan
0
97
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
363
22k
Fontdeck: Realign not Redesign
paulrobertlloyd
80
5.1k
Building a Scalable Design System with Sketch
lauravandoore
458
32k
Navigating Team Friction
lara
183
13k
Music & Morning Musume
bryan
46
6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
354
29k
Building Flexible Design Systems
yeseniaperezcruz
324
37k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
27
8.9k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
103
47k
The Illustrated Children's Guide to Kubernetes
chrisshort
46
48k
A better future with KSS
kneath
235
17k
Transcript
Backlogでプロジェクトマネジメントの基礎を抑えよう! 〜フリープランの活用方法〜 テックタッチ株式会社 QAエンジニア Michiya Maki JBUG札幌 #13
自己紹介 焼き鳥が焼ける QAエンジニア 巻 宙弥(まき みちや) プログラマ→システムエンジニア→マネージャ→ITコンサルタント 昨年、スタートアップのテックタッチ(株)にQAエンジニアとして転職 michiya.maki.1 makky_tyuyan 昨年から自分で串打ちして焼く「おうちやきとり」にハマってます。 #札幌串打同盟
マイブーム 北海道札幌からフルリモートで勤務中
None
None
None
None
None
Backlogでプロジェクトマネジメントするために 抑えておきたい3つの基礎 課題を構造化する 文章の客観性を保つ リスクを見分ける
課題を構造化する
課題を構造化しよう
課題を構造化しよう ゴールからつくる あきらかな問題からつくる 結論からつくる
そのまえに
課題ってなに?
問題 現状 目指す 状態 課題 課題とは ギャップ 打ち手 目指す状態と現状のギャップが問題、問題を解決するための取り組みが課題 注)絶対にこの考えが正しい!と主張するものではありません
課題を構造化しよう ゴールからつくる あきらかな問題からつくる 結論からつくる
ゴールからつくる ゴール 小さなゴール 小さなゴール もっと小さなゴール 施策 施策 施策
あきらかな問題からつくる 問題 要因・原因 要因・原因 要因・原因 要因・原因 要因・原因 要因・原因
結論からつくる 結論 小さな結論 小さな結論 小さな結論 根拠 根拠 根拠
結論 小さな結論 小さな結論 根拠 根拠 根拠 問題 要因・原因 要因・原因 要因・原因
要因・原因 要因・原因 ゴール 小ゴール 小ゴール 施策 施策 施策 論点が混ざらないように注意する
課題 背景 Backlogでわかりやすく表現する それがなに? なぜ? 親課題 子課題 TODO
課題 背景 Backlogでわかりやすく表現する それがなに? なぜ? 親課題 子課題 TODO フリープランだと使えない
シンプルにまとめる ### 概要 ◆◆◆◆◆(要約を載せる) ### 解決したい課題 本来◯◯◯だが、XXXなので□□□としたい ### 具体的なアクション -
[ ] ••までに▲▲を行う - [ ] ••までに▲▲を行う
要約はAIにサポートしてもらう フリープランで使える!
文章の客観性を保つ
客観性ってなに?
客観性とは 客観性(Objective)とは 個人の感情、偏見、主観的な意見を排除して、事象を公平かつ中立的に観察、評価、分析す ること。客観性を保つことは、科学的研究、ジャーナリズム、ビジネス意思決定など多くの 分野で重要視されます。 逆に、 、 、客観性の対義語は主観性(Subjective)です。 主観性は、個人の経験、感情、信念、好みに基づいて物事を捉えることを指します。 主観的な見解は、個々の人に特有であり、他の人と考えを共有するのは難しいとされます。
主観 共感 客観 わたし あなた ほかの誰か 客観性のイメージ
主観 共感 客観 わたし あなた ほかの誰か 客観性を保つために重要な4つの問い 事実と意見の区別 (ほんとのこと? 思っていること?) 客観的な分析では、確かな証拠やデータに基づいた事実と、
それに対する個人的な解釈や意見を明確に区別する必要があります。 証拠の確認 (どうしてそう思うの?) 提示された情報やデータが正確で信頼性のあるソースから得られたものであること を確認します。 複数の視点の検討 (いろんな人の考えが元になっているの?) 一つの視点だけに依存せず、異なる視点や意見を考慮に入れることで、より全面的 な理解を目指します。 透明性と開放性 (いつでも誰でもわかる状態になってる?) 判断や分析のプロセスを透明に保ち、批判的なレビューや他者の意見を受け入れる ことで、偏見の可能性を低減します。
文章をわかりやすくする
わかりやすい文章を書くための2つのコツ 単語の難易度を下げる 接続詞や接続助詞に頼らない
人間が短期的に記憶できる量はある一定のキャパしかない。 長い文章を読むにつれて難しい単語やわかりづらい単語、知ら ない単語が多いと把握しきれず読み直すことになる。 単語の難易度を下げる 難しい単語 わかりづらい単語 知らない単語 難しい単語 わかりづらい単語 知らない単語
知 ら な い 単 語 ※人間が瞬間的に保持できる情報の数は「7±2」であるとするもの。 アメリカのハーバード大学の心理学者、ジョージ・ミラー教授(George Armitage Miller)による1956年の論文「The Magical number seven, plus or minus two」で登場 ※ 未知語 (あまり知られていない単語) 曖昧語 (意味がハッキリしない単語) 難解語 (理解しにくい単語)
接続詞や接続助詞に頼らない ※ 転換(しかし、だが) 、因果(だから) 、選択(または) 、条件(なら)等の接続詞を乱用しない。 複文になりやすい、逆説(が) 、理由(ので) 、逆接(けれども) 、並列(と)を乱用しない。
例) 原因・理由を表す複文 「彼は疲れていたので、早く家に帰りました。 」 ※「彼は疲れていたので」が理由を表し、 「早く家に帰りました」が主文です。 対比を表す複文 「外は寒いけれども、部屋の中は暖かい。 」 ※「外は寒いけれども」が対比を表し、 「部屋の中は暖かい」が主文です。 結果を表す複文 「一生懸命勉強したので、試験で良い成績を取ることができた。 」 ※「一生懸命勉強したので」が理由を表し、 「試験で良い成績を取ることができた」が主文です。
リスクを見分ける
リスクの種類 プロジェクトリスク プロダクトリスク
プロジェクトリスクとは プロジェクトのマネジメントや統制に関連するものである。 プロジェクトリスクには、以下のようなものがある: ⚫ 組織的な問題(作業成果物の納期遅れ、不正確な見積り、コストダウンなど) ⚫ 人の問題(例:スキル不足、対立、コミュニケーションの問題、人手不足など) ⚫ 技術的な問題(スコープクリープ、ツールサポートの不備など) ⚫
サプライヤーの問題(例:第三者による納品の失敗、サポート企業の倒産など) プロジェクトリスクは、顕在化した場合、プロジェクトのスケジュール、予算、スコー プに影響を与え、プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf
プロジェクトリスクとは プロジェクトのマネジメントや統制に関連するものである。 プロジェクトリスクには、以下のようなものがある: ⚫ 組織的な問題(作業成果物の納期遅れ、不正確な見積り、コストダウンなど) ⚫ 人の問題(例:スキル不足、対立、コミュニケーションの問題、人手不足など) ⚫ 技術的な問題(スコープクリープ、ツールサポートの不備など) ⚫
サプライヤーの問題(例:第三者による納品の失敗、サポート企業の倒産など) プロジェクトリスクは、顕在化した場合、プロジェクトのスケジュール、予算、スコー プに影響を与え、プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf スプリントの機能開発が予定通りに進まず リリースサイクルに影響を及ぼすもの全てを指す
プロダクトリスクとは プロダクトの品質特性(例えば、ISO 25010 品質モデルに記述がある)に関連するもの である。プロダクトリスクの例としては、機能の不足や誤り、誤った計算、ランタイム エラー、貧弱なアーキテクチャー、非効率なアルゴリズム、不十分な応答時間、貧弱な ユーザーエクスペリエン ス、セキュリティの脆弱性などが挙げられる。プロダクトリス クが顕在化した場合、以下のようなさまざまな負の結果をもたらす可能性がある: ⚫
ユーザーの不満足 ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf
プロダクトリスクとは プロダクトの品質特性(例えば、ISO 25010 品質モデルに記述がある)に関連するもの である。プロダクトリスクの例としては、機能の不足や誤り、誤った計算、ランタイム エラー、貧弱なアーキテクチャー、非効率なアルゴリズム、不十分な応答時間、貧弱な ユーザーエクスペリエン ス、セキュリティの脆弱性などが挙げられる。プロダクトリス クが顕在化した場合、以下のようなさまざまな負の結果をもたらす可能性がある: ⚫
ユーザーの不満足 ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf プロダクトの設計・機能・仕様に関連し プロダクトそのものの評価に影響を及ぼすもの
「何が課題なのか?」 プロジェクトリスク プロダクトリスク どっちに対処?
デモ
ご清聴ありがとうございました ご清聴ありがとうございました