目的は同じなのに、なぜ上司と現場はすれ違ってしまうのか？　障壁や摩擦の発生を防ぐために理解したい「前提条件の違い」

中島氏の自己紹介

中島倫明氏：本セッションに参加いただきありがとうございます。ここでは「IaC や CI に理解のある上司になる（or なってもらう）には」というタイトルでお話しします。どうぞよろしくお願いします。

まずは発表に先立ち、簡単に自己紹介します。私は中島と申します。ふだんはRed Hatという会社で、ITインフラの自動化推進支援をしています。Red HatはAnsibleという自動化の製品を持っているので、こちらを使ってさまざまなお客さまのITインフラの自動化推進をやっています。

そのほかに、各種教育機関でのクラウド自動化に関する人材育成の講師をやっていたり、コミュニティでの活動というところでOpenStackやAnsibleの領域で活動したりしています。

効率化におけるトップダウン・ボトムアップのよくある会話

それでは本編に入っていきたいと思います。（スライドを示して）本日お話をしたい内容ですが、みなさんの中にも、例えばこういう経験をしたことがある方もいるんじゃないかなと思います。

左側の吹き出しに注目してほしいのですが、例えば現場サイドから「Ansibleを使って自動化したい」「Gitを使ってもっと効率的に仕事がしたい」「IaCやCIみたいなもの導入していって更なる効率化を追求していきたい」という、「新しいことをやってもっと効率化していきたい」という声があります。

一方で、右側のその上司やマネージャー層の人たちは「もっとコストを抑えたい」「リードタイムをもっと短くできないの？」「品質をもっと上げたい」とか、そういうことを考えています。これらの声は話しているレイヤーに多少差異はあれども、基本的に目指しているものは一緒のはずなんですよね。

同じところを見ているはずなのですが、左側から効率化をしたい人もいれば、上の目線から効率化をしたいと考えている人もいる。では、実際にこの取り組みを進めようとするとどんなことが起きるか。

ボトムアップ視点から見ると、現場サイドからは例えば「XXXを使ってもっと効率化がしたいんです」という話が上がってきて、それに対してマネージャーが「これで何ができるの？」と。（そこで現場サイドが）「それで自動化して効率化ができるんですよ」と。

「いいね、具体的にどうやって使うの？」「この技術はこうで、こんなことができます」「詳しくはよくわからないのだけれども、どのくらいの効果が出るの？」「たぶんこのぐらいだと思います」「え、それだけしか出ないの？　さらに開発やメンテナンスのコストもかかるでしょ？」「確かにそうですね」と。

「じゃあちょっとやるのは難しいかな。まずは今までの現状維持でやっておいて」というようなかたちで、せっかく現場のほうがモチベーションを上げて「これをやりたいです」と言っているのに、上司側でストップされてしまうケースがあります。

逆に上からは、「もっと自動化して効率化したいのだけれど何かアイデアはある？」と。「最近だと例えばXXXとかYYYとかありますね」「なるほど、いいね。それは具体的にどう使うものなの？」「この技術はこうで、こんなことができます」と。

「じゃあそれがどのぐらい効果が出るか試算できる？」「計算してみるとたぶんこのぐらいだと思います」「あれ？　なんか思っていたより効果がでないね」「さらに開発でこのぐらいのコストなどがかかると思いますよ」と。「え、そんなにかかるの？　もしかしてこれだとやらないほうがいいの？」「そうかもしれませんね」と。

これは上の人たちが現状を改善したいと思っても、なかなかうまく進まない一例です。先ほどはボトムアップでしたが、今回はトップダウンで進めようとしたのにうまくいかずにストップしてしまっている状態です。

この状態では、両方が「なかなかうまくいかないな」と思っているわけです。お互いに考えていることは基本的に一緒なはずなのに、なぜか話がすれ違ってしまって、うまく進まない。

その結果、そもそも取り組み自体が始まらなかったり、始まっても小さく取り組んで終わってしまったり、一部の人だけがやってその人がいなくなったらブラックボックスや負の遺産としてその部署に残ってしまったりと、いろいろなことが起きてしまいます。

なぜこんなことが起きるのかですが、実際に私もさまざまなお客さまを支援していく中で、こういったやり取りは数限りなく繰り返されてきました。その原因をもう少し見ていきましょう。

すれ違いの原因は「前提条件の違い」

（スライドを示して）まずはスライドの下側です。お互いの前提条件が異なっています。例えば立場の違いというところで、上司やマネージャーが見ているビューと現場目線で見ているビューは当然ズレがあるので、そこで前提条件は異なっていますよね。

さらに同じシステムを担当している部署だとしても、「システムの全体像をどう捉えているのか」「効率化というものの範囲をどう捉えているのか」も、人によってぜんぜん違ったりします。

あとは、（これは）あるあるですが、問題だと思っている場所が人によってぜんぜん違うケース。これは単純にマネージャーと現場でズレているだけではなくて、同じプロジェクトで同じ上司を持っている現場サイドの人たちでも、どこが問題だと思っているのかはぜんぜん違ったりします。

よくあるのが、最近印象深かったものが鮮明に残ってしまう場合です。例えば、最近障害が起きて、その解析や回復にすごく手間がかかって、そのことが頭に残っている状態で、イベントで障害からの復旧や原因追及に時間がかかると、「やはり自分たちの問題は障害対応なんだ」と捉えてしまうケースがあります。

単に印象深かったことは間違いないのですが、「それが本当に問題なのか」は必ずしも当てはまるとは限らない状態になってきます。

さらにそれぞれのツールの理解度や、それをどう使っていくのかという考え方も違ったりするので、ツールを持ってきたとしても、それが作用する場所がみんなバラバラです。ある人は「このツールを使ってここを効率化したい」と思っていても、別の人はぜんぜん違うところを効率化したいと考えているかもしれません。こんなふうに、みんな考えていることがバラバラだし、前提条件が大きく異なっています。

この（状況の）中で「効率化する」という大きすぎるゴールを設定してみたり、逆に自動化やツールという手段での局所的なアプローチを考えようとしたりしても、なかなかこの2つを効率化、または道具を使った手段にアプローチしていくのは困難です。

それは、前提がみんな異なっていて、重なり合う部分が非常に少なくなっているからです。たまたま重なり合う部分にみんなの目が行けばいいのですが、実際にはそもそも重なっていないことも多くて、みんなで一致して「ここを効率化していこう」という状態にすごくなりづらい状態です。

単純に今までずっと一緒に仕事をしてきてツーカーで意思疎通ができるような関係であっても、物事を進める時にはこういった前提条件の違いからくる、いろいろな障壁や摩擦が発生してしまう事態が起きてしまうんですね。

このセッションでは、「ではこういう状況を脱して自動化していくためにはどう考えていけばいいのか」「どういうポイントを押さえていけばいいのか」という部分についてお話しします。

このあとの話ですが、まずは「前提条件を合わせていくために何をやればいいんでしたっけ？」というものです。　そこで前提条件を合わせたあとに、「どの課題を解決するのか、どう明確化していくのか」を話します。ここまでくれば最後は簡単ですが「課題に対してどういう手段でアプローチしていくのかを決めていく」と。こういう流れでお話していきたいと思います。

（次回に続く）