納期さえ守ればコストは普通守れます。だってそういう人員計画で進めているでしょ。「追加仕様があればお金をもらえる」ようなスキームを確立すれば、期間の中でマネジメントしていればコストがオーバーすることはないです。「納期を守る」は、実は「コストを守る」ことになります。
問題プロジェクトというのは、すべて品質に問題のあるプロジェクトです。先ほど示した「Q＞D＝C」とは、品質を守れば納期は守れる、納期を守ればコストも守れる、だから、プロジェクトマネジメントの優先順位は品質を一番に考えるべきだということを示しています。
往々にしてPMは内向きになります。PMを見ていて思うのは、苦手なことを放ったらかしにしておく人が多い。本来は自分が苦手でわからないところほど手厚く考えなくてはいけない。ところが、自分のやりたいところ、できるところばっかりやる。これではうまくいかない。
PMというのは、一番苦手でわからないところをやる人でなければならない。優先順位を間違えないようにしてほしいですね。自分でできなかったら違う人を使うしかない。（上司である）部長に依頼するとか、さらに上の本部長に依頼するとか。そうした上司をうまく使うのもPMの仕事です。「これは関係ない」「面倒くさい」と思うことをやるのがPMなのです。
要件定義が終了したときの品質を測定し、少なくとも顧客の要求品質を超えていると測定されたら、安心して工程を進めることができます。しかし、テストするまで品質はわからないとなると非常にリスクが高くなります。どうやって早くバグを見つけるかがポイントになります。PMBOKでは、「出てきた障害（バグ）をどうやって分析し、何が原因か突き止める」ということに力点を置いています。
２つめが「現行機能保証」です。ITプロジェクトでは、ほとんどの場合、現行で何か仕組みが動いています。それを作り替えるケースが非常に多いです。でもPMBOKの場合、基本的に新しいモノを作るプロジェクトなので、現行機能保証は、ほとんど気にしていません。建物を考えると、壊して造る、そのまま使うなんていうことはないわけです。ITプロジェクトのように基本的に現行システムがあり、その機能保証をするという前提に基づいてPMBOKは作られていません。
３つめは「メンテナンス（エンハンス）」です。例えば建物で考えた場合、造ったあと何をするかというと、機能維持です。ということは、リリースしたときが最高の品質で、あとはこれを維持していくだけなのです。原発もそうだよね、x年が稼働の限界とされています。劣化するからです。劣化をできるだけ抑制する のがメンテナンスです。ところがITシステムのソフトウエアは、稼働後に機能を追加したり改善したりして、大きく変貌します。そこが大きく異なります。一般的なプロジェクトを対象としているのがPMBOKなので、PMBOKではメンテナンスに重きを置いていません。
5-2.ITプロジェクトの「三種の神器」
それは「サブシステム構成図」「スケジュール」「体制図」の３つです（図４）。
なぜ「成功します」と言わないかというと、失敗の原因はPMにありますが、成功の要因はプロジェクトメンバーの働きにあるからです。こうした話は第３部で詳しくします。
それと同時に実績も確保できます。それぞれの工程で何を報告すべきかを定義し、その情報が標準化されていることが重要です。これにより、プロジェクトが工程ごとにどう変遷してきたかが観測され、終了報告時に振り返ることができます。これにより、より良いプロジェクトにするためには、何をいつすべきであったかが明確になり、プロジェクトマネジメントのさらなる進歩につながります。
課題とリスク管理が重要なもう１つの理由は、課題やリスクが出てくるタイミングは、システムの品質あるいはプロジェクト運営の出来、不出来を指しているからです。課題やリスクの出るべきタイミングが大事だということです。「この時期にこの課題が出てきてしかるべき」「リスクが出ないほうがおかしい」という見方ができるのです。
緊急度と重要度は説明の必要はないと思いますので、拡大傾向度合いについて説明します。「拡大傾向のある課題」とは、その課題を解決せずにいると、時間とともに課題がドンドン大きくなって対応が困難になるような課題のことです。
「現行機能保証をしなくてもよい」の指す意味が違う
次に「⑤テストシナリオとテストケースの作成」について説明します。実施すべきつと日程の設定が重要です。通常日、非営業日、土日、得意日、月末、年末年始などのテストを行うべき時間的なケースを洗い出すことが必要です。これが総合テストの特徴になります。