プロジェクト・マネジャーが知るべき97のこと/成果物を効果的に管理する

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

プロジェクトはひとそろいの成果物で構成されます。それが完成すると、製品、サービス、成果すべてが完了することになります。ソフトウェア開発プロジェクトの場合、すべての構成要素を統合することは、適切に機能する最終成果実現のために極めて重要です。もちろん、あなたが作っているソフトウェアの種類によって、その構成要素も変わってきます。成果物は次のように、積極的に計画され、コントロールされ、監視され、管理されるべきです。

成果物を特定する

成果物を特定することで、ソリューション全体のアウトラインを示し、開発や納品されるべき順序を特定し、開発と納品を監視/コントロールするのに使うべきメトリックスを特定します。計画されたベースラインとメトリックスに対する進捗を、能動的にモニタリングしましょう。成果物を部分的なコードのかたまりに分割して、それぞれが特定のソフトウェア機能を提供するように作ることが非常に重要です。複雑なプロジェクト/ 環境であったり、サードパーティが開発するプロジェクトの場合、これは特に重要になります。最終的に完全な作業パッケージを受け取るまで、ただ待っているだけではいけません。プロジェクトを少しずつ納品するよう調整して、事前に計画されたプロセスにしたがって他のメンバーが開発に取りかかれるよう提供するとよいでしょう。

成果物を監視/コントロールする

作業パッケージ（機能単位のコード群）を構築し、監視し、コントロールする手段を定義したら、次に作業が計画通りに完了しているか確かめるために、能動的に構築フェーズを監視/ コントロールする必要があります。チェックポイント、メトリックス、KPI（KeyPerformance Indicator、重要業績評価指標）などがチームメンバー全員に共有されている必要があります。チェックポイントでは、その変動を特定するため、KPI やメトリックスを基準とトレンド分析に対して評価すべきです。これによって、直感や伝聞ではなく、実際のメトリックスに基づいた修正措置をとることができます。

成果物をうまく扱う。

想定していた作業ができ上がったら、コードをテストして完了したと判断する前に、一部のユーザーにそれを提供して、要件にしたがっているか確かめましょう。このやり方は問題を特定するのに役立ち、ソフトウェアがユーザー全体に提供される前に修正措置をとることができます。このアプローチで必要なことは、あらゆる小さな成果物を段階的に用意し、それらを順次まとめて（波が寄せるように）テストする必要があることです。もし、すべてのコードがそろうまで待ってしまうと、未知のエラーや欠陥、想定外の動作に満ちたコードを受け取ることになります。製品/ サービス/ 成果はこうした問題を抱えたまま作られていき、その影響は埋もれたまま増殖していきます。この時点になると、動かないコードをすべて修正するのにかかるコストと時間は非常に高くついてしまいます。あなたの会社の環境やベンダーの経験を考慮して、開発に必要とされる複雑さとのバランスをとりながら、このやり方があなたにとってうまくいくかどうか判断しましょう。一般的に、複雑なソリューションや新しい技術、ソリューションに対して、このやり方は非常に役立ちます。