はじめに
DX Criteria という企業のDXを推進する上で活用できるガイドラインがあります(初版は2019年に作成されました)。
本稿では、その DX Criteria を活用してチームを改善する例を紹介します。
DX Criteriaとは
公式サイトの DX Criteria 企業のデジタル化とソフトウェア活用のためのガイドライン には、以下のように書いてあります。
DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。
本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。
公式サイトの DX Criteria 策定の目的とビジョン には、DX というのを以下のように定義しています。
日本CTO協会では「DX」という言葉を２つの意味で捉えています。
一つは、これまで述べてきた企業のデジタル変革を意味する「Digital Transformation」です。
もう一つはソフトウェア開発者にとっての働きやすい環境と高速な開発を実現するための文化・組織・システムが実現されているかを意味する開発者体験「Developer eXperience」です。
このような「２つのDX」を一体として捉え、320個の現代的で具体的な文化資本の発露となる習慣をリストアップしたものが本DX Criteriaです。
公式サイトの DX Criteriaの構造 には、以下のようにあり、チェックする項目が全部で320個あります。
５つのテーマ、８つのカテゴリ、8つの項目で全320個のチェック構造を持っています。
DX Criteriaの使い方
公式サイトに DX Criteriaの使い方 というページがあり、以下のように記載されています。
DX Criteriaのご利用に関して、主な使い方は次の３つです。
・自社のDX進捗度の簡易的なアセスメント
・担当マネージャによるチームとシステムごとの詳細なアセスメント
・外部パートナーとのコミュニケーション
つまり、アセスメントする最小単位は「チーム」になります。
ある1つのチームについて、そのチームのマネージャーまたはリーダーがアセスメントするだけなら、始めやすいと思います。
また、アセスメントの項目数は320個あり、全部やるのは大変そうに見えます。
だからまずは自分のチームでやる効果が高そうなものだけに絞って実施するのをお勧めします。
(公式サイトにも「まずは簡易アセスメントからはじめよう」と書いてあります)
例えば、最も大きな分類の「5つのテーマ」は以下で、テーマで絞ることもできます。
- チーム
- システム
- データ駆動
- デザイン思考
- コーポレート
この中で「チーム」というテーマに絞って実施すれば、320個のうちの64個のみで始められます。
私のチームの場合も、この「チーム」というテーマに絞って実施しました。
図のようなアセスメント項目64個に対して、「はい(TRUE)」「いいえ(FALSE)」「はい、でも‥(but)」の3択から選択するだけなので、早い人なら30分くらいで実施できます。
ちなみに、こちらの記事でも、DX Criteriaの「テーマ」と「システム」をやってみて、それを改善に繋げる活動をしている例が紹介されていました。
アセスメント結果
私のチームでは、「チーム」というテーマに絞ってアセスメントを実施しました。
アセスメントする人は、チームメンバー全員でやったり、リーダー複数人でやったりなど、色々なパターンがあるようでしたが、私のチームではマネージャーの私1人で実施しました。
参考までにアセスメント結果を紹介します。
2020年時点では、図のような結果になりました。
この結果について、チームのメンバーと共有して、どの辺りを改善していこうかというのを検討しました。
アセスメント結果を改善に活用する
DX Criteriaの使い方 というページに上記のように書かれています。
DX Criteriaでは、適切なメトリクスを測ることでより議論が明確化し、活発な改善と対話を促進していきたいと考えています。
しかし、これらを経営が一方的に数値目標としてしまうと、本来の価値を喪失してしまいます。
DX Criteriaは、高速な仮説検証をする組織が持つ習慣や文化・ケイパビリティに注目するものです。
そのため、すべての項目を満たせばよいというのではなく、自社の事業環境において
どこがボトルネックになっているかを判断した上でお使いください。
従って、アセスメントした結果、よくなかった項目を盲目的に改善するのでなく、改善の入力の1つとして活用するのが良いと思います。
私のチームで具体的に改善の入力として活用できた例を以降で紹介します。
太字で書いたものが、DX Criteria のアセスメント項目です。
それぞれのアセスメント項目に対して、当時に足りなかった観点と、その後にどんな改善を行ったのかを記載しています。
TEAM-1-4：チームは価値提供をするのに必要な全職能のメンバーで構成されているか。(フィーチャーチーム)
→ プロダクトの新機能の開発時に、仕様を定義する上で、仕様を作る人とレビューする人の2人が必要でしたが1人しかいませんでした。また、アーキテクチャ設計も同様に、設計する人とレビューする人の2人が必要でしたが1人しかいませんでした。そのため、他チームの人にレビューしてもらう必要がありました。その後、当時のメンバー全員が仕様・設計を担当できるように育成しました。
TEAM-2-4：新しくチームに参画するメンバー用のオンボーディング・デック（チームの一員として働き始めるための、価値観・実務・スキル・相互理解のための明文化されたドキュメント集）が存在するか。
→ 環境構築手順や必須の教育資料など、必要最低限のものしかありませんでした。
その後、インセプションデッキを作成して最初に説明する手順を追加したり、リモートワークでもコミュニケーション不足にならないオンボーディングのプラクティスを定義して改善しました。新人が楽しく成長できるようにするためのプラクティスの詳細は以下の記事を参照ください。
TEAM-3-2：1on1や、落ち着いた場面でのカジュアルな雑談を含む直接業務に関わらないキャリアやタスクの壁打ちを、月に1度程度は実施しているか。
→ 1 on 1 をやっていませんでした。
その後、「コーチング脳の作り方」という書籍の内容を参考に、1 on 1 にてメンバーそれぞれの自己実現を考えるコーチングをするなどの改善をしました。
TEAM-3-5：チームの不安や不満などを可視化し、吸い上げるための仕組みを持っているか。
→ チームの不安や不満を出力する場を提供していませんでした。
その後、デブサミの発表資料などを引用して、不安や不満を溜めるよりも分報で公開した方が良いことをチームで共有し、分報でネガティブなことも書くようにしました。そのためにも、なるべく分報に現在の状況(今のタスクをどう進めていくつもりかなど)を書いていく運用を推奨しました。
TEAM-4-6：他部署からの依頼が明確なタスクツールではなく、担当者へのダイレクトメール/メッセージ/口頭など透明性のない形で行われている。
→ 他チームからの依頼が、SlackのDMや口頭だけで行われることがありました。
その後、透明性を確保するために、他チームと連絡するための専用チャンネルを作成し、そのチャンネルにお互いのチームメンバー全員を登録して、そのチャンネル経由で依頼してもらうようにしました。
TEAM-7-1：ふりかえりのテーマごとに数字を集めたり計測するなどして、ファクトベースで議論できるようにしているか。
→ リリースごとの成果量、工数、不具合数などのデータを入力とせずに、振り返りを行っていました。
その後、リリースごとの成果量、かかった工数の合計、工程ごとの工数比率、工程ごとのレビュー比率、工程ごとの手戻り比率、工程ごとの不具合数などをまとめた帳票を作成して、それを入力にして振り返りをするように改善しました。
TEAM-7-5：ふりかえりにおいて前回のふりかえりで改善するために起案したタスクが実行されたか検証しているか
→ 前回の振り返りで決めたアクションについて、それが効果的だったかの評価をし忘れることがありました。
その後、振り返りの最初に、前回振り返りで決めたアクションが効果的だったか評価するようにしました。
まとめ
まずは自分のチームで、一部の項目だけでもアセスメントしてみると、それが改善に活用できることを実感できると思います。
その結果をもとに、他のチームでもやってみたり、他のアセスメント項目に広げてみたりするのが、やりやすいと思います。
ちなみに私はITエンジニア向け情報誌「Software Design」の2022年5月号から「ハピネスチームビルディング」を題材に連載記事を書いています。Web上でも以下で公開しています。
X(旧Twitter)でも役立つ情報を発信しますのでフォローしてもらえると嬉しいです → @kojimadev