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

# はじめに
この記事は[モチベーションクラウドシリーズアドベントカレンダー2022](https://qiita.com/advent-calendar/2022/mcs)の記事です。

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さんの下記の記事が参考になります

https://asana.com/ja/resources/project-charter

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

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

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

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

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

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