最近わたしは、ソフトウェア開発プロジェクトを蝕む10の典型的な過ちについての記事を書いたが、その後、読者から数多くの貴重なコメントを受け取った。今回は、TechRepublic読者からのフィードバックを集めて、さらに10個の典型的な過ちをまとめた。
ある読者は、「プロジェクトマネージャーやチームマネージャーがノーと言えないと、要件変更があまりにも頻繁に発生してしまう。『イエス』と言うべき時と、『ノー、次のバージョンまたはアップデートの時まで待って下さい』と言うべき時をわきまえていなければならない」とコメントしてくれた。彼は正しい。要件変更は、プロジェクトにとって想像以上に大きな問題になる場合がある。問題なのは、単に作業が増えるということだけではない。問題なのは、もともとの設計では、その新機能や新要件は考慮されていないということだ。要件を拡大するのは構わないが、実装にかかる時間は、その要件が事前に分かっていた場合にくらべ、はるかに長くなってしまう場合が多い。これは記事のコメントの中でもっとも評価が高かったが、それには十分な理由がある。
要件変更と似た問題に、プロジェクトの仕様が大きすぎるというものがある。次の通り指摘をくれた読者がいる。
「多くのプロジェクトは単に規模が大きすぎ、カバーする範囲が広すぎる。多くの場合、仕事の範囲が大きくても、一歩ずつ進めていった方がよい。明確に定義された、管理しやすい作業群を実行することに集中し、先に進む前に土台を固めていくべきだ。多くの場合、巨大な『ビッグバン』データの移行が失敗する原因は、その複雑さか、エンドユーザーが単にプロジェクトの完了に必要な同時に起こる変化を吸収しきれないことだ」
また別の読者は「わたしは、あるソフトウェア開発プロジェクトを離れたところだが、そのプロジェクトでは、わたしはプログラマーではないと言われ、議論の輪の中から閉め出されていた。わたしが抱えていたプロジェクトは他のメンバーに分担される予定だが、わたしが議論に参加していなかっため、その多くは書き直される必要がある。議論から閉め出されていたので、わたしのプロジェクトは彼らの標準に準拠していないのだ」と述べている。
CNET Japanの記事を毎朝メールでまとめ読み(無料)
ZDNET×マイクロソフトが贈る特別企画
今、必要な戦略的セキュリティとガバナンス
ものづくりの革新と社会課題の解決
ニコンが描く「人と機械が共創する社会」