• 戻る
  • PMP：PDU
    • PMセミナー
    • PMプラクティス
    • PMコンピテンシー
    • アジャイル関連（本ページ）
    • 組織的PM（OPM）

• PMPで言う適応型のライフサイクル区分（PMP：共通 の該当節）

• 採用プロジェクト比率が年々増加している...何故か？

  • ビジネス領域の変化

    • ニーズの変化が早いビジネス領域
    • ニーズの不確実性が高いビジネス領域

  • ITに対する期待の領域が広がってきている
    （→ DX：企業がITを利用して事業の業績や対象範囲を根底から変化させる）。

    • 顧客獲得
    • 売上の増加
    • 満足度向上

  • システム開発の効率化、スピード化を推進

• 特徴・比較

• アジャイルソフトウェア開発宣言
  http://agilemanifesto.org/iso/ja/manifesto.html

• アジャイル宣言の背後にある原則
  http://agilemanifesto.org/iso/ja/principles.html

• ユーザのニーズ・要求からの乖離
• 完全なプロジェクトの失敗
• リリース（移行）の失敗
• 作業未習熟に起因する失敗
• 過剰な機能の盛り込み

Evo、DSDM、XP、FDD、Lean Software Development、
Crystal Clear、EssUp、Kanbanなどがあるが、
最もメジャーなアジャイル開発手法がScrum（58%）。

• スクラム・チーム

  • プロダクト・オーナー(PO)：１人
    開発の方向性を定め、プロダクトの価値を最大化することに責任を持つ。

  • スクラム・マスター：１人

    • スクラムチームのリーダーでスクラムの進行役
    • 開発チームが合意したプロセスを確実に実行するよう支援

  • 開発チーム：３-８人
    デザイナー、ライター、プログラマーなど作業を行う人々から成るチーム

• 一連の開発作業

  • プロダクト・バックログ

    • プロダクト・オーナーが作成・管理
      PBIリストを優先順に並び替える。

    • プロダクト・バックログ・アイテム（PBI）
      ・実現したいこと
      　(1) 顧客として
      　(2) 達成したいこと
      　(3) その理由
      ・受け入れ条件
      　・成果物（ソース、ドキュメント）
      　・デモと手順
      　・非機能要件
      　・完成の度合
      ・プランニング・ポーカーによるPBIの見積り
      　・基準となるPBIのポイントを決める。
      　・各PBIのポイントを基準から相対的に決める。

  • スプリント
    10営業日（二週間）に4つのスクラム・イベントが定義されている。

    • スプリント計画ミーティング（初日）
      ・チームのタイムボックス、ベロシティ（処理能力的な）の設定。
      ・PBIからスプリント・バックログ（SBL）を仮決め。
      ・SBLの実現に必要なタスク（とその時間）をタスクボードに並べる。

    • デイリー・スクラム（朝会）
      ・タスクボードのToDo、Doing、問題などの説明。
      ・バーンダウン・チャートで予実（日毎に残タスクの作業量）を確認。

    • スプリント・レビュー（最終日の最初）
      SBL（PBI）の現物デモとOK・NGの判断

    • スプリント・レトロスペクティブ（最終日の最後）
      Keep・Problem・Try（KPT） → 優先順にActionを設定。 ・継続すること（Keep） ・解決すること（Problem） ・上記の双方を受けて、新規にチャレンジすること（Try）

    • プロダクト・バックログ・リファインメント（最終日の最後）
      プロダクト・バックログのPBIの追加、変更（優先順位、ポイント）、削除

• The Scrum Guide
  https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

• スコープ、スケジュール、コスト、品質について、

  • ウォーターフォール開発は「コスト」変動、その他は固定
    SoR開発案件を請負、準委任で契約する場合

  • アジャイル開発は「スコープ」変動、その他は固定
    順次リリースするSoE開発案件を準委任、派遣で契約する場合（もしくは内製）

• リスク検討チェックシートの活用

  • カテゴリ
  • 判断項目
  • 重要度
  • ウォーターフォールが適する
  • アジャイルが適する。

見積・進捗・品質

• ベロシティ（処理能力的な）が見積・進捗に影響。

  • 故にベロシティに幅を持たせておく。
  • 80％ ～ 100％ ～ 120％のパターン

• 見積

  • 工数

    • PBIのポイント
    • チームのベロシティ
    • バーンダウン・チャート
      （ポイント・ベロシティの再見積）

  • スコープ

    • 予算 / 単位スプリントあたりの費用 = 実行可能なスプリント回数
    • 実行可能なスプリント回数で消化できるPBIがスコープ

• 進捗

  • リリース・バーンダウン・チャート
    予実（スプリント毎にプロダクト・バックログの残ポイント量）を確認。

• 品質

  • ソーシャルコーディング や ペアプログラミング
  • テスト自動化、CI / CD、DevOpsを可能な限り自動化
  • リリース・スプリント（リリース専用スプリント）を設ける。
  • テスタ（QAなど）によるテスト（探針テスト）を行う。

主に上司の介入

• 自己組織化の妨げ

  • 上司が決定する
  • 開発チームの決定を上司が覆す

• 上司に依る

  • タスクの割り当て
  • メンバの能力を定量化・可視化

※ アジャイルは上司の介入がなくてもワークする。
※ 従って、上司は進捗を妨げる障害を除去する方が良い。
※ （全体最適化しないため）個人ではなくチームとして評価。
※ どうしてもと言うならメンバとして上司が参画する（のはOK）。

• PBIのINVEST

  • Independent
    依存関係がなく独立している。

  • Negotiable
    手段については交渉可能である。

  • Valuable
    そもそも顧客にとって価値がある。

  • Estimatable
    見積もり可能である。

  • Small (Size Right)
    １スプリントで完了できるサイズ

  • Testable
    テストのチェック条件・確認項目が設定可能

• インセプションデッキ

  • アジャイルにおけるプロジェクト憲章

  • 以下の10個の質問についてチームで話し合う

    1. 我々はなぜここにいるのか
    2. エレベータピッチ
    3. パッケージデザイン
    4. やらないことリスト
    5. プロジェクトのコミュニティ
    6. 技術的な解決策の概要
    7. 夜も眠れなくなるような問題
    8. 期限を見極める
    9. トレードオフ・スライダー
    10. 初回リリースに必要なもの

リーン

• カンバン

• アジャイル

  • DSDM
  • XP
  • FDD
  • ASD
  • スクラム
  • スクラムバン
  • クリスタル

参考：PMP > 歴史（PMP の該当節）

• 予測型
  ウォーターフォール（PMP：共通 の該当節）

• 反復型、漸進型
  スパイラル（PMP：共通 の該当節）

• 適応型

  • リーン
    トヨタ生産方式を手本に７つの無駄を削除

  • カンバン
    現場の可視化のためにカンバンを利用（以下のリスト）

    • ユーザー・ストーリー
    • カンバン
      ・作業待
      ・作業中
      ・テスト中
      ・完了

  • DSDM
    ステークホルダーに焦点を当てる方法

  • XP

    • 変化を抱擁（顧客第一、変更の予定）
    • 開発のベストプラクティス（ペアプロ、TDD等）
    • 開発サイクルを反復（タイムボックス、イテレーション）

  • FDD
    成果物をユーザ視点でモデル化する手法

    • 機能単位で開発（２週間単位の規模）
    • Domain Object Modeling（DOM）の採用

  • スクラム
    マネジメントのフレームワーク

• 新しいPMのリーダーシップ・スタイル、革命

• 革命（チェンジ：何を → どうやって → 何に）

  • マーケティング、コミュニティ、問題領域の発見、しがみつく（？）
  • 仲間を作る、成功させる、結果を宣伝する、チーム評価
  • 上位マネジメント、中間管理職、PMO、施設、財務、調達

• ビジネス・ケース作成

  • ポイント

    • 専門家の知恵を借りる
    • 投資効果の明確化
      財務指標：ROI、NPV、PP、IRR

  • 手順

    • ビジョン記述 → ビジネス提案
    • 財務的ビジネス・ケース（ROI、NPV、PP、IRR）
    • 組織的影響（抵抗と克服、リスクの対応）

• ポイント

  • 手法の選択
  • 小さくか、ビッグバンか
  • 公にするかどうか
  • トレーニング、コーチング
  • リーダーシップ（サーバント・リーダーシップ）
  • エンジニアリングの実務（現場の声）

• 大規模化
  規模に関する４テーマ

  • 組織

    • プロダクト・オーナー（PO）
    • 複数チーム（専任/兼務、統合/分散、PMO）
    • 経験と知識の共有（ナレッジ（KM,KB）、コミュニケーション）

  • プロダクト・バックログ

    • 大きさ
      プロダクト → エピック → フィーチャー → ユーザー・ストーリー → タスク
    • 作業分担
      プロダクト → ユーザー・ストーリー → タスク（スプリント・バックログ）

  • プロジェクト・マネジメント
    協業のための、

    • 行動規範
    • 横断的コーディネーション（調整業務）
    • 報告内容の統一、共通言語＆用語
    • 作業時間ルール（コミュニケーション、コーディネーション）
    • スクラムのスクラム（SoS）、ベロシティ（処理能力的な）、チーム間依存関係

  • プロセス

    • リリース（単位の？）のキックオフ（３ヶ月計画）
    • イテレーション計画（POとチームで策定）
    • タスク・ボード（カンバン）
    • 総合テスト（リリース列車）
    • プロダクト・レビュー
    • レトロスペクティブ

発注側と受注側の契約

• 日本

  • 発注側と受注側で評価基準が異なる。
  • 請負、準委任、派遣などの形態。

• 形態

  • 協業

    • 成果物を顧客が評価
    • 評価結果から計画策定
    • 追加要求は次イテレーション

  • 柔軟性

    • 変更要求 ≒ フィーチャー
    • スコープは可変（初期スコープ ～ 最終スコープ）
    • 環境変化に依ってスケジューリングする

  • 増分開発

    • イテレーション毎の納品
    • 増分（や変更）がなくなったらPJ終了
    • （スコープの）コスト総額は事前に見積もれない。

• 異文化圏
  契約をリスクと捉える。

  • 暗黙知を100%の形式知へ

  • 見積もりには不確実性のコーンがある事を認識する。

    • 見積もり前提条件の変化の可能性
    • 発注のために低く見積もる傾向
    • 受注のために高く見積もる傾向
    • コンペでは低く見積もる傾向

  • コミュニケーション・リスク

    • 送信者・受信者モデル（送信者・受信者の責任）
    • 顧客の真の要求を引出し理解する。

• フレームワーク

  • ６つのプリンシプル

    • 価値による優先順位
      事業価値、狩野分析、ユーザ・ストーリーに疑似紙幣を分配

    • 協業
      明瞭、気付き、充当

    • タイムボックス
      ・スプリント計画
      ・スタンドアップ会議、スプリント
      ・レビュー、レトロスペクティブ

    • 反復開発
      立ち上げ → スプリントｎ → リリース（増分開発）

    • 自己組織化
      自律型チームの構成（オーナーシップ）
      ・リーダーシップ・スタイル（PMP：役割 の該当節、サーバント・リーダーシップ）
      ・コンフリクト・マネジメント（PMP：共通 の該当節）
      ・タックマン・モデル（PMP：チーム・マネジメント の該当節）
      ・マズローの欲求５段階説（PMP：チーム・マネジメント の該当節）
      ・マクレガーのXY理論（PMP：チーム・マネジメント の該当節）

    • 経験を積み重ねるプロセス管理
      透明性、検査、適応（プロセス改善）

  • ５つの視点

    • 組織
      ・プロダクト・オーナー（プロダクト・バックログの定義）
      ・スクラム・マスター（サーバント・リーダーシップ）
      ・スクラム・チーム（プロジェクト成果物の作成）

    • ビジネス正当性
      ・ビジネス・ケース
      ・アーンド・バリュー（EV）
      ・累積フロー図（CFD）
      ・その他の決定要素
      ・価値駆動型開発

    • 品質
      ・定義（ビジネス価値、スコープ、性能、機能、バグ）
      ・受け入れ基準（ユーザ・ストーリー毎に妥当性確認）
      ・計画、実行、監視・制御
      ・PDCA → PDSA（CheckからStudyに）

    • 変更
      ・積極的対応（変更要求 ≒ フィーチャー、スプリントへ）
      ・柔軟性と安定性（スプリント・バックログを固定化）のバランス

    • リスク
      ・脅威と好機（PMP：試験 - 計画 の該当節）への継続的対応
      　（好機の重要度が高い）
      ・リスク態度（PMP：計画 - リスク の該当節、ステークホルダー分析）
      ・リスク・マネジメント
      　・通常のリスク・マネジメント（PMP：共通 の該当節）
      　・プロダクト・バックログに入れ、
      　　リスク・バーンダウン・チャートで管理

  • ５フェーズ・１９プロセス
    ココの内容は入門 > 手法（スクラム）に近い。

    • 立ち上げ
      ・プロジェクト・ビジョン作成
      ・スクラム・マスターとステークホルダー識別
      ・スクラム・チーム結成
      ・エピック開発（アプリから得られる体験的な）
      ・優先順位付きのプロダクト・バックログ作成
      ・リリース計画の主導

    • 計画と見積
      ・ユーザー・ストーリー作成
      ・見積を承認し、ユーザー・ストーリーをコミット
      ・タスク作成
      ・タスク見積
      ・スプリント・バックログ作成

    • 実行
      ・成果物の作成
      ・日次スタンドアップを主導（バーンダウン・チャート）
      ・優先順位付きプロダクト・バックログを遂行（グルーミング）

    • レビューと振り返り
      ・スクラムチームのスクラムを招集
      ・スプリントをデモ
      ・スプリントを振り返る（KPT）

    • リリース
      ・成果物を出荷する
      ・プロジェクトを振り返る

ロール	スプリント計画ミーティング（初日）	デイリー・スクラム（朝会）	スプリント・レビュー（最終日の最初）	スプリント・レトロスペクティブ（最終日の最後）	プロダクト・バックログ・リファインメント（最終日の最後）
ステーク・ホルダー	△	△	◯	△	△
プロダクト・オーナー(PO)	◎	△	◎	◎	◯
スクラム・マスター	◎	◎	◎	◎	◎
開発チーム	◎	◎	◎	◎	◎

着手可能な状態

• PO
  • 価値・必要性の説明
  • 受け入れ条件の説明

※ プロダクト・バックログ：ユーザー・ストーリー → タスク
　「Ｘ」（誰）が「Ｙ」と言う理由で「Ｚ」したい。

• スクラムマスタ

  • 必要なリソース類の準備

• 開発者

  • 見積もり

• ストーリー・ポイントを決定

• = ストーリー・ポイント / スプリント

• 初期ベロシティ

  • 過去実績
  • １回やる
  • 予想する

• PMBOK 7版の変更点（PMP：変更点 の該当節）

• SCRUM BOOT CAMP THE BOOK
• エッセンシャル スクラム

移行メモ

• 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
• PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
• 元 Wiki の赤字強調は太字にした。
• KPT の表は元 Wiki ではセル結合（~）を使っていたが、GitHub Wiki では セル結合を再現できないため、箇条書きに展開した。 スクラムのイベント参加者の表は、末尾の見出しセルが 「プロダクト・バックログ・リファインメント（最終日」で切れていたため、 本文の記載に合わせて「（最終日の最後）」と補った。
• 元 Wiki の「Redyな状態」→「Readyな状態」、「優先慎位付き」→「優先順位付き」、 「チーム感依存関係」→「チーム間依存関係」、「リクスの対応」→「リスクの対応」、 「価値駆動形開発」→「価値駆動型開発」に正した。 財務指標の「NPN」は「NPV（正味現在価値）」の誤記と判断し修正した。

---

Tags: 移行, 資格, PMP, PDU, アジャイル, スクラム, プロダクト・バックログ, スプリント, INVEST, カンバン, リーン