2010年に創業された株式会社スタディストは、マニュアル作成・共有システム『Teachme Biz』、実行力向上支援システム『ハンクラ』、コンサルティングサービスを提供している会社です。
2016年まで一けただった従業員数は、2023年3月1日時点で178名（※業務委託・派遣を除く）まで急速に増えています。開発を担う開発本部でも、月あたりのリリース回数が10倍になるなど、事業拡大にあわせて成長を続けています。
株式会社スタディスト 取締役 CTOの佐橘 一旗さんと執行役員 VPoEの北野 勝久さんに、成長する開発組織についてのお話をうかがいました。
関連記事：フルリモート環境で心理的安全性の高い組織づくりをする方法
大企業からスタートアップへ転職した二人
――お二人がスタディストに入社した理由を教えてください。
佐橘：
一番の理由はプロダクトがおもしろそうだったからです。誰もやっていないことができそうだと思いました。
もともと、自分でもスタートアップをやりたかったんです。学生時代にスタートアップに関するゼミに入ったり、実際に起業したりしていました。大学卒業後は、株式会社リクルートホールディングス（現：株式会社リクルート）に新卒で入社し、6年ほど働いていました。次にジョインする会社はフェーズを問わず、スタートアップで考えていたんです。
いまの時代って、どこにでもSaaSがありますよね。もうSaaSの参入余地はどこにもないと感じるなかで、スタディストがやっている「手順」の領域はどこもやっていないように思えました。この時代にもブルーオーシャンが残っていたか、と。
北野：
わたしも同じく、プロダクトがおもしろいと思いました。手順書はほとんどの会社に存在していますが、フォーマットは各社で異なります。ここをなんとかすれば、組織の生産性につながるし、世の中の役に立ちそうだと思いました。
前職は日本タタ・コンサルタンシー・サービシズという、インド最大財閥のIT企業の日本法人で働いていました。当時で全世界のグループ総従業員数が30万人以上いるような会社で、規模が大きすぎて仕事している実感が得にくいと感じていたんです。規模の小さい会社で働きたいと思い、当時の社員数が20人くらいのスタディストにジョインしました。
入社前に代表の鈴木と面談する機会をもらい、大量の質問を準備していろいろと聞いたんです。そのときに、はるか先のことまで考えて計画していることがわかりました。スタートアップは代表の与えるインパクトが大きいので、「これはおもしろいことになりそうだ」と思って入社しました。
――お二人とも大企業からスタートアップへ転職されたわけですね。現在、御社の従業員数は178名とうかがいました。開発本部の規模はどれくらいなのでしょうか？
佐橘：
開発本部には56名が在籍していて、エンジニアのほかに、プロダクトマネジャーやプロダクトデザイナーも含まれます。カスタマーサポートも5名ほどいます。
CTOとVPoEに求められるスキル
――佐橘さんはCTO、北野さんはVPoEという立場です。役割分担はどのようにされていますか？
佐橘：
CTOなんですけど、最近は開発管掌役員としてポートフォリオ管理をしています。攻めと守りをどのくらいにするか、などです。横断の技術組織や採用、開発文化をどのようにしていくかは、VPoEの北野に任せています。
北野：
VPoEであるわたしの場合も、テックリードとして現場のアーキテクチャをひたすらやっているかというと、全然そのようなことはありません。エンジニアチームに優秀なメンバーがいるので、連携しながらやっています。
佐橘：
他社でもテックリードになれそうな人材を、できるだけ採用するように意識しています。正直言って、現場からしてみると個別の技術選定とか実装指針に関して、上がしゃしゃり出ても迷惑なんですよ。こちらとしても、複数のチームが動いているとコンテキストに追いつけません。
なので、最後の責任を取る覚悟だけは持っておいて、現場に介入する必要がないようにしています。
――現場の方々を信頼して任せて、なにかあったら責任を取るスタンスなわけですね。お二人は、CTOに求められるスキルはなんだと思われますか？
佐橘：
よく他社の方から「CTOを採用したいんだけどどうしたらいい？」と相談を受けます。CTOという言葉は多義語だと思うんです。会社の規模やフェーズによって役割は違います。
たとえばスタートアップといっても、規模は異なりますよね。立ち上げ時期であれば、取り組んでいるドメインを理解して、いち早くプロダクトをつくって試せるスキルが必要です。プロダクトがマーケットにフィットしてスケールした時期であれば、セキュリティやスケーラビリティに関するスキルが必要です。さらに、チームを複数抱えるようになると、組織について考えるスキルが必要となります。
どの状況であっても、スーパーマンであろうとするのは無理です。できることとできないことがあると理解しつつ、やらなければならないことを見つける。それをやるために、どのような人を採用すればいいか、どうすれば達成できるかを考える必要があります。
会社の状況を理解して、判断を変えられるかが一番大事だと思っています。
北野：
CTOは、経営のロールとしての意味合いが強いと思っています。経営全体のリソースにおける技術の配分をよく考えてコントロールしているな、と佐橘と一緒に経営会議に出て感じました。
――VPoEに求められるスキルはなんだと思われますか？
北野：
CTOと同じく、VPoEという言葉も多義語だと思います。会社の規模やフェーズによってやることは異なります。ただ、共通しているのは採用や組織づくりについての期待が大きいことです。
採用や組織づくりだけできる人であればいいかというと、そうではありません。事業や技術が交わる部分で、採用や組織づくりをしていきます。そのなかでも、技術がどうインパクトを与えていくかに好奇心を持つことが適正として大事だと思います。
佐橘：
採用や組織づくりに関するスキルが求められると思います。組織の文化や人事評価に関することなど、いかにエンジニアが楽しく、プライドを持って働けるようにできるかが大事です。
リリース回数を10倍にした組織改善、カスタマーサポートを組織にいれるなどの取り組みも
――これまでに組織運営で失敗したことを教えてください。また、失敗経験を踏まえて改善したことを教えてください。
佐橘：
顧客や事業ドメインを理解してプロダクト開発にのぞむべきだと思っていますし、実際にやってきています。ただ、うちの場合『Teachme Biz』のように、Horizontal（水平）なtoBプロダクトを開発・運営しています。なので、顧客のバリエーションが広いんです。銀行の融資窓口や製造業の機械メンテナンス、レジ打ちの方法などさまざまあります。顧客理解を求めたときに、みんなの見ていた顧客が違ってしまいました。
この事例をもとに2年くらい前から改善していることがあります。パイロット顧客を3社ほど決めて「この人たちのために機能開発するぞ」としました。大きい開発のときは、β版をパイロット顧客に使ってもらい、フィードバックを得るようにしています。これはうまくいっていますね。
北野：
Why・WhatだけではなくてWhoもすごく大事です。「誰に向けて」が定まらないと、どういう方向性に向かうのかが定まりきりません。
――佐橘さんと北野さんの2名体制になってから、月あたりのリリース回数が10倍になったとうかがいました。どのようにして、リリース回数を大幅に増やせたのか教えてください。
北野：
技術面と組織面の話があります。技術面だと自動リリースのように機械にやってもらうことで、誰でもできるようにしたことが一番の変更点でした。ただ、エンジニアの意識として、品質が大事だから気軽にリリースするものではないという組織文化だと、これはできません。そのために組織にも向き合ってきました。
昔は開発の進め方が、ある意味ウォーターフォール的というか、すぐリリースしたらいいのにできない課題感があったんです。
そこから専門のSlackチャンネルを作って、みんなでリリースサイクルをどのようにしていくかを議論しました。最終的にドキュメント化し、リリースできるものは随時出していきましょうというスタイルに変えたんです。
佐橘：
組織に関しては、カスタマーサポートを開発チームに入れているのもその一環です。リリースが増えると、カスタマーサポートが疲弊するんですよ。お問い合わせが来たのに「その機能について知りません」とは言えないので、事前にインプットする必要があります。
とはいえ、お客さまのためには機能がどんどんリリースされるのはいいことです。一緒のチームになったことで、会議体も同じになり密に話せますし、キャッチアップもしやすくなります。
北野：
カスタマーサポートが開発チームに入ったことで、お客さまからの声を共有しやすくなりました。毎週1回、開発中の機能を見せながら話す機会があります。
そこで、カスタマーサポートのメンバーから「この機能なら、あのお客さまが喜ぶと思います」とフィードバックを得られるようになりました。これは、開発者にとっても非常にいいと思います。
ソフトウェア開発はチームスポーツ
――組織で活躍できるエンジニアはどのような方でしょうか？
佐橘：
「共通認識」をつくれるかどうか。これがすべてだと思います。自分が知っていて相手が知らないことや、相手が知っていて自分が知らないことを認識できる人は、組織で活躍できると思います。相手を理解しようとすることは大事です。
北野：
やりたいこととやるべきことを、お客さまや会社のメリットと結びつけて周囲を巻き込める人は活躍できると思います。たとえば、技術のフレームワークのバージョンアップって、非エンジニアの人にとってはなぜやるのかが、わかりづらいですよね。
そこでしっかりと理由を話せる人は、周囲もついてくるので活躍しています。
ソフトウェア開発はチームスポーツの側面が強いと思うので、コミュニケーション能力は必要だと思います。
関連記事：フルリモート環境で心理的安全性の高い組織づくりをする方法
（取材／文：川崎博則）
