ブログ始めました。運営者情報はこちら!click

「アジャイル開発」のキモ!プロダクトバックログの作り方【上級】

お悩み人

・最近よく聞く「アジャイル開発」ってなに…
・PMP試験にアジャイル頻出って聞いたんだけど…
・SEとしてキャリアアップ(転職・昇進)したいよ…

システム開発手法が「アジャイル型」に移ってきています。
転職サイトでも「アジャイル経験のある人」の記載も増えており、ニーズは高まるばかりです。
この記事では現役システムエンジニアが、アジャイル開発について簡潔に説明します。

この記事で分かること
  1. アジャイル開発におけるプロダクトバックログとは
  2. プロダクトバックログの作り方
筆者はこんな人
  • IT業界最大手のシステムエンジニア
  • システムの要件定義から運用、保守まで、一連の作業を経験
  • 数億円超プロジェクトのプロジェクトマネジメントを経験
  • 約70名の学生からOB訪問を受け、IT業界やシステムエンジニアについて説明実績あり

宜しくお願いします!

この記事について

アジャイル開発とは?

アジャイル開発は
「ニーズに柔軟に応えるために、小さく作って素早く提供し、改善を繰り返す」ことで
ビジネスの不確実性に対抗する(影響を少なくする)ことが最大のメリットです。

アジャイル開発はプロジェクトマネジメントの国際的な資格「PMP」の問題の主流になっています。
(正確にはウォーターフォール型とアジャイル型のハイブリッド開発が主流)

PMPの合格体験記を別記事に作成したので、よかったらご覧ください。

合格には「アジャイル実務ガイド」が必須です。
以降はアジャイル実務ガイドからピックアップした内容です。

中級編のおさらい

アジャイル開発の全体像

中級編ではアジャイル開発の全体像をご説明しました。

プロダクトバックログを起点として、システム(機能)を順繰り作成していくのがわかるかと思います。

プロダクトバックログとは

プロダクトバックログの例

プロダクトバックログとは、
プロダクトの開発・改善に必要なタスクが、優先順位が高い順に並べられた一覧です。

・プロダクトバックログはプロダクトオーナーが管理します。
・次のスプリント開始までに、次のスプリントまでに必要な分の更新が終わっていればOKです。

プロダクトバックログは明確に”こうやって作るもの”という定義はないです。

が、ある程度”型”があると作りやすいと思うので、
以降でプロダクトバックログの作成方法について紹介します。

Step1:プロダクトバックログ作成の事前準備

❶ゴールを決める

完成の定義(DoD:Definition of Done)」を設定します。

完成の定義:「○○という基準を満たしたら完成とする」といった内容が記述された定義のこと

「完成の定義」の作成者

作成者はプロダクトオーナー、スクラムマスター、PJチームメンバーの皆です。

「完成の定義」を設定するメリット

  • ゴールが明確になることで、システム(プロダクト)の方向性をチームで共有することができる
  • 方向性の共有により、行動の迷いや無駄な衝突を避け、チームの一体感が生まれる
  • 各開発者で品質のバラつきがある場合も指摘でき、結果としてプロダクトの品質が安定する

「完成の定義」の作成観点

例えば、「勤怠管理システムを刷新する」といった要件自体を「完成の定義」とすることもできますが、
以下の観点をもとに、より具体的に「完成の定義」を設定するとチームとして動きやすくなります

  • プロダクトバックログアイテムの完成の定義は何か?
  • スプリントを完了させる際の定義は何か?
  • リリース時に守るべきルールは何か?

上記3つの観点を意識して「完成の定義」を作成した際のイメージは以下のとおりです。

「完成の定義」のイメージ

❷プロダクトバックログに記載する内容を整理する

システム(プロダクト)を開発するにあたり要検討事項があります。

どのような顧客(ペルソナ)に、どのようなサービス(価値)を提供するか

この検討が甘いと、提供するシステムの価値が下がります
(=使っても意味ない、そもそも使ってもらえない)

ユーザーに提供する価値を整理する手法として
「ユーザーストーリーマップ」が有効です。

時間軸と優先度の観点で、ユーザーが
「システム(プロダクト)を通じてどんな価値を提供したいか」
を視覚化したものがユーザーストーリーマップです。

ユーザーストーリーマップ(勤怠情報システムの場合)

❸プロダクトバックログの管理方法を決める

プロダクトバックログの管理方法は大きく2つあります。

  • アナログ管理(例:ホワイトボードと付箋を使用)
  • デジタル管理(例:アプリ、ツールを使用)

現場で使いやすいのはアナログ管理ですが、
近年リモートワークが広まったことでデジタル管理で実践するのが良いです。

プロダクトバックログを作成するツールとしてよく利用されるものは以下3つです。

Jira

正式名称はJira Softwareで、
システムの作りがアジャイル開発用の仕様になっているのが特徴です。

カンバンボードやバーンダウンチャート等、
プロジェクトの状況の可視化に優れています。

Jiraで見るプロダクトバックログ
Jiraで見るカンバンボード

Microsoft Planner

Microsoft Plannerはアジャイル開発に特化したツールではありません
が、アジャイル開発でも利用されます。

特徴は以下のとおりです。

  1. 直感的に操作できる
  2. Microsoft 365利用者なら、すべての機能が無料で使える
  3. Officeアカウントの常時ログインで、利用ごとのログインが不要である
  4. Microsoft Teamsとの連携が可能である

TeamsとPlannerを連携しておくと、チーム内のワークフローや進捗状況を
各担当者と紐づけながら見ることができます。

PlannerとTeamsを連携した場合

個人的にはJiraよりPlannerがオススメです!
本当に便利!

【なぜアナログ管理が使いやすいのか】

プロダクトバックログはスプリント開始前にリファインメントを実施します。

・すでにプロダクトバックログに書いてあること詳細化する
・新たにプロダクトバックログに追加する

この作業は「ブレーンストーミング」に近く、
一般的に「ブレーンストーミング」はホワイトボードや付箋を使って実施するのが効率良いです。

アナログ管理のカンバンボード

Step2:プロダクトバックログの作成

❶プロダクトバックログを作成する

プロダクトバックログアイテムを書き出す

プロダクトバックログアイテムを書き出す

ユーザーストーリーマップを元にプロダクトバックログアイテムを書き出します。

この時に書き出した内容がタスクにならないように注意しましょう。

  • ユーザ登録機能を実装する
  • ログイン機能を実装する
  • サイトに訪れた人がアカウントを作成することができる
  • アカウント登録済みの人がログインすることができる

ユーザーストーリーに沿って書きましょう。
5W1Hによる整理だと思ってください。

プロダクトバックログアイテムを優先順に並び替える

プロダクトバックログアイテムに優先順位をつける

プロダクトバックログは、優先順位が高いものから順に並べます。

以下の観点で並べ替えると良いでしょう。

  1. 顧客、ユーザへの価値が高いものか?
  2. 早くリリースが必要なものか?
  3. コストを抑えられるか?

内容を詳細化する

プロダクトバックログアイテムを詳細化する

次にプロダクトバックログを詳細化します。

実際に作業できるレベルに詳細化するのは、
スプリントプランニングのタイミングで良いです。

ここではPJチームメンバーがスプリントプランニングで困らないよう、
ユーザーストーリーの内容をもとに「誰がどのような価値を得られるのか」を明確に
しましょう。

以下の観点で詳細化すると良いでしょう。

  • インプット
    どんな事前情報が必要か?
    例:ユーザ登録時に必要とする郵便番号や電話番号等の設計情報
  • アウトプット
    作成するものは何か?
    例:ユーザ登録画面のイメージ図

受け入れ基準を決める

受け入れ基準を決める

勤怠管理システムを例として、受け入れ基準を上記のように決めます。

作成したプロダクトバックログアイテムが「完成」されたかを判断する基準が必要です。

この基準はプロダクトオーナーが設定します。

ストーリーポイントを見積る

ストーリーポイントを見積る

最後に、PJチームメンバーが
プロダクトバックログアイテムのストーリーポイントを見積ります。

アジャイル開発では、規模・難易度の見積りするために時間ではなく「ストーリーポイント」を使用します。

時間で見積る場合:担当する人のスキルや開発速度により完了までの時間が異なる
ポイントで見積る場合:基準を設けることで、それよりも難しいか簡単かは誰でも見積れる

ストーリーポイントを活用するタイミングはイテレーションの終了時点です。

次回の達成能力(どれくらいプロダクトバックログアイテムを完了できるか)
を判断するために活用します。

❷プロダクトバックログがReadyの状態か確認する

ここまでで作成したプロダクトバックログは、
スプリントで実行できる状態になっているはずです。

これをプロダクトバックログがReadyである(=準備ができている状態)といいます。

いきなり全てのプロダクトバックログアイテムをReadyにする必要はありません。
少なくとも直近のスプリントで実施するプロダクトバックログアイテムをReadyにすればOKです。

ここまで来たら実際にスプリントで開発するのみ!

Step3:プロダクトバックログをリファインメントする

アジャイル開発ではスプリント終盤〜次回スプリント開始までに3つのイベントを実施します。

・スプリントレビュー
そのスプリントで作成した機能が受け入れ基準を満たしているかのチェック

・レトロスペクティブ
そのスプリントにおける各メンバーの行動から改善事項ををチェックし、次のスプリントまでに改善

・バックログリファインメント

次項でバックログリファインメントについてご説明します。

バックログリファインメントの実施

以下の2つの観点で実施しましょう。

  • プロダクトバックログアイテムの更新(追加/修正/分割/削除)
  • プロダクトバックログの優先順位の最新化

なお、「プロダクトバックログアイテムの分割」は、
粒度が大きすぎる場合に実施します。

プロダクトバックログアイテムの粒度が大きすぎると
スプリントで完了しない可能性があるからです

スプリントで完了しないと、

  • プロダクトオーナーがチームの再編を検討する時間が必要になる
  • メンバーのモチベーションが削がれる

のようにPJチームに悪影響を生むため、
プロダクトバックログアイテムの分割は重要なのです。

まとめ

今回はアジャイル開発の中核にを担う「プロダクトバックログの作り方」をご説明しました。

プロダクトバックログの質が、実際に出来上がる機能(システム)に大きく影響します。

最初からプロダクトバックログうまく作れなくても問題ありません。

リファインメントしてスプリントを重ねて品質向上させればALL OKです。

今回でアジャイル開発についての記事は終了です。

よりニッチな内容にニーズが出れば記事にしようと思います。

最後までご覧いただき、ありがとうございました。

この記事が気に入ったら
フォローしてね!

シェア頂けると嬉しいです!よろしくお願いします!
  • URLをコピーしました!

コメント

コメントする

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

この記事について