とある受託開発(請負開発)会社のお話

はじめに

とある受託開発(請負開発)会社の話をします。これから書くお話はとりあえずフィクションくらいのつもりでお読みください。ですが、請負で自社開発というビジネスの構造上こうなりがち、という傾向をベースにまとめてますので、きっと今もどこかにこういう会社はあるんだと思います。

何が目的？

別に受託開発の良し悪しを論じたいわけではないです。どんな商売にもメリデメもあれば構造上発生しがちな問題もあります。
受託開発(請負)にも良いところたくさんありますが、持ち帰り自社開発の良いところは他でもいくらでも語られており今更私がどうこう言うことではないので、割と埋もれがちなお話でもできればなと思って筆を執りました。

殊更に受託開発(請負)をどうこう言うつもりもなく、SESとかサービス運営会社のこと(他はやったことないのでわからんです)もぽつぽつ話せたらなーと思ってます。

言葉の定義を整理しておきます

Web系だのSIerだのSESだのなんというかいろいろな思惑でいろいろな用語が飛び交ってますが、本投稿で次のような位置付けで話すこととします。

ビジネスオーナーがどちらか

：自社
〇：顧客

契約の違い

〇：請負契約
：準委任契約
：派遣契約

働く場所の違い

〇：自社
：発注元の会社(請負とこの組み合わせだと結構な割合で違法ですが、、、そうじゃないこともあります)

会社の紹介

とある受託開発会社の立ち位置

受託開発会社(請負開発会社)として稼ぐぞ！と自社開発に拘って立ち上げた会社のスタート地点の立ち位置を説明しておきます。

初期メンバーがPHPでWebサービス開発するよ系エンジニアであることもあり、だいたい図のような立ち位置での案件が中心となります。
大手に関わるにはそもそも商流が固定されており入り込む余地がないので、あぶれた仕事を拾うとか、クラウドワークスにともすれば流れるような中小零細の案件、個人事業主の案件が中心となります。

ビジネスモデル上の制約と罠

立ち位置の説明でだいたい答えは出ている気もするのですが、仕事の各フェーズでの特徴についてまとめていきます。

(だいたいこれ)最初から良案件ができるわけではない

お客様の立場で考えてみればそりゃそうだという話ですが、何百万という大事な予算をどこの馬の骨ともわからんベンダーに預けたりはしません。設立時のポリシーとして「SESはやらない」と決めている受託会社ですからSESは選択肢から除外しています。

したがって、だいたいご発注いただけるのはこんな感じのお仕事です。

既に事故ってて、そのまま事故処理するか試しに外注して事故処理するかってとこまでどうしようもない奴
- ちなみに予算も使い切ってるので、見積もったところで残り予算以上の発注にはなりません
- うまくいかなかったら払わない、としたいのでSESみたいな契約形態も選択肢にありません
LPのコーディングとお問い合わせフォームつけたいとかそういう超低額案件
- 軽い仕事がたくさんあると案件管理だけでもコストがつらいです
- 中堅に任せるには手間がもったいないけど、若手に任せるとフロントに出せないので結局手間がかかるというジレンマがあります

すこーしステップアップすると、ようやくこんな感じのご相談をお客様から頂けるようになります。

他のベンダーにやってもらってたけど、ベンダーが撤退しちゃったから引き取ってもらえないだろうか案件
- 撤退するには理由があります
- 仕様書も開発環境もありません
- お客様も仕様をご存知ありません
- だいたいが瑕疵担保も引き連れてやってきます

請負のリスクを引き受け可能なほど利益の出る案件でもない

少々業界にお詳しい方であれば「ンなもん、事故った時の人件費コミコミで見積もればよいのでは」とお思いかもしれませんが、そんなことは百も承知です。

これもお客様の立場になればそりゃそうだというお話なのですが、事故るリスク入った見積を快く受けるということは絶対事故りたくない＆そのための金も出すということなわけでして、だったら信頼してるベンダーにお願いするよね…という話です。

受注量は空きリソース基準ではなく売上目標で決まる

売上目標っていうとノルマとかその類っぽい響きですが、要するに社員の人数分の売り上げ(≒受注量)は維持しましょーねという話です。

どうしても受注量の決め方は、
「リソースが空いてるなら受ける、空いて無ければ受けないor伸ばす」
ではなくて、
「必要な売り上げ分受注する。どう捌くかは売上計画が立ってから考える」

こんな、状況、よく発生するんですが・・・・

担当	翌月のアサイン	翌々月のアサイン
A口さん	埋まってる	埋まってる
B場さん	埋まってる	埋まってる
C山さん	埋まってる	埋まってる

翌月の売上予定	翌々月の売上予定	翌々々月の売上予定
達成	未達	未達

ここで3人月で3か月後が納期の案件相談をお客様から頂いたら・・・・？答えは「受注する」です。
※ 余談ですけどこういう状況でまた同じような受託会社や、よくあるSES会社の出番だったりするのです。

ちなみにヤバい案件の撤退が難しいのも同様の理由です。金にならない案件なんかやらなきゃいいじゃないという意見もありますが、撤退したら売上に穴が開くわけで、

次の案件の営業コスト(見積とかしないとだから大変なのは営業マンだけではない)
既にかけてしまった開発コスト
案件の撤退処理
次の案件の開発コスト

これがぜーんぶ乗っかってくるわけです。それを見てもなお撤退した方がマシって程ではないと撤退の判断にはなりませんね…。

納品して「ハイ終わり」じゃない

本当に手離れしたくて資産を相手持ちにして失敗するケース、多いと思います。

資産がお客様持ちでも結局接続情報や運用保守ルールの管理するの開発会社なんですよ。特に立場が弱い受託会社だと、

運用保守はお客様側でやる（つまり無料。できるかできないかはまた別の話。）
無碍にはできないお問い合わせ

こういう取り決めになってしまうことが多いです。

自然とこんな感じにやることが増えていって、常にリソースを上回る仕事がある状態に。

※ ついでにめんどくさいのが、資産がお客様持ちだとお客様側のルールに合わせるしかなくて、管理の種類だけが増えていくという‥‥

こうすればいいじゃんというものの…

忙しいなら人を増やせばいいじゃない

既にここまでで答え出てる気もしますが、ここまでくると「人を増やすと売上目標があがり、さらにリソースが足りなくなる」という状況になります。

SESに切り替えていこうよ

「SESはど新人を教育もなしに現場ぶっこんで中抜きするだけだから楽に儲かるでしょ」とおっしゃる方もいらっしゃいますが、少なくともお客様との信頼関係考えたらそんな雑なことはできません。
じゃあ、エース級からSESに出す？そんなことしたら社内が崩壊します。

10人とか20人の企業で受託とSESをどっちもやるって、どっちかうまく行かないからやるだと逆効果で、初めから計画的にやるもんだと思うの・・・。SES企業としてスタートして持ち帰りするとかさ・・・。

得られるものがないわけでもない

とにかくタフになります

ほんっと、とにかくタフになります。

短納期低予算案件が多いので、チーム組むほどの規模になかなかりません。
小規模でいちいちエース級に案件統括させてると会社回らなくなるので、フロントに出られる見込みがあるメンバーはそりゃもうどんどんフロントに出ることになります。

そもそも短納期こなしてるとバタバタに強くなります。

折衝の場数もそりゃもうたんまり積めます。

案件始まる段階からもうスケジュールきめでもちゃもちゃしますし…
カットオーバーしたら入金されると思いますでしょ？されないんですよ…

技術のキャッチアップを強制される

引き継ぎ案件だと、その技術と周辺知識を覚えるしかないです。
スマホアプリ、Webパッケージ案件が大変多いです。パッケージありきで決まっちゃったけどできる人居ないなんて相談を受注することになったら強制的にキャッチアップすることになります。

とはいえ何とかならんもんか…

私だったらこう解決できる！とかではなくて、こんな方法でどうだろうか…くらいの気持ちで書いてみます。

少人数で始めること

無理な受注を避けるためには会社を身軽にして置いた方がよろしいかと。

最初はSESで販路と貯金を作ろう

SES案件から始めて、持ち帰れそうな案件、受託案件の相談できそうな信頼づくりしつつ、「無理して受注しなくてもいい下地作り」は必要かなぁと。

マーケットをそれでも絞る

ワープレ系、ECサイト系など低単価大量生産向きそうな領域に絞るとか
下請け系より、小さくてもエンド向けを狙う
案件紹介サイトやランサーズで似たような案件探してSaaSやパッケージ化を狙うとか？

運用は自社でやる

やっぱり管理するもの増えるのはしんどいなと…。運用の基本業務フローとか監視ルールのお品書きはちゃんと準備して置いて(もしくは監視会社と話付けておいて)、システムの利用料もらうような仕組みにしておきたい。
SaaSだと割り切ってもらうのが一番いい。

おわりに①

ここに書いたことなどとっくに乗り越えている会社や、同じような問題は発生しなかった会社、全然別の課題に直面してる会社もいろいろあると思いますが、こんな会社も業界の片隅にいるかもね、くらいに思ってください。

僕は少なくとも開発ってキラキラしてることばかりとは思ってませんし、往々にしてこんな感じの試練はどこかで迎えるもんだと思ってます。

これからIT業界に入ろうという方、ここに書いたようなことでも、そうじゃなくても、「こんなはずじゃなかった…」なんてことにならないよう、公平な情報収集と、覚悟と、あとちょっと勇気をもって業界に入ってきてもらえたらなぁと。

おわりに②

上記あくまでフィクションです。仕事の構造的に起こりうる話を組み立てているだけです。

ただし、私が力不足な中、受託の事業にエンジニアとして参加し、ドロドロになりながら仕事していた経験もありますし、突き詰めれば私の力不足が原因の一端であり、反省したいところも山のようにあります。
そんな中、一緒に仕事をしてくれた方々、付き合っていただいたお客様、世話をしてくれた上司や出資者の方、皆様には感謝しかありません。
Webの片隅から届くかどうかはわかりませんが、この場を借りて御礼を申し上げたいと思います。