鈴木:英語でやられると困る人もたくさんいるんですけれども、でもやはり生きている情報が出てくる、という発想で。15万ノードを20人で運用それで、先ほどの成果の話ですね。これは、プロジェクトだとすれば納入物というか、できあがるものはどういうかたちになるんでしょう?チームの新しい方法をもって改善された自信というんですかね。それともなにかスペックのようなものが出てくるんですかね。VSM(バリュー・ストリーム・マッピング)の結果というのはありますけど、これってどういうかたちで経営者に説明をしていくことになりますか?吉羽:僕はこれは逆だと思っていて、経営ってすべからくKPIを持っているんですよ。業績目標や各部門で数字があって、やはり多くの活動はその数字の達成に沿った関係がないといけないと思っている。それに合う活動を選べばいいじゃんという。「なんのために会社が存在していて、なんのために部門が存在していて、なんのために期初にゴールやビジョンを設定するの?」と言ったら、活動の軸を定めるためなので、それに従えばいいんじゃないのという気がしますけど、どうですかね?塚:それは本当にそうですね。僕は、実は9月まではセキュリティの仕事をしていて、10月からSRE部というところに。なにをやっている部かというと、ヤフーはけっこうリアルサーバーを持ってるんですよね。この間CTOが言っていたんですが、15万ノードぐらいあるんですよ。僕は、これを20人で運用しようという博打をやっているんですね。これ、すごいじゃないですか。15万ノード20人で、じゃあ「24時間1週間で運用できるの?」といったら「ちょっと厳しい」って考える人が多いと思うんですけど、僕が始めたチャレンジはそれです。「じゃあ普通にやるとどうだっけ」というと、厳しいですよね。そこでなにをやっているかというと、1つは自分たちでモニタリングのプラットフォームを作っています。いうものを作っているかというと、prometheus.ioってドメインご存知ですかね。いった感じのものを自分たちで作っています。それを作って、「15万ノードのうち10万ノードぐらいをあと1年でそこに放り込みますよ」というのをCTOとかにコミットして、やる。吉羽:それってもうインフラに対する思想も変わっていますよね。吉羽:要は、名前付けて大事にやるんじゃなくて「壊れたやつ外せばいいだけだよね」みたいな。いわゆるクラウド、AzureとかAWSと同じですよね。極端な話、コードを書けないエンジニアはいらない鈴木:考えによっては、それはもうDevOpsができあがっている姿のようにも思えちゃうんですけど(笑)。それってビジネスの目標にアラインしてやっているんですよね?塚:そうです。吉羽:ちなみにどういうビジネス目標なんですか?塚:単純に、開発の生産性をもっと上げたいんです。上げていって、いわゆる専任のオペレーターみたいな人もどんどんモノづくりしてほしい。極端な話、コードを書けないエンジニアはいらないぐらいの勢いで「精鋭は僕の下に来てくれ」と。ない人はフロントエンドからプラットフォームからの開発をすればいいというかたちです。今、クリエイターが2,000人ぐらいいるんですけど、その濃度をどんどん上げていきたいというところが会社の意図ですね。吉羽:その時は、開発したチームが自分たちで運用する、セルフサービスのイメージになっていくんですかね?塚:実質、運用というのはちょっと概念が変わるかなと思っています。作ったもののバグは作った人が直せばいいですけど、ほぼコンテナとかになっていくので、実際は捨てていく感じですかね。吉羽:じゃあもうセルフサービス?塚:そうです。「オーナーシップを持ってリリースさせてください」「どんどんプッシュしてください」と。ダメなやつはこっちでどんどん落としていくし、各ライブラジのアップデートは、こっちがローリングアップデートみたいなかたちで上げ下げして、どんどん上げていきます。そこはもうAzureとかAWSとかと変わらないと思いますけど。あそこに関しては僕はちょっと違う意見を持ってるんですよ。agreeなんですよね。いうところを理解してもらうのって普通では難しいところがあって。普及のためにわかりやすいキーワードを使う吉羽:もちろんわかる。現場の人にとっては、その数字より目先の仕事だっていう感覚はもちろんよくわかる。牛尾:本当に本質的にはすごくアグリーなので、どういうことをしているかというと、僕はけっこうテロリストで、元々NECにいたんですけど、2001年ぐらいにNECのなかでいかにアジャイルやるかというのをやっていたんですよね。いろんなずるいこともけっこうやっているんですけど。吉羽:ダマでやったりしますよね。今のDevOpsは、上の人も(DevOpsという)言葉を知ってるし、その頃に比べると圧倒的に簡単な気がしていて。牛尾:僕は人に説明するときにわかりやすさって重要だと思います。リードタイムって、それがめっちゃ本質かというとちょっと違うんですよね。「リードタイムがバーンと短くなりました」「なりそうです」って言ったら、みんながだいたい納得するんですよ。いうわかりやすいキーワードを使うのと、チームが本質的な方向に向かっていくというのはやはり地道な活動なので、チームに対しては、実際にバリューとかアウトカムを上げていく方向に向かっていくように、そこは地道にやったり(笑)。僕はそんなアプローチをしたりしています。塚:でも、あまり変わらないかなとは思います。牛尾:本質的にはあまり変わらないですね。考えていることはみんな違わないと思います。いうので、やっぱり僕も少し変えているので。顔とか、かぶる帽子とか(笑)。(会場笑)吉羽:たぶんその話をし始めると、DevOpsの文脈で、カルチャー、文化、組織の話ってやっぱりすごい重要だよねという話になって。チャレンジを尊ぶ文化なのか、減点主義の文化なのか、決められたことをやるのがいいのか、そうじゃないことをやるのがいいのかとか。それから「人事評価の基準ってなんだっけ?」「採用の基準ってなんだっけ?」みたいな話ってすごく重要ですよね。日和った意思決定をすると文化が腐るやはりいいチームは当たり前のようにいいプロダクトを作れる傾向にあって、どちらかというとチームを軽視するのがエンタープライズにはけっこう......どうしても稼働率を優先してしまって、チームを簡単に割ったり足したり。あとパートナーさんをどんどん突っ込んだりして。塚:ああ、そうですね。吉羽:要は持続性のないチームを作っちゃう傾向が多くて。そこは改善の余地があるんだろうなって気がするんですよね。ヤフーのなかでもあるんですよね。「身の丈に合ってないビジネスをしてるよね」って僕ははっきり言うんですよ。業務委託みたいなのをドバドバ突っ込んで、お金じゃぶじゃぶ使って......大丈夫かな、これ?(笑)。いうことがあるんですけど(笑)。「文化は意思決定が作っている」って誰かが言ってましたけど、本当にそうだと思っています。いう一見目先の数字が上向きそうな施策にお金を突っ込んでやっても、やっぱりそういう本質を変えない日和った意思決定を上がやっちゃうと、文化が腐るんですね。いうものになんとか抵抗して。僕らはテロリストですからね。暗殺していかないといけないのかなとは思いますけども。(会場笑)吉羽:そうそう。Serviceという会社にいたんですけど、採用の基準とかがすごく厳しくて、会社で明文化した考え方みたいのが14箇条ぐらいあって、それに合ってないと思われる人は、いくらスキルがあったり業界で有名な人でも「僕らには合わない」ということで仲間にしないという選択をしていたんですね。それぐらいカルチャーにお金も時間も使ってる。そこは足元を固めるという意味ではやってもいいんだろうなという気はします。鈴木:DevOpsというのは、先ほどからカルチャーという言葉も何回も登場しているんですけれども、やはりそこに非常に色濃いものがあるんじゃないかと思います。DevOpsの前にまず足元を固めろもう少し具体的なイメージを掴んでいただくために、次の質問。シミュレーション的な感じで取っていただければと思っています。とある企業、例えば牛尾さんの場合はAzureのユーザー、吉羽さんの場合は典型的なガチのエンタープライズ、塚さんの場合はもうとにかくインターネット系の会社、大きめのところを想定してあげてください。その会社で、月曜日朝一番に幹部会議がありました。CEOが執行役全員に対して「我が社はDevOpsをやる」「1週間以内に俺のところにDevOpsの方針を持って来い」という号令をかけます。それで、その執行役がバーっと下に降りて、月曜日のお昼前に各部長会議が行われるわけですね。「どうもCEOはDevOpsを我が社で取り入れるということを宣言された」「さて、どうしたものか」と。エンジニアはみんなDevOpsのツールを使っていると。AnsibleやJenkinsはそこら中で使っている。それを上に持って行ったら「ふざけるな」「ツールを使うことがDevOpsだと思ったら大間違いだ」とCEOに怒られるわけなんです。CEOは少しは勉強されているんです。いうような状況で「相談をしよう」となって、各社、お三方に相談されたときに、どういうところからスタートすべきか。ドライな表現......辛口な方法でもいいと思うんですけども。順番はどんな順番でもけっこうです。塚:これ、先にしゃべったほうが勝ちなんじゃないかなと思ったんですけれども、そんなCEOいるんですかね?。鈴木:いいほうだと思います(笑)。塚:でも、やっぱりこういうときに、牛尾さんがやってるやり方がすごくいいんだなと思います。バリュー・ストリーム・マッピングって、もともとは製品を設計して出荷するまでですよね。誰がどこでどういうふうに関わっているのかというのが可視化される。それがどれくらい放置されてきたのかというのを認識するところから始めないといけないんじゃないかなと思います。その代わり、「CEOはなんのためにDevOpsという概念をやるのかちゃんと考えてくださいね」という感じなのかなと思いました。