はじめに

こんにちは。株式会社サイカでソフトウェアエンジニアをやっている鹿島（kashitaka）です。

サイカでは1年以上の期間をかけて、モノリスで動いていた自社サービスをマイクロサービス(Microservices Architecture)に作り替えました。

前回のマイクロサービス化の全体像に続き、今回は「プロジェクト管理編」として、期間1年以上、全員フルリモート環境の中、会社のメインプロダクトのシステムをマイクロサービスに移行したプロジェクト進行の手法や工夫を紹介します。

私と同じく、自社でマイクロサービス化やリアーキテクティングを計画している方々の参考になれば幸いです。

マイクロサービス化のプロジェクト管理

プロジェクトの性質によってプロセスを変えたり手法を変えたりすることがありますが、マイクロサービス化においてはどうでしょうか？私自身、本プロジェクトを進めるにあたってマイクロサービス化だからこそ配慮したり備えておくべきところがあるのではないかと気になっていました。

しかし、プロジェクトを完了させた現時点で、マイクロサービス化だからこそという特別なことはなく他のシステム移行やリプレイスと同様の基本的な開発手法で乗り越えられたと振り返っています。むしろ、より基礎を重要視した取り組みに意識し続けることが大事でした。それはフルリモート環境下という状況で「認識を合わせ続ける」ことをいかに維持するかという点です。

特にシステム移行やリプレイスといった、既存のフローやシステムを入れ替えるプロジェクトにおいては現状からの変化や完成予想、プロジェクトの現況など認識の共有が非常に重要になってくると経験上考えています。フルリモート環境下では、メンバー間での認識合わせがモチベーションや進捗の維持においては生命線にもなると感じています。この前提の中で、私は本プロジェクトで下記３つの軸でメンバー全員が同じイメージを共有し続けることに注力しました。

進め方：誰がいつ何をするのか？
完成品：何を作るのか？
現状：いまどこにいるのか？

認識共有の手段は必ずしも「ミーティング」である必要はありません。実際、このプロジェクトでは定期的なミーティングはチーム昼会のみで、全員リモートでも進行に大きな問題が生じませんでした。

以降では上に挙げた3点に関して、具体例も交えて説明していきます。

進め方：誰がいつ何をするのか？

続いてプロジェクトの進め方についてです。まずプロジェクトの最初に、このプロジェクト全体の進め方を定義しました。各フェーズはどの役割がどんな成果物に責任を持っており、どうすれば完了できるのか？も併せて定義しました。

お互い初めて一緒に仕事するメンバーも多くフルリモートという状況だったので、あえて言語化して認識を共有しました。

併せて、各フェーズの完了目標スケジュールも議論して決めました。

完成品：何を作るのか？

ベンチャーあるあるですが、ローンチから継ぎ足されてきた自社プロダクトには、まとまった仕様書も設計書もなく、動いているプロダクトとコードが全てでした。

今回のマイクロサービス移行では「移行前と同じ機能要件」で作り直す方針ですが、前と同じという理由で仕様書も設計書なしで突き進むのは危険です。

すでにそれなりの規模のプロダクトなので、仕様書・設計書を書き上げるとなると時間も労力もかかることが予想されました。ただ、ソフトウェア開発において仕様書と設計書は「何を作るか」の認識合わせのために欠かせない重要なドキュメントです。すぐに実装を始めたい焦る気持ちをグッと堪えて仕様書・設計書の作成にあてました。

仕様書はPM全員が手分けして作りました。2週間ほどで全機能・画面の仕様書を書き切り、続いてPM責任者がレビュー、さらにエンジニアに対しての仕様のインプットとディスカッションを経て、2ヶ月ほどで完成させました。

完璧な仕様書を書こうとすると時間がかかりすぎるので8割くらいの網羅性で書きました。このように最初に完成度の期待値を揃えることも重要です。

一方、設計書はマイクロサービスという技術的チャレンジでは設計段階で重要な技術課題と解決策を明らかにしておくことが重要です。

PMが仕様書を作っている時期に並行して、エンジニアではテックリードが中心となり、2ヶ月ほどの時間をかけて相互レビューをしながら仕上げて行きました。

これらは結果的にプロジェクトを通して重要なドキュメントになりました。開発の後半でも議論の土台としてPM・エンジニア・QAが参照し、作っているものの正しさの唯一の基準(Single Source of Truth)となりました。

これで何を作るか・どう作るかが明らかになり、作るために必要なスケジュールも明らかになり、あとはひたすら開発するだけという状態になりました。

現状：いまどこにいるのか？

続いて、実際に進んでいく過程で、私たちが現状の認識をどのように合わせていったのかをご紹介します。

最初にCI/CDを整備して常に結合テスト

プロジェクトの現状を把握する上で最も効果的な方法は現時点での成果物を見ることができることです。どの画面ができていてバグがどこにあるのか実際の製品を見ながら進捗を確認して進めることができるメリットがあります。

開発の最初のタスクとして開発環境・ステージング環境を用意した際に CI/CD環境の整備を行いました。常に最新の main ブランチがステージング環境にデプロイされるようにして、各自の作業ブランチは開発環境で疎通確認できるようにしました。

マイクロサービス移行プロジェクトなどでは、システムのフロントエンドとバックエンドの認識合わせと同様に、サービス間の疎通確認も大事です。開発プロセスとしてはそれぞれのサービス単位で別々の担当者が並行開発しています。これがいざ結合となった時に「想定と違った」ということがあります。そういった問題にいち早く気づいて対応する上で、常に最新の成果物を確認できる環境と仕組みは有効でした。プロジェクトメンバー全員が実際のモノを見て、完成した画面を讃えたり、問題を議論したりしました。

進捗はガントチャートで

今のプロジェクト進捗はスケジュールより遅れてるのか、進んでいるのか。
大きなプロジェクトでスケジュールの余実を把握するのは一苦労です。また、システム移行系のプロジェクトは他の開発プロジェクトのブロッカーになることも多いため、プロジェクト遅延は大きなリスクになります。そういった背景から、本プロジェクトでは全員が1つの画面を見て状況がわかるようにガントチャートで進捗を管理しました。