ソフトウェア（アプリ）の価格はこのように算定されていた

このページは１９８６年「社団法人情報サービス産業協会　ソフトウェア価格問題研究部会資料」をhtmlに変換したものです。現状はおいてはこの資料のような問題はないと考えていますが、ソフトウェア導入に際して、参考になると考え作成しました

１．初めに

ソフトウエアに関する価値の認識は、「般産業のそれと比べ、まだ隔たりがあると思われる。例えば、経営の重要資源であるといわれるヒト、モノ、カネに対する投資について、一般産業では、価格に反映され、回収されることにユーザーの抵抗はないと思われるが、ソフトウエア産業においては、モノに相当すると考えられる技術およびノウハウが、必ずしも価格に適正に反映されていない。すなわち、経営の重要資源の価値が、価格の重要要素になりえていないのが現状である。
ソフトウエア会社が持つ技術力が、ユーザーに適正に評価され原価として回収できることは、ソフトウエア業が産業として発展することを意味し、ソフトウエア産業が、ユーザーの援助的役割から脱して、真のユーザー・ニーズに応えられることにつながる。しかし、技術およびノウハウの価値のとらえ方については、これといった決め手がなく、またどのようなソフトウエアを開発するのかさえ明確でなかったり、あるいは成果物に対する責任も明確でない場合も多く、発注サイド、受注サイドともに共通する一般的、客観的な価格の考え方、価格決定の基準、メカニズムをもちえていないのが現状である。
ソフトウエアの価格は、本来、需要と供給との関係によって決まるべきものであるが、ソフトウエアの流通を促進するためには、価値に関する適正な認識を広める必要があると考え、昭和54年度からソフトウエア産業振興協会で研究されてきた価格問題は、情報サービス産業協会に引き継がれて現在に至って いる。
ソフトウエアの価格には、プロダクト、あるいはシステムハウス、パソコンなどの価格形成もあるが、ソフトウエア業の売上げの80%以上が受託開発という現状であると同時に、今後の見通しでもあるので請負型のソフトウエア開発を取り上げ、原価主義をよりどころに検討した ここでは、その考え方を中心に、現実の営業の場で聞かれるいろいろな意見をまとめてみた。

価格算定方式

ソフトウエア開発費用の算定にあたっては、開発作業への対価を重点に考えた結果、開発工程別の価格算定方式とし、その費用算定の考えと方式を検討した。開発費用の算定には、他に、技術者個人の技術力を評価する要員別価格算定方式もあるが、これは、開発責任がない派遣を前提とした方式であり、ソフト ウエア業を産業としてとらえる考えと相容れないところがある。
工程別価格算定方式では、開発工程別に所要工数を見積もり、あらかじめ設定した工程別単価を掛けて、工程別の開発費を見積もり、積算することで開発費用を算出できる。
∑(工程別作業工数×工程別単価)十諸掛経費
諸掛経費は、開発に伴って各工程で発生する直接経費のことで計算機使用料、パンチ等媒体変換費用、旅費交通費、印刷費などを指している。
工程別の単価を設定するにあたっては、次のとおり、あらかじめ設定しておいた原価構成に人件費をあてはめ、技術者稼動率を考慮して、平均的な単価(これを基準単価と呼ぶことにする)を求める。この基準単価は、技術者1人当たりの平均的な売上高を意味している。
直接人件費/直接人件費比率/技術者稼動率/12カ月=基準単価
工程別単価は、工程別に要求される技術力をもとに、基準単価に重みづげをして求められる。

(1)原価構成とその割合

売上げの原価構成要素を、次のとおり想定した。

• 直接原価相当　直接人件費
  
• 直接原価相当　直接管理費
  
• 間接原価相当　販売費および一般管理費
  
• 間接原価相当　技術整備費
  

原価構成のうち直接人件費は、直接部門の給与、賞与、退職金、法定福利費、通勤費などを言い、製造原価の大部分をなすものである。
直接管理費：直接部門の間接要員人件費、および直接部門で使われる事務所費用、ソフトウエアおよびハードウエアの費用、印刷費、旅費交通費、通信費などの費用をいう。
販売費および一般管理費：いわゆる販管費であって、間接部門の人件費、物件費、一般管理費、支払金利などである。
技術整備費：蓄積された技術、ノウハウなどの価値を無形原価ととらえて、その技術向上のための投資と回収を明確にするために設定したものである。

(2)技術者稼動率

技術者の所定労働時間のうち、教育、有給休暇、事務処理などの非稼働時間を除く、直接生産的な作業時間を指し、その時間によって、会社の総費用に見合う売上げを上げる前提とした。 章七度

3.標準工程の設定

開発作業を明確にするため、表lのとおり、標準工程を設定した。

4.　1961年度工程別単価の試算

以上の工程別価格算定方式にもとづいて、61年度の工程別単価を試算すると、次のとおりである。なお、算定にあたっては、過去、何度か行った実態調査の結果を参考としたが特定のユーザーに片寄らずに、多くのユーザーから受注していう独立系のソフトウエア会社の例がほとんどであり、したがって、非常に多くのユーザー向けの実勢価格であると考えられるので業界の平均ととらえてもよいと思われる。

(1)原価構成とその割合

従来からの調査ならびに検討結果から、次のとおり、売上げ に占める原価構成とその割合を想定した。 直接原価相当直接人件費 直接原価相当直接管理費 間接原価相当販売費および一般管理費 間接原価相当技術整備費 利益相当

(2)直接人件費

IPA(情事拠理振興事業協会)の情報処理産業経営実態調査によればソフトウエア業の従業員1人当たりの人件費は、58年度、4、151千円であり、これに東京都労働経済局などの調査によるサービス業の人件費上昇率から、60年度の人件費を推定すると次の通り、4、642千円になる。 58年度人件費　　4、151千円 59年度人件費　　4、379千円（賃金上昇率　5.5％） 60年度人件費　　4、642千円（賃金上昇率　6.0％） 一方、当部会での実態調査によれば60年度のそれは、4、672千円であって同様であり妥当性が考えられるので、これから61年度の人件費を推定すると次の通りである。

(3)技術者稼働率

過去の調査による技術者稼働率は、70～85％に集中しているがあるべき姿を含めて考え75％とする。

(4)基準単価の算定

以上の数値を使って技術者1人当たりの必要売上高を求めると次のとおりである。 4、975千円/0.5/0.75/12=1、1005/人月 この端数を丸めて基準単価を1、100円/人月とする。

(5)工程別の重みづけ

工程別の重みづけは、ある意味で市場価格の反映でもあり、基準単価をプログラム設計工程の単価とすると従来の調査などから、 おおむね次の通りになる。 調査分析　1.8 システム設計・基本設計　1.8 システム設計・詳細設計　1.5 プログラミング・プログラミング設計　1.2 プログラミング・プログラミング作成　1.0 総合テスト　1.2 検収・マニュアル作成　1.0 検収・検査立会　1.0 保守　　別途

(6)工程別単価表の作成

基準単価に 工程の重みづけを乗じて工程別単価を求めると次のとおりである。 調査分析　1.980千円/人月 システム設計・基本設計　1.980千円/人月 システム設計・詳細設計　1.650千円/人月 プログラミング・プログラミング設計　1.100千円/人月 プログラミング・プログラミング作成　880千円/人月 総合テスト　1.320千円/人月 検収・マニュアル作成　1.100千円/人月 検収・検査立会　1.320千円/人月 保守　　別途 以上の様に求められた61年度の工程別単価は当部会がまとめた60年度の実績値の7～8％アップになっており実態とほぼ近い値と考えられる。

5.工程算定と見積

工程別価格算定式のもうひとつ要素である工程別算定については、従来からいろいろな場で検討されてきたが、こうすうが適正に算定できることこそが技術力の表れでもあるという事と、あらゆる業務に共通な一般式を設けるこできないという事は確認されている。あるユーザーから継続的に受注する場合は、作業内容、条件が限定されることもあり、慣習的に、お互いに問題のない工数が決まってくることもあるが、ふつう同じ開発テーマについて、複数のソフトウェア会社から出される見積は、違うことが多い。それは、無形のものをつくるという性格の作業であるのにもかかわらず、開発すべきソフトウェアとその成果物並びに開発環境条件などの、見積もり条件を明確にしきれないという、ユーザーサイド、ソフトウェア会社サイド双方のの問題である場合が多い。すなわち、不明確なところを残しながら契約を取り交わし、開発に着手ケースが多いと思われる。もしそうであればとらぶるは、起こるべきしておき散るといえよう。 実際に、ソフトウェア会社がユーザーから引き合いを受けて工数を算定し、見積り、契約するまではの手順は蓄積した技術を生かして図1の様な手順で見積まれる。 引合は、見積り条件の提示でもあり、ユーザーから発注仕様の形で示されることが多いが、開発環境が異なるソフトウェア会社から見れば、不十分であったり、あるいは、開発にあったって提案すべき提案すべき点も見られるので、発注仕様に忠実に見積もるものではなく、発注仕様を問題定義として受け取って、いろいろな提案と調整をこなう。工数を算定する事だけが見積でなく、この過程こそが実は見積であるといえる。 当然、見積条件のとらえ方によって、見積もる工数も違ってくる。従って、見積りの評価にあっては、工数の多少もさることながら見積条件をどのようのとらえたが重要である。 工数見積もりでは、まずステップなどの尺度で成果物のボリュームを見積り、それをもとに、それぞれの工程における自社の技術力を想定して、ステップ生産性、あるいは配員の想定、開発別工程の工数比率などいくつかの方法を組み合わせて、算定される。いずれにしてもソフトウェア会社がもつ技術と経験に左右されるところである。 代金の支払条件は、下請のとおり、工夫されている。 工数が見積もれるという事は、開発作業に関連して発生する諸掛経費が見積もれることであるので、工程別価格算定方式のとおり、開発費を求めることができる。しかし、ここで算出した開発費は、技術力が高いソフトウェア会社ほど、おそらく開発にかかる工数は少なく、開発費が低くなるという矛盾が出てくる。従って最終的な開発費は、技術料ともいうべきソフトウェア会社のもつ技術力を反映させて求めれる。技術料に相当するものとして、開発過程でおいろいろな問題へ対応したり、作業チームをとりまとめる管理力とか、高度な専門的技術力、開発経験があげられる。 これらの見積結果は、次の項目を含んだ見積書、あるいは提案書の形で整理できる

1. 開発すべきシステムの概要・目的
2. 開発すべきシステムの構成
   • ハードウェア構成
   • ソフトウェア構成
3. 開発作業の範囲
4. 開発スケジュール
5. 開発環境
   • ハードウェア開発環境
   • ソフトウェア開発環境
6. ユーザー体制と提供物件
   • ユーザー体制
   • 作業報告と打ち合わせ
   • 提供物件
7. 納入物件
8. 検収条件
9. 見積と条件変更の取り扱い
10. 工数と開発費用

6.契約にあって

作業開始後に見積条件が変更になり、品質、納期延期、工数あるいはコストオーバーなどにつながることもよく聞くが、そのようなことがないよう、問題が発生した問題の対応について、あらかじめ契約で取り決めておくべきである。 例えば、次のような取り決めである。

1. 見積条件が変更になった場合の対応について、例えば、工数、スケジュールの再設定、開発費用などのついて取り決める。
2. 作業量、作業範囲が確定しにくい場合は、次のように契約パターンで対応できる。
   1. 概算見積として契約し、作業開始後、作業量などが確定してから詳細見積りをして契約条件の調整をする。
   2. 不明点、不確定部分を切り離して契約する。
   3. 作業量が確定するまで、期間契約、派遣契約とする。
   4. 開発工程別に分割契約する 　表2は契約パターンの例です。
3. 支払い条件、保守料金、著作権など、取り決めによっては、開発費用として考慮すべきものもある。普通、次のように取り決められる。
   1. 納入物件に関する検査は、「下請代金遅延等防止法」などから、納入後30日後以内に行われるものとし、検査合格の場合は、その証として、検収書が発行されるものとする。
   2. 検査合格の場合は、納入日から起算して60日以内に、現金にて、代金が支払われるものとする。 いずれも、検収日ではなく、納入日であることに注意してほしい。
   3. 代金の支払い条件は、下記の通り工夫されている ・作業開始には、応分の支払いを受け、ざんきんは、 最終納入物件の検査合格後、支払われる。
      ・6か月以上にわたる作業については、さらに作業中の適当な時期に中間金の支払いを受ける。
   4. 開発し、納入したソフトウエアの保守については、別途、保守契約を結ぶことによってソフトウェアの異常発生にすぐ対応するとか、バージョンアップに優先対応する、修正の有無にかかわらず常時メンテナンス体制をとるなどする方法がある。
   5. 保守契約は、一定の期間を設定し、基本料金プラス実作業料金とする例がよく見られる。この場合、基本料金は、ソフトウエア開発費用の6～10%程度が多いようである。
4. なお、保証とは、開発ソフトウエアの検収完了後、一定期間無償にて負うカシ担保責任であって、その期間、範囲、場所などの保証条件について、明確に取り決めるべきものである。

7.今後の課題

原価主義をとっている以上、毎年の人件費アップに伴って、工程別単価がアップするという理屈になり、事実、従来はほぼそのように推移してきたようである。しかし、ここ数年の実態調査によると、単価は一率にアップするのではなく、工程によって差が出てきている。すなわち、大きくアップする工程と、そうでない工程とがある。このことは、技術の価値が、工程別単価という形で現実の市場において受け入れられていることにはかならない。 しかし、市場における技術の評価には、それ以上のものがある。そのうちの1つは、工程による評価だけでなく、同じ工程であっても、実際の作業内容によって評価されることである。 例えば設計工程を例にとると、オフコン、あるいはパソコンのそれと、大型汎親機のそれとは、ソフトウエア開発、あるいは専門的コンピュータの知識、業務知識など、必要とされる技術が違うが、そのことが価格に反映されているのである。また、同じ大型汎用機の設計工程であっても、ユーザーサイドのそれと、基本ソフトウエア・サイドのそれとは事やはり違う。 また事市場におけるもう1つの評価として、作業全体のとり琵まとめ能力とか、許画立案能力などの、管理力ともいうべき技締力がある。 ほかにも、ある先進的技術力とか、開発経験などもあるし、企業としての対応力、信頼感みたいなものもあろう。 これは、従来のような、技術者個人の技術力の評価中心から、それらの技術を菜ね備えたソフトウエア会社としての技術力の評価へと変わってきたことでもあるといえよう。 その背景として、ソフトウエアの開発技術、開発環境の革新ともいえる進歩があり、開発すべきソフトウエアが高度化、大規模化、広域化していることがあげられる。 ソフトウエア産業の立場から見た価格問題は、結果としての金額の高低もさることながら、そこに至るソフトウエアの価値についての適正な評価とこその、その反映としての適正な価格形成が、目標である。技術を価値の根源とするソフトウエア産業の発展につなげるためにも、技術をより適正に評価する考え方方式を明らかにできればと考えている。

現在以下の様であるが、システム導入における作業ステップにおいて大きく変わるものではない