DevOpsDays Tokyo 2023 各セッションから学ぶDevOpsの特徴

この度4/18(火)と4/19(水)に開催されたDevOpsDays Tokyo 2023に参加しました！(オンラインですが)
全てのセッションを聴講できなかったので聴けたものをまとめていきたいと思います。
最後に各セッションを聞いて自分なりの感想や各セッションの共通点などもまとめていきます。

1. 高信頼 IaaS を実現する DevOps

さくらインターネットのDevOpsの話です。
ここではSRE室がDevOpsの役割を果たします。

行ったこと

  • DevOpsを実践していく上でまずは目標や期待値を明確化する
  • 決め事は作らず一緒に手を動かして信頼性を向上していく文化を作っていく
  • 開発と運用もコミュニケーションを活発にして動く

具体的な活動

  • みんなが同じ知識ではないので情報の共有
    • ヒアリング会(情報の共有)
    • 読書会(知識の共有)
  • CICDの整備
    • いろんなツール使っていたがGitHubActionsに統一

SRE室自体の課題

これらの活動を行う上で期待値のズレが起きました。
→ まずはチームづくりから始めます
朝会、定例、個人を責めない振り返りやこまめにドキュメンテーションを行うことで問題の早期発見が可能になりました。

まとめ

まずは目標や期待値を合わせることが大事です。

2. GitHub Actions & オートスケールする Self-hosted runner で実現する KAG のみんなの CI/CD

KDDI アジャイル開発センター株式会社 (以後 KAG) で始めたスターターチーム

スターターチームとは案件を持たずに存在するチーム
目的は個人個人の価値を提供するのではなくチームで価値を提供することです。
従来の方法では案件が発足したタイミングでチームを組む(メンバーが決まる)のですぐに連携が難しいが、あらかじめチームを組んでおけばチームビルディングも実施いておけるのでスムーズに案件に入れます。
案件が終わっても同じチームで動くことでよりチームとしての価値がより高められます。

問題点

  • Outputがわかりづらい
    すぐに活動できれば価値を見せやすい。
    →そのためにすぐ使えるCICD基盤が欲しい

解決策

GitHubActionsのSelf-hosted runnerを使いました。
Self-hosted runnerとはGitHubActionsのWorkFlowを自前の環境で実行するように指定できる機能です。

結果

Self-hosted runnerによりみんなが共有して使えるCICD基盤を用意でき早期活動ができるようになりました。

3. 変更障害率0%よりも「継続的な学習と実験」を価値とする〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜

背景

DevOpsが浸透していないときの株式会社ナビタイムジャパンでは障害がバレるとヤバいというマインドでした。
障害が起きると社内であっても謝罪する文化です。これだとみんなは障害が発生しても隠れて修正して報告をしないようになってしまいます。
結果、一人で隠れながら修正を行うことになり時間はかかるし、再発生時にすぐ対応できないので解決したかった。

変えたこと

  • 障害はあるものという認識の共有しSlackに発生した障害を投稿するチャンネルを用意
    2020年以降はより気軽に障害を共有できるチャンネルも用意
  • 障害報告・再発防止策について勉強会を実施
    障害が発生した際、再発防止のためナレッジを共有しました。
    障害報告は反省文ではなくナレッジとして活用しました。
  • テストの意識
    これまでテストの意識 : 障害のない保証
    現在のテストの意識 : チャレンジできる機会

結果

障害発生率は減り、デプロイの頻度が増えました。
また早期発見解決共有することが大事な価値観が生まれました。

DiRT の実施

DevOps が浸透してきた頃スクラムフェス大阪に参加し DiRT について知ってからDiRTの社内上映会、API基盤チームが DiRT を実施するまでトントン拍子に進みました。
ここまで会社的に行動できたのは長年かけて作られた文化と価値観の変化の力だと考えられます。

4. ノリと組織

株式会社ポリゴン・ピクチュアズが"オモロイ"ものを想像するための仕組み、場、組織づくりなどお話しされました。
DevOpsの観点から"オモロイ"ものを想像するために大事なことは以下になります。

  • ノリ
    将来を見据えて行動することはできない。そこでノリを信じて行動していく。
    そこで会社としてミッションステートメントをノリで実行していくことがDNAとして引き継がれ続けています。
  • WHY
    WHYを明確にWHATはおぼろげに提示します。
    "なぜこのプロダクトを作るのか" が無いと完成した後になんで作ったのかとなってしまいますが、WHYをちゃんと伝えればその過程は様々であっても同じ目的地にたどり着きます。
  • 場
    オフィスはカッコよくしていきます。カッコよければオフィスに興味を惹かれて人々が集いムーブメントが起きます。
    またリモートワークの方が効率も良くなるのでオフィスは働く場所から集う場へ変えています。
    集う場にしたことでイベントも活発になりメンバーがより行動するようになっていきます。
  • 人
    動かせる人材はやはり必要です。
  • 物語
    物語を聞く力が伝える力が無いと人を動かすことは難しいです。
    面接でも「あなたのライフストーリーはなんですか？」と聞いています。

4つのセッションでわかったこと

ここから自分なりに感じたこと共通点などをまとめたいと思います。

共通点

  • 動かす人がいる
    SRE室や社長など何かしら行動を起こす人(チーム)がいないと何も始まらないと思いました。
  • 全社員が動く、または動かされるようなイベントや環境を用意している
    イベントや環境を用意したことで積極的でない人も動かされるようになっていくようになっていると思います。
  • outputをしている
    成果物はもちろんだが障害が起きたときの報告や勉強会など多くの人が知られる場所に対しoutputを行っている。
    このDevOpsDays Tokyoの公演も一つのoutputだと考えます。
    outputにより他の人も"自分も行っていい"をいうマインドになれると思います。
  • 新たな文化が生まれる
    これはDevOpsの行動を行った結果だが総じて行なった活動が文化となり会社の一部になっているように思われます。
    文化になっていることでまた同じ問題が起こるといったことはないように思いました。

わかったこと

各セッションを聴いて実感したのはこれらの行動を起こそうとした人がある程度影響力を持っていることでした。
DevOpsDays Tokyo 2022に参加した際も企業の社長が登壇してくださりどのように会社を変えていったかを聞きとても素晴らしかったと記憶しています。
ここまでDevOpsの文化を浸透させるには上のものにいかに声が届くか、そして対応してくれるかでかなり変わると思いました。

感想

KAGのスターターチームは面白いと思いました。
はじめのチームビルディングは大変だと理解しているので良い案だと思いました。しかしチームが固定されることで知見が周りに共有されないのではとも思いました。

ノリと組織ではオフィスを働く場所から集う場へ変えていくというのは大賛成です。個人的に仕事をするには家の方がやりやすいですしオフィスを仕事をする場でなくコミュニケーションをする場に変えればとても良くなると思います。

プロフィール

吉村海斗
吉村海斗
緑を目指してAtcoderやってる2年目エンジニアです。
AWSアソシエイト三冠達成しました！
AWSプロフェッショナル二冠目指してます！
Rubyが好きです。