受託・派遣型の中小ソフトウェア業が抱える課題：コスト構造（その４）
●（３）生産性の向上が、売上や利益の拡大につながらない原因その２
ここでは、私が認識する受託・派遣型の中小ソフトウェア業のかかえる課題について述べ、解決に向けての情報共有を行いたいと考えている。
「受託・派遣型のソフトウェア業」とは、主にベンダ企業や大手のソフトウェア業のシステム開発を請負または委任契約で受託し、客先の企業内に技術者が常駐して開発を行うタイプの業務形態を示している。世間一般で言う「ソフトハウス」がこれに該当する。
私が本稿で述べたい結論は、「受託・派遣型のビジネス慣習によって、受託・派遣型のソフトウェア開発は、ハイリスク・ローリターンのビジネスモデルになってしまっている」という点である。これではリスクだけ引き受け、リターンは低いという、全くうまみの少ないビジネスと言えよう。
日々生産性向上の施策なども打っているが、なぜか利益が出ないし組織が伸びない、とお悩みのソフトウェア業の方は、ぜひご一読を頂き、ご批評を頂ければ幸いである。
当方の考えるコスト構造に関する課題の結論と、結論に至るまでの仮説は以下である。
- ●結論
- 受託・派遣型のビジネス慣習によって、受託・派遣型のソフトウェア開発は、ハイリスク・ローリターンのビジネスモデルになっている。
- ●仮説
- 人月単価での発注という慣行によって、組織の生産性向上によって余剰工数が生み出されても、柔軟に仕事をアサインできるマネジメントが存在していない。
論述はおおよそ以下の順に述べることとする。
- （１）受託・派遣型ソフトウェア業のコスト構造における課題提起
⇒コスト構造に関する課題の概要を述べる。
（受託・派遣型ソフトウェア業の課題：コスト構造（その１）） - （２）ソフトウェア業のコスト構造
⇒コスト構造とは何かを理解するための、一般的な説明を行う。
（受託・派遣型ソフトウェア業の課題：コスト構造（その２）） - （３）生産性の向上が、売上や利益の拡大につながらない原因
⇒前述した仮説を述べる。
（受託・派遣型ソフトウェア業の課題：コスト構造（その３））
（本記事が該当） - （４）コスト構造の課題
⇒前述した仮説によって、コスト構造にどのような影響を及ぼすのかを述べる。
（３）生産性の向上が、売上や利益の拡大につながらない原因
●前回までのおさらい
前回は、ソフトウェア業は固定費型産業なので、生産性を向上させることで、余剰工数を生み出し、その工数で新たな仕事を行うことで、売上の拡大、利益の拡大を目指そうとするといった点を、電力会社の例を用いて説明した。
この「利益増大へのシナリオ」を記載すると、以下のようになる。
- １）生産性を向上させる
- ２）もっと多くの仕事をこなせるようになる
- ３）多くの仕事をこなすことで売上高が上がる
- ４）多くの仕事をこなしても固定費は増加しない
- ５）利益が大幅に増加する
今回はこのシナリオが現実的なのかを検証していきたい。
●その生産性向上施策は、ほんとうに利益に直結しているのか？
良く考えると、前述の「利益増大へのシナリオ」には落とし穴がある。
生産性を向上させることで売上高が増加するためには、次の２つの前提条件を満たしている必要がある。
- その１：市場制約
- その会社の供給量以上の需要が市場に存在していること
これは当然の話である。いくら効率よく仕事をこなせるようになり、供給能力が向上したとしても、市場にそれだけの需要（仕事）がなければ供給する先がない。ただしこれは、市場全体が冷え込んでいるということもないとは言えないが、それよりも営業力や組織の競争優位によって大きく事情が異なってくる。魅力的な企業であれば、需要を掴み取ることはできる。ひとまず今回の話題としては「ビジネスモデルとしてのコスト構造」に着目しているので、第一の前提条件は満たしているものと考えたい。
- その２：方針制約
- 生産性を上げることで確保した余剰工数に対して、柔軟に他の仕事をアサインできる組織体制になっていること
これはどういう意味だろうか。生産性を上げた場合、同じアウトプットはこれまでよりも少ない工数で達成することができる。つまり、今までと同じ仕事をしているならば、時間が余るということである。時間が余れば、この空いた時間に他の仕事をアサインすることができれば、売上はあがるだろう。
ただしここで疑問がある。本当に、空いた工数にうまく他の仕事をアサインできるほど、組織の仕組みが柔軟に設計されているのだろうか。
当方の仮説は「この方針制約が取り除かれていない」ということを想定している。以下に、この仮説が正しいと考える事象を述べたい。
余剰工数に柔軟に仕事を割り当てるためには、メンバ一人ひとりの作業を細かく管理することが必要になるだろうし、高度な分業体制を構築することも求められる。
例えば、私が仕事をしていて、予定よりも効率的に作業を進めることができたので、１週間で４時間の余裕時間を捻出できたとしよう。しかし、その４時間の工数に当てはめることができるだけのサイズの仕事量が都合よく存在するだろうか。また、少ない時間で成果を出す必要があるので、その人の得意分野のタスクをアサインするという工夫も必要になってくるだろう。
例えば私がデータベースのプロフェッショナルだとしよう。そのとき、４時間程度で完了できて、かつデータベースの構築に関係したタスクが、今週に都合よく存在しているだろうか。はなはだ現実的ではない。もちろん、４時間単位という粒度ではあまりにマネジメントが難しいから、もっと人日程度の粒度でざっくりと管理すれば、それなりにうまく回るのかもしれない。そうだとしても、かなり高度なマネジメントになることは確かなはずだ。ただし、このような高度な分業体制を構築することは可能であるし、安易に構築することが難しいからこそ、競争優位にもなるであろう。
●方針制約が壁になる最大の原因
しかし、このような高度な分業マネジメントが確立できない、最も大きな原因が他にある。これが、「人月単価での発注」という慣行だ。
委託者が受託者に発注する場合は、システムの規模や作業内容からみて、何人の頭数が必要かを判断し、頭数に対する単価で発注を行う。発注された側は、頭数を指定されているので、その人数を発注元企業に常駐させることになる。受託企業としては、頭数分の技術者さえ派遣していれば、１人月あたり決まった金額を稼ぐことができる。
そうなると、受託企業にはどのような誘因が働くか。
派遣している技術者の生産性などはほとんど気にしなくなるだろう。もちろん、顧客から愛想を尽かされないだけのパフォーマンスは必要だが、卓越しようとは思わなくなるだろう。なぜなら、生産性が高かろうが低かろうが、１人月の単価は変わらないからだ。人月単価のしくみは、派遣する技術者１名の単価が保証されるというメリットがあるが、そのために手放したのは、技術者の動的な仕事のアサインという流動性だ。
流動性を手放してしまった企業では、客先にメンバを常駐させているということもあり、生産性を上げて余剰工数を生み出せたとしても、他のプロジェクトを掛け持ちさせるということは考えもつかない。また、発注した客先も頭数分の金額は発注しているのだから、そのぶんの人数はきちんと常駐して働いてもらいたい、と思うことだろう。となると、「１人＝１プロジェクト」という縛りが発生してくる。生産性を上げたところで、他のプロジェクトのタスクをアサインできないという構造がここで作り上げられるのだ。そして、生産性向上の掛け声でいろんな施策を行っても、売上高や利益には結びつかなくなってしまう。
もし人月単価での発注ではなく、一括定額での発注であるならば、アウトプットさえしっかり出せるのであれば、何人の技術者で業務を行ってもよい。もちろん、一人でいくつのプロジェクトを兼任しても何も問題はない。誰をどのように、どれだけのプロジェクトにアサインさせるのかという流動性は受託企業で持っていることになる。生産性を向上させることで余剰工数を生み出し、そこに他の仕事をアサインすることも可能になる。もちろん、前述したような高度なマネジメントは必要になるだろうが、それは可能なのだ。
●方針制約を強める近年の動き
近年だとソフトウェア受託業務の発注は、全ての工程が委任契約になることも多くなってきている。
委任契約だと、受託者は成果物完成責任を負うことはないが、更なる下請けの利用が原則的に制限される（請負契約であれば、受託業務を下請けに再委託することは原則として自由）。となると、自社内のメンバでプロジェクトメンバをやりくりする必要性が高まってくる。
自社内のメンバがすでに他のプロジェクトに参画してれば、人月単価の縛りによって他のプロジェクトにアサインすることができず、受注機会を逃す可能性も高まる。これは受託企業が、既存のプロジェクトがいくらヒマであったとしても、人質？として客先に常駐し続けるのが当たり前だと思い込んでいることによることの制約による。
ちなみに、委任契約が増えていることの背景には、情報セキュリティのリスクが高まっていることが挙げられる。請負契約だと、発注元の知らないところで知らない会社がプロジェクトに参入していることがあるため、それだけ営業秘密が漏れるリスクが高まる。
またビジネス環境がダイナミックに変動しているので、３カ月や１カ月といった短い期間で委任契約を結び、これを更新するというスタイルにすることで、環境変化によってプロジェクトが中止になっても、すぐに協力会社との契約を終了できるように、流動性を高めるという意味合いもある。請負契約の場合は、途中でのプロジェクト中止が発生した場合、そこまでプロジェクトに投入した費用は発注元で負担することが筋だし、急にプロジェクトを中止したことによる損害賠償を負担する可能性だってなくはない。そのため、発注元は品質担保についてのリスクは負うものの、セキュリティリスク、環境変化のリスクのほうが影響は大きいと判断したのだろう。
●方針制約が存在する場合、生産性向上は利益に直結しない
以上のように、ここで述べた「余剰工数に柔軟に仕事をアサインできる高度なマネジメントが存在していない」という仮説が正しいとするならば、生産性の向上をしても売上は上がらない、ということになる。
前述した利益増大へのシナリオを引用すると、
- １）生産性を向上させる
- ２）もっと多くの仕事をこなせるようになる
- ３）多くの仕事をこなせるだけの余剰工数を生み出すことはできるが、柔軟な仕事のアサインができるマネジメントが存在しない（１人＝１プロジェクトの業界慣行が存在する）ので、実際には多くの仕事をこなすことができない。
といったことになる。
ここまででまただいぶ長くなってしまった。
今回は「人月単価による、１人＝１プロジェクトの業界慣行が存在するため、生産性向上によって余剰工数が生み出されても、柔軟に仕事をアサインできるマネジメントが存在していない」という仮説について述べた。この仮説が正しければ、生産性向上活動は、売上の増大や利益の拡大には貢献していないということになる。
次回はこの仮説を前提条件としたとき、コスト構造はどのようにふるまうのか、といった点を述べたい。ここを述べることで、私の考える結論である「受託・派遣型のビジネス慣習によって、受託・派遣型のソフトウェア開発は、ハイリスク・ローリターンのビジネスモデルになってしまっている」にやっとたどり着く。
