サービス統合によって得た学び

自己紹介

株式会社じげんライフサポートDiv. エンジニアの前川です。

ライフサポートDiv.は主にリフォーム会社の情報・見積比較サービスを展開している「リショップナビ」、プロパンガス会社の情報・見積比較サービスを展開している「エネピ」をはじめとする、住環境に特化したサービスを運営しています。

今回、弊社で運営している「プロヌリ」という外壁塗装の見積もり比較サービスを「リショップナビ」に統合することになりました。

そのサービス統合を担当に任命され、なんとか３ヶ月でやり切ることができたので、振り返りも兼ねて、プロジェクトを経て得た知見について書いていきます。

概要

サービス統合で何をしたのか

今回行ったことは主に３つです。

ひとつ目は、管理画面の統合です。
プロヌリにはあるがリショップナビにはない機能を移植していきました。移植と一言で言いつつも、データの構造が違うため簡単にはできない部分が多かったです。
請求部分で違う箇所があったので、そこがかなりハードでした、、

ふたつ目は、プロヌリからリショップナビへのデータ移行です。プロヌリのデータをリショップナビのデータに合うよう変換をかけ、移行を行いました。データ構造の違いや、それぞれのパラメーターの意味の違いなどを踏襲しながら移管を行いました。

三つ目はプロヌリのフロント画面の変更です。今回の統合によって、プロヌリから「リショップナビ外壁塗装」へとリショップナビのサービスのひとつという位置付けになったので、それに伴うデザイン、文言変更等になります。

担当範囲

スケジュール管理、各タスクの要件定義・設計、メンバーへのタスクの割り振り、自分自身が担当となっているタスクの実装をしました。

なぜ統合したのか

理由はさまざまありますが、理由のひとつとして管理画面の開発コストの削減があります。

リショップナビもプロヌリも、ビジネスモデルが似ており、リショップナビで実施した管理画面の改善施策をプロヌリでも実施するということが多々ありました。
同じ機能に２倍近くの工数をかけているというところに課題を感じていたため、統合し、管理画面を統合することで、開発コストを下げるという狙いもありました。

プロジェクトを進める上で行ったこと・意識していたこと

短い期間で統合を行うにあたって、以下を行いました。

スケジュールの作成

JIRAのロードマップを作成し、統合関連のタスクの進捗を見える化しました。

要件定義が終わっているかなどの進捗が一目でわかるので、非常に助かりました。
JIRAに集約することで、Issueと進捗状況を管理するシートの両方を更新する手間が省けました。開始直後は進捗状況の管理をスプレッドシートでやろうとしていましたが、上長のアドバイスでこちらになりました。スプレッドシートでやらなくてよかったと思います、、w

事業部、開発メンバーとのコミュニケーション

事業部とは週１のMTGで課題、リリース後に起こり得るリスクの共有、対策について議論していました。開発メンバーとは毎日の朝会等で都度進捗の確認をおこなっていました。

リスク管理

統合後のリスクはシステム的な視点、事業部的な視点で洗い出しをおこないました。

また、リスクは発生した場合の重大度を評価し、対策の要否・優先度をつけて管理しました。

システム的な視点は、データが増えることで負荷に耐えられるのかどうか、どの機能で問題が起こり得るのか、仮に切り戻しが発生した場合はどうするのか、といった点を主に見ていました。

事業部的な視点は、プロヌリの運営をしていたメンバーがリショップナビでスムーズに業務を開始できるか、１箇所に負荷が集中するようなことがないかを見ていました。

負荷が集中することへの対策のひとつとして、統合関連タスクの事前リリースをおこなっていました。統合のために請求関連の修正が必須だったのですが、その修正後の請求と統合後の請求が重なると請求を担当している部署の確認作業が膨大になるため、請求関連の修正を統合の１ヶ月前にリリースするようスケジューリングしました。

それぞれ以下を意識しておこなっていました。

スケジュールに遅れが出ないよう統合関連以外のタスクがあたらないよう調整すること

クリティカルパスに遅れが出ないよう注意して見ていました。また、そこにアサインする人には、極力そのタスクのみに集中してもらえるよう統合以外のタスクがあたらないように注意していました。

タスクを事前にリリース可能なもの、事前にリリースしておかなければならないもの、最終リリースでないといけないものの３つにわけ、優先順位、アサインを決定し進めました。

常に開発メンバーの進捗を確認すること

開発メンバーに関しては、全員がバラバラの場所で働いている状態だったため、頻繁にslack等で進捗確認をしていました。

リスク管理のための業務フローの把握

リスク管理を行う上で、リショップナビの業務フローの確認を行いました。
どの時期にどこの部署で何を行っているかを把握し、懸念事項、負荷分散についての対策を検討しました。

プロジェクトを通し学んだこと

スケジュールを見ただけで進捗が把握できる形で管理することにより、工数削減につながる

今回JIRAのロードマップを使用しましたが、パッと見てすぐ何が遅れているか見つけることができるというのは、それだけで工数削減に繋がります。

タスクのステータスと紐づいており、タスクのタイトルと、ステータスが一覧になって表示されるので、ステータスを見るだけで遅れているものが把握でき、素早い判断に繋がりました。

事業部メンバーと定期的に会話することで全体がスムーズに進む

今回、事業部と週１でMTGを設けていましたが、そこでリスク、スケジュール、実装で困っている点を共有することで、その場で仕様調整、スケジュールの調整も行うことができました。今回のプロジェクトと関係なくやった方がいいことです。

事前に想定し得るリスクの洗い出し、対策の立案・キーパーソンとの合意形成で精神的余裕が生まれる

事前にリスクを洗い出し、対策を立案しておくことで、トラブル時にどうしたらいいか分からない状態が減るので、精神的に余裕が生まれます。
今回は撤退のラインを決め、「リリース後にこの不具合が起きたら、この時点のデータの状態にし、ソースも全て戻す」など事業部のキーパーソンと合意を取っていました。

リリース後に、データ量増加により一部機能でタイムアウトが発生しましたが、もとよりリスクとして想定していたところは事前に対策も行っていたため、業務が停止するという事態にまで発展することはありませんでした。
その後のタイムアウトに対しての対応も冷静に行うことができました。

よかった点

今回のプロジェクトを通してよかった点は、ほとんどの実装を業務委託の方や、ベトナムのメンバーで完遂できたことです。具体的には管理画面の統合の大部分と、プロヌリ側の変更に関しての実装をしていただきました。

リショップナビでは、サービス統合以外にも、多くの機能改善施策が並行して進んでいたのですが、統合を限られたメンバーで実装することにより、それらの施策を止めずに進めることができました。

また、今後リショップナビの施策を業務委託の方や、ベトナムのメンバーに依頼する際にも統合をやりきった経験は活かされていくと思います。

苦労した点

今回１番苦労したのは、スケジュール管理です。
納期が３ヶ月（実装は実質２ヶ月程度）だったことと、アサインできるメンバーが限られていたため、事業部メンバーと私の方で要件のすり合わせ・設計を行い、エンジニアのメンバーには実装に集中してもらう形で進めました。また、メンバーから上がってきた工数を確認し、アサインの変更を行っていました。

また、一部機能には最終リリースとは別に納期があったため、事業部の方と要件、テストスケジュールを調整しながら完了することができました。