tech.nikkeibp.co.jp
あいかわらず、なのですよねー。。。
スケジュールの遅延が発生した理由を複数回答で尋ねたところ、最も多かったのは「システムの仕様変更が相次いだ」（37.4％）。その次に要件定義やシステム設計といった「各フェーズの見積もりが甘かった」（28.7％）、「システムの不具合など想定外の問題が発生した」（27.7％）、「当初の稼働スケジュールにそもそも無理があった」（26.7％）と続く。
この結果から「失敗の要因は相変わらず上流にあり、安直ともいえる策で場当たり的に対応している」という戦略なき実態が見えてくる。システム開発における「失われた10年」と言えるほど、何も進化していない。
この結果から、次のようなプロジェクトの姿がイメージできる。
要件定義では要件の洗い出しに苦労する。完全に要件を固められたわけではないが、スケジュールを優先して次のフェーズに進む。だがテスト・移行工程に入って要件定義の漏れが見つかり、大幅な手戻りが発生。当初の予定よりも長引いた──。遅延プロジェクトではよくある光景だ。
プロジェクトの遅延にどう対応すればいいのか。まず必要なのは要件定義を疎かにしないことだ。
ITベンダーの回答者（SE部門、係長クラス）は「ユーザー企業が自身の要求内容をしっかり把握していることが大切。そうしないと、後々手戻りが発生してスケジュールに悪影響が及ぶ」と指摘する。ベンダーを選定する際も「ユーザー企業がRFP（提案依頼書）を作成しておくことがプロジェクトの成否を握るカギ」としている。
（中略）
ABC協会の細川氏は「一般に要件定義の工数を1とした場合、プロジェクト全体工数が10になるよう配分するのが妥当だ」と指摘する。こうしたノウハウを生かせば「見積もりが甘い」「稼働スケジュールに無理がある」といった問題の回避につながる。
スケジュール管理の徹底も大切だ。流通・小売業の回答者（IT部門、部長クラス）は「以前のプロジェクトでスケジュールが遅延したことがある。進捗を定量的に把握できる管理手法を導入するのが成功のカギだ」と指摘する。
「スケジュール短縮のためアジャイル開発を採用した」（製造業のIT部門、係長クラス）という声もあった。小規模な案件で手法にたけた要員を確保できれば、効果が見込める可能性もある。
テスト・移行については「テスト期間としてプロジェクト全体の4分の1は確保したい」と細川氏は話す。要件定義を入念に進めるとともに十分なテスト期間を確保すれば、スケジュール遅れを回避できるだろう。
「スケジュール短縮のためアジャイル開発を採用した」ってのも、「結果そうなった」ってことだと思うんだが、
そこを含めて「あいかわらず」な感じの記事でした。
seichi23.hatenablog.com
tech.nikkeibp.co.jptech.nikkeibp.co.jp
