サイト内検索:

プロジェクト管理.info

プロジェクト管理について解説しています。このページでは、プロジェクトの実行・監視・コントロールについて記述します。



プロジェクトの実行・監視・コントロール

変更管理

変更の理由で最も多いものは仕様変更です。この場合、まず仕様変更の理由を明確にする必要があります。仕様変更の原因は2種類あります。客先の業務改革や組織変更等、顧客側に起因するものと開発メンバのスキル不足等、開発側に起因するものです。

続いて計画フェーズでルール化された変更管理手順に基づき変更の手続きを行います。一般的には、変更依頼書を記述し、変更管理委員会等の変更に対する決定権を持つ会議体に提出します。その会議体で、プロジェクトマネージャが中心となり、変更の必要性を判断、変更が必要なら担当者、変更時期等を決定します。そして、プロジェクトスコープとプロダクトスコープの再定義やスケジュール、体制、費用の見直しを行います。変更する/しないの判断は、進捗状況や費用、体制等への影響を考慮し、総合的に判断します。

変更要求発生時には、上記のような適切な手続きを行わなければなりません。適切な手続きが行われない場合、納期遅延やコストオーバ等、致命的な問題発生につながる恐れがあります。開発メンバの独自の判断などで変更を行ってはいけません。変更要求は一元的に管理され、変更可否は正確に判断されなければなりません。

変更の原因が顧客側にあるならば、契約内容の見直しとなります。すなわち納期と費用の見直しということです。開発者側にあるならば、費用は開発側で負担することになります。

進捗管理

進捗を管理する目的は、納期を守ることです。納期を守るためには、進捗遅延を早期に発見し、早期に対応する必要があります。これは、一旦進捗遅延が発生すると挽回することが難しいためです。

進捗の遅延は、進捗管理表等で予定と実績の差より判断します。また、必要に応じて、設計書の作成予定数と完了数等の定量的指標も参照します。

クリティカルパスのように、進捗遅延が絶対に発生してはいけない工程では、進捗遅延の予兆管理を行う必要があります。つまり、進捗遅延につながる先行要因に管理指標を設け、これを監視します。先行要因としては、要員のスキル不足、仕様未確定などによる生産性低下が挙げられます。それを管理する指標としては、要員の残業時間、要員の生産性、設計レビューの指摘件数、兼任している要員の負荷等があります。これらは定量的に計測します。

また、進捗遅延の予兆を事前につかむには、プロジェクトマネージャが開発メンバと直接、コミュニケーションをとり、判断することが重要です。メンバが疲れていないか、悩んでいないかを対話して判断する。定例進捗会議は、一般的に1〜2週間に1度、2時間程度が望ましいとされています。

進捗遅延に関して問題を発見したならば、まず根本的原因を把握するために原因分析を行います。根本的原因を把握したら、それを除去し、遅延の拡大を防ぎます。そして、遅延の挽回策を検討します。

スケジュール短縮技法としては、ファスト・トラッキングやクラッシングがあります。ファスト・トラッキングとは、先行タスクの完了前に後続タスクを開始し、並行作業を行うことです。この場合、並行作業に伴うリスクが増加します。クラッシングとは、クリティカルパス上の作業に要員を追加投入し、スケジュール短縮を図る技法です。この場合は、コストが増加します。残業時間や休日出勤でクラッシングを行う場合は労働基準法や三六協定に反しないよう注意が必要です。

進捗遅延が挽回できない場合には、本番時期の変更、システムの部分稼働等を検討します。

費用管理

費用管理の目的は、費用を予算内に収めるということです。費用管理においても、費用超過の予兆管理は重要です。一旦オーバーした費用の挽回は困難だからです。管理指標については進捗管理を参照してください。

開発費の予算超過を検知するには、計画フェーズで作成したコスト・パフォーマンス・ベースラインと実際に発生した費用を比較します。比較を行うツールにはアーンドバリュー法などがあります。

予算超過の原因には、見積り精度の低さや生産性の低さ等があります。不確定要素が多いため、見積り精度を上げることができない場合には、予防的対策として、契約による対策を打つことが有効です。例えば、要件定義工程と外部設計工程を委任契約とし、大枠が固まった時点で請負契約を締結する等の分割契約を考えます。分割契約が難しく、一括請負にせざるを得ない場合は、適宜再見積りを行う旨を見積書に記載する対策をとります。この場合、スコープを明確にし、顧客側と合意を得ておく必要があります。スコープの変更があった場合に、再見積りを行います。

契約による対策が取れない場合、あらかじめリスク相当分を見込んで予算設定を行う方法もあります。例えば、COCOMOのようなリスクを考慮できる見積り技法を使用したり、見積り費用の20%を上積みする等です。

予算超過が発覚した場合には、まず原因分析を行ない根本的原因を把握します。原因が顧客側にあるならば、追加費用の請求となります。

原因が開発側にある場合、例えば、ヒアリング漏れ、見積り漏れ等による仕様変更でスコープが変更になる場合は、顧客側に費用を請求することができないので、後の費用を削減する対策を検討します。例えば、開発メンバを単価の安い技術者に代える、外注してコストを削減する対策等を検討します。要員の技術力不足により、生産性が予想より低くなった場合には、要員の交代を検討します。費用を抑えるためにテスト工数の削減は行ってはいけません。品質に影響するからです。

品質管理

品質管理の目的は、計画した品質を保証することです。計画フェーズで策定した品質計画に基づいて、レビュー結果やテスト結果を確認します。品質不良の早期発見のために品質の評価基準を組み込んで定量的に管理します。この時使用されるツールには、管理図や信頼度成長曲線があります。定量的に管理していた値が許容範囲を超えたならば、状況確認を行います。確認の結果、品質不良が発生していたならば、原因分析を行ない根本的原因を特定します。原因分析にはパレート図がよく使用されます。品質不良発覚に対する事後対策には、問題要員の交代、有識者・経験者によるサポート、工程をさかのぼっての改善等が挙げられます。

要員管理

プロジェクトの実行フェーズにあたっては、人的資源計画書に基づき、実際に要員を任命、配置し、プロジェクトチームを編成します。また、プロジェクトの生産性を向上させるための教育やトレーニングも行います。連帯意識を形成するための活動等も実施します。

要員に関する問題の早期発見を行うためには、要員ごとの進捗、生産性、勤怠をチェックすることが有効です。また、メンバ間の相性も重要であるので、プロジェクトマネージャは、現場を直接見たり、要員と直接対話をするなどした方が良いでしょう。

問題が発生した時の対応としては、まず、このままプロジェクトを進行した場合どうなるかを予測します。プロジェクト体制の変更は大きなリスクを伴うからです。労働基準法等の法律に違反することや特定の要員に過剰な負荷がかかる等のことがなければ、体制の変更なしも有力な選択肢です。

要員を新たに追加する場合には、作業の引継ぎや作業環境に慣れるための準備期間等の時間も考慮する必要があります。新規要員に期待通りの能力がない可能性もあるため、体制変更後の新規要員の生産性チェックは充分に行う必要があります。

コミュニケーションの管理

プロジェクトの実行にあたり、プロジェクトマネージャは、コミュニケーション・マネジメント計画書に基づいて、ステークホルダーに適切なタイミングで情報を配布します。そして、ステークホルダーの要求事項とその実現度をチェックし、問題が発生していれば、解決を図ります。また、スケジュールベースライン、コストベースライン、品質ベースライン等のベースラインに基づいて収集された実績データを実績報告にとりまとめ、ステークホルダーに対して報告します。

リスクの監視とコントロール

プロジェクトの進行中は、随時、計画段階で埋め込んでおいたリスク検知の評価基準をチェックします。リスクが発生していたら、計画しておいた対応策を実施します。また、新たなリスクが発生する可能性もあるため注意します。新たなリスクが発生した場合は、リスクマネジメント計画書の手順で、管理を実施します。

調達管理

RFPの発行に際しては、説明会を開催し、質疑応答を行った上で、提案書を提出してもらいます。そして、提案書を評価基準に基づいて評価し、発注先を決めます。

発注先の決定方法は客観的でなければなりません。そのため、各評価基準項目に対して重み付けを行い、各評価基準項目に対する点数と重みの積を合計し、総合点で評価するといったような方法が望ましいでしょう。また、スクリーニング(評価基準に対して最低限必要な条件を定めること)を行い、不適切な発注先を選択しない工夫もあるとよいでしょう。

調達先を海外に求め、コストダウンを図ることがあります。海外の企業に依頼し、海外でソフトウェア開発を行ってもらうことを、オフショア開発といいます。海外技術者の単価は、国内の3分の1から5分の1程度と言われており(2010年現在)、大幅なコストダウンを図ることができますが、問題点も多いです。

オフショア開発の問題点としては、品質不良が挙げられます。納品された成果物の品質が低いというケースが、国内企業に依頼した場合より多いと言われています。品質不良が発生すると納期遅延やコスト増につながるので、充分な対策をしておく必要があります。品質不良の原因はおもに2つあり、1つはコミュニケーションギャップ、もう1つは、品質に対する意識の違いです。

コミュニケーションギャップは、言語や文化の違いにより発生します。これに対しては、ブリッジSEや経験者を手配するという対策が有効です。また、ドキュメントにUMLや図表を活用して認識の共通化に努めることも重要です。

海外企業には品質に対する意識が低い企業も多いと言われています。これに対しては、契約条項に「品質に関する条項」を盛り込む等、条件を詳細につめることが有効です。必要であれば、品質不良、納期遅延にたいしては金銭的ペナルティーを加えることも考慮します。

また、雇用スタイル、文化の違いにより、開発がうまく進まないケースもあります。例えば、開発メンバが転職をちらつかせて報酬の増額を要求する等の問題です。これに対しても、契約条項を詳細につめることが有効です。

前の項目:プロジェクトの計画 | 次の項目:プロジェクトの終結
© 2010 プロジェクト管理.info管理人 | プライバシーポリシーお問合せ