はじめに

こんにちは、ヌーラボの池です。ビジネスチャットツール Typetalk の開発をしています。
さて、先日 Typetalk はフロントフレームワークを AngularJS から Angular バージョン2 以降(以下、Angular2系という) に完全移行しました。移行作業は数年にわたる長期プロジェクトとなりましたが無事完了させることができました。今回はこのような長期間の移行作業にかかったリソースや、プロジェクトの進める上で行ったこと、得られたことについて紹介したいと思います。具体的に行った移行作業については別記事にまとめていますのでそちらをご参照ください。

• AngularJS を Angular に移行する際に必要だった作業

アサイン時の状況

まず、私が移行作業にアサインされた時の状態からお話しします。AngularJS の移行作業は私がアサインされる2年ほど前に開始されていました。当時の作業者は1人のみで、半年ほどの作業のあとに担当者がチームから抜けて作業がストップとなり、そのまま1年半ほど経過していました。AngularJS のサポートは2021年12月31日をもって終了されると公式から発表され、その目前に迫った同年8月に4人編成のプロジェクトチームが発足し、本格的な移行作業が始まりました。私がアサインされたのはこのタイミングです。本記事はこのプロジェクトチームが発足されてからの内容が主です。

移行対象の規模

• ビジネスチャットアプリ Typetalk のフロント部分全て
• 行数およそ6万行。(テストコード、Storybook 含む)

移行かかったリソース

以下が AngularJS の移行にかかった人員と期間の全体像です。

青色の部分が実際に移行作業をしていた期間です。
人月換算で62人月を要しました。

行ったこと

1. プロジェクトを6週間ごとに区切る

プロジェクトを6週間ごとに区切り、その1区切りを1シーズンとしました。

良かった点

• プロジェクトにメリハリができた。シーズンごとの実績の確認、チーム編成の見直し、プロジェクトのマイルストーンの見直し、クールダウン(後述)の契機となった

2. クールダウン期間を設ける

1シーズンの終了ごとに移行作業とは無関係の作業を行う期間を2週間設けました。この期間中にプロジェクト外で発生する差し込みの作業を行います。また、時間に余裕がある場合はメンバー自らが行いたいプロダクトの改善作業を自主的に行います。

良かった点

• プロジェクト外の差し込み作業をある程度まとめて行えるので、切り替えにかかる作業コストを軽減できた
• 自分がやりたいと思う作業を行うことでリフレッシュになった
• 有給休暇を使ういい機会になった

3. 実績の指標を設け定期的に計測する

プロジェクトの初期に実績の指標を設けました。具体的には、AngularJS 関連のレガシーとみなされるコードの行数の合計をとり、その減少具合を1つの指標としました。週の最後にこの行数を測定し記録していきました。

良かった点

• 経営陣などへの進捗報告用のデータの1つになった
• 予想の終了時期を概算する参考値になった
• 進捗をチームで確認し合うことでモチベーション維持に繋がった

4. 初期はモブ/ペアプロを多めにする

当初、Angular の経験者はチーム内で1人、AngularJS の移行経験者はいない状況でした。メンバーのほとんどは Angular2系 と AngularJS の両方をほぼ未経験の状態で進めないといけないため学習コストが高く、不安も大きかったと思います。そのため、初期はオンボーディングやコード設計の意思決定をスムーズにするためモブ/ペアプロに多く時間をとりました。1日中モブプロをする日もありました。徐々に2人1組 -> 個人作業と並行性を上げていきました。

5. 週の最後に全員でもう一度プルリクストのコードレビューを行う

週の最後に、その週で行った PR をチーム全員で再度見る時間を設けました。工夫した点、苦労した点を共有し、リファクタリングできそうなところを見つけたら実際に一緒にコード修正をしました。

良かった点

• 工夫した点、苦労した点をチームに知ってもらう機会となり、コードの品質をあげるモチベーションとなった
• コーディング中に生まれる細かい疑問をチームに相談する機会となった
• 問題解決の方法がチームに共有され、各メンバーが同じ問題に時間を費やさずに済んだ

6. 週の最後に YWT 形式でふりかえりを行う

週の最後にチーム全員で、その週の YWT (やったこと・わかったこと・つぎにやること)を出し合いました。プロジェクトの途中からは「他メンバーの良かったところ」「今回のスプリントで起きたバグ」の項目も追加してメンバーに感謝したり発生したバグを再確認しました。

良かった点

• 1週間を振り返ることで次にやるべきことの洗い出しができる
• メンバーの追加・入れ替わりの際、オンボーディングに使うための注意ポイントを思い出せた
• 実際今回のプロジェクトは長かったので、メンバーの入れ替わりはよくありました
• 後でブログ等を書くために、過去に行っていたことや苦労ポイントを思い出せた
• メンバーの良かったところを伝え合ってメンバー同士のヘルプが活発になった

7. Lighthouseのスコアを定期的に確認する

週に1回、パフォーマンス等の分析ツールである Lighthouse (Google) のスコアを確認し、移行作業によってパフォーマンスやアクセシビリティの低下を招かないかを監視しました。

良かった点

• 移行によってアクセシビリティ数値の低下を検知することができた。具体的な原因も示されるのでそれを元に修正できた

8. ドッグフーディングによるバグの検知

Nulab では社員自身が自社製品を日常的に使用するいわゆる”ドッグフーディング”を行っています。そして、開発チーム内外からのバグ報告・フィードバックを簡単に行えるようにしています。これによって今回の移行作業でもほとんどのバグを社内環境の時点で検知し、一般ユーザーへの影響を最小限にすることができました。

良かった点

• 変更箇所からは予想困難な箇所へのバグを検知できた
• 特定の環境下(ブラウザ・OS 等)でのみ発生するバグを検知できた
• タイミングによって稀に発生するバグを検知できた
• 開発者単独の動作テストでは検出困難な、複数人での同時使用によるバグを検知できた
• 大きな変更を行う勇気を出せた

移行作業によって副次的に改善されたこと

今回の移行プロジェクトでは AngularJS からの脱却以外にも多くの副次的な改善がみられました。

1. 巨大なファイルが分割された

今回の移行を機に、長年、コードの付け足しが積み重なり肥大化してしまっていたファイルを分割させることができました。

2. 形骸化していたコードが一掃された

度重なる変更でいつの間にか意味をなさなくなっていたコードや、ブラウザのアップデートによる JavaScript 標準機能の拡充によって自前で実装する必要がなくなったものを一気に削除することができました。

3. バグ検出の仕組みを強化する機会になった

移行作業によるバグをいち早く検知するため、Autify をつかった自動のE2Eテストを導入しました。また、元々導入していた Sentry によるエラー検出も、開発者への通知方法を見直し気づきやすくする改善を行いました。

4. 型の導入により開発体験が向上した

今回の移行作業によってプログラム言語がJavaScriptからTypeScriptへ移行されました。型の導入によって実行時エラーが大幅に削減できることがどれほど嬉しいことか、改めて知る機会になりました。

5. レガシーなライブラリ(AngularJS 以外)の削除・移行できた

jQueryを含む多くのライブラリの置き換え・削除ができました。標準のJavaScriptに置き換えたり、サイズの大きかったレガシーなライブラリを軽量なものに変えることでアプリのパフォーマンスの向上にも寄与しました。

6. プロダクトの仕様を広く深く把握できた

移行作業によってチームメンバー全員が横断的にプロダクトの仕様を深く理解することができました。これによって移行作業以外のコード修正やユーザーからのお問い合わせ対応も迅速に行えるようになりました。

初めは五里霧中、しかし…

初めはチーム全員わからないことだらけでした。Angular2系 と AngularJS の両方をほぼ未経験から始めるメンバーがほとんどで手探り状態で進めていました。エラーが出た時もネット上に前例の情報が少なくトライ&エラーの繰り返しでした。初期の頃はあまり進捗が芳しくなく、私も終わりが見えないことへの不安を感じていました。しかし、根気よく皆で知見を共有し合いながら進めていくうちに移行作業はどんどん加速していきました。移行対象のコードの残り行数が50％を切ったあたりからはメンバーも作業に慣れてきて予想よりも早いスピードで進んで行きました。初期によくモブプロ/ペアプロを行ったことや、全体でのコードレビューを行っていたことが後になって響いてきたのだと思います。

チームで進める大切さ

レガシー技術の移行作業は精神的な負荷が大きい作業だと思います。もう EOL を迎えるフレームワークのドキュメントを長時間読み漁るのは骨の折れる作業です。移行作業によってプロダクトに目新しい機能ができるわけでは無く、下手をすればバグだけが表にでます。プロジェクトチーム発足前(私がアサインされる前)はこの作業を長期間ほぼ一人で行っていたので、担当者の負担はとても大きかったと思います。当時から在籍していた Typetalk のプロダクトマネージャーも、初期の1人体制は本当に良くなかったと当時を振り返っています。その反省が、現在のプロジェクトのチーム構成や進め方へとつながっていきました。実際、私が長期間このような作業を続けてこられたのは、大変さを分かち合えるチームメンバーがいたことがとても大きかったです。自分の変更に起因するバグが検出されたときも「これは気づけないですね💦」と励ましてもらいつつ、再発防止に向けて建設的に議論することができました。タスクの遂行と並行してリファクタリングを行った際は「いいですね!」と褒めてもらえたので、常に+αの成果を出す気持ちを保てました。なので一緒に作業してくれたメンバーにはとても感謝しています。

さいごに

レガシーな技術の移行は多くの組織が直面する大きな課題だと思います。実際、大変な作業ではありましたがその分得られるものも多かったです。もし今も同様の課題に向き合っている方がいらっしゃいましたら、この記事が少しでもお役に立てれば幸いです。