【コネヒトーク5th「ママリ、クックパッド、BASEのCTOが語る!組織づくりや技術選定について」】に行ってきました

コネヒトーク5th「ママリ、クックパッド、BASECTOが語る!組織づくりや技術選定について」

https://connehito.connpass.com/event/141459/

に行ってきたので、そのときのレポートです。

自己紹介

コネヒト CTO:伊藤さん

クックパッド CTO:成田さん

BASE CTO:川口さん

お題1:「CTO を打診されたときや、就任時の心境は?」

共通点として、それぞれ、2代目 CTO であること。

それを踏まえてのディスカッション。

川口さん

CTO になる前は、漠然と、同じようなテックリードなどを育てていくことになると、キャリアパスを考えていた。

ある日、初代 CTO の方から、CTO やらないか?と言われた。

理由を聞くと「まかなわなければいけない範囲をまかないきれなくなったので」だった。

そこで、技術に特化した範囲を担当する(経営にはあまり触れない)範囲であれば、やりますとなった。

伊藤さん

CTO に、ランチのときに、やってくれないか?と言われた。

CTO は辞めて、新しいチャレンジをしたいという背景だった。

迷ったが、迷ったら一番難しいことをやろうと決めていたので、やりますと回答した。

また、CTO という責任のあることをやるのはやりがいがあると思った。

成田さん

CTO になったのは結構前(2016年)

打診を受けたときは、ワクワクした。(「やっていいんだ」と思った)

もともと、CTO になったらやってみたいことがいくつかあった。

前の CTO を見ていても、自分だったらもっと上手くできると思う部分があった。

ただ、数年経って、前の CTO を改めて思い起こすこともでてきた。

お題2:「CTO って何をしているのか?」

川口さん

今日は、採用関係のことをしたり、技術マネージャーと MTG したりとか

リリース関係の優先度の判断をしたりとかを主にしていた。

結構 CTO になってから、採用周りの仕事は増えた。

質問:前 CTO との住み分けはどうしているんですか?

面接に来たひとにとっては、前 CTO が判断したほうがいいときとかもあって、

会社経営に関しても、前 CTO に任せている。

川口さんは、プロダクトに責任をもつようにしている。

成田さん

CTO として、いま困っていることをやるのではなくて

1 年後とか 3 年後とかに困りそうなことを対応しなくてはいけない。

そのためにはインプットが必要で、

あらゆるエンジニアの分報を確認したり、他の CTO の方の話を聞きに行ったりしている。

伊藤さん

経営会議などに出たりしている。

マネージメント業務を意図して自分に寄せている。

コードは書きたい気持ちもあるが、その気持ちは抑えて、

戦略を考える時間を多くするようにしている。

お題3:「事業会社の CTO としての大変さは?」

例えば、事業会社だと、0 -> 1 でスクラッチで開発する機会が少なく、

挑戦だったりモチベーションの対応とかどうやっているのか?

成田さん

クックパッドは 20 年近いシステム

それを改善していくのが日頃の業務。

確かに、技術的なチャレンジをどうするか?

グロースするにしても、CM 打ってもあまり変わらないとか、アプリランキングが上がっても下がっても売上に影響ないとか。

そういうフェーズに来ている。

なので、日頃の業務が楽しいと思える人が活躍できる現場になっている。

成田さんは、そういう中で、現場のモチベーションを保つように意識している。

伊藤さん

ある程度、新しい技術を取り入れる事に関しては

方向性を示していかないといけないのかなと思っている。

川口さん

PHP 界隈では大きなシステムになってきている。

逆に、PHP 書けないと入社できないのかなと思われるのが良くないと思っている。

そこで、新しい技術を取り入れることも考えるが、

PHP で作ったほうがスピードが早かったりもする。

そういう面で、悩んだりはする。

成田さん

そういう時に、マイクロサービスなのかなと思っていて、

マイクロサービスは失敗がしやすいと思っている。

新人が入って来た場合は、既存の技術スタックを学ばないといけない側面があるが、

失敗がしづらいと思っている。

成田さん含め、失敗してきて積み重ねてきたのが今を作っている。

Rails 以外にもバックエンドだと、Go, Rust, Java など使っている。

質問:ハレーションなどはありませんでしたか?

既存のシステム構成だと、デプロイのスピードが早いというメリットがあったが、

マイクロサービスを取り入れると、整っていない環境になってしまうので、

メリットが感じられず、反対意見が多かった。

環境が整うと、誰も何も言われなくなった。

Q & A

Q1CTO をしている上で、決断を迫られるとき、苦境に立たされたときにどのようなモチベーションを保つようにしているか?

成田さん

苦境はメッチャある。

苦境は基本、人にある。

目の前にいる人が働いていて楽しくないとか、そういうことが苦境になる。

そういうときのモチベーションはサービスにある。

会社の中の揉め事は、サービスに関係ない。

川口さん

成田さんとほとんど同じ。

僕らが立ち止まっていても、お客さんは知ったことではない。

サービスを使っているのはお客さんなので、

決断を求められたときの判断材料は、サービスのためになるかどうか。

伊藤さん

二人とほとんど一緒。

最後の判断基準はプロダクトだなぁと思っている。

サービスのことを考えて、意思決定をするようにしている。

成田さん

もともと成田さんはインフラをやっていたので、ログをよくみていた。

それが心の支えだった。(ログの向こうに、ユーザを感じることができる)

エンジニアがクックパッドに入るが、相性が合わずに辞めていくことが残念だと思うが

それよりもサービスが止まっていることのほうが問題。

川口さん

同じく、サービスが止まっていて一番困るのはお客さん。

また、それぞれのエンジニアの中で、サービスが止まっているときの不信感を考えながら

判断をするようにしている。

Q2:「それぞれの理想の CTO はいますか?」

伊藤さん

ないです。

その中で、前職の CTO の人が、どんどん周りを引っ張っていくタイプだったが

その人に「同じようなことができない」と言ったところ

「自分にしかできないことがあるので、同じようにしなくてもよい」と言われた。

なので、明確な理想はなくて、自分で作っていくしかないんだろうなと思っている。

川口さん

ユーザになりきれないサービスを担当していて、困ったことがあったが、

やっぱり、いとうなおやさんはすごいなと思う。

成田さん

従業員がユーザになれるサービスはとてもいいと思う。

伊藤さん

ママリとかは、男はどうしてもユーザになれないが

そこは、ユーザではないからこそできることもあると思っている。

それが、データドリブンだったりとかそういう手段があると思う。

そもそも、コネヒトとして掲げているものがあるので、そこをモチベーションにしていることもある

川口さん

前職で、乙女ゲームをしていたが

会社ではユーザではなくお姫様と呼ぼうと言われていた。

ので、いまだにユーザと呼ぶとドキドキする。

成田さん

自分も同じで、前職はユーザと呼んでいなかったので

クックパッドでユーザと呼んでいるとドキドキする。

Q3:「中長期の技術戦略を考える上で、どういった進め方をしているのか?例えば、製品に直接関わらない技術改革などを、どうしているのか?」

成田さん

あまりそういうことは、現状していない。

いままでの CTO やエンジニアを踏襲しているフェーズ。なので変えてない。

未来に向けて動くというのは、そういうところではなくて、どっちかというと

インサイト:従業員の気づいていないことにどう気づくか?

に目を向けるようにしている。

なので、過去 3 年分の記録を追ったりして、みんなが気づけないことに気づくようにしている。

長期的に見る目線が大事。

伊藤さん

まだ行動に移せていることはないが、

伊藤さんが CTO になったときに、経営陣が刷新された。

新しい経営陣のビジョン等を聞いて、CTO としてどうコミットできるかを考えているところです。

川口さん

経営に関することは、他の人に任せていて、

技術戦略を考えないといけないが、いまはまだできていない。

そこで、3 年後とかのために、材料を集めているところ。

成田さん

採用を通す人が変わった。

この人が入ると会社が変わるのかな?という目線で考えるようになった。

現場にちょっとと思う人でも、会社にとって良い行動を起こしてくれる人なども

採用していかなければなと思っている。

お題4:「CTO として今後やっていきたいことは?」

成田さん

成田さんが CTO をやっている理由が、クックパッドのミッションを達成するのが好きだから。

だが、結局は人だと思う。

成田さんが学生のころ、友達の部屋によく遊びに行っていた。

そういう、みんなが集まるような場にクックパッドもしたいと思うようになった。

そういう文化が、組織を強くして、サービスを強くするんだと思うようになった。

川口さん

いまのサービスを日本で 1 番にしたい。

ただ、その思いは、自分がインターネットが好きだから。

だからこそ、インターネットに貢献したい気持ちがある。

CTO は責任をもらっていて、それが重要だと思う。

最終的な決定権は CTO になると思う。

採用に関しても、インターネットに貢献できる人を採用できるようになったのが良かったと思っている。

伊藤さん

家族を幸せにするサービスを作りたいと思っている。

伊藤さんは自由に育てられた。それをなんとも思っていなかったが

大人になって、恵まれていたと思うようになった。

家族に対して、幸せにしたいと思うようになった。

そこにコミットしていきたいと思うようになった。

CTO として、そういうことをしていきたいと思うようになった。

ビジネスにテクノロジーが貢献している会社がテックカンパニーだと思う。

家族を幸せにしたいというビジョンに対して、テクノロジーを使って貢献していきたいと思っている。

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得に行ってきました

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得

https://supporterzcolab.com/event/410/

に行ってきたので、そのときのレポート

対象者

  • 現在新規事業の立ち上げに携わっている方
  • これから新規事業にたずさわるかもしれない方
  • (もしくはたずさわりたいと思っている方)
  • ライブラリを書くより、プロダクト開発が好きな方

話すこと

  • 作りすぎて失敗したことの事例紹介
  • つくりすぎないために
  • コアバリュー大事

登壇者の方が作ったサービス

pook

https://s.pook.life/lp/

ランサーズは、オンラインクラウドソーシングの会社だが

pookはオフラインでやることに特化したサービス

 → オフィスで肩を揉んでくれたり

 → 栄養士の方が手作りご飯を届けてくれたり

本題

エンジニアの新規事業への関わり方

そもそも新規事業って?

新規事業とは、既存事業から生かして、新しい経済成果を生み出すこと。

対して、起業というのは0から始めること。

どうやって関わって行くの?

求められること

サービスを作ることが求められる。

実際には、プログラムを書くというよりは、問題を解決すること。

失敗1:作りすぎた。

リリース時に作ったのは、

  • APIの数150本
  • ページは80

ガチガチの仕様をその通りに作ってリリースした。

多いと何が悪いか。

多いとリリースが遅くなる

 → 多すぎたということは、無駄なことを作ってしまった。

  → 使われないコードはただのゴミ。

本当にあった怖い話

 nヶ月書けて作った仕組みをすぐに消した。

 顧客が本当に求めていたものと違った。

どうすれば良かったか?

作らなければよかった

 → しかし作って見ないと分からないこともある。

  → 作る前にそもそも考えることがあるはず。

  • 同じような体験ができるサービスを作って模擬する。
  • ユーザーにもっとヒヤリングする
  • プロトタイプで実験してみる。

反省

  • 作らないで実験できないか考えてみる。
  • 試したい仮説をすぐに実装できないか考える

失敗2:技術選定

エンジニアあるある。

最近イケてる○○という技術を使おうぜ!

 → 既存に縛られないので、使いがち

結果

情報が少なくて死ぬ。

社内で知識が多い人の助けも受けられない。

サービスがあたるか当たらないかという問題の前に

サービスが作れるか作れないかという問題が発生する。

反省

  • 枯れた技術を使うべきだった
  • もっと協力しやすい技術を選定すべきだった。
  • できるかどうか分からないは早めに潰す。

失敗3:仕様が変わる。

どうしてそうなった?

  • 作るべきものがあやふやだった
  • 目的を達成するための機能がもりもり
  • 全部マスト

どうすればよかった?

コアバリューを定めて、やらないことを決める。

コアバリューとは?

ミッションやビジョン実現のために、組織が独自にもつ共通の価値観。

これを選定することで、作らないものを決めることができる。

 → コアバリューはなんですか。どうしても欲しい機能はなんですか。と唱える。

  → そうすることで、議論の着地点も見つかる。

反省

コアバリューを決めて、作らないを決める。


まとめ

新規事業開発に置けるエンジニアの心得

  • 一番大事なことは作らないこと
  • また、そのために、コアバリューを決める。
  • エンジニアとして問題を解決することにコミット

とはいえ、経験がないと分からないことが多いので、経験をたくさんしよう。


Q & A

Q1.

コアバリューを決めることでいらないものが見えてくるということだったが

APIの数など具体的にはどの程度減ったりするか?

A1.

Apiの数は80本になったりした。大体全部合わせて半分くらいになった。

Q2.

やっていくなかで一番コストがかかることは?

A2.

新規事業でいうと、人件費が一番コストになる。

技術でいうと、どこにコストがかかるか?

 → 作って捨てればいいので、キレイに作らないことを考えればよかった。

  → 無駄にキレイにつくることを考えてしまった。

   → 結果、使われないキレイな部分ができてしまった。

なので、キレイに作るっていうところにコストがかかる。

Q3.

新規事業をやる上で、予算をどのくらいに抑えろとかあったか?

A3.

最初はなかったが、途中からなんでこんなに時間かかってんだとかあった。

最初はノリで始まったものだが、どうしてこれこんなに時間かかってるの?とか。

新規事業は黒転するまでに時間がかかる。

 → なので、試算を前もってしておいて(エンジニアどのくらい必要です。どのくらいでリリースできます。どのくらいで黒転しますとか)ロードマップ考えておこう。

Q4.

開発するに置いて、「これ使ったよ」みたいなツールとかあるか?

A4.

プロトタイプを作るツールでいうと、InVisionというツールを作っていた。

https://www.invisionapp.com/

InVisionというのは、web上ピピッと操作してプロトタイプを作れるツール。

逆にコンフルエンスを使ったのは失敗だったと思った。

コンフルエンスはバージョン管理ができたり、キレイに書けたりすることができるツール

別にキレイに書く必要はなかったが、キレイにかけるがために、キレイに描こうという空気ができてしまった。

それよりも、ガンガンアウトプットできるようなツールのほうが良かった。