『THE MODEL』を読んだ

「科学的な営業」に興味があり、その分野の定番のひとつである『THE MODEL』を読んだ。
どのように営業プロセスを構築し機能させるのかについてコンパクトにまとまっているので、特に BtoB SaaS を提供している企業で働いている開発者は、一度読んでおくとよいと思う。

www.shoeisha.co.jp

なんとなくの印象だが、「営業」というものについて、自分とは縁遠いもの、別の世界のもの、という感覚を持っている開発者は多いかもしれない。
自分もそうだった。むしろ、かなり悪い印象を抱いていた。

新卒で入った信用金庫の営業スタイルが絵に描いたような根性論、精神論だったのが大きい。
「飛び込み営業をすれば嫌がられるし、何度も訪問すれば怒られる。それでも諦めずに通い続けることで根性を認めてもらえて、取引してもらえるんだ」ということを役員が真顔で語っていたし、「昔は「契約するまで帰りません」と玄関に座り込んだもんだ」みたいな「武勇伝」をよく聞かされた。ビジネスモデルや対象顧客が違いすぎるから、SaaS 事業者と比較するのはフェアではないかもしれない。それでも、ひどかったと思う。
そもそも、顧客の利益など誰も考えていなかった。とにかくノルマのことしか考えていなかった。使いもしないカードローンを契約してもらう、月末の融資残高を増やすためだけに不要な借り入れをしてもらって翌月にすぐに全額返済してもらう、みたいなことを支店ぐるみ、いや会社ぐるみでやっていた。今もやっているのかもしれない。誰のためにもなっていない、数字をいじるためだけの「営業」だった。本当にバカバカしかったし、嫌だった。ノルマ未達だと罵声や暴力が待っているし。
そうではない営業も存在するのかもしれないが、それはフィクションの世界の話というか、それこそビジネス書のなかのお話であり、自分にとってのリアルな「営業」というのは、上記のようなものを指していた。

だが現職では「そうではない営業」を実践しており、イメージが変わった。
「THE MODEL」型のプロセスを構築して営業活動を行っている（今日現在）。そしてちゃんと数字を積み上げている。

SaaS 事業者で働いたことがなかったこともあり、「THE MODEL」という概念自体を知らなかったのだが、入社直後の研修で説明してもらって興味を持った。
新卒時のトラウマもあって自分が営業をやってみたいという気持ちにはならないが、「学び、理解する対象」として面白そうだなと思った。そこでまず手始めに、本書を手に取った。

本書のことも当然知らなかったのだが、「THE MODEL」という概念を日本に広めた本らしい。
「THE MODEL」の概要を大雑把に説明すると、営業プロセスをマーケティング（MK）、インサイドセールス（IS）、フィールドセールス（FS）、カスタマーサクセス（CS）に分解し、各プロセスが協力して売上を伸ばしていくモデルのことを指す。
従来の営業は、一人の担当者が全ての領域を担当していた。見込み客の開拓、商談、既存顧客の管理、全てを行う。私が所属していた信用金庫もそうだった。そうではなく、分業体制を敷き、そのプロセスを緻密に管理していくことに、「THE MODEL」の特徴がある。

本書では、「分業（顧客ステージの分類）」の他、「客観的な指標による計測」、「リサイクル」、などが重要な概念として何度も出てくる。
既に述べたように 4 つのプロセスに分解するのだが、各プロセスのなかでもさらに細分化を行い、「顧客は今どのステージにいるのか」ということを緻密に管理する。そしてセミナーやアポイントメント、商談、オンボーディングなどの各種コミュニケーションは全て、顧客を次のステージに進めるために行われる。そして、提供すべきコミュニケーションやコンテンツはステージ毎に異なるため、正確な顧客管理が重要になる。プロセス管理を細かく行うことで、どこがボトルネックになっているのかも把握しやすくなる。
そしてそれを行うためには、客観的な指標が必要になる。ステージが遷移したと判定するための明確な基準がなければ、管理や分析は上手く機能しない。性質上どうしても主観が入るものもあるが、それでも、担当者毎のバラツキを抑えるための取り組みを行うことが求められる。
そして、顧客ステージの遷移は直線的にのみ行われるものではなく、循環する。具体的には、様々な理由で受注にまで至らなかった顧客を「リサイクル」というステージに遷移させる。そしてそのステージの顧客を、再び検討プロセスに戻す。例えば、顧客の事業フェーズの問題で受注にまで至れなかった案件が、半年後には状況が変わって受注できる状態になっているかもしれない。このような失注した案件の掘り起こしは目新しいものではないが、これを仕組みとして管理することで、新規開拓だけに頼らない成長が可能になる。

著者自身が「自分の会社にとっての「ザ・モデル」を創造することを目指してほしい（「はじめに」より）」と述べているように、本書で紹介されているやり方をそのまま模倣すればいいというものではない。
それでも、基本というか、定番の考え方や方法論を知ることで、議論を理解しやすくなるとは思うし、読んでよかった。

自分は開発者として本書を読んでいたが、「開発者がよいプロダクトを作らないとどうにもならないんだよな」と改めて思った。
営業組織がいくら高い志を持ち、ロジカルに戦略や戦術を立て、頑張ったところで、商材であるプロダクトがポンコツで顧客のニーズに全く応えられておらず、そして競合にもあらゆる面で負けていたら、どうしようもない。
価値のあるプロダクトを作り続けないと、自分がすごく嫌だった「数字を作るため、顧客にとって明らかに不要なものを売り込む」という状態を生み出しかねない。

「何を作るか」は全社的に決めていくことだが、「どう作るか」は基本的には開発組織の責任だと思う。
スピード感を持って開発できなくなる要因はいくらでもある。開発者としての実務経験は 3 年にも満たないが、それでも、何度も見てきた。純粋な技術力不足もあれば、組織が硬直化して機動的に動けないこともある。過去の雑な実装や設計が積み重ねって身動きが取れなくなることもある。採用や育成に失敗して開発組織のキャパシティを大きくできず、事業が縮小していったケースも見た。

最終的には、営業組織と開発組織は独立して個別に存在するものではない、お互いに影響を受け合う、みたいな当たり前過ぎる感想になった。だけどこういう話をしている開発者ブログはあまり読んだことがないから、関心を持っている人は少ないのかもしれない。
私も、自分が営業を経験していなかったら、興味を持つことはなかったかもしれない。そう考えると、とにかく苦痛だった信金時代にも少しくらいは意味があったのかもしれない。

技術選定の観点や技術の優劣について

技術選定を行う前にまず、どのような開発組織にしたいのか、どのように事業を進めていきたいのか、そこを整理しないと上手くいかない。
そんなことを最近考えていたので、ブログに書いておく。自分は書くことで思考を整理していくので。

この記事では、「技術選定」そのものについて書いていく。
そのため、個別のライブラリの良し悪しを判断する手法などについては扱わない。もっと抽象度の高い、どのような考え方や態度で技術選定に臨むべきか、というようなことを書いていく。

また、作りたいものを作れるか、仕様を満たせるか、セキュリティ上の問題はないか、などの当然の前提は省く。
そういった「最低条件」を満たした技術が複数あったときにどうやって選ぶのか、という意味での「技術選定」を扱う。

お互いの「納得感」のためにもまずは軸を明確にする

技術選定について考えたり誰かと議論したりする際には、「自分たちは今、どういう観点を基準にして技術を選ぼうとしているのか」を明確にすることが大事だと思う。
そうしないと、思考が迷走したり、議論が噛み合わなかったりする。

社内にノウハウが蓄積されていることを理由に技術Aを推している開発者がいる一方で、今後の人員の増加のためにBを推している別の開発者がいるとする。
このときに議論すべきなのは、「AとBのどちらが適切か」ということではなく、「自分たちはどういう観点で技術を選ぶのか」ということだと思う。そこの認識を合わせる前に具体的な技術の話をしても、上手くいかない。
既存の開発者と相性のよい技術を選ぶのか、それとも、人員を増やすために採用活動に有利な技術を選ぶのか。どちらの観点をどの程度優先するのか。ここの擦り合わせを行っておかないと、議論は平行線を辿る。一人で技術選定を行う場合も、どういう観点で判断すべきなのか自覚的であったほうがいい。
転職活動においてまずは「企業選びの軸」を決めるように、技術選定においてもまずは軸を明確にしないといけない。
特に複数人で技術選定を行う場合は、納得感を醸成するためにもしっかりと考え方について合意を取っておいたほうがいい。絶対的な答えが存在しない中で、自分たちは相対的に何を重視して何を妥協するのか。また、妥協するにしても、譲れない最低ラインをどこに引くのか。こういったことを明確にしないまま技術選定を行ってしまうと、納得感は生まれにくく、不満が残りかねない。

最終的には事業戦略や組織戦略の話になる

技術選定の観点は、先程の例の他にも様々なものが存在する。
短期的な生産性を重視したいのか、時間を掛けてでも堅牢なシステムを作りたいのか。安定性のために十分に枯れている技術を使いたいのか、開発者のモチベーションや技術的な優位性のために最先端の技術を積極的に取り入れていきたいのか。
様々な観点があり得るし、どの観点を重視すべきなのかは、状況によって変わる。つまり、「どのような観点で技術を選ぶのか」についても、前段の議論に依存する。ここでいう「前段の議論」とは、事業や組織に対する基本的な考え方や戦略のことである。

とにかくスケールさせて時価総額を高めることや上場することを目指している組織と、人を増やすことに慎重で少数精鋭のまま経営していくことを意図している組織とでは、当然、技術の選び方にも違いが出てくる。
事業内容によっても違う。可能な限り長く運営していくことを意図しているウェブサービスの開発と、納品や出荷をすれば終わりというプロダクトの開発とでは、技術の選び方はかなり変わってくるだろう。前者では常にメンテナンス性を意識することになるが、後者は必ずしもそうではない。少なくとも優先度は変わってくる。
また、既に売上を稼いでいる主力サービスなのか、それとも実験的なプロダクトなのか、といったように、プロジェクトの立ち位置によっても変わってくる。

まとめると、まず事業や組織の戦略について整理する。そして、その戦略を実現するためにはどのような観点で技術を選ぶべきなのか、考える。そしてその観点に従って、具体的な技術選定を適宜行っていくことになる。

現場のニーズに応えられる技術か

このように、「現場のニーズ」から、どの技術を選ぶべきなのかが決まってくる。具体的な状況を想定しない「技術選定」は存在し得ないと思う。この記事では事業における技術選定を扱っているが、個人開発や OSS の現場でも、やはり何からのニーズがある。「仕事で使っていない技術に触りたい」というのも、立派なニーズだ。そこから、「仕事ではいつも React を触っているから Elm をやってみるか」などの技術選定が行われる。
まずはニーズがあって、じゃあそれに最もよく応えてくれる技術はどれか、という論の運び方になる。

そこから分かるのは「最強の技術」などはないということだ。
いついかなる時も選ぶべき「決定版」のような技術など存在しない。
守備範囲が広くて多くのケースに応えられるから採用されやすい技術、というものはあるかもしれないが、それでも、常にその技術が正しいというわけではない。
そしてこのことは、技術に対して単純に優劣をつけることは難しい、ということも意味する。ある特定の観点や尺度において優劣をつけることは出来るかもしれないが、別の観点を持ち込めば結果はまた変わってくる。

長期にわたって広い人気を獲得している技術は、他の技術よりも優れているから人気を獲得したわけではなく、多くの現場のニーズに上手く応えられたから人気を得たのではないだろうか。
もちろん、人気というのは色んな要因で決まるから、そう単純な話ではないが。
それでもやはり、一時的なブームではなく安定的な人気を得るためには、多くの現場のニーズに応えていることが必要条件になると思う。逆に言えば、技術的に高度であったり、先進的なことをしていたりすることは、人気を得る上ではあまり関係ない。
そう考えると、ある技術が人気なのは、それが「優れているから」ではなく、多くの現場のニーズに応えているからに過ぎない。そのため、人気のある技術だからといって、自分たちの現場のニーズに上手く応えてくれるとは限らない。人気という意味では後塵を拝しているような技術のほうが、自分たちの状況に上手くハマる可能性は十分にある。

ライブラリの盛衰

そして、「最適な技術」は時間の経過によって変化していく。
なぜなら、現場のニーズは変化していくから。創業期と拡大期では、事業の戦略や進め方は変わってくる。市場の変化によってビジネスモデルそのものが変わることもあるかもしれない。
同様に、技術の立ち位置も変化していく。より便利な後発の技術が出てくるかもしれないし、利用事例が増えることで「実務に耐えられる」と見做されて採用されやすくなることもあるだろう。

定期的に「XXX（任意のライブラリやフレームワークなど）はオワコン」のような言説が出回る。大半は読む価値のないものだが、中には（表現はともかく）鋭い指摘をしているものもある。
それまでは「多数派のニーズ」に上手く応えておりそれゆえに人気のあった技術が、変化した「多数派のニーズ」に上手く応えられなかったとき、あるいはもっと上手く応える別の技術が出てきたときに、「衰退」が始まるのかもしれない。個人的にはそんな風に思う。

とはいえ、それはあくまでも「人気」の話であり、「優劣」ではない。
もちろん「人気」も重要な尺度ではある。「開発者のモチベーション」「開発者の集めやすさ」「エコシステムの充実性」などの理由で「人気」の技術を選ぶことは十分にあり得る。だがそれは、尺度のひとつに過ぎない。
それ以外の尺度を重視している組織にとっては、「衰退」した技術が上手くマッチすることもあり得る。