この記事は🎄10X プロダクトアドベントカレンダー2023の22日目の記事です。
21日目の昨日はaineさんによる「プロダクトマネージャーになった自分が大事にしていること」でした。
こんにちは。エンジニアリングマネージャーの坂本(kazu0620)です。
この記事では10XがStailerの開発に取り入れて来た仕組みやルールの中で、「もしも過去に帰れるならこれは早い段階で取り入れたい」と私個人が特に思ったものたちを紹介したいと思います。
過去に帰ることはできませんが、我々と同じようにプロダクト開発を行っている組織の方の参考になれば幸いです。
Stailer最初期の開発と現在
Stailerの開発が始まったは2019年末のことです。私が10Xに入社しStailerの開発に関わり始めた2020年3月の時点では、ソフトウェアエンジニアの数は6名でした。当時はプロダクトマネジメントはCTOであるishkawaが担当し、まだデザイナーや品質管理に携わるメンバーはいない、という状況でした。
ここから3年半で、開発組織は成長し、今ではプロダクト開発に携わるメンバーの数は50名を超えています。これまでの過程で10Xの開発組織は、Stailerのエンドユーザーやパートナーに早く安全に価値を届けるための制約やプロセスを、数多く加えて来ました。下記は特に印象に残っているものを記載してますが、他にも多くの取り組みや試行錯誤があります。
| 時期 | 導入したもの |
|---|---|
| 2021年4月 | コードレビューの必須化 |
| 2021年11月 | Desing Docの運用開始 |
| 2021年12月 | 開発チームの組成 |
| 2022年 7月 | シフトレフト化によるQAプロセスの改善 |
| 2022年8月 | Stailer開発ライフサイクルの策定 |
| 2022年10月 | アプリケーション仕様書の確立 |
| 2023年1月 | ADRの運用開始 |
| 2023年4月 | ドメインベースの開発体制への移行 |
| 2023年5月 | 技術的意思決定会の開始 |
| 2023年7月 | SLOの運用開始 |
ちなみに、開発初期からこれら全てを揃えて開発を進めるべきか、というと私はNoだと考えています。事業もプロダクトも不確かな状態で、初期から制約やプロセスを増やしすぎると結局事業自体が立ち上がらない、というリスクのほうが大きいと考えているからです。特にプロダクト開発の最初期はスクラップアンドビルドを繰り返す必要があり、あまりに早い段階で制約を設けすぎると、事業やプロダクトの生存可能性をかえって下げてしまうというケースもあるのではないかと思います。
プロダクトの複雑さや守るべきものを守れなかったときのリスク度合いなど、さまざまな要素に応じて徐々にプロセスや制約を追加していくべきだと思います。
ただ、それにしてもこれは早く取り入れておけばよかった、もう一度過去に戻れるなら早い段階から導入してみたい、というものもいくつか存在しています。本日はそうしたものを3つ、紹介したいと思います。
Design Docの導入
Design Docは、システム設計のデザインを記述するものです。永続的にメンテナンスするもの、というよりは、実装に入る前に設計を議論しレビューするためのツールとして10Xでは利用しています。フォーマットはデザインごとに任意ではありますが、以下のような項目を記載することが多いです。
- 目的
- Goals
- Non Goals
- 選択肢とPros / Cons
- アーキテクチャ
- テストやモニタリング、リリースのプラン
Design Docは2021年11月に導入したのでStailerの開発が始まってから2年を経て導入した、ということになります。その2年間の間にも、10Xでは重要なシステムの意思決定を数多く行なって来ました。
Design Doc導入前も設計上気にかかる部分があれば他のメンバーと相談したり、レビューを依頼したり、といったことはしていました。
しかし、やはりフローやフォーマットが正式に存在していることによる敷居の低さ、「これくらい複雑な設計ならDesign Doc書いた方が良いな」という心理が働くことから、Design Doc導入前に比べると設計に関する議論やレビューは盛んになっています。
また、設計に関する議論が実装前・リリース前に行われることにより、コードレビューで大きな手直しが入ることや、ベストではない設計でリリースしてしまったがゆえに負債となってしまう、といったようなことを防ぐことができていると感じます。
こうした恩恵を考えるとDesign Docは、任意かつフォーマットが軽量なものでもよいので、開発初期から取り入れていてもよかったな、と今振り返れば思えます。
ADRの導入
ADR（Architecture Decision Records）は、アーキテクチャや開発プラクティスに関する意思決定の内容や背景を記録し共有するためのドキュメントです。Design Docは設計を考える上での議論に使うフロー型のドキュメントであるのに対し、ADRは決定事項をメンテナンスし続けるストック型のドキュメントになります。
ADRは、以下のようなフォーマットに沿って記載します。
- 意思決定のコンテキスト
- 決定内容
- 影響
- コンプライアンス(決定をどう遵守するかの方針)
ADRの効用として、チームにとって何が標準であるのか・なぜその標準が存在しなければいけないのかが明らかになる、というものがあります。後からチームに参画するメンバーのことを考えると、これは非常に大きな恩恵があります。
加えて私は、標準・ルールを適用したり変更するためのプロトコルが明確である、という恩恵も同じくらいあると感じています。現在の開発スタイルだったりアーキテクチャに怪しさを感じていたり危機感を持っていても、それを変更するためのプロトコルが明確でない場合、どうしても対応が後手に回るものです。
近い話で、ADR導入の少しあとで始めた「技術的意思決定会」という取り組みも似た効力を発揮しています。これは、技術的な意思決定権を持ったCTOであるishkawaがオーナーとなり、技術的な相談や意思決定を行う、という会議体です。毎週開催され、メンバーが意思決定したいこと・意思決定まではいかないけど相談したいトピックを登録しておき、関心あるメンバーとCTOが議論し、技術的な意思決定をします。
ここでの議論内容がADRとして起票される、という流れになることが最近は多いです。いきなりADRを起票しても良いのですが、事前に同期的に会話可能な場所で相談と合意を経ることができることから、技術的な意思決定に関わる敷居を下げられているのではないかと思います。
このように、決定があとから閲覧可能なものとして残っているだけでなく、アーキテクチャや技術的な方針をどこで相談しどう適用すればよいのかが明らかである、プロトコルが定まっている、というが非常に重要なことではないかと思います。
ADRを導入したのは2023年の1月なので、Stailerの開発開始から約2年と少し後ということになります。これまでの間も技術的な意思決定は10Xの中で多くなされてきましたが、もっと早くこうした仕組みがあれば、早く意思決定を行い良い変化をプロダクトにもたらすことができた可能性はあるな、と思います。これらも少なくとも開発開始から1年後くらいの段階では、軽量でも良いので取り入れていてもよかったのではないかと思います。
シフトレフト化によるQAプロセスの改善
これは、品質管理部の仲間たちが推し勧めてくれた大きな成果です。従来、Stailerの開発はで完成した仕様書をもとに品質管理チームのメンバーがテスト設計を作り、QAプロセスを実施する、という流れでした。
これを2022年7月ごろから、仕様書が確定する前に品質管理のメンバーが仕様書をレビューする、仕様書を作る前の時点から品質管理のメンバーが関わりフィードバックする、といったように徐々にシフトレフト(早期に問題発見する）という動きが進みました。
現在では品質管理チームのメンバーは開発チームの中に入って、仕様が定まる前の段階から仕様がどうあるべきかについてプロダクトマネージャーやソフトウェアエンジニア、デザイナーと一緒に議論を進めています。
これにより、リリース前のQAプロセスで発見されるバグ・あるいはリリース後に発生するインシデントの数を削減ことができました。リリースされたあとよりもリリースする前に問題を発見する方が、開発が完了したあとよりも開発が開始する前に問題を発見する方が、対応にかかるコストはずっと低くなります。
これは、先に挙げたDesing DocもADRも、ある種同じ話であるとも言えます。工程を悪戯に増やすのはプロダクトが立ち上がったばかりの状態では悪手とも思われますが、できるだけ早い工程で問題を発見し、改善するための手を打つことは、小さな組織でもスピードを上げることにつながります。
そういう意味で、これらの3つは仮に過去に戻れるならばまだプロダクトや開発組織の規模がより小さいときから導入したいな、と個人的には思えるものです。
早くやりすぎても成功しなかったかもな、と思うもの
一方で良い取り組みではあったものの、もっと早いタイミングでやったとしてもうまくいかなかっただろうな、と思うものもあるので、補足として紹介しておきます。それは、ドメインベースの開発体制への移行です。これはドメイン（業務）ごとにチームを分割するという組織設計上の試みで、2022年12月から検討を開始し2023年4月に実施しました。
振り返ればStailerというシステムが扱う業務の領域が幅広いこともあり、扱っている業務とシステムの解像度が高まり、朧げにでもどういうドメインの切り方が存在しているのかが明らかになって来たのが2022年半ばのことでした。
Stailerの開発を開始した2019年時点ではStailerの扱う業務の全体像を見通すことは非常に困難だったし、開発開始から1年が経過したタイミングでもまだプロダクトも事業も大きく変化している最中で同様、業務の全体像や業務ごとの関連を見通すのは困難な状況でした。
あまりに早い段階でこうしたチーム構造をとることや、それに応じてドメイン理解が浅い状態でチームごとにモジュール化を進めることは、おそらく混乱や手戻りを生んだだろうなと個人的には思います。
この移行の意思決定を行なった時点では、チームの認知負荷は増大しており、またコードのオーナーシップも持ちづらい状態ではあったのでギリギリとも言えますが、前述の理由から例えばこれをあまりに早くやったとしてもあまり幸せな結果にはならなかったのではないかと思います。
終わりに
ここまで読んでいただき、ありがとうございました。開発に関して必要となる制約やプロセスは、事業の状況やチーム状況に応じて変わるもので、少なければいいというものでも多ければ良いというものでもないのが難しいところだなと思います。
10Xでもこれからまた状況が変わるにつれて、無くなる制約もあれば加わる制約もあると思います。この記事を読んで、自身のプロダクトや組織にはいつどんな制約やプロセスを設けると良いかな、と思いを馳せていただければ幸いです。
