テクノロジーがあらゆる業界全体に普及していくようすを目の当たりにできたのは、私のこれまでのキャリアの中でも特に心を躍らせる経験でした。15 年前には社内ストレージ、ファイアウォール、VPN など、初めて遭遇するテクノロジーの設定に苦戦していたような会社も、今では専門のエンジニアリング チームを抱え、アプリやサービスの開発に力を注いでいます。たとえば、靴メーカーが e コマース アプリを開発したり、百貨店が店舗とオンライン ショップの売上向上につながるテクノロジーを開発したり、重機メーカーが技術サービスと自動走行トラクターを開発することは、今や珍しいことではありません。これまで保守的と思われてきた多くの企業が、生き残りを賭けて大規模なデジタルトランスフォーメーション(digital transformation) に取り組んでいます。
しかし、変革を起こすのは簡単なことではありません。特にデジタル トランスフォーメーションのような大規模で体系的な変革には、大きな困難が伴います。私自身、IT 業界に身を置く 20 年の間に多数の企業とかかわり、高い目的意識を掲げて変革に取り組んでも結果を出せなかった例をいくつも見てきました。とは言っても完全な失敗はまれで、チームや部門レベルでの小さな成功は果たせるのです。しかし、大規模なプロジェクトになると途中で失速してしまう。そこに特定のパターンがあることに気付きました。今回の記事では、デジタル トランスフォーメーションの大きな障害となる 3 つの要因と、その回避方法についてご説明します。
チームの参加意欲の欠如
大規模な構造変革は、トップダウンではなくボトムアップで進めなくてはなりません。どんな組織でも、新しいメール システムやセキュリティ ツールの導入、DevOps による事業部門の再編成といった構造変革に踏み出す前に、リーダーがどのようにしてチームの士気を高め、メンバー全員をプロジェクトに積極的に参加させるかを考える必要があります。「どうせすぐに頓挫するに違いない」とプロジェクトを否定的に捉えるメンバーがいないとも限らないからです。
リーダーは、プロジェクトの成功のためには手続きの変更だけでなく、企業文化の変革が欠かせないことを認識する必要があります。従業員は、新しい世界に向けて一歩を踏み出すにあたって、自分が果たすべき役割を理解しているでしょうか。チームの一員として、プロジェクトの一翼を担うつもりがあるでしょうか。
大規模な変革に取り組むときは、他のメンバーを鼓舞し、モチベーションを高める社内の旗振り役が必要です。この役目はただ指名すればよいものではありません。プロジェクトの重要性をよく理解し、やり遂げる意欲のある人物、このプロジェクトが業務や職場環境の改善につながる理由と、そこにたどりつくまでのプロセスを把握している人物が適任です。
大規模なプロジェクトを管理し、遂行するためには、このプロジェクトに参加する人々のモチベーションを高める方法を知っていることが重要です。たとえば、会社が新しいプロジェクトを立ち上げ、大規模な生産体制に入ろうとするとき、このプロジェクトが会社の EPS (1 株あたりの収益) にどれほどの影響を及ぼすかを説明することで従業員を味方につけようとした例を何度か目にしました。しかし、大株主でもない限り EPS にはさほど興味がありませんから、この方法では従業員の士気は高まりません。やる気を刺激する方法はもっとシンプルです。たとえば、休暇を用意したり、次のプロジェクトの予算を増額したり方法が有効でしょう。
標準化の失敗
かつて、分散環境で 5 種類のオペレーティング システムを運用しているお客様を支援したことがありました。もちろん、最初からその状態だったわけではなく、企業文化に問題があり、社内のいくつかのグループが無計画に新しい OS を導入した結果、システムが乱立してしまったのです。その状況でも、アプリケーション チームは特定のアプリケーションを単一の標準的な方法で運用すればよいため、それほど困っていませんでした。余分な負担を強いられたのはシステム チームです。OS が関係するプロセスごとに分岐を用意しなくてはなりません。監査、セキュリティ管理、モニタリング、バックアップ、プロビジョニングなど、あらゆる処理に if 文をもう 1 つずつ追加する必要がありました。if 文を追加するたびに、プログラムは複雑さを増します。確認すべきパスが 2 つになると、やがて組織にとっての足かせになっていることに気づくでしょう。しかも、半永久的に新しい言語にも対応し続けなくてはいけません。
この状況では莫大なコストがかかります。金額面だけでなく、時間と労力の浪費にもつながり、さらなる問題が生じてしまうのです。最終的に、メインで使用していた 5 つのオペレーティング システムを 2 つに減らすのに 9 年も費やしました。このケースは、標準化の重要性を実感する良いきっかけになりました。アプリケーションの OS を選択した人たちは、その決定がどれほどの問題を生み出すかわかっていなかったのです。
ツール、方法、プロセスの種類を減らせば、変化はスムーズになります。大企業にとって、新しい標準の実装は、数年にわたる重要な取り組みです。その過程で、手放さなくてはならないものもあります。しかし、こうして痛みに耐えて変化を起こせば、わずかながら前進し、新しい一歩を踏み出すことができるのです。常に難しい選択を迫られますが、他に方法はありません。標準化できなければ、プロジェクトの進行中ずっと複数の要素に対応しなくてはならず、最悪の事態を招く結果となるでしょう。標準化とはつまり、全体を最適化することです。そして、全体の最適化は、ときに部分的な最適化にもなり得ます。場合によっては部分的な最適化が正解となることを従業員全員が理解していなければなりません。
標準化は、変数を少なくする強力な手段となります。変数が少なければ「もしこうだったら…」と他の可能性を考える場面も少なくなるため、細かい調整が不要になり、問題発生を防ぐことができます。
変化への抵抗感
これは非常によくある問題です。改善の必要性は理解しつつも、変化を望んでいない会社をこれまでにいくつも見てきました。以前、大手銀行の幹部数名とエンジニアリングの戦略について話し合う機会がありました。私が何かを提案するたびに、先方は「いやあ、それはゴー サインが出ないでしょうね」と言うのです。何回かそのようなやり取りがあった後、私はとうとう質問しました。「ゴー サインが出ないとおっしゃいますが、どなたがお決めになるのですか? あなた方かと思っていました」
変化は起こり始めればスピーディに進みますが、これまでの常識を覆そうとする気持ちの方にブレーキがかかってしまうことがあります。もちろん、それは簡単なことではありません。だれも慣れ親しんだ方法を手放したくはないでしょう。成功につながるツールや戦略がわかっていても、いざ導入する段階になると億劫さが勝ってしまうものです。しかし、大きな変革を成し遂げるつもりなら、前に進むしかありません。
変化は絶えず起こるもの。リーダーはそのことを理解し、常に意識している必要があります。
まとめ
私がプロジェクトで行き詰まったときは、まず今回ご紹介した 3 つの障害の有無を確認し、障害が見つかった場合は解決方法を検討します。また、成果をアピールすることで、今はプロジェクトのロールアウトに問題が発生しているだけでまだ見切りをつける段階ではないと示します。どんなプロジェクトにも難局はありますが、前進する方向がわずかでも見えているなら、解決策は見つかるものです。
最後に、ほとんどの問題はテクニカルなものではなく、企業文化にかかわるものであるという点を強調しておきます。IT 企業のマネージャーの主な役割は、チームのモチベーションとやる気を保たせることですが、テクノロジー畑の人たちは、人間に本来備わっているモチベーションの引き上げ方を戦略的に考えることが得意でない場合もあります。しかし、これは学ぶ価値のある重要なスキルです。
変革は決して生易しいものではありません。変化を妨げる最も一般的な障害は、チームの参加意欲の欠如、標準化の失敗、変化への抵抗感だと私は考えています。これらの障害を克服するために、時間とエネルギーを費やし、やり遂げようという気持ちを持ち続ければ、最後には必ず結果を出すことができるでしょう。
