🧤
2. DX Criteriaのポリシー
このドキュメントはDX Criteriaを策定・改訂するにあたって、どのような点を重視しているのかをその優先順位とともに明文化したものです。
DX Criteriaの各項目やクライテリアの表現が「なぜそのように書かれているか」をご理解いただく上で重要なポリシーとなっています。
1.明晰性
まず第一に重視したい性質が、明晰性です。明晰性とは、YES/NOの判断がしやすくその境界がはっきりと理解できることです。これによって、様々な状況に置かれた人がDX Criteriaを活用しやすくなり、またその得点の大小や良し悪しを比べやすくなります。
そのため、「適切に行っているか」「定期的行っているか」と言う曖昧な表現ではなく、「半年に一度」「１ヶ月に一度」などの具体的なサイクルや修飾語をつけて評価しやすくしています。
これらは本質的には目安でしかありませんが、クライテリアの判断基準を一律にするために一定の割り切りを持って定義しています。
2.身体性
第二に重視したい性質が、身体性です。
身体性とは、実務的な実践から得られた感覚で日常化し、当たり前になっている立ち振る舞いや、習慣的な行動への諸性向、美的センスなどからくる価値判断であるかどうかです。
たとえば、「テスト駆動開発」「ペアプログラミング」のようなものは、その投資を上回るベネフィットがあるかという確立した論文やエビデンスがあるわけではありません。（各種論文群のシステマチックレビューなども進んでいるものの）
ですが、その価値は認識され、優れた習慣として多くの生産性の高い/開発者体験の高い現場で用いられています。このような実践感覚に根ざしたプラクティスや行動を抽出して評価することで、DX Criteriaは実際的に組織の能力を検証することができます。
また、これらは最初から費用対効果を目指して行うと言うよりも継続的な取り組みが優れた成果につながるものだと私たちは捉えています。そのため、まずは実践し、学ぶことが促されることを優先した選定方針になっています。
DX Criteriaでは他の基準よりも、その良さが「非自明」「証明されたわけではないが、実際の現場で評価がされている」「手触り感がある」企業活動を基準として取り入れ、コミュニティベースでの継続的なアップデートを目指します。
3.同時代性
第三に重視したい性質が同時代性です。ソフトウェア開発の世界は日進月歩であるため、昨日まで当たり前だった習慣も現在ではよいものとはかぎりません。
たとえば、開発環境の構築について、一つのOSを共有した開発でも問題がなかった時代から、一人一つの仮想環境になり、ローカルで動作するVMで複数個の環境を用意することが当たり前になり、さらにはコンテナ技術により手元で十数個のコンテナを起動しながら開発をすることもよくみる風景になりました。
また、リモートワークの急速な普及に伴い、オフィス環境を前提とした基準も記述としては不適当だと思っています。陳腐化した記述を削除し、新しい記述を取り入れていくことで常に同時代性を確保しようと努めていきます。
そのため、過去のクライテリアの評価がそのまま、10年後も使えるとは限りません。しかし、項目の変化スピードを比較的ゆるやかに設定することで、過去との比較や改善が見て取れるようにしていきます。
4.可観測性
第四の性質が可観測性です。可観測性とは、同じチームや組織を対象にする場合においては、アセスメントを記入する人の立場によって評価結果がわからないように、内心や意識の持ちようではなく、「観測できる行動」の部分を評価するようにしています。
たとえば、「心理的安全性が高いか」ではなく「心理的安全性をアンケート調査しているか」のように、具体的な行動に紐付けたクライテリアにするように心がけています。
また、さまざまな事象に対して「観測可能」であるような習慣や行動を重視したアセスメントとなっています。そのため、十分うまくいっていると考える人が多いためわざわざ観測していないようなことに対しても、可観測性を促すことがある項目が多くあります。
誰か一人が(特にアセスメントするような立場にある人が）うまくいっていると考えていても、それが本当に正しいとは限らないためです。
5.非限定性
第五の性質が非限定性です。これは、解決策の手段を特定しすぎないということです。
DX Criteriaの各項目は、多くの企業が自社内で実践されてきたナレッジを元に生み出されたものです。そのため、コストを払えば内製でも実現可能なものが多いのですが、近年ではクラウドサービスやパートナー企業のサービスとして、低コストに取り入れられるものも多数存在します。
FAQや個別ページなどでそのようなツールやベンダー機能の紹介することは、利用者にとっての利便になります。それらを促進していきたいとは思うものの、クライテリアの解決手段がどこか特定の企業のサービス利用しかないと言う状況は避けたいと思っています。特定サービスとの依存を奨励したいわけではないからです。
多様な手段の中から、自身の環境に合わせた最適解を考えるためのきっかけになることが本懐ですので、手段を限定しないようなクライテリアにすると言うことを意識しています。
また、サービス導入以外にも、ソフトウェア開発の分野においては、さまざまなプロセスモデルや手法、プラクティスが存在します。たとえば、ウォーターフォール的文脈で生まれた中にも良き習慣があり、アジャイル・リーンなどのムーブメントの中にも良き習慣が存在します。
各流儀に対しては敬意を払いつつも、状況に合わせた取捨選択の自由を制限することもまた、組織のダイナミックケイパビリティ獲得にとって良い影響はないと考えています。