2004年、新卒でゲームの開発会社へ入社後、2006年 株式会社永和システムマネジメントに転職。Rails・iOSエンジニアとして従事するかたわら、iOSアプリ開発の書籍執筆なども手がける。2012年、株式会社リクルートに入社。新規サービスの開発部署にて十数を超えるプロジェクトに参加し、事業責任者や開発責任者などを担う。2019年、ストリートアカデミーに参画。現在は、技術基盤や開発体制の構築・改善を務めている。
ストアカについて
弊社は、“教えたい人”と“学びたい人”をマッチングさせるスキルシェアサービス「ストアカ」を運営しています。
主に、サービスの特長は、3つあります。
1つ目は、教える人は特別な資格がなくても、好きや得意を生かし誰でも先生になれるところ。
2つ目は、ネットでマッチング後は対面型でリアルの場で教えることです。
3つ目は、講座内容がバラエティに飛び全170ジャンルにも及びます。「包丁研ぎ」や「靴磨き」のような一般の習い事にないようなものがあることです。
弊社は、2012年7月に創業し、今年で第8期目になります。スタートアップ界隈で言えば、比較的古株になってきています。
最初は、代表の藤本がほぼ一人で始めていたので、エンジニアはいませんでした。藤本は、ITエンジニアではなかったので、Railsを自ら勉強するなどプログラミングを0ベースから始めて「ストアカ」を立ち上げています。
現在では、会員登録数は、36万万人以上で、そのうち先生として登録している方は2万3千人、講座数は3万5千講座というように、着々と成長しています。
ストリートアカデミーへ入社するまでの経歴
新卒ではゲーム開発の会社に入社しました。もともとゲームが好きだったので、それを作りたいと思いからプログラマーとしてのキャリアをスタートしました。
その後、2006年永和システムマネジメントに入社し、RubyやRailsに加え、日本国内だとアジャイル開発の老舗だったので、アジャイル開発の実践などを行っていました。
ただ当時、受託でソフトウェアを作ることにすごく違和感を感じました。
技術を持たない会社に対して技術を提供するというのは、もちろん価値あることです。一方で、受託したシステムを納品したけれども、そのサービスがユーザーに全然受けなかった時、納品されたクライアントはお金だけを失って終了といったことも多数ありました。
「そういうビジネスだから。」と言われればそれまでですが、エンジニアだったら、多くのユーザーに使われて、そのリターンとして対価を受け取るというような構造の中で働きたいと思うようになりました。
はい、そうですね。永和システムマネジメントで、新規ビジネスに携わっていた時に、システムをうまく作る力と、ユーザーに価値あるサービスを作り届けていくのは、別の意味なのだと感じました。また、そのような力は明らかに不足していると感じ、身に着けたいという思いからリクルートに転職をすることにしました。
リクルートでは、メディアテクノロジーラボという部署でエンジニアとして働いていました。いわゆる新規事業に携わる部署で、リクルートの新規事業提案制度Ringなどの運営をしていました。Ringで誕生したサービスは、有名どころでいうと、ゼクシィや、カーセンサーなどがあり、会社全体として新規事業に関して、気合いを入れて取り組んでいました。
エンジニアも技術ばかりを追うというよりかは、「どうやって新規事業というものを作り上げて、それをどうやって成長させていくか。」ということころを目指して仕事をしていました。その他、在籍していた7年間で、手広く色々なサービスを企画しましたね。当たればそのサービスにリソースを裂き、駄目だったら次へ行こうという形で進めていました。
結果的に幅広タイプになりましたね。
永和システムマネジメントも、会社自体はRubyやRailsといったように比較的特化型だったんですが、私自身WEB系というよりは、サーバーサイドで動いていて、そのレンダリング結果がやってくるのではなく、自分が持っている端末の上で自分のソフトウェアが動いているスタンドアローン型の技術が感覚的に好きなので、iPhoneが出たときにこれは面白いなと。当時Rails の会社だったのにiOSにはまり、初期からモバイルアプリを開発していたので、iOSの本も執筆しました。
またリクルート時代には、新規事業を作っていたので、エンジニアでもコードを書くこととは関係ない書類作成などの業務が大量にありました。その中で、フレキシブルに動けるとことが、プロダクト開発を支えると思ったので、今でもゼネラリスト志向というのは信念として持っています。
森田氏のストアカ入社後のキャリア
ストアカには、2019年1月からは業務委託スタッフとして少しづつ関わり、4月にCTOとして正式入社しました。CTOは私で3代目です。
弊社代表の藤本から直接スカウトされたのがきっかけです。最初は、明確にCTOという形ではなく、テックリードに近い形のオファーでした。実際はCTOが欲しいと思っていたのかもしれませんが、いきなりCTOというのはおかしな話なので、一回面会した後、CTOとして積極的に考えたいと言われました。
リクルートでやっていた時の地続きだと思っています。
当時は、エンジニアとプランナーが組んでやっていったのですが、「プランナーはCEOでエンジニアはCTOだよね。」という立ち位置でゼロからスタートアップするのと近い意識で取り組んでいたので、違和感はなかったです。
組織を1チーム⇒プロジェクト制へ変更
私が入社する前は、プロダクトチームが１チームでした。業務委託スタッフやデザイナー、ディレクターも含めてとなると、ワンチームで10数名と大人数で、マーケティング的な視点やCS的な観点でやりたいことが入り込んでいるという業態でした。
また、「ストアカ」はCtoCビジネスなので、当時、生徒向けの機能の方に注力していましたが、先生向けの機能も拡充していこうという動きも起きました。
そうすると、1チームで、サービスの優先順位をつけてやっていくことが難しい状況になるため、大きくテーマごとに切り分けて行うプロジェクト制を導入しました。
現在、プロジェクトは6個で、各プロジェクトには、エンジニアは1～2人くらいアサインされています。
開発グループは、私の管理になりますが、私が直接的にプロジェクト内の業務オペレーションを指示しているわけではなく、プロジェクト単位にアサインして、その中で何をやるかというのをチームとしてスクラム的に決めて進めています。
弊社ではプロジェクトリーダーを「オーナー」と呼ぶのですが、基本、オーナーは経営陣が入り込むという形になります。僕も２つのプロジェクトのオーナーをやっていますが、各経営陣、２つくらいプロジェクトのオーナーをやっています。
ただオーナーといっても経営陣なので、プロジェクトには別にリーダーという存在がいて、そのリーダーがプロジェクトを回していて、最終的に、意思決定はオーナーがやっていくという形で進めています。
はい。エンジニアリング的な設計は全てやってくれています。私自身が、直接的にここの設計はこうしなきゃとかあまり口を挟むようなことはしていないです。
とはいえ、一人で実装しきれるものでもないので、そこはメンタリングに入りながらという感じで進めています。
アジャイルな考え方でいくと、各々が視座を高く持って、やっていけるというのが理想像ですが、現在はまだなかなかそうもいかないです。
なので、実質私が全部のプロジェクトに関わっています。マネージメント的な観点を持っているディレクターがいる場合は、そのスタッフに任せています。逆にいうと、ディレクターがいないプロジェクトは私が変わってプロジェクトマネジメントをしています。
経営メンバーそれぞれで違うと思いますが、私の場合一番は、メンバーの納得性をどう理解して高めるかが重要だと思っています。
メンバーの中から「この施策は本当に効くのか。」という意見が出てきた時、納得できる説明を提示できないと、最大限にパフォーマンスも出せないと思っています。
常に納得させることはできるとは思わないですし、時間にも限りがあります。可能な範囲で、双方すり合わせをし腹落ちしてもらう、もしくは乗り気になってもらう状態まで持っていくよう努めています。
そうすることで、チームが勢いづき、開発をするうえでも良い状態になってくると思っています。
例えば、ワンマンのようにリーダーがぐいぐい引っ張ていくやり方もありますが、そのようなマネジメントは本当に限られた人しかできないと思っています。そのため私は、「メンバーの納得性をいかに高めるのか。」ということへ力を注いだ方が良いと考えています。
まだまだ変えていく必要がありますね、今の形もまだ発展途上の形です。現在の状況は過去を振り返り考えれば、それなりに落ち着いてきていますが、まだ課題もあるので、改善を重ねることでより良い形になっていくと思います。
ストアカの開発組織の今
Devopsで言うと、かなりプレーンオールドなスタイルでやっています。仮想技術など最新技術をいっぱい入れてという形ではないです。
もちろん、モダン化する要素はあるなと思うのですが、モダン化が現在の弊社にとってベストな解なのかと言われるとそうでもないというのが現状です。結構クイックに行えるようにカスタムはされているという感じなので、必要十分な状態ではあるかなと思っています。ある程度レガシー部分はありつつも、そこは受け入れてやっています。
インフラにレガシーな部分があるのと同様、アプリの方にも技術的負債あります。初期は藤本自身が書いていたというところからくるデータ設計の歪みだったり、その後入社したエンジニアの主力がインターンだったので、そこからくるコードの乱雑さなどがあります。アプリケーションやプログラミングの観点でいくと、いわゆるDRYになっていなかったり、レイヤーの組み方が複雑になっている箇所がいくらかある状況です。
その後、ある程度キャリアを積んだエンジニアが入っているので是正されている部分がありますが、それを完全に払しょくされているかというと、まだそうとも言い切れない部分があります。私としては、内部設計はこだわりたい部分ではあるので、そこは何とかしたいという思いは強いです。
あります。ただ全体感をもって今何をすべきかで言うと、弊社はまだまだビジネスグロースに注力すべきと思っています。ある程度グロースの目途が立ってくれば、技術負債に時間を割いて、効率良くやっていこうかなと思っています。
ちゃんとみんなで議論して、そういう結論付けにしています。もちろん私の意志が多く入り込んでいる要素はありますが、その意志というのは、結局経営的な判断ということになります。
でも、エンジニアに対してきちんと説明はしているので、私が見えている範囲では納得はしてもらえていると捉えています。
エンジニア組織のコミュニケーション
主にSlackを使ってのコミュニケーションを取っていますが、重視しているのはやはり直接対面で会話する1on1ですね。基本2週間に1回30分でやっています。話す内容は、ケースバイケースですが、基本的なスタンスとしては、「私の時間というよりはあなたの時間だ。」ということでメンバーが話したいことを話してもらうようなスタイルで行なっています。
話す内容は様々ですが、中には「今プロジェクトでやっているこの活動は収益貢献として意味があるのかということを議論したい。」といってくるエンジニアもいますね。その時は、事業的な観点の内容を説明し、どうやって解決すればいいんだろうねといった話をしたりします。
特に話題がない場合は、今後どうしていきたいかというキャリアの話は積極的にやってはいます。技術の話は、エンジニアの集まりみたいなのは定期的に行っているので、そこで話すようにしています。
ストアカの今後
会社の最終目標は、1兆円ほどある教育市場において、CtoCビジネス観点で20%シェアを獲得することです。また、ゆくゆくはグローバル展開も視野に入れていきたいと考えています。
CtoCビジネスの「ストアカ」を通して、誰でも先生となって教えるということをみんなが自然とやっている、そして人生100年時代だからこそ幾つになってもいつでも学び直せるという状態を世の中全体に上手く作り出したいと思っています。
あるデータで、日本人は映画館に平均年4回観に行くという統計が出ているのですが、それと同じくらいの頻度で「ストアカ」を活用して学びに行って欲しいという話をよく藤本としています。その視点に立つと我々の競合ってまさに映画という“余暇時間”を奪うような何かだったり、例えばライバルはNetflixのようなものだったりしますね。
ストアカには、人と人とが出会って、インスパイアが生まれるというのを広げていきたいというビジョンがありますが、現実的に現在ストアカの活用が活発なのは東京のような都市部が中心です。地方都市に対しては課題を感じています。
私自身も地方出身なので、地方の活性化もうまくやってきたいなと思っています。
ある地域コミュニティの中で学びたいという人がいて、一方で、教えたいという人がいて、もともとは知らなかった人々が、ストアカを通じて知り合ってそういう風にコミュニティができたり、コミュニケーションしたりする未来は素晴らしいと思っています。
まだ先の話になると思うのですが、もし本当に地方にもこういう状態が広がったら、すごく良い状態だろうなと想像しています。
