前提がズレるインフラの世界では、全体の可視化と是正が重要
課題を明確化するための「バリューストリームマッピング」活用

前提条件を揃えておく時に押さえておくべきポイント

中島倫明氏：というわけで、ここからが本題になります。前提条件を揃えて課題と手段を明確化する進め方というところで、まずは我々が押さえておくべき1つのポイントがあります。それは「今と昔でインフラがどう変わっているのか」というところです。

ここでは特に変化のポイントの中でもインフラ担当者が時間をどう使っているのかという部分に注目して見ていきたいと思います。

（スライドを示して）その変化をお話しするために、2つの円グラフを表示しています。左と右です。まず左から注目していきます。これは、インフラ担当者がふだんの時間をどう使っているのかをすごく単純化して、2つに分類して、その比率を円グラフで表しているものです。

（円グラフの）青い部分が実作業となっています。これはすごくわかりやすくて、インフラの担当者がサーバーにログインして何か作業をしている、ネットワーク機器にログインしてコマンドを打っているなど、実際の環境に触っている時間だと思ってください。

一方で、左側の赤い部分が何を表しているかというと、実作業する上で、当然いきなり環境を触って変更し始める人はいないと思います。環境を変更するためにはいろいろな準備をしてから臨むと思うので、この赤い部分は調整準備を表しています。左の円グラフの状態は、これがきれいに半分半分ぐらいの状態になっていますね。

これは、過去の比較的シンプルなシステムにおいては確かにそうだったでしょう。一方で、現代の大規模で複雑化したシステムはどうなっているかというと、右側の状態になっています。

違いは一目瞭然ですが、赤い部分がすごく伸びてきていて膨らんでいるので、青い部分の比率が相対的に下がっている状態になっています。

これは作業量が減ったというよりも、全体のバランスで見た時に（実作業が）相対的に減っているということです。みなさんの中にも覚えがある方がいるんじゃないかなと思いますが、ふだんの仕事を振り返ってみるといつもExcelやPowerPointで資料を作っていたり、誰かに説明するための資料を作っていたりする。

誰かに依頼するための資料を作っていたり、誰かの作った資料をレビューしていたり、メールで調整を誰かに依頼をしていたり……。

そういったところに多くの時間が費やされていって、実際に環境に触れる時間がどんどん減っていると感じている方も多いのではないかと思います。これはやはり当然で、システムやモノがシンプルで規模もあまり大きくなかった昔は、1つのシステムのインフラに関わってくるメンバーが少なかったのです。しかし規模が大きくなり、それぞれの要素も複雑になっていきました。

例えば、サーバーなどが典型だと思いますが、昔のシステムは1、2台のサーバーで動かしていました。でも今ではサーバーが20～30台並んでいて、そのサーバーの中も階層化されていて、さらにその階層の中もコンテナで細分化され、コンテナの中にはいろいろなミドルウェアのスタックが昔よりも分厚く積み上がっています。つまり、システムが昔に比べて非常に大規模で複雑化してきています。

そこで何が起きるのかというと、当然、大きくなって複雑化したものを少人数でメンテナンスして維持し続けるというのは難しいので、インフラに関わる人間が増えていきます。人間が増えると何が起きるかというと、関係者といろいろな確認や調整を行わないといけなくなります。その結果、（グラフの）赤い部分が膨らんでいくというところですね。

「実際にこうなっていますよ」という例をあとで見せますが、私がふだん仕事をしている中でも、これを如実に感じる部分がやはりあります。この変化を押さえた上で、我々が気をつけないといけないポイントが1つあります。

（スライドを示して）我々は、特に「自動化などで効率化していきましょう」と考えた時に、こういう考え方をすごくしてしまいがちです。自動化で効率化しようと考えたら、やはり（グラフの）青い部分に注目したくなるんですよね。

実際に人間がコマンドを打っているので、その人間の代わりにシェルスクリプトやなにかツールに手順を置き換えることで効率化していきましょうという考え方です。インフラの世界では、スクリプトなどを書いて自動化することはけっこう日常的にやられてきています。みなさんの中で、実際にやったことがある方も多いのではないかと思います。

つまり、実績や伝統があって、非常にいろいろなノウハウが溜まっている領域ということです。このやり方は確かに左の状態であれば良く機能しますが、右の状態になってしまうと相対的に青い部分の比率が下がったことによって、全体に及ぼす自動化の効果がすごく小さくなってしまいます。

しかし、なぜか我々は過去の成功体験や過去にやってきてうまくいったことを引き継いで仕事を進めていくケースが多いので、やはり多くの方がこういうアプローチをしてしまいます。

ただ、現代のインフラにおいてはなかなかこれがうまく機能しない背景があります。「では、どうしていけばいいんですか」と。

こういった変化があるから、上司が現場にいた頃にはすごくうまく行っていても、そのイメージでこちら側を考えてしまうと、先ほどのような認識の齟齬が生まれます。「あれ？　これはもっと効果が出ると思っていたのだけれど、ぜんぜん出ないね」という状態になってしまうということです。

「バリューストリームマッピング」で課題を可視化する

認識の齟齬が生まれている状態を是正してどう考えていけばいいのかというところで、自分たちが対象としているものをちゃんと可視化していくことが非常に重要になります。ここで、バリューストリームマッピング（VSM）という手法を紹介したいと思います。

（スライドを示して）これは、仮想マシンを1台払い出す例を、事細かに可視化しているものになります。この付箋の一つひとつがインフラ部門の中で行われる一つひとつのタスクを表しているので、それらがどうつながって全体が動いているのかをちゃんと見ていきましょうと。

それぞれ必要な数値を出していって、それぞれのタスクに「どのぐらいリードタイムがかかっているのか」「どのぐらい工数がかかっているのか」「手戻りはどのぐらいの頻度で起きているのか」というところをちゃんと数字化して積み上げていきます。

こういった全体像をまず把握するのが非常に重要になってきます。これがないと、いろいろなものが空中戦になっていたり、過去の事象にすごく囚われた発言になってしまったり、お互いに認識がすごくズレている状態での対話になってしまいます。なので最初の一歩として、こういったプロセスをちゃんと可視化していくことが非常に重要になってきます。

プロセスの可視化を行うと、いろいろなものが見えてくるんですね。例えば、先ほど「作業をしている時間がどんどん減っていますよ」という話がありましたが、実際に仮想マシンを払い出す例でも確かにそうなっています。

（スライドを示して）青い部分が実際に環境を触っている部分で、赤い部分は環境にまったく触っていない、ほぼ机上の作業ばかりなんですね。

（スライドを示して）さらにこの赤い部分がどうなっているのかという話を掘り下げていくと、この例ではこう分類できます。

例えば、仮想マシンを払い出す時に、依頼している部署といろいろな調整を行っています。「これはこういうスペックで払い出すんですね」「こういうネットワーク構造が必要なのですね」というようなものです。

こうした調整から始まり、仮想マシンを払い出すのであれば、ネットワーク担当者からIPアドレスを払い出してもらうためにいろいろな情報を連携します。また、実際にここまでくるといろいろな情報が揃ってくるので、その情報を使って仮想マシンを払い出すために作業手順書や、テスト項目のようなものを作って内部でレビューをしたりもします。

さらに仮想マシン（VM）が作成されたあとには、監視チームと連携し、作成された仮想マシンに監視設定を行っていくかたちで、全体の構造が見えてきます。こうなってくると、我々がどの部分に時間がかかっているのかが見えてくるんですね。

こうして全体像を把握して前提条件を合わせたあとは、課題の設定というところで、「我々の課題はここなんだ」などというのが決まってくるわけです。

（スライドを示して）これはちょっと簡単に分類していますが、「要件の分類」「他部署連携」「作業の準備と品質確認」です。どこに時間がかかっているかです。

例えば、他部署との連携で人と人とのやり取りに時間がかかっているケースにはどんなアプローチが有効かというと、セルフサービス化です。

従来は複数のチームが人と人とが連携していろいろな調整を行って物事を決めていたのですが、それを1つのチームが自分たちのやっていることをセルフサービス化して、イチイチ自分たちの調整が必要なく物事が進む状態を作ってあげましょうと。

先ほどの例でいえば「払い出しを依頼する」「IPアドレスをもらうために調整する」「監視チームと連携する」部分ですね。こういう部分をセルフサービス化することで、お互いの調整事項をなくしていきましょうというアプローチが考えられます。

例えば、作業手順書やテスト項目を作るのにすごく時間がかかっている場合。

であれば、インフラCI化をしたり、人間と人間がドキュメントを使って品質を確認するのではなく、最初から自動化コードやパラメータを作ってあげて、システムで品質を判定することで全体の効率を上げたりしていきましょう（となります）。

こうして問題を明確化すると、そこで必要な手順もある程度自ずと決まっていきます。

そういうかたちで整理していくと、先ほどの非常に複雑だった仮想マシンを払い出す作業もとてもシンプルになって、自動化や効率化を考えられるようになります。

さらに、これをいきなり全体でやる必要もなくて、全体像さえみんなで合意ができていれば「では、まずここからやりましょう」「ここがちょっと簡単にできそうだからここからやりましょう」というようなかたちで、最終的なゴールをみんなで共有していきながら、「では、最初に何をやろうか」という議論ができるようになっていきます。前提条件を揃えて課題を明確化してから、そこに当て込む手順を決めていくことができます。

当たり前のように見えるかもしれませんが、インフラの世界ではみんなの前提条件が大きくズレているということが非常に多いのです。つまり、その部分を全体で可視化していくことで是正して、ちゃんと進めたいことを進めていくことにつながりやすくなっていきます。

自動化や効率化を進めるためには前提条件のすり合わせが必要

ここで最後にまとめます。自動化や効率化を進めるためには、前提条件のすり合わせが非常に重要になります。そのためには、まずプロセス全体をちゃんと可視化していきましょう。これにはバリューストリームマッピングのやり方が非常に重要になってきます。

「バリューストリームマッピング」という名前で検索すると、どう作るかであったり、最近はこういったものを作成するためのオンラインの支援ツールもあります。こういうものを使うと、リモートワークでみんなでコラボをしながら作業することもできます。ぜひ利用してみてください。特に最初の一歩を楽にしてくれるので、検討していただければと思います。

全体像が可視化できたら、その中で我々の課題はどの部分にあるのかを明確化していきます。自分たちのプロセスでどこに時間がかかっているのかをちゃんと数値化して、特定していきましょう。過去の事例や印象だけで決めないということですね。

そこから課題に対する手段を決めていきましょう。AnsibleやGitなどのインフラCIみたいなものは手段や道具なので、それらをどう活用していくのかは完全に現場の人の腕次第になります。

単純に手順を置き換えるだけではなくて、セルフサービス化やCI化していくなど、そういったところをうまく活用していくことで、さまざまな課題が解決できるようになっていきます。こういう話を現場サイドから持っていけば、上司の人も全体の構造としてわかりやすく、上から下まで一気通貫でつながっていくことができます。

やはりストーリーがつながっていることが非常に重要で、ストーリーさえ描けてしまえば、社内でどう効率化を進めていくかの議論がすごくやりやすくなっていきます。

ぜひとも、前提条件をすり合わせるところに注目してやってみてください。「これで合っている」と思いこんでいるかもしれませんが、案外というか、同じ社内や同じグループ、同じチームの人ですら、ほぼ確実にズレていることがほとんどなので、まずはここを注目してやるといいかなと思います。

それでは、私の発表は以上で終わります。ご清聴ありがとうございました。