業務改善PJTで学んだ「変革するまで、責任を持つ」という姿勢
こんにちは。
株式会社リンクアンドモチベーション新卒3年目の柳です。
この記事では、私が兼務先である モチベーションクラウドエンゲージメントの運用を代行するチーム （運用代行チーム）で関わった
業務改善ツールの改修プロジェクトについて、背景と学びをまとめます。
もともとは社内イベントで発表した内容ですが、
業務改善PJTにどう向き合うかという観点で、社内外問わず参考になる部分があると感じ、Qiitaに書き起こしました。
運用代行チームと業務改善PJTの背景
運用代行チームでは、
モチベーションクラウドエンゲージメントのサーベイ実施にあたり、
- 回答者
- 所属組織・属性情報
を一括登録するためのファイル作成など、
サーベイ実施前の運用準備を顧客に代わって行うサービスを提供しています。
しかし、
- 利用顧客数の増加
- 顧客規模の拡大
により、
手作業中心の運用では限界が見え始めていました。
そこで立ち上がったのが、
手作業をツールで代替する業務改善プロジェクトです。
ツール導入後に見えてきた課題
本プロジェクトでは、短期間で業務改善ツールを導入しました。
しかし運用を始めてみると、
要件定義の漏れにより実務で使えない状態であることが判明します。
私はその後、
ツールの改修担当としてプロジェクトに参加しました。
「改修者」としての立ち位置の限界
当初の私は、
「エンジニアでなければできないことだけ対応すればよい」
というスタンスで動いていました。
- 不具合の原因調査・改修は行う
- 改修するかどうか、優先順位の判断は運用代行チームに委ねる
- 工数が大きいものは「ツール外対応」でお願いする
一見、分業としては正しそうですが、
このやり方には問題がありました。
不具合が減らない構造的な問題
運用代行チーム側の前提
- ツール改修を継続的に回す仕組みがない
- その仕組みを作った経験のある人もいない
起きていた悪循環
- 不具合・改善要望を片っ端から対応
- ユーザー対応に追われ、改修作業に集中できない
結果として、
「改修しているのに、ツールが良くなっていかない」
という状態に陥っていました。
「仕組みを作らない限り終わらない」と気づく
この状況を俯瞰して、
自分が仕組みを整えない限り、改修は終わらない
と感じるようになりました。
また、
- 運用代行チーム・開発部門双方から役割拡張への期待をもらったこと
- プロジェクト全体を見る立場になったこと
をきっかけに、
自分の役割を見直すことにしました。
役割の再定義：「生産性向上の責任者」
私は自分の役割を、
「運用代行チームの生産性向上の責任者」
と定義し直しました。
単に改修チケットを消化するのではなく、
元々現場が抱えている問題に立ち返り、
ツールによって手作業工数を削減し、
より多くの顧客に運用代行サービスを安心して提供できる状態を実現すること
までを、自分の責任範囲として捉えるようになりました。
具体的にやったこと
- 不具合・改善要望を集約する仕組み作り
- 改修優先順位の判断基準を明文化
- 改修が難しい場合の運用代替案の検討・提案
「改修する／しない」ではなく、
運用代行チーム全体として最適かどうかを考えるようになりました。
改修の優先順位判断に使用していた基準表（参考）
得られた成果
その結果、
インパクトの大きい改修に集中できる状態を作ることができました。
今Qの改修では、
- 1案件あたり 約4.75時間の工数削減
- 年間換算で 約15案件分の稼働時間に相当
する見込みです。
また、不具合・改善要望数も、
外的要因を除けば 全体として収束傾向にあります。
不具合・改善要望数の推移
学び：「変革するまで、責任を持つ」
このプロジェクトで得た最大の学びは、
「変革するまで、責任を持つ」こと
です。
- 自分の作業を終わらせること
- 依頼された改修を完了させること
ではなく、
現場の課題が解消された状態になるまで関わり続けること
が、本当の意味での責任だと理解しました。
自社内プロダクトも「育て続ける」もの
運用代行チームの業務やデータは、今後も変化し続けます。
それに伴い、ツールに求められる役割も変わります。
この半年間で強く感じたのは、
自社内プロダクトも、一度作って終わりではない
ということです。
だからこそ、
- インパクトの大きい改修をやり切ること
- 持続的・安定的に保守・運用できる仕組みを作ること
この2点を、アウトカムにこだわって進めていきたいと考えています。
おわりに
この記事が、
- 自分の役割をどこまで担うべきか
- 変革まで責任を持てているか
を見直すきっかけになれば嬉しいです。
最後まで読んでいただき、ありがとうございました。