負債解消プロジェクトでのPMの動き方

負債って言葉なんか嫌ですよね。借金みたいで。 でもどんなシステムも長年運用していると優先度や人員変動によって放置されたり、やるべきことがやれていない状態になるかと思います。

ご多分に漏れず、Amebaでも以下のような状態が発生しているシステムが有りました。

• 大規模に開発したシステムが、現在は数名が兼務で保守運用している
• サポートの止まったミドルウェアを使用している状態で、システムコストも高くなっている
• 独自フレームワークを使用しているため再利用性が低く、学習コストがもったいない

プロジェクト初期にはどういった状態が今後に向けて良い状態なのかを検討しました。

先に上げた、負債となる状態に対して以下対応を進めることを決めました。

• 大規模に開発したシステムが、現在は数名が兼務で保守運用している
  • 利用頻度の低い機能の廃止
  • 提供する機能を小さくして、システムサイズも小さくし、保守コストも下げる
• サポートの止まったミドルウェアを使用している状態で、システムコストも高くなっている
  • サポートの止まったミドルウェアの利用を廃止
  • 必要なデータのみデータ移行
• 独自フレームワークを使用している状態である
  • 独自フレームワークを使用したシステムの廃止

何をどこで整備するのか

プロジェクトを進める中で何度も繰り返す作業や、エンジニアやデザイナーなどの技術者への依頼を含む作業が発生するケースがあります。

例えば当プロジェクトでは機能廃止に伴ったAPIアクセス数の抽出作業を都度エンジニアに依頼していました。その作業をプロジェクト初期にAmazon Athena連携し、非エンジニアがクエリで抽出可能になりました。その結果、エンジニアが本来集中するべきタスクに注力できました。

これは一例ですが、こういった「1回の作業時間は小さいが、繰り返す可能性があるもの」を見つけ、早めに効率化することが大事だったと、今振り返って思います。

どういった粒度で進捗を可視化するか

本プロジェクトは当初から1年を超える長期を想定しており、プロジェクト初期はタスク管理や進捗の可視化がうまくできていませんでした。

プロジェクト中盤以降、APIエンドポイントや画面URLをリスト化し、それらをタスク管理ツールと紐づけました。その結果、残りのタスク数と今まで完了したタスク数を可視化することができました。

進んでいる感やあとどのくらいで終わるのかがわかっているかはとても大事です。 チームメンバーのモチベーションはきっと上がったはずです。

わからないものはいくら調べてもわからないから、やってみよう

これはあまり良くない考えかもしれないですが、「やってみよう」って思いを常にチームでは意識していました。

古いシステムだったので、全容を把握しているメンバーがいません。そういった状態では調査をどこまでやっても、「完全に理解した！安心してリリースできる！」とはなりません。そうなってくると調査にどれだけ時間をかけても見合ったリターン（リリースの安全性）が得られず、プロジェクト進捗の悪化を招くのみでした。

そのようにプロジェクトを進める中で「可逆的な失敗であれば許容し、リリースも失敗の切り戻しも最短でやろう」という考えにチームが変化していきました。

これは「動くからとりあえず出してみよう」に近いですが、不可逆な失敗、例えばデータ不整合やデータが壊れるなど単純な切り戻しでは治らないかどうかの調査や確認には時間をかけます。その代わり、ユーザー影響と切り戻しコストが軽微な失敗に対しては最短で対応できる準備をした上でスピードを優先しました。

長々と書きましたが、最高のプロジェクトマネジメントだったのか、もっと良いやり方があったのかはわからないです。おそらく今後もわからないなりに進めていくんだと思います。 そうした業務においてはチームで早めに試して早めに失敗に気付いて改善してのサイクルを繰り返していくことが大事だと思っています。

Ameba LIFEは「つくる、つむぐ、つづく、」をビジョンとして「人と情報をつむぎ、暮らしが豊かに育ちつづけるための機会をつくる」をミッションとし、これからも人々の暮らしを豊かにするサービスを提供し続けていきます。

このようなビジョンやミッションに共感をしていただけるプロダクトマネージャー（PdM）の方を募集しております。今回の記事でサイバーエージェントに興味を持った方は以下のURLよりエントリーをお待ちしております！