はじめに
デジタル作品を販売・閲覧するオンラインECサービスでフロントエンド領域の開発改善を担当しています、surumebeerと申します。
本記事では、私の所属するチームがWebフロントエンド版DX Criteriaを「改善の出発点」としてどのように活用しているかをご紹介します。
Webフロントエンド版DX Criteriaとは
DX Criteriaについて
DX Criteriaは、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。
日本CTO協会は「DX」を以下の2つと捉え、企業変革には両方が不可欠としています。
- Digital Transformation（企業のデジタル化）
- Developer eXperience（開発者体験）
DX Criteriaは、この2つのDXを一体として捉え、高速な仮説検証を実現するための具体的な習慣をリストアップしたものです。（参照）
Webフロントエンド版の位置づけ
Webフロントエンド版DX Criteriaは、プロダクトのユーザー体験と変化に適応するチームのためのガイドラインです。
DX Criteriaが掲げる「2つのDXによって高速な仮説検証能力を得る」というビジョンを、Webフロントエンド技術領域の観点から実現するためのサブセットに相当します。
以下の5つのテーマで構成されています。（参照）
| テーマ | 概要 |
|---|---|
| 持続可能な技術スタック | 長期的に維持・発展できる技術選定 |
| ユーザー体験を支える品質 | ユーザー価値を届けるための品質担保 |
| 安定的なデリバリー | 継続的かつ安定したリリース |
| 効果的なシステム設計 | 変更に強いアーキテクチャ |
| 成長できるチーム | 学習し続けるチーム文化 |
なお、DMMのフロントエンドエンジニア複数名が、監修者としてWebフロントエンド版DX Criteriaにコミットしています。
なぜ活用しようと思ったのか？
DX Criteriaを活用する前、私たちのチームは開発改善を主として行っていました。
開発改善を行っていくために、不足箇所や改善効果の高い施策をリストアップしたり、改善に対するロードマップを敷いていました。
しかし、課題感に基づいた施策を実施してはいたものの、施策の分類や優先順位付けが難しく、より戦略的な視点が必要だと感じていました。
単発的なプロダクト分析だけでなく、継続的な取り組みとして定着させるための分析手法が求められている状態でした。
また、これまで行ってきた改善活動に対する答え合わせのようなことを行いたかったのもありました。
曖昧な課題感を整理し、戦略的な改善の方向性を見出すために、Webフロントエンド版DX Criteriaを用いた評価が有効ではないかと考えました。
そして、以下の目的を定めてWebフロントエンド版DX Criteriaを活用することにしました。
- プロダクト・チーム体制・開発環境に対する現状把握と「強み」と「弱み」の可視化
- 開発者体験（DX）・ユーザー体験（UX）の改善
- 上記に対する改善進捗の可視化
DX Criteriaを活用することで、現状把握としてチームの強み・弱みを可視化し、戦略的な改善の議論に活かすことができるのではと考えました。
また、定期的にアセスメントを実施することで、改善進捗の可視化と改善サイクルを回せる仕組みの構築を狙いとしました。
具体的な活用事例として
Webフロントエンド版DX Criteriaの使い方にも活用方法の記載はありますが、具体的に私たちがどのように活用していったかをご紹介していきたいと思います。
1. 評価範囲の決定
チームごと・システムごとのようにテーマごとに分割した上で、複数の担当者に記入していただくなどすることで部門間の違いや共通の強み・弱みを知ることができます。
使い方にも記載のあるとおり、「どこ」を評価するかについて決定しなくてはなりません。
私たちのチームは複数のプロダクトごとに編成されており、そのプロダクトを対象として評価範囲を区切って行うよう決定し、
まずは私が担当しているECサービスのフロントエンド領域に区切って評価対象としました。
後述しますが、この評価範囲は組織体制やプロダクトの特性によってアセスメントによる効果が変わってくる箇所だと思いますので、留意が必要だと思っています。
2. アセスメントシートの準備 / チェックリストの記入
DX Criteria Webフロントエンド版アセスメントシートをコピーして、シートを作成します。
採点方法は、1つのカテゴリにつき全8問で、「TRUE」が1点、「FALSE」が0点の8点満点です（アンチパターンの項目のみ評価が逆転します）。
「TRUE、ではあるが…」や「FALSE、だけれども」といった曖昧な状態は0.5点として換算しています。
私たちは担当者1名がチェックリストを全て埋める形で進めました。
把握のできていない箇所や範囲については、詳しいメンバーにヒアリングしながら記入しています。
実際に行うと、この採点はなかなかに一筋縄ではいかず、「改善を中途で進めているが…」といった評価や、「一部ではTRUEやFALSEとして答えられるけれども…」といった評価をすることが多かったように思います。
この曖昧さに悩むことが多かったのですが、後工程であるレビューの手を借りて微調整していく形で進行し、ひとまずは「採点する」ことを重視して行うようにしてからはスムーズにこの工程を行うことができました。
3. レビュー
担当者が記入したチェックリストを、他のメンバーがレビューします。
remarks列にレビュワー各自の見解を記載し、評価の妥当性や認識のズレがないかを確認します。
この過程で「実はこういう状況だから評価が変わるのでは」といった意見が出ることもあり、より正確な評価に近づけるのではと思い、レビューをする形にしています。
前述したとおり、チェックリストに記入した際に「できていると思ってたが一部では不足している」や「実は行っている」など、認識していた状況と異なっている点を修正できました。
加えて、この認識のズレを確認できたことは、プロダクトやチームに対する多角的な現状把握につながり、とても良かったと思っています。
4. アセスメント結果の確認
アセスメントシートのチェックリストを埋め終わると、「可視化」シートにテーマごとに以下の情報が表示されます。
- 得点
- 偏差値
- レイティング
- 分類グラフ
これにより、チームの強み・弱みが視覚的に把握でき、どの領域に注力すべきかが明確になります。
実際に私たちのプロダクトでは、インフラ面の負債脱却や整備が先に進んでいたため、「効果的なシステム設計」は高いスコアを残しており、
まだ整備の進んでいない「持続可能な技術スタック」や「ユーザー体験を支える品質」に対して低いスコアを出す結果になりました。
このような状況を漠然と把握していたものの、可視化により明確になり、チームで共通認識を持つことができました。
5. ディスカッション
チームでミーティングを実施し、以下の観点で議論をし、展開します。
- 各項目でなぜこの評価になったのか要因分析を実施
- 改善・対応できる余地があるか精査
- 課題化して取り組むものはチームへ展開する
この段階での要因分析を丁寧に行うことで、より本質的な課題が見えてきます。
また、「なぜその評価だったのか」が記録として残ることにより、改善の効果測定も明確になります。
項目の中には、フロントエンド領域だけの改善行動では対応の難しいものも時にはあります。
そういった項目の採点が変わった場合は、組織として取り組めているかどうかの評価に繋がります。
自分たちの改善活動だけでなく、プロダクトに関する改善活動の全体的な把握と要因分析は、チームやプロダクトを越えた枠組みに対する視座を高めるきっかけにもなりました。
6. 定期的な振り返りと改善
チームへ展開しタスク化された改善対応は、隔週開催の改善会にて進捗確認を行っています。
また、改善対応が完了されたタスクに関しても、継続的に行えているか、その内容に関しても振り返りを行うようにしています。
項目内には、継続的に行うことが重要である内容のものもあるため、定期的にその進捗を確認するようにしています。
7. 定期的なアセスメントの実行
半年ごとにアセスメントを再実施し、改善の効果を測定しています。 定期的にサイクルを回すことで、改善活動が一過性のものではなく、継続的な取り組みとして定着していきます。
取り組みとしては、進め方の「2.アセスメントシートの準備 / チェックリストの記入」に戻って進みますが、 私たちは再び評価する際に、アセスメントシートのチェックリストに以下の行を追加しました。
- 前回集計分のスコア（推移を比較するため）
- 改善Flag（課題化するかどうか）
- 即時での改善・対応できる余地があるか
こうすることで、前回比較からの要因分析、改善対応の取捨選択や優先度の決定が行いやすくなりました。
実際に進捗が出ている、継続的に行えていることがスコアとして可視化されるのは改善活動を行っている身としては嬉しいですね。
感想・所感
良かった点
改善アイデアのヒントになる
「プロダクトを良くしたい」「チームを良くしたい」という思いは漠然と持っていても、
具体的に何から手をつければいいのか迷ったり、何をしたら良いのかがわからなかったりすることがあります。
Webフロントエンド版DX Criteriaは包括的にチェック項目が用意されているため、普段見落としがちな観点や未知の観点にも気づくことができました。
チェックリストを埋めていき、不明点を調べていく過程で「ここは改善できそうだ」「この項目は盲点だった」といった発見があり、改善アイデアのヒントとして非常に役立ちました。
実際に、このチェックリスト項目からアイデアを得て、改善活動として取り入れたものもいくつかありました。
チーム内の認識を揃えるきっかけに
自分も含めてレビュワーと、定められた基準とその評価についてディスカッションを行うことで、各々がプロダクト・チームに対して持っている認識を擦り合わせることができる良い機会になりました。
「この項目はTRUEだと思っていたけど、実はFALSEだった」といった認識のズレが明確になったり、
「この項目について、実際にはこういうことを行っている」という情報交換の側面もあり、
チーム内での共通理解を深めるきっかけにもなっています。
改善活動の優先度が明確になる
アセスメント結果を可視化することで、どの領域が強みでどの領域が弱みなのかが一瞥して理解できるようになり、
改善活動を進める際の優先順位の決定を、テーマ・各チェック項目に沿って意思決定が行えるようになりました。
例えば私たちの場合、前述したとおり「効果的なシステム設計」は高スコアだった一方で、「持続可能な技術スタック」や「ユーザー体験を支える品質」は低スコアでした。
この結果から、まずは低スコアだった領域の中でも特に改善効果が高そうな項目から着手するという優先順位の決定を容易に行うことができました。
注意が必要だと感じた点
評価範囲
シートを用いてアセスメントを行っていく中で、評価範囲の設定は非常に重要だと感じました。
私たちも当初は広い範囲で評価しようとしました。しかし「TRUE/FALSE」の判断が曖昧になりがちで、一部では改善を行えているものの一部ではまだ、といった評価が続く形になってしまいます。
もちろんその評価はできる形でシートは残っているのですが、前回差分からの進捗把握のしづらい形でシートが残ってしまいます。
私たちの場合は改善活動を実際に主導できる単位で評価範囲を設定し、プロダクトごとに差異を確認していく方法に落ち着きました。
この評価範囲の設定は組織体制によっても、プロダクトによっても千差万別かと思うので、ある程度試行錯誤が必要ではと思っています。
数字より「なぜ」「どうすれば」
DX Criteriaの公式サイトでも、以下の点に注意するよう記載されています。（参照）
- 理解をせずに導入する/しない
- 一つ一つ実践しながら体感的な理解を積み重ね、自社にあった適切な形を模索していくことが大切
- 過度に数字を気にしてしまう
- スコアを一方的な数値目標にしてしまうと、本来の価値を見失ってしまう
- 内容より結果に注目する
- すべての項目を満たすことがゴールではなく、どこがボトルネックになっているかを判断することが重要
- 誰かを攻撃するのに使う
- 基準を満たさない誰かを責めるためのものではなく、より発展した議論に導くためのもの
私たちのチームでも、アセスメント自体のスコアの数字や評価だけに囚われず、
「なぜその状態なのか」「どうすれば改善できるか」「どのようにそうなったか」の議論を大切にしています。
例えば、あるチェック項目が低スコアだった場合、単に「改善しなければ」と決定して取り組むのではなく、以下のような観点でも議論するようにしています。
- 現状のリソースや優先度を考えると妥当な状態なのか
- 今すぐ改善すべきか、後回しでも問題ないか
- 現状から換算して対応は可能か、もしくは容易か
あくまでWebフロントエンド版DX Criteriaは本質的な課題の顕在化と、その把握と対応判断をするためのツールであり、開発改善の検討材料であると捉えています。
まとめ・今後の展望
本記事では、Webフロントエンド版DX Criteriaを活用した私たちのチームの取り組みをご紹介しました。 DX Criteriaは、開発チームの現状を客観的に把握し、改善に向けた議論を活性化させるための有効なツールです。 今後も半年ごとのアセスメントを継続し、現状把握をしながら改善を積み重ね、長期的な改善の軌跡を可視化させながらプロダクト・チームの成長を実感していきたいと考えています。
そして、Webフロントエンド版DX Criteriaの活用を通じて得られた気づきや改善の成果を、他のプロダクト・チームにも展開していけたらと思っています。
