事業会社出身者で創った開発会社ができること

初めまして。株式会社クアリタで代表をしている萬浪と申します。

株式会社マクロミルに新卒入社、その後株式会社ライフスポーツというCtoCのスポーツマッチングアプリの会社に社員一期生として入社し、それから約1年後に数人のメンバーとともに開発会社である株式会社クアリタを創業し、以降自社サービス開発と受託開発の双方を行ってきました。

自社サービスと受託の双方を経験している立場から、事業をしていて思うことを書いてみたいと思います。クアリタに興味を持ってくださっている皆さまに少しでも弊社の考え方をお伝えできると嬉しく思います。

クアリタで採用活動をしていると、事業会社と迷っている…だったり、他社の開発だけしてる受託会社ってどうなの？言いなりで開発って大変じゃない？みたいな話をよく聞くので、今回のストーリーでは僕が考える事業会社と受託会社の違いに触れつつ「受託会社はどうあるべきか」について少し所感を書いてみたいと思います。

前提として以下の2点を考慮した上でお読みいただけると幸いです。

・文中の事業会社とは自社開発をしている会社とします。
・会社によってポジショニングは様々なので世の中の全てのケースに当てはまるものではありません。

事業会社と受託会社で大きく違うところ

主に現場に携わるとした場合に大きく異なるのは以下の点ではないでしょうか。

1. 未知のことやビジョンにお金を投資するヒリヒリ感の有無
2. １つのプロダクトと継続的に向き合い試行錯誤するPDCAフェーズの有無

この2点が自社プロダクトを持つ会社には必ずあり、逆にクライアントのお手伝いをする受託会社には備わっていないことが多いと思います。

1. 未知のことやビジョンにお金を投資するヒリヒリ感の有無

これは言わずもがな事業会社の醍醐味ですよね！
受託会社にはこれがない…とよく言われます。仕方ないことではあるのですが…。

受託開発会社はドラスティックなことがしにくい組織です。クライアントからお金をいただいてものづくりをし、あくまで意思決定者はクライアントです。そして開発会社のコストの大部分は開発メンバーの人件費です。事業会社のように自社プロダクトがないので、受託する案件に従事しなければその人件費が自社の資産に転換されるということがありません。仮に案件がない状態でメンバーが増えた場合、キャッシュフローの観点においてはコストだけがかかることになってしまいます。逆にたくさん引き合いをいただいても開発リソースがなければ今度は依頼を受けることができません。組織の成長のためにはコスト過多にならない程度にリソースを増やしながら、会社がパンクしない程度に案件を増やしていくことが求められます。その上で会社としては、メンバーの技術力や興味分野に合った案件を増やしていきたい…。

上記のように、受託会社は事業会社のように社運をかけて大きく勝負に出る！というドラスティックなことをなかなかしづらいビジネスモデルですし、そのようにする理由もほとんどないというのが正直なところです（事実ですが非常につまらないことを書いてしまいましたw）ここを解決している受託開発の会社さんがあれば本当に素晴らしいと思います。

2. １つのプロダクトと継続的に向き合い試行錯誤するPDCAフェーズの有無

重要っ！
こちらが今回のお話の肝です。これも事業会社にあって受託会社にはないものですが、受託会社がクライアントに価値提供する上で、このサイクルを経験したことがあるかどうかはとても重要だと思っています。

僕が自社サービスのスタートアップでCtoCマッチングアプリを開発していたときは当たり前にこのPDCAを繰り返していました。
例えば自社アプリの運用開発を例に挙げると、PDCAは以下のように回ります。

Plan: 目標の達成に向けて機能の開発要件が定まる（仮説立て）

ユーザーファーストという大前提のもとで、目標達成に向けてアプリに何をするか？をプロジェクトメンバー全員で考える。複数の意見がテーブルに上がったときは、どの案が最も早く事業のビジョンを達成しうるか？という軸で考える。

Do: 実装＆リリース

Planで決まった要件を実現させる。サーバサイドエンジニア、アプリエンジニア、デザイナー、開発ディレクターが密に連携し開発を進める。オフィスワークのメンバー、フルリモートのメンバー、社員、業務委託、様々なバックグラウンドを持つメンバーをディレクターが一つにまとめ上げる。

Check: アプリ内の数字をウォッチし、当初設計した目標値と実情を比較する（仮説検証）

Planで立てた仮説を検証する。リリースしてほどなくするとその成果は全て数字で表れるので、仮説通りだったか、そうでなかったか。そうでなかったのであればどの要素をどう改善しえたのか、事実から洞察を得る。

Action:次の一手を考える

ボトルネックがあればその解消、うまくいっていれば次の改善に着手と、アプリ内でのユーザの行動を元に成功と失敗を判断し新しい一手に繋げる。

このPDCAを回した経験があるのとないのでどのような違いがあるかを掘り下げていきます。

サービスの"Do"しか関われない受託会社のリスク

事業会社では当たり前のように求められるサービス成長のためのPDCAサイクル。成功・失敗から学びを得て次の一手に繋げること。事業会社はそのサイクルを回しながら意思決定を繰り返します。サービス運営に最も重要な要素であり、これがなければ成長は為し得ないとまで言えます。

しかしそのような事業を行うクライアントを手伝う立場の受託会社はどうでしょうか。多くの案件がクライアントの要望に沿って進み、納品完結の案件はもちろん、運用保守が続いたとしてもマーケティング系のデータを見ることまではできず、自分たちが開発したサービスのPDCAサイクルを回すということはほぼありません。自分たちが自信を持って開発したプロダクトを「世に出すまで」で、その後プロダクトが受け入れられたか総スカンを食らってしまったかを知る由がないのです。受託会社にとっては開発完了がゴールですが、事業会社はそこからが始まりです。

このように多くの受託会社は"Do"の繰り返しでその先がありません。しかし本当にそれで良いのでしょうか？サービスの成長を担うはずの受託開発会社にサービス開発の経験がない状況で、クライアントやエンドユーザが満足する本質的に良い開発ができるのかは疑問です。画面設計したそのUIはユーザーに理解されるものでしょうか？そのUIは事業のKPIの達成に貢献しますか？機能の取捨選択は何を基準に行なっていますか？事業においては「不具合を出さないアプリ」が至高ではありません。重要ではありますが。

サービスを運営していて「これなら必ずうまくいく」は絶対にないのですが「これでは必ず失敗する」は多々あります。事業会社ではそのような知見がPDCAサイクルで少しずつ溜まっていき、次の設計や開発に生かされていきます。しかし"Do"しか経験していない受託会社はどうでしょうか。開発案件をこなした数に依らずサービス開発運用の知見は貯まりませんので、クライアントの期待に応えられないリスクは拭えません。

「受託はクライアントの言いなりだ」とよく言われますが、少なくとも僕の環境ではそう感じたことはありません。そのような声が多いのは、上記のような観点でクライアントと受託会社の間で会話が噛み合わなくなることによるのではと思います。プロジェクトの認識に齟齬が生じていれば事業会社から見ていやこれおかしくない？みたいなことをやってしまうことがあり、受託側はなぜおかしいかが理解できないために摩擦が生じます。クライアントと受託会社は対等ではないかもしれませんが、少なくとも会話が噛み合う関係であればプロジェクトは幾分もエキサイティングに進んでいくと思います。

では、受託会社が"doしかできないリスク"から抜け出すにはどうしたらいいのでしょうか？受託会社がクライアントの事業をビジョンやビジネス背景から理解しそれを目の前のアプリに落とし込み前衛的に進めていく、時には技術的な観点を交えながら事業推進のための次の一手の提案をしていく、カスタマーファーストや事業成長のために必要であれば新しい技術を積極的に取り入れる、加えてメンバーもプロ意識を持って仕事ができる…。受託会社がそういった「事業パートナー」のような存在になるにはどうしたらいいのでしょうか？

それは間違いなく、サービス開発の痛みや辛さを知っている受託会社になること。
言い換えればサービス運営のPDCAを経験している受託会社になることだと僕は思います。

事業会社とゴール認識を共有できる受託会社は強い

発注元の事業会社が本質的にゴールにおいているものは「アプリやシステムを作ること」ではなく「エンドユーザーが満足するもの・喜ぶものを提供すること」です。受託会社は、あくまでその実現手段としてアプリやシステムの開発を提案しているに過ぎません。
このようにクライアントと共通のゴール認識を持って寄り添える受託会社はさほど多くなく、これを心得ている受託会社はそうでない会社と比べてマインド・技術のどちらをとっても強いです。事業成長の手段がITと捉えれば、将来的なメリットによっては新しい技術を採用すべきとなり、必然的にその会社は技術力や情報感度に長けていきます。組織内のメンバーは新規性の高い案件に関わることができ、新しい技術にも積極的に触れることができます。そもそもこのような事業視点を持っている受託会社は、開発を請け負うことに留まらず、受託会社ではなくパートナー会社という別次元の位置づけになってきます。

では、そのような強い受託会社、、ならぬパートナー会社になるには何からすれば良いのか？

まずは事業出身のメンバーが集まってやることに尽きると僕は思います。
受託事業しか経験していない状態からPDCAの経験を得るのはほぼ不可能です。１から事業開発をしてみるなら出来なくはないですが、それなら初めから受託ではなく事業会社を全力でやった方がいいです。企画、開発、運用、マーケティング、どれも実際の現場で試行錯誤してこそのノウハウがあるもので、書籍や一般論でキャッチアップできるほど簡単なものではないからです。

UIひとつをとっても理論通りに作ってユーザに受け入れられることはむしろ珍しいことです。
実際にはビジネス背景だったり、想定するターゲットユーザの属性だったり、リテラシー水準だったり、あらゆる変数を考慮して総合的な最適解は自分たちで考えて設計する必要があります。言わずもがな作って終わりではなく、ユーザからのフィードバックを得てサービスを柔軟に変化させていくことが必要です。
このようなノウハウは変化の激しい現場で揉まれた経験のあるメンバーしか持っていません。僕たちはその部分に着目し、クライアントの事業にパートナーとして参画できることを自分たちの最大の強みにしようと考えました。

最後に疑問が残ります。
そんな変化に富む環境でサービス開発をしてきたメンバーが受託をやって楽しいの？という点です。
楽しいです。クライアントのパートナーとして事業に責任を持って関わるのであれば、実はいいところはたくさんあります。

"強い"受託会社のいいところ

最後にそのような"強い"受託会社にあるものを１つ挙げたいと思います。
それは「たくさんの０→１開発に携われる」ということです。

事業会社ではプロダクトを継続的に成長させることが多いので、技術領域が数ヶ月のうちに大きく変化したり、新しいアプリやシステムを次々構築したりということが少ないです。その点では受託会社は様々な規模の案件を様々な技術を取り入れて設計構築することができるので、新しい技術のキャッチアップにおいては事業会社に引けを取らず、むしろ初期開発という高難度の仕事を短期間のうちにいくつも経験することができます。

「自分は１つのプロダクトと心中したいんじゃ！！」

という志の場合にはもちろん事業会社がおすすめなのですが

・短期間で多くの経験を積んでスキルアップをしたい
・新しい技術を積極的に使って仕事をしたい
・将来的に起業したいので開発のノウハウを得たい

などという場合には受託会社はうってつけの環境だったりします。新規事業などを手伝っている受託会社であれば優秀なメンバーが多く関わっていて、自分の知らないことを知っているメンバーもたくさんいますし、プロジェクトごとにメンバーが編成される環境であればメンバー同士でナレッジ交換なども事業会社と同様かそれ以上に活発に行うことができます。

これで、事業会社出身者が受託会社に関わるメリットや動機についてもすっきりしましたね。
理屈っぽく書いてしまいましたが、実際にはメンバー各々に思いがあって参画しています。BtoBなのでBtoCに比べると会社規模が小さくても事業が安定しやすいとか、リモートが基本で子育てをしながらでも自分のスキルを生かしながら安定して稼ぐことができるなどなど、動機は様々です。

まとめ

・事業会社にあって受託会社にない大きなものはサービス開発運用経験の有無
・事業を手伝う立場としてサービス開発の経験を持たないことのリスクは大きい
・事業会社出身者が創った受託会社はサービス運用経験を持っていることが最大の強み
・強い受託会社は0→1開発に多く関われるのがいいところ

最後までお読みいただきありがとうございました。

クアリタについて

弊社クアリタは事業会社出身者が創業した受託開発会社で、サービス開発運用経験を持ったメンバーがクライアントと併走して主に新規事業開発のお手伝いをさせていただいています。
落ちてきた要件を開発して終わりではなく事業設計や要件定義、運用フェーズからマーケティング領域まで一気通貫で関わることが多いです。そのため開発の設計段階から、リリース後には自分たちの手で運用・集客することを想定し責任を持って設計・実装を行っています。

そのような取り組み方が多いこともありお客様とはいわゆる「言いなり」の関係になることはありません。受託開発会社というよりもクライアントの事業の中でクアリタの得意分野については責任を持ってお任せいただくパートナー会社という位置づけでお仕事をいただいていますので、基本的にクアリタの得意領域に関しては自分たちが裁量権を持って業務を遂行しています。

具体的な開発案件としてはiOS/Androidアプリやシステム開発の案件が９割以上を占めており、さらにそれらのほとんどは要件取りまとめからクライアントとともに進める新規事業開発です。ユーザーファーストという大前提を大切にしつつ、現場のエンジニアの設計によりアプリはFlutter・フロントはPWAなどトレンドの技術も積極的に採用しています。

採用については中途採用・業務委託（副業・フリーランス）どちらも常に行なっておりますので、ご興味がおありの方がいらっしゃいましたらぜひご応募いただけると嬉しいです。

エンジニアも開発ディレクターも大歓迎です！
WEB面談でカジュアルにお話ししましょう！