エンジニア運用工数40%削減！Bill One における運用改善のとりくみ

Bill One Engineering Unitの田上です。運用改善と題したプロジェクトによって、エンジニアの運用工数を半年で40%削減することに成功したので、今回はその取り組みをご紹介します。

背景

Bill One のエンジニアリング組織では、フルサイクルエンジアリングで開発と運用を行っており、開発者自身が運用対応（本番環境で発生したエラーの調査・対応、ユーザからの依頼・問い合わせの対応など）を行っています。
エンジニアが自身の開発したプロダクトへのフィードバックを迅速かつダイレクトに受け取れる非常に良い方式ではあるのですが、その対応工数があまりにも多くなりすぎて開発工数が逼迫するようになっていました。
その状況をどうにかするため半年の期限付き特命チームとして運用改善チームを立ち上げることにしました。

立ち上げ

組織内のフラストレーションの高まりを背景に、2名のエンジニアが新たなチームの立ち上げを決意しました。そこで課題となったのは人員の確保とチームの構成でした。
具体的な個々の施策は後述しますが、運用負荷状況を根っこから改善するためには組織横断的な取り組みが欠かせません。
そのためにはアイディアの立案から対外折衝・開発・リリースまで自立して動けるレベルの人員が必要になりますが、そういった人員は欲しいといったからもらえるものではありません。
そこでまず、直近のPBI（プロダクトバックログアイテムの略、開発予定機能）と運用工数削減（以下、運用改善）をプロダクトマネジャー（以下、PdM）とともに明確に優先順位付けをし合意形成を行いました。
このときのポイントとして「どれも大事」になってしまうと意味がないので優先順に確実に差をつけるようにしています。
次にこの優先順位をPdMからエンジニア組織に明示し、組織として明確に定めた優先順位であることを明確化しました。
これにより、組織メンバーの不安を払拭し、実際の改善活動でも協力を取り付けやすい土壌を作りました。

実際に、PdMとともに整理しエンジニアリング組織に共有した優先順位付け図（PBI 名だけ抽象化）

また上述のように運用改善でインパクトを出すためには組織横断的な取り組みが欠かせません。エンジニアの人員確保と並列して、エンジニア外のチームメンバーの選定と確保を行いました。
結果チームの構成として、

エンジニア：3名
PdM：1名
カスタマーサクセス：1名（以下、CS）
テクニカルサポート：1名（以下、TS）
CS/TS の部門長：1名

となりました。（エンジニア以外はフルコミットではなくパートタイム）
組織横断的な取り組みでは部署や役割間の利害調整ができる必要があるので、この際の CS/TS の人選では各部署で裁量のある人物に入ってもらうようにしました。また、重要な案件は CS/TS の部門長にも参画してもらう体制をつくりました。
これ以上ない豪華なメンバー構成ですが、上記の優先順位整理と併せて話を進めたことでステークホルダー間の課題感が一致し、選定や協力の取り付けにおいて何ひとつ滞ることなくスムーズにこの構成に行き着きました。

意思決定

運用改善チームで取り組む課題には次のような特徴があると事前に考えました。

「なにかひとつの根本原因を解決したらすべて解消」みたいな一発逆転はできない。多角的な視点から多数の手を打つ必要がある。
組織横断的な取り組みが必要でステークホルダーが多くなりやすい。また、課題が複雑で解決策が容易にわかるものではない。そのため、具体的な施策について異なる立場・視点から意見が出ることとなり意思決定が遅延するリスクがある。

これらを踏まえ、意思決定の方針として次の点を定めました。

2 Way Door の意思決定を基本として、正解に悩む場合は元に戻しやすい粒度に調整して実際に試してみる
アイディアはチームの内外を問わず広く常に募集し、ROIを雑に見積もって期待値の高い順に実行していくことにより、施策の量と質を確保していく

これにより、意思決定の方向性と基準が明確になり、個々の施策検討・合意形成に必要以上に時間を取られることなく実行までのリードタイムを短くできると考えました。

具体的な施策の例

運用にまつわる業務フローの改善

一言に運用にまつわる業務フローといってもいろいろありますが、ここではユーザーからのサポート依頼を例に挙げさせてください。
ユーザーが解決できない問題や特例的な要望は、CS/TSに依頼されサービスとして対応すべきと判断されたものは基本的にCS/TSで対応されますが、CS/TSで対応できないものはエンジニアに依頼が流れてきてエンジニアが対応することになります。
この業務フローの中で担当する CS/TS によっては経験が浅いなどの原因で、CS/TS で対応できる作業をエンジニアに依頼しているものや作業に必要な情報が不足している依頼が散見されました。これでは不要な作業がエンジニア側に発生したり、情報確認のための冗長なコミュニケーションが発生してしまったり、ユーザー・CS/TS・エンジニアの3者全員のリードタイムと工数が増加してしまいます。
これに対し、細かい改善は多数あるのですが代表的なものを挙げると

CS/TS向け：部門内/ドキュメント確認をフロー上必ず通るようにする
CS/TS向け：ケース別エンジニアへの依頼要点/依頼時に必要な情報をナレッジ化して参照できるようにする
エンジニア向け：ドキュメントメンテナンスを依頼ごとにフロー上必ず通るようにする

などを行いました。

社内フローの改善イメージ
オレンジ：始点・終点
ブルー：変更点・追加点
グレー：削減できたフロー

結果として、エンジニアへの依頼件数はピーク時の半分以下まで減らすことに成功しました。これは Bill One の非常に高い成長率を考えると大きな成果だと言えると思います。

エラー対応担当割り振りの自動化

Bill One では本番環境でおきたエラーレベルのログに対して、都度内容の確認→問題がなければクローズという対応をしています。
既存の対応フローとしては

1. 運用1次対応当番チームがエラーを確認
2. ぱっとわかればそのまま対応
3. 判断が難しければエラー内容から担当チームを探し出し対応を依頼
4. 依頼された担当チームが対応

という手順になっていましたが

どの程度調べたら担当チームに依頼するのか？がエンジニアによってばらつきが大きい
経歴の浅いエンジニアではエラー内容から担当チームを探し出すのに工数がかかってしまう

という問題がありました。
そこで、エラー内容から担当チームを割り出し依頼を飛ばす処理を自動化しました。
これにより、運用1次対応当番チームの工数削減と認知負荷低減ができました。
また副次効果として、担当チームがエラー発生頻度を正確に把握することが可能になったのでエラー発生原因への恒久対応の優先度判断がより適切にできるようにもなりました。

良かったこと

ほとんどの意思決定がチーム内で完結できた

この手の活動は通常であれば、実務者に話を聞きに行き・ステークホルダーと会話を往復させ・意思決定者に伺いをたててやっとひとつ意思決定ができるものです。
ですが、今回のこの運用改善はほとんどの意思決定をチーム内で行え、各施策のリードタイムを非常に短くできました。
当然ものによりますが、優先度が高いと判断されたものであれば概ねアイディアだしから実施まで1〜2週間といったスパンで実現できていました。
これはチームの座組による効果で、実務者・開発者・意思決定者・立場の強いステークホルダーをチームに引き込めたことで実現できた状況でした。

問題認識がステークホルダーで一致していた

「エンジニアの開発の時間が取れていない」ということが問題であるという認識がエンジニアだけでなくステークホルダーで一致していたことは非常に恵まれていた点です。
チーム立ち上げにおいて、機能開発との明確な優先順位付けや人員確保がスムーズかつ優位に行えたのはみなが同じ問題認識を潜在的に持っていたからです。
また、CS/TS も普段の業務においてエンジニアの負担を気にかけてくださっていましたが、エンジニアの負担に忖度して改善の声を上げにくかった面がありました。今回の活動でエンジニア側から声を上げたことにより熱意を持って取り組めた結果としてユーザー・CS/TS・エンジニアの3者全員が負荷軽減を実現できました。

チーム・部署を跨いで多様な人から多様なアイディアをもらえた

上述の通り広くアイディアを募るようにしたのですが、実際にさまざまな方からアイディアをもらえました。
こういった活動では目線の多さが質の高さに直結するので非常にありがたかったです。
活動開始時点でアイディアを募る方針を明確にしたこともそうですが、活動内容や結果が外から見えることを意識して活動を続けたことや事あるごとにフィードバックを求めていたことがいい方向に働いたのかと思いますし、また相互協力が盛んな組織風土のおかげだと感じました。

意見調整が難しい施策も手軽に実行できた

活動開始時点では最大の壁になるかと思いましたがまったく困らなかったので拍子抜けしました。
世の常として、例えば社内フローを変更しようとするとこれまでの運用からの変更を嫌がる意見が上がったりするものですし変更内容によってはセクション間で負担が移動するので説得に時間や策が必要になるものです。
しかし、この運用改善では、筋の良い施策に対してはフィードバックはありましたが実行に対する反発はなく、新しい仕組みの運用にも非常に前向きな協力をいただけました。
これはCS/TS・エンジニア両面で一定のプレゼンスをもつメンバをチームに加えたことによる効果もある程度あるかとおもいますが、なによりも Bill One というプロダクトのために一致団結する組織風土が自分たちの利害ではなく全体での利害を優先する判断を常に生んでいたのだと思います。良い組織だと改めて実感する機会となりました。

結果

2023年12月から2024年5月までの6カ月間の活動でエンジニア1人あたりの運用工数を約4割削減することに成功しました。
もともと期限付きの特命チームとして発足し、掲げた目標の数字を達成したので5月末でこの運用改善チームとしては解散します。
一方、この活動を通して本来の目的であるエンジニア運用工数の削減だけでなくCS/TSの工数削減やユーザーの体験向上を行えました。また、本来の目的を達成できたゆとりで見えてきたものがあります。ここまでの実績と知見の積み重ねからより広いスコープにリーチして Bill One に関わる人々の体験を向上できるのではないかとチームとして考えるようになりました。
具体的には、