退任エントリ

シェアする

8月28日をもって、株式会社シェアダインのCTOを退任することになりました。
在任中、たくさんのご支援をいただきましたことを、この場を借りて深く感謝いたします。

本当にありがとうございました。

さて、ウェブエンジニア界隈で流行っている「退職エントリ」なるものを書いてみました。
書き終えて読み返すと「上から目線」の内容になっていて、公開するかどうか迷ったのですが、CTOとして新規事業と向き合い、考えてきたことを記録に残す意味で公開いたします。

どういう会社?

「出張つくりおき」の会社です。

「料理家さん」と呼ばれる方が自宅に来てくれて、おおむね3日分の「作り置き料理」の調理をしつつ、ご家庭の料理の悩み(子供の好き嫌い食材の克服だったり、離乳食のつくり方だったり)の相談にのってくれるサービスです。

ジャンルとしては「家事代行」と同じジャンルに属するサービスです。ただ「料理に特化」しているのが特徴です。

家事代行は近年、子育て世帯を中心に急速に普及してきており、スタートアップ企業も多いのですが、各社とも提供者(料理をつくる側)の確保に苦戦しています。
つい最近では、DMMが撤退を決めましたが、「需要がありすぎて提供者が確保できない」という撤退理由が象徴的です。

DMM.comは、スマホのアプリから頼める家事代行サービス「DMM Okan(DMM おかん)」を、2018年9月30日で終了する。その理由はサー...

私の参画したサービスは、この展開は当初から予想して、後発からの逆転を狙っています。

「料理に特化」することで、提供者の獲得に関して、まったく別の戦略を考えているからです。
この場で詳細は割愛しますが、現在のところ、目論見どおりに進んでいます。

私の立場

「PMF(Product Market Fit)がもうすぐ見えそうだ」というタイミングでお話をいただきました。

そこからCTOとして、自社エンジニアチームの採用・組織化、プロダクトのアプリへの落とし込み、グロースハックの基盤づくりまで、幅広く推進してきました。

ここでは、私の得意分野「エンジニアチームの組織化」「アプリ開発(プロダクトのアプリ化)」「グロースハック」の3分野に分けて、振り返ります。

エンジニアチームの組織化

エンジニアチームをつくるとき、よく見落としがちなのが、エンジニアの「セグメント」です。
「セグメント」と言うと、「サーバサイドもフロントエンドも一通りわかって経験3年くらいの方と、あとは若手をもう1名・・・」というような話を聞きますが、これは「採用条件」で、私の言う「セグメント」とは異なります。

私は今回、以下の「セグメント」を定義しました。

「(わが社のサービスに関連した)非エンジニア職で社会人経験があり、エンジニアへの職種転換を目指してプログラミングスクール卒業直後、最初の実務経験を積む場を探している方」

「採用条件」と「セグメント」の最大の違いは「成長志向性」の有無です。

スタートアップでは、会社はもちろん、仕事をする人間も成長志向であるべきです。
「セグメント」は「どんなキャリアを目指している方が」「どういう実力の段階で」この仕事に関与してもらうかを明示しています。

逆に言うと「採用条件」では、この仕事を通して、その方がどう成長するか(できるか)が曖昧なままです。
曖昧なまま(もしくは「目の前の仕事を頑張れば成長できる」などと精神論で誤魔化して)採用しても、出入りの激しい組織が出来上がるだけです。

セグメントに基づきシステムインフラを設計

採用するエンジニアの「セグメント」が決まったら、それに基づいてシステムインフラを設計します。

・・・と言うと、多くの方は違和感を覚えるでしょう。

教科書的にいうと、システムインフラは、システムの機能や負荷予測を基に設計するものです。
「採用するエンジニアにあわせてインフラを設計する」というのは「暴論」といっていいでしょう。

教科書的な考え方は否定しません。

しかし、新規事業のアクセス量をさばく程度であれば、これだけサーバの性能がよくなり、クラウドで手軽にサーバ調達できる現在、まったく難しくありません。
どんなインフラでも、たいていちゃんと動きます。

となると、新規事業インフラは、「インフラの魅力をアピールしてワンランク良い人を採用する」前提で、自社の採用したいエンジニアのセグメントにあわせて構築したほうが、むしろ投資対効果がよくなります。

私の参画したサービスでは「プログラミングスクール卒業直後、最初の実務経験を積む場を探している方」をターゲットにしました。

そのため「初心者がいじっても事故が少なく、怖がらずに操作できる」ことを目指して構築しました。

細かな工夫(種)はたくさんあるので割愛しますが、大きな特徴は以下の通りです。

エンジニアの「関心ごと」をRuby on Railsレベルに集約

よくいじりそうな部分はRuby on Railsの管轄にし、逆に、いじらない(変にいじってほしくない)部分は構成管理ツール(Ansible、AWS CloudFormation)の管轄にまとめました。

これにより、Ruby on Railsさえわかれば日常業務がまわるようになり、学習コストが大きく下がりました。

また、Ruby on Rails以外の部分をいじるときも、構成管理ツールにより、いつでも元に戻せるので、いじりやすくなりました。

多少問題があってもインフラが吸収

本番環境にはPaaS(AWS Beanstalk)を全面採用しました。
社内システム、業務、体制は、すべて、PaaSの利用を前提に設計しました。

これにより、多少問題のあるコードが書かれてもシステムインフラが吸収してくれるため、リリース可否の判断を初心者エンジニアにまかせ、じゃんじゃんリリースできる制度にしました。

副次的に、障害時のサーバ再起動や、脆弱性パッチ適用が自動化され、夜間休日のエンジニア待機体制を組まずに十分運用できる状態になりました。

閑話休題

聞くところによると、私の後任体制は、フルタイムで参画するのは初心者(経験半年)のエンジニアだけで、経験者のエンジニアは非常勤だそうです。

エンジニアの経験者なら「そんな体制でシステム運用まわりますか?」と心配になりますが、上記のインフラができているので、無謀な挑戦ではないと私は思います。

今後のメンバーの頑張りに期待します!

プロダクトのアプリ化

「プロダクト」とは、必ずしも「アプリ」とは限りません。

私が参画したサービスで「プロダクト」といえば「料理家さんが自宅に来て、作り置き料理を調理してくれる(+料理の悩みの相談に乗ってくれる)」ことです。

このプロダクトをアプリ化しました。

アプリ化の最大のハードルは「マッチング」の仕組みでした。

時間、訪問場所、料金、相談したい料理の悩み・・・などの諸条件から、料理家さんと利用者さんをマッチングする仕組みです。

PMF(Product Market Fit)を確認する段階ではチャット(Facebookグループ)でマッチングが行われていました。

チャットのままだとスケールしないので、システム化を見据えたマッチングプロセスの標準化、拡大期(グロースハック)を見据えたユーザー流入経路の設計から始まり、ワイヤーフレームの作成、アプリの要件定義、システム設計・・・というプロセスで、マッチングアプリを完成させました。

コンシューマー向けのシステムを設計するとき、私はまず「アハ!ポイント」に注目します。

「アハ!ポイント」とは「アハ!体験」をするポイントのことで、すべての施策は、この体験の最大化が目的になります。

(サービスが成長し、収益化ステージに達したら「収益の最大化」が施策の目的になりますが、当時のステージでは「アハ!体験」のほうが重要でした。)

このサービスの「アハ!ポイント」は「料理家さんが調理してくれた料理」または「料理家さんに料理の悩みを相談した体験」です。

一般的な家事代行サービスの「アハ!ポイント」とは少し異なりますが、この「違い」こそが差別化要因です。

つまり、料理家さんが「これまでにない」3時間の顧客感動満足をつくれるかが、このサービスの成否を握っています。

「これまでにない」顧客感動満足をつくるためには、サービス提供の「マニュアル」や「研修」はもちろん、(結局、書類や座学では不十分ですから)料理家さん同士の「横のつながり」をしっかり構築し、お互いに自身のサービスを「高めあう」仕組みをつくれるかが鍵になります。

そのため、CTOとして最も力をいれるべきことは、実は、料理家さん同士の「横のつながりをつくる」仕組みづくりでした。

逆に、ユーザーが使うメインのアプリ(マッチングシステム)は、アハ!ポイントに向けた「前座」に過ぎないので、独自性を出す必要はなく「他社と比べて遜色のないレベルで十分」と私は考えていました。

エンジニアの採用に関して「プログラミングスクール卒業直後、最初の実務経験を積む場」というセグメント設定にしたのも、上記の考えからです。

「他社と比べて遜色のないレベルで十分」という前提が決まったので、アプリの要件定義、システム設計は、「初心者エンジニアがいじりやすい」ことを第一に考え、教科書に載っているような典型的な設計にしました。
また、エンジニアの大量動員が必要な初期開発フェーズは、躊躇なく外注を選択しました。

グロースハック

もともと私は、月間17億PVの情報サイト(食べログ)の運営に携わっていました。
アプリ開発部門(エンジニア職)から始まり、システムインフラ、個人課金のグロースハック(企画職)のトップを務めてきました。

システムインフラからグロースハックまで、幅広い視点からサービス設計をするのが得意分野です。

オウンドメディア、SNSシェア促進、SEO対策、広告・・・拡大期に実施する流入施策を予想して、スムーズに施策がすすむよう、立ち上げ期のサービス設計をいくつもの「種」を撒いてきました。

「種」の開花を見届けずに会社を去ることになったのは残念ですが、順次、花を開かせることでしょう。

在任中に開花した数少ない「種」の1つが「オウンドメディア」との連携です。

着任早々、サービスの全体像を設計する前からwordpressでメディアを立ち上げ、被リンクを集め、あとからできたRuby on Railsのマッチングシステムと「合体」させる策をとりました。
・・・と書くと簡単そうに見えますが、同じドメイン上に「wordpress」と「Ruby on Rails」を共存させるのは、インフラエンジニアの協力がないと難しい要件です。

逆に、やらなかった施策もあります。
ABテスト、ABテストに基づくUI/UXの改善は、まったくやりませんでした。

ユーザーが使うメインのアプリ(マッチングシステム)は「前座」に過ぎず、前座を細かく改善したところで事業全体への改善効果は小さいと判断し、他の案件を優先しました。

ただ、この判断が一部のステークホルダーに非常に不評で、今回の退任劇の一因になったようです。

もともと「グロースハック」という言葉に明確な定義はありません。

「グロースハック」=「ABテストを繰り返してUI/UX改善」というイメージの方からすると「ABテストすらやらない」=「グロースハッカーとしての能力もやる気も感じられない」という印象をいだかれたのかもしれません。

これは今後、同じような仕事を受ける際の改善ポイントです。

今後に関して

CTOは比較できません。
例えば、AさんとBさんと、2人のCTO候補のどちらを採用するか悩んだとして、CTOを2人おいてパフォーマンスを比較することはできません。

私の得意分野は、「エンジニア組織化」「アプリ開発」「グロースハック」の各分野の経験があり、その総合力でサービスやアプリの設計をすることです。

ただ設計時に撒いた「種」の開花には時間がかかり、すぐに成果が見えないこともあります。

一方で「エンジニア組織化」「アプリ開発」「グロースハック」の各分野を、それぞれ別の専門家に依頼した場合、単純に3人で仕事を分担することになるため、短期的には進捗がよく見えます。
(人件費3倍+コミュニケーションコスト+バラバラの設計によるムダの増など、長期的にみると、いろいろ追加費用はかかりますが。)

結局は「スピードをとるか」「低コストをとるか」というトレードオフの経営判断です。

ただ、CTOを採用する時点で、経営者や投資家の方に、ここまでの先読み判断を要求するのは難しく、いきおい採用してから「そんなつもりはなかった」という展開になりがちです。

根本的には、自分で事業をつくり、その成功をもって具体的な価値を提示するのが一番だと感じています。

以上の背景から、現在、スマホアプリ開発の分野での事業化を目指して、技術開発・調査を進めております。
詳細をお話できる状態になりましたら発表いたします。

この記事を書いた人

渡辺直木(Naoki Watanabe)

1980年生まれ、一橋大学卒。リーマンショックを機に経営コンサルタントからウェブエンジニアに職種転換。

株式会社カカクコムにて、月間17億PVの情報サイト(食べログ)に参画し、アプリ開発部門、システムインフラ部門、個人課金事業部門のトップを歴任。

スタートアップ企業の職業CTOとして独立し、株式会社CSS-Consulting、株式会社シェアダインの立ち上げに参画。