赤字ビジネスの利益供与について

じゅんたば さん

こんにちは

システム開発に於けます斯様な問題は、競争が激化している今日、多く耳にします。

鍵を握っているのが、見積りです。見積りの前提になった工数の上げ方の妥当性検討であります。見積り明細では、作業工程別（現状分析、要件定義、基本設計、詳細設計、試験、インストール及び環境設定作業、移行作業、運用保守等）におのおのの主要作業に於ける計上見積り工数や開発対象範囲にお客様とブレている場合が多く見受けられます。
　工数が結果として見積り以上掛ったからと言って、請求できるものではないと考えております。
　工数増の原因を明確にしなければお客様は納得しないと思います。

　契約時と規模（システム範囲、プログラム本数等）変わらなければ、認められない可能性が高く、規模が広がった場合でも結果からでは受け付けられないと考えます。この点ではそのプロジェクトマネージャーが開発中にお客様にお伝えし開発するか否か、求める責任があると考えていますし、それが一般的と思います。

　また、規模が同じでも、担当技術者のレベルであったり、開発に於ける効率を図ることも当然の請負方に責任があり、増加分を請求することは難しいと考えます。
　そうしたお客様との工数について、折々、技術面のみならず営業面でも動いてこれれた場合、お客様も考えていただけるのも一般的と思っております。

　つまり、開発に於けるＳＥは技術屋のみならず、営業としての力量も求められているのが実態かと思います。

　係る開発の背景が見えませんので上述のような回答になってしまいますが、例外を除いて利益供与には当たらないと考えます。

　例外：　以前に何十億もの開発費用と一般的に考えられる開発を￥１で受注したことが何社かありました。
しかし、本件はそれには該当しないと考えられます。

　さて、交渉の余地があるか否かは、契約で交わしたシステム範囲、規模と現況との比較を行い、それを基に１件ごとお客様と認識をすり合わせては如何でしょうか

　今後のことでは、上述いたしましたようなことに気をつけていけば宜しいと思います。

とここばさん

じゅんたばです。
早々に非常にわかりやすいお返事を頂きましてありがとうございました。結果としまして、例外を除き利益供与に当たらないことがわかりましたので安心致しました。

> 主要作業に於ける計上見積り工数や開発対象範囲にお客様とブレている場合が多く見受けられます。
> 　つまり、開発に於けるＳＥは技術屋のみならず、営業としての力量も求められているのが実態かと思います。

以上のご説明で、SEへの教育が重要であることがわかりました。
お客様と範囲にぶれがある場合、社内への早期報告、およびお客様との調整を図ることが重要であることを教育してまいります。

> 　さて、交渉の余地があるか否かは、契約で交わしたシステム範囲、規模と現況との比較を行い、それを基に１件ごとお客様と認識をすり合わせては如何でしょうか

今回の案件におきましては、「契約で交わしたシステム範囲、規模と現況との比較」を行い、調整をしてまいります。

ありがとうございました。

じゅんたば

じゅんたばです。

本当に暑いです。とうとう今日は一歩も外へ出ておりません。

さて、係る問題は、原因追及とその責任はどちら側にあるかと言う点で内部検討されることに期待します。

多い例をいくつかご紹介致します。
　．当初の開発機能が増えたことに因る工数増：
　・誰の指示による追加機能か
　・それがお客様の場合、ｓｅから追加機能であり有償である旨伝えたか
　・誰の承認で、開発に着手したか
　⇒お客様ご担当者とｓｅを越して直接ｐｇに依頼してしまう場合があります。
　この場合は、貴社の体制を突っ込まれますので、対策をお考えください。事前にｓｅまたは営業から商流の基本運用についてお話や体制図を下にお話してますと若干異なってきますが
　プログラマーは狭義な部分は理解してると思いますが、そのことがシステムのどこに影響するとまでは理解していません。この点もお考えください。
　・その機能は要件定義で出てこなかったのか
　⇒このことは、事前に契約締結していたとしても、要件定義書では明らかにして双方のコンセンサスを取っておくべきことと認識してます。（失礼ながら）

多少でも追加予算を頂けると良いですね

とここばさん

追記、ありがとうございます。
私も一日家にいました。。。
早速、社内で原因と責任の確認を致します。
その上で、お客様に少しでも負担していただくように調整いたします。
同じようなことを繰り返さない社内対策も実施してまいります。

> 多少でも追加予算を頂けると良いですね

ありがとうございます。がんばってみます。