概算見積を通して感じること
わたしは、某金融機関様のシステム保守を担当しています。立場としては、サブリーダーとして位置づけられています。実装、実作業もしますし、プロジェクトのマネジメント、推進も行っています。
保守とは言っても、稼動済みシステム、アプリケーションに関するエンドユーザー様からの照会対応、トラブル対応、制度変更に応じた対応、新業務開始に応じた対応、提案が実った対応……等があります。
わたしの会社自体は、1月から新年度が始まっているのですが、お客様は4月から新年度が始まるため、今ちょうど、新年度のシステム投資案件の「概算見積」が佳境を迎えています。
「概算」とはいえ、お客様へ提出する正式文書であるため、ここで出す数字はこの後ついて回る数字になるので、気を抜くことはできません。
お客様サイドでは、さまざまなシステムの「概算」を集計し、新年度予算の総額と照らし合わせながら、新年度のシステム投資案件を絞られます。
平たい言葉で言うと、後にやってくる「正式見積もり」では、よほどのことがない限り、「概算」を超えた数字を出すことは難しくなります。
もちろん、決まっていないこともありますし、詳細が不明な要件もありますので、前提・制約を置いて算出することになります。ユーザー様などにヒアリングし、できる限り有効性のある前提・制約を明示するのですが、ユーザー様にとっては「概算」という意識があるため、なかなか要件定義局面のように詳しいお話にまで踏み入ることができない場合が多いです。
できることなら、案件を、要件定義とそれ以降の局面でわけ、まずは要件定義のみしっかり行い、この間のコストは、投入した人数＊期間で頂き、それを基に算出した以降の局面の工数を「見積」として提示するほうが、案件に関わる人の幸せにつながるのではないかな？ と感じます。
とはいえ、現実的に、プロセスとしてそうなっていないわけですから、工夫が必要になります。
概算見積をお客様に提示する前にも、QA（QualityAssurance）評価を受ける必要があるのですが、小規模の案件では部長レビューで済んだり、大・中規模の案件、複雑な案件、新製品を使う案件……等は、QA担当のレビューを受けます。
わたしは、これまで、今担当させていただいているお客様以外にも、大きな案件に関わることはありましたが、ただ担当者として関わることが多かったため、見積を算出することはあっても、それを取りまとめ、QAを意識する機会は少なかったです。
今、概算見積をしている案件は、中規模でなかなかQAレビューが通らず、困っています……。
さまざまな指摘があります、正直「そんな細かいことまで……概算やん……」と思うものもあります。
しかし、上流工程の「ぶれ」は、下流工程では「大きなぶれ、大きなコスト」として跳ね返ってきますので、概算見積時点でつじつまの合わないことは、案件開始後には、「大きなぶれ、大きなコスト」として跳ね返ってきます。
「概算」だけど、得られる情報の範囲で「詳細に」「きちんとしたロジックで」が必要だと思っています。
QAレビューでの指摘、それから思ったこと、感じたこと、考えたこと、理解したこと、それらを次回から整理してみたいと思います。
こちらにもどうぞお越しください。ちあきの場所(ありか) http://nishi3.info/chiaki99/