CloudNative Days Tokyo 2022 登壇レポート -Vol.04 / 開発者向けブログ・イベント

2022年11月21日（月）～22日（火）に「CloudNative Days Tokyo 2022」がハイブリッド開催されました。
GMOインターネットグループはダイヤモンドスポンサーとして協賛・登壇しました！

今回は、CFPセッション「ペパボのSREが生産性の向上を目指しCloud Nativeなチーム作り実践した話」の書き起こし記事となります。
ぜひご覧ください。

イベント告知：https://developers.gmo.jp/25932/

登壇者（敬称略）

GMOペパボ株式会社　技術部プラットフォームグループ（PFG）
渡部龍一（@ryuichi_1208）

「ペパボのSREが生産性の向上を目指しCloud Nativeなチーム作り実践した話」

プロローグ

本日は、パパボのSREが生産性の向上を目指しCloud Nativeなチーム作りを実践した話というタイトルでお話ししていきます。

最初に、簡単にプロローグの話からしていきます。
これは2021年の11月頃の上司と私の会話になります。
「チームの体制変わるんだけど、スクラムマスターやってみない？」という声をかけていただき、私は二つ返事で「やったことないけどやってみます！」と回答しました。それに追加した情報としては、「今後も人増えたり移動したりってのは短期的に発生する予定です」ということで、私は「チームをスケールさせる必要があるということですね」と理解しました。

本日のセッションは、スクラム経験がほぼなかった私が、SREチームのスクラムマスターとして1年間奮闘したお話となっております。対象者はチームでの開発を行っているすべての方と思っております。

自己紹介

最初に、簡単に自己紹介をさせていただきます。
私は渡部龍一と申します。所属は、技術部プラットフォームグループというところで仕事をしています。以降、「PFG」と省略させていただきます。
役割としてはSREがメインで、あとはスクラムマスターを兼任しております。好きな言語はGo言語で、好きなミドルウェアはNginxです。趣味は旅行、ドライブだったり技術書集め、ちょっと古めの技術書が好きで古本屋などへ行ったら見ています。

セッションの内容にも関わるので、ちょっとだけ経歴についてお話しさせていただきます。
2017年から2019年は、Linux向けファイルシステムの開発プロジェクトに開発メンバーとして参画していました。そのあとは、ニュースサイトの運用開発ということで、こちらも2年ぐらい開発メンバーとして参画しておりました。2021年7月にGMOペパボへ入社して、ちょうど1年前、2021年11月に現チームのスクラムマスターになりました。

所属チームの紹介

次は所属チームの紹介をさせていただきます。
先ほど申しましたように、私が所属しているのはPFGというところで、役割としてはGMOパパボのサービスの可用性を確保し、成長に合わせて適切な環境を提供するグループとなっております。
ミッションとしては、サーバーの調達やキッティングに留まらず、SREによるサービスレベルの向上や、あとはクラウド環境の検証や選定を行い、必要に応じて事業部門のアプリケーションの改善、開発を通して事業の成長を支えるというものになっております。

簡単にいうと、主な活動としては事業部を横断したSRE活動などを行っています。詳細に関してもし興味があれば、過去に登壇した資料があるので、こちらのスライドをご覧ください。

もう少しチームの内容を深掘りしていくと、PFGは14名いまして、その中でさらにチームが細分化されており、3つのチームに分かれております。その中でも私が入っているのは「pfg-ec-team」と呼ばれているチームで、カラーミーショップやGoopeといったサービスを主に見ているチームになっております。これらのサービスインの時期は2005年からや2009年からなので、17年ほどのサービスとなっております。

Cloud Nativeなチームと生産性の定義

本題に入る前に、まずは「Cloud Nativeなチーム」と「生産性」の定義をしたいと思います。
Cloud Nativeとは、CNCFが定義しているCloud Nativeについての文章があるので、こちらから抜粋しております。その中でも、チームビルディングに役立ちそうなものに関して赤字を引いております。
特に、「回復性、管理力、および可観測性のある疎結合システムを実現します」という部分に私は目を付けました。あとは「堅牢な自動化」だったり、「エンジニアのインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができる」といったところに、何かしらのチームに対してできるのではないかと考えています。
これらの内容をそれぞれまとめますと、以下のようになっていくと思っております。
先ほど述べられていた回復性、管理力、可観測性は、チームにおいてこんな感じで生かせると思っております。
回復性から見ていくと、障害時や不測の事態でチームの体制が一時的に崩れたとしても、やるべきタスクをこなせている状態、管理力については、現状のチームの状態を管理できている、例えばチームが抱えている不安要素などを把握できている状態が、管理力のあるチームだと思っております。あとは分かりやすいところでいうと、可観測性の部分になりますが、パフォーマンス、のちほど定義される生産性を可視化できている状態が、可観測性のあるチームだと思っております。

疎結合と弾力性についてですが、疎結合なチームとは、メンバー全員が主体性を持ってタスクをこなせている状態、弾力性はメンバーが増えても短い時間でパフォーマンスが出せる、メンバーが仮に減ってしまったとしても、タスクの引き継ぎや割り振りなどの変更が容易である、こういったチームを「Cloud Nativeなチーム」と定義しております。

なので、Cloud Nativeと呼ばれるものは、モダンなソフトウェアを使って構築されたサービスでないように、「Cloud Nativeなチーム」も同じくモダンなツールを使っているチームではない、と私は考えております。

続きまして、今回の発表での「生産性」の定義をしていきます。
生産性という単語の意味としては、「費やした資源に対し、どれくらいの成果が得られたのか」という指標になります。SREチームということで、サービスに対するシステムの開発なども行うので、今回指標とした生産性は、デプロイの頻度、例えば特定リポジトリでのデプロイフローの実行回数を計測しました。あともう1つは、チームが割り振られたタスクがあって、そのうち実際に完了させることができたタスク数、それぞれを生産性の指標として挙げております。

我々のチームが抱えていた課題

続きまして、我々のチームが抱えていた課題の話をしていきます。
我々のチームが抱えていた課題としては、担当しているサービスが冒頭でも述べたようにサービス開始して約17年と長く続いているサービスとなっております。そういった中でSREとしてサービスの運用を行っていましたが、ドキュメントや構成図がないなど、暗黙知に頼り切った運用が前提となってしまっておりました。
そんな中で、プロローグにもあったように、2021年11月にチームの体制変更があって、ガラッと変わってしまったというのがありました。体制変更後には、生産性の部分はだいぶ大きく下がってしまった状態となってしまいました。

体制変更を簡単に図にするとこんな感じです。上が体制変更前、下が体制変更後となります。サービスに携わった期間が長いメンバーが3名、短かったメンバーが3名でやっていたのですが、体制変更後は長かったメンバーが1名に減ってしまって、歴の浅いメンバーが4名というチームになってしまいました。

生産性の低下を招いた原因を考察しました。
暗黙知による運用・開発がメンバー入れ替えによって通用しなくなったのが大きな原因と思っております。例えば「何かをするのに実は○○が依存している」というのを知っているメンバーがいなくなってしまったので、必然的に作業するのに対してもすぐに終わらせることができない、といったようなイメージです。サービスのデプロイ1つとっても、mainブランチへマージしたあと、何をすればいいのかということが文書化されていないので、記憶に頼っていたものが一切できなくなってしまい、実は何もできていなかったということが起きていました。

あとは、必要な技術スタックに関して習熟しているメンバーがいなくなったというのもあります。
左の図にあるのが、我々の勤務で見ている技術スタックの一部になりますが、これだけの数を使っております。それぞれ簡単には使えないものが多く、必要な知識が幅広く、メンバー間に知識格差が生まれてしまったというのもあります。
例えば、Kubernetesクラスタのアップグレードや、MySQLの設定値の変更について、タスクごとの属人化がより進んでしまい、仮に誰かが休むとその分がタスクの遅れに直結してしまっていました。

課題に対して実際に行ったアクション

ここからは、こういった課題に対して、具体的に実際に行ったアクションについてお話ししていきます。
大きく2つに分けてお話しします。

あらゆるチームルールの言語化と文化作り

1つは、あらゆるチームルールの言語化と文化作りを行いました。
あらゆるチームルールの言語化と文化作りに関してお話しします。
チーム作りにおいて割と重要視したのは、タスクをこなすだけでなく、良かった動きは再現性を高めるために、行動の言語化を徹底しました。言語化するメリットは以下のように挙げていて、物事を整理して考える力が身につき、自分の思考を客観視することができる、あとは観察力、思考力、要約力といった力を意識するきっかけにもなります。あとは、言語化しておくことによって、例えば新メンバーが参画した時には、我々のチームがどう考えてどういう風に行動しているかの共有を行いやすくなりました。

ちなみに、この言語化はIaCにおける宣言文と命令文の考えからヒントを得ております。
例えば、決めたルールは宣言文として言語化することで、チームでタスクをこなす上でありたい姿の共有を行うことができました。このあと実際に言語化した内容を紹介しますが、それらの内容は全メンバーがある程度同じ品質で再現可能な状態に持っていくことができました。

具体的に言語化したものは次のようになります。
チームの発足時に考えたチームテーマというものがあり、それを言語化していきました。テーマは「ハイスケーラブルなチーム」を目指しました。狙いとしては、弾力性のある、スケーラビリティのあるチームを目指すものになっております。特に、頻繁にメンバーの入れ替えが発生するということは分かっていたので、入れ替わり時にスムーズにバリューを出せるチーム作りが必須だと思い、ドキュメントの作成、環境構築などの自動化、複雑な手順はゼロベースで単純化を実施する、などを行いました。

ほかにも、タスクの重要度や優先度の決め方についても言語化しました。
例えば、仕事をする上で自分たちが大事にしている考えを全員で共有した上で決定、新しいタスクの発生時にはスライドの右下にある「家訓 – タスクの優先度」を決めて、こういったものをルールをもとに作業のアサインなどを実施していました。もちろん例外はあります。
あと、大きめのタスクには担当者を明示的にアサインしております。SLI/SLOの策定・運用や、マルチクラウド化といわれるものを現在我々は行っていますが、そういった年単位、半年単位で行われるタスクについては、スクラムメンバーひとりに責任を持つために、責任者をアサインしています。

あとはドキュメントの作成の定着といって、コードレビュー時のドキュメント更新の有無や、古くなったドキュメントの継続的見直しなどを定期イベントとして開催して、書くのが当たり前のチームへ向かいました。
ほかにも、インセプションデッキの継続的なアップデート機会を提起しました。実態に即しているかを四半期に1回程度見直すことで、ある程度、自分たちがなりたい姿ややるべきことを見直すタイミングを作りました。

こういったチームテーマやチームルールを行う上でのTipsとなりますが、こういう考えで今後はこんなチームになっていきたいといった考えを言語化してメンバーに伝えることが大事だと思っています。策定する際は、「こう思っているんだけどどうする？」のように、決定事項として共有するのではないことを心掛けたりしました。

言語化してよかったこととしては、新しくメンバーが入ってきた際に、言語化されている状況から文化や風土などを読み取れることができるようになりました。あとは、ルール自体は結構頻繁に作成しては破棄をしたりしていたので、ルールを浸透させやすい文化ができあがったと思っています。

スクラムイベントの見直し

もう1つはスクラムイベントの見直しです。
前述のとおり、技術スタックが多く、それらに習熟しているメンバーがいなくなりました。
例えば、体制変更前に30分でできていた作業、TerraformでMySQLのパラメータを変えるとか、アラートが出た時に即座に対応できるようなものも、1日掛かってしまうことが散見されました。
そういった時に考えられるのは、弾力性の面でいうと、メンバーが減ってしまった時にタスクの引き継ぎや割り振り変更が容易である、とはいえないチームになってしまっておりました。

なので、目指したい姿とのギャップを埋める方法を模索しました。
チーム事情より知識格差が大きいという課題もありました。知識格差を埋めるためには、スクラムイベントやチームのイベントとして取り組むべきだと判断しました。

スクラムイベントの見直しの内容としては大きく2つあって、メンバー間の会話する機会を増やすのが大事だと思って取り組みました。進捗報告で止まってしまっていたデイリースクラムでディスカッションを促すようなタイムスケジュールへ変える、あとは雑談時間を意図的に入れるなどをしました。

あとはモブプログラミング用の時間を毎日入れて計画を行いました。デイリースクラムの時間で収まらなかったディスカッションをやる場として、事前に予約してカレンダーに入れたりもしました。
この内容に関しては、プログラミングだけでなく、プルリクエストのレビューだったり、あとはトラブルシュートなども実施しました。

ほかにも小さなものとしては、タスク消化数などの計測を行いました。あとは勉強会やLT会の開催です。特定技術が得意なメンバーに依頼して、会を開催するなどして知識格差を埋める取り組みなどを行いました。
それぞれの得意領域をメンバー間で認知することで、その分野における主体性を持った取り組みが行えるような試みを行いました。

結果

実際にこれらの課題に対して行ったアクションで、どのくらい結果が出たのかについてお話しします。

縦軸がタスク数と本番環境へのデプロイ数のグラフになります。青線がこなしたタスク数で、緑線がデプロイ回数です。一応どちらも右肩上がりにはなっているように見えます。タスクについては1.5倍をこなせるようになった、マージ数に関しては4倍近い数字を出すこともできました。なので、効果はあったと考えております。

ただ、メンバー間で数値にばらつきがあるのが現実です。また、こなせているタスクの数に関しても、実はまだまだ自分たちでやれるのではないかという思いがあるので、この結果について満足はしていないという実態があります。なので、グラフ上では伸びていますがまだまだ道半ばという感覚です。今後も改善を続けていく必要があります。

では、我々は「Cloud Nativeなチーム」になれたのか、という話をしていきます。
回復性については、コミュニケーションを増やすことで例えば障害時でも期限のあるタスクをこなすことができました。ただ、属人化はもちろん排除し切れておらず、特定メンバーがお休みした際にはタスクが進まないなどといったものは変わらず発生しています。
管理力については、インセプションデッキを定期的に見直すことで、現状のチームが抱えている不安などを把握できている、そういったチームにはなったと思っております。

可観測性の面に関しては、可視化はできました。ただ、可視化できただけで、具体的にそれをもとにしたボトルネックの特定や改善活動へ活かすといった、データドリブンな行動までには至りませんでした。なので、ここについてはまだまだ伸びしろがあると思っています。
疎結合に関しては、メンバーの得意領域において主体性を持って取り組めるようになったというものがあります。これは、モブプログラミングや勉強会の開催で培われたものと思っております。
弾力性については、ドキュメントの整備やルールの言語化で、新参画メンバーがバリューを出すまでの時間が短くなったと思っております。受け入れ体制が整ってスケーラビリティの向上を実感しております。

まとめ

最後にまとめとなります。
Cloud Nativeな考えというのは、チーム作りにも活かすことができたと思っております。
ただ、実績が出るまでには時間がかかるので、「近道はない。やるしかないんだ。」ということを常に念頭に置く必要があると感じました。
今後やりたいこととしては、可視化の部分に関してFour Keysの指標のうち1つしかできていないので、可観測性をより上げて取り組むべきと思っております。

以上で発表を終わります。