読者です 読者をやめる 読者になる 読者になる

プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

プロマネは「原価計算を取り戻せ」

システムの工数見積とは統計である - プロマネブログ

前回からの続きです。

 

今回は

の2本立ての見積もりの話の2本目です。

 

なので、受託開発イメージなので悪しからず。 

 

前回記述の通り、現状工数見積するためには「経験」が必要と書きました。

 次は、実際のチームの活動予算である原価について考えてみたく。

 

開発原価を改めて考えてみる

システム開発における開発原価とは、システム開発に関わる開発側費用であり、所謂システムの商品原価ですね。

 

オッサンは頭のなかでは以下の様な数式で組み立てて計算してます。

 

開発原価 = 見積工数(前回記事のやつ) × 生産性変動 × 単価 × リスク係数

※インフラなどがある場合は違う計算となります。

 上記はアプリケーションのみ対応の想定です。

 

 

生産性変動とは、次の案件を実施するに当たって予測される生産性の変動割合です。

メンバーの入れ替わり、新規ツール導入、開発手法の変更やドキュメントの整理などから、次回案件の推進に当たって生産性が増減するため、その増減分の補正を行うための想定値です。

う~ん、このチームなら。。。前回よりもみんな成長しているので、生産性は以前の1割増しで行けるはず!

決め手は勘あるのみ。

 

リスク係数は突発的な体調不良などへの備え、要件のブレ、未確定事項などの見積変動などを見込んでのバッファです。

今回は、要件確定にちょっと自信がないので上積みしようかな。。。

決め手は度胸。

 

単価は、開発者一人頭おいくら万円というアレ

 

となります。

基本は工数と単価の掛け算ですけど、それに生産性やリスク変動などを考慮加えた形です。実際の計算はもっと複雑ですけど、概念だけなら前述みたいになります。

 

原価決定に必要なのは、

  • 勘の生産性変動
  • 経験の工数見積
  • 度胸のリスク係数

というわけです。ここでもKKDですね。

 

原価計算できる情報はPMしか持ってない

さて。原価計算の要素についてもう一考。

 

生産性変動ですけど、これって言い換えれば、現在の開発チームの状況です。

  • 開発キーマンがいなくなったから 、生産性が低下している
  • 新規ツールを導入したので生産性が向上した
  • メンバーのスキル底上げができたので生産性が上がっている

こんな情報は毎日チームのメンバーと向き合っているリーダーぐらいしかきちんとは把握してないものです。

外野から到底知りうる情報ではありません。

 

またリスク係数ですが、洗い出しができない場合はざっくり定数を掛ける場合がありますが、きちんと分析しようとすると以下の様な要因からリスクの大きさを想定します。

  • 要件のブレ具合。未決事項などが多い場合はリスク上乗せ。未決事項なしであればリスクなし。大体工程が後ろなほどリスクは少なくなる。
  • 対応スケジュールと密度。スケジュールに余裕が無い場合は、金銭面でのリスク確保しないと破綻の可能性がある。
  • 新規技術など、対応内容中に含まれる未検証の事象。当然未検証が多ければ多いほど、リスクは高くなる

で、これらリスクの有無の判断は、最終的にはリーダであるPMがやれる!といった度胸で判断するしかありません。いずれも現状、リスク量を解消でき無いからです。

 

 

原価見積とは、チームの活動計画そのもの

さて、いろいろ書きましたが、結局のところ原価見積とは、プロマネがプロジェクトをどのように動かしていくのか、という活動計画を考えるのに等しいです。

案件を、チームをどのように動かしていくか、そのために必要な予算はいくらなのか、という計画をたてるのと一緒です。

 

であれば、これをプロマネ以外の営業ができるわけはありません。

正直、「炎上プロジェクトの責任はプロマネが9割 - プロマネブログ 」のブコメ欄で「プロマネが担当した段階で炎上案件だった」みたいな声が幾つもありましたが、オッサン正直信じられませんでした。ここで書いた通り、プロマネ以外が原価を見積もることはできないから。もし、原価を営業が見積もったのなら、その営業がプロマネです。これでは、組織として無理があるんじゃないかなと思います。(まあ、火消しなら仕方ないかあ)

 

ちなみに、赤字案件自体はありえます。上記の原価見積を顧客に提示する際には更に価格見積を行いますが、この時、顧客と金額が折り合わなければ、営業側の方で戦略的に赤字で受注するなんてよくあります。

あくまで、プロマネ提示の原価は確保の上でですよ。

 

原価を減らしたければ、営業はプロマネときちんと合意をとるべきです。相談次第で、チームの活動計画を変更することで検討することは可能ですし、事前の検討や制約事項の付与によりリスク係数を減らし減額することも可能です。

それをせずに一方的に原価減額や原価の上限設定は行うべきではありません。

そして本来であれば、原価削減は生産性変動により対処するべきです。チームの生産性向上できるような措置を導入し、次回以降の案件の原価削減を図るべきです。これはプロマネの仕事として常時心がけるべきでしょう。これサボってたら営業は文句言ってもいいと思います。

 

原価見積までは開発の持ち物。プロマネの仕事。

価格見積からは営業の持ち物。営業の仕事。

こういった役割分担が適切な製販関係かなと思います。

まとめ

というわけで、前回に続き原価見積もりの話を書いてみました。

 

本文中でも思いますが、原価見積こそ、プロマネしかできない、プロジェクト計画の花だと思います。適切な原価見積が、プロジェクトの円滑な活動と、炎上を防ぐ最大のポイントだと思います。

 

これをもし営業が行っているのであれば、ぜひともプロマネはメンバーのためにも仕事を取り戻すべきかなと思います。見積は愛なんです。

 

 

(開発メンバーの)微笑み忘れた顔など 見たくはないさ

原価見積(アイ)を取り戻せ・・・

 

 

※長文書きましたが、これが言いたかっただけなんですよ。最後はネタ切れ。。。

 

 

以上

広告を非表示にする