lycheejam's tech log

チラ裏のメモ帳 | プログラミングは苦手、インフラが得意なつもり。

レポート:「プロダクトを10年運用するチームをつくる」 #devsumi2020 #devsumiB

概要

Developer Summit 2020に参加して株式会社はてなだいくしーさん(@daiksy)のお話を聞いてきました。

人の入れ替わりにどう対応するか、対策を打つかみたいな話です。

聞けてよかったセッション同率1位くらい、是非スライドに目を通してほしいです。

目次

セッション情報

発表資料

トピック

システムを10年安定稼働させる事の難しさ

昔は「動いているモノに触れるな」で解決した。
しかし、それは過去の話で外部要因によって変化を余儀なくされる。
ex.OSのアップデート/ブラウザのアップデート/脆弱性の対応

(昔ながらの日本のエンプラ系は閉域網使ってインターネットと接続しないので、この外部要因には左右されないので強いっすねw)

否が応でも何かしらの更新が発生するので、それに対応する必要がありますよねと。
CI/CDの整備、監視の整備、DevOpsの整備...etc
システムを触り続ける環境を整える必要がありますよねと言う話。

ここまでが導入。

チームメンバーの変化

外部要因によって否が応でも変化を求められるけれども、
一番変化があるのって人じゃない?と。
なので人の変化に対応出来るチーム作りをしましょうというのが本題。

箱根駅伝の優勝チームは4年かけて最高のチームを作るけど、
IT企業って4年もずっと同じチーム維持することってほとんど無いし
こっちの方が全然難易度高くない?って話が印象的でした。

逆に10年メンバーが同じチームも問題がありそうと言う問いかけもありました。
異動や退職、新規メンバーの加入で新陳代謝も大事ですよねと。

でも、メンバーの入れ替わりで失われるモノもりますよね? プロダクト固有のスキルやドメイン知識とか。
なので、失われない努力(対策)をしましょうと。

スキルマップの作成

上図のようにメンバーがそれぞれどんなスキルを保有しているかを図にする。
すると色々メリットが生まれる。

  • チームのスキルバランスの可視化
  • スキルの属人化によるリスクの可視化(予測が出来る様になる)
  • チームの失われたスキルの可視化(気がつくことができる)
  • 学習目標の指針(自身のロードマップ作成の助けとなる)

おー、なるほどなとなりました。
これ、カイゼン・ジャーニーの本の中でも紹介されていたのを思い出しました。

失われたスキルに気づけ無いことが一番のリスクとdaiksyさんが言ってたのが印象的でした。

上図がMackerelの実際運用しているスキルマップ。
2週毎にスプレッドシートで履歴(シートをコピーで)を残しながら作成するそう。
実際に所属チームの中で最(在籍)年長者が異動した時に、ヤバさに気づけてよかったと紹介してくれました。

所属チームは現状、スキルマップ作らなくても属人化しているのがわかってるんですが、
それでスキルマップ作ってどんなバランスなのか見てみたいですね。

あわせてスキルマップを維持するコツも紹介されていました。

  • 人事考課に使わない。
    →正直に書かなくなる。
  • 他のチームと比べない。
    →ベクトルが違うのだから比べても仕方がない。
  • 項目の粒度を気にしない。
    →細かく作ろうとするといつまで経っても完成しない現象に陥る。
    荒くていいからとりあえず作る。
  • 定期的なメンテナンス
    →Mackerelでは振り返り会のアジェンダに入れてる。

(2週に1度と言っていたので、1スプリントが2週間なのかな?)

障害対応の話

障害対応だから緊急事態だし、古参の独壇場になりがち。
かと言って緊急事態なので教育してる暇なんてないよねと。

その通りでございます...
かく言う私は新しい現場に配属されて即炎上してる障害に一人で放り込まれて泣きましたけどね。

つまり属人化してると。
なので対策を打ちましょうねと。

障害対応演習

実地ではないですが、わざと障害の状況を発生させて教育目的で演習を実施するのが効果的。
Mackerelの場合はステージング環境をわざと壊して復旧するような演習をするらしい。
Netflixは本番でこれをやるらしいw

頻度的は半期に1回程度、メンバーの選定(役割)はスキルマップを参考にする。

もしくは障害発生直後に同じシナリオで実施する。
これは当日、オペレーションに参加できなかった人を中心に選定する。 実際に発生した事象で演習するときはポストモーテムをやったあとに再現するのが効果的らしい。

データベース復旧演習とかやってみてえええwww(演習のために壊す役絶対やりたい。)

去年発生したAWSの大規模障害時は発生の1週間前に、偶然同様のシナリオで演習をやってたらしく
Mackerelは1時間で復旧することができたらしい(すごい)

こんな感じで思い立ってやることもあるらしいw

んで、目次的には式年遷宮の話になるんだけど
前提の話があるので少し飛ばして次の話へ。

技術的負債とプロダクトのスケール

話は変わって技術的な負債の話とプロダクトの成長の話へ。
いや、話は変わってって変わってないんだけどね。

これも、前述の外部要因の話で
プロダクトを運用していたら成長もするし。技術も進化するよねと。

技術が進化するからとかプロダクトが成長するからって言ってはいるけど
要はキャパシティが限界を迎えてシステムが耐えられなくなる時がいずれくると。

なので式年遷宮

式年遷宮をしよう

宮大工の技術が失われないように式年遷宮をするのと同様の理由で、
システムも式年遷宮をしましょうよと。

メリットはこのスライドに全部書いてある。

技術的負債の返済と言う側面を強調するとネガティブでテンションが下がってしまうので
技術の継承だとかポジティブにやろうなって話をしてました。

あとは、プロダクトに一番詳しい人はそのプロダクトを作った人って言うのが印象的でした。
「そこで式年遷宮ですよw」と、作り直せばその作り直した人がプロダクトに一番くわしい人になるよねと。

まとめ

  • チームの人の入れ替わりはいずれ発生する。その時のために対策をすることが大事
    • スキルマップ
    • 演習での訓練
    • 式年遷宮(ほかの表現が見当たらなかったw)

雑感

本当に聞けてよかったなと思いました。
真新しいフレームだったりツールの話ではなく、地道にやってるよって話ではあるんですが
弊社ではやってない話なので「めっちゃやりたい!」となりましたw