Tweet
- 岡本 興一
- ウィジット株式会社 代表取締役
- ITコンサルタント
方法としては、テスト工程を圧縮することで、システムの品質を下げてでも、コストを挙げずに、納期以内で完成したことにしてしまうのです。
しかし、これは絶対にやってはいけません。
なぜなら、テストを圧縮するとシステムの品質が下がるからです。
バグと呼ばれる不具合が大量に残ったまま、完成したとごまかすことになります。
そうして、無理矢理本番稼働させたシステムで、実務を行っている時に不具合が出ます。
最悪の場合、ビジネスそのもに大打撃を与えてしまうことも考えられます。
さらに、不具合が内包された状態で動かすのですから、稼働後に様々な修正が必要となります。
稼働後の修正をするとなると、システムを止めることができなかったり、深夜にしか作業ができなかったり、修正を行う事によって作られた新たなバグにより、より大きな問題を起こすことがあり得ます。
すなわち、稼働後の修正は、非常に複雑になる上、対応が難しくなるので、稼働前の修正に比べてコストがかかるのです。
これは、プロジェクト期間を延長し、コストを余分にかけてきちんとテストを行い、稼働させるよりも、間違いなく大きなコストになります。
したがって、プロジェクトの遅れがあった時、品質を維持するために必要な工程を削減することは絶対に行ってはならず、そんなことをするのは、問題の先送り以上に、問題を大きくしてしまうことであると認識しておかねばならないのです。
なお、こうした問題があることから、プロジェクトの計画をたてる時、必ずバッファとなる部分を考えとく必要があります。
デッドラインを設定したら、それより前にマイルストーンを設定する。
マイルストーンから、デッドラインまでの期間をバッファとするのです。
ただし、このバッファは、プロジェクトメンバーで共有するべきではありません。
プロジェクトマネージャだけで考えておかないと、現場の作業者はバッファを前提として仕事を進める癖があるからです。
集客につながるホームページ
ネットとセキュリティ〜ウィジット株式会社
岡本興一
