株式会社トイポに実は入社してました!

ここ数年、筆不精だったのですがようやく重い腰を上げてブログを書き始めてみようと思います。2022年6月から株式会社トイポという小さなスタートアップにシニアソフトウェアエンジニアとして入社して、現在は開発全体を統括する執行役員CTOという立場で働いているのですが、入社からちょうど1年経過してキリがよかったのと、インターネットでちゃんと宣伝したことがなかったので今回はそのことについて書いてみます。実は入社よりもっと前から業務委託としてお手伝いはさせて頂いてたので、累計で言うとトイポのプロダクト開発には1年以上コミットしています。最近はいろんな人から「会うたびに会社が変わってない?」というツッコミを受けながら日々邁進してます。色々と大人の事情があったんや・・・

トイポって何?

トイポを一言で表すと店舗へのリピーターを増やすためのアプリです。店舗の業態は問わず、トイポの導入先には飲食店を始めとして温浴施設や整体、クリーニング店など、様々な施設があります。リピーターを増やすということはつまり、お店のファンを作るということで、彼らに何度もお店に足を運んでもらうことで、結果的に店舗の利益に貢献するのです。

トイポが特徴的なのは、プラットフォームとしてサービスを運営している点です。お店向けのアプリというと、各店舗がそれぞれ自分たち専用に開発したアプリを持っていることも多いですが、トイポでは「トイポ」というスマホアプリの中に各お店アプリが出来上がる形になっていて、いわゆるミニアプリ形式を採用しています。ブランディングという面では、自分たち専用のアプリを持つことと比較してデメリットが目立ちますが、トイポは利用料が非常に安く、さらにプラットフォームという特性上、トイポへの機能追加はトイポでミニアプリを展開している全店舗へ適用されることになるので、その辺りのメリットも大きいです。

ありがたいことに直近は優秀なシニアの方々が次々とジョインしてくれていて、全員の頑張りが事業の成長を後押ししてくれています。ここ半年ほどはトイポを導入してくださる店舗も順調に増えていて、これからさらなる成長を遂げるために何が必要なのかを考えながら、次のステップへ進もうとしているところです!

トイポの技術スタックって?

トイポの中身をちょっとだけ紹介すると、いま私たちが開発しているプロダクトは大きく4つのコンポーネントに分かれています。

  • API (Ruby on Rails)

  • エンドユーザー向けアプリ (React Native)

  • 店舗向け管理画面 (React)

  • 店舗向けアプリ (React Native)

また、インフラとしては基本的にはAWSを使っていて、CI/CDとしてGitHub ActionsやApp Center、データ分析基盤にはRedashやBigQuery、コミュニケーションツールにはgatherやSlack、ドキュメンテーションツールにはNotion、などなど、スタートアップとしてはよくある構成になっているのかな、と思います。

トイポでこれまで何してきたの?

そんなトイポですが、私が所属しているのは開発組織。トイポというプロダクトを開発・運用していくための組織です。シニアソフトウェアエンジニアとして開発組織に加わった自分が、これまでトイポの中でどんな活動をしてきたのか、プロダクト開発文化形成、そしてその中で生まれた組織的取り組みという3つの観点からそれぞれ振り返ってみます。

プロダクト開発

プロダクト開発については、いまでこそトイポのプロダクト全般に責任を持つCPOがいて、その彼が描いたプロダクト戦略を中心に、その戦略に沿った機能の実装をエンジニアとデザイナで進める、という流れになっていますが、私の入社当時はそういった明確なロール分けがありませんでした。つまり昔は、創業者の一人である当時のCTOが、プロダクトのことも考えるし、実装もするし、開発組織のマネジメントもするし、そして経営にもコミットするし、本当になんでもやっていました。リソースが豊富ではないスタートアップでは、そんな風に役割を兼任することは非常によくある話だと思います。

そういう状況の中でジョインした私の役割として期待されていたことは、当然プロダクトの開発業務、特に実装担当で、最初の1〜2ヶ月は実装者として当時のCTOや他の開発メンバーと一緒に機能開発に集中していました。トイポの生みの親であり、なんでもそつなくこなしてしまう当時のCTOの優秀さに関心しながらも、一方でプロダクトマネージャー、プログラマ、エンジニアリングマネージャー、経営者等のロールを兼任しているとどうしてもどれも中途半端になってしまいがちで、個人的にはそこに課題を感じていました。プロダクトファーストな事業計画の策定だったり、長期的なプロダクト戦略の策定だったり、そういうことにもっと集中してもらえると会社としてさらに前進できるのではないかという考えのもと「CTOを暇にすること(開発組織内の業務において)」というミッションを自らに課していたのを覚えています。当然この想いは本人との1on1でも相談し、実は本人もプロダクトに集中したいと考えていたということもあり、自然とCTOはプロダクト戦略に集中した方がいいよね、そういう流れが出来上がってきました。

それからの動きは速く、後述する文化形成や組織的取り組みなど私が主導しながら、これまでCTOがやっていた開発組織に関連する様々な業務をどんどん剥がしてきました。結果的に、当時のCTOは現在プロダクト全般に責任を持つCPOという肩書きでプロダクトマネージャー業に専念しており、うまくロールの分離ができるようになりました。

文化形成

当時、トイポの開発組織には実務としての開発経験を積んだメンバーが少なく、またレベル感もコードの質もバラバラでした。そんな中、私自身も含めて、開発組織が一定のスピード感をもってプロダクト開発に対してバリューを発揮し続けていくために、暗黙的に私に期待されていたもう一つの点として、開発組織の文化形成がありました。

良い開発文化というのは良い開発体験に繋がり、それはエンジニアのモチベーションやプロダクトの価値提供のスピードなどに繋がっていきますが、基本的に良い開発文化は自然発生するものではなく、作り上げられた文化の裏には必ず誰かの努力があるはずです。そういったことを意識しながら、自分自身の振る舞いを振り返る中で感じたコツのようなものを2つだけ書き下してみます。

現状を批判しない。尊重し、理解して受け入れる。
これは割と重要だと思います。外から来た人がいきなり否定ばかりしてくると、いくら正しいことを指摘されていたとしても、元からいる人たちは決していい気分にはなりません。テストを書かない、大したレビューもしない、週1回の深夜リリース、本番環境で直接作業、作業記録もない、など、こういうのは良くないよね、というのは誰もが認めるところだとは思いますが、ただ、誰もこれを望んでやっていたわけではありませんし、もっと言うと、こういう状況でありながらも前進し続けてきたお陰で今があるとも言えます。まずは現状の背景を理解し、そして現状を受け入れるところから始めないといけません。

リーダーシップを発揮する。文化の体現者となる
そして、文化を作り上げるという文脈においては、強烈なリーダーシップの元、文化を体現してくれるような人物が必要です。現状を理解して受け止めることができているという前提で、特に小さなスタートアップにおいては、リーダーシップを持ちながら経験と知識を行動と共にアウトプットし続けることで、そのリーダーシップが周囲へ影響を与え、成功体験が積み重ねられ、次第にその行動そのものが文化として浸透し、定着していきます。

組織的取り組み

そのような振る舞いをしていく中で、開発組織の中で出来上がっていった取り組みについて、こちらも軽く2つだけ紹介しようと思います。

MaaQ
M
ob-programming as a QAという言葉の略で、トイポ内での造語です。当時はテストに明るい人がいなかったため、みんなで集まって自動テストを書くという、週1回の頻度で実施されるイベント。私は幸いにも、これまでたくさんテストを書いてきた経験があって、テスト自体には比較的明るかったため、周りからの質問に答えたり、書き方をレクチャーしたり、時にはライブコーディングしたりしながら、テストの重要性を説き続けました。こういったことは1回やって終わるのではなく、継続して初めて成果が出始めるもので、続けていくとだんだんとMaaQの時間以外でも普段からテストを書くようになり、そうこうしているうちに自分が書いた自動テストで自分が修正した箇所のデグレを検知するという成功体験を複数人が経験しはじめ、今となってはテストを書かない人は誰もいなくなりました。なお、テスト文化を根付かせるという目的で導入されたこの取り組みは、その目的を達成した今、無事に解体されました。

少し話題は逸れますが、何かを新しく始める時、その取り組みに何かわかりやすい名前が付いていることは、それが組織内に浸透していく過程においては重要です。Mob-programming as a QAという文字列、そもそも英語的に正しいかどうかわかりませんが、少なくともMaaQというキャッチーでユニークな名前をつけたことで、それがみなの認知に繋がり、この取り組みが盛り上がった理由の一つだったのかなと思います。

プロダクトレビュー会
こっちはMaaQと違って普通の名前です(笑) スクラム開発におけるスプリントレビューとほぼ同等のもので、エンジニアが作った成果物を、実際に動くデモを通してプロダクトマネージャーから振る舞いに関してのレビューを受ける、という内容で毎週開催されています。元々振る舞いレビューのようなことはほとんどやっておらず、機能のリリース後に「思ってたんと違う」とか「ここ考慮不足で動作確認してないやろ」ということが良く起こっていたため、そういったことを防ぐ目的でこの取り組みを始めました。トイポの開発組織ではスクラムという枠組みに沿って開発しているわけではありませんが、そうでなくてもプロダクトマネージャーの構想とそれを実装するエンジニアの間でのフィードバックの受け渡しは重要なことで、またトイポのプロダクトレビュー会で特徴的なのは、CSにも参加してもらっていて、彼ら視点から意見してもらうことも有用なフィードバックとしてプロダクト改善に活かされています。

トイポでこれから何するの?

ということで、すごく長くなりましたが、この1年を振り返ってみてのことをつらつらと書きなぐってきました。もっと色々紹介したいこともありますが、あまりにも記事が長くなり過ぎそうで一旦ここで区切って…

さて、トイポでは、やりたいこと/やるべきことが無限に湧き出てくる状態ですが、我々はまだ小さなスタートアップですので潤沢なリソースがあるわけではありません。そういうわけなので、現状は私自身もいちプレイヤーとしてプロダクト開発にも参加している立場ですが、これからさらにプロダクトを前進させ、事業を成長させていくために、効率的なプロダクト開発が出来るよう、より良い文化を育て上げ、強い開発組織を作っていく必要があります。

そういう背景もあり、直近トイポではシニアエンジニアやプロダクトマネージャー、プロダクトデザイナの募集を開始しました。https://open.talentio.com/r/1/c/toypo/homes/4016

個人的にオンラインでのカジュアル面談はいつでも受け付けているので、よかったらお気軽にご連絡ください(Twitter @tkengo のDMは開放しています)そして最近は新型コロナが明け、各所コミュニティの動きも以前のように活気を取り戻しつつあり、オフラインのイベントも徐々に増えてきた印象を受けます。そういうコミュニティにも積極的に参加して、登壇して、友だちを作って、そしてトイポのプレゼンス向上にも繋げたい。

そういう想いを馳せながらこのノートの締めにします。飽きずに最後まで読んでくれた方、ありがとうございました!

この記事が気に入ったらサポートをしてみませんか?