ソフトウェアプロジェクトにまつわる神話

管理にまつわる神話

開発に必要な手順書も標準集も揃っている。必要なことをすべて部下に教えられないだろうか

手順書や標準集がある会社は多い。 しかし実際に利用されているのだろうか。開発者は存在に気づいているんだろうか。最新の開発状況における常識を反映したものだろうか。 また、完全なものだろうか。適応しているのだろうか。品質を重視しながら納期を改善するよう能率的に作業しているのだろうか。 多くの場合、質問の答えはすえてNOである。

スケジュールに遅れたなら、さらにプログラマを追加すれば取り戻せる

ソフトウェアカイア開発は、ハードウェアの大量生産のような機会中心の単純なプロセスではない。 直感的には、人を増やせば作業のスピードが上がるように思われる。 しかし、新しい人を追加すれば、それまで働いていた人々が新入りの教育に時間を取られることになり、開発に費やす時間の総量が減ることになる。 人を追加してもよいのは、十分計画し、調整した場合だけである。

ソフトウェアプロジェクトを第三者機関に委託すれば、リラックスでき、その機関にソフトウェア開発を任せられる

社内でどのようにソフトウェアプロジェクトを管理・制御するのかわからなければ、ソフトウェアプロジェクトを委託する際にはいつも苦労する。

顧客にまつわる神話

プログラムを書き始めるには、大まかな目的があれば十分である。詳細は後で決めればよい。

要求について必ずしも包括的かつ安定した記述が行えるわけではないが、目標についてあいまいに記述することは災害の材料となる。 通常繰り返し導入される明白な要求は、顧客と開発者との効率的かつ継続したやり取りを通して作成することができる。

プロジェクトに対する要求は常に変化するものだ。ソフトウェアは融通がきくため、容易に変更できるだろう

ソフトウェアへの要求が変更されてしまうことは事実である。しかしその影響は、変更要請の時間にかかっている。 設計やコード作成前の初期段階で変更要求が出された場合、コストへの影響は比較的小さい。しかし、時間が経過するとコストへの影響は急速に大きくなる。 リソースが確約され、設計のフレームワークが確立され、変更によってリソースの追加や主要な設計の修正を必要とする大変動に発展する可能性がある。

技術者にまつわる神話

プログラムを書いて動くようにすれば、それで仕事は終わりだ

「コードを早く書き始めれば始めるほど、終わらせるまでにはより長い時間がかかる」という格言もある。 ソフトウェア産業に関するデータによれば、ソフトウェアに費やされる費用のうち60〜80%が、最初に顧客に引き渡した後に発生する。

プログラムを走らせるまでは、その品質を評価できない

最も効果的なソフトウェア品質保証の手法は、プロジェクトの開始から公式技術レビューを実施することである。 レビューは、テストを行ってプログラムの不具合を見つけるよりも効率的な「品質フィルタ」である。

プロジェクトの成果物は、動いているプログラムだけで良い

プログラムは、ソフトウェアを構成している様々な要素の1つにすぎない。 ドキュメントは開発を成功させる基盤となる以上に、保守作業のガイドの役割を果たさねばならない。

ソフトウェアエンジニアリングを現場に適用すると、大量かつ不要なドキュメントを作成しなければならず、間違いなく作業が遅れてしまう

ソフトウェアエンジニアリングはドキュメントを作成するためのものではない。 品質を作りこむためのものであり、品質が向上すれば、手戻りが減少する。手戻りが減少すれば、納期が早まる。

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-