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

なからなLife

geekに憧れと敬意を抱きながら、SE、ITコンサル、商品企画、事業企画、管理会計、総務・情シス、再び受託でDB屋さんと流浪する人のブログです。

受託開発に「ボリュームディスカウント」は成立するのか?

雑記 プロジェクト


IT業界の慣習で、どうしても理解できないことがある。


それは
下請け発注先を整理縮小して、絞り込んだ企業へ発注を集中させる
というものだ。


大手ベンダーなら少なからずやっているだろう。


絞り込んだ企業へ集中発注することでボリュームディスカウント効果引き出すことを狙ったものだ、という説明を聞いたことがある。
この手のものは、たいてい「購買部」主導で行われる。


現場は非常に不便だ。
案件の内容によって適した開発委託先は違ってくるし、会社公認「発注先リスト」に乗っていない企業への発注には、
リストへの追加申請自体がおそろしく負荷が高い。


それ以上に解らないのは、ボリュームディスカウントが成立する余地があるのか?ということだ。


製造業のように、大量発注を受けることで、コスト削減に寄与するものがあるのか?
ボリュームディスカウントってのは、大量生産方式によるコスト削減効果を、大量発注者に還元する」ってのが本筋と考えている。*1


ぐぐって見てもそうなのだが、最近「ボリュームディスカウント」という言葉を、「購入者側の立場」で語ることが多い。
「大量に買うから安くしろ」
という、半ばゴリ押しにも似た理論がまかり通る時代だ。


IT業界における受注側として、特に二次請負以降にとって、大量発注というのは、コスト削減に寄与する何かがあるのだろうか?


1案件のボリュームが大きい場合、思いつくだけでも、契約、納品作業が、細切れな案件に比べて効率化される。
50人月の仕事を5回に分けて請負で発注されると、5回の契約手続き、-5回の納品作業*2が発生する。
50人月1本契約だったら、1回の契約手続き、1回の納品作業で済むだろう。
結合テストなんかも、細かい納品タイミングにあわせてテストするより、まとめて一気に、というやり方の方が効率的だろう。


一方で、大きすぎると管理工数もバカにならないので、一概にコストが下げられるかというと、そうでもないと思われる。


1案件のボリュームが大きいときについては、上記のようなことが思いつくのだが、本題である「発注先の絞り込み」が目指しているところは、ちょっと違うように思う。
「複数の案件でも、同じ会社に集約することで総量を増やし、それによるボリュームディスカウントを引き出せ」
ということではないか。
そもそも、発注なんてのは金額単位で発注先を買えるのではなく、案件単位で変えることの方が多いのだから。


で、細かいの積み上げてでも総量を増やす大量発注方式において、請ける方のメリットといえば、「毎度お引き立てありがとうございます。人を切れ目なくつぎ込めるので経営者はラクさせてもらってます。依存度上がりすぎるのはちょっと怖いけど。」というくらいか。
総量が増えたところで、何か省力化できるところが見当たらない。案件が違って発注元ユーザーが異なれば、ソースやドキュメントの再利用すらままならないことだってしばしば。
もっと言うならば、複数案件もらったところで、元請のPM次第、あるいは発注元ユーザーの文化次第で進め方とか違ったりすれば、同じ元請から請けているかどうかなど問題にならないくらい「まったく別の代物」。


あんまり本格的に分析しているわけではないのですが、この程度まで考えをめぐらしてみても、
やっぱり、受託開発の世界にボリュームディスカウントが成立するとは、どうしても思えないのですよ。




似たようなところで、翻訳業界についての「ボリュームディスカウント」についての考察の記事があったので、参考まで。
JES社長の 翻訳業界「徒然草」 翻訳業界におけるボリュームディスカウント

*1:まともに経済学?の勉強をしていないので、定義わからず。だれか教えて。

*2:納品作業って、それ自体は何も生産してない、と思う。