【Tips2】検証・移行計画：属性定義で「網羅すべきテスト」を設計する
段階移行を安全に進めるうえで立ちはだかったのが、SmartHRの多岐にわたる契約形態だ。10年以上の歴史の中で新規受付が終了した契約形態であっても、すでに契約しているテナントは更新を続けているケースがあり、対応すべき契約形態は膨大な数に上る。すべてのパターンを網羅したテストが不可能な状況で、「どのパターンが検証されていれば問題ないのかを考える必要がありました」と由利氏は振り返る。
そこでQAエンジニアと連携し、契約形態やシステム的に差分が出る特徴を「属性」として定義するアプローチを取った。例えば「クレジットカード払いか否か」「月払いか年払いか」といった項目がそれぞれ1つの属性にあたり、実際には20件ほどの属性を洗い出した。テナントはこれら複数の属性を持つ組み合わせで構成されている。
テスト設計では、属性の掛け合わせで検証すべきパターンと、単独で検証できるパターンに分けた。「カード払いと月払い／年払いの組み合わせは、システム的に大きく違いが出るため掛け合わせでテストします。一方で、グループ会社向けの請求形態は他の属性との掛け合わせで差異が出ないので、単独で検証できると考えました」と由利氏は説明する。
また、本番移行では一度にすべてのテナントを切り替えるのではなく、先行移行グループを設けて段階的に進めた。第1グループは移行手順の確認が目的で少数のテナントを選定し、第2グループは洗い出した属性の代表的なパターンを網羅するテナントを選定した。
もうひとつ、見落とされがちだったのが切り戻し計画だ。当初チーム内では「切り戻しは想定しない」という空気があった。プロジェクト開始前から一部の契約形態にはすでに新アーキテクチャが適用されており、そのデータは切り戻しができない状態だったことから、チーム全体に「切り戻しはできない」という先入観が生まれていたのだ。しかし由利氏は「なんとなく」という思い込みを潰すため、改めて調査を実施。「結果として、ほとんどのパターンで切り戻しが可能だとわかりました」と明かす。SmartHR機能自体に影響が出た場合は速やかに切り戻すという判断基準を定めたことで、より安全に本番移行に臨む体制が整った。
一連の取り組みの成果として、由利氏は「属性を定義したことで、最終的な移行テストで過不足ないテスト設計ができました」と語る。属性の洗い出しはテストパターンの設計と段階移行の計画策定に直結し、切り戻し体制の整備とあわせて、より安全に本番移行へ臨む準備が整った。
【Tips3】ドキュメント整備：「書いておけば見つかる」時代の設計知識管理
由利氏のチームには元々、設計書や仕様書を残す文化がなかった。しかしプロジェクト開始のタイミングで会社全体のドキュメンテーションツールが「Notion」に移行したことも追い風となり、「このプロジェクトではドキュメントを残していこう」と方針を定めた。
整備のポイントは2つある。1つ目は、ユーザーストーリーベースで設計書を記述すること。「クレジットカードを登録してプラン登録ができる」「プラン登録したユーザーが退会ボタンを押したら退会できる」といったユーザーストーリーを起点に、そこから退会可否判定・契約削除・ユーザー削除といった必要な機能へとブレイクダウンしていく。「何を叶えたい改修なのかという軸がぶれないようにできました」と由利氏は語る。
2つ目は、チームとしての判断ログを積極的に残すことだ。「どんな方法を検討し、なぜ決定案を選んだのか」を記録しておくことで、後から判断の根拠を追えるようにした。由利氏によると「実際に助かった場面がある」という。あるデータ更新方法の検討では、当初の決定案が後の工程で上手くいかないことがわかった。しかし、検討ログに他の方法の懸念点と事前調査結果がまとまっていたため、「懸念点をクリアできればこの方法が取れそうだとすぐにわかりました」と由利氏は振り返る。
ドキュメント整備の成果として、当初想定していなかった副産物も生まれた。プロジェクトの途中からAIコーディングの機会が増えたことで、「人間が読む以上にAIにドキュメントを読ませる機会が増えました」と由利氏。最近はNotion AIによって「どこかに書いてさえいれば見つけられる」環境になり、ドキュメント化の効果はさらに高まっているという。
一方で課題もある。設計書の「賞味期限」管理だ。コードとNotionのドキュメントを常に同期させ続けることは難しく、いつまで設計書をメンテナンスするのかがチーム内でまだ曖昧になっている。また、AIに設計書を書かせる取り組みを始めたものの、AIが書いたドキュメントは冗長になりがちで、人間がレビューするのが難しいという問題も残る。
