５．プロジェクト終結

　5-1　プロジェクト終了状況の確認
　　511　プロジェクトの目的・目標の達成
　　512　計画書に記述された成果物の存在
　　513　成果物が要求仕様を満足する
　　514　プロジェクト完了基準を満たす
　　515　推進組織の全チームの作業完了
　　516　残項目を除く全問題点の解決
　　517　承認された変更要求の実施

　5-2　プロジェクト完了報告書の作成
　　521　実行要約の明確かつ完全な文書化
　　522　計画と完了時の差異原因の文書化
　　523　実施された変更の効果の文書化
　　524　残項目が明確である
　　525　残項目が引き継げる状態にある

　5-3　ユーザによる成果物検収に対する対応
　　531　ユーザ検収条件を満たす
　　532　全成果物の検収・承認
　　533　利用者・製品管理者への引き渡し

　5-4　プロジェクト完了報告と終結
　　541　評価関係者への完了状況の報告
　　542　評価関係者による完了の承認
　　543　評価関係者への終結の通知
　　544　有効な情報が共有情報として追加

コメント：
　ソフトウェアというのは、一般的な工業製品などと異なり、エンドユーザーの目に見えないものである。見えるのは画面や帳票といった入出力部分だけであり、処理機能そのものは通常ブラックボックスになっている。しかし、利用者の目に見えないから設計書は多少の不備があってもいい、ということにはならない。むしろ見えないからこそ可視化、すなわち見えるようにすべきだろう。どのような設計内容に対しどのようなレビューを行い、どのような手法でどのようなテストを行い、どのように品質を保証したのか。それらがわかる成果物を納品することが、プロジェクト終結の必須条件と言える。

Pman注目：
　512　計画書に記述された成果物の存在
　スキル基準には「プロジェクト計画書に記述されたすべての成果物が存在すること」と書かれている。ただし、計画書に記述するのは、例えば、詳細設計書、ソースプログラム、テスト項目表など成果物の種類だけであり、それぞれの種類について、機能単位あるいはモジュール単位の成果物がなくてはならない。私は以前、あるプロジェクトの結合テスト工程が終わりに近づき、成果物の確認をしたところ、１機能におけるテスト成果物が見つからず、青ざめたことがあった。信じられないことだが、進捗表から漏れていたため、テストされていなかったのである。幸いにして、空き要員を割り当てて集中的にテストできたため事なきを得たが、思わぬところに落とし穴があるものだ。
　スキル基準の解説も、次回でいよいよ最終回となる。長かった・・。

　次回予定→　６．プロジェクト完了評価