CTOの jun です。今年から釣りを始め、10回は海に足を運んでいるのですが、一匹もつれていません。 近くに多くのベテラン釣り人もおり、釣り場としては成立していると思うのですが、あまりにも釣れないので何か根本的に間違いを侵しているような気がしてきました。 周りに頼らず自分の頭で考えて来年は鯵の一匹でも釣り上げたいと思います。
この記事では開発体制の変更について書きます。 プロダクトが拡張されていくのと同時に、プロダクト開発に関わる関わる人も増えてきており、自分たちがどのように考えて開発体制を変更してきたのか書こうと思います。
技術スタック型のチームからの脱却
過去テックタッチでは、フロントエンドとバックエンドで分けた２チームのスクラム体制をとっていました。これには2つの背景があり、創業当時から、フルスタックエンジニアではなく各領域にどっぷりつかったエンジニアの採用が進んだという背景と、テックタッチのフロントエンドは、第三者のページに対して影響を及ぼすこともありえるので、フロントエンドの開発はブラウザの仕組みやJSの理解を深くしていく必要があったという背景からです。
通常のフルスタック型（チーム内に全職能のメンバーがそろっているチーム）のスクラムとは違い、技術スタック型のスクラムでは、上流で製品仕様が固められ、チーム間にタスクが割り当てられ、各チームのタスクの完了を待って結合され、検証工程に入ります。小さなウォーターフォール開発のようなものです。 リリース頻度が半年～1年というような比較的大きな開発をする上では有効なアプローチだと考えており、明確な仕様のあるプロダクトの基盤を作る段階では有効だと思います。
テックタッチは、リリース後、プロダクトをほぼ0から作り直した過去があります。この再設計は無事完了し、当初の期待値通りのプロダクト品質の底上げを達成できたと思っております。 そこからプロダクトの磨き込みを進めていたのですが、少し違和感を感じるようになってきました。
一つは、お客さんの声が多く届くようになり、その期待にスピード感をもって対応していくには、上記のように半ウォーターフォールの側面のある開発スタイルはオーバーヘッドが大きい点です。
それよりも大きな違和感は、プロダクトが提供する価値や新しい機能がどういうユースケースに応えていくものなのかを議論する場が開発者のフローの中に設計されていないといったものです。
事業や顧客に無関心ではないのですが、技術の話が優先されているように感じました。 そこで、体制変更の検討を開始しました。
チーム体制変更にあたってメンバーとのコミュニケーション
体制の変更は、今までの会議体や意思決定プロセスを変更することになるので、簡単に進めるわけにはいきません。 一度たたきとなる自分の考えをまとめて、色々なメンバーに意見をもらいながら進めました。 特にフロントエンドのエンジニアのtaka（技術スタック型押し）とは、スタック型チーム解消におけるコードレベルの品質低下リスクについて、連日深夜に及ぶまで議論を重ねました。
エンジニアとして技術への探求心はモチベーションの源泉になりますが、その探究心とはまた別に、ユーザへの価値提供の最大化を自分たちで考え、それを形に変えることとそれがユーザに受け入れられることも、モノづくりの最大の魅力だと思っています。
フロントエンド開発のテック面でリードしてくれているtakaの考えも「安定した製品が顧客への価値提供に直結している」という点で正解ではありますが、僕たちが出した結論は、スクラムチーム内での議論はもう少しボトムアップされた「ユーザーにどのような価値を届けるか」を優先できる体制にしようとなり、技術スタック型からフルスタック型にチーム体制を変更することにしました。
実際にチーム体制を変更してどうだったか
チームが変更されたことで、フロントエンドとバックエンドの相互理解が深まったのは言うまでもありません。チーム変更によるリスクとしてコードレベルの品質低下を懸念していましたが、技術スタックごとの会議体を新たに設けることや、レビュープロセスを整備することで免れており、むしろ上がってきていると感じます。
この体制になってからリリースした「テックタッチ オートフロー」は多くの反響を得ており、既存機能のブラシュアップもユーザ目線で考えられた素晴らしい改善になっていると思います。
そして、当初の違和感を拭い去るように、事業やプロダクトのユースケースに対しての意識が高まってきたと感じます。もっと顧客に会わせてほしいという言葉が開発チームから多く出てきており、顧客理解の重要性が定着してきました。
このチームは社内の中でも「成熟したチーム」として認知されるようになってきました。チームが自立しており、安定して製品の機能追加やブラシュアップができる状態です。
避けては通れない成長痛
ただ、今現在の僕たちは次の壁にぶつかってもいます。 次の課題は、事業の成長とともに開発者が増えることで、一つのスクラムメンバー数として適切だと言われている8-10名を超えてきてしまっていることです。 過去、少し強引に2チーム体制に分割したこともあったのですが、チーム体制とアーキテクチャとの親和性が低く、手を入れたコードのコンフリクトが発生するなど非効率な面があり分割を断念しました。
しかし、いつまでも大きなチームで運用することは競争力の低下につながると思っており新しいアイデアとその準備を進めています。
最後に
スタートアップは最初のプロダクトビジョンでPMFすることを最優先で取り組むと思います。リリース後には顧客の声を聞きながらプロダクトを進化させていき、その過程でビジョンがより具体化してきたり、また違ったビジョンが見えてくると思います。
常に変化が起きる環境の中で、最適な体制とアーキテクチャを維持するのは困難ではありますが、足踏みに近い焦りは感じつつも、違和感を感じたタイミングでその違和感を言語化し、議論のテーブルに上げてチーム全体で解決に向きあっていくことが重要だと思います。
変化に強いソフトウェアを作るというテックタッチ開発チームの考えを実現できるように、体制も含め今後も体当たりで突き進んでいきたいと思います。
