「日和った意思決定をすると文化が腐る」DevOpsの有識者が語る、企業カルチャーの重要性

人も組織も一気に変えるのは危険

吉羽龍太郎氏（以下、吉羽）：さっき出た「変わらないのは退化だ」という話はその通りなんだけど、その“枕”というんですかね、始まる前に話したいんだけど。

塚穣氏（以下、塚）：（笑）。

吉羽：「くれぐれもいっぺんにたくさん変えるな」と。

塚：そうですね。

吉羽：これが大事ですよね。

牛尾剛氏（以下、牛尾）：重要ですね。

吉羽：失敗してもリカバリーできるぐらいのやつ。意地でも、場合によっては自分が必死こけばなんとかなるという範囲からまず変えたほうがいいですよね。

塚：そういえば、裏でトライとチャレンジの話をしていました。

吉羽：ポートフォリオ・マネジメントなので、金のなる木でいきなり大きいチャレンジをするというのは、やっぱり危ない。

塚：危ないですね。

牛尾：その通り。

鈴木いっぺい氏（以下、鈴木）：それはやっぱり現場では、経営者とかやっぱり根幹となるところからやろうという意識がどうしても働いちゃうから、そういうのはキチッと……。

吉羽：そうそう。根幹のあるところも一気に変えなきゃいいんですよ。1個ずつ変えて、うまくいくんだったらそのまま定着させればいいし、うまくいかないならやめればいいんだけど。

塚：そうですね。

吉羽：人も組織もぐしゃぐしゃっと変えて、「さあやろう！」っていうのは、なかなかね。もう後戻りできないじゃないですか？

牛尾：超絶デンジャラスだよね。

改善する場所が重要

塚：計測できないですからね。1個ずつ変えていかないと、良かったのか悪かったのかわからない。

吉羽：A／Bテストみたいなものですよね。

塚：本当にそうですよね。

吉羽：僕は「開発プロセスもA／Bテストすればいいじゃん」と思うんですけどね。

鈴木：そうすると、例えば現場で小さな改善を1個やったとするじゃないですか。当事者はそのよさを体感できると思うんですよね。

ただ、周りにいる、ある意味で傍観していた方というのは、「壊れてもいないものをなぜ直さなきゃいけない？」という、どちらかというと反論の空気が出てくるということもあるんじゃないかと思うんですけど、それについてはどう思いますか？

吉羽：（反論の空気は）あると思うんですけど、それはたぶん直してる場所がおかしいと思うんですよ。穴を塞げば、たぶん見た目でリードタイムが短くなるし、成果も出る。

要は全体最適をするか部分最適をするかという話でもあるんだけど。全体の流れにインパクトのあるところを直していれば、結果に出るんです。

塚：そうです。「ビジネスインパクトじゃないですよ」と。そこが大事なんですけど（笑）。

吉羽：そうそう。少なくともプロセスとか品質とか、なにかにインパクトが出るはずです。

塚：プロセスにインパクトがあることですね。

吉羽：それが出ないところはいわゆる部分最適であって……局所最適って言ったほうがいいのかな。だから、ぜんぜんプロセスのボトルネックを直していないんですよね。自己満足に近いという感じだと思うんです。

まずは1個ずつ、高濃度でやっていく

鈴木：牛尾さんも同じイメージですか？

牛尾：だいたい一緒なんですけど、最初におっしゃった質問のアンサーということで言うと、僕は1個成功させるということがすごく重要だと思っています。

僕がよく言っているのは、例えばさっき言っていたようなすごく根幹のところで変えようとしたら、たぶんいろんな制約事項が出てきて、すごく妥協することになるんですよね。

吉羽：あるある。

牛尾：そうではなくて、ryuzeeさんが言っていたような、安全なやつをやるんだけど、これはもう超高濃度でやってほしいんです。開発の習慣も関係があるので、そこまで高濃度に高めたやつをやってほしい。よく「濃いカルピスをそのまま原液で飲む」みたいに言っているんですけど、それをまず1個。

吉羽：ヤバそうだね（笑）。

鈴木：それはおいしくなさそうな感じ。

牛尾：まあ、そうですけどね。それを高濃度でやると、けっこう結果が出るじゃないですか。僕は人をハイヤーするのもすごく気を遣って、イケメンをちゃんと投入して、確実に……。

吉羽：イケメンって顔のことじゃないですよ。技術的に。

鈴木：わかります。「技術イケメン」ってやつですよね。

牛尾：技術イケメンをちゃんと呼んで、ちゃんと回るようにして、そこで開発の習慣も含めてリードタイムが短くなって、フィードバックも早く得られるようなチームを1個作るじゃないですか。そうすると成果が上がるでしょう。

成果が上がったら、次は上を巻き込んだりします。さっきのバリュー・ストリーム・マッピングみたいなことはそっちにも使えて、「リードタイムが今これぐらいだけど、これぐらいになりそうですよ」というのをある程度出せるわけじゃないですか？

例えばNECさんの時だったら、今はリードタイムが8.5ヵ月だけど1週間になりそうってわかったんですよね。実際に今はそうなったんですけど。そういうふうに上の人に言ったら、たいていみんな「それならやろうよ」という話になるじゃないですか。だから、そういう実績を持って上の人を巻き込んでいく。

そして次もいきなりバーンってやるんじゃなくて、また1個ですよね。知見を持った人をハブにして、その人のリソースも入れながら、次に新たな周りのチームを少しずつ作っていくというか。

上が評価しやすいことが極めて重要

塚：「そこはやる人の裁量に左右されるような気はしていました」と。そして、強烈な成功体験を現場に落とし込む。それはマネージャー陣が評価しやすいことであることが極めて重要だ、ということをおっしゃっていると思っていて。

上は、自分が評価できる内容というのは、自分の業績ですから、予算も取りやすくなってくる。こういうところがすごく大事で、ここはやっぱり小ずるくやったほうがいいと思うんですよね。上が評価しやすいように、そういうものを成果としてあげていくというのはすごく大事だと思っています。

僕は自分のレイヤーとして、今でこそ「評価するからどんどんやってくれ」ということを言えますけど、当時、自分のやったことというのはやはり、「評価してほしいけどなかなか……」という部分はあったんですね。

でも、ある時「上が評価しやすいことが極めて重要だ」と気づいた。そうすることでいいサイクルが生まれていくと。評価されれば、みんなうれしいのでやはり成功体験につながっていくのかなというのはあります。

牛尾さんすごいのは、そこで自分がハブになってるところですよね。

牛尾：そうですかね（笑）。

塚：僕はちゃんと事前に政治を働かせてネゴっちゃいますもん。「こういうふうにやったら、うまくいったということで1つ」って。それはすごいと思います。

鈴木：最近「ディスラプティブ」という言葉が流行っていますからね。やはり最近、私の信条としては「ディスラプティブじゃないものはやっちゃいけないんじゃないかな」と思うぐらいで。

昨日もセミナー、今度の金曜日もセミナーがありますけど、もう全部英語でやるとか。日本語に翻訳する時間ももったいない。

塚：（笑）。

牛尾：そうですよね。

鈴木：英語でやられると困る人もたくさんいるんですけれども、でもやはり生きている情報が出てくる、という発想で。

15万ノードを20人で運用

それで、先ほどの成果の話ですね。これは、プロジェクトだとすれば納入物というか、できあがるものはどういうかたちになるんでしょう？

チームの新しい方法をもって改善された自信というんですかね。それともなにかスペックのようなものが出てくるんですかね。VSM（バリュー・ストリーム・マッピング）の結果というのはありますけど、これってどういうかたちで経営者に説明をしていくことになりますか？

吉羽：僕はこれは逆だと思っていて、経営ってすべからくKPIを持っているんですよ。業績目標や各部門で数字があって、やはり多くの活動はその数字の達成に沿った関係がないといけないと思っている。だから、それに合う活動を選べばいいじゃんという。たぶん逆。

だから、「なんのために会社が存在していて、なんのために部門が存在していて、なんのために期初にゴールやビジョンを設定するの？」と言ったら、活動の軸を定めるためなので、それに従えばいいんじゃないのという気がしますけど、どうですかね？

塚：それは本当にそうですね。僕は、実は9月まではセキュリティの仕事をしていて、10月からSRE部というところに。なにをやっている部かというと、ヤフーはけっこうリアルサーバーを持ってるんですよね。この間CTOが言っていたんですが、15万ノードぐらいあるんですよ。ホスト15万です。

僕は、これを20人で運用しようという博打をやっているんですね。これ、すごいじゃないですか。20人で運用できると思う人います？　僕はやるんですけど。

たぶん15万ノード20人で、じゃあ「24時間1週間で運用できるの？」といったら「ちょっと厳しい」って考える人が多いと思うんですけど、僕が始めたチャレンジはそれです。

「じゃあ普通にやるとどうだっけ」というと、厳しいですよね。そこでなにをやっているかというと、1つは自分たちでモニタリングのプラットフォームを作っています。どういうものを作っているかというと、prometheus.ioってドメインご存知ですかね。ああいった感じのものを自分たちで作っています。

それを作って、「15万ノードのうち10万ノードぐらいをあと1年でそこに放り込みますよ」というのをCTOとかにコミットして、やる。そんな感じですね。

吉羽：それってもうインフラに対する思想も変わっていますよね。

塚：そうですね。

吉羽：要は、名前付けて大事にやるんじゃなくて「壊れたやつ外せばいいだけだよね」みたいな。いわゆるクラウド、AzureとかAWSと同じですよね。

塚：そうです。

極端な話、コードを書けないエンジニアはいらない

鈴木：考えによっては、それはもうDevOpsができあがっている姿のようにも思えちゃうんですけど（笑）。

吉羽：そうそう。でも、それってビジネスの目標にアラインしてやっているんですよね？

塚：そうです。

吉羽：ちなみにどういうビジネス目標なんですか？

塚：単純に、開発の生産性をもっと上げたいんです。もっともっと上げていって、いわゆる専任のオペレーターみたいな人もどんどんモノづくりしてほしい。

なので極端な話、コードを書けないエンジニアはいらないぐらいの勢いで「精鋭は僕の下に来てくれ」と。そうでない人はフロントエンドからプラットフォームからの開発をすればいいというかたちです。

今、クリエイターが2,000人ぐらいいるんですけど、その濃度をどんどん上げていきたいというところが会社の意図ですね。

吉羽：その時は、開発したチームが自分たちで運用する、セルフサービスのイメージになっていくんですかね？

塚：実質、運用というのはちょっと概念が変わるかなと思っています。作ったもののバグは作った人が直せばいいですけど、ほぼコンテナとかになっていくので、実際は捨てていく感じですかね。

吉羽：じゃあもうセルフサービス？

塚：そうです。「オーナーシップを持ってリリースさせてください」「どんどんプッシュしてください」と。だけど、ダメなやつはこっちでどんどん落としていくし、各ライブラジのアップデートは、こっちがローリングアップデートみたいなかたちで上げ下げして、どんどん上げていきます。そこはもうAzureとかAWSとかと変わらないと思いますけど。

吉羽：ですよね。

鈴木：Azure側のご意見は？

牛尾：僕はそこはもちろん変わらないですけど、その前の議論というか、ryuzeeさんがKPIの話してたじゃないですか？　あそこに関しては僕はちょっと違う意見を持ってるんですよ。

本質的にはtotally agreeなんですよね。でも、なかなかそういうところを理解してもらうのって普通では難しいところがあって。

普及のためにわかりやすいキーワードを使う

吉羽：もちろんわかる。現場の人にとっては、その数字より目先の仕事だっていう感覚はもちろんよくわかる。

牛尾：本当に本質的にはすごくアグリーなので、どういうことをしているかというと、僕はけっこうテロリストで、元々NECにいたんですけど、2001年ぐらいにNECのなかでいかにアジャイルやるかというのをやっていたんですよね。だから、いろんなずるいこともけっこうやっているんですけど。

吉羽：ダマでやったりしますよね。

牛尾：そうそう。だから、今のDevOpsは、上の人も（DevOpsという）言葉を知ってるし、その頃に比べると圧倒的に簡単な気がしていて。

塚：楽です。

牛尾：僕は人に説明するときにわかりやすさって重要だと思います。リードタイムって、それがめっちゃ本質かというとちょっと違うんですよね。でも、「リードタイムがバーンと短くなりました」「なりそうです」って言ったら、みんながだいたい納得するんですよ。

そういうわかりやすいキーワードを使うのと、チームが本質的な方向に向かっていくというのはやはり地道な活動なので、チームに対しては、実際にバリューとかアウトカムを上げていく方向に向かっていくように、そこは地道にやったり（笑）。僕はそんなアプローチをしたりしています。

塚：でも、あまり変わらないかなとは思います。

牛尾：本質的にはあまり変わらないですね。考えていることはみんな違わないと思います。

塚：そのために各個人にはどういうアプローチをするのか？　チームには？　部門には？　というので、やっぱり僕も少し変えているので。顔とか、かぶる帽子とか（笑）。

（会場笑）

吉羽：たぶんその話をし始めると、DevOpsの文脈で、カルチャー、文化、組織の話ってやっぱりすごい重要だよねという話になって。

チャレンジを尊ぶ文化なのか、減点主義の文化なのか、決められたことをやるのがいいのか、そうじゃないことをやるのがいいのかとか。それから「人事評価の基準ってなんだっけ？」「採用の基準ってなんだっけ？」みたいな話ってすごく重要ですよね。

日和った意思決定をすると文化が腐る

やはりいいチームは当たり前のようにいいプロダクトを作れる傾向にあって、どちらかというとチームを軽視するのがエンタープライズにはけっこう……どうしても稼働率を優先してしまって、チームを簡単に割ったり足したり。あとパートナーさんをどんどん突っ込んだりして。

塚：ああ、そうですね。よくないです。

吉羽：要は持続性のないチームを作っちゃう傾向が多くて。それって文化とかがプロダクトや作るものに反映されないじゃないですか？　そこは改善の余地があるんだろうなって気がするんですよね。

塚：そうですね。ヤフーのなかでもあるんですよね。「身の丈に合ってないビジネスをしてるよね」って僕ははっきり言うんですよ。業務委託みたいなのをドバドバ突っ込んで、お金じゃぶじゃぶ使って……大丈夫かな、これ？（笑）。

まあ、そういうことがあるんですけど（笑）。「文化は意思決定が作っている」って誰かが言ってましたけど、本当にそうだと思っています。

そういう一見目先の数字が上向きそうな施策にお金を突っ込んでやっても、やっぱりそういう本質を変えない日和った意思決定を上がやっちゃうと、文化が腐るんですね。

なので、そういうものになんとか抵抗して。僕らはテロリストですからね。暗殺していかないといけないのかなとは思いますけども。

（会場笑）

吉羽：そうそう。僕、今の仕事をする前はAmazon Web Serviceという会社にいたんですけど、採用の基準とかがすごく厳しくて、会社で明文化した考え方みたいのが14箇条ぐらいあって、それに合ってないと思われる人は、いくらスキルがあったり業界で有名な人でも「僕らには合わない」ということで仲間にしないという選択をしていたんですね。

それぐらいカルチャーにお金も時間も使ってる。だから、そこは足元を固めるという意味ではやってもいいんだろうなという気はします。

塚：そうですね。

鈴木：DevOpsというのは、先ほどからカルチャーという言葉も何回も登場しているんですけれども、やはりそこに非常に色濃いものがあるんじゃないかと思います。

DevOpsの前にまず足元を固めろ

もう少し具体的なイメージを掴んでいただくために、次の質問。ちょっとシミュレーション的な感じで取っていただければと思っています。

とある企業、例えば牛尾さんの場合はAzureのユーザー、吉羽さんの場合は典型的なガチのエンタープライズ、塚さんの場合はもうとにかくインターネット系の会社、大きめのところを想定してあげてください。

その会社で、月曜日朝一番に幹部会議がありました。CEOが執行役全員に対して「我が社はDevOpsをやる」「1週間以内に俺のところにDevOpsの方針を持って来い」という号令をかけます。

それで、その執行役がバーっと下に降りて、月曜日のお昼前に各部長会議が行われるわけですね。「どうもCEOはDevOpsを我が社で取り入れるということを宣言された」「さて、どうしたものか」と。

エンジニアはみんなDevOpsのツールを使っていると。AnsibleやJenkinsはそこら中で使っている。

それを上に持って行ったら「ふざけるな」「ツールを使うことがDevOpsだと思ったら大間違いだ」とCEOに怒られるわけなんです。だから、CEOは少しは勉強されているんです。

さて、そういうような状況で「相談をしよう」となって、各社、お三方に相談されたときに、どういうところからスタートすべきか。少しドライな表現……辛口な方法でもいいと思うんですけども。どういうようなアドバイス、指導をしていくべきなのか、そのあたりを少しリアルな感覚でご説明いただけますか？　順番はどんな順番でもけっこうです。

塚：これ、先にしゃべったほうが勝ちなんじゃないかなと思ったんですけれども、そんなCEOいるんですかね？。

鈴木：いいほうだと思います（笑）。

塚：でも、やっぱりこういうときに、牛尾さんがやってるやり方がすごくいいんだなと思います。バリュー・ストリーム・マッピングって、もともとは製品を設計して出荷するまでですよね。誰がどこでどういうふうに関わっているのかというのが可視化される。それがどれくらい放置されてきたのかというのを認識するところから始めないといけないんじゃないかなと思います。

その代わり、「CEOはなんのためにDevOpsという概念をやるのかちゃんと考えてくださいね」という感じなのかなと思いました。まずはそこからかなと。

吉羽：そうですね。とはいえ、現場でやるとしたら、僕はもうちょっと違うことを言うと思います。

DevOpsをやろうって上の人は言うんですけど、たぶん多くの現場は、「バージョン管理システムのブランチの使い方をろくに知らない」「ユニットテストを書いてない」「受け入れテスト自動化していないよね」「CI回ってないよね」とか、やるべきエンジニアプラクティスをやってないことのほうが圧倒的に多いんですよ。

だから、僕はたぶん「DevOpsだとか流行りモノがぐちゃぐちゃ言う前に、まず足元固めろ」と言うでしょうね。

誰からの依頼かというのは重要なパラメータ

牛尾：僕もそれすごいアグリーですね。僕のやり方でいくと、プレゼンテーションとデモをします。おっしゃる通り、両方のエレメントが重要なので。

プレゼンテーションするのは、やっぱりDevOpsの定義がふわっとしてて、みんなよくわからないので、そういうのをまずシェアをするんですね。

そのあとにバリュー・ストリーム・マッピングをまずやります。そしたら、リードタイムが出てきて、estimated lead timeというか、リードタイムの見積もりが出てくるので、僕はそれを持ってCEOに会いに行く。

「ちなみにCEOさんはなぜDevOpsをやりたいんですか？」とか、そういうところをまず明確にします。CEOはリードタイムを短くしたいのか、フィードバックを早くしたいのか、わからないですけど。

それで、彼らにちゃんとコミットしてもらって、彼らの期待を持って僕はまたチームに戻って、「彼らはこういう期待をしてるから、じゃあどうやってやっていこうか」みたいな話をたぶんディスカッションすると思います。

吉羽：よく考えたら大事なこと1個忘れたんですけど、誰から依頼をもらうかがすごく重要だと思っていて。

塚：確かに。

吉羽：経営者から頼まれたら、極論すると、大手術とか多少過激なことをしてもいいし、現場から頼まれたら、その現場を意地でも成功させなきゃいけない。僕の場合は独立したコンサルタントなので、お金を払ってくれた人に対してバリューを出すというのが鉄則なので、誰からその話が来たかはけっこう重要。

鈴木：だいたいミドルマネジメントのケースが多いんじゃないかと思うんですよね。

吉羽：そしたら少なくともその人の評価が落ちないようにするというのが、やはりお金を払ってくれる動機じゃないですか？　なので、その人が望む成果プラスアルファを出しにいくというのはやはりありますね。

たぶんこれは会社のなかにいても同じで、誰からの依頼なのかというのはけっこう重要なパラメータだと思うんですよね。

塚：そうですね。それ本当に僕もそう思っています。ちょっと上から目線であれなんですけど、うちはCTOが変わってからすごい努力をしていて。ある日突然、エンジニアとクリエイターを渋谷のどこかに集めて、「今日から半年でCI100パーセントやります」と勝手に言うんですよ（笑）。

（会場笑）

塚：裏では非常にがんばってちゃんと執行役員たちを説得していたらしいんですけど、そういうことを言ったりして。

やはり企業をDevOps的な感じに持っていかないと、もう僕らですら滅びると思っているんですよね。その強い危機感が彼をそういうことに駆り立てているんだろうなと思って、僕もすごく共感をしてるんですけれども、やっぱりけっこう強権って大事なんですよね。

なので、誰の依頼かというのはすごくわかる。本当それ（笑）。

文化に合わせてやり方を選ぶ

牛尾：僕は、その人がパワーを持てるように手伝う場合が多いですね。ミドルマネジメントぐらいの言い合いの場合って、やっぱり彼の権限だけではいろいろやりにくいです。

吉羽：もちろん、もちろん。

牛尾：だから、彼をうまく、彼と一緒に、例えば上の人を巻き込んであげるとか。そうすると彼もより動きやすくなって、より会社にいい影響が出ると思うんですね。

吉羽：それはたぶんマイクロソフトさんだとできるけど、個人のコンサルだとけっこう大変で、博打っぽいところもあるんですよね。藪を突いてなんとかってあるじゃないですか。

塚：そうですね。

吉羽：「偉い人引きずりだしたらけっこう大変なことに……」ということはあるので、そこは見極め。たぶんみなさんにとっていいやり方が絶対あると思うので。

塚：そうですね。こっそりやって、「そのコミュニティで登壇してすごく評価よかったですよ」というのが刺さる人もいますからね。いろんなやり方があるんじゃないかなと思います。

吉羽：文化に合わせてやり方を選ぶ感じはあると思うんですよね。

牛尾：ちなみにryuzeeさんがもし困ってるんだったら、そういうときは僕を利用していただけたら（笑）。

吉羽：そうですね。はい。

鈴木：話も尽きないところなんですけれども、なんと時間がやってきてしまいました。気がついたらもう50分しゃべりまくっていて。

牛尾：あら、早い。1個目やん。マジで!?　まだ1個目ちゃうかったっけ？（笑）。

鈴木：楽しい話題はついついね。最後に1点だけ申し上げたいんですけれども、今、実はこういった方々を中心にしたコンソーシアムを組織化しようと動いております。世界中でDevOpsDaysと呼ばれるイベントが開催されていまして、日本は久しくやっていないんですよね。もう2年、3年ぐらいですか？

塚：やってないですね。2013年にヤフー、ミッドタウンでやって以来ですかね。

鈴木：ですね。ですから、その復活も含めて、日本ならではということが正しいかどうかわからないですけど、日本できちっとDevOpsを発信していくというものを。ご覧のように個々の力で非常に成果をあげていらっしゃる方も多いんですけども、そうではなくて、やはり結集された力というものを世に訴えていくと。

なおかつ、ここで生まれたものが逆に輸出できるようなノウハウになればということを願いつつ、活動を始めております。近々そのあたりの発表も含めてやってきたいと思っています。意思のある方、ぜひ参加されたい方もお声がけをいただければ、募集しております。

塚：Q＆Aのときとかに来ていただけるとうれしいですね。

鈴木：ということで、今日も熱く語っていただきました。本当はもう少しきついことも出るのかなと想像しつつも、みなさん基本的にジェントルマンなので、DevOpsに関していろいろとパネルディスカッションを通していろんな意見を集めさせていただきました。本日はありがとうございます。

塚：どうもありがとうございました。

吉羽：ありがとうございました。

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