デジタル組織とは何か。なぜ組織改革が求められているのか
現代はVUCAの時代と言われています。VUCA とはVolatility(変動性)、Uncertainty(不確実性)、Complexity(複雑性)、Ambiguity(曖昧姓)の頭文字を取った造語で、将来の予測が困難な状況を示します。そんななかで成長を続けていくためには、「安定的に変化対応できる」必要があります。
変化対応力とは、変化に対して柔軟迅速な意思決定を行う決断力と、意思決定結果を迅速に実行・実現できる即応力であると考えています。これを安定的に実現できる組織が本日のテーマであるデジタル組織です。
デジタル組織というのは、自ら変化を起こしていくための仕組化ができている組織であると私は考えています。組織を作り上げるためには、目指したい姿に合うマインドセットから、それを実現するためのプロセスやツール、加えて組織を維持・改善を続けられるガバナンスやルールといったさまざまな要素が必要になります。
以前は、個別の要件をすべて整理しきって、その要件に合わせた計画を立て、着実に遂行することがポイントとなっていました。しかし今は求められることが変わる世界であり、要件は変わっていくことが前提となります。
ですのでこれに対応して、自ら変わるように環境を変え、仕組化していくことがポイントになります。
例えばプロセスであれば、1ヶ月に1回、3ヶ月に1回といったリリースサイクルを確定させ、その時に最も価値が高いと思われるスコープにします。ツールであれば要件に合わせて個別構築するのではなく、アーキテクチャのトレンド変化に対応できるようベストプラクティスのソリューションをうまく組み合わせることを優先します。そしてこれらを遂行するマインドセットは、期初に綿密に計画を立てその通りに遂行するという従来の方法から、トライ&エラーを繰り返しながら限りあるリソースで最大価値を目指すマインドセットに切り替ることが重要になってきます。
このようにすべての組織要素に変化が起きるよう仕組化できている組織がデジタル組織である、と私は考えています。
上記のようなデジタル組織を組成するために、NTTデータは「SAFe」というフレームワークを活用しています。SAFeは経営から現場まで一体となって、提供価値の最大化を目指すために変化を促していく大規模アジャイルフレームワークです。経営層から開発の現場まで一貫して価値提供していくためのプロセスが規定されています。
NTTデータでは このフレームワークを使って社内でデジタル組織化の実践をし、そこで得られた知見をもとにお客様のデジタル化の支援をしております。
デジタル組織への変革事例
ではお客様との具体的な取り組み例をご紹介します。
私は自動車業界の顧客接点領域のDX推進をミッションとしています。この分野は市場変化のスピードが速く、エンドユーザーの顧客体験全体に対して一貫した取り組みが求められるなど、コンスタントな変化が求められるため、デジタル組織が最も必要とされる領域の1つです。
お客様とのプロジェクトではSAFeを活用して推進してきましたが、そのなかでいろいろな障壁にぶつかってきました。
特によく直面する2つの壁をご紹介していきます。
1点目はプロダクトオーナー(PO)問題です。提供価値をもとに実現したい要件を整理し、開発側と連携していくというロールに関わるものです。
2点目は、他組織や他システムといった外部システムとの連携に関わる問題です。
障壁１：プロダクトオーナー
プロダクトオーナーの役割というのは、価値の高さで優先順位を判断することです。 優先順位を明確化するために、ここではCost of Delay、つまり デリバリーが遅れた場合にどのくらい損をするかというコストを判断基準に使うのですが、これを阻害するさまざまな要因が現れてきます。例えば、あまり使われていないファイルの故障に対するクレーム、 SNS のコメント、あるいは社内の声の大きな人の存在、さらにはシステムの制約による作業の面倒さなどが、プロダクトオーナーの判断力を鈍らせます。
こうした阻害要因があっても正しく判断するためには、価値をKGI・KPIとして可視化し、戦略と整合が取れているか、関係者全体で合意し、それを拠り所として使えるような状態にしておくことがポイントとなります。
もう1つの障壁となるのがプロダクトオーナーのスキルの問題です。
プロダクトオーナーの必要スキルは以下のように非常に広範です。
・業務知識、ビジョン、戦略の理解という「ビジネス観点」
・ソリューション、開発技術、仕様整理などの「デジタル技術」
・会社組織のクセを理解して調整する「文化の観点」
個人でこれらすべてをカバーするには限界があります。
これを解決するためには、プロダクトオーナーをお客様との混成でチームとして構築し、お客様のスキルセットを補完する形でお互いをカバーしていくことが有効です。例えば業務部門のお客様であれば、ビジネス価値に基づくスコープ管理や優先順位判断は得意です。一方で開発知見は少ないことが多く、開発の勘所を押さえた要求仕様の整理や、テスト観点、受入基準などの整理は苦手な傾向にあります。システム部門ですとその逆の傾向になります。こうした相手側の組織に合わせてこちらの要員構成をすることにより、チーム全体としてカバーできるようになります。
また組織文化はお客様で暗黙知され無意識化されているため、私どものように外部からの観点で形式知とすることで意識化できやすいという利点があります。
このようにお客様の状況に合わせてバランスを勘案した要員構成をとり、さらにPOコーチなどにより第三者視点でアセスメントしていくことで、プロダクトオーナーの広範なロールを機能させていくことができると考えております。
障壁２：外部システム連携問題
外部システム連携問題に関する壁も2点あります。
1つ目は、開発を共に行う他組織・他システムのプロジェクトがウォーターフォール型であることも多いという点です。私たちがベースとしているSAFeはアジャイル型であり、ウォーターフォールとは考え方が全く異なるため、スムーズに連携を取るには工夫が必要です。
そこでウォーターフォール開発と共存するために、要件定義やシステム間テストは一緒に実施するプロセスと定義し、それに応じた計画としました。一方でアーキテクチャは疎結合にして極力個別に開発可能とし、インタフェース部分の合意方法を定めました。
このように共に実施する部分と、それぞれが並走可能な部分で緩急をつけ、合流時期とインタフェースを明確にして取り組むことが大切だと考えています。この際、対面とオンライン両方でコミュニケーションを密にとれるような環境を整備することがポイントです。
2つ目の障壁は外部システム連携の中でも特に難しいと思われる基幹システム連携についてです。
多くの業界の基幹システムは重厚長大で複雑な業務仕様やデータ構造のものが多く、直すのにとても時間がかかる傾向にあります。その一方で、価値の拡大のためにはここに収められているデータの活用とシステムとの連携が欠かせません。
そこでいかに省エネに連携していくかがポイントになってきます。例えばAPIのように疎結合でつなぐことができるアーキテクチャを活用したり、周辺にある機能のみを切り出して新しく作り直したりなど、小さく切り出し疎結合に繋げることを意識するのが重要であると考えています。
ただこれに関しては共通の解があるのではなく、それぞれの基幹システムに合わせたやり方を、関係者と地道に議論を積み重ねながら探すこと大切になってきます。
まとめ
本日は、デジタル化組織とは何か、そしてその適用事例のなかでぶつかる壁についてお話しさせていただきました。その内容を簡単にまとめると以下のスライドになります。これらの知見が皆様 の業務にとって何かのご参考になりますと幸いです。
