スタートアップのCTOを1年やって思うこと
とあるスタートアップのCTOをはじめてそろそろ1年たちました。
半年前は鬼滅にはまっていたのですが、呪術廻戦にはまってます。オープニングの曲が大好きです。
半年からのアップデートをふまえて書いてみたいと思います。
ビジネスをスケールさせるうえで技術選定はやはり重要
スタートアップのビジネスは激しく動いていきます。そのうえでどうゆう土台にアプリケーションをのせているのか、というのはとても重要になります。一年前に用意したものが正しく機能したものもあれば、そうでなかったものもあります。
自分が選定に誤ったと感じている事が一つあります。それは Web とネイティグアプリのコードを同一した点です。
時代はモバイルファースト、通知をうけとれるネイティブがよいと思い、B2Bのサービスに最初からネイティブアプリを導入しました。
これはいくつかの問題を生みました。
- 通常の Web サービスと比較するとレンダリング面で体験がよくない。
- ネイティブアプリのアプリの審査の基準がダイレクトにWebにも影響する
- 開発速度がWebと比較すると遅い。
- 企業にとって従業員の端末にアプリをインストールすることが許可されていない。
- ネイティブとアプリは機能が異なる。同じ体験ではない。
通知を受け取るには、アプリのほうが体験としてよい、ネイティブアプリが存在するアプリはより普及する、みたいな発想から当初は考えたのですが、この判断がビジネスの進み方を強く阻害しました。
長期的に主体的にアプリケーションの開発に関与することによってより痛感できました。
MVPについて
作くって体験しないとわからない、だからMVPで検証したい、というのは最近の流行り(というか常識?)
ただ数ヶ月かけてつくったMVPは経営者にとっては貴重なリソースです。特に資金力と時間が限られているスタートアップはなおさらです。
まずは最短で開発しよう。これはMVPだ!とわりきって作っても、それサービスにつながっていきます。
自分は正直、MVPを実際に使えるプロトタイプのような捉え方をしていました。
サービスになると品質が当然求められますし、追加機能もはいってきます。
このあたりは最初から想定して拡張性、品質を実現できるものを選定すべきだと痛感しました。
テストコードは書かなくてもよいがいつでも書けるように
特に初期のMVPの構築時、テストコードは多くのエンジニアはその時間をカットする選択をすると思います。それは正しいと思います。
ただいつでも書けるようにしておくようにしておく必要があると感じました。
”書けるようにしておく”とは具体的は下記のようなことを準備しておくことです。
- テストコード実行環境の整備
- アプリケーションがテスト実行環境で動作すること
- メンバーに書けるようになってもらう
なぜかというと品質よりスピード重視した場合、ビジネスは加速していきます。結果、品質が求められる時期も突然やってきます。
このとき、テストコードをかく準備ができてないと、品質と戦うことになります。
似たような話としては、Typescript です。
開発速度を重視すると導入しない、導入したとしても any とか ignore が多めになります。
私は案件を行うときに Typescript を導入するので、今回も導入していたのですが、初期はルールは緩くしました。
途中そのことによって実行時のエラーがおきるなどが多発したので、途中から厳密な型チェックをいれるようにしました。この対応を途中でいれたので大変でしたが、実行エラーが大幅に下がりました。
レベルの高い技術やインプットはなんだかんだで現状を打開する。
うちはメンバーを育成しながら開発しています。(メンバーはどんどん成長しているので、育成という言葉は適切じゃないかもしれない)
そんななかで重要だと感じるのは、こうしてほしい、ああしてほしい、ではなく具体的なお手本やルールを先につくり、これをみて使って開発してください、というものをどれだけはやく準備できるかが重要です。
ここの質がよいとメンバーの限界が変化してきます。
開発でよいインプットとは、すぐれたコードやフレームワークを用意するということです。
自分がその能力をなければ、その道に優れた人を探しだし、お願いするという手段もいいと思います。
その際もできるだけ自分の理想に近づくようなインプットを用意する必要があります。例えば、技術顧問を雇ってもその顧問へのインプットがなければ適切にワークしない可能性があります。
質高いインプットは当然のようにアウトプットの質をあげます。そのことは多くの問題を解決します。
人手不足も結局のところ、インプットがすぐれたものであれば解決します。アプローチが良いと開発ははやく終わり、安定するからです。
例えば、機能をつくるときに質の高いコンポーネントとそれの使い方がわかるサンプルを用意し、さらにはそれをテストするためのテストコードが事前に用意されていたとします。メンバーはそれ使ったり、参考にしながらつくっていくので、アウトプットのレベルがそろっていきます。
この具体的なインプットをつくるったり探してきたりするのが、最近の自分のメインの仕事になってます。
楽しいが最優先
サービスを開発するうえで大事なことってなんでしょう?
アップデートされつづけていく価値観の中で、一つの答えにいきつつあります。
それは作っている人が楽しいと感じれることです。
一年前の自分がみると、なんだそれは?とつっこみたくなりますが、今はそう感じています。
いろんな技術を導入しても、いろんな機能を作っても、作り手がそれをエンジョイしてないサービスは品質が悪くなり、使い心地が悪くなっていきます。
エンジニアには、楽しいにはいろんな方向性があります。作っている機能がよかったり、メンバーとのやりとりが楽しかったり、成長を感じれたりなどですね。
一つでも多くメンバーが楽しいと感じてくれていれば、サービスは自然とよくなっていきます。
結局人のモチベーションは細部にあらわれます。
若人から青春を取り上げるなんて許されていないんだよ 何人たりともね
呪術廻戦の五条先生の言葉です。すごいセリフですよね。最強キャラを先生にしようという発想がすごいです。
若手のメンバーからこうゆうことやりたい、と言われて、うーん、まだちょっとはやいな〜とか、方向性がちょっと違うな〜とか当然あります。
ただ本人がやりたい!と思っているなら、是非やってみてるのが一番です。
経験がないからここでつめ、サポートはする、かわりに全力をつくせ!
スタートアップはロマンであり、若手メンバーにとっては青春に近いと思います。彼らの人生を考えると、やりたいことをここでやってもらう!
それって上述の最高に楽しい体験になっていくと思います。それはつまりサービスの向上にもつながると自分は信じます。
経営者、メンバーとのコミュニケーションが大事
経営者とのコミュニケーションが大事だと痛感します。忙しいとどうしてもコミュニケーションが不足しがちになります。
ただ思ったより、CTO的ながんばりは理解されずらいです。なぜなら考え方、みえてる世界が違うからです。
同様に経営者の悩みも成果物に心血をそそぐことに集中している自分たちにはみえずらいです。
なので、普段からのコミュニケーションが大事です。
同様にメンバーとのコミュニケーションも大事です。1on1 をするといろいろ感じる事があります。
その他、PdM的なの学び
他のCTOはわかりませんが、自分はプロダクトの機能や体験設計もコントロールしています。
正直、役職とか呼び方とかどうでもいいとは思ってます。あるときはCTOだし、あるときはPM、PdMでもありますし、プログラマーでもインフラ見る人でもあります。いつか分業できる仲間ができたらいいなと思ってます。自分がどっち方面にいくかはわかりません。
サービスは価値を生みお金をもらうものでなければならない
これはまだ自分も答えがみえてません。ただいくつかわかってきたことがあります。
サービスには、売るための機能と継続してもらうための機能が存在します。
売るための機能はカタログスペック的なもので使ってみたいと思わせるようなものがあるか、ないかという話です。例えば、Slack 連携などです。
Slack 連携できます!とカタログにかければ、問い合わせが増えるという効果を生み出します。
実際にどの程度快適につかえるはさておき、このカタログスペックがあるかないか、というのが重要になってきます。
一方継続してもらう機能は使い心地がよかったりするいわゆる非機能要件(UX的なもの)などです。ここはなかなか奥が深く、この機能があるからトライアルではなく継続しなくてはならない、というものもあります。
この選定はものすごく重要になります。さらに機能だけでなく、UXも品質も重要になり、このバランスが難しい。
ユーザー目線で重要視する点を整理する
例えばデザインの話をします。
ブランドイメージがしっかりあって個性を表現するようなサービスが売れると思ってました。
では、ユーザにとってサービスの個性はあったほうがよいのでしょうか?
自分が毎日使うサービスのカラーはどうゆうものがよいのでしょうか?
自分のいまのところの正解ですが、わかりやすくシンプルであればそれで十分だし、サービス提供者側の個性はないほうがいいのだと感じています。
例えばヤフーとグーグルが全くの同じ性能だった場合、どちらが毎日使いたいとおもうでしょうか?
多くのはシンプルなグーグルを選択するのではないでしょうか?
売るために広告は個性的にする必要がありますが、普段からつかうものにそれは必要でしょうか?なんでもデザインをいれなくてもよいこともあるのかなと思います。
最後に
なんだかんだだで二年目に突入です。
いろんな体験をえて考え方はどんどんアップデートされてきました。
やっぱりやったことのないことをやるって大事です。新しい目線をてにいれることで物の見方が変わってきます。
優秀なエンジニアな人は、技術を追い求めるのも素晴らしいですが、ぜひ スタートアップのCTO をやってほしい、と思います。技術やエンジニアをみる尺度がちょっと変わります。
多くの経営者はそうゆうエンジニアを求めていると思います。この体験をすることで得られる事は大きいです。
あと新規メンバー募集してます〜!気軽にお問い合わせください。
Twitter とかでDMとかでも大丈夫です。
https://o-inc.jp/careers
https://twitter.com/coa00
ではまた半年ぐらいたてば更新します!
Stay Safe!!