概要

先日、『DevOpsDays TOKYO 2023』という世界中で開催されているカンファレンスに参加しました。
そこで、『ソフトウエア開発プラクティスのトレンド』や『障害対応についての考え方』について考える機会を得ました。
この記事では、私がカンファレンスに参加し、心に残ったセッション内容、気づかされたこと、感じたことを、参加レポートとして書いていきたいと思います。

記事の内容

  • ソフトウエア開発プラクティスのトレンド
  • 障害発生件数を0件にすることが必ずしも最優先ではない？
  • DevOpsDays TOKYO 2023で気づかされたこと、感じたこと
    • あまり知らなかったDevOpsの歴史
    • 目標立てるとき『障害発生件数を0件に』と書いてたなぁ
    • コミュニケーションって大切

ソフトウエア開発プラクティスのトレンド

自動テストのFour Keys​ テストプロセスのソフトウェア化の4つの鍵
https://confengine.com/conferences/devopsdays-tokyo-2023/proposal/18440/four-keys-4

このセッションの中で『食べログ品質管理室の活動とソフトウェア開発プラクティスのトレンド』というお話がありました。

内容は、
話題の『Developer productivityは、元を辿ると日本の製造業、『トヨタ生産方式』、『TQC QC活動』、から源流は来ている。
1970年代では日本の製造業が様々なプラクティスを導入し取り組んでいた。
そこから受け継がれ2001年に『リーン』、『スクラム』、『XP』の提唱者たちによって、アジャイル開発前言が出される。ここで『アジャイル開発』が出てきます。
『アジャイル開発』はその後、パイプラインの自動化、テスト自動化など、自動化のプラクティスと融合していくことにより、継続的デリバリーへと発展し、さらにインフラ面の自動化（クラウドIOC自動化）とマージし『DevOps』へと発展してきた。
近年話題の、『Developer productivity』はこの反復作業を、より早くボトルネックを見つけ、積極的に改善していくところが『Developer productivity』のプラクティスだと考えている。
といった内容でした。

Four keysのお話や、「自動テストのFour keys」の提案といった内容もセッションには含まれていましたが、自分の中で、いままでDevOpsの歴史を意識したことがなかったため、釘付けになりました。

障害発生件数を0件にすることが必ずしも最優先ではない？

変更障害率0%よりも「継続的な学習と実験」を価値とする〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜
https://confengine.com/conferences/devopsdays-tokyo-2023/proposal/18230/0dirt

こちらのセッションでは、
障害を発生させないことが目標として設定されていた。
障害報告を上げると自分の責任になるのではないかという不安感から疑わしい事象を報告することについて心理的ハードルが存在していた。
2016年頃Slackの導入により、障害について報告するチャンネルが開設され、「あってはならないもの」から「起こりうるもの」へと意識が変化して行く様子。
このような変化を通じて、組織の価値観がDevOpsマインドに転換していった軌跡が時系列で紹介される内容でした。

話のペースや進め方も心地よく、ガッツリ聴き入ってしまいました。
『障害が発生した際社内に向かって謝罪するのはやめよう』というワードと
『文化は急には変わらない。指針を打ち出し、その指針に沿った行動を促す仕組みをつくる。そこで学習と実験が起こり、「継続的な学習を実験」が組織に根付いていく。』
というワードがとても印象的でした。

DevOpsDays TOKYO 2023で気づかされたこと、感じたこと

あまり知らなかったDevOpsの歴史

私は、DevOpsをピンポイントで学ぶことはありましたが、背景や歴史をあまり意識して学んできませんでした。
DevOpsに興味を持ち学び始めたのも最近です...。

DevOpsとは...。
といった基本的な事は書籍や、ブログなどで学んで知っていました。

ですが、スクラムやアジャイルもそうですが、ピンポイントで学んでいたため、理解するのに時間がかかってしまうことがあったり、いざ実践しようとするとうまくいかなかったりして、モヤモヤした気持ちになることがありました。
しかし、うまくいかないことがあってもいいんですね。
背景や歴史を知ることで、生産性を上げるため、先駆者たちも、様々な取り組みを行い成功と失敗を繰り返し、進化し続けてきたことがあたらめてわかりました。
失敗を経験し、次に進んでいくことの大切さを知り、さらにDevOpsという文化が面白く感じる機会になりました。
今後どのように進化していくのか楽しみです。
自分も、楽しみながらDevOpsに関り、進化し続けたいと改めて思いました。

目標立てるとき『障害発生件数を0件に』と書いてたなぁ

会社でKGIやKPIを設定するときKGI（重要目標達成指標）に、『障害発生件数を0件』って書いてました...。

まさに、
小さなインシデントは生涯にカウントしないとか、
顧客に影響がなければ障害じゃないとか、
言い訳し隠すようになったりして、目標を達成することや怒られ内容にということばかり意識し、よくない風潮になっていました。

ですよね。そうなりますよね。
怒られたくないですもん。目標達成したいですもん。
ですが、障害やインシデントを隠すようになったりすることで、初動が遅れたり、影響が広がったり、悪影響が出ることが多いんです。
怒られないようにと気にしていること自体、心理的安全性も低くなってしまいます。

『障害は起こりうるもので、対処できるものだ』

『文化は急には変わらない。指針を打ち出し、その指針に沿った行動を促す仕組みをつくる。そこで学習と実験が起こり、「継続的な学習を実験」が組織に根付いていく。』

素敵なマインドですよね。

こういったDevOpsのマインドを知って欲しい！！！広げていきたい。そう感じました。
激しく共感し、印象に強く残ったセッションの一つでした。

やっぱりコミュニケーションって大事♡

DevOpsDays TOKYO 2023で特に感じたことは、コミュニケーションってどんな場面でも、重要になってくるんだと感じました。

プロジェクトは一人で行うことが少なく、たいてい誰かと一緒に取り組んでいきます。
チームメンバーがいてくれることが多いです。
チームメンバーがいるのであれば、不得意な部分をカバーし得意な部分を生かせる環境作りができたら、パフォーマンスも発揮でき、ナレッジ共有やいざという時（障害時）に強いチームになっていけるのだろうと考えてます。
また、チーム内でのコミュニケーションは、ミスを減らし、問題の早期発見と修正、プロジェクトのスムーズな進行を可能にすると考えます。

もちろん、異なる部門間での協力も非常に重要です。
開発者、テスト担当者、運用担当者、セキュリティ担当者、プロジェクトマネージャーなど、異なる部門が関わっている場合が多いです。
こうした場合、コミュニケーションを適切に行うことで、チーム全体の理解度を高め、目標の達成を促進することができます。

対人間の意思疎通をスムーズに行い、信頼関係を築くうえでも重要ですが、気分が乗らない時だってあります。
特に女子の月一イベントの前は、イライラすることが多いし、情緒不安定になるし、話したくなくなる時もあります...w
では、何から始めたらいいの？話すの苦手...。
と色々と考えだすと、むずかしくなってきてしまうので、
私は、相づちなどのリアクションをしっかりとることを心がけ、コミュニケーションをとっていこうと再決意しました。

リモート環境での仕事では特に、
Meet、Zoom、Teamsなどで会話していても、相手の反応がなく、『心が折れそうになってしまったり』、『聞いてるのかな？』と感じてしまうことがあります。
表情や相づちなどのリアクションをとることで、相手に対し聞いています！という意思も伝わるし、自分も話す側ならそうして欲しいと思ったため、こういった小さなことから取り入れ、続けていきたいです。

コミュニケーションを円滑にとり、雰囲気の良い強いチーム作りができる人になっていきたいと感じました。

プロフィール

中嶋 直美
中嶋 直美
一児の母です。
新潟県でエンジニアしています！