レガシーフレームワークからの移行

by Arakaki Yuji

Slide 1

Slide 1 text

レガシーフレームワークからの移行 CBcloud 株式会社新垣雄志（あらかきゆうじ）

Slide 2

Slide 2 text

自己紹介 ● 新垣雄志(あらかきゆうじ) ● Twitter: @arakaji ● 職歴 ○ 琉球インタラクティブ株式会社 ○ 株式会社Payke ○ CBcloud株式会社 ← NOW ● 現職での役割 ○ PickGoというサービスのリードエンジニア

Slide 3

Slide 3 text

COMPANY PROFILE C B c l o u d 株式会社 

Slide 4

Slide 4 text

会社概要  基本情報  © 2016-2019, CBcloud Co., Ltd  2  会社名  英文社名  CBcloud株式会社   CBcloud Co., Ltd.  所在地  東京都千代田区神田練塀町300  住友不動産秋葉原駅前ビル16階  代表  松本隆一  設立  2013年10月  社員数  160名(業務委託・アルバイト／派遣除く)(2022年10月24日時点)  主要株主  Tokyo Ofﬁce

Slide 5

Slide 5 text

会社概要  沿革 © 2016-2019, CBcloud Co., Ltd  3  2013年設立  運送会社時代  ｢PickGo｣の原点  ｢軽town｣リリース  本社を神田に移転  3.6億円資金調達 (シリーズA)  60億円資金調達 (シリーズC)  計80億円調達  沖縄オフィス立ち上げ   大阪オフィス  立ち上げ  初のテレビCM放送  愛知、福岡オフィス  立ち上げ  急成長フェーズを見込む   従業員数(人) 

Slide 6

Slide 6 text

業界情報  物流業界の課題  ラストワンマイル/近距離領域における主な課題   © 2016-2019, CBcloud Co., Ltd  6  1次請運送会社（元請け）を頂点とした階構造となっており、 2次・3 次・4次運送会社（下請け）は、一般的に低賃金や過重労働時間などの問題を抱えている   2次請運送会社 2次請運送会社 2次請運送会社  3次請運送会社  4次請運送会社  3次請運送会社  1次請運送会社  多重下請け構造  紙の地図に、その日の運行ルートを手書きするなどアナログな現場作業による不便さが顕在化している   アナログ・非効率な業務  

Slide 7

Slide 7 text

業界情報  業界の課題を解決するために   業界の課題を解決するために、以下プロダクトを展開   © 2016-2019, CBcloud Co., Ltd  7  業界課題  多重下請け構造  アナログ  非効率な業務  提供プロダクト  概要／説明頁  荷物を送りたいユーザーと、届けてくれるユーザーを直接つなげるプラットフォーム   これまでのアナログな業務を自動化・効率化し、一つのプラットフォームで全ての管理が可能  宅配サービスの配送効率と品質をあげ、簡単に宅配事業を効率化  

Slide 8

Slide 8 text

Slide 9

Slide 9 text

今日話すこと ● PickGoというプロダクト立ち上げ時に選択した技術的意思決定が現在の状況に合わなくなった ● とあるフロントエンドのフレームワークがその状況に陥ったため、そこからどのように移行していくことに挑戦しているかという話をします。 ○ どう意思決定したか？ ○ どのような手順で進めているか？ ○ ぶつかった課題はどのようなものがあるか？ ● 話さないこと ○ 各フレームワークの技術的な詳細 ● ちょっとマネジメントよりの話になるかもしれません。

Slide 10

Slide 10 text

プロダクト立ち上げ当初の技術 ● PickGoというサービスは2016年に「軽town」という名前でサービスローンチ ● 当時の技術スタック ○ バックエンドScala ○ 荷主が使う配送依頼画面はウェブアプリケーション ○ ドライバーがつかうのモバイルアプリ ○ ウェブアプリケーションは SPA ○ モバイルアプリなネイティブ (Swift, Kotlin)で実装された一部の画面を除き、大半は WebViewでSPAの画面を表示 ● 今回移行を進めているのはこの時採用した SPAのフレームワーク

Slide 11

Slide 11 text

会場限定 🤫 

Slide 12

Slide 12 text

その名はAngular.js ● 2012年6月にバージョン1.0.0がリリースされたSPAフレームワーク ● SPAという概念がで始めた時代に、それ実現するフレームワークとして非常に多くのプロダクトで採用された ● ちなみにVue.jsが2014年、Reactは2013年にOSSとして発表された会場限定 🤫

Slide 13

Slide 13 text

なぜこれが技術負債となるのか？ ● 2016年9月にアーキテクチャが一新された次期バージョンがリリースされる ○ 実装時の推奨言語が変わる ○ フレームワークの名称も変更される ○ フレームワークの仕様が大幅に変更され、既存バージョンとの互換性はない ● 中長期的に見てこのフレームワークでプロダクトを作り続けるのは困難 ○ バージョンアップ = ほぼ作り直しのため困難 ○ 現バージョンのままでいることのセキュリティリスク ○ エンジニアの採用・維持への悪影響 ○ 古いフレームワーク故の開発生産性の低さ

Slide 14

Slide 14 text

当時のお気持ちを察する ● 2016年のサービスリリースとフレームワークの次期バージョンの公開はほぼ同時期 ○ こればかりは不幸 ○ できるとするとフレームワーク選定時やプロダクト開発中もフレームワークの開発動向を継続的にウォッチしていれば防げたかもしれないが、プロダクト立ち上げ集中している時期にそれができないのは全然わかる ● サービス立ち上げ後まだこのサービス自体がどれだけ続くかもわからないのに、ほぼ描き直しが必要になるようなアップグレードやフレームワーク移行の選択はとれなかった。 ● その後も事業を伸ばすことにフォーカスした開発が継続する

Slide 15

Slide 15 text

2020年、脱却に向けた活動をスタート - PMFも成功、資金調達に成功、エンジニアの採用も進み、ついに某フレームワークからの脱却に一歩踏み出す - ドライバー向けモバイルアプリで開く WebView、荷主画面のウェブアプリをそれぞれ Nuxt.jsに移行することを決定 - まずドライバー向けモバイルアプリの新機能の画面を Nuxt.jsで実装することからTryすることになった

Slide 16

Slide 16 text

2020年スタートって遅くない？

Slide 17

Slide 17 text

移行開始が遅れた背景 ● CBcloudでは複数のプロダクトを展開 ○ PickGo, PickGo ショッピング、Smaryu トラック、Smaryu ポスト, etc.. ○ 1~1.5年に一つは新しいプロダクトを爆誕させている ○ その分エンジニアの人数がその立ち上げに割いていた ● PickGoの技術的負債はフロントエンドだけじゃなく、バックエンドにも ○ 当初Scalaで開発していたが、開発生産性やエンジニア採用の難易度を理由に途中からバックエンドに Railsを採用 ■ 新機能のAPIはRails, 既存APIはバグ修正や仕様変更があるたびに徐々に Railsに移行 ■ ScalaとRailsの変更稼働状態が続く ○ Rails側も大変 ■ 移行時にAPI仕様を理解してRails wayで書くではなく、 Scalaのコードをポートする形で実装 ● トランザクションスクリプト的なコード、 ARのバリデーションとか使ってない ■ テストがない ■ そう、テストがない ○ バックエンドの課題解決にも工数が取られなかなかフロントの課題に向き合う余力がなかった

Slide 18

Slide 18 text

補足: バックエンドの課題の現在の状況 - 2022年8月時点でテストコードがほぼゼロの状態から現在はテストカバレッジが 74%ほどに - テストコードの充実により、開発速度と安定性は劇的に改善された - ScalaのAPIの移行もある時期に一気に進めて残った APIは1割以下になっている - 外部連携が関わるところがテストが難しく現在止まっているが、実装自体は終わっている

Slide 19

Slide 19 text

パートナーアプリ側の移行PJTがスタート - 新機能の画面をNuxt/TSで開発 - 完全に別サイト・別ドメインでリリース。アプリ側で画面によって開く WebViewを切り替えることで一部の Nuxt/TS化を実現した。 - その後、荷主画面側の機能開発をきっかけに荷主画面も Nuxt移行を進めることを決断 - このタイミングでフロントエンドエンジニアはドライバー側の開発からは離脱して、荷主側に入ることになる。 - パートナーアプリ側の移行 PJTはこのあと停滞期間に入る

Slide 20

Slide 20 text

移行先の技術スタックをNuxt -> Flutterへ変更する - アプリ側の新機能開発要件で、どうしてもネイティブで実装しないといけない要件が出てきた - そのときはKotlin, Swiftで別々に実装 - 両方のOSをメンテし続けるの厳しい - 別プロダクトでFlutterを採用していたので、PickGoでもFlutterが使えないか技術検証 - いけそう - 両方OS対応をする負荷も減らせるため移行先を NuxtをWebViewで開くではなく、Flutterで実装するという風に方針展開

Slide 21

Slide 21 text

Flutter化プロジェクト - まず既存の少ないネイティブ画面を完全に Flutterに移植することからスタート - 完了したらベータリリースにユーザー協力してもらいながらバグを潰していく - 本リリースへ - その後はボトムメニューを Flutter毎にFlutterで実装=>QA=>ベータリリース=>本リリースを繰り返す - 移行中も新機能開発が必要な場合は Flutterで実装する - 新機能開発と移行PJTを並行しながら、2022年8月には移行完了 - 2021年1月スタートなので 1年8ヶ月ほどかかった

Slide 22

Slide 22 text

移行後の恩恵 - いままでモバイル、フロントエンド、バックエンドのメンバーが連携しながら開発を進める必要があったが、モバイル・バックエンドだけで開発が完結するようになった - Flutterで開発したいというモバイルアプリのエンジニアの採用ができた - 某フレームワークで開発したい人、いない

Slide 23

Slide 23 text

荷主画面の移行PJT - 荷主側Webアプリの「依頼画面統合」というプロジェクトに重ねる形で Nuxt移行をスタート - 2020年10月頃

Slide 24

Slide 24 text

依頼画面統合PJTとは - PickGoというサービスでは、500kg以下の荷物を軽貨物というフリーランスのドライバーさんに、それ以上の荷物は2t、4t、10tのトラックを保有する運送会社へ依頼することができる - ただし運送会社への依頼は Smaryuトラックという別サービスで実装されていたため UIが別になっていた - それを一つの画面からどちらにも依頼ができるようにするというのがこの PJT

Slide 25

Slide 25 text

依頼画面統合PJTの状況 - 当初は1人月のフロントエンドエンジニアでできるのではーという甘い見積もりからスタートしたが思いのほか複雑ということで、2人/3ヶ月くらいに変更 - しかし着地としてはフロントエンドエンジニア 3人/11ヶ月くらいかかった。 - バックエンドエンジニアは他にいる

Slide 26

Slide 26 text

難航した原因 - フロントエンドにドメインロジックが強く組み込まれていた - 新機能開発と移行を同時に行ってしまった - プロジェクトリードやメンバーがコロコロ代わり引き継ぎコストが非常に高くなった

Slide 27

Slide 27 text

フロントエンドにロジックが強く組み込まれていた - 配送依頼画面はサービスの根幹を担う機能 - サービス立ち上げから現在までの試行錯誤や価値提供のためのロジックがたくさん存在する - この仕様を読み解き、取捨選択して移行する難易度が非常に高かった - 本来バックエンドが担うべきビジネスロジックがフロントエンドに漏れ出していた - バックエンドの負債とも強い関係 - ScalaのAPIを改修すればいいができないので、別 APIをRailsに作ってフロントエンドでマージ /計算する - Railsの既存APIを改修すればいいがテストなく複雑なコードを触るのが怖いので、別 APIを作ってフロントエンドでマージ・計算する - バックエンドにロジックを組むべきだが他が壊れるのが怖いのでフロントエンドでロジックを組む - 結果、フロントエンドのコードが肥大化していくことに - 技術的負債が重なると更なる負債を生み出すという結果を観測することになってしまった。

Slide 28

Slide 28 text

新機能開発と技術移行を同時に行った - Nuxtへの移行と依頼画面統合という大幅な仕様変更を一緒に行ってしまった - 統合するだけでなく、このタイミングでということで他にも組み込まれた修正が多数 - 既存の実装を完全に把握できていない状態での移行、加えての仕様変更により、実装や計画の複雑さ、関係する部署とのコミュニケーションの複雑さが増してしまった。 - 統合や仕様変更をするにしても、一度既存仕様のまま移行し、その後に統合、そして仕様変更するという形にした方が結果としては早く終わった可能性が高い

Slide 29

Slide 29 text

プロジェクトリードが変わって引き継ぎコストが高い - プロジェクト開始の時点で社歴が長くて仕様理解が高い人は別プロダクトに入っていたり、退職したりでシステム理解が乏しいメンバーでの開発スタートになってしまった - それに加えて、プロジェクトマネジメントやテックリードが別プロジェクトへのアサインために変わったり退職してしまったりで3ヶ月ごとくらいのイメージでリードが変わってしまう状況になってしまった - 引き継ぎコストや仕様理解がその都度は発生し、最終的な QAの段階での仕様確認もこれが正しいという状況を判断するのが毎度毎度時間がかかる状況に

Slide 30

Slide 30 text

2021年8月にローンチ - かなり過酷なプロジェクトとなったが無事ローンチ - この時も特定の荷主様向けのみ事前リリースして利用してもらい、バグ修正などを対応していた上でリリース。 - それでも事前リリースした荷主は使わないパターンでバグが出るなどは多少ありつつも、このバグ対応に開発リソースを一時的に集中して短期で安定化することができた

Slide 31

Slide 31 text

現在の移行PJT状況 - 配送依頼画面をNuxt/TSに移行できることで、その後の新機能開発はだいぶ安心感を持って開発することができた - しかし、その他の画面の移行する余力を得るまで一時的に移行 PJTを停止して他の課題を解決することに集中 - その後しばらくして、移行PJT再開 - 社内のエンジニアだけ進めることが難しいため、社外の開発会社と協力して現在進行系で移行中 - すでに50%の画面は移行済みで、来年 3月には全画面が移行完了する見込み

Slide 32

Slide 32 text

現在の移行PJTの工夫ポイント - バックエンドのScala->Rails移行を先行して進めバックエンド由来の複雑さを軽減 - 機能追加はせずに、既存仕様での移行に専念 - フューチャーフラグを使い、ユーザー公開しなくても mainブランチにマージできるような仕組みを導入

Slide 33

Slide 33 text

スタッフ用管理画面の移行PJT - サービス運営する上で社内のスタッフが広く使っている管理画面 - こちらも荷主画面を拡張する形で作られているのでレガシーフレームワークで実装されている

Slide 34

Slide 34 text

スタッフ管理機能の不足による課題 - サービス運営上多数の機能が必要だが、全然たりていない - そのため開発者に依頼して SQLを叩いて行うオペレーションがたくさんあった - それにより負のサイクルが回っている状況 - 管理機能が足りない - 開発者に依頼がくる - その依頼対応のために新機能のための時間作れない - 管理機能がたりない - これに加えて負債となっているフレームワーク上に新しい画面を追加して負債を増やしたくないという思いが重なる

Slide 35

Slide 35 text

新管理画面開発PJTと爆誕 - 既存の管理画面は一旦そのまま - 開発にくる依頼を新管理画面でできるようにするという目的で Nuxt/TSで新しい管理画面を作る - これにより正のサイクルを作る - 管理機能を作る - 開発者のオペレーション負担が減る - 開発する時間が増える - 管理機能を作る

Slide 36

Slide 36 text

最初はNext.jsでプロトタイプを作る - 社内の別プロダクトもすべて Nuxt.js - だが技術検証の意味もこめて一度 Next.jsで作ってみた - 3ヶ月で10以上の機能を作ってテスト運用 - その上で再度技術選択を考える

Slide 37

Slide 37 text

最終的にはNuxt.jsで作りなおす - Nuxt.jsの3が近くなっている状況なので、管理画面で新しいバージョンの Nuxtを使うことで他プロジェクトに知見を共有できる方がいいだろうと判断 - さらに3ヶ月程度かけてNuxt.jsで作り直して本稼働開始 - その後も機能追加を継続、かつ新しい管理機能もこちらに実装することで管理機能を作ることの抵抗感を大きく減らすことができた。 - いまもオペレーションを支えていて、開発チームの工数削減や他部署のメンバーが開発チーム待ちになるリードタイムを減らしている

Slide 38

Slide 38 text

新管理画面の今後の方針 - 開発者の工数を下げるという目的は一定達成 - 次はスタッフの非効率なオペレーションを効率化する機能開発や、既存の管理機能の移行を目指す

Slide 39

Slide 39 text

まとめ - ビジネスを前に進めるために以前行った決定の上に僕らは立っている - そこを否定しない - とはいえ、これからの数年を今いる人の意思決定が支えるので、現在進行形でレガシーフレームワークの課題に向き合っている - 技術的な課題も多いが、マネジメントの課題の方が多くここをしっかり向き合って改善していくにはある程度長い目線で向き合う覚悟と気合いがいる - だからMPをかなり消費する - ただ、モダンな技術を新規で採用するスキルよりも既存の技術を新しい技術に置き換えていくスキルの方がエンジニアとしての市場価値もおそらく高い - ここに積極的に向き合えると、逆に難しい課題を解く楽しみを味わえて楽しい