スタートアップ界隈のCTOの現場のお話が聞ける、CTO呼んでしゃべらNightに参加してきたメモ

スタートアップ界隈でCTOをやっている方々がお話をするCTO呼んでしゃべらNight 〜ここでしか聞けないスタートアップのサービス開発現場のリアル〜に参加してきたので、そのまとめです。

シードスタートアップ各社CTOによるパネルディスカッション

パネラーの皆様について

• SmartHR　取締役副社長・CPO（最高プロダクト責任者）　内藤研介 氏
  • 飲み友達と3名で企業した
    • デザイナー、エンジニア、社長といった構成
    • お互いインターネットやwebの文化が好きだったので自分たちでサービスを作りたいとなった
  • 最初のアイデアから同じアイデアで進めたわけじゃなく、何回かは初回のアイデアから変えていった
  • 作るときは少人数だったのでなんども話し合いながらやっていた
  • サービスを潰す判断はみんなで話して決めていたが、ボーダーラインを決めておいたほうが良かった
  • 今まで2個のサービスが世に出して、3個めがスマートHRになる
  • 今までは自分たちが作りたいものをつくっていたが、スマートHRはユーザが欲しいものから作った
  • ユーザヒアリングや周りの友達などのインタビューを通じてアイデアを抽出した
  • スマートHRの強みは社風に合う人をとってるので、いい人が多い
• ワンファイナンシャル株式会社　CTO　丹俊貴 氏
  • ワンというレシートを10円で買取るサービスを立ち上げたが、大量に買い取りが来たため、キャッシュ的事情で一度ストップした
  • 17歳の起業家とジョインした理由としては、カフェで若い子が起業しているということで会ってみたが、前に見かけたことがあり、そこから話すようになり、誘われるようになった
  • CEOは若いが、話すと普通の高校生じゃないというところがあり、不安要素はそんなに感じていない。
  • ワンファイナンシャルの風土はシンプルにする。ワンのプロダクトもDLしてから買い取る体験まで30秒でできる。
    • UI/UXもどうやったら気持ちいいプロダクトになるかを追求している
• 株式会社hokan　CTO　横塚出 氏
  • 一人で受託案件をしているのが寂しくなっていたところに、高校の後輩であるhokanのCEOに声をかけてもらってジョインした
  • hokanの強みは、エンジニアがよく喋って、biz側とも意見を交わしている
• Quantstamp　Forward Deployed Engineer　岡洋平 氏
  • ブロックチェーンのイベントで知り合ったメンバーがきっかけでジョインした
  • 主に日本展開を担当
  • 学問をいかにスマートコントラクトにつなげるのかを行っている
  • Quantstampの強みは、PHDを持っていて、アカデミアに強いエンジニアもいて、グローバルに戦える俊敏さを備えている

プロダクト開発について

こうしたらよかったこと

• いくつかピボットしていて、自分たちの作りたいものをつくるのがまずっていた。ユーザありきで作らないといけない（内藤氏）
  • ちなみに最初のサービスはユーザが質問に答えるとその人のスキルが視覚化されるというサービスだったが、なぜユーザがスキル登録するのかというのが詰められてなった
  • UI/UXは作る際はどうしてるか？
    • 新しい機能を開発にするにしてもユーザの課題を考えているようにしている
  • スマートHRは新しいのをとりいれているか？
    • 時間がなかったので、使い慣れた枯れた技術を使っている
    • 新規プロダクトに関しては新しいチャレンジをしている
• ペイメントのサービスが失敗した。裏側がクレジットカードの決済を他社のサービスに載せていたが、自分たちでコントロールできないところが多くてビジネス上進めることができなかった。また、不正が多すぎてグローバルからみても不正が多いといわれて、サービスをクローズした(丹氏)
  • サービス自体は４ヶ月位稼働させていた
  • 問題は作り込みとコントロール出来ないところだった。
  • 決済を自分たちで作るのは大変なので事業領域を変えるべきだった
• 4月の頭にベータ版を出したが、ユーザとの乖離があったので、開発途中でもユーザにヒアリングするのは大事だと感じた。（横塚氏）
  • 技術的な部分ではプロトタイプ時点では裏のDBをgraph dbを使ったりしていたが、本リリースにはスタンダードな作りに変えた
• チャレンジの点としては、ICOに投資してくれた期待値のコントロールが難しかった（岡）
  • どんだけ自分たちが頑張ってもいつリリースされるのかと投資家に突っ込まれたりする
  • 自分たちのサービスのニーズを確かめながらやっている
  • Ethereumの技術に依存しているのでトランザクション処理が早くならないと大きくなりにくい

組織について

CEOとうまくいっているか

• CEOのコミュニケーションは問題ない。ユーザの意見の取り入れ方は、リリース前は想定ユーザを仮定して話を聞きに行く。リリース後はユーザに直接聞く。日々サポートチームがユーザの不満などをとりいれる。また、営業チームが営業して意見をとりいれている。（内藤氏）
  • 挙げられた課題が普遍的な課題かどうかを意識している
  • どこからやるようにしているのか？
    • 普遍的な課題であるか、サービスが解決すべき課題なのかを意識している
    • サービスの領域を拡張するかどうかという議論もある
  • 議論を大切にしているので、リーダー陣が集まってやっている
• ユーザーインタビューは全くやっていない。プロダクトリリース前の仮設は自分たちでやって、出してしまってから考えている（丹氏）
  • ワン自体は使う世代は20-30代が多い
  • 学生主婦にはささるとはおもっていた
• CEOのコミュニケーションギャップはない(横塚氏)
  • いちばん大事なのはユーザの声
  • 保険業界の知識はメンバー全員にインプットする機会を設けている
  • それ以降の仮設は民主主義な形でやっている
• 今はお客の声を使ってどうやったプロジェクトやサービスが必要かを考えている（岡氏）
  • スマコンデプロイしたあとの保守など、次開発するものを考えながらやっている
  • 世界中にクライアントがいる。アジアのプロジェクトのやり取りや対応の仕方などは難しいものがある

エンジニア採用方法はどうしているか？

• 採用までは手が回っていない。ブロックチェーンをやっているエンジニアももともと少ないので苦戦している（岡氏）
  • 優秀な人はその人専用のポジションを作る
  • ポジションにあわせるというよりは採用してから考えている
• 人がたりてなくて、社内の知り合いのエンジニアに声をかけたりしている（横塚氏）
• 採用をする気はまだない。もしするならリファラルベースで考えている（丹氏）
• 会社の内情をオープンにアピールしたら応募がとれるようになった（内藤氏）
  • 社内イベントやカンファレンスにスポンサーとして出たりしたが、内情オープンしてとれるようになってきた
  • 育成はこれからの課題。採用は即戦力が多い

グロースステージスタートアップ各社CTOによるパネルディスカッション

パネラーの皆様について

• dely株式会社　CTO/執行役員　大竹雅登 氏
  • 2014年のdely創業から参画している
  • kurashiruは3つ目のプロダクトでヒットした
  • CEOが大学の同級生で、駅が近く、あったら面白そうだったのでジョインした
  • 現在はデザインに力をいれようとしている
• FOLIO　CTO　椎野孝弘 氏
  • ファウンダーのメンバーがyahooにいて当時、その部下だった。
  • イノベーティブなチャレンジをしたくてジョインした
  • 組織ビルドを主にやっている
• FlyData　プロダクトマネージャー　金本祥平 氏
  • シリコンバレーに本社がある会社で、RDBからredshiftにデータをコピーするソフトを売っている
  • 日本の大企業ではデータが整っていなかったりするのでそのコンサルなどをしたり、AIなどのプロダクトを作ろうとしている

プロダクト開発について

構成は何人くらいか？

• エンジニア14人、デザイナー2人（大竹）
• エンジニア40数名、デザイナー5,6人、ディレクター（エンジニア兼務だったりする）としてはwebフロント5,6人バックが18人、モバイルが7名（椎野）
• 10人ほどがエンジニア、一人デザイナー。社長がエンジニアトップなので、会社の技術方向を決めている（金本）

開発フローはどうしてるか？

• アジャイルのSCRMでやっている（椎野）
• 担保すべきところが非常に多いので、QAの期間が一般的な開発よりも長く撮っている
• 2週間は開発して、3週間目をQA期間としてやってからリリースしている

QAや仮説検証をやっているか？

• QAレベルはやっていない。consumer向けのサービスなので、ITに得意じゃなくても使ってもらえるように、使いやすいインターフェースを徹底している。（大竹氏）
  • 開発フローをデザインと実装の2つにわけている
  • デザインフェーズはなにか解決したい課題時、そのプロトタイプを作って、社内にいるユーザになりえるひとに試してもらって、録画しながらチェックしている
  • プロトタイプを2~3周回して不確実性を減らしてから実装フェーズにしていて、リリース時のリスクを減らしている
  • 仮説検証はデザイナーがやっており、デザイナーは横断的に統合してすべてのフェーズでみるべきだと思っている。
  • どうやってテストユーザを集めているか？
    • 社内にユーザになりうる人がいるならその人たちにやらせるが、bosyuを使ってテストユーザ募集したりしている
• UI/UXはこだわりは持っていて、一般のユーザにどういうサービスを提供するのがベストになるかを考えながら、金融として認められる文言や挙動かと、両方を仮説検証する必要がある(椎野氏)
  • あとから発覚することもあったりする
  • 事前にコンプライアンス舞台にモックアップをみせて、問題がないかをチェックしてもらい、場合によっては社内の一般ユーザを募ったり、外からよんで見てもらったりする。
• 第一弾は5年くらいやっているプロダクトなので、新規機能もなく、使ってもらっている担当者がエンジニアなので、そんなに仮説検証はしない（金本氏）
  • QAはバグチェックはテストコードでテストが通るかどうかでリリースを決めている
  • AIの製品は市場に受け入れられているかを仮説検証を行っている
  • モックやプロトタイプを見せたり、プレゼンしたりして様子をみている
  • テストユーザはPOCという仮説検証フェーズをやってからリリースしようとお客とやっている
    • お客が慎重な客なら2~3ヶ月など長期に検証フェーズを持っている

技術的負債解消はなにか取り組んでいるか？

• マイクロサービスをアーキテクチャに採用しているが、立ち上げ時と今とで粒度が違う（椎野氏）
  • 証券取引のシステムを理解してからスタートしなかったため、マイクロサービスがどんどん多くなった
  • これからはマイクロサービスによっては、ドメインを最適化して分けていこうとしている
  • 技術的にレガシーになる部分については、マイクロサービスのオーナーシップを持っている人が独自で負債を返していけばいいと思っている。
    • 役割の分担が同じアーキテクチャじゃないと解決できなくなってるので、アプリエンジニアがやりやすいように変えるよう考えている
• デザイン的負債を提案したい（大竹氏）
  • 2年前のアプリを今のアプリと比較するとダサく感じるようが、作ってる人はそのダサさに気づかない
  • 画面遷移のヌルヌル感があまり再現できていない
  • うまくできてないとユーザはなんか使いにくいと感じてしまう
  • 意識的に最新のデザインを取り入れるようにしています

組織について

CEOとのやりとりはどうか？

• 技術のことがわかってもらえないという対立はないが、CEOがアメリカにいるので時差に困っている（金本氏）
  • プロダクトの意思決定は一任してもらっていて、報告をテレビ会議でやっている
  • slackで方向修正入りそうだったら、こまめに報告を入れながら話している
• CEOはエンジニアに強いリスペクトがある。見ている方向はだいたい同じ。（椎野氏）
  • 非常にフランクな方なので、突然隣りに座ってカレーを食べながら〜やりましょうよと突然提案してきたりするくらいのフランクさ。
• CEOは破天荒な感じだが、結構任せてもらえている（大竹氏）
  • 正しい意思決定をするのが仕事と思っているので、意思決定をしやすいようにドキュメントを渡したり整理するのが必要と思っている。
  • Opinionとパーソナリティを結び付けないようにしている

カルチャー作りでしていることや、チームビルディングで意識していることはあるか？

• カルチャー作りとして、仕事と関係ないことをやるということをしている（大竹氏）
  • 信頼して働けるかというのも重視している
• 直接対面してコミュニケーションが難しいので、ビデオチャットをなるべく使うようにしている（金本氏）

今後のビジョンについて

• kurashiruは今後食品のECのトップシェアをとる。売上1兆円を目指す（大竹氏）
  • 自分自身もバリューを出すようにしたい
• 3年後にバリエーションとして3000億の価値をだせる会社になりたいと思っている。（椎野氏）
  • 金融周辺の情報もアップデートした上で金融に慣れ親しんだサービスを出して、イノベーティブなものを提供したい
  • 役割としては、組織の拡大により、職務を権限委譲していくが、役割がどんどんかわっていくので、今の役割は全て委譲して、次のステップの役割をどんどんやっていく
• すべての会社がデータドリブンを気軽に作りたいというビジョンがある。（金本氏）
  • AIエンジニアやデータサイエンティストと相性がいいので、成長してお客にとって効率的な助けができればと思っている
  • 社長がエンジニアだったので権限委譲をしてきた。同じように役割の変化に合わせて権限委譲をやったり働きかたを整えるのをやっていきたい。

@mogmetの所感)

サービスを当てるまでには何個かリリースしてるのが印象的でした。
一発であてるというのはなかなか難しいのを感じました。

また、ユーザベースで必要なものを考えると当たりやすいというのも感じました。