玄録

玄録は、秀玄舎の事例を通した、
実践研究の成果をご報告する不定更新の
ビジネスレポートです。

システム開発におけるトラブルとプロジェクト管理の役割

トラブルの表面化

2005.08.12

  • Facebook
  • mixi
  • hatena

 秀玄舎では、システム開発における様々なトラブルに対するレスキューサービスを実施しています。今回はシステム開発におけるトラブルとプロジェクト管理(Project Management: PM)の役割について、お話をします。

○その1:トラブルの表面化
○その2:トラブルの根本原因
○その3:トラブルの対処方法
○その4:プロジェクト管理の重要性
○その5:プロジェクト管理の発展性

1.トラブルの表面化

 システム開発プロジェクトのトラブルは、以下のような形で表面化します。
○スケジュールの遅れ
○開発規模の増大
○要件を満足していない機能

 秀玄舎のレスキューサービスに依頼された時には、トラブルの表面化直後ではなく、さらにトラブルが肥大化した状態となっているケースがほとんどです。このような場合には、スケジュールの遅れ、開発規模の増大等の複数のトラブルが複合して表面化しています。

①スケジュールの遅れ
 各開発工程の区切り(例えば、要件定義、基本・機能設計、コーディング、テスト)で、スケジュールの遅れは表面化します。実は開発担当内部では、プロジェクトとして表面化する前に遅れが予想されていたり、若干の遅れとして把握されているケースがほとんどですが、『まだ簡単に挽回できるだろう』とか、『怒られるからぎりぎりまで内緒にしよう』とかの心理的要素が働き重大性の認識が遅れる傾向にあります。プロジェクト内部の通気性(コミュニケーション)の度合いにより、プロジェクトとしてのトラブルの表面化は更に遅れる傾向にあります。

②開発規模の増大
 見積りの甘さ・仕様変更等により開発規模が増大し、さらにスケジュールの遅延にも繋がります。WBS(Work Breakdown Structure) などの手法により仕事内容を細分化した各機能単位での予定コーディング量と実績コーディング量の推移を把握することでトラブルとして表面化します。ドンブリ勘定で作業を実施していた場合は、開発規模の増大に気が付かず、大幅なスケジュールの遅延として表面化します。

③要件を満足していない機能
 品質問題・性能問題などは内部テスト工程で、機能要件レベルの問題はユーザ受け入れテストや業務開始で表面化します。

・品質問題は、仕様書通り動作しない。ひどい場合はプログラム終了などの重大障害として表面化します。
・性能問題は、負荷テストなど想定トランザクション数、想定最大データ量でのテストを実施することで表面化します。
・機能要件レベルの問題は、顧客側での仕様書レビュー不足や業務検討が不足して、ユーザ受け入れテスト、業務を開始して表面化するため、非常に大きな問題になります。

 プロジェクトを円滑に進めるためには、これらのトラブルが表面化した時、できるだけ早く原因を調べ、その影響を判断する必要があります。

 次回は、トラブルの根本原因についてご説明します。