新しいビジネスモデルを成立させるシステム開発の面白さ
なぜこの記事を書いているか？
Saleshubでエンジニアをしております安田と申します。
今、Saleshubのエンジニア採用活動の一端を担わせていただいているのですが、エンジニアに「Saleshubにおいでよ」とお誘いするにあたって、今
自分がどんな風に働いているか？
どんなことを喜びとしているか？
こうした内容をある程度明らかにしておかないと、誘われた方も意思決定しづらいだろうな、という思いから今回記事を書いています。
なので、この記事を読んだ方が、読み終わった後
この人はこの会社でこんな風に働いているんだ、ということがイメージできる
Saleshubに少しでも関心を持っているエンジニアが、Saleshubでは開発はこんな感じでやってるんだ、とイメージができる
そんな状態が作れたらいいなと考えています。
私は誰か？
詳細な自己紹介は割愛しますが、noteをはじめブログ等を各所に書き散らしていますので、そちらをお読みいただたら嬉しいです。
https://note.com/takata_no_toshi
https://qiita.com/toshi1973814
https://zenn.dev/takatanotoshi
さて、私はSaleshubに入社して大体10か月が経ちました。入社後5か月の時点でも記事を書きましたが、さらに5か月が経過する中で、事業への解像度や組織への理解度が上がり、僕の中で皆さんにお伝えしたいことも増えてきています。今日はそのあたりも含めて書いてみたいと思います。
プログラムコードの新陳代謝が高い理由
今、ちょうどSaleshubの開発チームでは、不要コードを消す、という作業を進めていますが、Saleshubのシステムは不要コードや不要データが頻繁に生まれます。それはシステム設計が悪いのではなく、様々な施策をトライアンドエラーし、効果測定をし、十分な効果が得られなかったものは不採用にし、効果のあったものだけを残していくという、スタートアップとしては健全な理由によります。
ただ、それゆえの難しさもあります。
不要コードは、削除が忘れられ残存してしまうケースもありますし、そもそもその施策がいつ失効したのかがあいまいなケースもあります。
なので、今ちょうどそうしたコードを集中的に整理しているところではありますが、そこにはSaleshubの開発の特徴も現れていると思います。
それは仮説に基づく新しい挑戦がどんどん打たれてきたということ。
そしてその効果がしっかり計測され、KPIとしてモニターされ、改善サイクルが回されることによって、施策としてさらにブラッシュアップされたり、捨てられたりするということが、継続的に実行されてきたことの証ではないかと思います。
もちろんプログラムコードに追加されたり、削除されたりの試行錯誤があることが、事業的な試行錯誤の健全性を保証するということが言いたいわけではありません。無駄な試行錯誤によってそういうことも起こりうると思います。ただ、Saleshubでは開発の意思決定が、KPI等のデータに基づいてしっかりと行われています。
非エンジニア向けSQL勉強会
具体的にはRedash上でのSQLによるデータ分析が非常に活発に行われています。活発さの一つの証拠が非エンジニア向けのSQL勉強会です。
Saleshubではエンジニアが主導する形で非エンジニアメンバーのSQL勉強会を行っています。CSやセールスのメンバーが「こういうデータがどうなっているか知りたい、と思ったときに、エンジニアにいちいちSQLを頼んで作ってもらうのではなく、自分でSQLを作ってしまえたほうがいいよね」という話が、発端です。
そうした話を起点として始まったSQL勉強会も、すでに半年くらいが経過していますが、実際に非エンジニアメンバーが「こういうデータが欲しい」という自分の要求を、エンジニアのサポートを得ながらにせよ、自分で書くというところまで到達しています。
また、そういうメンバーに引っ張られる形で、新しくSQLを勉強し始めるメンバーも継続的に現れているので、そうした方向けに初級者向けのSQL勉強会もたびたび開催している、という状況です。
このようにエンジニアや経営陣だけではなく、非常に多くのメンバーがSQLを使ってデータを分析し、意思決定するということに非常に高い意識を持っています。
データドリブンとオープンネス
Saleshubの施策のトライアンドエラーはそうしたデータドリブンな性格を多分に持っているので、納得感があり、かつ根拠に基づいています。
仮説に基づいた挑戦、といっても組織によっては、誰か強い権限を持った人が独断的に作った仮説に基づいて施策が決定され、メンバーは納得感のないままにその施策を遂行せざるを得ない、そんな組織もあったりするかと思います。
Saleshubでは、多くの施策が決定プロセスを含め、主に朝会を通して日次で共有されていきます。ブラックボックスの中で施策が決定されるということは基本的にありません。また施策に関する議論も基本的に全社員に公開されており、疑義が生じた場合は、その議論にどんどん参加していくことができます。Saleshubには、そういうオープンネスがあります。
そのようなオープンな環境で議論され、仮説に基づいて新しい挑戦が行われていきます。また、その挑戦はデータに基づいて決定されていきます。そうした改善サイクルが日々スピーディに行われていきます。このスピーディな改善サイクルは、組織の健全性の証である一方で、事業の性質が要求するものでもあります。
存在しないビジネスモデルを作り上げる難しさ、面白さ
Saleshubのビジネスモデルはまだまだ世の中的に確立されたものではありません。むしろ同じビジネスモデルの企業はSaleshub以外には存在しません。もし、このビジネスモデルが確立されたモデルであるのなら、どんどん追随する企業が現れるかと思いますが、全く現れないわけではないにせよ、ほとんど現れていない状況です。これがSaleshubの事業の最も大きな特徴になるかと思います。
まだ存在しないビジネスモデルを成立させる。
それがSaleshubでの仕事の難しさであり、また面白さでもあります。
なので、この事業に関わるシステム開発も、当然不確実性が高く、本当に効果のある実装を探り当てるのが難しいです。
場合によっては、簡単な実装を加えるだけのために、多くの仮説を立て、UIパターンや実装パターンをリストアップし、比較・議論し、時間をかけてその中の一つを選択していく、そんなプロセスが必要になります。
その一方で、実際の機能リリースを繰り返しての改善サイクルも大切です。
仮説はあくまで仮説なので、結局は機能をリリースし、それを測定し、検証しなければ確かなことはわかりません。また、その結果によってまた新たな改善も必要になります。
まだ存在しないビジネスモデルを、上記のような試行錯誤を通してビルドアップしていく。それがSaleshubでの開発の楽しさではないかと思います。
Saleshubの組織の特徴
最後にSaleshubの組織の特徴についても少し触れてみたいと思います。
この組織の大きな特徴として、創業メンバーが学生時代に事業を立ち上げて、一つ屋根の下で寝食を共にしながら事業を作り上げてきた、という点があると思います。
同じマンションに住みながら、サービスを開発し、仕事以外の時間も、一緒にカフェに通ったり、仕事後に神社でフリスビーをやったりしていたそうです。
その話を聞いたとき、「どんだけ仲がいいんだ！」って思いましたが、Saleshubには根底にそういう、ほとんど意味を越えた鉄の結束感や運命共同体感みたいなものが流れているのを感じます。
その一方で、Saleshubは東北や関西在住の方も多く、リモートワークが前提で業務が進行します。僕自身はオフィスで仕事をするのが好きなので、オフィスで仕事をすることの方が多いですが、オフィスにいるメンバーは少数派です。
リモートワーク主体の会社では組織的な求心力を保つのが難しいという話もよく聞きますが、Saleshubの場合はリモートでありながら非常に高い求心力を保っています。それはしっかりと事業に共感を持った適正なメンバーを採用してきたことに拠る部分も大きいとは思いますが、先ほど述べたような創業メンバーたちの結束感もまた大きな影響を持っているような気がしています。
創業メンバーたちが仲が良い、というケースにおいて、創業メンバー以外のメンバーが疎外される、みたいなスタートアップのケースも聞いたりしますが、Saleshubの場合は、そういう疎外感は感じられません。創業メンバーたちは非常に謙虚に新しいメンバーの意見を尊重してくれるので、創業メンバーたちの結束感は非常にいい形で組織の求心力の核になっているように見えます。
技術面での変革、進化
エンジニア向けに記事を書くといいながら、話は若干ビジネス寄りな側面が多かったかもしれませんので、技術的な面についても若干書きたいと思います。
技術面の話は、前回書いた記事でも紹介しておりますが、そこからの進捗含め書いてみたいと思います。
前回記事で「新機能開発を通して、TypeScript + React + Viteの環境に移行を図っています」と記載した部分についても、該当機能は完成し、上記環境が一通り整備された状況です。そして今まだ導入はできていませんが、さらに一歩進んでNext.jsの導入を議論しています。そんな感じで大谷さんの実装および助言のもとに着々とフロントエンドの環境が進化しつつあります。導入した技術の詳細については、こちらにも記事としてまとめております。
r7kamuraさんによるアプリケーション環境改善やRuby, Railsバージョンアップも着々と進んでいます。バージョンアップに関しては、r7kamuraさん側の作業はものすごい進んでいる一方で、それを実際に本番環境に適用する作業班である自分たちメンバー側が追いついておらず、そこがボトルネックになっているところはあります。アプリケーションの適正化、標準化は相当進みましたし、r7karmuraさんのレビューは非常にクオリティが高いので自分含めメンバーは非常に勉強になっています。
AIの活用に向けたプロジェクトも進んでいます。宝さんがそこを進めてくださっていますが、これもSaleshubにあらたな革新をもたらすのではないでしょうか。
その他、開発ではないかもしれませんが、会社としてのビッグトピックとしてTV CM、タクシーCMなどのCM施策がありました。
事業としても大いに盛り上がりましたし、これに伴いWebサイトの大幅な更新もありました。
サービスの機能的にも、
アタックリスト作成機能が追加
企業情報の拡充
通知周りの改善
つながり登録UIの改善
など様々な変更がスピーディに加えられています。
開発チームの進化
開発チーム的な進化もありました。
開発メンバーが二人増えたことです。
一人は正社員で入社した早崎さんです。
モバイルアプリからインフラまで実に幅広く扱えるベテラン、オールラウンダーのエンジニアです。しかも僕と一緒でリモートワーク派ではなくて、オフィスにいらっしゃることが多いので、技術的な問題にぶつかった時に、気軽に相談できたりしてとても頼もしいです。
もう一人は前職で一緒に仕事をしていた
https://twitter.com/_uro3
で、業務委託として参画していただくようになりました。
これは僕個人としてはとてもうれしいことでした。
前職で一緒に仕事をしていて、彼が別の会社に転職してしまい、その時非常に残念な思いをしたので、その彼とまた一緒に働けることが決まったときはとてもとてもうれしかったのです。
彼には今、インフラ整備面でバリバリと活躍していただいています。
最後に
直近の出来事含めて、エンジニアに「Saleshubにおいでよ」とお誘いするにあたって、伝えてみたいことをザーッと書いてみました。いかがでしたでしょうか？
上記読んでみてもよくイメージできなかった、とか「この辺って実際のとこどうよ？」とか疑問や不明点ありましたら、もっと詳細にご説明できますので、Twitter、Facebookなどからお声掛けください。
もちろんSaleshubにジョインしたいとかではなくて、ただエンジニアリングやら開発について話してみたいという方もウェルカムです。
Meetyでお声掛けいただけるのもうれしいです。
この記事が気に入ったらサポートをしてみませんか？