はじめに

この記事はモチベーションクラウドシリーズアドベントカレンダー2022の記事です。

Vue2(Options API)使用しているPJTに対し、CompositionAPI化&Typescript化を始める機会がありました。
今回はそのPJT開始の初動の話をピックアップして、
　①環境準備の初動
　②PJT進行の初動
の2本立てでお話したいと思います。

やりたいこと

Vue2アプリに対し
- Options APIで書かれている処理をComposition APIに書き換えたい
- TypeScriptを導入したい

環境

Vue.js(v2)
vue-cli
yarn

①環境準備の初動

初動のinstallを進めます。今回導入する2点のinstallと初期設定を進行します。

Composition API
TypeScript

Composition APIのinstall

Vue3の推奨機能とされているComposition APIですが
Vue2でも拡張機能としてimportして使用することができます。
下記実行でinstallを進行します。

yarn add @vue/composition-api@{バージョン}
(※ バージョンに関しては都度確認してください)

TypeScriptのinstall

TypeScriptと関連ライブラリをinstallします

yarn add --dev typescript@{バージョン}
yarn add --dev @typescript-eslint/eslint-plugin@{バージョン}
yarn add --dev @typescript-eslint/parser@{バージョン}
yarn add --dev @vue/cli-plugin-typescript@{バージョン}
yarn add --dev @vue/eslint-config-typescript@{バージョン}

ts_configファイル作成

TypeScriptの設定ファイル。tsconfig.jsonを作成します。
アプリのルートディレクトリでtsconfig.jsonを作成してください

touch tsconfig.json

ts_config設定内容

tsconfig.jsonに初期設定を記述していきます。

今回のリリースはビッグバンリリースを避けて細かく行うことに決めていました。
そのため、「一部は.tsファイルに置き換えて、一部はまだ.jsファイルのまま」といった、
.js、.tsファイルが混在する期間が発生します。
このために、移行プロジェクトの観点での設定が必要です。

compilerOptions.allowJs : true

trueを立てることで、.jsファイルがビルド対象に含まれ、
.tsファイルから.jsファイルを参照ことが出来るようになります。

compilerOptions.checkJs : false

falseにすることで、.jsファイルに対して静的解析をしないようにします。

  "include": [
    (中略)
    "src/**/*.js"
  ]

コンパイル対象に.jsファイルを含めます。

移行PJTが完了した暁には.jsファイルがなくなり、上記の設定は必要なくなるため
移行最後のタスクとしてtsconfg設定の更新を積んでおきましょう。

lintルール追加

.eslintrc.jsにtypescript用のlint設定を追加しましょう。
設定後、既存ファイル対しにlintの新ルールからの指摘が大量に届きます。

新たなlint設定で引っかかった箇所に、一時的にlint disableをつけておく
移行タスクや他の機能開発で対象ファイルを一緒に直しておく

という方針を固め、lint修正を都度進めることにしました。

以上で、TypeScriptとComposition APIが動く環境ができました。

②PJT進行の初動

方針の策定「小さく・続けやすく」

PJT進行を行う上で、今後の作業を鑑みたとき、まず最初に決めたのが
「小さく・続けやすい」　形でやってこう。という方針でした。
定めた理由を大きく3点で記述します。

①ユーザーへの価値提供を止めたくない

本リファクタへリソースを割きすぎてしまい、顧客への価値提供が滞ってしまった。。。
なんてことは絶対に避けなければなりません！
そのため、通常の開発業務と"並行して進行できる"事を目指しました。

②ビッグバンリリースを避けたい

影響範囲が広く、多岐に渡るため、複数のPRが重なるとすぐ試験の負荷が高くなっていきます。
負荷低く、安全なリリースを目指すために、"fatにしないで、小さく出す"事を目指しました。

③優先度・メンバーの変化に強いPJTにしたい

チーム状況に応じたメンバーの増減や入れ替えは起こりえます。
もしこのとき属人性が高い状態だと、メンバー変更と同時にPJTが停止することも有りえるので、
属人性低く、誰でも始めやすい形がいいだろうと考えていました。

また、状況に応じて機能開発の優先度が高まることもあります。他機能の優先度が高まったら、すぐシフトできるが、
お手すきの際にはこちらに着手できる、戻れるような柔軟さを持ちたいとも考えました。

このようなことから 「始めやすい」PJTを目指しました。

小さく続ける工夫

実際に定めた「小さく・続けやすく」を目指して進行するために行った工夫を2つ、ピックアップしてご紹介します。

①PJT憲章の作成

長くPJT進行を行う上で、様々なステークホルダーも増えていきます。

PJTの価値と優先度を判断するPdM、PM、エンジニアリーダー
開発を実際に進行するフロントエンジニア
チームの増減に合わせた新規ジョインメンバー

継続的にリファクタリングを続けていく上では周りの理解と協力・応援が不可欠です。

独自の観点を持ったチームメンバーと、視界を合わせて同じゴールを目指すために、
PJT概要をまとめた資料「PJT憲章」を作成して認識共有を図りました。

※ PJT憲章の書き方に関してはAsanaさんの下記の記事が参考になります

資料では先にご紹介した方針や、PJTの目的、マイルストーンを整理し、
開発フローなども追記して作成しました。

実際に、ステークホルダーが増えるタイミングでは、毎回活用することができ、
オンボーディング負荷を下げることができました。
MTGに赴く際には話す側も要点を押さえて話すことができますし、
参加する側も事前準備や事後の見返しなどができて便利です。

②コンポーネント単位のチケット分割

今回の移行PJTは
　① Options API -> Composition API化
　② TypeScript化
の2点です。今回のPJTでは①、②を順にやっていくなどではなく、
各コンポーネントごとに①、②を対応していくことにしました。

これを遵守するために、対応チケットも各コンポーネント毎に作成して、タスク進行をはじめました。

コンポーネント毎に対応していくことで
「①はやったけど②はまだやってない」などの中途半端な状況を防ぐことができ
どのファイルまで対応したかはっきりする形を目指しました。
対応/未対応と影響範囲がはっきりさせることで「続けやすい」形を目指しました。

さいごに

本PJT進行に携わることで、リファクタリングとの向き合い方、闘い方を考えるきっかけになりました。
これから移行PJTを始める皆様へのヒントになると幸いです。

Vue2へのCompositionAPI＆Typescript導入の初動の話