全1786文字
PR

 書籍『誰も教えてくれなかったアジャイル開発』(日経BP)では、ウオーターフォール型開発が主流の「日本企業」で試行錯誤しながらアジャイル開発を成功に導いてきたコンサルタントたちが、自らの経験を体系化している。本書から抜粋し、初期計画段階で重要になるポイントの2番目として「移行」「テスト」「運用準備」といった「通常タスク」の重要性について解説する。(技術プロダクツユニットクロスメディア編集部)

ポイント(2) 「通常タスク」を忘れない

 アジャイル開発では「開発」にチームの視線が集まるあまり、システム開発プロジェクトで必要とされる「通常タスク」を計画から見落としてしまうケースがある。通常タスクとは、例えば「移行」や「テスト」、「運用開始に向けた準備」などを指す。

抜けがちな通常タスクの例。通常タスクを漏らさない
抜けがちな通常タスクの例。通常タスクを漏らさない
(出所:シグマクシス)
[画像のクリックで拡大表示]

 具体的には、移行のタスクであれば「移行ツール作成」「移行リハーサル」、テストのタスクであれば「外部結合テスト」「システムテスト」、運用開始に向けた準備であれば「マニュアル作成」「ユーザー教育」などがある。いずれもシステム稼働には必須の作業だ。

 通常タスクを計画に入れ忘れてしまうと、バックログの優先順位やリソースの調整が後手となってしまい、多くの場合スケジュールが遅延する。それを防ぐには、ユーザーストーリーには新システムで実装する機能はもちろん、意識的に通常タスクも登録しておくことが欠かせない。

 移行タスクをユーザーストーリーに入れなかったために生じた失敗事例を紹介しよう。プロジェクト当初、PPO(代理プロダクトオーナー)や開発チームリーダーは移行の必要性を認識していて、マスタースケジュールでは大まかに移行タスクを計画に入れていた。

 だが、新規機能の開発に注目してしまい、移行タスクをユーザーストーリーに入れず、しかるべきタイミングで移行タスクの見積もりを精緻化しなかった。その結果、マスタースケジュール通りに移行タスクを開始したものの、移行タスクの工数だけでなく移行にかかる社内外との調整の工数も不足し、移行自体が間に合わず全体のリリースを遅らせる事態となった。

 このような状況を回避するためにも、プロジェクトの初期計画段階で、何はともあれ通常タスクをPBI(プロダクト・バックログ・アイテム)に入れて、さらに実施するタイミングのイテレーションに「固定」してしまうとよいだろう。

通常タスクを優先して設定した計画の例。通常タスクのスケジュールは先に決めてしまう
通常タスクを優先して設定した計画の例。通常タスクのスケジュールは先に決めてしまう
(出所:シグマクシス)
[画像のクリックで拡大表示]

 その後、イテレーションの空きスロットに機能開発に関するPBIを優先順位と照らし合わせてはめ込んでいく。後から通常タスクを加える場合も同じで、実施すべきタイミングのイテレーションにはめ込む。通常タスクを追加したことで、機能に関するPBIがベロシティー(1つのイテレーションで消化できるタスク数)を超えた場合は、優先順位に沿って後続のイテレーションで調整する。