CLOSE

【小規模チーム事例】小規模チームの裏話 – 弱者のマインドセット(全1記事)

スピード優先の“リード・ホフマン派”か、クオリティ優先の“スティーブ・ジョブズ派”か プロダクトライフサイクル導入期〜成長期におけるデザインと開発の裏話

大規模組織と少数精鋭チームそれぞれの方に、ステークホルダーとの合意形成の大変さや対応の工夫を聞く「チーム規模で違う?プロダクト開発の意思決定と合意形成の裏側を聞いてみた【開発PM勉強会vol.23】」。ここで株式会社Rebaseの林田氏が登壇。プロダクトライフサイクルの導入期から成長期の期間で起きていた、デザイン・開発の裏話について話します。

林田氏の自己紹介

林田遼氏:株式会社Rebaseの林田と申します。今はRebaseでプロダクトグループのグループマネージャーと、デザインチームのチームリーダーという仕事をしています。本日私は「小規模チームの裏話 弱者のマインドセット」というタイトルでお話ししたいと思います。

まず簡単に私のRebaseでの経歴を紹介・説明します。

私は2017年にエンジニアとしてRebaseに入社しました。当時はエンジニアが3人で、デザイナーが0人、PMも0人という状況でした。僕を含めてエンジニアが3人だったのですが、もう1人がCTO、もう1人が僕より遥かに優秀なエンジニアというチーム構成だったので、必然的に僕がデザインとかPMとか、プロダクトを作るのに必要な役割をすべてを巻き取るような状態になりました。

2019年にエンジニアを辞めて、デザインチームの立ち上げを行いました。そのあとプロダクトグループのマネージャーに昇進して、2022年に会社としてグロース市場への上場を経験しました。

趣味としては登山が好きで、好きな山は長野県にある燕岳という山です。みなさんがイメージする普通の山って、茶色い地面に木がいっぱい生えているみたいな感じかなと思うんですが、燕岳って白い……。あ、すみません。これぐらいにしておきます。ちょっと話が長くなるので、とりあえず次に行きます。山が好きな奴だと思っておいてください。僕はPMを専任でやったことはありません。あくまでも兼任でやっていたかたちになります。

プロダクトライフサイクルの導入期から成長期にかけて意識していたこと

(スライドを示して)こちらが一般的なプロダクトライフサイクルの図です。プロダクトというのは導入期があって、成長期でグーッと伸びて、成熟期でちょっと落ち着いて、衰退期で衰退していく。僕は導入期の中盤ぐらいに入社しました。なので本日の話は、この導入期から成長期にかけてあたりの話だと思って聞いてください。

この期間にずっと意識していたことがあって、それが「とにかく迅速に価値を提供する」ということです。なぜかというと、理由は2つあります。

1つ目が、せっかく作ったなら少しでも早くユーザーに届けたいという思いが単純に強かった。僕だけじゃなくて、チームとして(この思いが)強かったというのがあります。

あとはこっちのほうが大事なんですが、スタートアップは大手と同じやり方をしたら負けるという危機感が常にありました。質と量で考えた時に、正直大手にはどちらでも勝てないなと思っていて。なのでせめてスピード感だけでは負けないようにしようというマインドをチームで意識していました。

『ハウルの動く城』状態でのリリースは正解だった

裏話。デザイン編に入りたいと思います。私たちにはずっとデザイン面の課題がありました。リソース不足だったんですね。

これはどこの会社さんでもあることかなと思いますが、その結果、私たちみたいなスタートアップの場合にどのような影響があるかというと、だんだん『ハウルの動く城』みたいなデザインになってくるんです。

僕らの場合、当時は基本的にエンジニアがデザインしながら開発をしていて、たまにデザイナーさんがスポットで入って対応してくれたりはするんですが、徐々に一貫性がなくなっていくんですね。

この状態でリリースすると何が困るかというと、まず、「恥ずかしい」です。あとは「この状態で本当にリリースしていいのか」という不安とか葛藤があったりします。

でも今振り返ると、これらの感情は正解だったなと。『ハウルの動く城』状態は正解だったなと思っています。

なぜかというと(その理由は)2つあって、まず1つ目が初期のユーザー、これは一般的にイノベーターとか、アーリーアダプターとかと呼ばれる人たちですが、この人たちは新しい価値とか利便性を求めていると思っています。

なのでデザインの不完全さはある程度許容してくれるんですね。もちろん、デザインはきれいに越したことはないんですが、ただ、初期ユーザーからすると「まずは新しい価値とか利便性がそこにあるかどうか」ということが、使うか使わないかの判断材料になるかなと思っています。

もう1つがContent is KINGという言葉。これはSEO系の言葉で、仮にデザインが不完全だとしても「インスタベース」でしか予約ができないものがそこにあるんだったら、ユーザーは使ってくれると思っていました。なのでもし恥ずかしい状態だとしても、まずは早くリリースして、そこに早くコンテンツを載せていくことを優先するようにしていました。

ホフマン派か、ジョブズ派か

ここでちょっと2つ名言を紹介したいと思います。1つ目が「Linkdin」の創業者のリード・ホフマンさんの言葉で「サービスをリリースした時に恥ずかしさを感じないとしたら、リリースするのが遅すぎる」という名言があるんですね。これは「X」に書かれていたんですが、これを見た時に「あぁ、自分たちが感じていた恥ずかしさとかって正しかったんだな」と思いました。

もう1つ。スティーブ・ジョブズさんの名言で「急いでできそこないを発表するよりは、期日を遅らせる」というものがあります。これって要は「恥ずかしいものは世に出すな」という意味だと思っていて。

この2人は真逆なことを言っていると思うんですよ。弊社の場合はCTOがホフマン派で、CEOがジョブズ派だったんですね。こうなると、時に意見がバチバチに食い違うことが起きる。なので、みなさん新規事業を始める前に、自分たちはホフマン派で行くのか、ジョブズ派で行くのかをあらかじめ社内で合意形成をしておくことをおすすめします。

自分たちが納得できる言い訳を作り、その代わりにスピードを出す

次に裏話の開発編に入りたいと思います。私たちは開発面でも課題がありました。こっちもリソース不足だったんですね。実際にエンジニアも3人しかいなかったし、新しく採用をするといっても、それまでがずっとリファラル採用だったので、誰も採用活動とかをしたことがなくて。そんな中でどう向き合ったかというと、これも2つあります。スライド32

1つ目は「コードは汚くてもOK。とにかく早くリリースしよう」と考えていました。なぜかというと、このフェーズではきれいなコードを書くことよりも、まずは会社の成長を優先すべきだと。会社が大きくなってくれれば、あとから優秀なエンジニアが入って、全部きれいにしてくれるだろうと。そういう希望的観測をしていました。

実際に今まさに優秀なエンジニアさんたちがたくさん入ってくれて、昔に僕が書いた闇のコードを全部葬り去ってくれています。なので、これはその時の判断として合っていたんだなと思っています。

2つ目に「リリースしてからユーザーにテストをしてもらう」ことを意識していました。テストは品質を担保するものですが、スタートアップとか新規事業では会社や事業の存続自体が最優先です。

なので、決済とかセキュリティ以外のテストは最小限にしてしまおうと。その代わり、「Sentry」とか「New Relic」みたいなエラー監視ツールをいち早く導入して、エラーが発生したら迅速に対応するようにしていました。

要はこれを全部まとめると、「これはマストでやる必要があるよね」というボーダーラインを意図的に低く設定してあげて、そこに自分たちが納得できる言い訳を作ってあげる。そうやってエンジニア3人でもスピードを出せる環境を作っていました。

林田氏が心がけていた“一人多役”

次に、私個人が心がけていたことです。正直な話、僕はエンジニアとしてはぜんぜん優秀ではありませんでした。本当に闇のようなコードをたくさん量産していました。デザイナーとしても「デザイナー」と名乗れるほどのスキルは正直なくて、PMも兼任でやっていただけなので、スキルとしてはすごく不十分でした。

ただ、私自身が心がけていたというか、これはただのポジティブシンキングの話なんですが、一人多役という状態を目指すようにしていました。これは強みとしての“何でも屋”みたいなイメージです。

一般的には“何でも屋”ってネガティブな文脈で使われることも多いかなと思いますが、僕は強みだなと思っています。

『達人プログラマー ―熟達に向けたあなたの旅―』という有名なエンジニアの本があるんですが、ここに「毎年少なくとも1つの言語を学習する」という教えが最初のほうに書かれているんですね。

「異なる言語やツールでの経験が、多角的な解決策を生むからだ」と書かれています。この「多角的な解決策を生む」というのがけっこう大事なことだと思っていて。

PMの方って(PMが)セカンドキャリアの方もけっこう多かったりすると思うんですが、前にやっていた仕事の知識のおかげでプロダクトマネジメントがスムーズに進むみたいな経験を、みなさん持っていると思うんですね。

なので、僕みたいにどのスキルにおいても優秀じゃないとか、中途半端みたいな人でも、いろいろな知識をつけておくこと自体がすごく重要だと思っているし、そういう心がけがその時のリソース不足を緩和することにもつながっていたかなと今では思っています。

株式会社Rebaseが上場するまでのプロダクト面の変化

最後に弊社が上場するまでのプロダクト面の変化を紹介します。まず変化の1つ目が、昔は『ハウルの動く城』でしたが、今はなんとサクラダ・ファミリアぐらいの完成度になっています。一貫性はあるけれど、いつ完成するかはわからないみたいな。プロダクトってそういうものだと思っています。

変化の2つ目としては、ちゃんとテストをするようになりました。「上場するということは社会のインフラになることだよ」と言われたことがあって、目新しいモノから安心なモノへと変化しなきゃいけない中で、変化をしました。

変化の3つ目としては、インスタベースはジョブズ派になりました。やはり安心なモノへと変化するという中で、不完全な状態でリリースするのはちょっと難しいよねと。でも期日も遅らせたくないというところで、プロダクトマネジメントが以前よりもより重要になってきています。

一方で、新規事業に関してはホフマン派で引き続きやっています。要は、ジョブズ派とホフマン派をプロダクトによって使い分けるってことが起きています。なので、どちらも経験できるというおもしろいフェーズになっているかなと思っています。

弊社は10年目の会社ですが、2022年にようやく1人目のPMが入ってくれました。

ご清聴ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!