基盤システムへの移行という複雑なプロジェクトに立ち向かっている話

こんにちは。情熱に駆動される世の中にしていきたいnasaです

最近エアコンをつけ忘れたまま眠りました。無事、熱中症になりました。36℃ ~ 38℃ を行き来する日々を過ごしていましたが、復活したので最近取り組んでいるプロジェクトについて書きます。

この記事でいちばん伝えたいことは、温度管理がとっても大事ってことかもしれません！命を大事にしつつガンガン行きましょう

TL;DR

プロダクトの深部を基盤システムに乗せ替えている
基盤システムへの移行のために立ち向かっている課題が複数存在する
この複雑性にどうやって対処しているのか
- 共通の語彙を作る
- ドキュメント整備や意思決定の記録を残す
- リファクタリングを行いながら、新しく作っていく

本記事の登場人物

予約: STORES 予約というプロダクト。STORESが提供しているサービスの一つ。
組織基盤: 組織と従業員と従業員の権限を扱うシステム。組織の構造を管理する

基盤システムへの移行プロジェクトの説明

はじめに、僕が取り組んでいる「基盤システムへの移行」について説明します。

STORESでは、STORES 予約・STORES ネットショップなど6つのプロダクトを展開していますが、まだこれらのプロダクトは完全に相互に接続されているとは言い難い状況です。

これらの連携を加速する上で、組織や従業員とその権限を管理する基盤システムを中心に据え、それぞれのプロダクトのドメインの機能の開発により集中できる状態を目指しています。

その一環として、STORES 予約における「組織」を扱う部分を組織基盤に乗せ替えるのが今進めているプロジェクトです。

組織は下図のようなものになっています。

ここまでの3行まとめです

組織基盤を中心としてプロダクト間がシームレスに接続・連携された状態を目指している
組織管理を基盤システムに委譲し、より予約ドメインに注力した開発を進めることができる
組織管理に注力した機能を、どのプロダクトを使っているかに関わらずオーナーさんに提供できる

何を作るのか

基盤システムへの移行で必要な実装は次の二つに区分できます。

新旧どちらの組織でも既存機能が動作する状態にする
組織基盤への移行機能の開発(旧組織を新組織に移行する)

組織基盤の方はSTORESのどのプロダクトでも使えるように設計されています。そのため、ユーザーさんに入力してもらう項目は、組織基盤の方が多くなっています。

システム移行と言ったときに裏側を切り替えて終わりではなく、ユーザーさんが移行を行うための機能開発が必要になります。(下図のような機能です)

また、当たり前なことですが既存の機能が移行前・移行後のどちらでも変わらず利用出来ないといけません。組織というプロダクト根幹部に手を入れながらプロダクトが変わらず動き続けている必要があります。移行機能の実装よりもこちらの方が遥かに大変です、、、

(ちなみに後者は僕が参入する前におおかた終わっていました)

どのような問題と戦っているか

互換性がない機能

STORES 予約の組織構造はSTORESプロダクト群のなかでも柔軟な方です。

そのため、組織基盤では対応していないユースケースがいくつも存在しました。(もちろん、組織基盤に移行することで実現できる機能も存在します！)

	予約	組織基盤
機能1	o	x (ぴえん)
機能2	o	o
機能3	x	o (嬉しい！)
機能4	o	x (ぴえん)

互換性がない機能については、組織基盤チームに依頼し対応してもらうか、組織基盤をベースとしつつその上に機能開発し対応する、といった対応が必要になります。

ここでは、o or xでシンプルに表していますがグラデーションがあります。「互換性があると言えなくもない」「この部分を削れば行ける」と言った具合です。ほとんどの機能が組織の上に乗っかっているため「互換性があると思っていたけどこのケースでは、、、」といったことも発生するリスクは高いです。

この辺りの調査・見極めが、本プロジェクトでかなり難しい部分だと個人的に思っています。

権限の違い

STORES 予約と組織基盤では権限の構造が異なるため、整合性を取ることが難しいという問題があります

STORES 予約では、ひとつの店舗をひとりの店舗オーナーが管理する、という構造を基本としていました。そのため、ログインユーザーがわかれば、必要な機能・権限・操作対象がわかる状態でした。

例えば、「店舗1の管理者アカウント」でログインしているなら、「店舗1の管理画面」で「店舗配下のリソース全て」に対して操作が行えていました。

組織基盤では、組織とユーザーの関係はより柔軟に表現できます。

ユーザーは「従業員」として「事業者」に所属できる
「従業員」は「事業者」内の「店舗」それぞれについて、一定の操作を行える「権限」を持てる

STORES予約と組織基盤の違いは下図のような感じです。

STORES 予約	組織基盤

これにより、より柔軟な組織構造を実現できますし、アカウントを使い分ける面倒さから解放されるのでユーザーさんにとってはとても良いことです！

ただ、システムの根幹を変更していくことを考えると厄介な問題が多くあります、、

一例としては、「本部アカウント」としてログインする場合は全ての店舗に対して管理権限を持っている前提で機能が作られていました。新システムではこの前提は成り立たないため、ユーザーが何かを参照・操作する際に適切な権限を持っているか考慮して回る必要があります。

対応箇所が多く、1つ1つの影響範囲も広いため難しい部分だなと思っています。

複雑性に立ち向かう

以上がプロジェクトで向き合っている問題の概要でした。（他にもいっぱいあるけどね！)

ここからは、本プロジェクトに参入してからどのように対応してきたか書こうと思います。このプロジェクト固有の話は特にないので、普段から行えることだと思いますー(すでに行っていることばかりだと思いますが、、)

そもそもの考え方

「どう立ち向かっているか」説明する前に、どのような考え、姿勢で望んでいるか説明します。(この辺りは自戒込めではあります)

プロジェクトの目的を振り返ると、「開発効率の向上」と言えなくもないです。

組織管理の面倒を他プロダクトに移譲できる。よりドメインに注力して機能開発を行っていける

ただ移行すれば良いわけじゃなく、「最初から組織基盤が存在したかのように自然な形で」システムが存在する状態を作りたいわけです。

なので、このプロジェクトはSTORES 予約がピタゴラスイッチになるか・ハウルの動く城になるかの分かれ目に立っていると思っています。

これが、本プロジェクトを進める上での前提というか姿勢になってくると思っています。

別の言葉で書くと下記のようなことを考えながらプロジェクトを進めるべきだと思っています。

パッチワークによる開発力の低下を招かない
複雑なものを作る必要がある際に、これは何かがオカシイという嗅覚を持っておく

共通の言葉を作る、まとめる

まずやっていることは、共通の言葉を作ることです。

具体例を挙げると、チーム内で「フランチャイズパターンでは..」「フランチャイズの時xxx」と「フランチャイズ」という言葉を使っていました。しかし、フランチャイズに対して個々人の認識が異なっており議論が空中戦になっていました。

そこで、フランチャイズ認識合わせを行い、ドキュメントや図にまとめるといったことを行いました。

このように、チーム全員の共通の言葉にすることの他に、コードと普段使う言葉を合わせるといったことも行っています。

例えば、店舗には世代があり下記のように判定されていました。

1世代: shop.user.nil?で判定できる
2世代: !shop.user.nil? && !shop.manage_organization_system?
3世代: shop.manage_organization_system?

これくらいのロジックコードを見た時に何を指しているか頭で補完されると思いますが、やはり普段使う言葉と合わせておくほうが認知負荷が低いのでメソッドを追加したりしています。

上記のように「チームメンバー間」や「常用語とコード」で共通の言葉を使うようにして、減らせる認知コストをどんどん減らしていく動きをおこなっています。

情報をたくさん残す

プロジェクトが進んでいく中で、昔の決定を忘れたり、議論の背景や意思決定理由が思い出せないことがありました。僕自身このプロジェクトに入ったのは途中からで、当時は「フェーズ7」という呼び名でした。(いや、1~6何やってきたん、、、みたいな気持ちになったのを覚えています)

人間は忘れてしまうものですし、チームメンバーの入れ替わりへの対応、プロジェクトに関わらない人がコードを触りづらくなっている、などなどいくつか理由がありドキュメントに力を入れ始めました。

具体的にはこれらを実施しています

意思決定ログをdocsリポジトリに追加する(チームではADRと呼んでいますがAは余計ですねw)
コードコメントを追加する
- 該当モジュールが何者か説明。design docみたいなイメージ
- ロジックの説明
- 既存ドキュメントへのリンクをコードコメントとして追加
- 暗黙の前提をコードに残す。コメント追加や、例外を追加するなど