エンジニアと経営のクロスオーバー

第2回 ビジネスモデルと原価と経費

この記事を読むのに必要な時間:およそ 2 分

エンジニア出身の社長という視点で前回記事を書きましたが,今回もその続きで,おもにビジネスモデルというものに焦点を当ててみます。

受託や業務委託は「儲ける仕組み」とは言わない

そもそもビジネスモデルとは,⁠どうやって儲けるか」という仕組みのことですが,じつはこの「仕組み」というところがポイントです。以前の連載(⁠エンジニアに捧げる起業幻想」⁠や前回の記事でも触れましたが,エンジニア,特にITにおけるエンジニアというのは技術を売るという手段があるため,いざ困るとそちらに容易に行ってしまうというパターンが少なくありませんというか大変多いです。

受託や業務委託でも,スタッフが自分だけだったり,ほかにもいたとしても全員エンジニアであれば,とりあえず食っていくことはできます。ただこれを「儲ける仕組み」とは言わないでしょう。この状態では「エンジニア出身の社長」ではなく「社長という肩書のエンジニア」だというのは,前回も触れました。ビジネスモデルというのは,いったん軌道に乗ったらしばらくの間はその仕組みを回したり加速させることに集中すれば事業が拡大していく,というようなものでなくてはなりません。

エンジニアの給与は「原価」として扱われる

ところで,経営に携わっている,もしくは興味がある人はご存知のように,事業にかかるお金には原価と経費と投資というものがあります。このなかで,投資(金融投資や設備投資など)はいったんちょっと置いておきます。

原価と経費ですが,一般的には原価は売上を上げるために必要な材料,経費は事業活動のための費用(販管費とも呼びます)と説明されたりします。これが商品を仕入れて販売するようなビジネスにおいては,その分け方は明確です。仕入れ代金が原価,その他の費用すなわち給与,オフィス家賃,通信費などもろもろが経費です。

ところがIT業界,特にソフトウェア開発に関わる場合,少しそのあたりが厄介になります。通常,給与というのは経費ですが,販売に関わる製造の元となるエンジニアの給与は原価として扱われるからです。

たとえば10億円の売上があったとして,他社に下請けに出している分が2億円,自社のエンジニアの販売に関わる製造に費やした※労働時間の給与が3億円だったとすると,原価はトータル5億円ということになります。

他社に発注した分はいかにも仕入れというイメージが強いですが,エンジニアの給与を仕入れというのは,おそらく違和感があるのではないでしょうか。

余談ですが,⁠販売に関わる製造に費やした」と書いたのは,そうでない部分は原価にはならないからです。これは経費になったり資産になったりしますがここでは割愛します。もともと原価というのは売上に連動する費用(これを変動費用といいます)という意味合いが強いものです。

仕入れ販売であれば売上がなければ仕入れをなくせばいいですし,製造業でも原材料の在庫の調整ができますが,エンジニアを原価とする場合,売上がないから給与を減らす(もしくは人員を減らす)というのは,そうかんたんにはできません。会計基準においては原価であっても,その本質は固定費(売上に直接連動しない)に近いということです。売上に連動しないのに原価,というのが違和感の大きな部分だといえます。

労働集約は中小企業においてはビジネスモデルとして成立しづらい

さて,ここまでは一般的な事象の説明です。私が思うに,ビジネスモデルとして必要な要素にはいくつかのポイントがありますが,それらを挙げてみると

  • 売上が継続的に拡大する見込みがある
  • 市場そのものもしくはシェアが継続的に拡大する見込みがある
  • 原価率を減らしていける(粗利率が拡大する)見込みがある
  • 販管費の比率も減らしていける(利益率が拡大する)見込みがある
  • 原価における人件費の比率を減らしていける見込みがある

などがあります。

ちなみに,売上を上げるために人を増やしていけばいいというビジネスモデルを労働集約,設備を増やしていけばいいというビジネスモデルを設備集約と呼んだりもしますが,私は労働集約というのは中小企業においてはビジネスモデルとして成立しづらいものだと思います。

それは大企業でも同じかもしれませんが,中小企業だとより労働集約のリスクが高まる(経営が相対的に脆弱)のでなおさらです。

売上のパターンは「フロー収入」「ストック収入」の2つに分けられる

売上のパターンにおいても,フロー収入とストック収入という2つに分けられます。フロー収入とは毎回毎回売上を獲得するタイプ,ストック収入とはいったん成立すると継続的に売上が上がるタイプのビジネスモデルです。受託などはフロー収入ですし,運用委託はストック収入です。ただ,フローっぽいストック収入や,その逆もあるので,あまり明確に線引きはできませんが。

つまり,理想を言えば,

  • 「市場もしくはシェアが継続的に拡大し,ストック収入型の売上が継続的に拡大し,その原価は設備集約タイプでかつ原価率は下がっていき,そのための販管費の比率の下がっていく」

ようなビジネスが,まずビジネスモデルとしては理想ということになります。

なかなかそんな都合のいいビジネスモデルはありませんが,企業を経営しているのであれば,極力その条件を多く満たすことを追求していくべきでしょう。

ちなみに,フロー収入は一度の取引で粗利をプラスにできますが,ストック収入の場合,当初は粗利自体がマイナスなことも多いものです。このためストック収入を目指す場合,最初はフロー収入と組み合わせるか,借り入れや投資といった資金調達と組み合わせるなどが必要になってきたりします。ただ,フロー収入とストック収入を組み合わせた場合,なかなかそのフロー収入から抜け出せないということもまま起こります。

話は変わりますが,経営判断というものは,十分に情報を獲得して十分な検討をおこなえば,あまりまちがえるものではありません。まちがえるのは,情報が十分でないか,検討が十分でないことが多いためです。これはもう,情報を十分に獲得する仕組みを作って,検討を十分におこなう経営努力をするしかありません。

ただ,情報も検討も十分にしたとしても,短期と長期のトレードオフが発生することはよくあります。短期的にはAが良いが長期的にはBが良い,というケースです。これはじつによくあります。先ほどの例でいえば,目先のフロー収入を優先するか,その先のストック収入を優先するか,なかなか難しいところです。

コストは投資の一種

さて,ビジネスモデルは追求するとして,ちょっと原価と経費の別の切り口について書いてみます。

経費(販管費)というのは,よく「コスト」と表現されたりもします(原価も「コスト」と表現されます)⁠なんとなく「コストは悪」というイメージが一般的にはある(つまりカットできるならカットしたほうがいい)と思いますが,経営的に言うと,コストは投資の一種です。

ここでいう投資は,先ほどの原価,経費,投資という区分のいわゆる設備投資や金融投資ではなく,事業への投資という意味です。

会計上は投資ではなく,単なる経費です。ただ,たとえば,働きやすいオフィスを構えるとか,開発効率を重視したIT環境を整えるなどは,会計上は経費ですが事業への投資だといえます。

経費が少ないほど利益が増えるのは事実ですが,逆にいうと利益の中からどう事業への投資となる経費を積んでいくかは,重要な経営判断の1つだと思います。

究極の福利厚生とは「ビジネスモデル」である

ただその線引きもなかなか難しく,⁠それなら利益や給料を増やしてほしい」と思われることも多々あるかもしれません。

思うに,究極の福利厚生というのは「ビジネスモデル」なのです。労働環境を整えるのもいいですが,素晴らしいビジネスモデルがあれば相対的に労働の対価は上がりますし,従業員だけでなく取引先も株主もみんなハッピーです。

とはいえ,そんな素晴らしいビジネスモデルはそうそう生まれないので,なんとかその取り組みの中で経費という事業への投資の最適化もしていくということです。

限られた収益をどの程度利益として残すか(内部留保といいます)⁠どの程度従業員にリターンとして返すか,配当として株主に渡すか,これは本当に難しい問題です。

たとえば自分が働いている会社が給与カットを宣言したら頭にくるでしょうし,逆に自分が株を持っている会社が大規模なリストラを断行して利益があがって株価が上昇したらうれしいかもしれません。ある期間での収益の使途はゼロサムなので,見方によってその良し悪しは真逆になったりもするのです。

さて,今回はビジネスモデルについてもうすこし掘り下げてみました。エンジニアと経営という切り口の前提部分までしか触れられませんでしたが,次回も引き続きさらに掘り下げていってみたいと思います。

著者プロフィール

山崎徳之(やまざきのりゆき)

青山学院大学卒業後,アスキー,So-netなどでネットワーク,サーバエンジニアを経験。オン・ザ・エッヂ(現ライブドア)のデータセンターである「データホテル」を構築,運営。2003年にベイエリアにおいてVoIPベンチャーであるRedSIP Inc.を創業。2006年6月に株式会社ゼロスタートコミュニケーションズ(現 ZETA株式会社)を設立,代表取締役就任(現任)。ECソリューションの「ZETA CX」シリーズとして検索エンジンやレコメンドエンジンを開発,販売している。

blog:http://blog.zaki.jp/
社長コラム:https://zetacx.com/column

コメント

コメントの記入