「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 Advent Calendarの21日目の記事です。
数年前になるのですが、長く運用しているシステムのフロントエンドのリプレイスに携わったことがあります。
最終的にはリリースできたのですが、その過程での経験した個人的失敗などを振り返り、プロジェクトマネジメントの観点からまとめることにしました。
背景
リプレイス対象のシステムは、長い期間運用されてきたサービスでした。その期間でじわじわ溜まっていた技術的負債が、普段のサイト改善の開発効率を下げているという問題がありました。
具体的には、
- 長年の機能追加･削除を通して生まれた、大量の不要なコード
- リポジトリの肥大化により、意図せぬ場所に依存関係があり、影響範囲の特定が困難
- コードが分割されておらず、再利用が難しい設計
- ドキュメント等が残っておらず、仕様はコードを読まないと(読んでも)わからない
- ノウハウが複雑化しており、正確に引き継ぐのは困難で、メンバーの入れ替わりごとにLPOの改善スピードは低下する
といったことがありました。
結果、軽微な修正であっても無駄な工数がかかってしまい、生産性が低下していました。その上、予期せぬ不具合が頻発してしまっており、事業の求める開発生産性を満たせない状況でした。
概要
リプレイスで一番解決したいポイントは、サイト改善の生産性を上げるという点に絞りました。
そこで、最も更新頻度が高いフロント部分をバックエンドから分離する設計としました。
バックエンドのAPIは存在していたため、フロント部分のみリプレイスしました。
7ヶ月程度のプロジェクトでした。
結論
たくさん学びはあったのですが、特に以下が重要だと感じました。
- 「成果物」「メンバー」「期限」を明確にすること
- エンジニア以外のメンバーにも理解してもらえるようにきちんと説明し、巻き込むこと
以下、プロジェクトでの失敗もふまえて、この学びに至った経緯を説明していきます。
1. 「成果物」「メンバー」「期限」が不明確だった
私がプロジェクトに参画したのはプロジェクトの中盤でした。その時点でのプロジェクトの計画は、リリース目標の月だけが大まかに定められており、タスクの分割や見積もりがされていませんでした。不確定な状態で調査から始まり、そのまま進んでいたようです。
また、人員のアサインも曖昧で、エンジニア以外はほぼ関わっていない状況でした。
当時は、プロジェクトが進んでいたというのもあり、参画した時点では大きな方向修正をせずに進めてしまいました。
しかし、開発中盤〜終盤に入ってくると、デザイナーやマーケターの工数が数人月単位でかかってきたため、計画外のリリースの遅れにつながってしまいました。
2. 仕様の変更を曖昧にしていた
リファクタリング等であれば、その機能のインタフェースを変更することはしません。もちろん機能追加も混ぜることはしないです。
一方、システムリプレイスとなると、完全に同じ機能を実装することばかりではなく、軽微な改善も入ってしまうことがあると思います。
例えば、
- 過去は必要だったが、現在は不要になった機能の削除
- 継ぎ足し実装されていたことで、非効率な実装になっており、それにより発生していた制約の撤廃
- 新しい技術を取り入れることによる機能アップ
などはあるのではないでしょうか。
この仕様変更について、実際に運用オペレーションをしているメンバーとの議論が不足していました。
一部、プロジェクト後半まで議論ができていなかったものもあり、リリース直前まで確認でドタバタしていました。
本来であればリプレイス時に、機能の変更、追加はできるだけ避けるべきです。しかし、不要だと分かっている機能を作り直すのは無駄なので、一定発生するのは仕方ないと思っています。
ただし、こういった仕様の変更をきちんと整理し、周知させておかないと、仕様自体だけでなく、リリース後のオペレーションの混乱などにも繋がりえます。
3. プロジェクトのゴール等を整理できていなかった
プロジェクトはエンジニア主導で開発を進めており、事業部内での説明と合意が不足してしまっていました。
特に「リプレイスをすることでどのような成果を得たいのか」について言語化できておらず、きちんと説明できていませんでした。
他にも色々ありますが、プロジェクトの途中になって初めて以下の点をまとめました。
- プロジェクトのゴール、スケジュール、関係するメンバー
- プロジェクトの全体像、具体的な変更点
- 成果の指標、切り戻し条件
- 他施策との優先順位の検討と工数割当の議論･合意
エンジニアからすると無条件で必要と感じる技術的負債の解消も、エンジニア以外の人にとっては何が嬉しいのか、どのような効果があるのかがイメージしづらいものです。
開発工数の削減と言っても、何%削減なのか、売上利益にどのような効果があるのかを伝えないと、人によって解釈が分かれて、優先度の判断ができない状態でした。
誰が見ても分かるように定量的に効果を示し、情報を集約しておき、いつでも見れる場所にまとめました。
そして、一度説明して終わりではなく、認識がずれないように根気強く何度も何度も説明をしました。
学び
- 「成果物」「メンバー」「期限」を明確にすること
- エンジニア以外のメンバーにも理解してもらえるようにきちんと説明し、巻き込むこと
まとめてみると、当たり前のことばかりですが、プロジェクトマネジメントの経験が少ない当時は分かっていても全然できないことばかりでした。
初期の段階でこれらを合意すべきですが、途中であっても「怪しい雰囲気」を感じ取った時点で、大きく舵を切る勇気も必要だなと思いました。
また、リプレイスというプロジェクトの特性上、「タスクが後から次々出てくる」「成果が計測しづらい」「エンジニア以外からは理解が難しい」のようなものもあり、プロジェクトマネジメントの難しさも感じました。
まとめ
リプレイスというと、エンジニア起因のニーズからスタートすることが多いですが、プロジェクトには多くのリソースを使いますし、最終的には仕様が変わったり、運用オペレーションが変わったりすることで、今動いているサービスへ影響が大きいものになります。
そのため、エンジニア以外のメンバーにも理解してもらえるように粘り強く説明し、最初から巻き込んで進めていくことがとても大事なのだと学びました。