Startup Angular #2 に登壇しました
atama plusのエンジニア友利奈緒（https://twitter.com/rettar5 ）です。
先日開催された、 Startup Angular #2 https://voicy.connpass.com/event/229367/ で 「atama plusでのAngular×ionicプロダクトのバージョンアップとの付き合い方」というタイトルで登壇させていただきました。
このnoteでは、登壇内容について簡単にお伝えできればと思っています。
atama plusとAngularの付き合い・なれそめ
atama plusでは、生徒が触るatama＋アプリや、塾の講師が利用するatama＋ COACHアプリ、家で宿題を解けるatama＋ HOMEアプリや、塾の教室長の方がアカウントや進捗状況を可視化・管理するatama＋ PORTALなどを提供しています。
atama plusでは、2017年の創業時からAngular x ionicの採用しており、4年以上の付き合いになっています。
当然、その中でAngularのバージョンアップ / EOLに対して追従する活動を社内で行ってきました。
半年前までのバージョンアップは、Angularのサポートが切れるEOKのタイミングが近づいた際に、社内のエンジニア有志が20%ルールのような形でバージョンアップ対応を行っていました。
開発基盤チームの誕生とバージョンアップ
半年ほど前、開発組織の体制を変更し、プロダクトオーナー（PO）・エンジニア・QAメンバーのみの「開発基盤改善チーム」が誕生しました。
この新しいチームは、開発効率をあげるための開発や、技術的な課題に専念するためのチームです。POもエンジニア出身のメンバーが担っています。
このチームは、以下2点の課題から誕生しました。
・POが、技術的課題に関するチケットの優先度と通常の機能開発・改善に関するチケットの優先度とを交えて判断することが難しい点
・現状のスクラムチーム（エンジニア・デザイナー・QAの混成チーム）で技術的課題に取り組んだ場合に、デザイナーが取り組む仕事が浮いてしまう点
このチームが誕生して以降、atama plusでは、Angularのバージョンアップは開発基盤チームがリードしています。この半年で、11までバージョンアップをすることができました。
バージョンアップのお困りごと
開発基盤チームの誕生により、有志によるバージョンアップから脱却し、組織的にバージョンアップと付き合える状態になりました。
とはいえ、この体制になってからも、バージョンアップする上で困ったことはあります。
例えば、バージョンアップ対応の期間が長いこともあり、起票されたバグチケットの担当が全て開発基盤チームボールになったりしました。
弊社は、バグのトリアージプロセスが日時で動いており、各チームで毎日取り組むdaily（朝会）の前にトリアージが行われ、チームごとにチケットが割り振られます。トリアージの場で主な原因が推察できない場合、「バージョンアップが原因では？」という理由で開発基盤チームに割り振られます。
この場合、開発基盤チームで調査や修正をしますが、バージョンアップと関係ないバグであることが大半だったりしました。
atama plusにおけるバージョンアップとの付き合い方と今後の展望
お困りごとの1例として挙げましたが、ありがたいことに開発基盤チームは技術力が高いこともあり、きちんと調査・修正を進めていくことができています。
ただし、大半がバージョンアップ起因ではなかったことについては、次のバージョンアップ時にはより良い進め方を検討していけたらと思っています。
開発基盤チームができたこともあり、今後は組織としてバージョンアップに付き合っていきたいと思います。
古いバージョンと付き合い続けるような負債を貯めず、最新バージョン-1に追従する形でバージョンアップを進めていきたいと思います。
ionicのバージョンアップとatama plus
話は代わり、ionicのバージョンアップの話です。
Angularと同じように、ionicともatama plusでは長く付き合っています。
去年の出来事ですが、atama plusではionicを4→5へバージョンアップするためだけに新規機能開発を1ヶ月止めたことがありました。
これは、2年ほど前に行ったionic3→4のバージョンアップの際に、とても大変だった学びを得ていたためです。
ionicのバージョンアップの進め方
はじめに、極力新規機能開発を止めないように、実装・テストの進め方などの作業を並列化できないかを計画しました。
技術的なリスクの検証の一例としては、ionicを採用しているアプリを1アプリのみバージョンアップし、起動できる状態まで持っていくことなどをしました。
これらの事前準備を踏まえた上で、新規機能開発停止を社内にアナウンスし、残りのアプリのバージョンアップに踏み切りました。
ionicのバージョンアップの検証
バージョンアップ後は、ありとあらゆる画面で画面ベースでの比較を行いました。
スクショを取り、miro（オンラインホワイトボードツール）にまとめ、対応が必要な項目をチケット化し、チームで分担して修正を行う、といった形です。
画像の左側のボードは、3→4にバージョンアップしたときのボードです。右側の巨大なボードが今回の4→5のものです。
プロダクトの機能や画面が増えたことで、チェックが必要な箇所がすごい多くなったことがひと目で分かると思います。
スクラムチームで分担して修正を行ったこともあり、対応が必要な項目については、1ヶ月後には無事対応が完了しました。そして、バージョンアップ後のアプリケーションをリリースし、停止していた新規機能開発も再開することができました。
今後の展望
4→5までのバージョンアップ時には、QAやデザイナーなどを巻き込みながら人力でチェック→修正を行ってきました。
プロダクトの規模的にも・人力でやることにも限界がありますし、世の中には便利なツールもあるので、E2Eテストの拡充や、スクリーンショットベースの差分検出をベースとしたバージョンアップの対応に移行していけたらと思っています。
終わりに
まとめです。
atama plusにおけるAngularとionicのバージョンアップの付き合い方についてお話させていただきました。
登壇時の資料は下記にアップロードしておりますので、ご興味をお持ちの方はコチラをご覧いただけたらと思います
atama plusでは、エンジニアを大募集しています。今回のようにプロダクトを全般的に触るエンジニアや、より裏側の仕組みであるレコメンドシステムを開発するレコメンドエンジン開発エンジニアや、アルゴリズム開発エンジニアなど、様々な職種で募集しています。
少しでも興味を持っていただけた方は、カジュアルにお話してみませんか？
下記のエンジニア向けの募集からお申し込みいただけたらと思います！
また、エンジニア向けのTwitterアカウントもできました。
atama plusの開発に関する発信をお届けしていく予定なので、よかったらフォローしてください。