玄録

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

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

トラブルの根本原因

2005.08.19

  • Facebook
  • mixi
  • hatena

2.トラブルの根本原因

 表面化したトラブルは複数の原因が複雑に関連していますが、それぞれ因果関係とその根本原因を発見することが重要です。表面的な原因だけを解決しても、根本原因を解決しない場合、また同じようなトラブルが発生してしまいます。

①スケジュールの遅れの原因
 スケジュールの遅れの原因は、沢山存在し複雑にその他の原因と関係しています。
例えば、

・元々のスケジュール自体がWBS(Work Breakdown Structure) で考えられていない(または大雑把過ぎ)で、作業ボリュームとリソース(開発者)割り当てが矛盾していたため工数不足となり、スケジュールが遅れた。

・見積りがあまく、工数不足となり、スケジュールが遅れた。

・仕様検討や設計での残課題が沢山放置されて、次工程でその検討に時間を要し、スケジュールが遅れた。

・設計でのアーキテクチャの選択ミスをコーディング工程で開発担当者が気が付いたが設計変更ができないため、カバーするための開発工数が増大し、スケジュールが遅れた。

・難易度の高い作業にスキルの低いリソースをアサインしたため、進捗が悪く、スケジュールが遅れた。

・プロジェクト内の風通しが悪く、遅れの兆候が事前に報告されていなかったため、迅速な対応ができず、遅れが増大した。

・仕様追加・仕様変更など、開発規模の変化に合わせたスケジュールを見直しや顧客とのスケジュール調整をしなかったため、スケジュールが遅れた。

・プロジェクト管理を行っていなかったため、各工程でのチェックが働かず、納品段階になって初めてスケジュールの遅れに気が付いた。

②開発規模の増大の原因
 開発規模の遅れは、沢山存在し、複雑にその他の原因と関係しています。
例えば、

・見積り検討・仕様の検討・調査不足により、利用できると思っていたパッケージ機能が不足していることが後工程で発覚し、それを埋め合わせる機能を開発するため、開発規模が増大した。

・仕様変更により、手戻り工数や開発規模が増大した。

・仕様決定後に仕様追加になった場合に、その開発規模の見積り誤りやスケジュール見直し ・リソース追加などに対応しなかった。

・本来、共通化できる機能・モジュールを共通仕様で作成しないで、ばらばらに作り開発規模が増大した。

③要件を満足していない機能
 要件を満足していないトラブルは、顧客とのコミュニケーション不足や本来開発作業として実施しなければならないことを怠ったなど、重大な根本原因を含んでいます。
例えば、

・仕様書通り動作しないなどの品質問題は、内部テスト工程や受け入れテストで表面化し、その原因は、問題が発生した前工程のレビュー不足(コーディングレビュー)、テスト実施不足(単体テスト、結合テスト)やテスト要因分析不足です。本来あってはならないことですが、スケジュールの遅れや開発規模の増大によって、テストの手抜きが発生するケースも多数見られます。

・性能問題は、負荷テストなど想定トランザクション数、想定最大データ量でのテストで表面化し、その原因は設計レベル(アーキテクチャの選択ミス)、コーディングレベル(コーディングレビュー不足によるプログラムミス)にあります。

・機能要件の問題は、顧客側での仕様書レビュー不足や業務検討が不足、SE側での仕様確認不足などが原因で、ユーザ受け入れテスト、業務を開始して初めて表面化するため、非常に大きな問題になります。

 これらの原因は、複雑に他の原因と関連し悪循環になっている場合が多いため、原因の関連性と影響度、表面化したトラブルの重要度を同時に検討する必要があります。

 次回は、『その3:トラブルの対処方法』について、ご説明します。