同期鰻
- ごく普通のエンジニアリング運用チームを強力なSREチームに変える | Google Cloud Blog
- これめっちゃよかったな…
- 「ごく普通の」と言ってはいるが、世の中的に見たらかなりハイレベルだろうな、とは思う
ルーターのアップグレード作業は、ソフトウェア エンジニアリングを必要とするプロジェクトの良い例でした。それは、Googleのエンジニアリング担当バイス プレジデントBen TreynorによるSREの説明にぴったり合致しています。「ソフトウェア エンジニアに運用上のファンクションの設計を依頼したときに生まれるものがSREの本質である。」
- 端的にまとまっていていいな〜
1年後には、ネットワーク エンジニアがルーターを手動でアップグレードするのは、ルールではなく例外となりました。実際、システムの信頼性ははるかに向上したので、手動でアップグレードを行うためには論理的根拠が要求されるようになりました。
- 良貨が悪貨を追い出していく例だ…！
私たちはチーム内での実際のスキルに格差があることに気付きました。まず、スタッフのほとんどはソフトウェア エンジニアリングの経験がありません（ネットワークについては確かな経験があります）。そこで、すべてのスタッフを対象とした社内教育プログラムを作成して自習時間を取れるようにし、能力の向上、実習、質問のための機会を設けました。
- ちゃんと、払うべきコストを払っているんだよな
ルーターのアップグレードをはじめ、転換への過程で数多くの新しいシステムが生まれ、成功しました。それらのエンジニア プロジェクトは、私たちの成功への原動力となりました。そして、システムの構築、手動作業の削減、SREへの転換、さらなるシステム構築、システムの信頼性の向上などの過程から成る、永続性のあるカルチャー サイクルとなったのです。
- めちゃくちゃいいな…
皆さんの組織でこのような変革を検討されているなら、最後にお尋ねします。皆さんの運用チームには、ソフトウェアを開発して問題を解決できるメンバーがいますか。「はい」であるなら、そのメンバーが挑戦できるよう支援してみてください。
- はい (はい)
- 失敗から学んだ１on１の重要性。DMM松本勇気の過去から紐解く「組織のポテンシャル」の引き出し方 - エンジニアtype | 転職type
失敗を許容できる環境を作り細かく沢山の挑戦を促す「Agitliy」、
数値をベースに科学的に判断を下しているかを問う「Scientific」、
社内外にとって魅力的な組織を目指していこうという姿勢を問う「Attractive」、
自分の仕事の意義を理解し仲間とともに意欲高く仕事に取り組めているかを問う「Motivative」
の４項目について、毎月決めた目標に対してどれだけ近づけたかを話し合いながら確認することで、お互いの意識をこまめに評価するようにしています。
- へぇ〜という4項目だった
今、私たちは３カ年計画でDMMをテックカンパニー化する計画に取り組んでいますが、私にとって最大のミッションは、「エンジニアが安心して挑戦し、失敗できる組織」をつくることなんだと思っています。
