本記事は「大企業スキル勉強会 Advent Calendar 2024」の18日目です。この企画を立ち上げた大澤あつみさんからお声がけいただき、普段大企業で奮闘している一人として寄稿することになりました。
私は普段、社員数が万を超える日本の通信会社に勤めています。本記事では、大企業でのクラウド導入プロジェクトを推進してきた私の経験をもとに、どのような課題に直面し、それを乗り越えたのか、特に「失敗」から得た学びを共有したいと思います。
大企業での活動の経緯
はじめて私の話を聞く人のために、少しだけ背景を説明させてください。 （もう知ってるよ！って方は # 変革の実践と失敗からの学び までジャンプ！）
私は社会人になってから、フリーランスを長く経験したり、社員数数十人程度の中小企業にいたりとわりと自由に生きてきました。フリーランス時代や前職でも沢山の大規模システム開発の現場にエンジニアとして参画してきましたが、真の意味での大企業の価値観や論理といったものは今の会社に入ってから学びました。
入社当時、私は自社システムへのパブリッククラウドの導入をミッションに背負っていました。私はこの会社でどう振る舞えば過去の自分の経験が活きるのだろう、ということをずっと考え続けていました。あの頃は、物理インフラを維持することの大変さとプログラミングの世界の真実の両方を知っている人間が社内に誰もいなかったことから、このノウハウやスキルこそが私の存在価値であり、「技術力でこの会社を変えていくんだ」と心から信じていました。
しかし話はそんな簡単なものではありませんでした。
大企業に異文化を入れることの難しさ
今日はその詳細までは触れないので、もしご興味がれば以下の別記事やスライドを参照頂きたいのですが、
ざっくりまとめると、
「どんなに破壊的で素晴らしいテクノロジーが存在し、それを組織に適用することが有効的で正しいということが明白であっても、最後にそれを使うのは人間であり、人と組織がそれを受け入れられることができなければ、その技術は「狂人の独り言」にしかならない」
ということです。
これは、人のカラダで考えてみると分かりやすいかもしれません。
それまでに体内になかった「異分子」を体内に取り込むには、拒絶反応を緩和し、ギャップに慣れさせ、異分子が体内にあることが定常である、という状態を作り上げる必要があります。そしてそれにはとても長い時間がかかります。これは会社組織であっても同様ですし、むしろ人よりも長い時間を必要とするでしょう。
技術で人を説得しようとする行為は、鋭利な刃物を振り回して脅迫しているのとほとんど同じです。発言者のチカラ（ここでいうチカラは組織の中の発言力と読み替えてほしい）が強ければ一時的には人々はそれに従いますが、発言者がいなくなれば強制力の効果を失います。本当の意味で「あたりまえ」である状態を作り上げるためには、誰が始めたことなのかが分からなくなっても状態を維持できるように、内発的動機づけと外発的制約の両方を成立させる必要があります。
私は「クラウドの導入でこの会社を救う」というミッションをブラさず、そのための手段としてエンジニアリングスキルを使う事を他のメンバーに任せることにし、自らの役割を「人と組織に行動変容を起こさせること」に変更する決断をしました。
自社の文化醸成までに7年半もかかった原因
上記の登壇の際にも発表していますが、当社でパブリッククラウドが使われ始めてから、当たり前に使われるようになるまでに、実に7年以上もの時間を要しています。

なぜこんなに時間がかかったのか？は、私はこれまで「それが大企業だから」と言い訳してきました。
しかし本当の理由は、「私がヘタクソだったから」ではないか、と思っています。
私は組織改革という意味ではド素人であり、心理学/組織学/マーケティングを学校で学んでいるわけでもありません。そんな人間が、藻掻きながらもなんとか辿り着いたのが7年半後だった、というというだけです。もちろん、その道のりは決して平坦なものではありませんでした。
変革の実践と失敗からの学び
さて、いよいよ本題です。
これまでの外部登壇では、「どうやって組織変革を行ってきたのか？」という観点から、当社に適用してきた手法をあげつらえて発表してきました。これらの発表は実施した施策のうちのほんの一部であり、かつうまくいった例です。
これらの成功例の裏で、私はいくつもの失敗を重ねてきました。今回は、これら数々の失敗談から、学びの多かった3つを取り上げてお話ししてみたいと思います。
事例① 特任チームの解散
何が起きたのか？
社内でクラウド適用案件のための特任チームを組成し、複数の案件に適用実績を作っていきました。全ての案件で社内のセキュリティルールを正攻法で突破し、紆余曲折あって最終的に社内のセキュリティ基準改定を達成することができました。キャズムでいえばアーリーマジョリティに対するアプローチができる状態まで持って行くことができたのです。
参照元：https://digimarl.com/tips/detail/4616/
まさにここからがキャズム越えに向けた正念場だ、というときに、この特任チームおよびグループは全く事前の予告なく解体され、私自身を含む全社員がそれぞれ別々の案件にアサインされることになってしまいました。
なぜ起きてしまったのか？
最初に目指すべきゴールを最初の大きなステップである「セキュリティルールの改定」に設定し、上長への報告についてもそれにフォーカスを当てすぎた結果、このゴールが達成されれば維持モードに入ればよく、特命チームは不要だろう、と判断されてしまいました。
また、この特任チームは変革を起こすことには高い成果を残せましたが、直接的に会社に利益をもたらすことには成果を出せていませんでした。その結果、優秀な社員はより利益面での効果が出せるところにアサインすべきだ、という、経営層からすれば当然の判断が入ることになりました。
どうすれば良かったのか？
全体のロードマップやビジョンを分かりやすく図示し、1stフェーズ以降のステップや現在の位置、この後に何が必要なのかを明確に示せるようにすべきでした。
また精鋭チームを集めたことでクラウド活用推進を急進的に進めることができましたが、その成果を最大化しようとメンバーが優秀であることをアピールしすぎたため、いわゆる「期待値コントロール」に失敗してしまいした。
チームが上向きの成果を出せていると慢心し、これからもチームは維持できるはずだという過信から、リーダーとしてやるべきだった周囲へのプロジェクトビジョンやロードマップといった全体像や、ビジネスへの貢献度の提示といったエスカレーション活動を怠ったのがこの失敗を招いた最大の原因だったと考えています。
失敗事例②：組織の力学による誘引
何が起きたのか？
｢パブリッククラウドの全社横断での利用推進」をミッションに持つこのチームは、解散後、既存のパートナーメンバー（派遣社員）だけを残し、ここにパブリッククラウド未経験の社員をリーダーに据えたチームとして再編成されました。私は上申してこのチームにアドバイザーとして関わり続けたものの、このチームはそれとは真逆のミッションをもつ部署に編入されることになってしまいました。
その結果、メンバーの稼働割合をその部署が持つ本来の業務のほうに多く割かなければいけなくなったうえ、チームにメンバーが増える事もありませんでした。これにより、約１年間の間、パブリッククラウド推進活動は停滞せざるを得ない状況に陥ることとなりました。
なぜ起きてしまったのか？
会社組織には部署ごとにミッションが設定されており、そこに所属する社員はすべてそのミッションに従って業務にあたります。当然の事ながら自身の成果＝昇進／ボーナスetcも、そのミッションに紐付いて決定されます。これは本人の意思とは関係なく働く「組織の力学」とも言えるものです。

もともと全社横断型活動であり、かつ社外の製品を担いで社内を最適化していくというこのチームのミッションは、社内にある一般的な組織のそれとはまったく相容れないものであり、編入先は慎重に選ぶ必要がありました。しかしその編入先は「クラウド」というキーワードだけを共通項として決定されたものであり、相容れないミッションを持つこのチームは編入先の組織で再び「異分子」として扱われるようになってしまいました。しかし組織の力学を考えれば、チームの稼働が所属部門側のミッションに引きずられていくのは当然のことと言えます。
どうすれば良かったのか？
この当時私は組織再編の決定権こそなかったものの、このチームをどこの組織に置くべきか？という点についてはある程度言及できる立場にあったにも関わらず、そこに対して強く抗議したり積極的に提案をしていくといったことをやらなかったのが原因の一端にあります。またチームが解散されることが決定された時点で腹を括り、自分の異動先に持っていくから業務ごと引き取らせてくれ、と懇願するという方法もあったかもしれません。
当時の私は特任チームが解散したことに強いショックを受けてしまい、茫然自失としていたために上手く立ち回ることができませんでした。起きた事実を受け入れられず冷静な判断が行えなかったのは、ひとえに私の未熟さに原因があったと反省しています。
事例② 進まない文化醸成
何が起きたのか？
ことクラウドにおいては当時はまだ世間に情報も少なく、書籍なども殆どなかったため、私は社外のコミュニティに参加して学びを得ていました。この学習体験が本当によかったため、コミュニティ活動を社内に広めようと考え活動を開始していましたが、見様見真似で技術勉強会を開いても報発信する側とそれを受け取る側の二手に完全に分断されてしまい、活動がコミュニティに昇華することはありませんでした。
なぜ起きたしまったのか？
会社組織に新しい文化を取り入れるためには、まず人を動かす必要があります。人を動かすには動機が必要ですが、この活動に賛同してくれる人は多かったものの、それはあくまで傍観者＝Taker、受益者としての賛同であり、自らが活動をドライブする存在になることへの動機にはなりませんでした。
コミュニティ活動とは、相互コミュニケーションであり、お互いに貢献＝Giveしあう関係性の成立が必要です。この活動がコミュニティにならなかったのは、一方的に情報発信する場だけを作って満足してしまい、相互にコミュニケーションを取る場づくりをしようとしなかったことが主な原因です。
どうすれば良かったのか？
私が尊敬する 山本五十六 - Wikipedia が残した有名な名言があります。私はこれをエンタープライズにおける「改革の理」と呼んで、座右の銘の１つにしています。
ここにあるとおり、人を動かすためには「体験させるための場づくり」が必要になります。
目的が、コミュニティのプラクティスを広めたい、のであれば、コミュニティそのものをゼロから体験させてあげる必要がある。一方通行的に情報を発信し続けるだけでは、コミュニティを創ることはできないのです。
やってみせ ＝ やり方を実践し、この活動の趣旨や効果を伝え続ける
言って聞かせて ＝ 参加に誘う、登壇に誘う、運営に誘う
させてみて ＝ 実際に登壇したり運営するという経験を積んでもらう
褒めてやらねば ＝ 実施者には承認欲求をくすぐるような声掛けや反応をする
ここまでやってはじめて人は動きだすことができます。
この失敗からの学びは、後の社内コミュニティ文化浸透活動の推進に繋がり、ゼロからコミュニティ文化を構築する、という新しい目標に向かって突き進む原動力となりました。
さいごに
ものすごい長文を最後まで読んで頂き、ありがとうございました。
今回は、「大企業における変革の実践と失敗から学んだこと」というタイトルで記事を書いてみました。「失敗」と言う言葉はあまり使いたくないのですが、同じことで悩んだり引っ掛かってしまう人が少しでも減れば、この失敗は学びに昇華できたのかなと思います。
コミュニティに限らず、大企業で新たな文化の醸成を進めている方の一助になれば幸いです。
大企業で生きていくために必要となる能力ってとても独特ですよね？ こんなもの、いったい何の役に立つんだろう？とか、これから先のキャリアにプラスになるんだろうか？か不安ばかりでしたが、そんな迷いを救ってくれたのが「大企業スキル勉強会」でした。
そんな唯一無二のコミュニティを率いる大澤あつみさんのブログをご紹介して、このブログの締めにしたいと思います。
