一般的な見積もりの構造について考えます。
とはいっても業界によって異なると思うんですが、特にSIer的に考えていきます。
SIerは機器の導入やコンサルを売って食べてます。富士通や日立?、NECなどの大手はサーバーやストレージなどの機器も売っていて、それはそれは多くの企業に好まれています。
が、機器の話については少し置いておくとして、導入やコンサルについてスコープを絞りたいと思います。
機器導入やシステム開発について
機器導入やシステム開発は基本的に開発モデルを基にプロジェクトで実施する内容を建て付けることが多いです。
わかりやすいものは「ウォーターフォールモデル」とか、「アジャイル」ですよね。
この辺りは標準化されていて、共通了解を得やすいので利用されています。
とはいえ、さらにあなたのビジネスにフィットする開発方法があればそれを用いるのが最適かもしれません。
僕の感覚的な話ですが、ウォーターフォールモデルでは、「一定の成果物」を約束し、アジャイルでは「モノを動かすこと」を約束している印象があります。
その上でウォーターフォールモデルの見積もりについて考えていきます。
ウォーターフォールモデルって
ウォーターフォールモデルはわざわざ解説しませんが所謂「V字モデル」を基にその成果物を出すことを基本としてます。
なので、見積もりでは各工程の成果物をどれだけの粒度で検討されているかということが見積もりの出し手として重要です。
見積もり粒度について
方式設計書一つとっても、いかの項目あると思います。
- ヒアリング事項の検討
- ヒアリングシート作成
- ヒアリングシートのレビュー
- ヒアリング実施
- ヒアリング結果の受け入れ
- 方式設計書のアウトラインの作成
- 方式設計書の執筆
- 関係各社などの責任ポイントによるレビュー
があります。
出す時にはまとめて出してもいいと思いますが、内側ではWBS的に作業を分解して検討する必要があります。
(構造ができちゃえばあとは変数要素を当てこむだけです。そのあたりはまた別の機会に)
この辺りの粒度の細かさが見積もりの精度につながります。※とはいえ、この職業、見積もり通りに行くことって基本ないので「見積もりしてないのでNGです。」を多用すると客を失います。責任の所在を意識して判断されたし。
開発工程に則ってればいいってもんじゃない
ウォーターフォールとか、アジャイルといった開発モデルはSIer商売向けに開発されたモノでなく自社組織などで開発することを前提に検討されたものです。
なので、SIerビジネスの要素も足してあげる必要があります。
管理工数(道路整備のような、プロジェクトがスムーズに動くための間接作業)
- WBS
- 進捗管理
- WBSに書いたり、今どれだけ進んでるの？といったことを話したり、先行きを占います。この場合タスクの処理だけでなく心や体の健康も占いに混ぜたいところです。
- 定例会
- 部や課、プロジェクトチームで定期的に会話をします。会話内容は進捗の話がメインになりがちですが、主力のアラートを検知できる数少ない機会です。丁重に扱うやうにしましょう。チームビルディングの数少ない機会でもあります。
- 課題管理
工数の見積もりについて
この記事はこれが書きたかったんです。
要は、どうやって工数を見るの？って話なんですが、
最終的には
- 悲観値
- 標準値
- 楽観値
この３つをなんとなく出して、
(悲観値 + 楽観値 + 標準値 × 4 )÷6で出します。標準値を中心にしつつ、悲観と楽観でブレさせるみたいな感じ。
じゃあそれぞれの値はどういう数字で構成されるの？って感じですよね。
って考えると、作業の自体を崩して、そのプロセスに係る作業をめちゃくちゃ見える化しないと数字出せないなと言う感じ
細かく言うと、「最小の作業単位は 1タイピング 何秒か」ってことになってくると思います。
・調査する時間
・まとめる時間
・入力する時間
一体この作業の中で、自分は何をするんだろうか。そう意識を伸ばして作ることがとても大事だと思います。
そういった積み上げでやっとこ工数が出てくると思うんです。
そして、それが調子のいいとき・悪いとき、能力のある人、無い人などで悲観値・楽観値を計算して、工数をはじくわけです。
作業を細かく認識することが、制度の高い見積もりに繋がります。
また、細かく認識した見積もりにこだわり、それを軸に作業範囲の調整をしない方がいいことは言わずもがなです。
アジャイル開発の見積もりはどう作る？
アジャイル開発で見積もりをするならきっと準委任契約で時間精算が一番精神衛生上にいいかもしれないですね。
単価でドン。そういう感じじゃないですかね
書いてて思った小言
- 見積もり作ってる時点で深掘りレベル2,3くらいのWBSないと、因果関係として少し不誠実じゃね？
