乱雑に組み込まれた技術からReactへの技術刷新
こんにちは。atama plusでソフトウェアエンジニアをしたり、ソフトウェアアーキテクトをしているゆきです。
前回の記事ではレガシー技術なWebサービスをReact刷新する意思決定までの道のりを紹介させていただきました。
今回は技術課題の取り組みもスタートしていますので、その詳細についてご紹介させていただきます。技術課題へのファーストステップに悩んでいる方や、実例を見てみたい方の参考になれば幸いです。
刷新のプラン立て
atama＋プロダクトは、5年ほど運用しているシステムです。今回、技術刷新を行うatama＋ PORTALという塾の運営をサポートするWebアプリだけでも、画面の数は100を超えます。
これだけ大規模なシステムの技術刷新をすすめるプランとしては大きく「一括でAll Replace」または「段階的にReplace」の2通りあると考えますが、以下の理由から今回は「段階的にReplace」する方法を採用しました。
atama plusはスクラムで開発していて、1週間のスプリント単位で動きが見えたほうが親和性が高いため
一括でAll Replaceした場合、どれがうまくいっているのか（あるいはうまくいっていないのか）の切り分けが難しくなるため
プラン立ての仕掛かりとして、スクラムの開発に馴染ませるためにタスクを小さな断片に分割しました。Webサービスの特性上、画面単位だと上手く分割できそうです。
しかし、タスク分割のみの準備で技術刷新をスタートしてしまうと、参考となる実装がないためエンジニアが同時に各画面をいちから構築する可能性があります。
となれば、リソースを多く使ってしまうコストの問題はもちろん、最大の問題として異なる実装方法が乱立してしまうことが想定されます。
これまで抱えていた「乱雑に組み込まれた技術が点在する」という技術負債に再度悩まされる姿が予想できます。
atama plusでは技術刷新の詳細なタスク分割の前に、次のようなフェーズ分けを行いました。
フェーズ1：1ページを刷新してリリースまでやり切る
フェーズ2：フェーズ1の結果を全ページに適応する
フェーズ3：新旧入り混じった実装から旧実装を消去し、刷新後の実装のみに整える
まずは1ページを作りきってしまえば、それが参考実装にもなります。
実際に動くものを参考に各ページに拡大していくと、採用技術や実装ポリシーがばらつくリスクもかなり抑えられそうです。
まずは、少人数で参考実装を作る
フェーズ1として、atama plusでは少人数でタスクフォースを結成することで走り出しました。
（atama plusにおけるタスクフォースは、目的を定めて集まり、達成したら解散する一時的なチームのことです）
今回のタスクフォースには2つの目的があります。
Reactのエコシステムを構成する技術を整えて参考実装を作る
フェーズ2以降の実現可能なプランを作る
少人数で短期集中的にやりきるためのチームなので、以下のようなチーム構成にしました。
技術刷新をドライブするメンバー（1人）
フロントエンドに強いエンジニア（5人）
刷新後のテスト計画を行うQAメンバー（1人）
スクラムマスターやPOの役割をするメンバーも別途いましたが、主な相談相手という立ち位置で動いてもらいました。
今回はタスクフォースを作る手法を選択しましたが、別案として一時的に、フロントエンドに強いメンバーが既存のチームに出張してもらう方法も考えていました。
大事なことは「少人数で」「技術構成を決定する」という2点なので、この目的を達成することができるなら、どんなメンバー構成でも問題ありません。
タスクフォースで検討し、決定したReactのエコシステムを構成する技術について詳しくは、こちらの記事で解説しています。
参考実装を基に全てリプレイス
既存の1画面をReactで作り切ったところで、今後のリプレイスで課題となりそうなポイントも見えてきたので紹介します。
1. リプレイスの作業量がページによって1週間のスプリント内で終わらない可能性が浮上してきました。
画面だけでなくもう1段階タスクを分割する必要が出てきたので、ここで一度、技術刷新を行う要因となった現状の課題に立ち返ります。
乱雑に組み込まれた技術で認知コストが大きいことが1番の課題だったため、リプレイスの最大の目的は「利用技術を統一すること」です。
Reactという観点から素直に実装するとSPAで構築したくなりますが、これは本来の目的ではありません。
もちろん素直な実装の方が言語として最適化されていますし、独自の構成を気にしなくて済むので最終的な形としてSPAが望ましいです。
しかし今回はリプレイスに優先順位を付けて、次のようにもう一段タスク分割します。
Reactにリプレイスする
SPA化する
前者のみ完了した状態というのは、画面の遷移を既存の仕組み（atama plusではDjango）に則ったまま各画面でReactアプリが立ち上がっている状態です。
しっかり画面として動作する前者のみの状態でもリリースを行える仕組みを用意することで対応しました。
2.コンポーネントを多数重ねていくReactの性質上、多数のコンポーネントを利用する画面実装の難易度が高くなることがあります。
フェーズ2の初期はプロダクトとして用意できているコンポーネントの数も少ないので、ページの構造がシンプルなページから段階的に着手する方法を選択しました。
ページAを作ったら、ページAのコンポーネントを再利用できそうなページBがUnlockされる形です。
タスク量をなるべく一定に保つことが目的のため、わたしたちはこの方策を選択しました。ですが、開発環境によっては、はじめに多数のコンポーネントで構成されている複雑なページを作り切ってしまい、後のタスクを軽くすることも有効な手段かと思います。
文化やチームのリソースと相談しながら実現可能な手段を探して実践していくことが大事です。
まとめ
技術刷新のような、どうしても長期的になってしまう活動では、本来の目的を何度も振り返ることが大切でした。
「React化」という言葉だけが先行し、いかに「イケてる実装であるか」に引っ張られてしまうことも何度かありましたが、その度に当初の目的に立ち返るよう各メンバーからのフィードバックを受けながら軌道修正してきました。
その点を踏まえて、全体をドライブするメンバーは固定化すると上手く回る確率が高まります。
もしも途中でドライブするメンバーを引き継ぐ場合は、なるべく決定事項だけでなく、決定に至った過程も大事に引き継いであげてください。
この時に起こり得るリスクとして、前任者の決定してきた事項は全て守るべきものという前提に立ってしまう可能性があります。
実際に、引き継ぎ前の状態から足し算でしか考えられなくなり、本来の優先順位を見失うことがatama plusでも起きました。
積み上げるだけではなく、「中止する」「引き返す」などのアグレッシブな引き算の選択肢を常に持っておくと、目的を失わずに前に進むことができます。
わたしたちの活動はまだ道半ばではありますが、この技術刷新を完遂しても更にその先、まだまだ技術改善の活動を続けていくつもりです。
技術課題と向き合い地道に改善に取り組む活動は、結果としてユーザへ本来の価値を届ける近道となっていることを信じています。
エンジニアのTwitterもあります。
特に技術に特化した発信はZennでも行っています。