logo

ソフトウェア開発プロジェクトを蝕むさらに10の過ち

Justin James (TechRepublic) 翻訳校正: 石橋啓一郎2012年07月02日 07時45分
  • このエントリーをはてなブックマークに追加

 最近わたしは、ソフトウェア開発プロジェクトを蝕む10の典型的な過ちについての記事を書いたが、その後、読者から数多くの貴重なコメントを受け取った。今回は、TechRepublic読者からのフィードバックを集めて、さらに10個の典型的な過ちをまとめた。

1.「ノー」と言えない

 ある読者は、「プロジェクトマネージャーやチームマネージャーがノーと言えないと、要件変更があまりにも頻繁に発生してしまう。『イエス』と言うべき時と、『ノー、次のバージョンまたはアップデートの時まで待って下さい』と言うべき時をわきまえていなければならない」とコメントしてくれた。彼は正しい。要件変更は、プロジェクトにとって想像以上に大きな問題になる場合がある。問題なのは、単に作業が増えるということだけではない。問題なのは、もともとの設計では、その新機能や新要件は考慮されていないということだ。要件を拡大するのは構わないが、実装にかかる時間は、その要件が事前に分かっていた場合にくらべ、はるかに長くなってしまう場合が多い。これは記事のコメントの中でもっとも評価が高かったが、それには十分な理由がある。

2.プロジェクトが大きすぎる

 要件変更と似た問題に、プロジェクトの仕様が大きすぎるというものがある。次の通り指摘をくれた読者がいる。

 「多くのプロジェクトは単に規模が大きすぎ、カバーする範囲が広すぎる。多くの場合、仕事の範囲が大きくても、一歩ずつ進めていった方がよい。明確に定義された、管理しやすい作業群を実行することに集中し、先に進む前に土台を固めていくべきだ。多くの場合、巨大な『ビッグバン』データの移行が失敗する原因は、その複雑さか、エンドユーザーが単にプロジェクトの完了に必要な同時に起こる変化を吸収しきれないことだ」

3.関係者を議論から閉め出している

 また別の読者は「わたしは、あるソフトウェア開発プロジェクトを離れたところだが、そのプロジェクトでは、わたしはプログラマーではないと言われ、議論の輪の中から閉め出されていた。わたしが抱えていたプロジェクトは他のメンバーに分担される予定だが、わたしが議論に参加していなかっため、その多くは書き直される必要がある。議論から閉め出されていたので、わたしのプロジェクトは彼らの標準に準拠していないのだ」と述べている。

-PR-企画特集