はてな粕谷氏が実践する「プロダクトを10年運用するチームの作り方」：「Developers Summit 2020」レポート（1/2 ページ）

「どれだけ長い間、ユーザーに価値を提供し続けられるか」という視点はビジネスを成功させるために重要だ。だが、サービスを長期間運用し続けるのは簡単ではない。はてなで「Mackerel」を運用する粕谷大輔氏がたどり着いた答えとは。

[編集部,＠IT]

　新たなサービスを立ち上げることは簡単ではないが、それを運用し続けることもまた難しい。サービスは提供された時点から徐々に陳腐化していくからだ。それ故、エンジニアは日々サービスを更新し続ける必要がある。CI/CD（継続的インテグレーション／継続的デリバリー）の仕組みは一般的に認識されつつあるが、長い期間運用が続けば、それだけでは対処しきれない新たな問題が出てくる。異動や退職などによる人の入れ替わりがいい例だ。

　はてなでクラウド型サーバ管理サービス「Mackerel」のチームディレクターで、認定スクラムマスターである粕谷大輔氏は、同サービスを長期間にわたって運用しているが、こうした問題に対してどんな対策を取っているのか。長期間健全でいられるチームを構築するためのノウハウとは何なのか。

　本稿は、2020年2月13〜14日に開催された「Developers Summit 2020」にて粕谷氏が講演した「プロダクトを10年運用するチームをつくる」の内容についてまとめたものだ。粕谷氏が挙げた「プロダクトを長期間運用するに当たって対処すべきポイント」は以下の3つだ。

• 変化し続ける周辺環境とシステム
• 人の入れ替わりへの対処
• 技術的負債とシステムのスケール

「動いているシステムは触るな」は「触り続けられる環境」で対処

　まず「変化し続ける周辺環境とシステム」として、粕谷氏はシステムに対する考え方の違いについて述べた。

はてなの粕谷氏

　「以前は『動いているシステムは不必要に触るな』というのが主流だったが、それはもう昔の話。ソフトウェアを取り巻く周辺環境の変化は激しく『インターネットとつながり、さまざまなサービスと連携するソフトウェア』が当たり前に存在している。そうなればOSのバージョンアップやブラウザのアップデート、日々発見される新しい脆弱（ぜいじゃく）性など周辺環境の変更に追従するために、頻繁にシステム変更が発生する」

システムを更新し続ける仕組みが必要（出典：はてな）

　しかも、スマートフォンの自動アップデートのように、もはやソフトウェアの更新はユーザーが意識することなく実施されるものになっている。ユーザーに意識させずにソフトウェア更新をするためには、テストやデプロイを自動化する「CI/CD整備」「監視の整備」「DevOpsの構築」が必要だと粕谷氏は語る。

　Mackerelの場合は管理ソフト「Jenkins」を利用してCIを実現し、サーバ監視にはMackerelを使っている（ドッグフーディング：Dog Fooding）。DevOps構築についてはアプリケーションエンジニアとSRE（Site Reliability Engineering）が同じカンバンボードでタスク管理をすることで実現しているという。

　「こうした整備をすることで初めて『システムを触り続ける環境』が出来上がる」（粕谷氏）

人がいなくなって失われるものは何か

　次に粕谷氏は「人の入れ替わりへの対処」について述べた。

　「システムを維持するのは人だが、10年間人が入れ替わらないチームはない。人が入れ替わることによって何が困るかといえば、失うものがあることだ。『その人と過ごすかけがえのない日々』はSNSのつながりなどで継続できるが、その人が持っているプロダクト固有のスキルやドメイン知識が失われるのはプロダクトへの影響が大きい」

　これらに対処するための方法として、粕谷氏が実際に取り組んだのが「スキルマップの作成」「障害対応演習の実施」「式年遷宮（しきねんせんぐう）」だ。

スキルマップによって「具体的にチームの弱い部分」を把握

　スキルマップとはチームメンバーのスキルや知識、例えばプログラム言語や障害対応、設計、ファシリテーションといった「チームを維持するために必要なもの」を可視化するためのツールだ。チームのスキルバランスの可視化やリスクの事前察知に役立つという。

　粕谷氏は、スキルマップの重要な効果として「可視化によって『チームから失われるスキル（知識）に気付ける』こと」を挙げる。例えば「フロントエンドに強いエンジニアが抜ける」などであれば失われるスキルは明らかだが、暗黙知など「失われたことすら気が付かないスキル」が意外と多いと粕谷氏は語る。

　だが、有用なこのツールも維持するのが大変で、何年か運用していて見えてきた「スキルマップをうまく維持するためのコツ」を粕谷氏は紹介した。

　1つ目は「スキルマップを評価に使わない」。評価につながると考えれば「自信がないスキルだけど問題ないことにしよう」といった心理が働き、正しいスキルが見えにくくなる。そのため、評価とは別のものだと強く主張して心理的安全を確保する必要がある。

　2つ目は「スキルを他のチームと比べない」。「他のチームはJavaとPHPを使っているが、自チームは使えない」といった比較は意味がなく、あくまでも自チームに何が必要かという点が重要だ。

　3つ目は「項目の粒度を気にしない」。しっかりと作ろうとして「ネットワークスキルが必要だけど、正しく分類しないと」といった議論が始まってしまうと、いつまでたってもスキルマップが作れない。思い付きのレベルでいいので必要そうなものをどんどん挙げた方がいいと粕谷氏は言う。

　4つ目は「定期的にメンテナンスする」。チームメンバーが変わりそうなタイミングでスキルマップを参照しようとしても最終更新が1年前、といった状態で意味がない。粕谷氏は振り返り会などのアジェンダに入れておいて定期的に更新することを勧めている。Mackerelでは2週間ごとの振り返りでスプレッドシートを見ながらチームメンバー全員でチェックするという。

　粕谷氏がスキルマップの効果を実感したのは、チームの中でもエース級の実力を持つCさんの異動が決まったときのことだ。

Cさんの異動によってチームから失われる技術（出典：はてな　※編集部で一部加工）

　「スキルマップからCさんのスキルを削除したところ、チームから幾つかの技術が目に見えて失われ、チームが騒然となった」（粕谷氏）

　このままではチームが破滅すると感じた粕谷氏とチームメンバーは、急いで不足するスキルの補填（ほてん）に務めたという。粕谷氏は「簡単にできるので、だまされたと思ってやってみてほしい」と勧めた。