システム開発のポイント - バナオの奮闘記

前回に続いて、システム開発のポイントをまとめる。

前回の記事で、WBSの粒度を揃える必要があることを書いた。

更に、作業者が実施したタスクを管理者がレビューできる単位で分解する必要がある。

そのため、まず、タスクを成果物が存在する単位で分解する。

成果物がないと、管理者が作業者のタスクをレビューできないからだ。

作業者は成果物単位ではなく、自分の作業の節目単位でタスクを分解しがちだ。

もちろん、作業者が自身で作業しやすいように細かくタスクを分解するのは良い。

しかし、プロジェクトのWBS上では成果物が存在する単位で分解したほうが良い。

次に、タスクをレビュー可能な単位で分解する。

作業者と管理者のスキルの違いによっては、成果物があっても管理者がレビューできないことがある。

例えば、管理者のITスキルがそこまで高くなく、作業者は管理者が発注したITベンダーだとする。

この場合、開発されたコードの一つ一つを管理者がレビューすることは困難だ。

こういったケースにおけるレビューの方法としては、進捗状況の星取り表を成果物としてレビューを実施するというのがある。

APIや画面単位で星取り表をつくる。

そして、各APIや画面が完成したら、星をつけて、その表をレビューする。

各APIや画面のレビューはできないが、進捗状況は追える。

仕様通りに機能が開発されているかどうかは、ユーザーテストの段階でレビューする。

タスクを分解した後で、クリティカルパスを明確にしておく必要がある。

クリティカルパスというのは、「システム構築などのプロジェクトを進めるうえで、ネックとなる部分を指し、事実上プロジェクト全体のスケジュールを左右する作業の連なり」を指す。

具体的な手順としては、まず各タスクに番号を振る。

そして、各タスクのメモに、そのタスクの前に実施する必要があるタスクの番号を書く。

ここまでの作業で、タスクのつながりが明確化される。

最も期間が長くなるタスクのつながりが、クリティカルパスとなる。

クリティカルパスを明確化することで、タスクが遅延した場合でも、スケジュールを調整することができるようになる。

クリティカルパスではないタスクが遅延したら、クリティカルパスに影響が出ないように期限を設定し直す。

クリティカルパスのタスクが遅延した場合には、後続のタスクで巻き返せそうか、もしそれがムリなら、プロジェクト完了の後倒しが可能か検討する。

各タスクの工数見積もりにおいては、バッファを確保することが必須である。

各タスクが最短で終わる場合の工数と、最長でかかりうる工数を算出する。

そして、その二つの工数の平均値を、見積もり工数とする。

こうすれば、無理のない範囲で、バッファを確保できる。

もし、何か懸念されるリスクがあれば、そのリスクが発言した場合の対応工数もバッファとして積んでおく。