[2022年版] トドケールの開発組織について
こんにちは。@hayata-yamamotoです。
この記事は、トドケールのプロダクトや開発組織、メンバーにご興味を持ってくれた方に向けて、我々がどんな技術をどんな風に用いて、どんな組織でなんのために開発しているのかをまとめたものになります。なお、2021 年夏に公開した以下の記事の続編です。
開発方針 | なぜ・なんのために開発しているか
ミッションの実現のためです。
が、トドケールのミッションです。 弊社では、ミッションのために価値規範と行動指針を設定しています。
トドケールの価値規範
- 学び合うこと Feedback & Coaching
- 認め合うこと Diversity
- 調べること Study & Analytics
- 素直であること Honesty
トドケールの行動指針
- リーダーになろう Everyone is a leader
- 境界線を超えよう Go beyond boarders
- 最後までやりきろう Never surrender
- 前に進もう Respect baby steps
- 挑戦しよう Stretch yourself
- 協力しよう Share success
- 数字を探そう Show me the numbers
- 顧客と話そう Customer centric
各メンバーが価値規範、行動指針に見合う行動を起こしやすくするため、プロダクト組織の形態やあり方を日々模索しています。特に、スタートアップの変わりゆく市場環境、顧客ニーズに合わせて進化できる組織を目指しています。
そんな我々は現在、以下の点を重視してプロダクト開発を進めています。
採用技術・ツール | 何を開発してるか・どこで開発しているか
全容を可視化したものが ↓ です。
Notion, GitHub, Slack を全ての開発で使用しています。また、全アプリケーションのエラー監視を Sentry で行っています。Sentry のリリース機能を用いて、どのリリースでどれくらいエラーが発生したか、パフォーマンスはどのように変化したかを管理できるようにしています。
以降では、クライアントサイドとサーバーサイドに分けて、詳細を説明します。
クライアントサイド
私の専門性はあまりクライアントサイドにはなく、関わってくれているメンバーを頼りにしながらさまざまな施策を行っています。クライアントサイドはほぼ TypeScript で実装されるようになりました。昨年の執筆時点ではまだ JavaScript の方が多かったのですが、メンバーが頑張って書き直してくれたこともあり、TypeScript 化が進んできています。
ウェブアプリ
ウェブアプリは、Amplify で提供されています。弊社は、アプリケーションをモノレポで運用しており、GitHub Actions 上でバックエンド → フロントエンドの順番で自動デプロイされるようになっています。
UI は MUI をベースに作成しています。MUI で作成したコンポーネントを Storybook 上でホストし、Chromatic にデプロイすることで Visual Regression Test や Interaction Test を行う構成となっています。
Figma, Storybook, Chromatic の使い分けは？
Figma は初期のプロトタイプ、ワイヤーフレーム作成用途で使っています
Storybook, Chromatic は、プロトタイプのブラッシュアップから完成までで使用します。
原則的に、Figma で完成系の5-60% まで確定させて、その後 Storybook, Chromatic を用いてプロトタイプを完成させています。
以前は、 Figma でプロトタイプを作って、フロントエンドをコーディングしてとやっていました。が、デザインで「ワイヤー」と「顧客に提供する体験」を設計した後は、実装してしまった方がユーザーヒアリングの精度も、実装の速度も早くなることが分かりました。弊社は今後もこの開発体制を続けていく方針です。
モバイルアプリ
モバイルアプリは、React Native で提供されており、Expo でビルドされ iOS, Android 版が配信されています。UI は Native Baseで作成されています。開発の際は、ローカルで Expo Go を用いて開発を行ったのち、PR を作成する流れです。PR を作成したら、expo-github-actionsで Expo Publish が行われ、Expo Go 用の QR コードがコメントされます。
develop など所定のブランチにマージされたら、Expo にビルドが作成され TestFlight 等で内部テストを実施する流れになっています。現在は、Expo の Classic Build を利用していますが、EAS Build に移行すべく対応を実施しています。
React Native も Storybook 対応する？
検討はしていますが、今はまだ対応までは計画していません。
サーバーサイド
アプリケーション
API サーバーを FastAPI で構築し、AWS Lambda 上に Serverless Framework
と Mangum を用いてデプロイしています。FastAPI と Mangum については以下の記事も読んでいただけますと嬉しいです。
サーバーサイドは現在、 GraphQL で提供していた API を REST に置き換え、各種テストを充実化することで品質保証を進めています。バックエンドの E2E テストも予定しています。リリース判定時の全体テストではパートナー企業様とも連携し、QA を実施したのちリリースを行う体制を構築していっており、様々な角度からプロダクト品質を保証しています。
なぜ GraphQL から REST に?
弊社のバックエンドは、AppSync を用いた GraphQL で提供されていました。GraphQL は技術としては、優れた側面が多いと思う一方で AppSync のバックエンドが大きくなっていくことで不都合もいくつか発生しました。分かりやすい例で言うと、単体テストがしにくい・できないところです。
社内で検討をした結果、REST に一旦バックエンドの API をうつし、フロントエンド側で BFF 層が必要になれば nest.js などで GraphQL 対応する方が分かりやすいし、使いやすいだろうと言う結論に至った次第です。
インフラ
Terraform で構成管理を行い、Terraform Cloud でプロビジョニングを行っています。変わったことは特にしてませんが、module などを活用しながら、管理しないといけない項目を減らしています。プロダクション用のブランチに変更がマージされたら、 plan が実行され、 approve を実行すると本番環境に変更が適用されます。本番・ステージング環境に関しては、ローカル環境からデプロイ自体ができないのでセキュアに運用することができています。
データ基盤は？
データ基盤に関しては、Glue, Athena, Redash の構成をとっています。毎日、Glue Job で DynamoDB からデータを取得しています。Athena からデータカタログ経由でクエリを発行しデータを収集する流れです。Redash は結果を可視化しやすくなるように社内に提供しています。
開発プロセス・体制 | どんなふうに開発しているか・誰が開発しているか
開発プロセス
この半年で、開発プロセスが大きく変わりました。
特に大きな変化をもたらしたのは Notion です。 Notion の公式が出している Notion によるプロジェクト管理システムの記事[1] が非常に有能で、弊社のプロダクトチームはこのベストプラクティスに乗っかる形でタスク管理を行っています。 具体的には、顧客から出た要望や不具合報告から、プロトタイピング、開発タスク、QA・CS のサポートタスクなど、プロダクト開発に関わる全てのタスクを一つのデータベースに集めています。
Atlassian 製品を使わなくなった理由は？
以前は、 Jira, Confluence, Bitbucket を使って開発を行っていました。これらのツールは開発用ツールとしては有益でした。ただ、ビジネスサイドが使いにくそうにしていたことも事実でした。顧客の声を一番持っている彼らがフィードバックしにくいツールを採用し続けることは全体としては不利益と考えるようになり、Jira, Confluence を Notion に移行しました。
Bitbucket に関しては、エンジニアメンバーからも「使いにくい」と声が上がってしまっており、全員が使い慣れた GitHub に移行することに決定しました。
開発体制
トドケールの行動指針の一つである、境界線を超えよう Go beyond boarders と 顧客と話そう Customer centric を実現しやすい組織にするため、この半年で開発体制を大きく変えました。
オフショアからの脱却・自社開発チーム組成
前回の記事を執筆した 2021 年 8 月時点では、日本側のコアエンジニアは私一人でした。業務委託で何名か日本側でも参加してくださっていましたが、オフショアの開発組織も存在しており、稼働量の関係で私は、彼らと日々英語でやりとりしながら開発を行っていました。
私も代表も英語でのやりとりに抵抗はなかったものの、プロダクトが成長していくことやユーザーの声をもっとプロダクトに反映させていくことを考えると、言語の壁は思った以上に大きいことがわかってきました。どうしても、日本語から英語に翻訳する際に伝わるべき温度感と情報量が落ちてしまう感覚があったことに加えて、私や代表など英語を話せるメンバーにどうしても負荷が寄り、特に私に関しては必要なコミュニケーションをとっていたら一日が終わるということが何度かありました。
それらを踏まえ、以下のような段階でプロダクトチームを組成し直すことを決定し、実行しました。そして、私がトドケールに昨年春から関与し初めて、足掛け 1 年かけて、日本側にプロダクトチームを自社で持つことができました。日本側に開発組織を持った後に、行った施策が、次節以降でお話しする二つの体制変更です。
UX デザイナーが、プロトタイピングと UI 実装まで一貫して対応する体制に
弊社は今、UX デザイナー という役割にデザインとフロントエンドの開発を凝縮し、ワイヤー作成・プロトタイピング・UI 実装まで一貫して対応できる体制にしています。このロールの責務は以下のように定義しています。
責務を果たすために必要なことであれば、領域問わずやっていいし、やることが求められる環境となっています。Figma でデザイン作っているだけではダメで、時にフロントエンドの実装をしたり、ユーザーヒアリングに同席し生の声をとってくることが求められています。
なぜそのような体制に?
弊社も元々は、デザイナー・フロントエンドエンジニア・バックエンドエンジニアと分けていました。しかし、限られた人員の中で開発を行っていくうち、UIUX に関しては、デザインと実装を合わせた方が効率的だと考えるようになりました。
実際、デザイナーは「フロント側でどう実装されているんだろう？このデザインは実装上、都合がいいのかな？」と思うようになり、フロントエンドエンジニアの方は「このコンポーネントをユーザーが触った時、どんなふうにインタラクションを作ったらいいんだろう？」と感じ、相互のコミュニケーションが増加していました。 しかし、コミュニケーションが増えた分、開発の効率が上がったか？と言われると、No でした。主にすり合わせのコミュニケーションがメインで、生産性がそれによって高まっているようには見えなかったのです。
また、チームとしても、実装しながら試行錯誤した方が手に馴染むようでした。雰囲気はこんな感じです。
ワイヤーフレームで 5,60% くらいデザインができていたら、詳細詰めながらフロントエンドを実装してしまった方が早い。顧客の声を獲得するにもそちらの方がリアルなフィードバックがもらえるから、結局効率的なのでは？
副次的にですが、プロトタイプで UI 実装まで行えるため、どんなデータが、どんな形式でどういう風に取得したいのか をサーバーサイドに明確に伝えることができるようになりました。デザイン → インターフェース設計 → フロント・バックエンド実装としていた以前の開発フローでは、定義したインターフェースに考慮漏れがあり、バックエンドの作業に手戻りが発生したり、クライアントサイドがデータ整形を頑張って実装が複雑化すると言った事象が発生していました。この問題も合わせて解決されています。
プロダクトの戦略を理解し、エンジニアが中長期的な視点で問題解決を行う体制に
エンジニアとデザイナーの役割は明確に以下のような切り分けをしています。
では、エンジニアはどんな責務を担うのか？と思われたかもしれません。弊社のエンジニアの役割は2 つあります。
試行錯誤をする際は例外を除き、特にサーバーサイドに関しては、なるべく一度の開発で拡張性の高い機能を提供することが望ましいと私は考えています。そう考える理由は以下です。
- 作った機能を資産として次の開発に活かすため
- データの不整合や不具合を防止するため（QA の資産を残すため）
- 貴重なエンジニアリソースを効率的に活用し開発効率をあげるため
その場その場で、必要な分の開発をしていくことは短期的に見れば良い面もあるものの、見方を変えると追加の開発を先延ばしにする選択とも言えます。意図なく、「求められているものだけ作ればいいでしょ？」と意思決定をしてしまうと、後の開発で負債返済に思ったよりも追加の工数がかかってしまったりしてしまいます。
逆に、ただ闇雲に拡張性の高い API や機能を提供したところで、正直あまり旨味がありません。むしろ、作らなくても良いものを作ってしまうオーバーエンジニアリングの方が懸念が大きくなってしまいます。エンジニアをやっているみなさんもやりたくないタイプの仕事なのではないでしょうか？
この匙加減をうまく行うことがチーム全体のパフォーマンスを上げることにつながり、ひいてはプロダクト開発全体を効率的に進めていくことにつながると考えています。負債を負うべきところは意図を持って負い、追わなくても良いところは資産として今後も価値を持つように、賞味期限の長い設計を行うことが重要となります。この匙加減を実現するのに必要なのが、プロダクトの戦略を含めた中長期的なプロダクトに対する視点と理解です。
それゆえ、我々はエンジニアにもプロダクトの戦略を理解し、今後の展望を踏まえた上で捨てるべき拡張性は捨て、残すべき拡張性は残す意思決定をするようにしています。プロダクトの戦略としては、我々がシステムを通してどんな価値を誰に提供しており、今後どのような価値提供をしていこうと考えているのかを理解することが重要です。具体的には、ロードマップ、顧客ペルソナ、顧客のユースケースなどです。
これによって、今少し開発工数が増えたとしても、今後の開発がスピーディに行える施策が打てると考えています。先の予定が見えているから、早めに仕込み・準備ができる開発はたくさんあります。逆に、その場限りで作った機能を拡張することは難しい。ゆえに、点と点を繋げるためには、短期的な視点だけでなく中長期的な視点をエンジニアも持ち、逆算しながらシステムを作っていくことが求められています。
また、リファクタリングやリ・アーキテクチャを中心に、必要と考えられればいつでも実施可能です。実際に、私も高頻度でリファクタリングを入れてます。加えて、最近では少しずつですが、モデリングの手法を取り入れドメイン駆動開発（DDD）でプロダクトが開発できるように進めていこうとしています。
おわりに
トドケールでは、一緒に働いてくれるエンジニアを募集しています!ここまで読んでくれて、気になったところがある人は是非カジュアルにお話ししましょう！
Discussion
企業がどういう意図を持って製品開発をしているのかが、かなり分かりやすくまとめられていて、大変参考になりました
コメントありがとうございます。毎年、形式は問わず現状の意図がある程度わかるように記事を書かせてもらっています！