全11859文字
PR

 実践編の第1回と第2回でプロジェクトの「企画」と「初期計画」におけるポイントを解説してきた。実践編の第3回ではプロジェクトを運営していく際に開催する5つの「定期イベント」について解説する。

 具体的には、「イテレーションの作業計画作成」「1日の作業計画作成」「ステークホルダーへの進捗報告」「振り返り」「作業計画の見直し」で、この5つの定期イベントを回していく。この方法はアジャイル開発手法の1つである「スクラム(Scrum)」と同じであり、本記事ではスクラムの用語を使って解説する。

 大切なのはそれぞれの定期イベントの目的や趣旨についてステークホルダー間の認識を合わせておくことだ。そのことが、各イテレーション(1サイクルの開発期間。スクラムでは「スプリント」とも呼ぶが、本記事では「イテレーション」とする)、ひいてはプロジェクト全体が誤った方向に進むことを防ぎ、無駄な作業を減らした効率的な運営につながる。それでは定期イベントごとに実践ポイントを見ていこう。

定期イベントその1:スプリントプランニング(イテレーションの作業計画作成)

 実際にイテレーションに取り組むには、実践編第2回で説明した「プロダクト・バックログ・アイテム(PBI)」を、各イテレーションで実行するタスクである「スプリント・バックログ・アイテム(SBI)」に分解する作業が必要となる。イテレーションの最初にPBIをSBIに分解する作業が「スプリントプランニング」である。その際のポイントは4つある。

ポイント1:工数は「人日」で見積もる

 スプリントプランニングでは、開発内容を把握して開発メンバーを取りまとめる開発リーダーが、PBIをSBIに分解し、担当者を決め、作業工数を見積もる。この際、「人日」という絶対的尺度で見積もる。

 実践編第2回ではユーザーストーリーの規模を工数ではなく、難度という相対的尺度で見積もると説明したが、ここで見積もる方法が変わるので注意したい。誰が担当するのかに基づき、SBIの工数を決定していく。人日という絶対的尺度で見積もることで、タスクの進捗状況を分かりやすくし、マネジメント層にも報告しやすく、理解してもらいやすくなる。

 SBIの工数見積もりでは、1日の作業時間を6時間程度とする。突発的な打ち合わせやプロジェクトメンバーとのコミュニケーション、休憩などに使う時間をしっかり除いておくことが重要だ。

 こうした時間は考慮されにくく、コストを重視するプロジェクトではなおざりにされやすいうえ、開発メンバーからは「控除してほしい」とは言い出しにくい。プロダクトオーナー(PO)などプロジェクトの責任を負う立場の人が率先して考慮したい点である。

 さらに、PO、または多忙なPOを支援して調整役やリーダー役を担う代理プロダクトオーナー(PPO)は、開発リーダーと開発メンバーの間での工数見積もりの「感覚」が合っているかを確認したい。SBIの工数を見積もるのは前述の通り開発リーダーである。開発リーダーは往々にして遅延を気にして保守的になり、多めの工数を積みがちだ。

 一方の開発メンバーは自分の力量やタスクの難易度に比べて楽観的な工数を見積もりがちである。例えば1つのSBIの作業に開発リーダーが「3人日かかる」と見積もっても、POやPPOが「そこまでかからないだろう」と担当の開発メンバーに直接確認してみると、「1人日ぐらいでできる」という回答を得るようなケースはよくある。

 POは「リーダーの見積もり過剰」なのか「メンバーが楽観的過ぎる」のかをよく見極め、見積もり過剰ならば全体的に工数を見直すよう開発リーダーに指示する必要がある。

ポイント2:SBIを担当者に「コミット」させる

 SBIに担当者を決め、工数を見積もるという方法が、「教科書」に合っていないのではないかと感じる読者もいるだろう。教科書的には、1イテレーション(2週間)分の全SBIを付箋などに書いて「カンバン」に貼り付け、開発メンバーは早い者順で優先順位の高いSBIから消化していくという方法を推奨している。