はじめに
こちらはバイセルテクノロジーズAdvent Calendar 2024の18日目の記事です。 前日の記事は前原さんのSASE製品のPoCをした話でした。 こんにちは！ バイセルテクノロジーズのテクノロジー戦略本部開発3部でプロジェクトマネージャーをしている本田です。
バイセルでは基幹システムGYROからCosmosへのリプレイスを進めており、 私が所属するGYROチームは、今年8月からCosmos CRMチームに合流して開発をしています。 そのチームでは現在、新システムの開発と既存システムの運用を並行して行っています。 本記事では、その中でも要所を押さえつつ、工数を抑えて既存システムを運用するために実施していることを振り返ります。
特に、システムリプレイスのプロジェクトを抱えていたり、並行プロジェクトの運用工数を削減したいプロジェクトマネージャーやリーダーの参考になるような内容を目指しています。
課題とその背景
課題: 安定稼働と運用工数削減の両立
新システム開発にできるだけリソースを割くため、既存システム運用は工数を抑えつつ、安定稼働を維持する必要があります。
一番最初に思いつくわかりやすい対策として、チームを既存運用メンバーと新規開発メンバーに分割して、それぞれが集中して作業を進める方法がありますが、それはやりたくありませんでした。 なぜなら、分断してしまうことがチーム合流の目的を損なってしまうためです。 チーム合流の目的はもちろん組織的な都合もありますが、最大の目的は既存システムを運用して蓄えたドメイン知識や事業課題を波及させてシナジーを生み出すことでした。 一部のメンバーのみ新規開発に参画しないことで、彼らの成長機会を限定してしまうとも判断しました。
そのため、合流に伴って「安定稼働と運用工数削減の両立」が既存システム運用の課題となりました。
課題解決のためのアプローチとその結果
まず、仮説を立てるためにチームのタスクを洗い出して分類し、プロダクトオーナーと相談しました。
| 定期・よくあるタスク | スポットタスク |
|---|---|
| ミーティング | ミーティング |
| データ修正 | データ修正 |
| コード改修 | コード改修 |
| 問い合わせ | 問い合わせ |
| 障害 | |
| システムメンテナンス |
問題点は3つあることがわかりました。
- 意思決定プロセスに全員が関わるため、時間がかかること
- MTGの時間が長いこと
- 定期的なタスクがいくつもあることがわかりました。
そこで、以下のようなアプローチを考えました。
- 意思決定に関わる人数を削減すること
- ミーティングの工数を削減すること
- 定期タスクを見直すこと
アプローチ (1): 意思決定に関わる人数を減らす
変更前
チームで意思決定を行う際、これまではチームで十分に意見を出し合った上で決定するというスタイルを取ってきました。 例えば、チームのルールを変更する時はドキュメントにまとめて全員でレビューしたり、障害の恒久対応・再発防止策を検討する時は全員のMTGを設定していました。 これは長期的な視点でチーム内の属人化を減らし、メンバーが自己組織的に動くことができるようにするという意味で、良い体制でした。 しかし、短期的な目線で見ると、意思決定に慎重で多くの人が関わるため、その分時間がかかっていました。
変更後
問い合わせと障害・システムメンテナンスにそれぞれ担当者を立て、プロジェクトマネージャーと担当者間の範囲で意思決定するように変更しました。 具体的なタスクに分解できた後や対応方針が決まった後に初めて、メンバーにタスクをアサインして進行してもらいます。 もちろん、意思決定担当でわからないことは他のメンバーに知見を求めます。
上記の意思決定体制の変更にあたって気をつけたのは、メンバーに目的をしっかり伝えることです。「運用工数を抑えるために物事を迅速に決定していく必要があること」をチームMTGや1on1で何度も共有しました。
ただ、障害の暫定対応だけは、全員で取り組んででも素早い完了を目指しています。 業務が止まる原因になる障害や問い合わせに対して素早く対処できていない状態は安定稼働と呼べません。 チームの半期目標として、検知から初動、暫定対応完了までのスピードを目標にしています。 暫定対応の完了後は、PMと担当者間で再発防止策の完了までの対応を検討・管理します。
結果 (1)
問い合わせの意思決定に関わる人数は9人から2人に、障害恒久対応は9人から2人に、システムメンテナンスは9人から4人に削減しました。 定量的な計測はできていませんが、メンバーのスイッチングコストは下げられています。 体制を変えてみた結果、そこまでデメリットは感じていません。 むしろ、問い合わせや障害を担当したメンバーが自身の役割を噛み砕いて理解し、行動し、その結果、活躍や成長が見える場面が変更前より増えました。
また、障害の発生件数は変更前に比べて変更後に9件減少しています。
| 変更前(4~7月) | 変更後(8~11月) |
|---|---|
| 19件 | 10件 |
こちらは既存システムへの新規開発を停止していることが要因として考えられます。
アプローチ (2): スクラムをやめ、必要最低限のミーティングだけ実施する
変更前
既存システム運用チームでスクラム開発を取り入れ、以下の方法で取り組んできました。
- スプリント期間は1週間
- デイリーでスプリントタスクの状況を共有する
- リファインメントでタスクの背景共有と分解および見積もりを全員で行う
- プランニングでタスク担当者をアサインし、タスクを分解する
- スプリントレビューで成果とベロシティを確かめる
- レトロスペクティブでスプリントを振り返り、次のスプリントで検証・試行することを決める
変更後
- 継続していること
- デイリー
- レトロスペクティブ
- スプリント
デイリーで状況の同期が行われないと、メンバーはチームが安定しているか、または危機的状況であるかを実感できません。他の人が何をしているのかわからないため、デイリーがないとチームとしての一体感がなくなることにつながると予想しました。 レトロスペクティブを継続している理由は、変化に対応するためです。メンバーで話し合い、節目では過去や状況を振り返り課題を出して改善していきたいという声が多く挙がりました。デイリーではPMから発信することが多いため、メンバーの意見を吸い上げる目的もあります。 スプリントは期間を区切るために設けています。見積もりやベロシティの計測は行っていません。
- やめたこと
- リファインメント
- プランニング
- スプリントレビュー
リファインメントにて背景共有、分解、見積もりを全員で行っていたのをやめ、タスクが発生したタイミングで少人数が意思決定する体制に変更しました。 プランニングもタスクが発生したタイミングで着手し、アサインはプロジェクトマネージャーが個別に相談する体制に変えました。
結果 (2)
チーム9人での定例ミーティングの工数合計を、週63時間から週16.5時間に削減しました。 変更後のMTG合計16.5時間の内訳は以下の通りです。
| デイリー | レトロスペクティブ | 障害管理 | システムメンテナンス管理 |
|---|---|---|---|
| 10時間 | 4時間 | 2時間 | 0.5時間 |
アプローチ (3): 定期タスクを見直す
変更前
既存システム運用タスクの1つに、ユーザーから依頼を受けてシステムのデータを修正することがあります。 例えば、イレギュラーな操作が原因で現実と乖離したデータが保存されてしまい、ユーザーが画面上で修正できないとき、開発チームに修正依頼が来ます。 その中には定期的なものや高頻度のものがあります。 以前からそのようなデータ修正は、システムの仕様を見直すことで発生しないようにしたり、対応を自動化して開発チームの作業を減らすことで工数を削減してきました。
変更後
さらにタスクを深掘りし、依頼背景をユーザーと関連部署にヒアリングを行うことで、現状も対応が必要なのかどうかを評価し直しました。 ヒアリングの際に、「既存システムの工数を削減するミッションがあり、動いていること」を共有し、関連部署との関係悪化に繋がらないように気をつけました。
また、データ修正対応基準の見直しを行いました。 「社内利用集計への影響しかないデータ」と「顧客や契約等に関わる正確な情報を保持すべきデータ」で対応方法を分けました。
結果 (3)
データ修正のタスクの対応を見直し、月あたりの平均データ修正対応件数は2.25件減少しました。 データは前後4か月で比較しました。
| 変更前 | 変更後 |
|---|---|
| 8.5件 | 6.25件 |
ただ、「データ修正対応基準の見直し」には改善の余地がありそうです。 基準を設定したものの、依頼者のポジションによっては理解されないことも多く、相談の末に結局、基準外のデータ修正に対応することもしばしばです。 具体的な今後のアクションは、後述の「今後の展望・ネクストアクション」で記載します。
取り組み全体の結果・成果
1ヶ月あたりの既存システムの運用工数を8人月から約3人月に削減しました。
| 7月 | 8月 | 9月 | 10月 |
|---|---|---|---|
| 8人月 | 3.2人月 | 3人月 | 2人月 |
また、メンバーそれぞれの体感も下がっています。 下記グラフはメンバーにヒアリングし、稼働の中で既存システム運用が占める割合を集計したものです。取り組み以降は徐々に低減しています。 8・9月の数値が高いのは、既存システム運用の定義がすり合わせできていなかったためです。
今後の展望・次のアクション
現在の施策での課題は、定期タスクを削減する目的でデータ修正の基準を設定したものの、基準を適用できていないことです。 適用できていない理由は、誰でも依頼できてしまうため、「社内利用集計への影響しかないデータ」と「顧客や契約等に関わる正確な情報を保持するべきデータ」のどちらに当てはまるかが伝わらず、合意形成ができないためです。結果として基準外のデータ修正依頼を受けることがあります。 また、基準が浸透しておらず、依頼者全てに毎回同じ説明をしなければいけないのも手間です。
そこで、現在よく依頼が来る部署には担当者を固定してもらうことを相談しています。担当者には、集計観点の視野を持ち、議論・判断ができることを条件に設定をお願いしました。様々な人から依頼が来ていた状態から固定の担当者に変わることで、オペレーション化や合意形成がやりやすくなり、運用工数の削減ができるはずです。
まとめ
リプレイスを進める中で、既存システムの安定稼働と運用工数削減の両立のために工夫していることを、ここ数ヶ月の記録を振り返って記載してみました。
読んでいる皆さんの周囲の状況によって、対応できることはかなり左右されますが、少しでも参考になれば幸いです。
バイセルではプロダクトマネージャーを募集しています。少しでも気になった方は、ぜひご応募をお待ちしています。
明日のバイセルテクノロジーズAdvent Calendar 2024は辻岡さんの品質とスピードを両立するためにチーム体制を変えている話です。そちらもぜひ併せて読んでみてください！
