ID:21080さん

## 背景 当時、社内ツールの運用開発をしていたのですが、レガシーと呼ばれるような構成でした。 いくつか掘り下げてみると以下のような課題がありました - 私を除いて専任のフロントエンドエンジニアが開発メンバーにいなかった リソースに余裕がないことからサーバサイドが兼務する形でコードを書いていた - モダンなフロントエンド構成への移行対応が行われていない - 現状でも継続して開発は可能だが、将来的に開発効率をあげる取り組みが必要 ## 課題 1. コードの整理ができていないためカオスな状態になりつつある 2. 例)ファイルやディレクトリの命名、構成、モジュールの粒度、コードスタイルなど - 機能追加や改修、バグfix を行うにも必要以上に時間がかかってしまう 　- あまり本質的でないレビューが発生し、レビュアー / レビュイー双方の負担が上がる 3. コードの修正による影響範囲がわかりにくくバグを発生させやすくなっている - リリースフローにQAを挟んでいるためバグが頻発するとQAのリソースまで使ってしまいとても時間がかかる 4. ページ単位でSingle Page Application (SPA) とMulti Page Application (MPA) が混在している - MPAはJava のThyme leaf を使って開発されていたがメンテする人がサーバーサイドの一部のみと限られており、属人化する恐れがある 要約すると、 **「開発がしづらいことで、ビジネスの実現に時間がかかりやすい」** 環境になっていました。 --- サービスの成長と共にここまで来たけどそろそろ変化が必要だ、と考えこれらを解決するためにサービス事業部全体に向けて3つに分けたロードマップを作って提案し以下のようなことを行いました。 ## 実績 上記の課題感をスライドに落としビジネスサイドのメンバーに説明したところ合意が取れたため、現在はロードマップの実施にむけリードして取り組んでいます。 - 型を意識したコードを書くことが出来る環境の導入(TypeScript の導入) - 既存のコードはそのままで、新規で追加するものはTypeScriptでかけるようチーム内で合意を取りながら進めた - 改修のタイミングで小さく切り出せそうなものはTS移行を行うなどといった関わり方も行った - Lint ruleの導入とコードフォーマッタの追加(eslint, prettierの導入) 組織全体で定義した lint rule を導入し、commit hook などで auto fix させることで誰が書いても同じようなコードになる環境を作る - 新たな Vue 3 を使って開発できる開発基盤を作成し導入 　 - Vue 3 が実行できる新たな開発基盤を作り、composition api を駆使したアプリケーションの全体的な設計や方針を決めています - Vue3 を採用した背景として、もともとのアプリケーション基盤の一部が Vue 2.6 だったと慣れ親しんだメンバーが多かったいう理由もありますが、将来的にメンテナンスフェーズに入る2系で開発するよりも、3のほうが inject / provide が活用できるなど State 管理するという点においても優位性があると判断したため採用に踏み切りました。 - フロントエンドにおけるテスト戦略の立案と vue-testing-library と playwright を用いたテストコードの書き方を布教するなど品質改善に向けてサポートといった動きを意識的に行いました ## 工夫した点 - 新しい技術への抵抗をなくしてもらうためのケアを意識的に行った TypeScriptの導入に際して、敷居が高いと心配しているメンバーに対してのケアを意識的に行いました。具体的には自分で出したPull Request に対してセルフレビュー的になぜこのような記述をしたのかといったコメントを付けたり、画面を共有しながら型の付け方を説明したりとチームメンバーへの技術力の底上げやTypeScriptへの理解度の向上にも寄与していると自負しています。 - 開発基盤を作る上でのCI / CD を誰でもリリースができるよう自動化し、手順がシンプルになるように工夫をしました 具体的には、release branch にマージするだけで自動で tag が push されCI から deploy できる仕組みづくりを開発基盤を作る初期から意識してやっておりました。これを行ったことにより、新たに参加したメンバーがすぐにプロジェクトに関わって2日目でPull Requestを送ったりリリース作業に時間を取られることもなくチームとしてより開発業務に集中できるようになりました。

既存の業務システムがレガシーだったため、サーバーサイドも移行しつつフロントエンドも既存の業務フローに合わせた画面やシステム設計をリードして取り組みました。 #### 現在と未来の比較表 | | back - end | front - end | | ----- | ----------------- | ----------- | | As-is | Perl | jQuery | | To-be | Java (SpringBoot) | Vue.js | 具体的にやったことは以下です。 - Vue.js 3系 と Element-plus というElement UI basedなOSSのUI コンポーネントライブラリを活用し既存機能の整理をしつつ現在の運用に最適化した形でのUIに変更しながらシステムの移行 - Vue 3 では積極的に composition-api を活用しており、定期的なリファクタリングを行うタイミングで設計に関するベストプラクティスを模索しています ### 工夫したこと - 実際に運用しているユーザーからの運用フローやどういった観点で既存システムを作っているのかをヒアリング - ゼロベースに近いものなどは Figmaを使ってプロトタイピングや画面のモックを作成して画面共有してブラッシュアップしていきました。 - スクラム開発でスクラムイベントのリードを行った 1週間1スプリントのスクラムで取り組んでいたのですが、レビューで開発している成果物を共有するときに実際に運用してもらう人を招待してその機能を触ってもらうように取り組みました。 その中でも、「ミニマムでも課題が解決できそうか」、「どうすればもっとより良いものになりそうか」といった観点でヒアリングをし日々イシューを意識した開発に取り組んでいました。その甲斐もあってか、1週間かかっていた作業が1日に短縮されるなどといった運用フローの効率化に寄与できました。

## プロジェクトの詳細について - TypeScript, Go を用いたBackends For Frontends構成でのAPI開発 TypeScriptはExpress、GoではEchoというフレームワークを用いてAPIの開発に従事。APIに必要なDBの設計などから一貫して行いました。 - Nuxt.jsを用いたSPA開発 Nuxt.jsはアルファリリースの段階から採用し、アップデートを継続して開発に従事。Vue.jsを用いたデータのバインディングやコンポーネントの設計及び実装を担当。 共通化して切り出せる UI コンポーネントの作成やaxiosを用いて外部APIを使用した開発、jestを用いたテストを行っておりました。 ## 実績 - TSLintからESLintへの移行 TSLint というのはTypeScriptにおけるコードが任意のコーディング規約通りに書かれているかどうかをチェックする静的コード解析ツールですが、実態は型を持ったJavaScriptなので、ESLintと機能的にかぶることが多くルールの管理が大変だと言われていました。そんな中、2019年2月にTSLintのチームがESLintのTypeScript対応の方針を出したことで自らが提案し合意を得てから移行に踏み切りました。具体的には、現時点で利用しているルールを精査し各Lintで提供しているRuleを対応表を元に揃えつつ整備していくということをやりました。 - Prettierの導入 Prettierとは、インデントや改行箇所といったところにまで介入してコードを自動整形してくれるツールです。 導入したことでレビュー時の細かい指摘などをすることなく誰が書いても同じ結果になるなどコーディングルールが仕組み化できました。 - 決済に関する機能をDBとアプリの設計からコーディング、テスト、リリースまでリードしてリリースを行いました 優待機能や無料お試し期間の提供アドオン機能、売上の集計に必要なデータなどといった課金が絡む機能やビジネス的に必要な要素の機能をリードして取り組みました。例えば、請求金額を表示したいという要件から逆算してどんな情報を保持しておく必要があるのかを洗い出し、APIのレスポンスやDBのテーブル設計、集計処理の設計を行ってきました。また、バッチ処理などでも用いる月ごとの利用料の算出処理や、ページング処理の提案と実装を行い共通化して利用できるようにしました。 - 外部登壇や初心者向けのハンズオン講師を行う DevelopersSummit福岡の登壇や、Ruby on Railsを使ってAlexaスキルを開発するハンズオンの講師などを行いました。https://note.mu/mclolipopjp/n/nb3d50eabbd21