※こちらの記事は、STRACT公式noteにて掲載した記事の転載です。

はじめに

先月に開発チームのリードとして入社をした加藤です。

僕の入社時の思いを綴ったブログはこちら

入社してからの2ヶ月間は怒涛の日々でした。がっつりコードを書き、開発サイクルの改善をして、採用活動をして、チームビルディングをしたりとたくさんの活動をしてきました。 その中で、会社やプロダクトのこと、開発と組織の課題も見えてきたので、これからの開発組織として、僕がやっていきたいことを書いていきたいと思います。

休日に勢いで書いていることもあり、あまり整理されていないかもしれませんが、ご了承ください。

現状の開発組織

CEOである伊藤を筆頭に、加藤がリードをしつつ業務委託の方含めた9名で開発しています。業務委託の方にはフルコミットや副業、技術顧問として関わっていただいています。
開発スタイルは、 全員が フルサイクル で開発をしています。そのためにモノレポでのコード管理やTypeScriptの全面採用、開発バックログの統一などをしてコンウェイの法則に沿いつつ開発効率を上げる取り組みをしています。
アジャイル開発を採用しており、以下の３つの理由でスプリント期間を1週間に設定しています。

1. チームの状況がタックマンモデルの 形成期 の状態であり、コミュニケーションのイベント数を増やすことでメンバー同士がそれぞれを知ることに重きを置きたいため
2. 伊藤以外のメンバーのドメインや仕様、コード理解が浅いため、なるべくタスクを分解をして、メンバー同士が何をどのように開発をしているかを把握・キャッチアップしやすくするため
3. 不具合が多く差し込みタスクが多いため

STRACTでは出社を推奨しており、僕も週3日で出社をしています。出社するとコミュニケーションをより円滑にとれると実感しています。もちろん、コードをガッツリ書きたいときはリモートワークも活用します。
また、チームとして開発を始めて日が浅いので Working Agreement をメンバー間で話し合い作成をして全員が Approve をして取り組んだりと、ハイブリッドの出社環境でもコミュニケーションを適切に取れる仕組みづくりをしています。

Working Agreement を作成をして approve をもらっているところ

他の取り組みだと 開発ドキュメントや調査ドキュメントなどストックする場所の整理 や コンテキストを揃えたコミュニケーションを意識できるようにツールや使い方の整理 などおこなっています。

レトロスペクティブ の様子

直近の課題

直近の課題としては以下の解決を意識して取り組んでいます。

1. 属人化の解消

伊藤がほぼすべての開発をして、すべての機能や仕様を把握している状態になっています。かつ開発チームとして苦しい時期もあり、伊藤への属人性がとても高い状態になっています。
ただ CEO でもある 伊藤 にはプロダクトオーナーとして、プロダクトの方向性やビジョンを考える部分にリソースを使ってもらいたいため、属人化の解消を急務でおこなっています。現状では僕が引き継ぎつつですが、すべてを引き継ぐと今度は僕が開発チームのスケールのボトルネックになるため、早めにチームで標準化できるように進めています。

2. 開発チームのスケール

開発したい機能がたくさんありますが、現状はそれに開発チームとして全力で取り組みきれていません。原因としては不具合や差し込みタスク、複雑なドメイン・仕様理解、コミュニケーション問題 などがあり、スケールするための基盤を整えることが急務となっています。

目的は開発ラインを増やして開発速度を上げるためなので、メンバーの採用もしていきます。「どういうメンバー・チームだとプロダクトと相性がよいのか？」「チームとして足りないスキルはなにか？」「予算は？優先順位は？」などを考えつつ採用計画を立てている最中です。

3. 他チームとの連携

小さい組織ですが、すでにチーム同士で何をしているのか？が共有できていない状況になっていました。わからないのは怖く、コミュニケーションを取るときの心理的ハードルが高くなるため、開発チームの状況やリリース内容の社内へ情報発信をなど接点を増やしています。今度はこれらを仕組み化して、本当に取りたいコミュニケーションにコストを掛けるようにしてきたいです。

次にチーム間のコミュニケーションインターフェスを整えて対人リスクを極力下げる動きをしていきます。小さい施策として #ask_dev チャンネルや プロジェクト管理ツールの issue の起票などのルール化をしています。開発チームも特定の人を設けるのではなく、チーム全体で受けることで開発チームメンバーが他チームとのコミュニケーションのきっかけを作りになればと思っています。

中長期の課題

開発チームをスケールさせてプロダクト開発を加速させたいが、今後確実に辛くなってくる課題も見えてきているので、このあたりも考えていきます。

1. 認知負荷との向き合い方

ドメインや仕様の複雑性から、開発の難易度がとても高いです。フロントエンドとバックエンドとインフラと切り分けることが難しく、すべてをうまく利用してプロダクトづくりに挑んでいます。
切り分けができない原因としては プロダクトの性質 と 新しい買い物体験の実現 によるものがあります。例えば、iPhoneのSafari拡張機能を使った新しいUX体験や、膨大な商品データの管理、多くのテナントとの連携などがありつつ、仕様の可変性を考えて設計をするとどうしても、それぞれが密結合になってしまいます。

なので フルサイクル で開発をしていますが、 フルサイクル でしか開発ができない状態になっています。そのため一人ひとりの認知負荷が高く開発効率が上がりづらい状態になっています。
ですが、 フルサイクル をやめたいわけではないです。会社の Value として Dogfooding を掲げています！プロダクト思考で開発を進めるうとやはり フルサイクル になると思いますし、今の会社のフェーズではコストを掛けてでも フルサイクル で取り組むべきだと思っています。

Value の Dogfooding

2. 肥大化したクラウドサービスのコストのスリム化

初回は開発スピードをとるためにコストの最適化の優先順位を下げてプロダクト開発をしていきました。そのため、とても高いシステムコストがかかっています… (軽く引くくらいのコストになっています)
プロダクトの性質からクローラーを使ったりデータ連携などで大量のデータを扱っているからですが、最適化できる余地はたくさんあるので中長期的に取り組んでいきます。

組織の方向性

綺麗事をならべた理想像を書きますが、理想像を口にできない組織に未来もないと思うので、これからの自分への教訓と思い書きます。
単にアウトプットや効率だけを求めるのではなく、プロダクトファーストで熱中して開発をしていきたい。

そのために Value の Be a Grande Maison を体現できるのが目標です。僕自身もプロフェッショナルが揃っているチームで働ける心地の良さを知っています。メンバーからの期待値やプレッシャー、アウトプットの責任、と負荷も大きいが全員が同じ目的に向かい生まれる仕事はとても大きなものになるし、個人として得られるものも多いと感じています。

Value の Be a Grande Maison

文化については、弊社は フルリモートでもないし、モダンな開発環境でもない、技術的負債だっておおい、でもそれらを取り組める文化や組織は、一人ひとりが改善の意識を持ち、プロダクトづくりの目標に向かう過程で必要になり生み出された結果であると思うし、それを忘れてはいけない。
享受されて当たり前ではなく、なぜフルリモートなのか？なぜモダンな開発環境が必要なのか？なぜ技術的負債を解消するのか？それらを考えるときにチームがプロダクト改善をベースに考えて作っていける文化にしたい。

まとめ

課題ベースで記事を書いたのでネガティブな感じが強いかもしれないですが、僕はそんなことはなく、今の会社の状況をポジティブに捉えています。課題が洗い出されていて、メンバーで認識を揃えたら、あとは解決をしていけばよいだけです。
ただ解決していくためには、チームにしても自分自身にしても成長は必要です。

そして、メンバーが足りないのはそうだけど、それは今のフェーズだけじゃなくずっとそう。でも仲間を増やせる会社の状況になっていることは、とても良いことだと思う。