この記事は Enginnering Manager Advent Calendar その２の1日目の記事です。（大遅刻しました）
こんにちは。@chaspy です。10月からスタディサプリ小中高*1プロダクト開発部の部長をしています。
本記事では、我々の組織で取り組んでいる技術戦略の現状と今後についてお伝えします。
技術戦略とは何か
ざっくりいうと、事業計画に対して、技術投資をどこにするのか、しないか、です。"技術"投資と言っても範囲は広く、開発部の正社員/パートナーの人件費をどう配分するのか、増やすのか減らすのか、から、開発案件として何を取り組むのか（技術的負債解消を含む）、また、クラウド/SaaSのコスト方針までさまざまです。
事業計画は半年に1度策定され*2、プロダクトマネージャ、開発、コンテンツディレクター、マーケター、事業企画、FP&A*3 他いろんな職種の方と協力して計画を策定します。その中で、開発投資額の計画も求められますし、直近1年について具体的にどういう案件を行うのかを計画します。
スタディサプリ小中高の技術戦略
現在実行している技術戦略、およびその体制について説明します。
開発比率適正化
2年ほど前に、開発比率適正化として、開発内容を新規・エンハンス・負債解消と分類した上で、この比率を 1:1:1 にすることを事業開発を行うプロダクトマネージャと合意しました。これは事業を伸ばしていく上でどうしても新規偏重になってしまい、負債解消に手が回らない状況があったためです。
現状、新規とエンハンスの割合はプロダクトマネージャに一任していますが、負債解消については毎年一定の予算を確保し、開発部として必要な案件を実施しています。
課題発見と改善サイクルの確立
技術的負債を解消するためには、我々がシステムを自己診断できる能力と、診断した上で負債を評価し、来期計画に繋げる仕組みが必要です。
我々は2021年、技術戦略を完全なトップダウンで行うのではなく、自己診断能力と課題発見・管理をボトムアップベースで行うことに決めました。全員兼務の技術戦略グループが存在し、横断 / フロントエンド / DevOps という3つのワーキンググループでの活動を続けています。
以下がそれぞれのワーキンググループとその周辺の役割を示した図です。
それぞれのワーキンググループの役割を説明します。
- 横断:
- フロントエンド: Web フロントエンド領域の技術課題の管理と解決
- DevOps: 自己診断能力の獲得
なお, Native(iOS/Android) についての技術戦略・技術課題管理は各グループ独立でやっています。API schema など横断的に関わる時にスポットで参加してもらっています。SRE も同様です。
普段は下段やや左の"開発チーム"が Stream Aligned Team*6 として開発ロードマップの達成を目指します。その上で、開発チームで解決できない課題については技術戦略グループでハンドリングします。ハンドリングした結果、組織体制の変更が必要なものはマネジメントチームで、各チームのアサインで行えるものは各チームで対応し、必要に応じて来期計画に反映します。
開発部長としては事業戦略に対して開発部としての技術戦略策定の責任を負っており、事業戦略のインプットや全体を把握して方針をレビューする役割を担っています。
過去のアウトプットもご覧ください。
- 技術戦略横断ワーキンググループの活動報告 - スタディサプリ Product Team Blog
- 自己診断能力の獲得を目指して / Toward the acquisition of self-diagnostic skills - Speaker Deck
- 自分たちのシステムを診断するために DX Criteria"システム"テーマを実施しました - スタディサプリ Product Team Blog
直近の取り組み
ガイドラインの策定
組織もシステムも徐々に大きくなり、新しいサービスの技術を選定する上で、何を選べばいいか迷うシーンも増えてきました。もちろん技術選定は状況・環境・サービスの求める特性によって異なるものですが、組織において十分使われているものがあれば、リスクも減らせますし、知見の共有も可能になります。
そこで、組織全体で使う技術のガイドラインを置くリポジトリを作成しました。*7
ガイドラインのドキュメントのトップには、「ガイドラインのガイドライン」として、ガイドラインとは何かが記載されています。一部引用します。
最初に: ガイドラインとは何か / 何ではないのか 「ガイドライン」の意味や使い方 わかりやすく解説 Weblio辞書 を抜粋すると、 >どのように行動したらいいかまとめたものを指す英語表現である >「guideline」の意味である「指針」とは、物事を進めるべき方針や頼りになるもの、もしくは手引きのことを示している。あくまで方向性を示しているものなので、守らなくても何らかのペナルティが発生することはない。 ガイドラインは "良い意思決定を助けるため" に存在します。いわゆる "ルール" とは異なり、強い強制力を持つものでも、守らないとペナルティが発生するものではありません。守ることで利益が見込まれる (あるいは逸脱すると不利益がある) 事柄について言語化したものと捉えるとよさそうです。
ガイドラインが役に立つと期待される例 意思決定において迷いが発生しがちなもの対し、よくある選択肢のメリデメと、デフォルトの選択肢を提供する プログラミング言語、フレームワーク、ライブラリ、など 放っておくと不利益が生じる選択肢を選びがちなものについて、どういう罠があるかを先んじて情報提供しつつ、オススメの考え方を提供する サービス名称の決め方、マイクロサービスの分割の仕方、モノリスの扱いなど
このように、ルールではなく、推奨事項が書かれることが期待されます。書く人にとっても読む人にとってもメリットがもたらされることが期待されており、逆に言えばそうではない議論が分かれるものはガイドラインとしては不適切であると言えます。ガイドラインに書かれていたからと言って、サービス固有の特性に従い推奨外のものを選択することももちろん可能ですし、そうすべきです。ガイドラインはそのような選択をするための観点を提供する役割もあります。
ガイドラインの例としては、以下のようなものがあります。
マイクロサービスの命名
以下、実際のガイドライン本文です。
## ガイドライン 1. サービス名は可能な限り実態を表し、将来新しく加入したメンバーにとって無理なく認知できるものを推奨します 2. サービス名は可能な限り時間の経過によって意味が変わりにくいものを推奨します 3. サービス名の長さは26文字以内としてください ## 理由 1. 無理なく認知できない場合、名前と実態の変換表という新たなドメイン知識が必要になります - この変換表をメンテナンスし続けないといけませんし、新しく入った人に周知し続けないといけません。忘れてしまった人にもしつこく言い続けなければなりません - これは、業務の遂行を不必要に複雑化させます。 2. 時間の経過によって意味が変わってしまう場合、1 のように無理なく認知できることが難しくなることが予想されます 3. 26文字を超える場合、quipper/terraform リポジトリの label 上限に引っかかるためです - また、あまりサービス名が長いと書きづらく、発音しにくいため、略称を使われるなど、1 のように無理なく認知されることが難しくなります。また略称を使われることで Slack や GitHub 等でのググラビリティの低下も懸念されます - 略称は避けるべきですが、やむを得ずどうしても略称が必要ならば、公式に略称を提供して、その使用を徹底してください。
今後追加が予定されているもの
数年前に策定されたガイドラインで、ドキュメントに残っているものを改めて Pull Request を用いて現状に適しているかどうかレビューする予定です。
- サービス間通信のプロトコル(JSON over http)
- Ruby の静的型付け(sorbet)
- S3 バケットの権限管理(IAM を利用する)
- Redis を利用するサービス(Redis Cloud or Elasticache)
monolith の方針検討
スタディサプリ小中高では一部のシステムは共有データベースを利用しています。複数の Rails Application から利用されているため、データベースのアクセスは共有ライブラリを利用しています。Rails の Model 層にあたるものです。また、この複数の Rails Application のうち、生徒向けサービスのバックエンド api はいろんな用途で利用される巨大なアプリケーションとなっており、このデータベース、およびアプリケーションのことを monolith と呼んでいます。
サービス構成の詳細は以下の記事も参照ください。スタディサプリのWebアプリケーションはこうやって開発されている - スタディサプリ Product Team Blog
以降具体を説明します。これらはいずれも議論に決着がついた場合、前述したガイドラインとしてドキュメント化する予定です。
共有データベースに対する Model 層の管理方針
現在、共有データベースへのアクセスのためのライブラリは2種類あります。1つは以前から存在する、内部で"schema"と呼ばれるもの。もう1つは monolith からの段階的なマイクロサービス移行を支援するために作成された"qmonolith"と呼ばれるものです。新規に共有データベース向けの処理を書く場合や、マイクロサービス化のために monolith から移行する場合は qmonolith を利用することが推奨されています。読み書きには qmonolith を利用する Rails Application である qmonolith-service を利用します。
当時の方針から年月が経過し、現状どうすべきか方向性が人によって異なる状況になってきました。そこで今回改めてこの monolith に対する実装方針を議論中です。
api endpoint ごとのオーナーシップ策定
前述した生徒向けサービスのバックエンド api は非常に大きく、複数のチームが触ることで、サービスのコストパフォーマンスや、変更時の影響が読めないなど開発生産性への影響が懸念されています。また、このサービス個別の SLO は定められているものの、実際にパフォーマンスの問題が現れた時にどのチームにアサインすればいいかがわかりづらい問題も起こっています。
そこで、api endpoint ごとにオーナーシップを策定し、オーナーシップなし（全員で共通で使っているもの）の割合が一定割合以下になるような方針を検討しました。また、それを endpoint の増減に関わらず維持できるように、設定自動化も検討中です。*8
技術戦略グループとして実現したいこと
10年先もユーザへの価値と事業利益を作り続ける組織とプロダクトを作ることを目標としています。
そのために、現場メンバーが誰でも課題を表明できること、その課題を適切に評価できることが重要で、その取り組み自体がグループ体制によりサステナブルにできることが重要だと考えています。
そしてそれを支えるのが、Ownership を持って（垣根をこえて自分ごととして）システムに向き合うこと、率直だが思いやりのあるコミュニケーション、事実を元にした意思決定をする Fact-Based な文化です。
今の組織ではこの文化を大切にしながら、技術戦略の活動を通じてユーザへの価値を提供し続けていきたいと考えています。
おわりに
本稿ではスタディサプリ小中高における技術戦略の体制および直近の取り組みを紹介しました。
技術戦略に興味がある方はぜひ @chaspy まで連絡ください。カジュアルに話しましょう！
*1:スタディサプリ小学・中学・高校・大学受験講座のうち、一般の家庭に提供している領域を BtoC 領域と呼んでいます。https://studysapuri.jp/
*2:厳密には年に1度、決算のサイクルで行われ、半年で見直しがされる
*3:Financial Planning & Analysis
*4:バックエンド領域や横断課題を取り扱う
*5:社内では Tech Darwin というプロジェクト名でやっている。命名は当時のメンバーの投票で決まった。
*7:余談ですが、quipper/handbooks というドキュメント用のmonorepo が存在し、誰でも簡単にドキュメント作成できる便利な仕組みがあります。ツールとしては docsify が多く使われています。
*8:Datadog API Catalog が便利そうである
