こんにちは。CTOの木下です。
この記事のテーマは、どんなビジネスモデルの元で働くのがソフトウェアエンジニアにとって望ましいのかです。
結論を先に言えば、ビジネスモデルこそ意思決定の構造を決め、それが開発現場に降りてきます。その影響力は、スクラムを採用してるかどうかなんかよりも圧倒的に大きいです。そして数あるビジネスモデルの中で、PLG(Product-Led Growth: 営業ではなく製品それ自体が製品を売るモデル)という選択は、ソフトウェアエンジニアリングの理想に最も近い構造を作ります。
違和感の出発点
私は日本に五万とあるだろう受託開発を行っている会社でキャリアをスタートしました。
より良いソフトウェア開発をしたいと思い、達人プログラマー(第1版)、情熱プログラマー、ハッカーと画家、プログラマのためのサバイバルマニュアル、アジャイルサムライなどを読んでいました。これらの書籍に共通する視点として「ソフトウェアの利用者にとって、より良いものを作るためには」という観点があると思います。今とは背景が変わっている部分も多いでしょうが、この観点は今にも通じるはずであり、今も私の追う理想です。
しかしながら当時の私の開発の現実はだいぶ遠いところにありました。
- Excelで書いた設計書を印刷する。そこに定規を当ててはみ出していることを指摘される
- 新しい言語機能を使うとそれがわからない人がいるため保守性が下がるという理由でバージョンを上げられない
- 品質保証担当者は設計やコードの品質ではなく、Excelで書かれたテスト計画書に添付されたスクリーンショットの網羅を気にしている
これはもう10年ちょっと前のことなので今はもうこのような環境は少なくなっているでしょう。ただ問題は、なぜこんなことが起こるのか、です。
なぜこんなことが起こるのか
書籍に書かれているソフトウェア開発と、自分の仕事内容があまりにも違う。どうしてこうなってしまうのか。
当時の私は最初、自分の会社の問題だと考えました。しかし周囲を見渡しても悪意のある人はおらず、むしろ真面目な人ばかりでした。真面目な人たちが集まって、なお理想から遠い仕事になってしまっていました。
ここで気づいたのは、真面目さや能力の問題ではなく、合理的な判断の積み重ねがこういう帰結になる何かが働いている、ということでした。組織論の古典とも言える『学習する組織』でピーター・センゲは「構造が行動を規定する」ことについて書いています。システムの中にいる人々は自分の意思で選んでいると思っていても、実際は構造がその選択を強いている、という視点です。
次に考えたのは、業界慣習の問題ではないかということでした。受託開発業界には特有の慣習があり、それに縛られているのではないか。
そこで私は弊社に転職し自社製品(SaaS)開発をすることになりましたが、そこを通して気がついたのは、同じIT業界であってもビジネスモデルが違えば現場の状況は全く違うということでした。業界ではなくもっと上位の構造、すなわち「誰に、何を、どうやって売るのか = ビジネスモデル」が、開発現場を規定しているということです。
受託開発の構造
受託の本質は作業の代行です。成果物が欲しい人が自社に作るリソースがない場合に、作業リソースを外部から調達するというのが受託のビジネスモデルの基本構造です。
この構造から2つのことが言えます。
第一に、最終成果物から収益を得られないという点です。作ったソフトウェアがどれだけ売れようとも、受託した側の利益に直接影響しません。 製作費としての対価を受け取って終わりです。 この構造では、クライアントが求める以上の品質で成果物を仕上げるインセンティブがありません。
そうなると、ビジネスとしての論点は「最もバリューがあるソフトウェアはどんなものか」ではなく「クライアントが許容する最低ラインを超えているか」に収束します。 もちろん個人として高い品質を追求するエンジニアは存在しますが、それは構造に逆らう行為であり構造に支えられていない分、例えば良いソフトウェアを追求するための行為が人事評価にポジティブに影響しなかったりします。
第二に、料金が人の単価と稼働時間から計算されるという点です。 受託の料金は、最終成果物が作る価値ではなく、投入された人の稼働時間から計算されます。 とすると安く仕入れて高く売るビジネスの原則に従えば、売上を最大化する方法は「安い賃金の人に長く働いてもらう」になります。 これは関係者の倫理感の問題ではなくまた構造の問題です。 プリンシパル=エージェント理論が示す通り、インセンティブ構造がその方向を向いている限り、合理的な判断の積み重ねがこの結果に収束します。
たとえスクラムをしてもペアプログラミングをしても、ビジネスモデルが変わらなければ、開発現場の根本的な性格は変わりません。
自社製品開発ならば良いのか
私はソフトウェアエンジニアやデザイナーのカジュアル面談に出ているのですが、「受託から自社製品開発へ」という軸で転職活動をしている方に出会うことが多くあります。実際、私自身もその考えで転職活動をしていました。
直観的には、自社製品開発なら構造は変わります。作ったソフトウェアが売れれば会社の収益になるわけですから、「最低ラインを超えるかどうか」ではなく「最大の価値を届けるにはどうするか」が論点になるはずです。
しかし自社製品開発にも異なるビジネスモデルがあり、違った構造を作り出します。
SaaSにはSLGとPLGがある
SaaS業界のビジネスモデルは、SLGとPLGに大別できます。
SLG(Sales-Led Growth)は、営業担当主導で商品・サービスを販売するビジネスモデルです。具体的な販売の流れとしては、製品HPで資料請求してもらいリードを獲得、インサイドセールスが電話・メールでアポを取り、フィールドセールスが商談し契約まで持っていき、契約後はカスタマーサクセスが導入定着を支援するというものです。
PLG(Product-Led Growth)は、プロダクト自体が売るモデルです。資料は自由に閲覧でき、無料お試しは何度でも、基本的に商談はなく、気に入ってくれたユーザーが自分で契約する。人が直接介在せず、ユーザー自身の行動のみで購入の判断をしてもらいます。
同じSaaSという言葉で括られていますが、この2つは構造としてまったく別のビジネスモデルです。誰に、何を、どう売るかが違うので、当然ながら開発現場に降りてくる構造も違ってきます。
SLG型自社製品開発の構造
SLGでは、営業組織が顧客と開発の間に入ります。
この構造から、開発現場には固有の問題が降りてきます。
第一に、判断の起点が「営業が売れると言っているかどうか」に収束していきます。営業は顧客と直接向き合っているので、現場の声として「この機能があれば契約が取れる」「あの競合にはあってうちにはない機能がある」という情報を持ち込みます。これ自体は有用な情報です。しかし開発の論点は「顧客群(マーケット)にとって最大の価値は何か」ではなく「(今商談している)顧客がこう言っている」になっていきます。
第二に、販売計画が開発計画を規定するようになります。売上目標を達成するために、この時期までにこの機能をリリースしなければならない。この逆算は事業運営上健全に見えますが、開発側の自由度を徐々に削っていきます。
これも営業の倫理感や能力の問題ではなく、受託開発のときと同様に構造から来るものです。
プリンシパル=エージェント理論で見ると、SLGではエージェンシーの連鎖が二重になります。本来のプリンシパルである顧客と開発の間に、営業という中間エージェントが入る構造です。
営業には営業のインセンティブがあります。例えば、1万5千円の契約を10件獲得した営業と、100万円の契約を1件獲得した営業のどちらが評価されるでしょうか。また営業はどちらを目指したくなるでしょうか。このインセンティブ構造から、SLGはサービスを高単価にし、大企業向けの開発を優先する圧力がかかります。
PLGという構造がもたらすもの
PLGでは、プロダクト自体が顧客と対話する構造なので、営業という中間エージェントを介さずに、顧客の反応が直接開発者に返ってきます。
この構造的な違いは、開発現場に4つの変化をもたらします。
第一に、判断基準が一元化されます。「営業が売りやすいか」や「販売計画に間に合うか」ではなく、「特定顧客ではなく顧客群(マーケット)にとっての価値があるか」が唯一の判断軸になります。社内で議論が分かれたときに立ち戻る場所が、「使ってくれるユーザーにとって良いかどうか」になります。そしてPLGでは結局マーケットで売れるのかに判断が収束します。これが一番大きな変化です。
第二に、エンジニアが直接結果を得ます。作ったものが良ければユーザーが増え、契約が増える。悪ければそうならない。この手応えが、営業という媒介なしにエンジニアに直接返ってきます。結果の手応えが伝聞ではなく、エンジニア自身の経験になります(ただし多くは数値を通じた経験ですが)。
第三に、主体的な開発計画になります。販売計画から逆算した締め切りがありません。リリース計画は開発側が決定します。これは「好き勝手にやる」という意味ではなく、「顧客価値に照らして最適な判断を自分たちで下す責任を負う」という意味です。最善の開発を磨き続ける責任があります。
第四に、コスト構造が優位に働きます。PLGでは売上の増加に対して営業コストが比例しません。だから利益が出やすく、結果として低価格でも提供できます。これは単に価格競争力があるという話にとどまりません。弊社のミッションは「すべての人を非効率な仕事から解放する」です。"すべての人"に届けるには低価格であることは必要条件です。また利益があれば継続した昇給が可能になります。
この4点が揃うと、冒頭に挙げた「ソフトウェアの利用者(たち)にとって、より良いものを作る」という私が読んでいた書籍に共通する理想が、個人の奮闘に依らず、構造上の帰結として成立しはじめます。
PLGは楽な道ではない
ここまでPLGの良さを書いてきましたが、トレードオフとしての難点もあります。
第一に、責任がエンジニアに返ってきます。直接結果に向き合うということは、ダメだったときの責任も感じるということです。他責することが構造上できません。
第二に、要求水準が上がります。要件を満たすだけでは不十分で、"売れるもの"を作らなければいけません。機能比較表を満たすだけでは不十分で、体験が良いなど選ばれる理由も作る必要があります。
第三に、直接のフィードバックが得づらくなります。営業が常に購買に直接つながる顧客の声を集めてきてくれる構造ではないので、改善につながる情報を得る難易度が上がります。ユーザーの行動データや問い合わせなどから、"真に解くべき問題は何か"を推察する力が求められます。
第四に、新サービスの立ち上げが難しくなります。PMF(Product-Market Fit)するまでの試行錯誤に使える情報や初期ユーザーの獲得が難しく、暗中模索の中をなんとか切り開く必要があります。
総じて責任の所在が明確になり、言われたものを作るのではなく、主体としてビジネスに参画することが求められます。
これを重荷と感じるか、手応えと感じるかで、PLGが向いているかどうかが分かれると私は考えています。
どういうエンジニアに向いているか
これまで採用活動を行ってきて、PLGが向いているエンジニアには共通する傾向があると感じています。
- 営業の要求や上司の指示よりも、顧客価値を判断の軸にしたい人
- 結果に対する責任を負担ではなく手応えとして楽しめる人
- 自律的に判断することを求められる状況を歓迎する人
もしここまで読んで、自分のことかもしれないと感じたら、一度お話しさせてください。
また、弊社とご縁がなくても本記事が迷われている状況を整理する一助になると幸いです。
トヨクモでは一緒に働いてくれる技術が好きなソフトウェアエンジニアや、デザインが好きなデザイナーを募集しております。
採用に関する情報を公開しております。 またインタビュー等の記事もあります。 気になった方はこちらからご応募ください。
