|
| |
| 開設２周年・１００万アクセス記念 |
2002.9.30 |
| 開発のたびに「インパール作戦」を敢行−その１ |
根拠地を山の中腹に持つ某事業部では、製品開発のたびに「インパール作戦」が敢行されている。「インパール作戦」に陥る理由の多くは、開発マネージャの経験不足または自己保身の結果であるが、失敗のツケは開発リーダに押
し付けられ、根本的な問題の解決は常に先送りされている。
[補足]インパール作戦とは、第二次世界大戦中に日本軍が敢行した軍事作戦である。戦況を一切考えず、精神力だけでことを押し切ろうとした結果、日本軍自体のみならずその捕虜にも多数の犠牲者を出したとして知られている。
|
ある事例（例に漏れずこれも競合他社の後追い）では、製品の基本設計（どのくらいの利用者が同時にアクセスするか、その場合の性能目標として応答時間を何秒以内にするのか、利用者が使用する環境としてどこまでのバリエー
ションを考えるのか）をまったく検討しないまま、納期だけが先行決定し、納期遵守を優先するあまり「まず、動く
ものを作る」方針のまま、機能設計も満足に行わないで製品開発を進めてきた。
しかも、開発リーダが試算の結果必要とした開発要員の数より少ない数で開発作業を進めることになってもスケジュールは変えず、無理なスケジュールで開発を敢行した結果品質確保のためのレビューを行う時間を確保できないまま作業が進んでいった。その後、まるで数を合わせるかのように開発メンバを追加したものの、既に手遅れとなっていた。
開発の最終段階になって慌てて会合を頻繁に開くようになったが、開発マネージャは、開発初期段階として正当な手順を踏まなかったこと、製品の規模や開発チームの開発力を客観的に判断し早めに納期を現実的な納期に変更しなかったことを棚に上げ、何か問題が指摘されるたびに
「リーダが何も仕事をしていないからだ！」
「問題ばかりずるずる先に延ばしてリーダはいったい何をやっているのだ！」
「検査部門から何か言われたらどうするんだ、こちらが恥をかくじゃないか。」
「このままいくとやばいじゃないか」
とののしり、会合の場は開発リーダつるし上げの場でしかなかった（本来なら、知恵を出し合って問題解決策を出す場であるべきであるのだが）。（つづく）
|
|