プロジェクト・マネジャーが知るべき97のこと/「完了」をどう定義するか

『プロジェクト・マネジャーが知るべき97のこと』(オライリー・ジャパン、2011年)を出典とする。

成功が何を意味するのか明確な定義がなければ、ソフトウェア開発チームが成功するのは困難です。開発者にとっての成功には、顧客の期待を満たす製品を納品することが必要です。しかし、プロジェクト全体の成功を定義するためには、「プロジェクトを完了する」ことが何を意味するのか、正確な定義がより大きなプロジェクトチームで共有される必要があります。

プロジェクト全体のスコープをとらえるため、反復型ソフトウェア開発で中心となっている信条が「分割統治」です。プロジェクトは複数の成果物に分割され、それらはさらに作業パッケージに分割されます。そして最終的に、各個人にアサインされるアクティビティへと分割されます。

1 週間から数週間のイテレーションや作業期間を設けるアジャイルなアプローチを使うと、プロジェクト全体のスコープについて考える必要性を隠すことができます。1 つのイテレーション目標を完了するということは、ユニットテストをパスし、可能ならインテグレーションテストを一部クリアし、実現すると約束したフィーチャーが実際に動作するソフトウェアを作って、ステークホルダーの承認とフィードバックを得るということであると明確に定義できます。

ここで問題になるのは、マクロレベルにおけるコードとそれに付随するテスト以外にも、プロジェクトレベルではたくさん検討すべきことがあることです。従来のウォーターフォール開発の場合、テストはプロジェクトの最後に追いやられてしまい、それがプロセス上の弱点になっていました。アジャイルなアプローチの場合、開発者はプログラミングとは関係ないアイテムやアクティビティをすべて、ソフトウェアプロジェクトには必要ないと考えて、間違って保留したり却下するおそれがあります。

これらの中には、新しく作られたコンポーネント/ フィーチャーと以前のイテレーションで作られたコンポーネント/ フィーチャー間のユニットテストやインテグレーションテストも含まれているかもしれません。こうしたインテグレーションは見落とされがちですが、開発チームにとって根本的な問題を浮き彫りにしてくれます。ソフトウェアの複雑さはコンポーネントの相互接続数に比例します。デモ環境を作り上げるのに必要な時間を無視してはいけません。ユーザーレベル/ 受け入れテストスクリプトを書いて、付属ドキュメントを書きましょう。どんなに軽量な開発手法であっても、出荷可能なソフトウェアには、ある程度のドキュメントが必要になります。

こうしたアイテムを無視しないようにすると、「完了」が意味するマクロな定義は、各イテレーションのフィーチャーセットの完了を積み重ねたものとはかなり違うものになります。そして、イテレーションごとに不足しているアイテムの積み重ねから作られた差分こそが、フィーチャーの実装方法、テスト方法、顧客のとらえ方を変えるのです。

管理上の問題やビジネス上の問題で、開発者に過度の負担をかけないようにしましょう。私たちが広めなくてはならない基本的な考え方は、イテレーションはソフトウェア開発者だけのためにあるわけではないということです。イテレーションは、もっと広範囲の一般的なプロジェクトメンバーの重要なタスクと連携していなければなりません。ビジネスアナリスト、プロジェクト・マネジャー、テスターは、自分たちのアクティビティと開発者のアクティビティをうまく調整しなければなりません。

こうした調整に責任を持つ人、それがプロジェクト・マネジャーです。プロジェクト・マネジャーはマクロレベルにおける完了が意味するのか、全体的な定義を理解し、広めなくてはなりません。そして、毎週のイテレーション作業と協調して、コードに無関係なアクティビティも実行しなくてはなりません。「完了」が本当に意味するところを定義するため、プロジェクト・マネジャーは開発チームとほかのステークホルダーたちの間の調停役を果たさなければならないのです。