ソフトウェアの開発金額って？

質問

あるシステムを請負で開発中なんですが、開発工数の考え方について発注元と食い違いがあり、困ってます。
その開発は、発注元の事情でリリースまで全く時間的余裕のない状態でスタートせざるを得なかったため、
わが社ではその分野の業務知識のないプログラマを投入せざるを得ず、代わりに経験豊富な上級SEまで緊急投入して、
厳しい納期に対応する、という方針で進めました。

私はこのような場合、通常の開発に比べて
・投入した上級SEの工数
・品質を保つための社内会議や設計書／テストレビュー等にかかる工数
が増え、その分は当然そのままソフトウェアの開発費用に載せられるものだと思ってます。

ところが発注元の認識は
「スケジュールが厳しくても、成果物としてのソフトウェアの機能は変わらないのだから、工数に載せるべきではない。
どんな人（『業務知識のないプログラマ』や『経験豊富な上級SE』）を使うかはこちらには関係ないことだ」
ということで一貫しています。

「ソフトウェアの価格＝作成する機能の積み上げ」という考えがあるのは知っています。
「同じ機能のソフトウェアなのに、開発する会社の事情で工数が変わるのは困る」というのも理解できます。
しかし、厳しい納期が原因で開発原価が膨らむのは事実ですし、
納期も要求定義の一つだと思いますから、それによって開発金額がかわるのは当然ではないでしょうか？
いろんな立場の方からご意見を伺いたいです。

回答No.1

sanori · ベストアンサー

時間×人数×１万　のオーダー（桁）ですかね。

そして、
そういう場合は、
「特急料金」という制度を、あなたの会社の「商品」としてしまいます。

標準的な工数に応じた報酬　×　特急料金率

そういうのを、最初に、どーんと提示しておかないと、
いくら交渉しても、駄目です。

仕事が速いほど、損します。

お礼

ご回答ありがとうございます。
「特急料金」という考えも制度もありませんが、
「納期の制限も請求対象となる」という点では私と同じですね。
問題は
＞最初に、どーんと提示しておかないと
という進め方でしょうか。

回答No.4

galluda

がると申します。基本的に受注側の、つまりは質問者さんと同じ立ち位置の人間です。
とりあえずこういった事故は結構多発するものなのですが。質問文を拝見しているかぎりですと…途中から、というよりも、一番初めの金額すり合わせのタイミングですでにミスがあるように見受けられます。

とりあえず、私的には「高いSE使ったんだから単価上げて」も「成果物基準で金額を払う」も、どちらも理解できてしまうので。

ただ、原則として発注元は「可能な限り値段を下げてくる」のが、彼らのお仕事の一部だと思います。
ですので、そのあたりについては(可能な限り作業前に)きちんとネゴをするほか、「仕様変更や追加による工期の遅延ないし作業量の増加」に対してもある程度契約書でやり取りをしておくことをお勧めいたします。

ちなみに他の方もかかれてますが。無理無理な納期であれば「特急料金」とか「超特急料金」とかを乗せるのも一つの手法です。
私は係数で掛け算をしますが :-P

お礼

ご回答ありがとうございます。
おっしゃる通り、初動時に工数の言質をとっていなかったのが私の最大のミスですね。
口頭では概算口数について同意してもらったはずなんですが、以前からお付き合いのあった会社という事情と
あまりのスケジュールのきつさにより、書面での確認を後回しにしてしまいました。
せめてもっと早い時期なら
「『特急料金係数』がダメなら、受注できません。着手済みの仕様書やプログラムも全て破棄します」
とも言えたのですが・・・。

回答No.3

fallen_angel

ご質問者様の会社、またはご質問者様の中で、基本的な開発工数の見積基準は、有りますか？
　僕はプログラマーの立場で発注する立場の時期があり、機能を細分化しておき、１機能▲個の関数、１関数●Ｈと自分で見積ちり、外注への発注時の工数は、打ち合わせなどがあるので、外注先や担当者のレベル毎に一定の係数掛けて見積をチェックし、上長に承認をもらっていました。
　ご質問者様とは逆の立場であった訳ですが、基数を持つ事で見積精度を上げました。
　またテストについては各機能の各関数毎のホワイトボックステストを強制して品質確保に努めました。
　逆の立場のケースですが、参考になるでしょうか？

お礼

＞ご質問者様の会社、またはご質問者様の中で、基本的な開発工数の見積基準は、有りますか？
基本的にはWBSを基にした作業内容から機能単位の工数を算出します。
（機能毎の作業工数は、画面帳票数／難易度／入出力の数などで判断します）

私の見積では、そこに短納期対応の「レビュー」や「品質管理」の工数を入れていますが、
発注元の考える「開発工数の見積基準」ではそれが考慮されていないため、双方のズレが発生しています。
fallen_angelさんの書かれている「外注先や担当者のレベル毎に一定の係数掛けて」という要素が
入っていない状態なのです。
発注側でfallen_angelのように進められるなら、受注側もやりやすいのでしょうが・・・。

回答No.2

fallen_angel

プロジェクト開始時期の双方の見解が異なるようですね。僕もいずれは同様なケースが出るだろうと勉強中の身です。

　『機能数×時間』で単純に価格が決められているようですね。

　同じ機能数でも投入スタッフのレベルと人数により工数が変わるのですから、担当者の数とレベルを工数の計算要素に入れておかないといけませんね。

　機能数の算定は妥当なのでしょうか？初期の打合せでは概略機能のみで詳細は掴めないと思いますが。

　またリリースまでの機会損失とリリース後の改修による損失、どちらを依頼主が採用するかで、話を進めるのではいかがでしょうか？

　依頼主が要求するの納期と品質を固持する為には、これだけの人数追加が必要となり、費用追加が必要です。といったストーリーも有りですよね？

　機能毎の工数を算出し、基本となる開発者の工数から、逆に人数を提示しておく。（社内では、人数分の工数を消化する為に上級ＳＥを投入）

お礼

ご回答ありがとうございます。
＞同じ機能数でも投入スタッフのレベルと人数により工数が変わる
私も同じ考えですが、発注元には拒否されています。

機能数や機能定義については合意しているのですが、
発注元では「これだけの人数追加が必要」や「基本となる開発者の工数」という考え自体、
納得してもらえません。