前置き
THE MODELではSaaSの役割分担として、従来の「営業」を、フィードセールスとかインサイドセールスなど、フェーズごとに分担していく形で細分化した形態について、徹底的に書かれています。そこでは、その中の位置役割として「営業」というものが出てきます。
が、このブログではセールス周りの役割全体を包括する意味で「営業」と使います。
感想
まず、この本に書いてある顧客へのリーチや販売プロセスのについてはアジャイル開発と似たものがあると思いました。特に見積りやタスク管理の考え方についてです。アジャイルの見積りと同様にその見積りの数字自体の精度は大した問題ではなく、それをしばらくつけていくことでチームとしての実力がわかることが大事だと言いたいのだと解釈しました。また、誰か一人が頑張ったりタスクが偏ったりしてベロシティを上げるのではなく、再現性や専門性、責任の範囲を明らかにすることで、全体としてのパフォーマンスを上げることを目指すことが書かれていました。同時に、自分達には制御不可能な要素（例えばセールスの話であれば、売れると思った会社が潰れてしまって契約にならなかった、ということがあるかもしれません）を明らかにし、逆に言えば制御可能なことを認識することで、生産性を上げることや顧客への適切なアプローチやサポート、関係づくりに注力できるという話がありました。
また、最近読んだ書籍だとチームトポロジーとも通じる点を感じました。 それぞれの役割があること、しかしそこには引き継ぎがないことが、本書では「分業から共業へ」の中で書かれていました。キーは「通常だったら一方通行になり得る分担の中で、逆方向へのコミュニケーションが必要になるような要素や動きがあること」だそうです。 チームトポロジーは、開発チームを主眼に置いた組織作りの話でしたが、ストリームアラインドチームは、CSや営業のような顧客と直接接点のある部署やメンバーとの話があったように記憶しています。今回読んだ本は営業が題材だったので営業内での共業の話がメインでしたが、実務としてその範囲は決して開発内、営業内などに閉じないと自分は感じていて、良いあり方を自分でトライしてみたいなと思いました。
少し話は変わりますが、「トップが開発のプロの会社と、経営のプロの会社では後者の方が絶対にうまくいく」というようなことが冒頭で述べられていました。一開発者としてはそれはちょっと引っかかりは覚えますが、言わんとすることはわかるなと思いました。
開発者として仕事をしていて、開発チームの中から製品・会社・顧客を眺めていると「私たちはこんな思いでここにこだわってこんなふうに開発したんですよ」というのをまずは伝えたくなったり「使ってみた感想を聞きたいです！そしてさらに製品を良くしたいです！」という思いを強く抱く傾向が私にはあります。そういう傾向が強いので、「自社開発で正社員」という働き方にこだわっている面もあるくらいです。 それは決して悪いことではないと思うのですが、営業の世界線では、0から新規開拓、商談、契約、継続的なサポート、プロダクトの活用やトラブル対応といった関わりがあると踏まえた時に、自分の開発者としての仕事の仕方は工夫の余地があるように感じました。「工夫の余地」が何かというのはすぐには言語化できないのですが、今後の仕事の中で答えになるようなものを作っていきたいなと思いました。
余談
最近株式会社アンドパッドを退職しました。入社時に、初めてSaaS開発をするというのもあり、SaaSの鉄板書としてこの本を読んだのですが、なんだか全然ピンとこず「いつか再読しよう」と思っていました。それで、色々と機会があったので今再読しました。在職中リモートな環境もあって事業部のメンバーとはほとんど接点が皆無だったのですが、社内の広報やイベント（総会など）を通して、2年のSaaS開発経験は営業周りへの理解も与えてくれていたことを感じる機会となりました。初回は数日かけても途中で止まってしまいましたが、今回は全部で3時間くらいで読み終えました。 ちょっとは成長したかもなー
