こんにちは！freeeでアプリケーションエンジニアをしているおっそーです。
この記事は freee 基盤チームアドベントカレンダー の11日目になります。
昨日のuryyさんのPagerDutyについての記事はいかがでしたでしょうか？😊
わたしは外部サービス連携開発部のグロースエンジニアをやっており、1年半ほど運用負荷の改善に努めてきました。今回はその取り組みについてお話します。
また、外部サービス連携開発部は freee 内部ではコアエンジンチームと呼ばれているので以降コアエンジンチームと記載します。
コアエンジンチームとは
freee会計の一機能で銀行やクレジットカード、交通系IC、レジサービス、決済サービスなどのfreee外のサービスからユーザーのお金の動きについてのデータをfreee会計に連携して、ユーザーの仕訳業務を自動化・効率化する連携機能を開発しているチームです。
以前 freee Tech Night でも紹介された際の記事もぜひ覗いてみてください。
多種多様なサービスと連携しているコアエンジンチームの特徴として「運用負荷が大きい」ことが挙げられます。
グロースエンジニアとは
分析・企画・仕様策定・設計・実装・効果測定までひとりでやるエンジニアのことです。
現在のコアエンジンチームのグロースエンジニアのミッションは「コアエンジンの運用負荷を下げ、ユーザー価値のための開発に使える時間を増やすこと」です。
1年目の取り組み
コアエンジングロースチームの取り組みの全体の流れについて紹介していきます。
モニタリング対象の決定
まずは運用負荷を表す指標で定義する必要があります。 わたしたちのチームでは、以下の3つの数値を改善することにしました。
- 問い合わせ数
- 問い合わせ率（問い合わせ数／課金事業所数×100）
- リードタイム（問い合わせがあってから解決するまでの時間）
問い合わせ数や問い合わせ率は季節性があったり、リードタイムについては異常値があったりするので正確に実態を表現できているかは注意して見るようにしていました。
改善対象の分析
指標を決めたら次は分析です。以下のようにいくつかの切り口で課題を発見するためのクエリをたくさん書きました。
- 問い合わせ分類×問い合わせ数
- 連携先ごとのエラー発生数
- 連携先×エラーごとの問い合わせ数
- 連携先×エラーごとのリードタイム
- etc…
この分析の結果で特に気になる数字が出たものを課題とし、プロダクトマネージャーにも協力してもらいながら個別具体の事例集めを行います。
「この問い合わせ多いよね」「対応に時間がかかっているよね」といった感覚は大事にしながらも、しっかりファクトベース・データドリブンな進め方をしています。
企画
その課題に対して企画案と仕様をいくつか考え、なるべくコストが小さくリターンが大きく見込める施策を選定します。 また、画面の変更がある場合はデザイナーとも相談し、画面を一緒に考えていきます。
コアエンジンが連携しているのは2000以上の連携先。連携先個別の対応をすべき場合もあれば共通仕様として改善すべき場合もあり、その影響調査をいかに正確に時間をかけすぎずにやるかがポイントで、ここにも難しさと面白さがあります。
1つの施策を実施するのに、ここまでで6~8割は時間をかけていることがほとんどです。
設計・実装とリリース
施策案が決まればここからが設計・実装とリリースです。修正規模や内容によっては、QAと相談してエンジニアでケース作成や実施までしてしまうこともあります。 2週間程度で完了するものから3ヶ月かかるようなものまで、1年で多くの施策をリリースしました。
取り組みの具体例
あまり詳細には書けないのですが、1年目に実施した施策のうち、エンジニアならではの視点でできた企画を1つ紹介させてください。
コアエンジンでは取り込んだデータの正確性を担保するために複数回システムチェックを通しており、取り込んだデータに何かしら誤りがある可能性を検知した段階で内部的なエラーとして処理しています（誤取り込み可能性エラーと呼びます）。このエラーの発生数が多いことでユーザーもエンジニアも困っており、改善の企画を考えることになりました。
このエラーの発生要因をコードから探ってみたところ、ある閾値を超えると発生することが分かりました。 この閾値が厳しすぎるのでは？という仮説を立て、この閾値だったらどうなるかを過去のデータを使って検証したところ、ある値であれば本当に捕捉すべきエラーは逃さず、必要以上にエラーに倒してしまっていたものはエラーではなくなることが実証されたため、この閾値を変更する修正をリリースしました。
コードも読める、分析もできるエンジニアだからこそできた改善です。 この企画により大きくエラー発生数と問い合わせ数を減らすことができました。
1年目の成果
様々な施策を実施した結果、なんと課金事業所数は増加したにも関わらず、問い合わせ数は年間で12%ほど減りました。
また、繁忙期に限っては31%の問い合わせ数を減らすことができ、長期間お待たせすることなく問い合わせの対応が完了できるようになりました🎉
1年目の反省と改善
1年目でだいぶ改善はされたものの、まだまだです。今後も課金事業所数に比例して問い合わせが増える可能性を考えると、「ユーザー価値のための開発に使える時間を増やす」にはもう少し運用負荷を軽減していく必要がありそうです。
そのため次年度にどうしたらよりインパクトの大きい施策を速くリリースしていけるかを考えました。
そこでチーム全員で考えたのが以下の3つです。
①追うべき指標をより実態に即したものにする
問い合わせ数もリードタイムも運用負荷の実態をそのまま表すものではなく、実際の運用負荷がどれだけ改善されたのか、またどれだけ改善すれば良いのかの議論がしづらくなっていました。
例えば、運用負荷と問い合わせ率はあまり関係ありませんよね。
また、「リードタイム改善のための施策もバランス良くやらないと」のような不要な議論を生んでしまうことにも繋がりました。
②リアルタイムでモニタリングできる目標値にする
今年設定した目標値は遅効指標かつ外部要因による影響を受けやすく、実際に直面した課題と問題を以下に挙げてみました。
| 目標値の課題 | 発生する問題 |
|---|---|
| 施策をリリースしてから結果が現れるまで時間がかかること | 予定通りにいかない場合のリカバリが遅れる |
| 改善してもユーザー全員に意図したアクションを取ってもらえる訳ではない | 見込みインパクトから下回る |
| 想定外の新しい問題が発生し、問い合わせが急増する | 急増分のリカバリのために追加の計画が必要になる |
結果、頑張っても思ったようには改善されないこともあり、モチベーションを保つのが難しい場面もありました…。 このため、施策の完了時点で成果としてカウントできる指標も同時に目標値に設定することも必要だと考えました。
③抜本的な改善に取り組む
運用負荷を減らして浮いた工数をユーザーへ価値を提供できる開発に当てられるようにするのが一番の目的ですが、グロースチームとしてはユーザーに問い合わせを強いている状況を改善したいという思いも強く持ってやってきました。
1年目に実施した施策の多くは、エラー発生時に原因と対処方法をわかりやすく伝えるものがメインでした。しかし、画面がわかりやすく変わろうとも、ユーザーはエラー内容を理解し対応する必要があります。それ自体がユーザーにとっては負荷のある状況です。施策のコストや現状のケイパビリティに捉われずに、もっとエラー発生による負荷がある状況を改善すべきだと考えました。
2年目の取り組みで工夫したこと
1年目の反省点を受けて、2年目は以下の通り指標、目標値、施策の見直しを行いました。
①運用負荷を表す指標の見直し
問い合わせ数×リードタイム（問い合わせがあってから解決するまでの時間）の平均とし、これを「合計負荷」と呼ぶことにしました。 これにより、運用負荷の実態に近い数字をモニタリングすることができるようになりました。
②目標値の見直し
もちろん合計負荷の指標の目標値を達成することが主目的ですが、先行指標の目標値として「リリースした施策の問い合わせ削減見込み数」も置くことにしました。
このように先行指標を目標に置くやり方はAmazonでもやっているそうで、Amazonでは売上や株価等の完全にコントロールすることが難しい指標をアウトプット指標、品揃えや価格等のコントロール可能な指標をインプット指標と呼び分けて、後者をトラッキングしているそうです。
これにより、目標に対していつまでに何をすれば良いかや、イレギュラーな事態が発生してもリカバリの計画も立てやすくなりました。
③施策の見直し
コアエンジンでは多種多様な問題が発生するため、全体的にかなり慎重にエラーハンドリングをしています。
しかし、
- エラーとなった実データを詳しく見ていくと、あるエラーは連携先によってはほぼ確実に偽陽性になるものだった
- エラーの発生数や発生率を見ていくと、ほぼ発生しないエラーのチェックに時間をかけて全体の処理の時間が伸びているいるだけになっていた
など、本来ユーザーのためにやっていたことが、逆にユーザーの負担になってしまっていることが分かってきました。
そのため、これらのエラーは発生しないようにしたりチェックポイントを減らしたりと改善を実施しました。
1年目であればエラーの伝え方改善やユーザー判断・操作を挟む改善を選択していた場面でしたが、このような思い切ったアクションも自分たちでデータ分析をして問題ないと言えたからこそ出来たことだと思います。
エンジニア側では引き続き事象の発生をエラーとは違う形で検知できるようにし、また発生割合が急増するなどの異常も通知されるようにもしていて、同様の品質を引き続き担保できるように努めています。
2年目の結果は・・・？
残念ながら、期半ばなので合計負荷がどこに着地するかは分かりません。 しかし、この半年の先行指標の目標は達成見込みでは大きく達成見込みです。 またどこかで成果をお話しできる場所があれば共有したいと思います！
さいごに
出せない情報が多いため定性的な表現が多くなってしまったので、現場では全部実際の数字で細かく議論していることは改めて言わせてください！！！笑
運用負荷が大きくなってしまう特性の強い領域で分析から企画・開発・効果測定まで一気通貫でやるのはとても大変ですが、だからこそ得られる経験や学びは非常に大きいです。チームも自走力が高いメンバーが集まっており、お互いの意見や考えをぶつけたり、学びをシェアし合ったりして最速で最大のインパクトを生み出せるように常に成長し続けています。 この記事を通じて、コアエンジンチームのグロースエンジニアの仕事の難しさ、面白さを伝えることができれば幸いです。 そんなコアエンジンのグロースチームに興味を持っていただけたらカジュアル面談まで是非お越しください！
まだまだやらないといけないことだらけですが、これからも本当にユーザーさんの価値になることは何かを考えて連携機能を改善していきます💪
明日のアドベントカレンダーもお楽しみに！
