複数事業部への横展開を支える4つの技術的工夫
場作りと並行して、体制面ではチームトポロジーの考え方に基づくプラットフォームチームを2つ立ち上げた。「データ連携基盤チーム」と「共通ヘッダーコンポーネントチーム」だ。
データ連携基盤チームの発端は、各チームがバラバラに顧客データモデルを設計していた問題だ。CXプロダクト全体の根幹となる顧客データが各チームで異なれば、顧客体験にも大きなブレが生じる。当初は複数チームから人を出してバーチャルチームを組む試みもしたが、責任範囲の不明瞭さや意思決定スピードの低下が課題になった。
そこで専任チームを設け、統一のデータモデルを作成・管理するデータハブを構築した。「データモデルを変えたいときの相談相手が明確になった」ことがこの体制の最大のメリットだと山田氏は語る。
共通ヘッダーチームはデザインシステム全体の構築を「現在の規模には見合わない」と判断した上で、乗り換えコストが小さく効果が明確な共通ヘッダー部分に絞った現実的な選択だ。挙動のプロダクト間統一に加え、「これは自分たちのプロダクトだ」というオーナーシップのもとで自律的な機能追加・改善が生まれたことが評価されている。
横方向、つまり複数事業部への展開には別の難しさがある。商流の違い、既存サブシステムの差異、製品ごとの規制や商慣習の違いが、事業部ごとに異なる機能要件として現れる。さらにプロダクトチームは複数の事業部・プロダクトチーム・プラットフォームチームと同時にコミュニケーションしなければならず、その負荷は膨大になる。
これに対して山田氏のチームが打ち出したのが「標準プロダクト」だ。事業部目線で変えたくない業務と変えていきたい業務を整理した上で、他の事業部でうまくいっている業務フローを横展開できるよう、設定によって仕様や挙動を切り替えられるプロダクトを設計した。技術的な工夫は4つある。
1つ目は設定ファイルと環境変数だ。ここの値を変えることで事業部ごとの挙動を制御する。2つ目はテーブル設計で、事業部固有の項目が生まれた際もSQLアンチパターンの「従属テーブル」の考え方を活用し、汎用的に扱えるよう設計している。
3つ目は事業部特有のビジネスロジックを設定ファイルで対処しようとするとif文が膨大になるケースに対し、割り切ってAPIごと独立させる判断だ。そして4つ目はフィーチャートグルで、事業部固有の検証中機能を他に影響を与えず追加・無効化できるようにしている。この4つの組み合わせが標準プロダクトの骨格を支えている。
