このエントリーをはてなブックマークに追加LINEで送る

第10章 スケジューリングと進捗管理

ハッピィ・エンジニアリング表紙

 中堅ソフトハウスのA社は、大手メーカーB社の下請けとして、事業会社C社の多数のシステムを手がけてきた。あるとき、B社の担当者が異動することになった。後任となった営業マンは、前任者と比較してそれほど熱心ではなかった。そのため、C社のシステム担当者は、今まで以上に小回りの利くサービスをA社に求めることにした。実験的に比較的小さいシステムを、A社に直接発注したのである。

 

 A社は、創業以来初めてのSI案件を受注することになった。これまで以上に責任ある仕事になるため、各部門の主力となっているSEを4人集めた。あいにく、プログラマの多くはほかのプロジェクトから動かすことができなかったため、何度か一緒のプロジェクトに入っていた人材派遣会社から12名のプログラマをアサインすることとなった。ところが、各部門から主力メンバを集めたにもかかわらず、プロジェクトはトラブルの連続に見舞われるのである。

 

 基本設計に入ってから、C社の担当者への説明資料作成に追われることになってしまった。設計書に従ってレビューしていくことができないのである。いくつもの概念図を書き、メリット・デメリットを明示しながら進めていかなければ、ものごとが決まらない。SEたちは説明資料を作成するので手いっぱいとなり、基本設計書の完成は予定より2週間ほど遅れてからであった。

 

 ここで、ようやく開発環境の手配をしていないことに気がついた。思えば、ハードウェアどころか、OSのバージョンやデータベースなどのツールもC社と合意していない。OSやデータベースを慌てて確定したものの、今のプロジェクトメンバはアプリケーションの開発者であり、サーバ環境を適切に構築できるメンバが不在であった。さんざん試行錯誤を繰り返して、当初のスケジュールから6週間の遅れを出し、開発環境を整備した。

 

「このプロジェクトの納期を遅らせるわけにはいかない」

 

 A社の上層部は、C社との今後の取引を考え、プログラマの増員を決定した。

 

 いよいよ開発プロセスである。プログラミング作業は順調に進んでいるかのように見えた。ところが、単体テストに入ったところで、大幅な手戻りが発生した。ほとんどのプログラムがきちんと動作せず、単体テストが通らないのである。A社は、プログラミングプロセスでしっかりとしたデバッグを行い、ほとんどの動作を完了してから単体テストを行っていた。しかし、人材派遣会社のプログラマは、単に「プログラムを書いただけ」でプログラミングのプロセスが終了だと考えていたのである。

 

 単体テスト・結合テストのプロセスは、ただ単にデバッグ作業を行うだけのプロセスとなってしまった。プログラマの必死の作業によって、どうにかこうにか納期ギリギリに納品できたものの、きちんとしたテストプロセスを省略したシステムが安定して稼働するわけもなく、運用で100を超える障害が発生し、A社の信用はガタ落ちとなった。

第10章 スケジューリングと進捗管理 ハッピィ・エンジニアリング記事一覧

10.1. 段取りなしの現場状況 ハッピィ・エンジニアリング

 ほとんどのプロジェクトが、プロジェクトマネジメントの基本的なプロセスに従っていない。「終わりよければ、すべてよし」という結果に至ればまだマシなほうで、たいていのプロジェクトは、テストプロセスでバグつぶしに追われ、運よく運用が開始されたとしても、その後で多くのトラブルに見舞われることになる。 たとえ...

≫続きを読む

10.2. 段取り八分 ハッピィ・エンジニアリング

 プロジェクトマネジメントに要求されることは、QCDの達成である。そのためには、すでに問題点として指摘した通り、作業内容の明確化〜作業に必要なリソースの検討〜作業ボリュームの見積もり〜実施スケジュールの作成と、きちんとした手順に従った段取りが必要である。 ところが、ちゃんとした手順に従って計画したと...

≫続きを読む

10.3. 作業の明確化 ハッピィ・エンジニアリング

 プロジェクトで実施すべき作業を明確化するためには、何がプロジェクトに必要な作業なのか、何がプロジェクトに不要な作業なのか、という2つの観点で、作業の洗い出しを行う必要がある。作業内容の洗い出しを行い、プロジェクトにおける作業を定義することを、「プロジェクトスコープの定義」と呼ぶ。 厳密に言えば、プ...

≫続きを読む

10.4. ネットワーク図の作成 ハッピィ・エンジニアリング

 WBS項目が100を超えるようなプロジェクトや、10人以上が参加するプロジェクトでは、それぞれのWBS項目に対して、作業の前後関係・依存関係を明確化しておく必要がある。 各作業の前後関係を明確にすることで、矛盾のないスケジュールにできる。矛盾のないスケジュールを作るということは、予想以上に納期やコ...

≫続きを読む

10.5. リソース計画 ハッピィ・エンジニアリング

 スケジュール、コスト、品質を決定する一番の要因はリソースである。リソースとは、プロジェクトを実施するうえでコストを伴うものすべてを意味する。システム開発プロジェクトでは、人的資源・開発機器・導入機器・ライセンス費用などが該当する。料金・資金などの金銭はリソースとみなさず、リソース調達の手段として扱...

≫続きを読む

10.6. 見積もり ハッピィ・エンジニアリング

 スケジュールを作成する上では、作業量と工数・所要時間を十分に見積もる必要がある。一般的なプロジェクトは、実現性を無視して、納期から逆算したスケジュールを作成している。さらにそのスケジュールを維持するためのリソースが計画されることもない。このようなプロジェクトは、誰もが「無理」だという意識を持ったま...

≫続きを読む

10.7. スケジュールの作成 ハッピィ・エンジニアリング

 スケジュール作成においては、カレンダー、すでに作成されているネットワーク図、WBSのワークパッケージに対応して見積もった所要時間を使用する。まず、ネットワーク図に所要時間を埋めていく。 この状態のスケジュールは、まだまだ完成とはいえない。その理由のひとつは、納期とのギャップ、もうひとつはリソースへ...

≫続きを読む

10.8. 進捗管理 ハッピィ・エンジニアリング

 進捗管理の大前提は、予定と実績のずれを定量的に把握しスケジュールを補正しながら進捗を管理することである。前節までの作業において、作業内容が明確化され、適切なリソースを割り当て、現実的かつ定量的なスケジュールが完成しているはずである。さらに、それらは、「8/80ルール」や「5人日分割」などで、進捗状...

≫続きを読む

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング