まずは、基本的なプロジェクトのコスト構造を理解しよう❷ | 設計開発
itpjstudy
6回シリーズの第2回目です。以前の回でお話しましたが、コスト見積をするためには、まず工数を算出することが必要です。そして、その工数を出すためには、工数を決めるための見積前提を理解して、設定することが重要です。
今回は、設計開発です。
なお、ここでの前提はウォーターフォールになります。大規模なエンタープライズシステムに関しては、依然ウォーターフォールが多いと考えるからです。アジャイルについては、別の回で取り上げたいと思います。
設計開発フェーズのタスクは、プログラム一覧をベースに決まっていく
設計開発のタスクは、基本的にプログラム単位に行われます。そのため、設計開発の工数を出すロジックはシンプルで、プログラム一本あたりに掛かる工数を出すだけです。
そこで、スタートは、プログラム一覧を作成することになります。後でも、お話しますが、このプログラム一覧をどれくらいの精度で用意できるかが、見積の精度を決めることになります。
工数マトリクス
精度の高いプログラム一覧が出来たら、工数を出すのは簡単です。
多くのITパートナには、過去に多くの設計開発の実績がありますので、たいてい各社独自の工数表を持っています。それに照らし合わせて、設計開発の工数を出すだけです。
ちなみに、なぜ比較的容易に工数が出せるのかについて、少し説明します。
下記の図で分かるように、プログラム設計開発は、基本設計が決まれば、あとはITパートナ内に閉じて作業ができます。外部からの影響を受けにくく、極めて工業的に作業を進めることができるため、開発手法や工数算出のためのノウハウを蓄積しやすいのです。
ITパートナ内に閉じて作業できるということは、設計開発のコスト削減にも役立ちます。例えば、オフショアの活用です。
オンショア・オフショア比率
工数削減にはなりませんが、単価を下げるために、オフショアを活用することは欠かせません。
ただ、プロジェクトによって、オフショア活用の度合いは、かなり違いあるように見えます。この回では、オフショア活用比率を上げるためのノウハウは割愛しますが、どの程度オフショアできるか、オフショア率を上げるために、できることがないかを考えることは重要です。
もっとも、最近は、オフショアの単価も上がってきていますし、AIによる自動コーディングも広がってくるでしょうから、オフショア活用のあり方も変わってくるかもしれません。この辺りについても、お話しできる機会があればと思っています。
さて、基本設計さえ決まれば、あとの工数見積はシンプルとお話しましたが、この「基本設計さえ決まれば」の部分が実は難しい。次に、この点について、お話します。
見積は段階的に上げていくもの
どういったプログラムを作らなくてはいけないかは、プロジェクトが始まる前は、まだ詳細には決まっていません。
フェーズを進めていくことで、大きな業務改革の方向性などから徐々にブレイクダウンしていきます。そうして、基本設計書が出来上がり、サインオフされて確定することで、内容が確定します。
実は、この過程で、見積が大きくなっていくことがよくあります。
構想立案フェーズのときは、もっとシンプルな仕組みにできると思っていたけど、基本設計フェーズに入ってから「現行システムの機能は担保して欲しい」と言われて、機能が複雑になってきた。
そのため、フェーズごとに見積を取り直して、プログラムやプログラム一覧がどのような状態になっているのかを確認した方が良いです。それにより、元の想定に戻るように、ユーザ企業とITパートナで議論を進めるべきです。
基本設計フェーズに入ってから、開発工数の見積が膨らんでいます。予算上限を超えてしまいますし、そもそも基本設計の工数も足りなくなります。何か対策を打ちませんか。
それは良くないですね。本来のプロジェクトの趣旨に立ち返って、本当に必要なものかどうか再確認するようにします。
結果的に、機能が膨らんだ状態を受け入れたとしても、こういった議論がなされて合意に至れているかどうかは重要です。
この辺りが、曖昧なまま進んでしまい、後で大変な目に会うことも多いです。
段階を踏むことの重要性
世の中には、基本設計フェーズがなかなか終わらずに、見切り発車で開発に着手。そのまま、テストフェーズにはいってしまうプロジェクトがたくさんあります。
最後につじつまを合わせられたプロジェクトもありますが、もっと大変な目に会っているプロジェクトも多いです。
基本設計がなかなか終わらないということは、基本設計工数が膨らんでいるということであり、開発以降の工数も膨らんでいるということだからです。
一方で、きちんと工数見直しを行っていませんから、後続の開発・テストフェーズのプランは正しく見直されません。その結果、テストフェーズで問題が一気に噴出し、延伸を繰り返すことになります。
どのようにこの事態を防ぐのか、リカバリするのかについては、またどこかでお話したいと思います。今回は、基本設計は非常に大事ということを覚えておいてください。
設計開発の工数見積のやり方は、比較的簡単です。プログラム一覧が正しく出来ていれば、工数マトリクスに照らし合わせて、工数算出するだけです。
一方で、プログラム難易度などを見誤って、工数を外すことも大変多いです。工数見積をするうえでは、この特性を深く理解をしておくことが重要です。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
