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

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

Makky
May 30, 2024
140

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

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

Makky

May 30, 2024
Tweet

More Decks by Makky

Transcript

  1. 結論 小さな結論 小さな結論 根拠 根拠 根拠 問題 要因・原因 要因・原因 要因・原因

    要因・原因 要因・原因 ゴール 小ゴール 小ゴール 施策 施策 施策 論点が混ざらないように注意する
  2. 主観 共感 客観 わたし あなた ほかの誰か 客観性を保つために重要な4つの問い 事実と意見の区別  (ほんとのこと? 思っていること?) 客観的な分析では、確かな証拠やデータに基づいた事実と、

    それに対する個人的な解釈や意見を明確に区別する必要があります。 証拠の確認  (どうしてそう思うの?) 提示された情報やデータが正確で信頼性のあるソースから得られたものであること を確認します。 複数の視点の検討  (いろんな人の考えが元になっているの?) 一つの視点だけに依存せず、異なる視点や意見を考慮に入れることで、より全面的 な理解を目指します。 透明性と開放性  (いつでも誰でもわかる状態になってる?) 判断や分析のプロセスを透明に保ち、批判的なレビューや他者の意見を受け入れる ことで、偏見の可能性を低減します。
  3. 人間が短期的に記憶できる量はある一定のキャパしかない。 長い文章を読むにつれて難しい単語やわかりづらい単語、知ら ない単語が多いと把握しきれず読み直すことになる。 単語の難易度を下げる 難しい単語 わかりづらい単語 知らない単語 難しい単語 わかりづらい単語 知らない単語

    知 ら な い 単 語 ※人間が瞬間的に保持できる情報の数は「7±2」であるとするもの。 アメリカのハーバード大学の心理学者、ジョージ・ミラー教授(George Armitage Miller)による1956年の論文「The Magical number seven, plus or minus two」で登場 ※ 未知語 (あまり知られていない単語) 曖昧語 (意味がハッキリしない単語) 難解語 (理解しにくい単語)
  4. 接続詞や接続助詞に頼らない ※ 転換(しかし、だが) 、因果(だから) 、選択(または) 、条件(なら)等の接続詞を乱用しない。 複文になりやすい、逆説(が) 、理由(ので) 、逆接(けれども) 、並列(と)を乱用しない。

    例) 原因・理由を表す複文 「彼は疲れていたので、早く家に帰りました。 」 ※「彼は疲れていたので」が理由を表し、 「早く家に帰りました」が主文です。 対比を表す複文 「外は寒いけれども、部屋の中は暖かい。 」 ※「外は寒いけれども」が対比を表し、 「部屋の中は暖かい」が主文です。 結果を表す複文 「一生懸命勉強したので、試験で良い成績を取ることができた。 」 ※「一生懸命勉強したので」が理由を表し、 「試験で良い成績を取ることができた」が主文です。
  5. プロジェクトリスクとは プロジェクトのマネジメントや統制に関連するものである。 プロジェクトリスクには、以下のようなものがある: ⚫ 組織的な問題(作業成果物の納期遅れ、不正確な見積り、コストダウンなど) ⚫ 人の問題(例:スキル不足、対立、コミュニケーションの問題、人手不足など) ⚫ 技術的な問題(スコープクリープ、ツールサポートの不備など) ⚫

    サプライヤーの問題(例:第三者による納品の失敗、サポート企業の倒産など) プロジェクトリスクは、顕在化した場合、プロジェクトのスケジュール、予算、スコー プに影響を与え、プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf
  6. プロジェクトリスクとは プロジェクトのマネジメントや統制に関連するものである。 プロジェクトリスクには、以下のようなものがある: ⚫ 組織的な問題(作業成果物の納期遅れ、不正確な見積り、コストダウンなど) ⚫ 人の問題(例:スキル不足、対立、コミュニケーションの問題、人手不足など) ⚫ 技術的な問題(スコープクリープ、ツールサポートの不備など) ⚫

    サプライヤーの問題(例:第三者による納品の失敗、サポート企業の倒産など) プロジェクトリスクは、顕在化した場合、プロジェクトのスケジュール、予算、スコー プに影響を与え、プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf スプリントの機能開発が予定通りに進まず リリースサイクルに影響を及ぼすもの全てを指す
  7. プロダクトリスクとは プロダクトの品質特性(例えば、ISO 25010 品質モデルに記述がある)に関連するもの である。プロダクトリスクの例としては、機能の不足や誤り、誤った計算、ランタイム エラー、貧弱なアーキテクチャー、非効率なアルゴリズム、不十分な応答時間、貧弱な ユーザーエクスペリエン ス、セキュリティの脆弱性などが挙げられる。プロダクトリス クが顕在化した場合、以下のようなさまざまな負の結果をもたらす可能性がある: ⚫

    ユーザーの不満足 ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf プロダクトの設計・機能・仕様に関連し プロダクトそのものの評価に影響を及ぼすもの