🧤

3. DX Criteriaのポイント

5つのポイント

 

ポイント1:組織文化と「見えない」投資

デジタル技術を経営に生かしていくためには、「ソフトウェアは見ることができないという性質(不可視性)」を理解し、その上で必要となる「品質への投資」を進めることが重要になります。また、それを育むための組織文化も重要なファクターになります。こちらも見えにくいものです。
たとえば、ソフトウェアのインテグレーションテストとデプロイパイプラインの自動化は、品質を担保するだけでなくリリースサイクルを早くする効果があります。そして、チームが細かなチェックを神経を削って確認することからいくぶんか開放します。エンジニアはソフトウェアを修正することへの恐怖や不安が減り、活発に改善活動が進みます。また、心理的安全性の担保されたチームは、闊達な意見交換が行われプロジェクトの課題にいち早く気がつけます。
しかし、これらの習慣は「力を入れて実行する合理性が説明しにくいこと」でもあります。ソフトウェアの不可視性を考慮に入れるとなおさらです。
このような「見えない」技術的な投資や組織文化に対して、ひとつひとつ実施していき役割が企業において必要になります。CTO(最高技術責任者)やVPoE(エンジニアリング担当VP)がそのような職責を担うことが多いのです。
これらの技術的な投資の価値や組織文化の価値は、実際に現場レベルでソフトウェアを書いてきた経験がないと理解しにくく、体感的な納得がしにくいものでもあります。
体感的に納得できていることを説明したり意思決定することは難しくありません。一方、体感的な納得がない状態では、説明をひどく難しく感じたり不必要なものを持って回った説明をしているように感じてしまいます。
これらの技術的な「見えない投資」とシステムを改善する組織の文化は、車輪の両輪のようなものです。2つのうち片方が欠けていても、事業の改善速度は悪化していく傾向があります。
いわゆる技術的負債やレガシーシステムとは「組織が必要な速度でソフトウェアの改善ができなくなること」によって発生します。
 

ポイント2:タスク型ダイバーシティ

デジタル技術をイノベーティブに活用するためには、特定の職能に閉じた組織のみでは成し遂げられません。多くの場合、デザイナーやエンジニアを始めとした複数の専門職が同じ目的のもとチームとして働くことによって、これらは成し遂げられます。
また、意思決定の速度を高速にするためには、自己完結であることが重要です。チームは「あるミッションの実行にあたって必要なケイパビリティ」のすべてを持っていることが重要になります。1つの仕事をするのに、様々な部署の調整が必要な状態になった組織は、実行の速度を失ってしまいます。
そのため、DX Criteriaでは組織的な職能関係がどのように融和・融合しているかを測ります。これは特定の職種だけの問題ではなく、ソフトウェア要件に関わる組織全体にとって重要な課題になります。
いわゆるダイバーシティ:多様性というと、女性活躍や人種宗教といった属性に伴う多様性を指すことが多く、これを「デモグラフィック型のダイバーシティ」といいます。その一方、複数の職能にまたがったチームが編成されている状態や組織を「タスク型ダイバーシティの高いチーム」といいます。
もちろんどちらの多様性も重要です。とりわけソフトウェア開発の現場においては、複数の職能に組織が分断されすぎていると、コミュニケーションコストが増大しやすく結果的に改善の速度が失われてしまう現象があります。
そのため、本基準では「タスク型のダイバーシティ」に注目します。
スタートアップにおいて、事業の立ち上がりのフェーズでは小さなチームに様々な専門家が集まっていきタスク型ダイバーシティの高いチームが 編成されます。この時点において、経営的意思決定とチームの意思決定は一致するため、高速でイノベーティブな事業開発が望めます。コミュニケーションも四六時中近くにいるメンバーとの対話になるため効率的です。
一方、事業が立ち上がり、徐々に競争環境が固定化されると「より効率よく」「より管理しやすく」部門が編成されるようになります。職能ごとの部門が編成され、組織ごとの経営指標を追いかけるようになります。
タスク型ダイバーシティの低いチームでは、より深く研究を進めたり効率的なリソース運用が望めるため、「知の深化」が進みます。
組織が大きくなるに連れ、徐々に組織同士のセクショナリズムが発生したり、全体最適な行動が取れなくなってきます。 組織がサイロ化され、イノベーティブな行動が組織から減ってきてしまいます。市場環境が不確実になりさまざまなイノベーションが連続するデジタル時代においては、このような状態を維持することは得策ではありません。
必要に応じて、戦略的に複数の職能をまたいだチームを編成し、機動力を高く維持する必要が出てきます。 これにともなって小さなチーム同士で同じようなことをしてしまったり、専門的な職能の人材の活用に関して、リソース効率的な無駄が生じやすくなります。
タスク型ダイバーシティの高いチームでは、意思決定の速さとイノベーティブなアクションが望めます。これを「知の探索」といいます。
この2つ、「知の探索」「知の深化」の両方を事業フェーズや組織戦略に応じて大胆に切り替えていくことが 不確実な次代の経営には必要な判断になってきます。
 
 

ポイント3:メリハリのあるIT戦略

標準化・コモディティ化した領域については外部サービスを利用し、競争領域に特化して内製化をすすめるためのメリハリのある投資を促します。
DXの進んだ組織では、自社の利益増大やビジネスの変革につながるようなコアな機能に関してを集中して自社開発する傾向があります。 これを「攻めのIT領域」といいます。この領域では、ソフトウェアに対する知見が自社に残るように内製開発が望ましいです。また、自社に十分な人員がいない場合においても、パートナー企業とともに自社にソフトウェアの知見が残るようなラボ型開発のようなスタイルが必要になります。
よくある誤解としては、すべてのソフトウェアは内製開発すべきだというものがあります。たとえば、現実的に多くのIT企業ではOSレベルでの開発は行いませんし、インフラについてもクラウドベンダーのサービスを活用しています。このようにすでに「コモディティ」となったソフトウェアの構成要素は、自社で開発するのではなくうまく外部サービスを活用していくことが望ましいのです。この領域を「守りのIT領域」と言います。
現代は、SaaS型の事業が増えています。これらをうまく選定し活用しましょう。「守りのIT領域」をオーダーメイドで作る必要はありません。
オーダーメイドのソフトウェアは月額費用を払うだけでサービス提供会社が継続的に改善されるXaaS(IaaS/PaaS/SaaSなど)と異なり、常に自社で改善をコントロールしていく必要があります。そして、多くの場合必要な改善リソースを確保できなくなってしまいます。
サービス事業会社は、自社のビジネスとして複数の顧客のために事業改善を行いますが、守りの領域のシステムは自社開発ではコストとみなされてしまいます。継続的な改善の経済合理性がなくなるからです。そのため、長期的には改善速度が遅くなってしまいます。
つまり、誰かにとっての「攻めのIT領域」であるSaaS事業を守りとして活用することで効率よくIT活用できるのです。
また、このメリハリあるIT投資をするにしても、自社の競争領域とコモディティ領域を見極めることは非常に難しいものです。 そのためには、業界動向に対する洞察が重要になります。業界動向の把握の一助にDX CriteriaとCTO協会を活用ください。
「攻め」と「守り」は完全なゼロイチで決まるものではありません。また、戦略なく決まるものでもありません。
現実的な制約の中で、一定のグラデーションを持ちます。
たとえば、全く内製の開発人員がいなく採用を進めている最中であるなら、パートナーとともにノウハウを蓄積しながら開発する方法もあります。
たとえば、守りの領域にも関わらずSaaS化が進んでいないような領域でのシステム開発をする場合には、競合他社と手を組むなどできるかぎりクラウドサービスと連携しながらつくるといった手段もあります。
 
 

ポイント4:組織学習とアンラーニング

新しいツールや潮流に挑戦するための組織学習と、時代が変わってしまった習慣のアンラーニング(学びほぐし)を促します。

組織学習

組織として評価のために数字を追うのではなく、事実に基づいた計測から洞察を得て学び、そして改善していくというサイクルが重要です。この点を確認していきます。

アンラーニング

アンラーニング(学びほぐし)とは、成功体験のある古い常識を忘れて、新しい当たり前を取り入れやすくすることです。時代の変化に適応できる組織にはアンラーニングの習慣が宿っています。
 

ポイント5:自己診断と市場比較

関連するレポートと自己診断によって競合状況との差を認識しやすくし、自社の強み弱みを理解して段階的に変化できるよう促します。

自己診断

さまざまな項目について、自己診断を行えるような個別具体的なプラクティスを列挙しています。そのことで、あえて取り入れていないのか、検討が進んでいないのかなどより現場感のある議論を促進することが目的です。
 

市場比較

今後、計測ツールなどを公開していき、自社がどのような状況にあるのかを全体と比較できるようにしていく方針です。ご協力いただける各社の統計データと比較して、今自分たちがどのレベルにいるのかを知れるようにしていく予定です。

「説明責任の向き」の反転

DXの実現のためには、今までの常識であったことから「新しい当たり前」を取り入れていく必要があります。
しかし、その外部の基準が存在しないことによって、「なぜそれを取り入れるのか/やってみるのか」の説明をゼロから求められ、結果的に現場は学習性無気力状態になってしまい変革が遅れてしまいます。
本基準で、リストアップされている項目は必ずしもすべてを実現する必要はありません。一方で、それをやらない場合には、自分たちはなぜやらないのかを説明できる必要があるでしょう。
このように基準を使いながら、「変える理由」から「変えない理由」を確認するような文化形成を育むきっかけになればと考えています。