こんにちは。プラットフォーム開発部 EMのchikaです。
今回は、DX Criteriaを使った私たちのチームで行っている取り組みについて書いてみようと思います。
DX Criteriaとは
DX Criteriaは、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインであり、企業のデジタル変革（Digital Transformation） と 開発者体験（Developer eXperience） の2つのDXの要素を具体的に実践、活用していくためのものです。
ガイドライン、というとドキュメントを想像しますが、Criteriaと名前がついている通り、DXの各要素に対する質問に答えることで、企業でのDXの実現度合いを測ることができるチェックシートのようなものです。
なぜDX Criteriaを使っているのか
導入の経緯
私たちの所属するプラットフォーム開発部には、機械翻訳サービス「Mirai Translator」の機能を開発する複数のプロダクトチームの他に、SREチームやQAチーム、アーキテクチャチーム（SWEチームと呼んでいます）などの横断系チームが共存しています。
一般的な話として、プロダクトチームはプロダクトの売り上げや成長への貢献が見えやすく、ロードマップなどで現在の状況も可視化しやすいですが、横断系チームが行うような開発基盤の整備やアーキテクチャ改善など技術的課題の解決のための活動は、時間がかかる上に短期的には売り上げなどの数値的指標にはつながらないため、ビジネスサイドにはその価値が伝わりにくく、時間を割く意義を疑問視されることもあります。
みらい翻訳ではビジネスサイドの理解は比較的得られやすいとはいえ、例えば技術的課題への取り組みが本当にプロダクト開発の効率化やスケールに貢献するのか、開発者体験の向上につながるのかといった点は何らか可視化して測れるようにした方が説得力があるのは当然です。
そこで目をつけたのがDX Criteriaです。
DX Criteriaで定期的にアセスメントを行うことによって、技術的課題の解決のような直接プロダクトの売上に繋がらない開発について、その価値や状況を可視化するための指標として使えないか？ということを考え、2021年ごろから試行錯誤して使ってきました。
DX Criteriaのアセスメントはパフォーマンス計測ではなくヘルスチェック
使い始めた当初はDX Criteriaのアセスメント結果のスコアの変化を見てチームのパフォーマンス（誤解を恐れずに言えば生産性のようなもの）が分かるのではという淡い期待もどこかにあった気がします。
ただやってみて分かったことは、DX Criteriaは確かにアセスメント結果が数値として可視化されるのですが、これをもってパフォーマンスを測るようなものではないということです。どちらかと言うとヘルスチェック的な位置づけであり、チーム改善のきっかけづくりとなる箇所を発見するために活用するものです。もちろんその改善の結果、チームのパフォーマンスを上げることに繋がる場合はありますが、そのパフォーマンスそのものを測る指標にはなりえません。
DX Criteriaのサイトトップページにちゃんと書いてあるので気づくのが遅いよという話ですが、実際に使ってみないと中途半端な理解をしてしまいがちです。
本基準は絶対ではありません。誰かを攻撃したり、アセスメント結果の数字のみに注目して本質的な改善をおろそかにするためのものではありません。
（DX Criteria (v202104)/企業のデジタル化とソフトウェア活用のためのガイドライン より）
現在の活用方針は
そんなこんなで最初に使い始めた動機とは少し変わりましたが、今は開発チームの開発者体験を向上するための継続的な改善の取り組みの一環として使っています。
みらい翻訳でのDX Criteriaの使い方
ではここから、私たちの具体的なDX Criteriaの活用方法について説明します。
現在の使い方を簡単にまとめると以下のようになります。
- チェック対象のテーマは「チーム」「システム」
- 回答者は開発部内の各チームのリーダー、EM、VPoE
- チェックする際の「チーム」は自チームまたは部全体
- 結果は集約して傾向・推移などをまとめる
- まとめた内容でディスカッションし改善に取り組む内容を決定
- 四半期ごとにアセスメント実施
以下、1 〜 6 を詳しく説明します。
1. チェック対象のテーマは「チーム」「システム」
DX Criteriaのクライテリアは5つのテーマｘ8つのカテゴリーｘ8つのチェックリスト＝320個という相当な数で構成されていますが、全部をチェックする必要はありません。私たちは開発チームのアセスメントが目的なので、「チーム」と「システム」の2つのカテゴリー（それでもチェック項目は8x8x2=128個あるわけですが）を使うことにしました。
2. 回答者は開発部内の各チームのリーダー、EM、VPoE
誰がチェックするのかについて、公式サイトではEMやPdM、DX担当者などが代表してチェックするオーソドックスな例の他に、以下のような例も紹介されています。
チームごと・システムごとのようにテーマごとに分割した上で、複数の担当者に記入していただくなどすることで部門間の違いや共通の強み・弱みを知ることができます。
私たちの使い方はこれに近いもので、各チームのリーダーが代表してチェックするか、複数メンバーが協力して1つのアセスメントシートにチェックするようにしました。
中には 「メンバー全員がアセスメント項目を理解したほうが良いから」 と考え、メンバー全員でチェックするチームもありました。
3. チェックする際の「チーム」は自チームまたは部全体
チェックする際に思い浮かべる「チーム」の範囲は、私のようなEMの立場で考えると「部全体」になりますが、各チームの回答者にとっては他のチームの状況が分かっているわけでもないので、当然自分のいるチームがスコープになります。
最初の導入経緯が「部としてのアセスメント」だったこともあり、回答者によってスコープがばらついて大丈夫かという疑問も浮かびましたが、今の活用の仕方を考えると、むしろチーム間の差は気づきに繋がりやすいので問題ないと分かりました。
4. 結果は集約して傾向・推移などをまとめる
各チームでチェックした後はアセスメントシートを私たちEMの方で集約して、全回答者のカテゴリ別スコアの一覧、平均、標準偏差などをまとめます。
このとき、その後のディスカッションのトピックにするため、以下それぞれの観点に当てはまる上位カテゴリをピックアップしておきます。
- 平均スコアの高い／低いカテゴリ
- チームごとにばらつき（標準偏差）の大きいカテゴリ
- 前回からの変化が大きいカテゴリ
5. まとめた内容でディスカッションし改善に取り組む内容を決定
その後、各チームの回答者に集まってもらい、ピックアップしたカテゴリを中心に回答者それぞれの意図や疑問などを話し合います。
今のDX Criteriaの使い方で最も重要なポイントはここかもしれません。
最初は何を話そうか、と戸惑う場面もありましたが、チェックした人により甘めの結果・辛めの結果に偏ったり、「うちのチームと比べてなんでその項目そんなにスコア高いの（低いの）？？」という質問が出たり、話し始めると意外に話題が尽きないので非常に面白いです。
そして話していると「これ気になるよね、改善したいよね」というカテゴリがいくつか出てきます。 そういったものを取り上げて、目標として何かしらのアクションを設定します。
実際に目標にしたものとしては、心理的安全性の改善や、コードレビューガイドラインの整備などがあります。
心理的安全性の改善については、次回ご紹介しようと思います。
6. 四半期ごとにアセスメント実施
DX Criteriaを使い始めた当初から、アセスメント実施は定期的に行うことで変化を確認することを想定していました。
当初はアセスメントのチェック項目数が多くて時間がかかるので3ヶ月に1回これやるのか...大変だなぁとというのが正直な感想でした。
四半期ごとの実施で変化がどれだけ出るのか（労力に見合うのか）を心配もしたので、参加メンバーにも尋ねてみたところ、
- チーム目標を四半期ごとに設定してふりかえりをしているので、アセスメントも四半期ごとに行うのが区切りがよい
- 2回目の実施以降は慣れてくるのでそれほど時間がかからずにチェックできる
このような意見をいただき、四半期ごとに実施するようにしています。
個人的にも、定期的にアセスメントをすることで設問内容が何となく頭に入ってくるので、どんな要素がDX向上に必要か、ということに対する理解が深まっていくのは良いなぁと感じています。
アセスメント結果の紹介
最後に、私たちの実際のアセスメント結果（集約後のもの）と推移についてご紹介します。
直近のアセスメントの結果
直近、2023年3月に各チームでチェックした結果を集約したものを掲載してみます。
傾向としては、「チーム」カテゴリについてはどのチームでも比較的高いスコアが出ていますが、「システム」カテゴリについては低めのスコアになっています。
もう少し詳細に項目別に言及すると、以下のような傾向が見えます。
| 観点 | 上位該当項目(スコア) |
|---|---|
| 平均スコア 高 | ふりかえり習慣(6.8) 心理的安全性(6.6) チームビルディング(5.7) |
| 平均スコア 低 | 疎結合アーキテクチャ(3.2) 継続的デプロイ(3.3) ソースコードの明確さ(3.4) |
| 標準偏差 大 | 経験主義的な見積りと計画(2.1) 透明性ある目標管理(1.6) |
カテゴリ別平均スコアの推移
こちらは2021年度からの毎回の実施結果のカテゴリ別平均の推移です。
（最初の方は四半期から少しタイミングずれていますがご容赦ください）
所属チームによってばらつきがある上、アセスメント実施タイミングによって回答者が変わることもあるので、平均スコアの推移にさして大きな意味はないかもしれませんが、前回からの変化が大きいものはディスカッションして深堀りしてみると何か発見があるかも知れないと思い取り上げています。
直近の2023年3月では、ふりかえり習慣、心理的安全性、疎結合アーキテクチャ などが比較的変化が大きい項目として話題に上がりました。
スコア自体に意味はない
アセスメント結果がスコアとして可視化されるので、「ウチのスコアは高いのか？」が気になってしまうかもしれませんが、最初の方にも書いた通りスコアの高低は他のチーム・企業と比べるようなものではありません（だからこそ堂々とスコアをご紹介できるのです）。
仮に同じスコアでもチームによって適応できている項目とそうでない項目はバラバラだと思いますし、チームが課題に感じていないことをわざわざ変えることもありません。
それぞれのチームで改善したいことを見つけるためのアセスメントなので、こうやって可視化することで何か分かりそうだ、チームで話してみようという気持ちにすることに意味があるのだと思います。
まとめ
今回は、私たちのDX Criteriaの導入経緯と使い方について紹介しました。
皆様の現場ではDX Criteriaを使っているでしょうか。
使っている現場での取り組み事例があればぜひ教えて下さい。 まだ使ったことのない方にとっては私たちの事例が参考になれば幸いです。
次回予告
次回は、アセスメント後のディスカッションから改善目標として取り上げた心理的安全性の改善について書く予定です。
※続きの記事は以下から！
miraitranslate-tech.hatenablog.jp
We are hiring!
みらい翻訳では、私たちと一緒に開発者体験の良いチームを作っていくことに賛同いただけるエンジニアを募集しています！ ご興味のある方は、ぜひ下記リンクより募集要項をご覧ください。
ご応募・お問い合わせをお待ちしております。
