この記事はOPENLOGI Advent Calendar 2024の8日目の記事です。
はじめに
昨年のアドベントカレンダーではCREチームへのお問い合わせをscikit-learnでラベリングしてみたという記事を書きました。
これは、CREチームではシステムに関するお問い合わせ対応や運用作業をしているのですが理想的には「できるだけ運用作業やお問い合わせ対応をしなくてもよい」という状態を目指しており、現状分析や運用工数削減に向けて運用作業やお問い合わせに関するデータをラベル付けしてみたという話になります。
オープンロジは実体のあるリアルな荷物を取り扱う物流プロダクトですので、システムの運用が画面内で完結するわけではなく「実体のあるリアルな荷物の動きや状態」と「システム上での処理やデータ」の整合性がとれているかどうかを気にかける必要があります。
そういった理由で、一般的な画面内で完結するSaaSと比べたときにオープンロジではシステムを利用している現場（主に倉庫）のリアルなオペレーションにエンジニアが入り込んでサポートする必要があるためエンジニアの運用作業の負荷は高くエンジニアの運用工数削減は重要なテーマになっています。
しかしあれから1年経った今振り返ると正直昨年の記事でのラベル付けはあまり現状分析や運用工数削減にはつながらなかったなと感じています。
昨年の記事はデータ分析がメインというよりは機械学習を試してみたという趣旨の記事でしたが結果的にデータを活用できなかった点については反省が残りました。
そこで本記事では、昨年の記事のよくなかった点について振り返りと今後に向けてどうしていくかについて書いていきたいと思います。
ちなみに私はCREチームから別のチームに異動したのですが異動先のチームでも運用作業は行っており、運用工数削減は現在進行形で向き合っている課題となっています。
昨年の記事は何がよくなったのか
昨年の記事ではデータのラベル付けに関して以下のように記載していました。
お問い合わせの大まかな傾向を把握することを目的としており、各行について4種類のラベルをつけています。
仕様調査...何らかのシステムにおける操作や処理においてどのような挙動や結果になるかを知りたい
原因調査...何らかの実際に発生した想定外のシステム上の挙動や結果に対してなぜそうなったかを知りたい
運用相談...ユーザが実現したいことがシステム上で実現可能かどうかを知りたい
運用作業依頼...事業側で対応できない設定作業やデータ抽出・更新作業などをエンジニアに依頼したい
お問い合わせの傾向を把握した上でどう活用するについては課題感があり、また上記のラベルが本当に適切かどうかは再考の余地は多分にありますが、まずは始めてみるということで一旦このようにしています。
上記を振り返ると、現状分析や運用工数削減したいというモチベーション自体は現在も変わらず間違ってはいないと思うのですが、一言で言うとそのために実施した「お問い合わせの大まかな傾向を把握する」という取り組みのゴールまでの道筋がかなり不明瞭で現状分析や運用工数削減をするために「どのようなデータを集めるか」「集めたデータをどう利用するか」と言う観点での仮説設定が足りていなかった点が良くなかったと思っています。
その結果として、「お問い合わせの大まかな傾向を把握する」ことが「現状分析や運用工数削減に取り組むこと」に結び付けることができず、とりあえずラベル付けはしてみたものその後に活用できなかったのが反省になります。
道筋を改めて整理する
モチベーションが現状分析と運用工数削減であることは現在も変わらないのですが、現状分析と運用工数削減とは何かをもう少し噛み砕くと以下のように言語化できると考えました。
- 「過去・現在」の運用工数を「実態把握」したい <= そのために「分析」が必要
- 「未来」の運用工数を「削減」したい <= そのために「意思決定」が必要
これらについて「どのようなデータを集めるか」「どう集めたデータを利用するか」について整理してみます。
余談ですがこの過去・現状の分析と未来の意思決定に向けての活動の考え方は、会計とファイナンスの考え方に近いなと思ったりもしました。
会計とファイナンスの違い
どのようなデータを集めるか
当然ですがデータは過去の実績から集めることになります。今回は過去の実績から運用工数の実態を把握したいわけですが、実態が把握できている状態とはどのような状態なのかを考えたときに、以下が分かればよいのではないかと考えました。
- 誰が、何に、どのくらいの工数を運用作業に使っているか？
- なぜその運用作業が発生したのか？作業をなくすことはできないか？
- なぜその運用作業はエンジニアが行うのか？エンジニアでなくても作業できないか？
昨年記事では「傾向を知りたい」とあいまいな表現をしていたことで特に下2つについてラベル付けの観点に含まれておらずその結果活用することができなかったと感じています。本当に知りたいのはあいまいな傾向ではなく具体的な実態なわけですが、それが分かるためにはどのようにラベル付けをすればよいのかを改めて考えていく必要があります。
集めたデータをどう利用するか
「データをどう利用するか」は「何のためにデータを集めるか」とほぼ同義かなと思います。そこで、何のためにデータを集めるかを考えたところ以下の3つになると考えました。
経営層やマネージャーに運用工数の実態を説明できるようにしたい
経営層やマネージャーの立場からするとエンジニアのリソースはより事業成長へ繋がることに使いたいと考えるはずです。そのための判断材料としてエンジニアがどのくらいの工数を運用作業に使っているのか？それは本当にエンジニアがやるべき作業なのか？といった観点で運用工数の実態を把握する必要があり、そのためにデータを利用します。
過去の運用工数実績や運用工数削減施策の効果を評価したい
何らかしらの運用工数削減に向けた施策を実施したときにその施策による効果を検証したいはずです。一方で運用工数の中には削減可能な工数と削減不可能な工数があります。例えばAPI連携を利用している場合は外部サービスの仕様変更による運用工数が発生することがありますがこれは自社の努力ではどうしても減らすことはできません。運用工数削減施策を評価するときにはそういった削減不可能な工数については除外して考える必要があり、そのためにデータを利用します。
運用工数削減に向けた施策の優先順位付けをしたい
運用工数削減の施策は当然費用対効果が高いものから取り組むべきはずです。費用対効果を知るためには施策を立てたうえで効果を定量的に見積りをして比較する必要があります。施策を立てるときには例えばより多く工数を使っている分類が分かればそこから取り組むべきと考えることができます。さらにその中で効果を見積り比較するためには過去にどのくらいの運用工数を使っていたかの実績を知る必要があります。このように施策を立てたり施策の費用対効果を比較して優先順位付けしたりするためには過去の実績から実態を知る必要があり、そのためにデータを利用します。
今後に向けてとまとめ
上記の整理を元に、どのようなデータを集めるか、データをどう利用するのかを掘り下げて考えていくことになりますがまだ途中であり、かつプロダクトのドメイン特有の事情をかなり含むので今回は割愛させていただきます。
今回1年前の振り返りをしてみて反省点は多かったもののアウトプットを通して思考が整理されてきた部分はあるかなと思ったので今後もこういった機会を利用してアウトプットを続けていきたいと感じました。