「本質を探し続け、柔軟に考える」　matsuriの開発チームとは

はじめましてmatsuri technologies株式会社の花田です。
matsuriの4人目の社員でもあり、約5年、開発部のこれまでの変遷を見てきましたので、どんなチームなのかといった点をお伝えできればと思います。

先に少しだけ私の自己紹介をすると、
職責としてはエンジニアリングマネジャーで、開発部における課題を見つけ、それの解決のために力を注いでおります。GoやRubyを使ったプロダクトのの開発・保守は今でもやっています。
現在は採用活動をメインにしておりますが、以前はカルチャーや雰囲気、また評価制度の整備をやりました。まだ運用が始まったばかりで改善点は多く有ります。

エンジニアリングマネジャーになる前は、何でも屋的なポジションで、開発・運用・保守はもちろん、パートナー企業の技術コンサルをしたり、テスト仕様書作成をやったり、英語での会議をやったり、と色々やってました。

1.どんなメンバーがいるか

構成としては2022年3月現在、CTO1名、EM1名、バックエンド寄りが2名、フロントエンド寄りが2名、デザイナー1名で7名と小規模なチームで、5つのプロダクトを作って回してます。
メンバーの雰囲気としては、のんびり、プロダクトをよくしていきたい、技術大好きといった感じでまとまっています。しかし、メンバーの背景は多様で、数学系で修士を修めた人、CTO経験者、調理師経験者、厳格なキリスト教徒、中途入社や新卒入社、と様々です。

2. どんな成長ができるか

1つ優れた技術を持つようになること、そして、プロダクトのライフサイクルをすばやく回すという能力が身につけられるようになります。
少し歴史の話になりますが、当初はRailsでモノリシックに開発していました。今はGo、Rust、React+TSをメインで使用するようになり、かつ、マイクロサービスアーキテクチャを採用するようになりました。かなり大胆に採用する技術を変更しました。これの実施のためには、いわゆる「技術投資」というのをかなりやりました。各アプリケーションの設計から実装まで、徹底してクオリティを求め、必要とあらば投資を惜しみません。
他にも、マイクロサービス化の副作用であるところの、並行した開発とデプロイの恩恵はかなり感じられましたね。
これにより、プロダクトに集中できるようになりました。サービス分割をする一方で、バックエンドかフロントかのどっちかしか携わってはいけない、みたいなサイロ構造は採用しませんでした。

プロダクトをよりよくするために、最も優れたものが何かを探求し、そのための技術投資を惜しまず、やれることはなんでもやる、というスタンスです。なので、ウェブアプリケーション開発において、1つ優れた技術を持って、かつ、プロダクトのライフサイクルをすばやく回すという能力を身につけることができます。
結果としてはプロダクトをよりよくする、ということを期待していますが、そのためには、大きな仕事に立ち向かえる人、専門性があり徹底した調査ができる人、継続的に勉強しそれをエヴァンジェれる人、のいずれかにはなって貰えるように成長を促してます。

3. チームの雰囲気

採用している技術への変化について触れましたので、他の変化についても触れます。
組織的な変化についてですが、CTOの石橋は技術面だけではなく、仕事の進め方に関しても手を加え、ビジネスサイドと開発サイドとのコミュニケーションコストの低下や、両サイドが一つのプロダクトに向き合う時間を設けられるようになりました。

今は「プロダクト会」という形で、プロダクトごとに週1もしくは隔週でビジネス側と開発側との話し合いの時間を設け、要望の明確化や整理、また進捗状況の共有、フィードバックの獲得ができるようになりました。
仕事がやりやすくなったのは情報共有の観点からもですが、同じ目標が共有されたことによって、漠然とあった溝みたいなものが減ったのかもしれません。

技術や組織は変わりましたが、本質的なところは変わっていないような気がします。のんびりした雰囲気があることとかは変わらないです。実際、2021年の4月に開発部のカルチャーとして、「本質を探し続け、柔軟に考える」、「小さく挑戦、すばやく失敗」、そして「フィードバックし、継続的に成長する」という3つのスローガンを立てましたが、これらは、私が入社した当初から変わらず、ずっと開発部にあって、開発部が大事にしてきたことです。人が増えたら文言は変わるかもしれませんが、本質は変わらないようにしていきたいですね。

👉開発部へのエントリーはこちらから