知らないでは済まされない「DevOps」スペシャリストたちが語るその本質と目的

業界のスペシャリストが語るDevOps

鈴木いっぺい氏（以下、鈴木）：みなさん、おはようございます。DevOpsをテーマとさせていただきたいと思っています。50分の間、ぜひお付き合いのほど、よろしくお願いいたします。

牛尾剛氏（以下、牛尾）：DevOps！

吉羽龍太郎氏（以下、吉羽）：お約束ですね（笑）。

鈴木：お約束の雄叫びを毎回させていただいています。これはもう今年の5月に行った、マイクロソフトさんの「de:code」のイベントからの恒例とさせていただいております。

というのも、DevOpsというキーワード、みなさんそれぞれいろいろな思い入れがあると思うんですけれども、この言葉が1人歩きする状況というもの、とくに日本において、みなさんDevOpsという言葉をいかに違う定義で取られているかということを、非常に懸念している方々もおりますし、なんと捉えていいか非常に難しい課題だと捉えている方も多くいらっしゃると思います。

今日は、業界のなかでDevOpsを実際に実践されているスペシャリスト、プロフェッショナルな方を3名お呼びしております。

私はクリエーションラインという会社の人間なんですけれども、モデレーターをさせていただきます。さまざまなオープンソースのいろんなシステムを手がけさせていただいております。

一番左にいるマイクロソフトの方が牛尾さん。マイクロソフトのAzureの代表というふうに見ていただければと思います。

DevOpsというのは、もちろんITの環境なんですけれども、クラウドがあったり、エンタープライズがあったり、インターネット系の会社、さまざまな環境のなかで、それぞれの代表を選りすぐっております。

真ん中におります、吉羽さん。この方は本もずいぶん書かれているので、ご存知の方も非常に多いと思いますけれども、エンタープライズに対する辛口な切り口。

吉羽：いやいや、優しいですよ（笑）。

鈴木：もう泣く子も黙る、歩いたあとにぺんぺん草も生えないという。

（会場笑）

鈴木：エンタープライズに対して非常に深いご知見とご経験のある、そういった角度からDevOpsを語っていただこうと思っています。

そして、一番右にいらっしゃいます、塚さん。こちら、ヤフージャパンの代表でございます。

ヤフーは、当然日本を代表するというか、世界を代表するインターネット企業でありながらも、エンタープライズの要素も併せ持つという、ある意味では非常に複雑な環境のなかで、あえて「DevOpsというものの位置づけ」という、非常にユニークなかたちでDevOpsを取り組まれている方でございます。

こういった方々に対して、5つほど質問をさせていただいて、ざっくばらんに語っていただこうという50分でございます。

見かけ上、モデレータのような顔をしておりますけれども、ほとんど自信がありません。この方々は火が点くとどんどん燃え盛っていきますので、どちらかというと止めるほうに回って行く、そんなパターンになるんじゃないかなと想定していますが、ぜひお手柔らかによろしくお願いいたします。

DevOpsはツールの話として捉えられている

鈴木：さっそくなんですが、DevOpsというものについてさまざまな本が出ておりまして、一番新しいものが、この黄色い『DevOps Handbook』というような著作物が非常に多く出ております。日本でも当然、この方々も関与されているDevOpsに関する本、改善に関する本が出ております。

テーマの1つ、第1の質問としては、冒頭にも申し上げましたけれども、日本国内で「DevOps」という言葉がどういうふうに捉えられているのか。DevOpsという言葉を聞いたときに、この業界にいる方々がいったいどういうイメージを持たれているのか。この方々の持たれている印象をまず語っていただいて、そこを切り口にしたいと思っています。

順番はもう自由にご発言いただいてけっこうですので。まあ一応礼儀にしたがって真ん中からいきましょうか。

吉羽：DevOpsがどう捉えられているかという意味でいうと、けっこうツールの話として捉えている方というのがすごく多くて。

例えば、「Infrastructure as Code（これまで手動で行ってきたインフラの構成管理を、コードによって自動的に行う仕組みのこと）」で、そのインフラのプロビジョニングとかデプロイを自動化しましょうみたいな話や、ツールとか自動化という文脈ですごく語られていますし、実際いろんなベンダーさんがDevOpsツールみたいな売り方をしてしまっているので、どうもツール主導というかツール偏重というか、僕にはそういう感じに見えていますね。

塚穣氏（以下、塚）：じゃあ、僕もそこに乗っかって。ヤフーは、ある種「DevOps」という言葉の発祥だったような気がするんですよね。Flickrが……。

吉羽：「10+ deploys per day」。

塚：そうですね。今のヤフーはどうなんだというのはあるんですけれども、やっぱりツールですね。「ツールを使って楽をしよう」みたいな。「いや、まあ、そうはそうなんだけど……」という感じで。せいぜい「クリエイターがちょっと生産的になりそうかもね」みたいな感じで捉えられているような気がしますね。

牛尾：そうですよね。僕もまったく同じような意見で。やっぱり、正直なところ、よくわからないんと思うんですよね。

僕はいっぺん経験したやつで衝撃的だったのは……お客さんのところに行って、DevOpsのエヴァンジェリストとか言うと、「うちはもうDevOpsやってますよ」って言われて。「あ、そうなんですか」って。

それで、「ところで、じゃあリードタイムどれぐらいですか？」って聞いたら、「6ヵ月です」「ん？　6ヵ月!?」みたいな。「はてな」となったんですけど。

話を聞いたら、ものすごく高い「これがDevOpsです」というやつを導入していて。でも、実際扱ってるのはキットだけみたいな。もう完全に騙されてますよね、はっきり言ってね（笑）。

（会場笑）

DepOpsの対象となるのは技術者だけではない

塚：ここにいる人たちで関与をしている人がいるとちょっとヤバイかなとは思いながらも。

牛尾：そうですね。まあ、気にしたら負けじゃないですかね。

塚：商売の道具ではないですよね。

鈴木：ちょっとデモグラフィックを聞いてみましょう。もちろんITに携わってる方がほぼ100パーセントだと思いますけれども、「自分は開発者である」という方は？

（会場挙手）

吉羽：お、けっこういる。6割ぐらい。

鈴木：そうですね。これは開発者のイベントなんでしたっけ。Tech Summitというぐらいですから、やはり技術メインですよね。

牛尾：どっちかというとね。ITプロが強いイベントの話。

鈴木：開発者が多いわりには、わりとスーツを着てらっしゃる方が……。

塚：そうそう。それがすごく気になってるんですけど（笑）。

鈴木：逆にOpsの運用関係に携わられている方？

（会場挙手）

吉羽：2割ぐらいですかね。

鈴木：8：2ぐらいのイメージですかね。

牛尾：ありがとうございます。

鈴木：今「野鳥の会」的な感覚で、実際に数えられてたんですか？　心のなかでカチカチと。

牛尾：（笑）。

鈴木：そうですね。まあ開発者の多い環境ということで。

それで、先ほど言われたことというのも、開発者の感覚からDevOpsを見たときって、やはりどうしてもツール（の話になってしまう）。ましてやツールはいっぱいありますから、どれを選んだらいいか、どれが使い心地がいいかというと、どうしても議論になってしまうというのは、これはDNA的に反論できないことじゃないかと思うんですよね。

もしかしたらDevOpsという言葉の対象となる方々が、技術だけではなくて、当然運用もありますし、ものの本では経営者も巻き込んだものもある。そうなってくると、DevOpsの捉えられ方が変わってくるんじゃないかと思うんです。

DevOpsの定義とは？

それが実は2つ目の質問にもつながってくるんですけれども、「DevOpsの意味」。

もう「DevOpsの定義」なんていったら、ものの本にはゴマンとあるわけで。その定義の1つは「定義がないというのも定義の1つである」なんて語っている人もいる。

実はあるエンジニアがいて、「私はテスターだ、テストをするのが私の仕事だ」「私にとってDevOpsはまったく意味がない」「DevOpsというものの定義はないほうがいい」というようなことを語られるんです。要するに、立場によって意味も変わってくる。

それを意識した上で、DevOpsの広義の意味での定義というのものを、もちろんご経験のなかから感じているものを語っていただければと思っています。

市場で思われているDevOpsの意味というものと、本来DevOpsってどういう解釈をするべきなのかということを少し語っていただければと思います。

吉羽：なるほどね。この話は長くなりそうですけど（笑）。

（会場笑）

吉羽：DevOpsってたくさん定義があるので、DevOpsの起源を紐解いておいたほうがいいと思うんです。確か2008年のアジャイルカンファレンスで、パトリック（Patrick Debois）という人が「Agile Infrastructure（＆ Operations）」というプレゼンテーションをして、翌年にFlickrの……。

塚：Velocityですね。

吉羽：そうそう。「10+ Devplays per Day」という、「1日10回以上デプロイするぜ」というプレゼンテーションをしたのがはじまりで、DevOpsという単語が出始めたんです。

その時のスライドや動画がYouTubeに上がっているので見ていただくといいんですけど、「DevOpsとはなにか？」という話はまったくしていなくて、「Flickrってどうやりました？」という話しかしていないんですよね。

どっちかというと、DevOpsという単語が1人歩きをして、そのあと数年かけて……。よく聞くのは「CLAMS」という感じで、Culture、文化。Lean。Automation、自動化。あとMeasurement、測定ですね。それからSharing、共有という、「この5つのキーワードがDevOpsの構成要素だね」というのが最近よく言われる話なのかなと思います。僕もその切り口で話すことが多くて。

なので、自動化も入っているし、それ以外に文化の話というのもすごく大きいし、当然データがないと改善できないので「測定しないといけないよね」という話もあるし、「そもそもなんのために」みたいな共有も必要だよねという、いくつも構成要素があるというのが僕の現状の理解ですね。

「どうせなら効率よくやりたい」というだけ

牛尾：僕もすごく近くて、本当に意見が一緒で。はっきり言って定義はないので、やっぱり歴史を紐解いて見ていけば、「こういう技術が出てきた」とか。

例えば、ウォーターフォールのあとにアジャイルが出てきて、コンティニュアスデリバリが出てきたり、アジャイルテスティング、それからリーンスタートアップとか。そういうものが、クラウドが出てきてグチャグチャになって、そのあたりのアイデアの素になっている。歴史を見ると、だいたい大外ししないという。

あと、僕がけっこう好きなのは、ジーン・キム（Gene Kim）の3waysの話ですね。あれは、もうほとんどDevOpsのゴールというか、ゴールの定義みたいな感じなので、そのゴールを理解すれば、あんまりブレないと思うんですよ。「こういう要素が必要だよ」という細かいものは人によって定義は違うと思うんですけど、ゴールはたぶんそんなにブレないので。

その3waysといったら、1個目はリードタイムの短縮というやつですね。アイデアを思いついてから……。

吉羽：たぶん、もっと大上段からいくと、ヤフーさんはもっとビジネス的な話ですよね。

塚：そうなんですよね。ひと言で、僕が社内で言っていることというのは、「効率よくオーナーシップを持って試行錯誤したいじゃん」と。

牛尾：なるほど。

塚：目的は帰属意識から出てきているはずで、僕は例えばヤフーに属しているわけですよ。なので、ヤフーが儲からないと自分が食っていけないんですね。だからそのためにいるでしょと。その目的を達成する。どうせだったら楽しくやりたいね、オーナーシップ持ってやりたい、効率よくやりたいよねという、ただそれだけの話だと思っています。

僕は心のなかで定義厨と呼んでいるんですけど、定義したかったりカテゴライズしたい人は、その時間をもっと効率よくするなにかの試行錯誤にあててくださいと。僕はどっちかというとそれぐらいの感じでいますね。「歴史もまあいろいろあるんでしょうけど……」というぐらい（笑）。

吉羽：すごい。おもしろい（笑）。

塚：「今、この瞬間どうなんですか？」「僕たちは効率よくやれてるんだっけ？」という、そこはやっぱりポイントなのかなと思います。

吉羽：そもそも会社が儲からないと話にならないので。

塚：そうなんですよ。

牛尾：その通りですね。

吉羽：そういう意味だと、ビジネス・オリエンテッドにするしかないと思うんだけどね。

塚：そうなんです。

相反する目標を両方目指すために

鈴木：先ほど吉羽さんと牛尾さんからいくつか出たキーワードなんですけれど、モノづくりの考え方にわりと近いものがあるんじゃないかと思ったんです。

もともとトヨタの生産方式みたいな、生産ラインのなかで役割を明確に分担を決めて切り分けるとか、あとは境界線を明確にすることによって、効率のよさを徹底的に追求する。それって全体のプロセスを整流していくという発想に近いものじゃないかと、自分なりに感じました。

塚さんの言われたことというのは、どちらかというと逆の発想で、チームとしてのまとまり、チームとしての強さというか、アトミシティというんですかね。

塚：そうです。やはり本当にアジャイルのコンテキストがすごく大事で。「別にお前のためにチームがあるわけじゃないんで」と。『SLAM DUNK』で書いてますよね。僕、安西先生大好きなんですけど、「チームのためにお前がいるんだよね」というところをけっこう強く思います。

鈴木：そこってどうなんでしょう。DevOpsを企業のなかで議論していて本格的にやろうと思ったときに、チームを重視すべきなのか、それとも全体の調和を重視すべきなのか。そこに混乱が生まれたら、方向軸が見えにくくなるような気がするんですけど、それはいかがでしょうか？

塚：僕は、できないことをやってほしいというか、それって相反する感じがするじゃないですか？　だから僕だったら、「両方目指して高止まりでいいバランス取りましょう」って言いますね。チームも高いレベル。それに対して、組織に対する価値の提供も高いレベルで。

これ、たぶんどこかにフォーカスしたらどっちかのバリューがすごく上がるんですよね。だけど、両方やるとすごい難しいじゃないですか。両方やるためにはおそらく自分たちが成長する必要があって、それはすごく大事ですよね。

日本人的な感覚だと、やはり現状維持とか、僕が一番大嫌いな現状維持バイアスが強く働く民族だと思ってるんですけど（笑）、そういうバイアスを排して、高いレベルでやっていかなきゃいけないとなったときに、やはりそういう相反する両方を追うというのがすごく大事なのかなと思っています。

鈴木：やはりDevOpsの本質的な目的というのは、各個人の持っているポテンシャルを最大限に引き出すシステムというんですかね、そのメカニズムというか、そういう考え方というのは共通して理解していればいいんですかね？

塚：あると思います。ただ、だからといってチームのパフォーマンスが出なかったらぜんぜん話にならないですし、チームのパフォーマンスが出ないことによって会社が微妙になったら「ご飯食べられないじゃん」というのがあるので、全部やるとたぶん死ぬんですけど、それを目指す、というところはあるのかなと思っています（笑）。

そのためには、物理的に泥臭くやっていても無理なので、やはり「技術を使っていこうね」「やらないこと決めていこうね」という話になっていくのかなと思います。そういうところでつながってくると、いいところに落ちると思いますけど。

DevOpsを目的化してはいけない

牛尾：単純に考えたらいいと思います。だから、やはりまず基本的にはリードタイムを短くするという1歩目があって。1歩目じゃなくてもいいですけど。

あとは、今というのは未来を予見できないというのが基本だから、いかに早くフィードバックを受けるかっていう。それを、仕組みや人のマインドセットかもしれないし、もしかするとツールや技術かもしれないけど、そういうもので早くフィードバックをやる。

今は未来が予見できないので、早くそれに適応していくというのが重要で、そういうのを継続的に繰り返して、実験して学んでフィードバックして、できるだけ早くビジネスがうまく回るようにしていく、というところだと思います。

吉羽：その話って個人も企業も同じで。もう全部のサイクルがむちゃくちゃ早いので、生命体としてどうシステムというか系に反応するかっていう話なので。

トラディショナルなビジネスをされている会社であっても、既存のビジネスはシュリンクしていくので、新規ビジネスを作らなきゃいけないと。そうすると、早いサイクルを投げれなかったら他者に全部やられてしまって、だんだん緩やかに死んじゃうよね、という話があります。

一方で、その組織のなかの人も「うちの会社たぶん、僕が定年するまで潰れないから大丈夫かな」という。昔だったら言えたのかもしれないけど、今は本当にわからないので、変化しないことがもう企業にとっても個人にとってもリスクになっているというのははっきり言えると思うんだけど。

DevOpsって、そういう意味だと、それを揺さぶる感じはあるのかなという気はしますね。ただ、DevOpsが目的化しちゃうのはよくないよねというのははっきりとある。

鈴木：それはそうよね。

吉羽：だから「なんのために？」っていったら、「会社がもっと儲かるためでしょう」「もっと仕事楽しくするためでしょう」とか、“流行ってるから”じゃないというのはあると思いますけどね。

鈴木：よく「目的であってはいけない」と語られますけど、もっと大きな目的があって、それを実現するためにDevOpsが必要になっている。

塚：手段の1つですね。

鈴木：手段になっている？

塚：はい。目的化してはいけないと思っています。

今はDevOpsというラベルがついているだけ

牛尾：そうですね。僕も基本的にソフトウェアやデリバリをどうやってうまくやっていくかという文脈が昔から脈々とあって、今はたまたまDevOpsというラベルがついているというぐらいのイメージですね。

吉羽：だから、中を紐解くと、普通にアジャイル開発でスクラムをやっていたり、普通にいろんなことを自動でやっていたりもするし、“ラベルがついただけ感”も多少はあったりしますよね。

塚：そうですね。僕も社内でDevOps広めていくって言ったんですけど、2～3年前ですかね、アジャイルの浸透率を社内で調べてみると3割ぐらい。「DevOpsもへったくれもないじゃん」と。今は6割ぐらいまで来ているので、まあまあいいのかなとは思うんですけど。

DevOpsって言ってもしょうがないので、「じゃあ、アジャイル、リーンがんばっていこう」、あるいは「自動化がんばっていこう」とか、そんなことをやっていましたからね。

鈴木：塚さん、心優しいですね（笑）。

アルコールが入ってないせいか、今のところモデレータとしては非常に楽させていただいています。なんか和気藹々とした会話になってますけど（笑）。

塚：（笑）。

牛尾：えっ、もっと燃え上がってほしい感じなんですか（笑）。

鈴木：次の質問からもうちょっとリアルな、辛口、なおかつ、赤裸々なご経験を少し出していただければと思っています。このお3方は、もう毎日朝昼晩、DevOpsを食べて飲んで生きているという方々で。

（会場笑）

鈴木：そういった方々が日頃なにをされているのかということですね。もちろん朝起きて、普通の人間のような生活をされていると思うんですけれども、はたしてお客さんとどのような関係を結んでいるのか、どういうような信頼関係、そして具体的にどのような戦いがあるのか。そのあたりのリアルなところも含めて、ぜひ言葉をいただけますか？　牛尾さんから。

牛尾：俺から!?　いいですよ。

鈴木：Azure側から。

「バリュー・ストリーム・マッピング」のメリット

牛尾：私のほうは、基本的にDevOpsのエヴァンジェリストをやっていますけど、エヴァンジェリストというと、基本的にトークをしているというイメージがあるかもしれないですけど、実は違って。

実は、今、僕の一番の仕事というのは、DevOpsのよいケーススタディを作ることなんですね。

そのためになにをしているかというと、まずお客さんのところに行って、ディスカッションやプレゼンテーションをしたり、あとはバリュー・ストリーム・マッピングというものを提供して、それで無駄を発見して、「ここを自動化しましょう」「こういうふうにプロセス変えましょう」ということをやるんです。

あとは実際にハックフェストというのをやって、実際にハッカソンを一緒にして、ガチの環境を本当に自動化しちゃうということをやっています。そうしたらいいケーススタディになるじゃないですか。

これが本社のシナリオなんですけど、日本ではそうはうまくいかなくて。僕はなにをしているかというと、だいたいその差分を見ているんですね。

DevOpsっていろいろ積み重なった結果で、今はDevOpsになって、次はたぶんマイクロサービスとかになっていくんですけど、ここの間をいきなり飛べないじゃないですか。だいたいここは空いているので、僕は空いているところをご支援したりします。

例えば、アジャイルが入っていなかったら、アジャイルを入れる手伝いをしてみたり、そのあたりの自動化ができていなかったら、「その前にこういうことをやらないといけないから、こういうことをやっていきましょう」みたいなギャップを埋めるようなこともやりながら、実際にそういうアクションをして、いいケーススタディをできるだけ作れるように。

鈴木：オーディエンスに対して、そのバリュー・ストリーム・マッピングが具体的にどういうものなのかというイメージを。本当は実際に画面があればいいんでしょうけど、イメージを掴んでいただくために少し説明をしていただけますか？　タイムライン的な。

牛尾：そうですね。バリュー・ストリーム・マッピングというのは、アイデアを思いついてからそれを本番にデプロイするまでのプロセスを見える化したものなんですね。

見える化するだけじゃなくて、それを関係者全員と、僕がオススメしているのは若干偉い人、プロセスを変える権限を持っている人を巻き込んで、一緒に可視化していくんです。

リードタイムとかをそれぞれ測って、あとはプロセスタイム、value added timeとも言いますけど、そういうところを可視化していく。バリュー・ストリーム・マッピングのいいところは、可視化することで誰の目にも「どう考えてもこれ無駄だよね」みたいなのがわかってくるんですね。

そうすると、「もうこのわけのわからない承認プロセスをやめちゃおう」とか「ここの部分ってガチで自動化できるから、もう自動化しましょうか」ということが出てくる。そういうのをやると、本当にリードタイムが短くなるんです。

例えば、de:codeのキーノートであった2件も僕が関わってるんですけど。

鈴木：NECとどこでしたっけ？

牛尾：NECさんとカラダメディカさん。NECさんの場合は、8.5ヵ月のリードタイムが1週間になったり、カラダメディカさんも13日が2日になったり、本当にそういう行動を始めるきっかけになれる、けっこうおすすめのツールですね。

鈴木：なるほど。

まずは“バケツの穴を塞ぐ”

吉羽：僕もしょっちゅうやるんですけど、今いきなり話を聞いて、会場の人はわからないかもしれないので、少し補足をしておきます。これは牛尾さんと考え方が違うかもしれないんですけど、やはりある程度エンタープライズの文脈になると、いきなりプロセスを変えようとしても、やはり承認する人や責任分界点の話があるので、変えられないです。

なかなか難しいのでゆっくりやるしかないんですけど、その前にやらなきゃいけないことがあって。

さきほど牛尾さんの話に出なかった、各工程を線でつないで、その時に前の工程にどれぐらい戻っているかという、いわゆる手戻り率っていうんですかね。逆流率というのを算出というか、だいたいわかるんですよね。「10回デプロイして5回障害出た」「10回レビューに投げて8回も落とされた」とか。

逆流率を測定して、逆流しているところを直すというのが、これはもう鉄則中の鉄則ですね。これだったらたぶん、プロセスを変えるとかじゃなくて今すぐできるんですよ。

例えば2回に1回戻りますといったら「じゃあ2倍の時間かかるの？」というと違って。次の1回やっても、また半分落ちる可能性があるので、けっこう何倍も時間がかかるようになっちゃうんですよね。

なので、さきほど鈴木さんから整流という話が出ましたけど、“流れを整える”って逆流を防ぐ、漏れを防ぐというのが先なんです。もっと短くするための、例えばプロセスをくっつけるとか順番に入れ替えるということは、漏れがなくなってからやればいいので、まずバケツの穴を塞ぐというのが先ですね。

（会場笑）

鈴木：雨漏りを直すような感覚ですかね。

吉羽：そうそう。僕はこれをもう口を酸っぱくして言っていて。「ツールとか入れる前に穴塞げ」ってよく言ってますけどね。

牛尾：ほんまそうよね（笑）。

塚：なるほど、ヤフーでなにをやっているか。ヤフーの人って今どれぐらいいます？　「ヤフーちょっと関わってるかも」っていう人いらっしゃいます？

吉羽：（会場を見て）なに言っても大丈夫です。

塚：よし！

吉羽：（笑）。

自分たちが最初の1人になるという勇気

塚：ヤフーは内製です。わりとYahoo! Inc.から持ってきているものもあるんですけど、かなり内製で自分たちで作っています。僕がいるプラットフォーム開発本部というのはまさにそのプラットフォームを作っているんですよね。フロントエンドがあれだけアジャイルにものを作っているんだけど、まあすごいんですよ。「銀行か？」と。

吉羽：ガチガチ？

塚：ガチガチですね。最近はそうでもないんですけど、そういうことがあって。

やっぱり偉い人がなんとなく「これでいけそう」って思ってくれないと、なかなかうまくいかないんです。だから、偉い人にアンラーニングをどうやってしてもらうかというところにかなり時間をかけたなというのがあります。

もう1つは、自分が偉くなっちゃえばいいんですよね。自分が権限を持って予算を持てば、ある程度はコントロールできちゃう。それで、そこでわかりやすい成果を出す。

そこのわかりやすい成果を出せなかったら、もう僕は死ぬんですよね。なので、けっこう必死でやるんですけど、わかりやすい成果を出すというのはわりと重要なことなのかなと思っています。

予算もうまいこと調達して。すごく小さくていいんですよね。わかりやすい成果を出すと、「おっ、よさそうじゃん」と過大な期待を寄せられるんですけど、そこからうまいことやっていくというのが、うちが進んでいった1つの道だったと思います。

吉羽：けっこう王道ですよね。

塚：まあ王道ですね。

吉羽：よく「DevOpsやりたい」ってSIerの方や大きい会社の方から相談受けるときに、僕は「人の金でやる前にまず自分の金でやれ」って言うんです。

塚：そう。そうなんですよ。

吉羽：どうせ社内にたくさんシステムはあるので、先にそれで練習して、お客さんのお金でやったらいいじゃないですか。「なぜいきなりやったことないやつを、外部のコンサル呼んで、いきなりやろうとしちゃうのかな？」っていうのは、ちょっとねえ。

塚：本当にそうなんですよ。