見積もり評価
見積もりは難しいですね。プログラム規模の見積もりでしたらそれでも何とかなりますが、プロジェクト規模の見積もりとなると対象要素が多すぎてまったく絶望的になります。加えて、対象要素がくまなく洗い出されても、それぞれに不確定要素、攪乱要素をはらんでいますから、思惑通りに行かないことが多いのであります。とはいえ、可能な限り見積もり要素を洗い出し、見積もりの対象にし、対象毎に見積もり根拠を確認しながら進めていけば、所詮人の頭に浮かんだものしか作らないのですから何とかなるのではあります。もちろん決めたことについて責任を明確にすることを忘れてはいけません。実際多くのシステムは紆余曲折を経ながらなんとか完成しています。
と、このように言ってしまいますと、いとも簡単のように聞こえますが、このような作業を基本動作として行うのはやはり難しいことです。
ということで、見積もりもまたプロジェクトレビューの仕組みを使って精度アップを図ることになります。
システムの利用範囲が広がり、利用技術もオープン化の進展で高度化し、プログラムを完成させるだけではシステムを稼働できない時代です。しかし、依頼されるシステム開発案件の元受となることが多い開発受託者側のアプリケーション開発担当者は、プログラムエンジニアであることが多く、見積もり作業がプログラムプロダクトの製造中心に検討されることになりがちです。エンタープライズ系事務システム開発では特にその傾向が強いといえます。
また、見積もりは、先に指摘したように、仮定、仮置きの要件、攪乱要素の配慮などについて漏れたり、過小評価になりがちです。加えて、ともすれば開発受託者側の理想の条件で計画し、これでいくしかないと、気合のみの天動説的見積もりになることすらあります。
つまり、システム開発の見積もりは大きく変動してきますので、冷静な目で検証し、いくつかの展開ストーリーを用意し、コスト面での準備をしておくことが必要です。開発の途中で障害時停止許容時間が変更になったらサーバーを買い増ししなければならないこともあります。コンピュータセンターの法定点検によりコンピュータを止める日があることに気がつき、完全365日稼働可能なセンターに運用をアウトソースしなければならない事も出てきます。これは機器などのコストだけでなく、検討手配要員コスト、システム対応コストなどにも影響してきます。
このようなチェックは、こういった観点をポイントとして用意したプロジェクトレビューによって行うのが効果的です。間違っても担当者だけにクローズして進めてはいけません。
システムエンジニアは専門家ですが、どんなことでもオールマイティとはなかなかいきません。
