「CTO＋未経験エンジニア3名＋PdM」が約半年で3サービスをリリース　SHE・CTOが語る、“迷いのない爆速開発”を叶えた技術的工夫

半年でリリースした3つのサービスの概要

横江亮佑氏（以下、横江）：今回のテーマでもある、「SHEで3つのサービスを半年でリリースした」という話なんですけど、SHEでいったいどんなサービスをリリースしたんですか？

村下瑛氏（以下、村下）：ありがとうございます。背景として、僕らの事業はいろいろ試行錯誤しながらではあるので、今の方針と当時の方針がぜんぜん違う部分があります。

当時は、キャリア支援の「SHElikes」というサービスがすごくうまくいったタイミングで、そこを違う領域に広げていけないかみたいなところ（を考えていて）。当時は「オールライフ」みたいなことを言っていて、「自分らしさってキャリアだけじゃないというところで、全領域に広げていきましょう」というような話をしていました。

なので、キャリアとかビューティとかファイナンスとか、いろいろな領域でSHEのモデルに需要があるかをクイックに調べたいところがあって、その領域で3つぐらいサービスをリリースしています。

村下：1つが「マルチクリエイターコースデザイナー」というサービス。デザインに特化して短期集中で深めていく4ヶ月のコースで、かつ、コーチの方が1on1でついてサポートしてくれるようなサービスをリリースしました。

村下：次は「SHEbeauty」という美容領域に特化したサービスをリリースしました。「今はけっこう美がステレオタイプ化しているんじゃないか」みたいなところを仮説として立てて、もう少し自分らしい見た目を定義して、そこに対してのHowを提供していくサービスに需要があるんじゃないかと考えました。コーチングをしながら理想の自分に向かって、メイクやボディ、マインドを学んでいくようなサービスです。

横江：すごいっすね。学習というところからだいぶ変わってきましたね。

村下：そうですね。

村下：最後が「SHEmoney」で、自分らしい人生を実現するための「マネー・ファイナンススクール」です。お金（について）はあまり語られてこなかったけれど、実は自分らしい人生の土台になるものだし、自分のライフプランとセットで資産運用とか計画を立てていくべきだというところで、目標設定から資産運用のプラクティスまでを学べるようなサービスをリリースしています。

横江：へぇ～、どれもおもしろそうじゃないすか。すごいっすね。短期集中型コースと、それから美容を学ぶっていう。そして、お金。ここ大事ですよね、やはり資産運用とかはけっこう大事です。

なぜ半年で3つもサービスをリリースすることになったのか

横江：3つともけっこう大きなプロダクトだと思うんですけど、これを本当に半年でリリースしちゃったんですか？

村下：そうですね。正確に言うと、けっこう共通の機能も多いんです。サービスとしては完全にスクラッチで書いているんですが、コース受講やコーチングの仕組みとか共通のところもあるという前提ではあります。

独自の機能もけっこうあって、moneyでいうと家計簿アプリみたいなものがあったり、beautyでいうと自分の美容をトラッキングする仕組みがあったり。特化した機能もあって、それは一応半年で終えた感じです。

横江：すごいっすね。企画もすごいっすね、なんか（笑）。半年で、「こういうふうに作ろう」という企画がちゃんと走ったのもすごいですし、それを開発したのもすごいですね。

村下：そうですね。うちの会社は「これだ」ってなったら、けっこう勢いを持って進めるカルチャーではあります。

横江：どうやったらそんなことができたんですか？　すごいっすね、なんか。ちょっとぼんやりと聞いちゃうけれど、まずなんで半年で3つもリリースすることになったんですか。すごいですよね。

村下：半年というのはそんなにアレなんですけど、できる限り早く検証したいというのが大きくて。「オールライフで需要があるのか」とか、「リクルート的な全領域に人生を軸に広げていく方向で我々は本当にいいんだっけ」というのが、当時仮説としては持っていたんだけれども、やはりわからないところはあって。

キャリアに特化していくのか、そこを広げていく方向性なのかを早く決めたいというのがやはり大きかったかなと思っています。だから、半年かどうかはアレなんですが、とにかく早く検証して、1年で検証しきりたいみたいなところはやはりありました。

なので、半年ぐらいでサービスをリリースして、残り半年で検証というか。実際にユーザーに使ってもらいながら意思決定をしたいというところが、一番大きかったかなと思っています。

横江：なるほど。最初から半年と決まっていたわけではないんですね。「開発期間は半年だよ」と決まっていたわけではないんですか？

村下：「できる限り早く」みたいなところで、交渉しながら半年ぐらいと決めた感じですね。

横江：でも、共通の機能があったというところも、ちゃんと半年でできた理由の1つなんでしょうね。最初から作りがわりと良くて、使い回せるような作りになっていたところも、けっこう大きな点なのかなと感じました。

村下：そうですね。それはけっこうあるかなとは思います。

当時の組織体制はCTO＋未経験エンジニア3名＋PdMの計5名

横江：すごいっすね。当時、エンジニアとかデザイナーの組織体制はどうなっていたんですか？

村下：（スライドを示して）当時の体制はこんな感じでしたね。

横江：さっぱりしている（笑）。

村下：今よりだいぶシンプルです。僕がCTOをやっていて、エンジニアが3名で。この子たちは全員未経験だったんですよね。

横江：全員未経験なんですね。

村下：PdMが1名という感じ。開発の進め方としては、未経験でも迷わず開発ができるような進行をけっこう意識する必要があったかな。

横江：なるほど。すごいっすね。よくこの状態でやれると思いましたね。先ほど「交渉した」という話もありましたけど。

村下：副業でスタートアップのリードエンジニアとかをやっていると、カオス耐性みたいなものが身につくんですよ。

横江：カオス耐性が（笑）。

村下：そうですね。SHElikes自身も3ヶ月ぐらいでリリースしていたりはするので、僕的にはけっこういけるかなという感覚はありつつ。

横江：もともとのSHElikesも3ヶ月でリリースしているんですね。すごいな。なるほど。じゃあそれで「いけるかな」みたいな気持ちはあったんですね。

村下：うん。

「迷いのない爆速開発」をするための技術面の工夫

横江：先ほども「未経験の人が少ない中でも全員がやれるように」という話がありましたが、組織の技術面での工夫とかはあったんですか？

村下：技術面での工夫の1つは、マイクロサービス化とか。基本、顧客基盤が共通なので、マイクロサービス化とかのあたりをガシガシ進める必要はあって。そのあたりはけっこう僕が巻き取っていく感じだったんですけど。

それ以外の機能開発でいうと、やはりGraphQLの採用が大きかったかな。そこがプロトコルのHowを超えて、開発にいい影響を持っていたのかなとは思っています。

次のスライドにいってもらってもいいですか。

村下：一応「迷いのない爆速開発」みたいな感じで書いているんですけれど。

横江：すごい。かっこいい（笑）。

村下：やはりドキュメンテーションとしての役割みたいなところがかなり大きくて。GraphQLでスキーマを落としていくと、だいたいの仕様の認識を合わせられるというところが1つ目です。ここがかなりジュニアと一緒に進めていく上では大きかったかなと思っています。

村下：プランニングをする前に、僕が中心になってだいたいのGraphQLのスキーマ定義とかを一緒に決めていく。で、だいたいどういうエッジケースがあるかみたいなことをスキーマとして書き起こしていった。

横江：先にそっちなんですね。

村下：（スライドを示して）これを見てもらうと、ドメイン知識がない方でもわりとわかりやすいんじゃないかなと思っています。応募をsubmitするという操作があって。エッジケースとして、成功した場合と失敗した場合で、リクエストがそもそも無効な場合と、応募がすでにされているようなエッジケースがあることは（このコードで）わかるじゃないですか。

これがわかっていると、「フロントエンドはこういうエッジケースに対応する必要があるのね」みたいなことであったり、「バックエンドはここの仕様を満たして実装すればよい」ということがわかる。こういうところで、かなり分担がしやすくなった印象があります。

あとは型安全なのがやはり大きいかなと思っています。「基本的にこの型に則っていれば壊れない」というところと、あとはスピードというところで、エコシステムが充実しているので、クライアントとかをほとんど書く必要がありませんでした。

スキーマを定義して、自動生成して、あとは実装を埋めていくみたいな感じで。けっこうガシガシ進めていくことができたかなと思います。

サーバーサイドとフロントエンドそれぞれの開発環境

横江：SHEさんって、サーバーサイドとフロントエンドはそれぞれ何で開発しているんでしたっけ？

村下：フロントはReactですね。最近はNext.jsを使うことが多くて。サーバーサイドはRuby on Railsを使いつつ、最近の新規サービスはTypeScriptが使われることが多いです。

横江：Rubyだと型はないですが、それでもGraphQLの強みは活かせたんですか？

村下：そうですね。動作チェックの観点で、型が間違っていたらエラーが出るので、ユニットテストとかも書きやすい印象はありますね。でも確かに、GraphQLをガシガシ書いていくと、やはりTypeScriptのほうが書きやすいなというのはメッチャ（思うので）、最近はけっこうTypeScriptを使いがちではあります。

横江：いいですね。もうNext.jsだけで終わるという世界観。すごく楽だと思うし（笑）。

村下：そうそう。TypeScriptだけに統一すると、学習コストがけっこう低い印象もあったりしますね。

横江：ですね。しかも型も定義されていて、なおさらGraphQLの強みが出ていくというところで。すごくいいですね。

新しい技術の導入をどのように決めているか

横江：もともと前職とかでGraphQLを使っていたんですか？

村下：いや、ここから初めて導入した感じですね。

横江：検証とかはどうしたんですか？　今まで使ったことがない技術を使うのって、けっこう抵抗もあるじゃないですか。

村下：そこはSHEのお箱なんですけど、エキスパートの人を呼んできて、まずPoCを作ることをけっこうよくやるんですよ。GraphQLを他社で書いている人を呼んできて、同じ機能をRESTで作るのとGraphQLで作るのとで、どう違うかみたいなのを1回チームメンバーも含めてプレゼンしてもらいます。メンバーの肌感を踏まえてでどっちがいいかを決めるというのをやりましたね。

横江：すごいですね。それは確かに良さそうな方法ですね。

村下：僕が全部決めるのはけっこう大変だったり、そこで最適でないことも多いので、副業でもいいからエキスパートを呼ぶようなことは意識しているかもしれないです。

横江：とはいえ、そのエキスパートの人をどうやって見つけてくるんですか？

村下：それはアレですね。Twitterとかですごそうな人に声をかけるみたいな感じですね（笑）。

横江：すごい。思った以上に地道な努力の末なんですね。

村下：そうですね。

横江：「GraphQLの記事を書いているな、この人」みたいなところから声をかけていくんですか。

村下：そうですね。

横江：なるほど。おもしろいですね。そういう技術選定の方法もあるんですね。

村下：けっこうやりますね。GraphQLはその先に「Fragment Colocationをどうするか」とか、あとGraphQL Gatewayはその周辺にけっこういろいろテクニックがあるんですが、それも1回PoCを作って、メンバーのフィードバックを得てみたいなところで、わりと小さく試すのはよくやっています。

横江：このGraphQLの導入が、スピーディな開発につながっていったと。

村下：と思っていますね。今も全社的にGraphQLにはベットしていて。僕的にGraphQLはけっこうラブですね。

横江：おおー、すばらしいですね。私、GraphQLの良さって、エンドポイントが1つだけだから、毎回開発工数がそんなにかからないみたいなところだと思っていたんですが、こういう利点があったんですね。

村下：そうですね。

GraphQLの魅力

村下：（視聴者に向けて）ちなみにGraphQLを使ったことがある方はいます？

横江：確かに。GraphQLを使ったことがある方は手を。お！

村下：けっこういますね。

横江：思いのほか、多いっすね（笑）。すごいな。エンジニアは8名ぐらいしかいなかったのに、けっこういましたね。すごいな。ありがとうございます。

村下：すごい。みんなどのあたりを利点と感じて、（その）技術選定をしているのかすごく気になるんですけど。僕らとして（感じていた魅力）は、当時は型が定義されていた、見て簡潔に仕様を理解できるところと、型安全に開発ができるところの2つだったんですけど。最近はクライアントが取る情報を選べるところも、けっこう魅力だなと思うようになりました。

APIとかを使い続けていると、「このフィールドは本当に必要なのか？」みたいなのがあって。よくわからないフィールドとかがけっこう増えてきたりするじゃないですか。不要なデータをメッチャ取得していて、すごく重いのも然り。

それが最近はFragment Colocationとかを使うと、クライアントがちゃんと必要十分なデータだけを取れるようになるので、すごく効率がいいよねみたいなところもけっこう魅力だなと思っています。

横江：なるほど。おもしろいな。GraphQLの魅力って、むしろ今話したクライアント側の話だと思っていたから、そっか。けっこう勉強になりました。うちの会社でも使ってみたいなと思いつつ、今あるプロダクトのAPIを移植していくのが大変で、なかなか踏ん切りがつかない感じですかね。

村下：確かにね。それでいうと、僕らも100パーセント移行できているわけではないんですけれど。

横江：今は両方使っているんですね。

村下：徐々に移行を進めている感じです。新規開発は全部GraphQLに寄せて、既存のものも徐々にという感じでやっていますね。

横江：そうですよね。昔のものだと、けっこう複雑な呼び出し方をしているAPIとかが存在しますからね。昔からちゃんと用途ごとに分けていればよかったんですが、なかなかそうはなっていない場合は大変ですかね。（視聴者の）みなさんの思うGraphQLの利点は、ぜひコメント欄に。

村下：あとアンチGraphQLの人も気になる。

横江：アンチGraphQL（笑）。いるんですかね、アンチGraphQL派。

村下：「RESTだろ」「オープンAPIだろ」みたいな人も中にはいるかもしれないので。

横江：オープンAPI派がいてもおかしくはないけど、REST派ってなかなかめずらしい気もするな。ぜひぜひチャット欄に残してください。GraphQLの話をして、技術の話はそこらへんかな。

（次回に続く）