見出し画像

コードが一行も書けないCEOがテックチームとの関わり方で気を付けてること

Sho Hashizume

Jamm橋爪です。
起業してから初めてのnoteとなりますが、初っ端から万人受けしなそうなトピックを選んでしまいました。

本トピックですが、大前提としてCEOがコードを書けることに越したことはありません。この記事はあくまで、「コードすら書けないのに起業してしまった」人向けの記事になっております。

…と言いつつも、開発の雰囲気やカルチャーについて少し分かると思うので、Jammへの転職を考えている方にも読んでいただけると嬉しいです。


まず軽くアンチパターンの把握

まず以下の「過剰関与CEO」パターンと「過少関与CEO」パターンを見てみましょう。

過剰関与CEO

マネフォの辻さんがエンジニアを催促してしまい、開発効率を落ちた、というツイートを以前見かけました。

こうなってしまっては、CEOが関与するだけで組織に対してマイナスですね。

過少関与CEO

以前とあるアーリーステージスタートアップに関して人伝てに聞いた話ですが、大量の技術負債を抱え3ヵ月間bug fixをし続けることになり、仕事がつまらなくなったエンジニアが数名やめた、という話を聞いたことがあります。
もちろん負債解消も重要ですが、ユーザーに新たな価値を一定期間届けられず、自社メンバーの士気も落ちてしまうのは非常に良くありません。

そうならないように自分はどうしてるか

とにかく、チームにとってマイナスなことをしない。これは当たり前に目指したいことです。更にテックチームにとって開発しやすい環境を整備するために、Jammで自分は以下のことに取り組んできました。

コードを書く前に（3ヵ月も）準備期間を取る

Jammの場合、コーディング開始前に3ヵ月ほどの準備期間取りました。その3ヵ月でテックと関連する部分で取り組んだことは以下になります。（簡易的にCTOと書いていますが、弊社の場合はテックリードになります）

MVPで（分からないことを）定義する

こちらのMVPの要素は結構一般的かと思います。

  • バリュープロップの定義

  • ターゲットユーザーの詳細な定義

  • 関連する外部システムの仕様の理解

  • ユーザー毎のuser journeyの定義

上記全てに関してCTOと100%意思疎通ができている状態でないと上手くいきません。もちろん「分かっていること」の同期も必要ですが、なによりも「分かっていない」ことの同期が重要だと思います。

例えばターゲットユーザーについて、Aのユーザーグループが一番いいと思っているが、もしかしたらBかもしれない。
どこで会社としてリスクを取っているのかを共有し意思決定を行うと、「ここは作りすぎてはいけなそう」や「このような機能が早期に必要になる可能性がある」のようなイメージを組織横断的にできるようになります。
これが将来ピボットする際に組織内の混乱や不安を軽減する作用をもたらします。

MVPの良い定義方法については良い記事が色々あるので、是非参考にしてみてください。

アーキテクチャを（良い質問をしまくって）考える

この際に弊社では「MVPで目指すアーキテクチャ」と「将来的に必要になるであろうアーキテクチャ」の二つ作りました。その差分をCTOと一緒に座って見つめることで、将来的に必要になってきそうな開発（システム分離や追加）についてイメージをすり合わせることができます。ざっくりにはなりますが、コードが書けなくても「この機能追加する時は大変になりそうだな」みたいなイメージが湧いてくると思います。

この時に色々CTOに聞いてみましょう。
「今ユーザー5000人想定だけど10万人になったらどこが一番ぶっ壊れそうか？」
「この機能要件、どうにかビジネス側で吸収できないか」
「将来的にこのようなユースケースが発生した場合に、このデータ構造で対応できそうか」
「競合他社はどのようなデータモデルにしてそうか」

ここでチームとしてリリースまでの時間を最小限に圧縮すると共に将来的な拡張性に対応できるようにするという相反する課題を両立しなければいけません。最大限のクリエイティビティを発揮して、このデザインプロセスを楽しみましょう。
ここはスピードを重視して、「monolithicにするけどコードは将来分離しやすく書こう」みたいな意思決定や、逆に「ここはあえて時間をかけてMVPでも対応しておこう」みたいな箇所もありました。

ここで質問しても設計が変わらない場合は、自分の質問が多分いけてません。いい問いかけができるように頑張ってください。

アドバイザー（を探してきて定期的）にレビューしてもらう

VCからよさそうな人を紹介してもらったり、自分からいきなり連絡してみたりしてアドバイザーを集めました。
関与してもらう方法として、テックアドバイザーにエンジェルに入ってもらったり、アドバイザーSOを渡してサポートしてもらったりと、オプションは色々あると思います。

初期は2~3週間に1回レビューセッションを1時間持ちました。こうすることで、CTOも時間ミーティングまで考えないといけないことも整理できますし、なによりも自分から「これをいつまでに検討して意思決定しよう」という回数が減ります。

（見えてる壁は痛くないから）想定されるピボットを書き出す

Jammは事業自体ステルスなので、詳細は書けないのですが、見えている範囲で出てきそうなピボットの方向性を書き出しています。
例えば2Bから2Cへのピボット。2Bの中でもターゲットのマイクロピボット。機能のピボット。

見えている壁に突っ込むのと、見えてない壁に突っ込むのはダメージが違います。メンバーが常に「こういうピボットは起こりうる」という意識を持ちながら仕事をすることで、将来の意思決定スピードを加速できます。

また原けんさんの記事ですが、こちらも参考にしてみてください。

チーム（ケミストリー）にフォーカス

追加でMVP開発中にCEOとして気を付けることは二つくらいあります。

一つ目はCTOがエンジニアチームとの信頼を順調に築けているか。
自分は定期的にCTOとエンジニアそれぞれと1on1をしながら確認してます。
具体的にエンジニアには「CTOがCTOとしてうまくやっているか」、またCTOには「各メンバーが期待されているアウトプットを出せているか」は毎回聞いてます。もちろんCTOとエンジニア間の直接フィードバックもその場で促しますが、自分から間接的なフィードバックもそれぞれのメンバーに共有してます。

二つ目は必要なスキルがチームに欠けてないかの確認。
どこかの領域でスキルが欠けている場合、そのゾーンをカバーできるメンバーを探してきます。短期的に必要な場合は副業で、長期的に重要な部分であればフルタイムメンバーを探してます。
自分は採用に20%以上の時間を使うようにしていて（一日平均2時間以上）、カジュアル面談1件+スカウトメッセージ5件のような日もあれば、culture deckを作って終わりの日もあります。

最後に

意外とやることありますよね

コードが一行も書けなくても、テックチームに対して提供できる価値はかなりあるはずです。更にこれ以降でもサービスの主要指標やユーザーの反応を確認しながら、プロダクト改善を進めていく感じになるので、やることは無限にあります。

ふわっとMVPを定義して、機能を詰め込んで、アーキテクチャには目を通さず、ただ進捗を細かく聞いてくるCEOにあなたはなってませんか？
…と私は毎日鏡を見て自分に問うてます。

めっちゃ採用してます！

エンジニアチームめちゃくちゃ採用してます！特にBackend, Appメンバーを探してますが、Frontend, Designerの方もご興味がある方がいらっしゃいましたら、お話させてください！（twitter DMください！）

めちゃくちゃ強いメンバーが集まってきており (ex-google, mercari, indeed) エンジニアの方にとって中々刺激的な環境なんじゃないかなと思ってます（コード書けないお前が言うなよof the year）。

Culture deckに弊社が取り組んでいる社会課題等について書いてあるので、ご興味ございましたら是非見てください。

日本語版はこちらのリンクから:
https://speakerdeck.com/jamm/jamm-culture-deck-jp

Let's get Jammin'!


いいなと思ったら応援しよう！