こんにちは、うしろのこです。STORES アドベントカレンダーの1日目ということで、本当は別の内容を書く予定だったんですがリリースの都合などもあり、今回は STORES における System Design Meeting という会議体について書こうと思います。
System Design Meeting とは
System Design Meeting は、STORES 全体に関わるような技術的な課題について議論し、意思決定をする場です。ミーティングのオーナーはCTOが担当し、基本的には持ち込みで技術課題を共有して全体の方針決めから実行までの合意を取ることになります。
誰でも参加可能かつ誰でも持ち込み可能なので、ボトムアップで直接CTOやシニアマネージャーへ相談しに行けるのも大きなメリットです。現在STORES アプリケーションが様々な基盤を通して繋がっている状況で、自然と影響範囲の広い意思決定が必要なシーンが増えており、そういったものを解消するために生まれた会議体でもあります。また、その場で決めきれなくても次回へ保留したり、持ち帰ってブラッシュアップして再相談ということもできます。
横断的な判断が求められるので、各アプリケーションに関わる人が最低1人以上参加しています。また、聞いておきたいだけの人も参加できるため、多い時には20人近い人が集まることもあります。
どんなことが決まるのか
以下は実際にSystem Design Meetingを通して決まったものたちです。
セットアップ方法の統一
STORES アプリケーションをローカルで動かす場合のセットアップ方法を統一しよう、という試みです。現在はcloneしたリポジトリのrootで make setup とすることで初期化が完了し、make dev で必要な開発環境が立ち上がるようになっています。とりあえず make setup すればいいんでしょ、というのを覚えておけば普段関わらないアプリケーションを動かしたくなった時も一発で行けるので、大変楽になりました。
ステージングの定義統一と、それぞれの接続
各所のステージングと呼ばれているやつってどうあるべきなんだっけ、という疑問から、ステージングにあるべき姿を定めて準拠するようになりました。この決定によって、何が・誰がステージングに繋いで良いのかやどのようなデータが置いてあるのか/置けるのかを明確にでき、表記のブレもなくなりました。
GraphQL Schemaレジストリの作成
現在 STORES アプリケーションは相互にGraphQLによって接続されていますが、各所でスキーマの破壊的変更があった場合、その影響範囲の観測漏れがしばしば発生しており、GraphQL SchemaのSingle Source of Truthが欲しいよね、という議題から始まりました。現在は、スキーマレジストリにpushできるのはproductionで利用できるものに限るというルールの元で運用されています。
この話題は、おなじくSystem Design Meetingでの意思決定によって生まれたGraphQL 分科会という別の会議体から提出されたものです。GraphQLのように、必要であれば専門性に特化した会議体を別途設けることもあります。
まとめ
このように、STORES 全体に関わるような意思決定が必要な場合でも各々が要件と提案をまとめて持ち込むことで、最終的な合意まできるような仕組みづくりを行なっています。
System Design Meetingはすでに1年以上運営されており、ここでされた意思決定や合意が後の全社ロードマップへ影響することもあります。ハードルが高そうに見えますが、その分大きな仕事を自分で発生させるチャンスなので、積極的に利用したいものでもあります。また、現在の形式に固執せずに様々な状況を鑑みて、会議体のありかたそのものを変化させていくことも意識しています。
STORES ではより1つのアプリケーションとしてオーナーさんをサポートできるものづくりを進めるために、採用を行なっています。今回の記事で興味を持たれた方は、ぜひ応募していただけると嬉しいです。
