昨今のシステムは大変なコストがかかるネットワークをはじめとするインフラの上で動いています。さらに開発するアプリケーションも曖昧な要件と、意欲的な開発依頼者のおかげで、開発を始めてから膨れ上がる要件との戦いです。いくらでもお金を使ってよいなどというシステム開発があるわけもなく、またにシステム開発担当者はお金のことなどをあまり考えずにシステム開発に没頭する人が多いですから、コスト管理についてはプロジェクトレビューをうまく使って、気持ちよく担当者が仕事に打ち込めるようにしてあげたいものです。
見積もり評価
見積もりは難しいですね。プログラム規模の見積もりでしたらそれでも何とかなりますが、プロジェクト規模の見積もりとなると対象要素が多すぎてまったく絶望的になります。加えて、対象要素がくまなく洗い出されても、それぞれに不確定要素、攪乱要素をはらんでいますから、思惑通りに行かないことが多いのであります。とはいえ、可能な限り見積もり要素を洗い出し、見積もりの対象にし、対象毎に見積もり根拠を確認しながら進めていけば、所詮人の頭に浮かんだものしか作らないのですから何とかなるのではあります。もちろん決めたことについて責任を明確にすることを忘れてはいけません。実際多くのシステムは紆余曲折を経ながらなんとか完成しています。
と、このように言ってしまいますと、いとも簡単のように聞こえますが、このような作業を基本動作として行うのはやはり難しいことです。
ということで、見積もりもまたプロジェクトレビューの仕組みを使って精度アップを図ることになります。
システムの利用範囲が広がり、利用技術もオープン化の進展で高度化し、プログラムを完成させるだけではシステムを稼働できない時代です。しかし、依頼されるシステム開発案件の元受となることが多い開発受託者側のアプリケーション開発担当者は、プログラムエンジニアであることが多く、見積もり作業がプログラムプロダクトの製造中心に検討されることになりがちです。エンタープライズ系事務システム開発では特にその傾向が強いといえます。
また、見積もりは、先に指摘したように、仮定、仮置きの要件、攪乱要素の配慮などについて漏れたり、過小評価になりがちです。加えて、ともすれば開発受託者側の理想の条件で計画し、これでいくしかないと、気合のみの天動説的見積もりになることすらあります。
つまり、システム開発の見積もりは大きく変動してきますので、冷静な目で検証し、いくつかの展開ストーリーを用意し、コスト面での準備をしておくことが必要です。開発の途中で障害時停止許容時間が変更になったらサーバーを買い増ししなければならないこともあります。コンピュータセンターの法定点検によりコンピュータを止める日があることに気がつき、完全365日稼働可能なセンターに運用をアウトソースしなければならない事も出てきます。これは機器などのコストだけでなく、検討手配要員コスト、システム対応コストなどにも影響してきます。
このようなチェックは、こういった観点をポイントとして用意したプロジェクトレビューによって行うのが効果的です。間違っても担当者だけにクローズして進めてはいけません。
システムエンジニアは専門家ですが、どんなことでもオールマイティとはなかなかいきません。
この記事は参考になりましたか?
- 実務で役立つプロジェクトレビューの心得連載記事一覧
-
- プロダクト品質管理の効能
- プロセス管理の効能
- コスト管理の効能
- この記事の著者
-
菊島 靖弘(キクシマ ヤスヒロ)
独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター(SEC) リサーチフェロー。1975年東京海上火災保険に入社。以来30年間、損害保険、生命保険、確定拠出年金といった業務システムの開発に携わった他、東京海上日動システムズ取締役品質管理部長として、トラブル削減や、開発品質管理の向上を実...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア