2月14日（金）、デブサミ2020に参加してきました。
その中で、特に印象に残った3つの講演についてメモ。ほぼ自分用。

チーム・ジャーニー 〜逆境を越える変化に強いチームをつくりあげるまで〜

DevLOVEの市谷聡啓さんによる講演。 講演内容は、おそらくチーム・ジャーニーの書籍の概要的な内容。

印象に残ったキーワード、メモ

• 不確実性との戦い
• 何を作るべきか、どうやって作るべきか、絶対的な正解を予め手にすることができない
  • 意思決定や合意形成が難しい
  • 理解不足や練度不足で成果にならない
• 組織変革の不確実性、前例がなく拠り所がない
• 分断が2項対立世界を作る
  • 一方を通すために、もう片方を極端に低評価するアプローチ
• 段階を取り入れていく
  • 一気に理想へ到達することを狙わず、発展の段階を設計し、求められる変化量を調節する
• 二項対立が招いたもの：全体性の欠如
• 希望があるからこそ、自分たちの歩み自体を楽しむことができる。

所感

心から共感する内容が多く、チーム・ジャーニーの書籍も読んでみたいと思った。

今思い返すと、スクラムのチームを任されたときは「スクラム、できてるのかな」とか「スプリントがうまく回せてないかも」ということに意識が向きがちだった。
でも一番重要なのはきちんとリリースするための手段として、スクラムを取り入れること。
理想はスクラムという外部から与えられたものではなく、自分たちにとって理想的なやり方を作り出すこと。
世の中に答えを求めるのではなく、自分たちにとっての正解を作り出していくことが重要になるんだろうな。

自分がわからないことや経験のないことに向き合う時、人は外に正解を求めやすい。
これは人の心理なのか、それとも学校教育の弊害なのかわからない。
でも正解がわからない中、現時点で最適と思う納得解を出し続けていくしかないのだろう。

守りのモニタリングから攻めのモニタリングへ

New Relicの大谷和紀さんによる講演。自社製品を推す内容が多めの印象。

印象に残ったキーワード、メモ

• 従来のモニタリング
  • 障害を素早く検知、警告
  • MTTRの改善、ダウンタイムの削減、サービスレベルの維持
• オブザーバビリティ成熟モデル
  • 4. データ駆動
  • 3. 予測敵対応
  • 2. 積極的対応
  • 1. 受動的対応
  • 0. 計測を始める
• New Relicで扱うもの
  • Metrics：測定値の集合
  • Event：ある瞬間に発生する個別のアクション
  • Log：システムが生成するテキスト行
  • Trace：異なるコンポーネント間のトランザクションの因果連鎖

所感

オブザーバビリティ成熟モデルなどの用語や観点が印象に残ったので、モニタリングを設計するときには参考にしたい。
また、講演中に「監視はSaaSのほうがよい」というTweetを見かけたけど、確かに…と思った。
これはそもそも監視を自前で作ると、そのインフラ自体が落ちていることに気付けないから。

これからインフラがAWS、Azure、GCPなどに集約されていく中、それらをどうやって監視すべきなのかは今後考えていきたいと思った。

プロダクトを10年運用するチームをつくる

はてなの粕谷大輔さんによる講演。講演資料はこちら

印象に残ったキーワード、メモ

• 人の入れ替わりへの対処
  • 駅伝は4年間で人が入れ替わる環境でチームを作っている。しかし、IT業界の方が入れ替わりが激しいのでは？
  • 人の入れ替わりによって、プロダクト固有のスキルやドメイン知識が失われる。
• 対処1：スキルマップ
  • スキルマップのメリット
    • バランスの可視化
    • 失われたスキルに気付ける
    • 学習目標の指針
  • スキルマップを維持するコツ
    • 評価に使わない。心理的安全のため
    • ふりかえりのアジェンダに入れるのがよい
    • ちゃんとしようとすると作れない
• 対処2：障害対応演習
  • 障害対応あるある
    • 属人化しやすい、隅から隅まで知っている古参メンバーが強い
    • 緊急事態なので丁寧に教育する余裕がない
    • 新規メンバー：何が起きているか分からない、何を学べばできるようになるか分からない
  • ステージング環境をわざと壊して復旧させる演習をやる
    • 半期に1回、スキルマップを参考にやる
    • 実際の障害が発生した直後に、同じシナリオでやる。当日オペレーションに参加できなかった人中心に
  • 例
    • AWSのAZの一つを壊して復旧
    • DBを意図的に壊して復旧
    • 同一シナリオを再現
• 対処3：式年遷宮
  • アーキテクチャやフレームワークなど、システムの根幹部分に手を入れるプロジェクトを一定間隔で行う
  • スケールアップへの対処。モダンなアーキテクチャへの以降といったポジティブな理由をモチベーションとする
  • 技術継承のため。式年遷宮に参画したメンバーは、最も詳しくなる

所感

現場感が強く伝わってくる、とてもよい内容だった。
障害対応演習（避難訓練）は有効だと感じたし、BCPの観点からも本来やるべきことなので、妥当だと感じた。
社内で実際にやるには、そのための工数を予め積んでおくと同時に、スケジュールをしっかり確保しておくことが重要になりそうだと思った。

確かGoogleが「すべてのソースコードは○年で書き換わる」というようなことを言っていた気がするのだけど、式年遷宮はこれに通ずる所がありそう。
結局、ソフトウェアやシステムはソースコードからアーキテクチャまで含めて、自分が真に理解している状態でなければ手足のように操ることができないのだと思う。
式年遷宮を定期的に行うことで、技術継承と生産性の向上を両立させることができるのだと感じた。

全体の所感

普段は日々の忙しさにかまけて、アーキテクチャ移行とか考えたりするのをついついおろそかにしがち。
しかし、こういうイベントに来ると業務から切り離されて、考えるきっかけになるのがとてもよい。
1日でできる仕事量なんて限られているので、忙しくてもこういうイベントに足を運び、きちんとキャッチアップしていくことの重要性を改めて実感した。