こんにちは クラウド経費開発チーム ・ クラウド債務支払開発チーム の 宮村（みやむー） @miyamura.koyo です。
私は現在ガーディアングループのグループリーダーとして、運用・改善活動に取り組んでいます。
ガーディアングループは一般的にいう保守・運用チームに近いです。 ただし、運用するだけでなく、DevOps を体現することを目指し、開発による改善や、開発内外とのコミュニケーションを重視して活動しています。
また、ガーディアングループではプロダクトの運用は開発だけで完結するものではないと捉えており、開発チームとのコミュニケーションはもちろん、 PdM / カスタマーサポート / カスタマーサクセス と連携した価値発揮を重視しています。 定期的な MTG や問い合わせベースの課題解決を主軸にして連携をおこなっています。
グループの紹介は以前チームメンバーが執筆した記事に記載がありますのでぜひご覧ください。
我々のプロダクトにおけるトイル
さて、運用しているとトイルに悩まされること、ありますよね。
※ この記事におけるトイルとは、プロダクションサービスを動作させることに関係する作業のうち、手作業で繰り返し行われ、なおかつ自動化することが可能であり、長期的な価値は低く、作業量がサービスの成長に比例するものを指します。
我々のプロダクトでも、大小様々なトイルが存在しています。
代表的なものが「銀行マスタ更新」「駅マスタ更新」作業です。
駅マスタ・銀行マスタ更新作業
私が関わっている2つのプロダクトでは全国の駅・バス情報が登録された駅マスタと、最新の銀行・銀行支店情報が登録された銀行マスタを用いてサービスを提供しています。
銀行マスタ・駅マスタの更新作業は、手順自体は簡単なものです。
しかし、様々な事情で週に1回のメンテナンス時間でしか反映できず、なおかつ更新作業は他プロダクトも巻き込む必要があるため負荷の高い定常作業となっていました。
加えて、マスタが古くなるのを避けるために月に1回程度のペースで更新する必要があり、ガーディアングループで毎月1営業日程度かけて更新していました。
これらの作業は時々改善されつつも5年以上続けられていた歴史のあるものでした。
駅マスタ・銀行マスタ更新自動化の難易度
このような明確なトイルであるにもかかわらず、なぜ5年以上も手動運用が続けられてきたのでしょうか。
これには自動化のための社内ツールが揃っていなかったことや、単純にチームの人手が足りなかったことなど、様々な理由があったのではないかと思います。
ただ、個人的には「自動化の要件」を決めるのが難しいということが理由として大きかったのではないかと思っています。
駅マスタ・銀行マスタの更新作業の自動化は少なからずユーザーに影響を与える意思決定が必要となります。
通常はユーザーに影響を与える開発に対しての要件を決めるのは PdM なのですが、自動化したいこれらの作業自体はエンジニアが行っており、PdM も詳細に把握しているわけではありませんでした。また、エンジニアにとってどうなると嬉しいのかはエンジニアが一番知っているという状況でした。
このような時に必要になるのは「ユーザー視点」と「エンジニア視点」の両方を持って PdM に対して「提案」ベースで要件定義をする能力です。
先述の通り、ガーディアングループでは PdM / カスタマーサポート / カスタマーサクセス とコミュニケーションをとってユーザー視点を獲得する機会に恵まれており、なおかつ技術のプロフェッショナルとして開発活動も行っていることでエンジニア視点も持っている状況でした。
数年前の人手が足りずなかった時代に比べてチームメンバーが成熟してきており、人手も増えてきたため、リーダーの私が率先して歴史の精算を行うべきであろうと判断し、チームの了承も得てこれらの自動化に踏み切りました。
駅マスタ・銀行マスタ更新の自動化
とはいえ、長年の運用の歴史を紐解きつつ、自動化を行うのは並大抵の作業ではありませんでした。
しかし、これらは先述した「ユーザー視点」と「エンジニア視点」を用いて、そしてエンジニアとして磨いた技術を用いて解決していきました。
例えば「自動化をいつどのタイミングで行うか」などのユーザーに影響を及ぼす要件においては、ガーディアングループで獲得した「ユーザー視点」を活かして PdM に対して提案して議論することで決定しました。
また、「エンジニア視点」を活かし、諸般の事情でテーブル移行作業が必要になった際には移行スクリプトを書いて実行したり、マスタの初期構築方法が変わることに伴い環境構築手順の修正が必要と気づいて修正したりするなど、実現に必要な追加の要件を正確に洗い出して技術的に解決していきました。
加えて、銀行マスタについては社内の共通マスタ基盤に乗り換えることができ、移行の際に文字コード差異を考慮したり、Ruby で gRPC クライアントを実装したりするなど、「エンジニア視点」を活かしたプロダクトのアーキテクチャの改善にも取り組みました。
ところどころチームメンバーに手伝ってもらいつつも、合間に実装を行い、 1〜2名の人員でそれぞれ2ヶ月程度の工数をかけて実現することができました。
そしてその実装の規模としては、各機能についておよそ15〜20件のプルリクエストが必要となり、かなりの量の作業が行われました。
幾多の困難を乗り越え、5年以上の歴史に終止符を打った瞬間は喜びもひとしおでした。
自動化した結果
これらの自動化は今年リリースを行い、現在数回の自動更新が行われていますが、事前の精緻な要件定義におかげで不具合なく稼働しています。
毎月それぞれ1営業日程度かけていた更新作業がなくなったことで、年に約12営業日の工数が浮いた計算になります。
今後長くプロダクトが続いていくことを考えても、長期的に見て大きな成果になったと思います。
また、これらの作業は手作業で創造的でない作業でモチベーションも上がりにくいものでした。
今後はこれらの時間をプロダクトの改善という創造的な時間に使うことができ、長期的な開発体験の向上、そしてより User Focus なプロダクト作りにつながっていくと自負しています。
トイルの撲滅に必要なもの
今回のトイルの撲滅に必要だったものはなんだったのかと振り返ってみると、それはエンジニア主導で要件を定義し、そして実現する能力だったのではないかと思います。
そのために必要なのが「ユーザー視点」と「エンジニア視点」です。
これらを獲得するためには、開発部内はもちろん、開発部外の様々なプロダクトの運用に携わる仲間と積極的に関わり、技術的に難易度の高い改善をこなし、DevOps を体現していくことが重要です。
ガーディアングループではこれまでも、そしてこれからもこの2つを大事にして、様々なトイルを撲滅し、長期的にユーザーに価値を届けていく所存です。
マネーフォワード福岡拠点では、エンジニアを募集しています！
福岡開発拠点のサイトもあるのでぜひみてください！
