これは オープンロジアドベントカレンダー2021 の21日目の記事です。
オープンロジは、物流フルフィルメントプラットフォームサービスを提供しています。
在庫管理、配送作業を行うサービスを提供しており、サービスをご利用されている荷主の方、オープンロジと一緒に運用をしている倉庫の方からお問い合わせをいただくことがあります。
標準サービスのお問い合わせであれば、カスタマーサポート、カスタマーサクセスで解決することができますが、少しイレギュラーな相談、新規機能に伴うお問い合わせに関してはエンジニアがサポートをすることがあります。
また、機能化する前の運用の検証であったり、大雪・大雨の災害、新型コロナに伴う配送の調整など、多くの場面でエンジニアのサポートを必要とする場合があります。
オープンロジでは、このようなエンジニアの対応を必要とするオペレーションを オペ と呼んでおり、今回はこのオペを改善するにあたって、使用した施策やフレームワークをまとめたいと思います。
改善前
改善前の2021年3月までは、倉庫管理システムの開発チーム（WMSチーム）が1週間交代の2名体制でオペ対応を行っており、当時は下記のような課題がありました。
- リードタイムの長い問い合わせが発生すると、1週間以内に終わらすことができず、開発とオペ対応を同時に進める期間が発生していた。
- オペ担当の期間が終わると、機能開発を進める必要があり、オペ対応の改善に着手しづらい状況だった
- 部署間でのルールが決まっておらず、問い合わせが来たらすぐに対応するという状況になっていたため、担当したエンジニアの稼働時間が長くなる時があった
上記の課題を解決するために2021年4月からプロダクトマネージャー1人エンジニア3人のチームで、オペレーション改善チーム（以降、オペ改善チーム）を作り、コミュニケーションの改善、開発によるコスト削減を行いました。
やったこと
オペに関する社内Wikiのトップを整理してガイドラインを用意
あまりメンテナンスがされていない状態だったため、社内Wikiのオペ改善チームのトップをガイドラインとして整理しました。
下記の項目をトップに記載することにより、欲しい情報にすぐにアクセスできるよう改善しています。
- 注意事項
- 気をつける時間帯
- 依頼者の運用
- オペ担当者の作業内容
- 短時間の定形作業担当者
- 長時間の定形作業担当者
- イレギュラー担当者
- 関連するSlackチャンネル
- 調査方法
- 開発要望
- サービスレベル目標
- スケジュールとスコープ
- インセプションデッキ
- ワーキングアグリーメント
- その他
改善チームとは言え、運用も行うチームであったたため、 オペ担当者の作業内容 に記載した3つの担当を、1週間交代でエンジニア3人で対応しつつ、改善を行っています。
オペ担当者の作業内容に呼びやすい名称を付ける
それぞれの担当に呼びやすい名称を用意し、チーム内での担当の呼称がぶれないようしました。
- 短時間の定形作業担当者 -> ショート
- 長時間の定形作業担当者 -> ロング
- イレギュラー担当者 -> イレギュラー
当初自分はインセプションデッキの 俺達のAチーム が好きだったので特攻野郎Aチームのキャラクター名をつけようとしたのですが、ネタに走りすぎたため、ショート、ロング、イレギュラーに落ち着きました
- その時の自分のアイディア
- ハンニバル: プロダクトマネージャー
- 司令塔なので。
- フェイスマン: 短時間の定形作業担当者
- 短時間の定形作業担当者は依頼者との一番やり取りが多く、face-to-faceになりがちなので。
- コング: 長時間の定形作業担当者
- メカの天才なので、プルリクを作ったり、細かい調整もできそう。
- クレイジーモンキー: イレギュラー担当者
- どんな飛行機でも操縦できるので、きっとイレギュラーなこともできそう。
- ハンニバル: プロダクトマネージャー
「今週はフェイスマンをやります！」とか言いたかった
参考
インセプションデッキを作成
自分たちのチームがやるべきこと、やるべきではないことを定義し、メンバー間の期待値を揃えるようにインセプションデッキを用意をしました。
チームに対してのインセプションデッキになりますので、プロダクトにフォーカスしているエレベーターピッチ、パッケージデザインに関してはかなり無理やりになってしまったため、正直作る必要はなかったと思います。
- 我われはなぜここにいるのか
エレベーターピッチを作るパッケージデザインを作る- やらないことリストを作る
- 「ご近所さん」を探せ
- 解決案を描く
- 夜も眠れなくなるような問題は何だろう
- 期間を見極める
- 何を諦めるのかをはっきりさせる（トレードオフスライダー）
- 何がどれだけ必要なのか（俺たちのAチーム）
個人的には、 やらないことリスト、 夜も眠れなくなるような問題は何だろう、 何を諦めるのかをはっきりさせる（トレードオフスライダー）、 期間を見極めるが重要だと感じています。
改善は3人で行いましたが、問い合わせ対応を行いつつ、同時に開発を行うことはリソースの観点からとても難しく、小さく改善を繰り返して開発の時間を確保できる体制を目指しました。
また、半年後、１年後チームがどうあるべきかを定義し、自分たちの理想に向かっていける状態にし、自分たちが正しい方向に進んでいるかを判断できるようにしました。
参考
ワーキングアグリーメントの定義
自分たちのチームのコミュニケーションコストを減らすために、ワーキングアグリーメントを用意しました。
一部抜粋ですが、下記のような内容を記載しています。
- 業務中
- 9:00〜18:30は誰かしらいるようにしよう
- 17:00以降はみんなで解決する
- コミュニケーション
- 困ったら、周りに助けを求めよう（10分ハマったら、困っている状態）
- 疑問や納得できないものは、Slackチャンネル で周知する
- 日中のチームミーティング中に優先度がタスク依頼が来たら、会話に割り込んですぐに連絡する
- 知識共有
- 頻度が多い場合には、Wikiに手順やエラー内容をまとめる
- ドキュメントをガンガン更新していこう
- ミーティング
- 朝会は平日10:00〜10:15
- 朝会で困っていることや疑問に思ったことを伝える
- タスクの進捗状況は、17:00を目処に共有しよう
- 朝会は平日10:00〜10:15
- 健康
- 健康には気をつける
- 辛かったら辛いと言う
- 開発
- 調査段階で情報をまとめる
- 各システムの開発チームが存在するため、無理して開発をしない
- チケット管理
- 作業時間を付けよう
- 不具合系の調査であれば、各システムの開発チームへ依頼
ワーキングアグリーメントを定義することにより、暗黙知が減ったことがよかったです。
ワーキングアグリーメントは、毎週行っている振り返り（レトロスペクティブ）で、チームメンバー内で合意した内容を記載するようにしていました。
参考
サービスレベル目標（SLO）の定義
社内のカスタマーサポートチームやカスタマーサクセスチーム向けにサービスレベル目標（SLO）を定義しました。
一部抜粋ではありますが、部署間での期待値をコントロールするために、下記のような項目を記載しています。
- サービス提供時間
- 09:00〜18:00
- 技術的オペの標準サービス提供時間とする
- 起票されたタスクチケット・質問チケットはオペ改善チームが当日中に確認する
- 18:00以降
- 起票されたタスクチケットはオペ改善チームが翌営業日中に確認する
- 48時間以内の完了が必要な場合
- Slackにてオペ改善チームにメンションをする
- 連絡がつかない場合は、エンジニア全員のグループにメンションをする
- 09:00〜18:00
- タスクチケット、質問チケットの期限設定のルール
- 期限が設定されている場合は、その期限内での完了を目指す
- 設定された期限内の対応が難しいと判断した場合は、オペ改善チームから依頼者へ相談の上、対応方針を判断する
- 期限が設定されていない場合は、1週間以内（当月中）に着手する
- 3日間Pendingのステータスに滞留しているチケットがある場合は、オペ改善チームから依頼者へ状況の確認をする
社内向けのSLOを定義したことにより、カスタマーサポートチーム、カスタマーサクセスチームに対して、調査や回答の期限を明確にしました。
またエンジニア側も健全な時間で対応ができるようになり、双方にメリットが生まれました。
周知に関しては、Slack上で各部署とやりとりをするチャンネルが決まっていたため、毎朝9:00に簡易的なSLOをリマインダーで通知しています。
参考
振り返り（レトロスペクティブ）
KPTを毎週行い、チームが自走できる体制にしました。
KPTは、Miroなどのツールは使わずに、それぞれの項目ごとにWikiに箇条書きにして運用を行いました。
注意点としては、個人ごとにKPTの項目は用意しませんでした。
個人ごとにKPTを用意すると、個人にフォーカスしてしまい、問題の解決も個人での解決になりがちなため、一つのKeep、Problem、Tryに対して、メンバーが記載していく形にしています。
また、Slackにチームの分報チャンネルを用意して悩みや思っていることを呟けるようにし、そのチャンネルの内容がKeepやProblemになるようにしました。
議論は振り返りで行うため、そのチャンネルのメッセージを拾う拾わないは自由なチャンネルとして定義しています。
最初は課題が多く、振り返りの時間も長くなりましたが、Tryを継続的に行っていたのでスプリントごとにミーティングの時間は減少していきました。
- Keep（よかったこと/QOLがあがったこと/ストレスがなかったこと）
- 事前に書き込み
- Problem（悪かったこと/QOLが下がったこと/ストレスがあったこと）
- 事前に書き込み
- Try
- みんなで話し合い、合意して進める
Problemに関しては、振り返り中に下記にカテゴライズするようにし、解決策をまとめるようにしています。
- オペ全体の問題
- 改善のための開発で起きた問題
- システムやアプリケーションで起きた問題
- コミュニケーションで起きた問題
- 知識が足りないことで起きた問題
- 時間がなーいみたいな問題
- その他の問題
朝会
メンバーの入社時期は違うため、ドメイン知識に差があり、得意不得意に差がある状態でした。
そのため、朝会では予実だけではなく、前日行ったオペ対応の知見共有を行い、メンバー間でのドメイン知識の差を埋めました。
朝会が長くなる場合は翌日に知見共有をすることにより、一度に多くの情報を入れないように考慮しています。
夕会
1人が遅くまで頑張る状態を避けるために、作業の分担を夕会で行いました。
コミュニケーションコストは増えますが、心理的安全性は高くなるので、オペ改善のような運用においては、夕会はおすすめのプラクティスだと思います。
作業時間の見える化
去年の@Telooさんの記事で、オープンロジでのRedashを使用した問い合わせの見える化を紹介しましたが、さらにブラッシュアップを行い、作業時間を計測するようにしました。
見える化を進めることにより、改善すべき課題を把握し、戦略を持って改善を進められるようになりました。
結果
上記のやったことをベースに、コミュニケーションの改善、開発を伴う改善を行うことができましたが、最後に下記の課題が残りました。
- 各システムの開発チームが担当した方が良い機能開発・不具合修正ばかりが残ってしまった
- オペ改善チームには機能開発・不具合修正に対してのアサインの権限がないため、各システムの開発チームに依頼が直接できない
- オペ改善チームが問い合わせの一次窓口を行っていたため、プロダクトマネジャーチームがどのような課題があるかをオペ改善チームからヒアリングする必要がある
- オープンロジでは、プロダクトマネージャーのチームが存在しています。
オペ改善チームでは、これ以上スピードを持って改善ができないと判断し、今年の2021年8月末でオペ改善チームを解散することになりました。
解散と言っても、やれるところまではやった上での解散だったため、良い解散だったと思います。
また、残った課題をクリアするために、下記の改善を行っています。
- お問い合わせの一次窓口をエンジニアではなく、プロダクトマネージャーチームに変更
- お問い合わせの一次窓口をプロダクトマネージャーにしたため、案件の優先度が調整でき、各システムの開発チーム内で改善ができるようになった
オペ改善チームを経験したことで得た知見
運用改善をがっつり行い、得た知見もあるため、せっかくなのでそちらも記載します。
この知見においては、オープンロジでもまだ適応できていないものも含んでいます。
開発と運用の両方をチームの場合、短いスパンで運用担当者を交代しない方が良い
本来であれば、各システムの開発チームが開発と運用を同時に行うのが一般的かと思います。
その場合、オペ対応のタスクを次のスパンに持ち越す場合もあるため、1週間交代だと開発期間が短かくなり、開発に集中できない可能性があります。
担当期間を1ヶ月のように長いスパンにすることができれば、タスクを持ち越ししたとしても、開発に集中出来る時間を確保することが出来ます。
また、オペ対応に関して言えば、ドメイン知識を得る機会にもなり、サービス理解にも繋がるため、可能であれば、全エンジニアが輪番制で対応できるのがベターです。
一次窓口は開発機能・不具合修正の優先度を決めることの出来るチーム（プロダクトマネージャーチームなど）が行ったほうが良い
機能開発・不具合修正の優先度を決めることが出来ないチームの場合、長期的に改善をすることはとても難しいです。
その場合は、タスクの優先度を決めることができるプロダクトマネージャーチームが問い合わせの一次窓口を行うようにした方が良いでしょう。
他にも、プロダクトマネージャーチームにオペ改善チームが所属するようにしても良いと思います。
運用バジェット（運用予算）を決める
SREのエラーバジェットを参考に運用バジェットを考えました。
運用バジェットを決めておくとチームの状況が健全かどうかを判断することができるようになります。
- 例: 月ごとのリソースの割合
- 新規開発: 50%
- 改善: 30%
- 運用: 20%
上記のようなリソースの割合を定義し、もし運用が20%以上になった場合、それは不健全な状態と言えるようになります。
その場合は、改善にリソースを割いて運用のコストを減らす努力をしましょう。
SREのエラーバジェットと同じように運用もゼロにすることは難しいため、一定の運用を許容することにより、健全なサービス運用ができるようになります。
まとめ
5ヶ月という短い期間でしたが、スピーディに問い合わせ対応やサービス運用を改善は出来たのではないかと思います。
サービスレベル目標（SLO）や運用バジェットなど、普段開発をしているだけではあまり意識しないところを深く考えられたのが良い経験でした。
また、毎週の振り返りで日々改善していたため、チームメンバー全員がモチベーションを下げること無く進められたこともとても良かったです。
この記事が自社でサービス運用している方のご参考になれば幸いです。
また、もしサービス運用で直接聞いてみたいことがあれば、オープンロジのカジュアル面談に是非応募してみてください！