「DevOps Interview with Q&A」のメモ #DevOpsDaysTokyo 2021

DevOpsDays Tokyo 2021の一日目のKeynote「DevOps Interview with Q&A」のメモ

DevOpsDaysの創始者でありTHE DevOps HANDBOOKの著者でもあるPatrickAlexがインタビューする形式

メモ

DevOpsの名前の由来

  • DevOpsという名前は「DevOpsDays」のイベント名に由来。
  • 「DevOps」という名前は考えていなかった
  • カンファレンス後に「DevOps」という名前がついた。業界の言葉になると思ってなかった。

DevOpsの定義

  • 正式な定義はない。意図的にDevOpsの定義をしなかった
  • いろんな人に定義してもらいたいと思っていたから
  • 定義を紙(?)にすると誤解されてしまう
  • 定義を閉じ込めたくなかった
  • 常に新しいアイディアに対して扉を開き、進化するスペースを持つようにしたかった

Patrickの定義:サイロ間の摩擦を取り除くこと(reduce friction)

定義はしたくないと言った上で、10年以上活動してきた中で見えてきたPatrick個人の中にある定義を教えてくれた

  • どうやってサイロを取り除くか
  • どのようにサイロ間の橋渡しをするか
  • どのテクノロジーを使っているかではなく、ギャップを埋めることがDevOps
  • 例えば、DevとOpsの間でうまくいっていても人事の採用基準があっていないならギャップがある
  • パイプラインが完璧であっても、ビジネスの成功は約束されていない
  • 最近は、文化の部分を強調するようになった
    • でも、テクノロジーの話もする
    • 「テクノロジーによって摩擦を解決する」方向で話す
    • DevOpsDaysは、午前中はソーシャルトーク(コラボレーションやテクノロジーがギャップをどう埋めるのか)にしている
    • テクニカルな話はブレイクの後にする
  • 元々の意図が失われる時がある
    • 「DevOps=自動化」と結びつけられている時がある
      • 元々の意図はそこではなかった
    • アジャイルスクラムになってしまった
    • ITILがチケットになってしまった
    • 言葉として「DevOps is dead」という人もいる
    • NoOpsという人もいる
  • DevOpsのアイディアというのはサイロを結ぶもの

その他

  • パラドクス(矛盾)
    • 自動化の理由を忘れてしまった。
    • セキュアだと感じれば感じるほど、十分だと安心してセキュリティのバジェットを確保できない
    • カスタマーセントリック
      • お客様にフォーカスする
      • スタートアップSaaSはそうして始まった
      • やがて、たくさんお金を払ってくれるお客様にフォーカスしてしまう
      • それはカスタマーセントリックなのか?
  • Continuous Learning
    • 時間をかけて自分のバイアスを変更する
    • ラーニングパス(学びの道筋)を文脈の中で醸成していく
  • なぜやっているのか?他の人がやっているから?
    • CICDシステムがうまく機能しているとしましょう
      • 一日エンジニアがそこにいなかったら?
      • 一週間は?なんとかなるでしょう
      • 二週間は?不安になってきますよね
    • 人が何をすべきか。どうしてやっているか
      • 「どうしてやっているか」のWhyの部分を説明できれば、CICDシステムがなくてもできる
  • マイクロサービス
    • マイクロサービスが出てきたときに開発者の多くはワクワクした
    • オペレーションの人も限定的にデプロイすればいい
    • 開発者はFunctionだけに集中するようになって
    • 全体の複雑さはオペレーションが理解することになった
    • 複雑さをどこか別のところにシフトしているだけ

Q&A 1

DevOpsDaysの10周年のオーガナイザーミーティングに参加して感動した。
隣に座ったジュネーヴ(スイス)のオーガナイザーに
「どういう人がジュネーヴのDevOpsが来るんですか?」と聞いたら
「スイスだから、銀行、病院、ジュネーヴだから、時計が多いかな」

日本では、システムインテグレーターが多い。時計メーカーはみるけど、銀行はあまりみない、病院はみたことがない。
わからない人への説明役ではなく、エンジニアリングに集中させてあげたいと考えているけど、アドバイスがあればください

  • DevOpsDaysは、地域のローカルなコミュニティと繋がって宣伝している
  • 開発セントリック、ビジネスセントリックとイベントによって方向性が違う
  • オーガナイザーが最初にネットワークを作って、広げていく
  • スイスでは元々オーガナイザーが金融業界だったから、そこから広がっていった
    • オーガナイザーのツテがきいている
  • 経営陣にどのように説明するのがいいのか?
    • THE PHOENIX PROJECTTHE UNICORN PROJECTのような本がある
    • 大企業のサクセスストーリーですべてがいいわけではないが、DevOpsDaysよりもビジネス的な用語が使われている
    • こういった本が有効だと思う
  • なぜコラボレーションが有効なのか?
    • 信条(belief)のレベルで話していないか自問自答してください
    • 「自動化すればコラボレーションは必要ない」と考えている人もいる
  • Damon Edwardsはビジネスの方にDevOpsの話をしている
    • あるCEOの方は「おもしろいね。でも、商品の値段を数セントあげれば同じ改善ができるよ」と言った。ということもあるので過信はできない。
  • DevOpsというのは、常に話しあってより良い仕事をするためのもの
  • モブプロ
    • 7人が同じところで問題解決することで、効率的じゃないかという人もいる
    • これは信条の問題で、コラボレーションをすることによって、より効率的になると私は考えている
  • 昨今のソフトウェアは、機械的にAをやってBをやってCをやってとすればいいという世界ではない
    • 試行錯誤してみつけていく
    • その答えがコラボレーションだと思っている

Q&A 2

聞き逃した!

Q&A 3

本を読まない。勉強をしない。
そういう人たちにGracefulにどうDevOpsを広めるか?
1歩はできると思うけど、3歩くらい踏み出すためのポイントはありますか?

  • 関心がないけど、どう説得すればいいか?
    • 彼らがペインを感じていないか、あなたが相手のペインを感じられていない
    • 自分たちで問題があるということを気づくことが重要
    • そしたら、アドバイスをすることができる
    • 私から問題を説明することはできない。説明しても聞く耳を持たない。
    • まずは、じっくり話を聞いてください
      • 「あなたはどういう問題を抱えていますか?どうやってサポートできますか?」と聞いてください
      • DevOpsという言葉は使わない
    • 信頼関係を作る
    • どういった問題を抱えているのか理解する
    • アドバイスは、いい質問をすること
    • 「どういう問題があって、私からはどういう価値を提供できますか?」

Slide

事前の打ち合わせスライドらしい

参考

DevOpsの歴史に関して参考になりそうな資料

newrelic.com

www.ryuzee.com