BOOK Preview 新訳 ソフトウェアプロジェクトサバイバルガイド 第1章 サバイバルのトレーニングの勧め 第2章 サバイバルテスト マイクロソフトプレスの書籍紹介ページ 書籍情報のページ 2005/07/30

Page1 Page2

　ソフトウェアプロジェクトの健全度を判定するための簡単なテストを紹介する。テストの結果、プロジェクトが危険な状態にあることが判明したら、点数を上げるように対処して、状態を改善していただきたい。

第2章 ソフトウェアプロジェクトサバイバルテスト

　本章では、プロジェクトの成功確率を評価するためのテストを紹介する。プロジェクトはスケジュールどおりに予算の範囲内で完成するのか。プロジェクトは輝かしい成功となるのか、汚点を残す過ちとなるのか。このテストを実施してみれば、判明するはずである。

サバイバルテストの答え方

　各質問に対する答えが「はい」の場合は、そのプロジェクトに3点を与える。完全に「はい」と言えない場合は、確信できる程度に応じて部分点を与える。たとえば、「おそらく」そのとおりであるという場合は2点を与え、「まったくそのとおりというわけではないが、そう言えなくもない」という場合は1点とする。プロジェクト始期の場合は、プロジェクト計画に基づいて質問に答え、プロジェクトがある程度進行している場合には、プロジェクトで実際に行われたことに基づいて質問に答えればよい。テストの後に、得点の解釈について説明する*。

*　このテストは、本書のWebサイトで入手できる。

サバイバルテスト

要求 1. 明確なビジョンステートメントまたはミッションステートメントがプロジェクトで制定されているか。 2. すべてのチームメンバーが、ビジョンを達成可能であると信じているか。 3. 事業における便益を詳細に示し、メリットの測定方法を明らかにするビジネスケースを策定しているか。 4. 実装するシステムの機能を現実的かつ明瞭に示すユーザーインターフェイスのプロトタイプを用意してあるか。 5. ソフトウェアが持つべき機能の詳細な仕様を文書で作成してあるか。 6. 実際にソフトウェアを使用する人（エンドユーザー）に対して、プロジェクトの始期に聞き取り調査を行ったか。さらに、プロジェクトの全体を通じてエンドユーザーの関与を得ているか。 計画立案 7. 詳細なソフトウェア開発計画書を作成してあるか。 8. プロジェクトのタスクの一覧には、インストールプログラムの作成、前バージョンのシステムからのデータコンバージョン、サードパーティのソフトウェアとの統合、顧客との会議、その他「些末な」タスクまで含まれているか。 9. スケジュールと予算の見積りは、最も最近完了したフェーズの終結時に公式に更新されたか。 10. アーキテクチャと設計についての詳細な文書を作成してあるか。 11. 詳細な品質保証計画書を作成してあるか。この計画には、システムテストだけでなく、設計とコードのレビューも含まれている必要がある。 12. ソフトウェアの詳細なステージ別納品計画書を作成してあるか。この計画書は、ステージごとに実装して納品するソフトウェアについて説明したものである。 13. プロジェクト計画には休日、休暇、病欠、教育などの時間が見込まれているか。さらに、リソースの使用率が100%未満で計画されているか。 14. スケジュールを含めたプロジェクト計画は、開発チーム、品質保証チーム、マニュアル作成チームの同意を得ているか。つまり、実際に作業を行う人たちの同意を得ているか。 プロジェクトのコントロール 15. 意思決定権を持つ特定の役員が、プロジェクトの責任者として選任されているか。さらに、その人物は積極的にプロジェクトを支持しているか。 16. プロジェクトマネジャーの作業量は、そのプロジェクトマネジャーがプロジェクトに十分な時間を当てられるだけの量か。 17. 完全に達成されたか、あるいはまったく達成されていないかを判定できる「二者択一型」の明確なマイルストーンが、プロジェクトの要所に設定されているか。 18. プロジェクトのステークホルダーに、これらのマイルストーンの達成状況が簡単にわかるようになっているか。 19. フィードバックするための制度が設けられているか。この制度は、プロジェクトのメンバーが直属の上司や経営上層部に対して匿名で問題を報告できる必要がある。 20. ソフトウェアの仕様の変更を管理するための計画を、文書で作成してあるか。 21. 変更管理委員会が設けられているか。この委員会は、提案された変更を認めるか認めないかの最終的な決定権を持つ。 22. プロジェクト計画案の関連資料と現状に関する情報は、チームメンバー全員が閲覧できるようになっているか。この情報には、工数とスケジュールの見積り、タスクの割り当て、その時点までの進捗状況と計画との比較などが含まれる。 23. すべてのソースコードは、バージョン管理が行われるようになっているか。 24. プロジェクトの環境には、プロジェクトを完遂するために必要な基本ツールが揃っているか。ツールには、欠陥追跡、ソースコード管理、プロジェクトマネジメントのソフトウェアが含まれる。 リスクマネジメント 25. プロジェクト計画案には、プロジェクトが現在抱えているリスクの一覧を明示した資料が含まれているか。その一覧は最近更新されたか。 26. プロジェクトのリスク責任者がいるか。その責任者は、プロジェクトに発生しているリスクを発見して特定する責任を持つ。 27. プロジェクトがサブコントラクタを使用している場合、サブコントラクタを管理するための計画を作成してあるか。また、サブコントラクタ1社につき1人ずつの担当者を決めているか（サブコントラクタを使用していない場合、この項目の得点は3点とする）。 人的資源 28. プロジェクトチームには、そのプロジェクトを完遂するために必要な技術を持った専門家がすべて揃っているか。 29. プロジェクトチームは、そのソフトウェアが実際に使用される稼働環境に関する技術的専門性を備えているか。 30. そのプロジェクトを成功に導ける指導力を持った技術リーダーがいるか。 31. 必要な作業をすべて行えるだけの十分な人数が揃っているか。 32. すべての人がうまく協力して作業を行っているか。 33. 各人がプロジェクトに十分にコミットしているか。 得点の集計 暫定得点＝それぞれの質問に対する得点を合計する。 規模別指数＝プロジェクトチームを構成するフルタイムの作業要員が、開発者、品質保証責任者、現場マネジャーを含めて3人以下の場合は、1.5 とする。フルタイムの作業要員が4 〜 6人の場合は、1.25とする。それ以外の場合は、1.0とする。 最終得点＝暫定得点に規模別指数を掛けて積を求める。

サバイバルテストの結果判断

　このテストは、ほとんどのプロジェクトに厳しい判定を下すだろう。50点に満たないプロジェクトも数多く存在するかもしれない。表2-1で、得点をどのように解釈したらよいかを解説する。ソフトウェアプロジェクトサバイバルテストの結果は、将来のプロジェクトと比較するための評価ベースラインにすることができる。このテストは、学校で学期の期首に行われるテストと同じような性格を持っている。テストが行われた後、学生はその学期の間に新しい科目を勉強し、学期の期末になるともう1 度テストが行われる。教師が学生を十分に指導できれば（そして学生が一生懸命勉強すれば）、得点は上がるだろう。

表2-1 サバイバルテストの得点の解釈 得点 コメント 90点以上 最優秀 この得点を獲得したプロジェクトは、あらゆる面で成功することが確実である。スケジュール、予算、品質、その他の目標をすべて満たすことができるだろう。第1章で説明したプロジェクトのニーズの階層で言えば、完全に「自己実現」のレベルに達している。 80 〜 89点 優秀 このレベルのプロジェクトは、平均よりはずっと適正に運営されていると言える。このようなプロジェクトは、スケジュール、予算、品質の目標から大きく逸脱せずにソフトウェアをリリースできる可能性がかなり高い。 60 〜 79点 良 この範囲の得点は、ソフトウェアの開発において平均よりは良いレベルの効率を上げていることを表している。このようなプロジェクトは、スケジュールか予算のいずれかの目標を満たすことができるチャンスは十分にあると言えるが、両方を満たすことはおそらくできないだろう。 40 〜 59点 普通 この得点は平均的である。この範囲の得点を獲得したプロジェクトは、高いストレスと不安定なチーム力学に悩まされるだろう。ソフトウェアは最終的にリリースできるだろうが、要求されていた機能のうちの一部は組み込むことができず、予算もスケジュールも超過することになる。このレベルのプロジェクトに対して本書で説明している計画を適用すれば、最も大きな効果を期待できる。 40点未満 危険 この範囲の得点しか獲得できなかったプロジェクトは、要求、計画立案、プロジェクトのコントロール、リスクマネジメント、人的資源という主要な領域において重大な弱点を持っている。このレベルのプロジェクトにとっての最大の懸念は、そもそもプロジェクトそのものを完了できるかどうかということである。

　「期首と期末」の比較に役立つテストにするためには、授業の内容をすべて網羅しなければならない。このサバイバルテストも、ソフトウェアプロジェクトのサバイバルについて本書で触れるすべての内容を網羅している。本書を読み終わった後で次のプロジェクト計画を立て、その時にもう1度このサバイバルテストを行うことをお勧めする。新しいプロジェクトの得点は本書を読む前より上がっているはずである。それとともに、プロジェクトが成功する確率も高くなっているに違いない。

サバイバルチェック サバイバルテストを行った結果、プロジェクトの得点が60点以上である。 プロジェクトの得点は60点未満であるが、得点の向上を目指して是正処置の計画を立てた。 　 プロジェクトチームが、計画された是正処置を実行していない。

　

INDEX
	新訳 ソフトウェアプロジェクトサバイバルガイド
	第1章 サバイバルのトレーニングの勧め
	第2章 サバイバルテスト

　

「BOOK Preview」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）