この記事は Ubie Engineering Advent Calendar 2023 の 16 日目の記事です。昨日はohtamanによる「言語モデルはどのようにして知識を蓄えているのか？ 関連文献の紹介 」でした。
本日の記事では、 Data Engineer 兼 Backend Engineer として働く私から、Ubieで実施されているアーキテクチャレビューがどのような効果を生んでいるかについて紹介させていただきます！
Ubie でのアーキテクチャレビュー
Ubie では、システムアーキテクチャに変更を加える際にはアーキテクチャレビューの実施をしています。
「Design Doc」と呼ばれるドキュメントを書き、それを様々な役割のメンバーにレビューしてもらいます。このドキュメントには、設計に加え、変更の背景や、考案した代替手段、残る負債などを記載します。
これにより、セキュリティやデータ活用など様々な観点での懸念を先に潰すことで手戻りを防止し、負債やリスクの適切なコントロールを促していきます。
アーキテクチャレビューを始めた背景などの詳細についてはこちらをご覧ください。
アーキテクチャレビューにより得られたもの
この取り組みがはじまってから、これまで100以上のレビューが行われています。こういった設計ドキュメントの運用はうまくいかず段々廃れていくということがあると思いますが、今のところ活発でうまくいっていそうです。
つい最近、社内でアーキテクチャレビューについて得られたものやコツを紹介する機会がありましたので、私や他メンバーが紹介したものをこちらでも紹介しようと思います。
得られたもの1: 自分では思い至らない論点が事前に発見できた
マイクロサービスを一つ作るにしても、真面目に考えるとかなり色々なことが気になります。
例えば・・
- どんなインフラ設計にするか？
- 技術選定はどうするか？
- セキュリティ面は何をどこまで気にするか？どう担保するか？
- データ保持の仕方は問題ないか？個人情報はどう扱うべきなのか？
- データは分析でも利用可能な形になっているのか？
- 他のマイクロサービスとの通信はどうするか？ 認証認可はどこまでやるか？
もちろん、技術選定のガイドラインなど型化されているものはありますが、どういった形が最適かは最終的には各サービスごとに異なるので、考える必要はあります。
また、マイクロサービスが依存するインフラの構成なども進化しますので、最新の状況や将来的にどうしていくか、というものともアラインできている必要があります。
こういったものを一人の人間がすべてを把握して完璧に作るのはなかなか難しいですが、様々な専門性を持ったメンバーにレビューしてもらうことで、様々な観点での論点がないかを担保してもらうことができます。
私自身もレビューで全く念頭においていなかった懸念点が発見された経験がありました。事前に発見できたことで、手戻りや意図しないリスクを抱えることがなくなり良かったと感じました。
得られたもの2: 書くことで、Why/What/How が研ぎ澄まされた
レビュアーとして、普段はそこまで関わらないメンバーもアサインされます。そうなると、効果的なレビューをしてもらうには、「なぜやるのか？」「なにがしたいのか？」といった基本的な部分をしっかりかつシンプルに書く必要がでてきます。
自分では意識できているつもりでも、いざ書いてみると、「この Why/What をするのに、本当にこの How はベストなのか？？」 「得たいものは本当にこれだけなんだっけ？？」 といった疑問が自分の中で湧いてくることがあります。
How も同じで、なぜその設計にしたのかの理由を書くことで、本当に妥当な How なのかを自分の中で自然と検証することになります。
得られたもの3: レビュアー・レビュイー双方に知見が溜まる
レビュイー目線では、自分が提案した How よりも良い How をレビュアーに提案してもらえることがあり、良い学習の機会となっています。
また、セキュリティやデータプライバシーについてどのような点を特に気をつければよいか、という観点も養うことができます。
レビュアー目線でも同様に、レビュイーが提案したHowから学ぶことは多いです。また、社内でどのようなシステム改修が、誰がどんな目的で、どんなスケジュール感でやるのかも把握することができるので、アラインメントも取りやすくなります。
アーキテクチャレビューの課題：質と速度のバランス
このように、学びもあり事業としても意味のあるアーキテクチャレビューですが、課題はあります。
それは 品質と速度のバランス です。
アーキテクチャレビューでは、変更の対象がシステムの主要機能でもPoCでも同じフローでレビューが行われています。上述の通り、レビューには様々な観点があるためステークホルダーが増えてしまい時間がかかります。
本来、どのくらい慎重にレビューすべきかはその変更の影響度合いにより判断されるべきですが、どのようなレビューでも基本的には同じ温度感で行われてしまっていました。これにより、特にPoCのように影響度合いが低いが速度が大事なケースにおいて難しい状況になっていました。
・・・と、このような課題はつい先週くらいまではあったのですが、社内でこれについて声があがり、その３日後くらいには解決の道筋が立ってきました。速度がすごい。
この話題についての詳細は、昨日発信された以下記事の後半「3. チーム間連携が大事だと気付かされる期(200人〜)」をご覧ください！
レビュイーとしての工夫
レビューを意味のあるものにすると同時に、スムーズに行うことが重要です。そのための工夫をいくつか紹介します。
背景と課題を明瞭に書く
アーキテクチャレビューというと、どういう設計をするかというHowに目が向きがちですが、意味のあるレビューを行うにはその背景や課題を理解することが重要です。
レビュアーとレビュイーでここの認識がズレていると議論がなかなか進まなかったり、重要な論点をレビュアーが見落としたりしてしまいます。
データ構造に関する記述は詳細に書く
DBなどに永続化されるデータの構造はあとで変更するのが難しいです。レビューにおいて想定しているデータの構造を明瞭に書くことで、あとでデータスキーマの変更やデータ移行といった大変なタスクを行うことを防ぐことができます。
特にUbieの事業はデータの重要度が非常に高いので、ここをしっかりレビューしておくことには意味があります。
以上、Ubieでのアーキテクチャレビューの紹介でした。
お約束ですが、Ubieで一緒に、お互いを高め合いながら最適なアーキテクチャを作っていきたいエンジニアを募集しています！
Discussion