はじめに
こんにちは！お会計チームの yamakazu (@yamarkz) です。
10Xでは4月から新しい期が始まるため、最近はバタバタしています。新しい組織や取り組みが始まってきていて、今年度はこれまでとはまた違った大きな変化が生まれそうで楽しみです。
さてそんな今回は期の変わり目ということもあり、
節目として「Stailerの開発を支える取り組み」を紹介します。
取り組みはプロダクトの規模や性質、組織構造、願望によって変わる唯一無二の存在で、各社様々な工夫を凝らして、より良い開発体験を追求していると思います。
自分たちもその時々の状況に合わせて、最適なやり方に変えて開発してきました。
今後も取り組み自体は変わっていくと思いますが、2023春時点での取り組み状況 (仕組み / ルール / 文化 / ツール) をスナップショットとして取り上げみようと思います。
前提
- プロダクトはエンタープライズ向けのマルチテナントEC SaaS
- SoR / SoE どちらの側面も併せ持ち複雑性が非常に高い
- 新規開発と運用改善どちらも並列して進む開発状況
- 開発関係者40名弱の規模
取り組み
$. Develop
1. DesignDoc
開発ではDesignDocを書くことが推奨されています。
DesignDocは基本フォーマットは用意されていますが、厳格に定められた形式はありません。
開発者自身の考えや問題特性を考慮して、解決に向かうスタンスや論点を洗い出し、解決手段のトレードオフなどが記述され、検討議論の場で建設的に話を進めるために書きます。
2. Architecture Decision Records
影響範囲が大きく、中長期の開発にも影響を及ぼしうる技術意思決定ではADRを書くことが推奨されています。
これまでは大きめの技術意思決定でも口頭で共有し、阿吽の呼吸で開発を進めてきました。
しかし今では組織も大きくなり、共通認識が取りづらくなっているのと、中長期を見据えた安定した開発が求められるため、可能な限り人に依存しない形での情報や意思決定背景の共有が望ましく、ADRはその手段としては最適であると判断しています。
よくDesignDocとの違いに混乱される方もいますが、DesignDocは「最終成果に対する中間成果物、都度使い捨てられるドキュメントである」のに対し、ADRは「最終成果物として中長期で参照され続けるドキュメントである」という違いで棲み分ける解釈で扱っています。
ADRはアーキテクチャ改善の文脈の「アーキテクチャの進化を支える適応度関数の活用」でも紹介していますので、こちらも参考に。
3. Proof of Concept
実装の不確実性が高い場合は、Proof of Conceptを実施することが推奨されています。
自分たちのPoCにはお作法などはなく、各々が自由に進めています。
実装方針に自信が持てない場合や、実装内容を元に建設的な議論 (フィードバック&修正) を行いたい場合に取り組むと、その効果を感じます。
4. Test Style
サーバーサイドのテストコードにはテストのコーディングスタイルが定められています。
基本はテストスタイルに従ってテストを記述することが求められ、誤った記述である場合には後述するStailer Lintでフィードバックがかかるため、成果が一定水準の品質で守られています。
標準を定めたことによって、開発者がテストを書く際に迷うことや考えることが減り、テストをレビューするQA Teamの認知負荷が減らせました。
「10Xのテストコード規約」でも紹介していますので、こちらも参考に。
5. Dart Documentation
コードにドキュメントコメントを書くことが推奨されています。
コードコメントの記述自体が大きな物議を呼ぶ時代もありましたが、自分たちは明確に "プロダクト開発の認知負荷を下げ、当たり前品質を中長期的に守っていくためには必要な取り組みだ" と考え、書いて永続的にメンテナンスしていくスタンスを取っています。
ドキュメントはジェネレーターによってWebページで確認できるようになり、QA Teamによるテスト設計時に参照されたりしています。
6. Stailer Lint
Custom Lint Ruleを活用して、独自のコーディング規約を定めています。
標準で整備されているLint Ruleでも成果品質の標準化は一定できていましたが、より踏み込んで整備を進めなければ自分たちの規模 (プロダクト & 組織) では、品質を守り続けるのは難しいと感じたことをきっかけに整備が進められてきました。
サーバーとクライアントは別で管理されていますが、将来的には統合も検討されています。
「10xな開発を支えるCustom Lint Rule - スケーラブルで効率的な開発を目指して」でも紹介していますので、こちらも参考に。
$. DevOps
7. Branch Deploy
GitHubのブランチごとにサーバーの開発環境を立ち上げることができます。
開発者が10名規模になり、並列で中規模の機能開発が進み始めた頃から導入されましたが、非常に便利です。
GitHub Actionsからブランチを指定すれば数分で検証環境が作られます。
8. Release Train
リリーストレインと呼ばれる、定期リリースの仕組みがあります。11時と14時に出発(リリース)します。
出発までの間にPRがマージされれば、自動でリリースPRが作られ、リリース担当者が最終確認を行い、マージすれば出発します。
複数名+複数PRのリリース希望がある中で、交通整理がうまくなされるので、リリース作業者の負荷が低減(慣れればほぼ無)されるので、良い仕組みです。
ちなみにリリースはインシデント発生を避けるため休日前は非推奨になっており、月火水あたりに集中してリリースされる特徴があります。
9. GitHub Actions
単発のデータマイグレーションやリカバリースクリプトの実行にはGitHub Actionsを活用しています。一般的な使い方しかしていないので、特筆すべき点はありません。
10. Checker
(センシティブ情報を含むため、画像なし)
能動的に状態を確認するために、Checkerを設けています。
チェック内容はSlackに定期通知されるため、関係者は状態異常にすぐに気づくことができます。
11. Monitoring & Alert
(センシティブ情報を含むため、画像なし)
受動的に状態を確認するため、MonitoringとAlertを設定しています。
モニタリングはDatadogやSentryなど、ユースケースに応じて最適なツールを選んでいます。
アラートにはPagerDutyを活用しており、ドメインやレイヤーによって対応担当グループを設けて輪番制で均等に負荷分散しながら運用を行っています。
12. Incident Bot
インシデント発生からインシデント収束までをサポートしてくれるIncident Botがいます。
雰囲気でインシデント対応をしていた時代 (10名規模の頃) もありました。
今ではIncident Botの指示に従って動けば、新しいメンバーでも能動的にインシデント対応に向かえる状態が作れています。
$. Product Management
13. Specification Document
プロダクトマネジメントでは仕様書を書くことが必須化されています。
ここで書かれるドキュメントは使い捨てではなく、機能が存続する限り、永続的に管理され続けるドキュメントです。
巨大なプロダクトの仕様を網羅して、非開発者向けにも説明可能な状態を作っています。
「仕様書管理が大変だ」という切り口から、"ドキュメント書くのか論争" がソーシャルでも何度か生まれていますが、10Xでは中長期目線でプロダクトを育てていくという覚悟から書いてメンテナンスを続けていくスタンスをとっています。
14. Application Roadmap
Stailerのプロダクトが中長期的にどのように進化していくのかを、ロードマップという形で示し、管理されています。
ロードマップを軸に、社内での取り組みの範囲やチーム内でのゴールを設定したり。パートナーに向けて、どういった機能をいつの時期にリリースし、どういった事業インパクトを産んでいくのか、またそのインパクトを最大化するためのフィードバックを貰いにいくための、議論のたたき台として使われています。
pmconfでuraさんが登壇して運用を紹介しているので、こちらも参考に。
15. Development Lifecycle
プロダクト開発ライフサイクルとよばれる形式的な開発フローが定められています。
一連の形式化された流れに従って開発を進めることで、高い品質のプロダクトを早くリリースできる状態を作ることを目指して定義されました。
ライフサイクルはステージと成果物、オーナーシップの所在が記載されており、もしプロダクトになんらか問題が生じた場合には、どの時点の取り組みを改善するべきかを建設的に議論できる状態になるため、長く運用を続ければ続けるほど価値が上がる構造になります。
16. Design System
プロダクトデザインではデザインシステムを活用しています。
プロダクトライン (お客様App, スタッフApp, 管理画面) ごとにUIパターンやコンポーネントが定義されており、デザインの一貫性や変更容易性が守られています。定義された内容をそのまま踏襲する形でプロダクトコード上ではコンポーネントが定義されており、開発者としてもデザインチームからのフィードバックを受けてUIの変更が容易に行える状態が作られています。
17. Test Design Doc
QA Teamによる自動テストの設計は、Test Design Docとして書かれます。
テストコードの設計は基本は機能を実装する開発者に委ねられていますが、金銭や個人情報といった完全性や秘匿性が求められる領域ではQA Teamにオーナーシップを持ってもらい、厳密なテスト定義を行なってもらっています。
18. QA Process
リリースの前にはQA Processをパスすることが求められます。
QA ProcessはQA Team向けのテスト実施依頼のチケットを切り、テストの設計、実施、確認完了のステップを踏んでリリースに向かいます。
QA Processを支えるチームの変化は「品質管理部の体制変化の1年間：リリースに対しての戦略と今後の展望」でも紹介していますので、こちらも参考に。
19. Genba & Analytics & Insight
10Xのプロダクト開発は現場で見つかる事実と分析で見つかる仮説、そしてどちらにも通じる深い洞察を大事にしています。
現場にはBizDevチームを中心に、GrowthやProduct方面のメンバーも足を運んで一次情報を集め、分析ではGrowthチームを中心に大胆な仮説を検証して、開発改善に活かしています。
1つ新たに紹介すると、社内には #insight と呼ばれるSlackチャンネルで、知見が共有されています。誰でも自由にインサイト情報に触れることができて、とても面白いです。
Productチームのメンバーが現場に足を運んで改善に取り組む話は「10Xのデザイナーが 「机から離れてデザインするのが大事」と痛感した理由」でも紹介していますので、こちらも参考に。
$. Team
20. Domain Development Team
2023/04からチーム構成が新たになりました。
ドメインごとにチームを編成しプロダクト開発を進めています。
これまでも事業状況に応じて何度かチーム形態を変えてきており、今回はドメインを中心として構成される形になりました。
えいやっで移行したわけではなく、検証期間と準備期間を経ての移行しており、スムーズに進んでいる手応えを感じます。
21. Team Offsite
定期的にチームや部門単位で集まってチームビルディングを行う取り組みがあります。
実際に会って話した方が打ち解けやすく、カジュアルに質問や相談ができるため、会うことも積極的に推奨されています。
エンジニアリング本部全体でのオフサイトは「10X 開発オフサイトはじめました」でも紹介していますので、こちらも参考に。
最後に
Stailerの開発を支える取り組みを21個紹介してきました。
自分が入社頃はここに挙げた内の2~3個の取り組みしか揃っておらず、ずいぶん充実してきたな〜と、書きながら思いました。
今の自分たちの前提では、ここで挙げた整備状況だとそれなりのスループットを出し続けられているというのは証明できています。
今後も取り組みに磨きをかけて、より良いプロダクトをお客様とパートナーに届けられるようにやっていきます。💪
開発基盤の運用と改善に興味がある方はぜひお話ししましょう。
