はじめに
こんにちは。SRE Team の @chaspy です。本日は 日本 CTO 協会が作成した DX Criteria を実施した話をします。
背景: 自己診断能力の獲得に向けて
スタディサプリ小中高大のプロダクト開発部では、今年の4月より「技術戦略グループ」という組織を発足させました。目的は、変化の激しい世の中にビジネス・組織が対応できるような開発組織を作ることです。そのために、「技術的なビジョンと方針の策定」「技術的課題・負債をコントロール下に置く」「改善サイクルの確立と自己診断能力の獲得」の3つを目標に掲げています。
本記事ではこの3つの目標のうち、特に「自己診断能力の獲得」について言及します。これを目指す活動体として「DevOps WorkingGroup」（以下 DevOps WG）を発足し、自己診断可能な指標あるいはクライテリアを検討・検証しています。
今回はその How の1つとして、DX Criteria を選択しました。DX Criteria は「チーム」「システム」「データ駆動」「デザイン思考」「コーポレート」の5つのテーマがあります。今回はそのうち「システム」テーマの話をします。その他のテーマの実施結果については後日別の記事でまとめたいと思います。
なお、あくまで今回は DX Criteria 自身の内容や運用方法を含めたノウハウを得るためのファーストステップであり、今後改善を重ねていくフェーズであることを言及しておきます。
どのように実施したのか
DX Criteria は各テーマごとに8つの Type、8つの質問があり、1テーマ合計64の質問項目があります。これを「Yes」「Yes, but」「No, but」「No」の4段階で回答し、それを元に点数がつきます。半年や1年といったスパンで実施し、推移をみることで、自分たちのシステムが改善しているのか、あるいはできなくなった点はどこなのかということを自己診断する、という使い方をします。詳細は DX Criteria の使い方 を参照ください。
システム項目を眺めると、「ソースコードの明確さ」「API駆動開発」に関しては Web Engineer (Frontend/Backend Developer) が、その他「継続的インテグレーション」「継続的デプロイ」「疎結合アーキテクチャ」「システムモニタリング」「セキュリティシフトレフト」は SRE がいれば回答できそうな感触を持ちました。DevOps WG には上記メンバーが集まっているので、この会議体で一度実施してみることにしました。
回答の出し方はいろいろありますが、今回はスピードを重視し、事前に @chaspy が回答したものを、これはどう？あってる？何かコメントある？という風に聞いて埋めていく形式を取りました。合計1時間半で診断が完了しました。やり方はいろいろありますが、このようにファシリテーターが事前に仮診断したものを確認していく形式以外だと、miro などのオブジェクトをオンラインで動かせるアプリケーションを使って、10秒ほどでせーので決めて、少数派の意見に対してどうですか？と聞いていく方法があります。後者の方法も「チーム」テーマで試しました。多様な意見を聞くメリットと、時間がかかるデメリットの両方あります。やってみて好みの方を選ぶと良いでしょう。
結果
このような結果になりました。*1
以下、内部で共有した @chaspy による講評をこのまま掲載します。
カテゴリ別講評
バージョン管理 7.0
ほとんど全てのコードがバージョン管理されており、良いスコアとなった。 残る点は code metrics 分析と、一部統合テストがコード化されていない点のみ。 code metrics は DevOps WG で候補指標としてあがっているので継続的に実験できないか検討していく。
ソースコードの明確さ 4.5
コードレビューガイドラインが存在しない点が大きくスコアを下げているが、これをどの粒度で、どういったものを、どう運用していくかは検討の余地がある。 また、循環的複雑度といった code metrics は候補指標になっているので取得を検討したい。 デッドコードの削除の仕組み化も本番環境でのカバレッジを計測するなどのアプローチで解決できると良さそうである。
継続的インテグレーション 5.0
概ねできているものの、CI における Flaky Test の存在、およびその時間と、インテグレーションテストにかかる工数（自動化されていない）点が問題となっている。 これらは Metrics として追いかけながら、改善のためのアクションを取っていきたい。
継続的デプロイ 6.0
デプロイ数は現在計測しているので、運用がより洗練すれば各チームごとに見ていけるようになりそうである。 E2E 自動テストも現在取り組んでいるため、将来点数が改善しそうである。 5分以内にアプリケーションを切り戻しできない点は障害対応・MTTR を考えると非常に良くないので、これは手を打っていきたい。
API駆動開発 2.0
"API" について共通認識が必要ではあるものの、サービス間で内部利用されている API と捉えても、かなり低いスコアとなった。 API 駆動開発は一部プロジェクトで実施できているものの、それ以外では実施できているとは言い難い。
疎結合アーキテクチャ 1.0
Design Doc Review でアーキテクチャをレビューする場所はあるものの、ガイドラインが存在していないことでスコアを大きく下げている。 今後このアーキテクチャレビューをする Capability を各チームに持たせるという意味では取り組みがいがあるテーマかもしれない。
システムモニタリング 5.0
ポストモーテムの TODO を組織として実践する仕組み、SLI/SLO のビジネスレベルでの合意ができてない点が問題としてあげられた。*2 アプリケーションログそれ自体にもポリシーやガイドラインがないことにも気づくことができた。
セキュリティシフトレフト 3.0
主体的にできているものがほとんどなく、dependabot / renovate でのライブラリアップデートのみが自信持って実施できている項目となった。 いずれも組織として長期的に取り組む必要があるテーマだと感じた。
総評: アセスメントの有効性
システムのテーマに関して、DevOps WG のメンバーで問題なく診断できた。欲を言えば新規事業プロジェクトのメンバーもいたほうがよかったかもしれない。 アセスメントの項目に関しても、まだスコアは良いと言えず、現状の K12 プロダクト開発組織にとって改善の余地があることが示された。 今回示された項目のほとんどが妥当な項目であり、しばらくはこれをアセスメントとして利用し、半年に1度の診断と、改善のサイクルを行うのは有効に思えた。
総評で書いているように、私たちの開発部にとっては有効なアセスメントだと感じました。この数値結果そのものが絶対でもないし、高い数字を目指す必要は必ずしもないという前提に立ったとしても、我々のシステムの問題点を明確に指摘してくれていると感じました。
今後
この講評を共有した上で、今後はアクションをどの分野に取っていくかのコンセンサスを取りました。
このように、各メンバーに重要だと思うタイプを3つ選んでもらい、その理由を共有してもらいました。その上で、簡易ですが重みをつけてポイント計算したところ、上位3つは明確な差が現れたので、下期ではこの分野に対してアクションを打っていく予定です。その後、また半年後に再度診断をして、経過を見てみようと思います。
おわりに
今回、システムと組織の健全性を自己診断する方法として DX Criteria のシステム編を実施しました。このアセスメントが適切か、それを活かすことができるかは組織によると思いますが、少なくともスタディサプリ小中高大開発部としては自分たちの問題を指摘している有益なアセスメントだと感じました。しばらくは半年ごとに診断を続け、アクションを打っていこうと思います。
DX Criteria はその指摘に対する結果を診断するだけでなく、その診断する過程にも価値があると感じました。ある項目はひとによっては判断がブレることも少なくありません。その際に、この質問の前提は何か、背景は何か、スコープをどこにおくか、ということを自然に共有することそれ自体が、チームの共通認識を進める良い機会だと感じました。
「問題はいろいろありそうだけれど、何から手を打っていけばいいかわからない」そんな風に考える開発組織の方、あるいは経営層の方は一度質問項目を眺めて、試しにやってみるととっかかりが掴めるかもしれません。
Quipper では 世界の果てまで学びを届けたい仲間を募集しています
また、明日 2021-08-25 に スタディサプリ/Quipper オンラインミートアップ #3（SRE）を開催します。このイベントでは今回紹介した「自己診断能力の獲得」に関係する、SRE Team がどのように成果を計測したかについての取り組みを紹介します。こちらもぜひ遊びにきてください。
*1:49.9 の偏差値は全部入れた上での相対評価なので意味のある数値ではない
*2:新規サービス作成時の Design Doc, Production Readiness Checklist で SLI/SLO を関係者と合意する項目はあるものの、範囲はプロダクト開発部（Product Manager 含む) となっており、Business Developer を含んでいない
