誰もが忙しい。では、変革する時間があるのは誰なのか？

ある企業は、未来に向けて変革したいと考えています。トランスフォーメーションがなければ、破壊的な競合他社に脅かされるか、顧客にサービスを提供できなくなります。しかし、従業員が日々の仕事に忙殺されているため、トランスフォーメーションに着手できません。変革には努力が必要です。また、プロセスを変更すると同時に、そのプロセスを使ってビジネスを運営しなければなりません （「自転車に乗りながらタイヤを交換する」という問題）。新しいスキルの習得、新しいクラウド環境の準備、ビジネスプロセスの変更、企業の再編成など、トランスフォーメーションに必要な作業を、同じプロセスで忙しくしている間に誰が行うのでしょうか？

事実：従業員はすでに忙しいのです。彼らはフルタイムの仕事をしています。彼らは新しい仕事を待っているわけでもありません。もしそうであれば、あなたはそれを容認しないでしょうし、従業員が十分に活用されていなければ、多くの給料を支払うこともないでしょう。また、トランスフォーメーションの仕事をするために新しい従業員を増やすだけでは変革はできません。それではトランスフォーメーションとは言えず、新しい会社や事業部を作るようなものです。トランスフォーメーションは、すでに存在しているものを変えることなのです。

つまり、トランスフォーメーションを会社の日常業務の一部にする方法を見つけなければなりません。というのも、私たちはトランスフォーメーションを、開始点、終着点、一連のステップが明確に定義されたプロジェクトであるかのように言い続けているからです。以前のブログ記事で指摘したように、デジタルトランスフォーメーションは解釈がぶれる言葉です。デジタルトランスフォーメーションとは、企業の働き方を変えることだと理解するのに役立ちます。それは日常の活動や考え方を変えることです。

もちろん、大規模な技術的取り組み （例えばクラウドへの移行） も含まれますが、そうした取り組みは会社の働き方を変えるためのものです。これらは日常業務の変更によって推進されるのが最適なのです。この2つは一体となります。私が役に立つと思ったフレームワークは、ゴイコ・アジッチのインパクト・マッピングです。彼のフレームワークでは、ビジネスの目的から出発し、どのような行動の変化がその目的を達成するのに役立つかをマッピングします。次に、どのような技術的変化がその行動変容をサポートするかを考えます。

日々の活動とは別に、5年間の詳細なトランスフォーメーションロードマップをプロジェクト計画として作成すれば、問題はさらに悪化します。全員の承認を得るのに何年も費やすことになり、その結果、それを実行する自由な時間を持つ者がいなくなってしまうでしょう。

確かに、この質問の出し方には少し突飛なところがあります。私は冒頭で、あなたが会社の将来にとってトランスフォーメーションが不可欠だと判断し、会社が顧客のニーズに応えられなかったり、新たな競合他社 （おそらくは動きの速い新興企業） によって破壊されたりするリスクがあると仮定しました。会社の従業員には、会社の存続に必要なことをするための十分な時間がないようです。ここには明らかに優先順位の問題があります。会社の存続は最優先事項なので、リストの一番上になければなりません （優先順位設定の問題については、以前のブログ記事を参照）。何か他のことをしなければならないのです。

とはいえ、これは私が企業のリーダーたちから聞く話であり、企業のリーダーだった私には彼らがどこから来るのか理解できます。

変革するための時間を見つける

問題に対する考え方を逆転させてみてはどうでしょうか。新しいテクノロジーを構築し、それを使って従業員の働き方を変えるのではなく、従業員が望む働き方を変え、それをテクノロジーの変革の原動力にするのです。そのためのアイデアをいくつか紹介します。

まず、トランスフォーメーションへのコミットメントを示す必要があります。社員に変革を指示したり、計画を書いたり、スライドデッキを作ったりするだけでは不十分です。トランスフォーメーションは、時間に余裕があるときに取り組む余分なものではないというメッセージを伝えなければなりません。それは最優先事項 （冗長な表現？） であり、会社が計画していることではなく、行っていることなのです。リーダーはそれを実現するためならトレードオフもいといません。

ある AWS のお客様の幹部は最近、ベストプラクティスや新しい知識を共有するための週1回のセッションなど、自社のトランスフォーメーションを進めるために彼が作った知識共有コミュニティについて話してくれました。彼は金曜日の午後にミーティングを行っていましたが、私にはそれが間違っているように思えました。小さなことかもしれませんが、リーダーシップがそれを重要だと考えていないことを示していました。月曜日のゴールデンタイムに、新しい知識が次の週にどのように使われるかを説明するミーティングを行えば、知識共有セッションが役に立つかどうかは別として、その重要性をより強く示すことができます。トランスフォーメーションを強力に推進するには、知識の共有よりもはるかに多くの 「実行」 が必要なのです。

次に、インセンティブと役割の定義を変える必要があります。トランスフォーメーションのゴールは行動変容 （新しい仕事の仕方や考え方） であるため、新しい行動にインセンティブを与え、それをテクノロジー変革の要件推進に利用することで、トランスフォーメーションを最も効果的に進めることができます。インセンティブを変えなければ、従業員はこれまでと同じことを続けることになります。私は、必ずしも金銭的なインセンティブについて話しているのではなく、従業員の仕事の目的や、自分の役割にとっての成功がどのようなものかを変えただけです。新しいインセンティブの下では、「ただ仕事をする」だけでは失敗につながります。成功するためには、トランスフォーメーションのビジョンに沿って動く必要があるのです。

従業員は、トランスフォーメーションがどこに向かっているのかを明確に認識しなければなりません。詳細なロードマップではなく、変革後の企業の新しい状態と、それがどのように変わるのかというビジョンが重要です。ビジョンは、将来の状態がどのようにビジネス目標や組織の使命をよりよく達成するかを明確にする必要があります。漠然としたものや一般的なものであってはなりません。なぜなら、従業員の頭の中に、何を目指しているのか、なぜそれが重要なのかを明確に描かなければならないからです。忘れてはならないのは、副次的なプロジェクトとしてではなく、全員が日々の活動の中でトランスフォーメーションのビジョンに向かって取り組むことが目標だということです。

考えてみれば、「トランスフォーメーション」と呼ぶだけでも、まるで別個の、しかも非常に大規模なプロジェクトのように聞こえます。そして、誰がそんなことをする時間があるのでしょうか？　詳細なロードマップなしに、大きなコミットメントを進めるのは無責任に感じられます。しかし、コミットメントすべきはビジョンであって、実行の詳細ではありません。

長期的なロードマップの代わりに、大きなトランスフォーメーションの取り組みを一連のビジネス目標に変換し、その総和をトランスフォーメーションのビジョンとすることを試してみてはどうでしょうか。最初の目標は、会社の運営コストの構造を 20％ 削減することかもしれません。第二の目標は、特定のビジネスラインを拡大することかもしれません。第三の目標は、パンデミックやランサムウェア攻撃に対処できるよう、業務に回復力を持たせることかもしれません。これらの目標は具体的であり、日常的な企業活動に一体化しやすいのです。

物事を個々の目標に分解すると、トランスフォーメーションが断片化され、考え抜かれた技術的アーキテクチャーが稚拙なものになるのではないかと心配するかもしれません。高レベルのビジョンがそれを導き、アーキテクチャは反復的に形成され、洗練されていきます。

私が USCIS (訳者注：米国市民権・移民業務局) で担当したのは、巨大なトランスフォーメーションプロジェクトでした。私たちの最初の間違いは、このプロジェクトを一枚岩の取り組みと考えたことでした。つまり、 USCIS の紙プロセスをすべてデジタルプロセスにするつもりだったのです。達成可能なビジネス成果を明確にしたほうがよかったのです。オフィス間で移動する紙の量を減らしたいことは分かっていました。そのため、最も紙の移動が多い業務に優先的に取り組むことができました。また、不正申請の検出を強化したいこともわかっていたので、不正の可能性が最も高い移民給付金の種類に焦点を絞ることができました。他の目標についても同様です。このように目標を明確にしたことで、副業として技術インフラを構築するのではなく、日常業務と結びつけてトランスフォーメーションを進めることができました。

CIO はよく私に、ビジネス機能への要求事項ですでに手一杯なのに、どうやってレガシーな技術的負債を是正する時間を確保できるのかと尋ねてきます。うまくいかないのは、新規開発をすべて中止し、システムのモダナイズだけに何年も費やすことです。企業は何年もじっとしているわけにはいきません。その代わりに私は、新規開発作業は継続するが、納品される作業の品質については、安全性、回復力、保守性、自動的にデプロイ可能でテスト可能であることなど、非常に高い基準を採用することをよく勧めます。この標準を達成するためには、レガシーシステムに対する作業においても、レガシーの技術的負債を解決する必要がありますが、それは新機能の開発をサポートする範囲に限られます。こうして、変革的作業は日常業務の一部となっていくのです。

その他の留意点

従業員のトレーニングに時間を割くことは重要ですが、それが新しいスキルを開発するための戦略のすべてというわけにはいきません。技術者は、実践的な作業を行い、他の技術者とペアを組んで仕事を提供することによって、最もよく学ぶことができます。新しいスキルは、前提条件ではなく、トランスフォーメーションのアウトプットとして考えるのです。

組織は、トランスフォーメーションの責任者、 AWS ではシングルスレッドリーダーと呼んでいる者を任命することがあります。トランスフォーメーションに完全に専念する人をリーダーの役割に据えることは、強力なものになり得えます。しかし、この人物がトランスフォーメーションを実施する従業員に対する直接的な管理権限を持っていない場合、まだ問題があります。従業員はどうやって変革活動のための時間を作るのでしょうか？　また、トランスフォーメーションには従業員の仕事を変える必要があるため、トランスフォーメーションの責任者はどのようにその変化を引き起こすのでしょうか？

シングルスレッドリーダーを置くことは決して悪い考えではないですが、多忙な従業員がその努力の一部となれるよう、組織のリーダー全体のコミットメントと組み合わせる必要がります。トランスフォーメーションが重要だと言うだけでは十分ではありませんし、肩書きに「トランスフォーメーション」とあるシニアリーダーを任命してその重要性を伝えるだけでも十分ではありません。コミットメントとは、トランスフォーメーションを全員の日々の活動やインセンティブの一部にすることを意味するのです。

新しい行動にインセンティブを与えて変革するのは時間がかかるように聞こえるかもしれませんが、決意をもってやればそんなことはありません。社員が暇になるまで待つよりも、確実に速くなるのです。

逆算と前進

変革を日常的な活動から遠ざけすぎると、トランスフォーメーションのための時間を確保できません。変革を日常業務の一部にするためには、テクノロジーを進化させると同時に行動を変える必要があります。従業員は、与えられた目標を達成するために時間を費やします。彼らのインセンティブが変わらなければ、トランスフォーメーションは起こりません。一方、あなたが望む新しい行動に対して従業員にインセンティブを与えることで、従業員はトランスフォーメーションの推進に参加するようになります。私たちは時々、物事を逆から考えることがあるのです！

この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。原文はこちらです。