BOOK Preview 新訳 ソフトウェアプロジェクトサバイバルガイド 第14章 構築 マイクロソフトプレスの書籍紹介ページ 書籍情報のページ 2005/08/30

Page1 Page2 Page3

進捗の追跡

　開発期間中は、進捗の追跡（トラッキング）がかなり重い作業となる。初期のフェーズではプロジェクトの作業を簡単に小さな単位に分けることはできないが、構築作業は、数日あるいはもっと短い期間の小規模マイルストーン、つまり「タスク」に分割できる。プロジェクトの進捗を知るために、これらのタスクの1つ１つの達成状態を追跡する必要がある。

進捗情報の収集

　自動ツールを使用すれば、小規模マイルストーンの追跡に必要な作業をかなり削減できる。たとえば、小規模マイルストーンリストをコンピュータで使用できるMicrosoft Projectのような計画ツールやスプレッドシートに入力しておけばよい。このリストをプロジェクトのバージョン管理システムに格納し、プロジェクトのイントラネットホームページを介してアクセスできるようにする。そうすればプロジェクトチームのだれもがこの情報を参照できる。開発者またはテスト担当者はマイルストーンを達成したら、バージョン管理システムからマイルストーンリストをチェックアウトし、その作業が完了したことを示すように更新して、再びリストをバージョン管理システムにチェックインする。

　作業時間記録システムについても同様にコントロールする必要がある。プロジェクトの構成メンバーがタイムシートに自分の作業時間を記入し、管理部門の担当者が後でまとめてデータを入力するという方法をとっている組織もある。しかし、自動システムの扱いに慣れてしまえば、オンラインで自分のデータを入力するのに、タイムシートに記入する以上の時間はかからない。プロジェクトメンバーは、最低でも週ごとに自分の作業時間記録データを作業時間記録システムに入力する必要がある。データを入力する間隔がそれ以上開くと、実際に費やした作業時間数を忘れてしまい、作業時間記録のデータが不正確になってしまう。

プロジェクトの可視性

　プロジェクトメンバーのだれもが計画資料に自由にアクセスできるようにしておくことの利点の1つは、作業予定と作業時間記録に関する情報を効率的に収集できる点である。これによって、すべての進捗情報がプロジェクトマネジャーの手元に滞留してしまうことがなくなる。プロジェクトの計画資料を公開することのもう1つの利点は、プロジェクトメンバーがそれぞれ異なる視点からプロジェクトを検証できる点である。また、プロジェクトの進捗情報の公開と、匿名による問題報告/フィードバックチャネルの公開は、プロジェクトマネジャーや経営上層部が発生しつつある問題を把握し、対応に必要な情報にアクセスできるようにする上で非常に有用である。

プロジェクトの追跡情報の週次更新

　プロジェクトマネジャーは、構築フェーズに入ったらほぼ1週間に1回の頻度で、プロジェクトの進捗状況をチェックする必要がある。このチェックは次のような作業を通して行う。

◆ プロジェクト計画、欠陥追跡、作業時間記録の各システムからの要約データの収集

◆ 小規模マイルストーンの達成実績値と予定値との比較

◆ 実際に報告のあった欠陥と予測した欠陥との比較

◆ 実際の工数と計画上の工数との比較

◆ トップ10リスクリストのレビューと更新

◆ 匿名によるフィードバック報告チャネルを通じて提出されたフィードバックのレビュー

◆ 提案済み変更とプロジェクトの変更管理委員会による承認済み変更のレビュー、およびこれらの変更のプロジェクト計画への累積的影響の検討

　この検討結果に基づいて、プロジェクトマネジャーは、実績と進捗状況が計画から大きく外れている場合や対処する必要のあるリスクが発生している場合に、是正処置を採らなければならない。

　こうして週次でデータを収集して分析した結果は、各ステージの完了時にプロジェクトログを更新し、さらにプロジェクトの終結時にプロジェクト履歴を作成する際のベースラインとなる。プロジェクトログについては「第17章　ステージ完了時の確認事項」で、またプロジェクト履歴については「第18章　プロジェクト履歴」でそれぞれ説明する。

顧客や経営上層部に対する報告

　進捗状況のレビューと並行して、プロジェクトマネジャーは、経営上層部、顧客、ユーザー、およびその他のステークホルダーに定期的な報告を必ず行い、プロジェクトへの信頼を失わないようにしなければならない。ステークホルダーの方から質問してくるのを待っていると、質問があったときにはすでに不安を抱いてしまっていることになる。プロジェクトマネジャーがその時点で質問に答えれば、不安を拭い去ることはできるかもしれないが、失われた信頼を取り戻すことはできないだろう。

　プロジェクトマネジャーは常に先手を打って、ステークホルダーが不安になって質問する前に、プロジェクトの進捗状況について積極的に報告すべきである。ほとんどの人にとって「すべて順調です」という報告は多いほど良いものなので、月に1回と言わず週に1回は報告すべきだろう。顧客や上司に対して定期的な報告を怠らなかったマネジャーや開発者は、協力的で責任感があり誠実であると評価され、労力以上のメリットを得たと述べている。

変更管理

　ソフトウェアが実際に動作するようになると、ソフトウェアの種類にもよるが、ユーザーやマネジャーはさっそくそれを使い始める。そしてその過程で、自分が期待していたものとそのソフトウェアに異なる点があることを発見する場合がある。これらの相違点の中には、ソフトウェアがまだ開発中であることに起因するものもあるだろう。このため、何か問題があったときにそれがバグなのか、まだ完成していないためなのか迷うことになる。ユーザーやマネジャーがソフトウェアを使用しただけでは判断がつきかねることが多い。

　しかし、発見された相違点の中には、明らかにソフトウェアの変更を必要とするものがある。構築作業の間には、ソフトウェアの変更を求める圧力があらゆる方向からかかってくる。プロジェクトがこの時点までは適切にコントロールされている場合、ここへ来ての無秩序な変更は、何にも増して、プロジェクトのスケジュールと予算の超過の原因となる。

ソフトウェアの変更を求める圧力が強くなればなるほど、 変更に対して慎重に対応することが重要になる。 さもないと、プロジェクトはコントロール不可能な状態に陥ってしまう。

　プロジェクトの変更管理委員会は、変更管理の核となる組織である。変更管理委員会がその使命を十分に果たすには、プロジェクトのすべてのステークホルダーが委員会の決定を尊重しなければならない。変更の大多数は、経営上層部、マーケティング担当者、顧客などから提案されるものであるが、当然そういった人々も委員会の決定には従うべきである。要求開発などのプロジェクト始期の段階で変更管理委員会を発足させておけば、開発フェーズに達するまでには変更管理委員会の存在価値をすべての人が認めていることだろう。変更を提案し、関係者に通知し、すべての影響を検討し、そして最終的には変更管理委員会の決定に従うというプロセスにも、この時点ではすべての人が慣れているはずである。

　ソフトウェアのリリース予定日まで残り3週間しかないというときになって、初めて体系的な変更管理プロセスを作業の中に組み込まなければならないとすれば、それは非常に困難な作業となる。この時期に設立された変更管理委員会では、いかにも「却下」と言うためだけに設立されたような印象を拭えず、プロジェクトメンバーがその権威を認めることは困難である。長期間運営されている変更管理委員会なら、そのような受け取り方をされる心配はない。この点からだけでも、プロジェクトの始期に変更管理委員会を設立しておく意味がある。

集中を乱す要素の排除

　このフェーズにおけるプロジェクトマネジャーは、作業への集中を乱すものから開発者を守るという役割も担っている。特に、ユーザー、経営上層部、マーケティング担当者などからの要求に対しては、プロジェクトマネジャーが防波堤とならなければならない。プロジェクトマネジャーは、すべての変更要求が、開発者に直接至ることなく正式な変更管理経路を経由するように配慮して、開発者が本来の作業への集中を乱されることがないようにする必要がある。

優れた構築のための要素

　構築は、ソフトウェア開発の成否を左右する重要なアクティビティである。優れた構築を行えば、不手際な構築に比べてプロジェクトの期間が半分で済む。優れた構築は何世代にもわたる容易で快適な保守管理の基礎を築くが、不手際な構築を行うと何世代にも渡って悩まされ、コストも増大し続けることになる。

　しかし、ソフトウェアプロジェクトサバイバルという観点から見ると、プロジェクトが最終的に成功するか失敗するかを決定付ける土台のほとんどは、開発フェーズに達するまでにすでに築かれている。徹底的な要求の調査、設計の詳細な肉付け、優れたアーキテクチャの設計、詳細なステージ別納品計画の作成、慎重な見積り、効率的な変更管理など、こうした作業をプロジェクトチームが確実に行っていれば、構築作業は着実に進捗し、大きな問題が発生することはないだろう。

プロジェクトの上流の作業を効果的に実施していれば、 構築作業では大きな問題が発生することもなく 作業はぐんぐんはかどるだろう。

　開発フェーズは、管理が適正でないプロジェクトで問題が表面化し始める時期である。このようなプロジェクトでは、初期のステージでは迅速に作業が進むように見える。わずかな工数で要求開発、アーキテクチャ設計、設計のフェーズを駆け抜け、取りあえず動作するコードを迅速に作成する。問題は、書かれたコードを基にテスト担当者やユーザーがソフトウェアを実行してみてはじめて表面化する。この時点で、多くの欠陥が発見され始める。この段階になると問題の修正には多大なコストが必要である。運営が適正でないプロジェクトは、最初は迅速に進んでいるように見えるが、後になるとその化けの皮が剥がれ、誤った近道をしてしまったことが露見する。開発作業に投入できる人的・物的資源は例外なく不足する。スケジュールを延長し、予算を増やし、それでも間に合わず、多くの重大な欠陥を未修正のまま残さざるを得ない状況になり、開発者、テスト担当者、マネジャー、顧客の間には無数の苦渋に満ちた対立が生じてしまう。

　プロジェクトを適正に運営すれば、このような問題は上流で検出され、はるかに低コストで修正できる。したがって構築作業で検出される問題の大半は構築作業自体に関する問題に限られ、わずかな工数で修正でき、険悪な対立が生まれることもない。

サバイバルチェック プロジェクトではコーディング規約を定めている。 すべてのコードに対してテクニカルレビューを行い、コーディング規約の適用を徹底させている。 プロジェクトではソフトウェア統合手順を作成してある。 　 開発者がソフトウェア統合手順に従っていない。 プロジェクトチームは、ステージ1でシステムの骨組みを構築している。 　 プロジェクトチームは、最初の目に見える機能を構築する前に、システムのインフラストラクチャをすべて構築しようとして、その作業に没頭している。 プロジェクトではデイリービルドとスモークテストを実施している。 　 デイリービルドがしばしば壊れる。 　 スモークテストがデイリービルドに追いついておらず、ソフトウェアのすべての機能がテストできていない。 プロジェクトマネジャーは、小規模マイルストーン、欠陥、変更報告、作業時間記録データ、トップ10リスクリストなどの、進捗情報の追跡を週次で実施している。 プロジェクトの進捗データは、すべてのプロジェクトメンバーがいつでも参照できるようになっている。 　 顧客や経営上層部に進捗状況が定期的に報告されていない。 変更は常に変更管理委員会を通じて管理されている。 　 変更管理委員会が初めて設置されたのは構築作業が始まった後であり、その権威が十分に認知されていない。

　

INDEX
	新訳 ソフトウェアプロジェクトサバイバルガイド
	1. 第14章 構築（1）
	2. 第14章 構築（2）
	3. 第14章 構築（3）

　

「BOOK Preview」

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