はじめに
こんにちは。リクルートテクノロジーズでソフトウェアエンジニアとグループマネジャーをしている高橋陽太郎です。連載第3回の本稿では、タウンワークにおけるレガシーフロントエンドのモダナイズとして取り組んでいることをお届けします。
タウンワークの開発体制
タウンワークの開発部隊は、Web・スマホアプリなどを合わせると50名ほどのメンバーで構成されています。開発内容は多岐にわたるため、開発内容の目的に応じてチーム分けがされています。例えば、クライアント（求人情報の出稿主）向けの商品となるような機能の開発を行うチームがあり、カスタマー向けの応募数の向上に寄与するためUI/UXの磨き込みを行うチームがあり、ときにはそれらのチームが協働しながら開発を行っています。
その中で、UI/UXの磨き込みを行うチームの活動の中で見つかった課題から、この改善活動が始まりました。
UI/UX改善チームの抱えた課題
UI/UXの磨き込みは、案件として不確実性が高く、また個々の案件のサイズのブレも小さいという性質があります。そのため、細かな仮説検証サイクルを頻繁に回して学びを蓄積していけるような開発スタイルを志向しており、カンバン方式で開発を行っています。よって、普段はいかに案件開発がムリ・ムラ・ムダなく、スムーズに流れているかをチェックするため、リードタイムや、スループットをモニタリングしています。
そんな中、リードタイムが長く、思うようにスループットが上がっていないという課題が浮き彫りになりました。原因として「開発テスト中にフロントエンド部分のバグによる手戻りが頻繁に発生して開発が予定通り進まない」「差し込み的にバグ対応をすることになり開発効率が上がらない」といった事象が起きていることがわかりました。
既存コードの技術的負債
そこで、さらに原因を調査しました。すると、既存のJavaScriptの実装上の技術的負債により、何かの機能を修正した際の影響範囲が読めない状態になっており、手戻りの頻発につながっていることがわかりました。
具体的には、既存コードに以下のような課題がありました。
- jQueryでグローバル化した変数の参照や書き換えを行っている。
- 画面の制御を行う関数内で、jQueryを利用して相対的に子要素の取得などを行っているが、それがHTMLの変更に弱いセレクタの指定になっている。
- jQueryが一般的でない使われ方をしており、新規メンバーがコードからその実装の意図を直感的に理解できない。
また、開発体制面にも課題がありました。
タウンワーク開発メンバーは、フロントエンドとバックエンドにそれぞれ開発メンバーが分かれており、フロントエンドの手戻りが頻発するとフロントエンド開発メンバーの負荷が高まります。反面、バックエンド開発メンバーはその間手が空いてしまう状態となります。可能であれば、手が空いたバックエンドメンバーがフロントエンドメンバーのヘルプを行えるようにしたいと考えました。
これらの原因を除去するため、改善活動を開始することにしました。
改善方針の策定
まず、改善方針を決めるところから行いました。改善方針の策定は、弊社技術顧問の和田卓人、シニアソフトウェアエンジニアの古川陽介らとともに行い、方針だけでなく利用するライブラリや構成案を検討しました。その際に検討した内容は大まかには以下のようなものです。
- まずはモジュール化し、影響範囲を局所化することが大事。そのためにテストコードも導入する。
- 影響範囲を局所化するため、必要であればReactなどのフレームワークの導入なども検討する。
- バックエンド開発メンバーがフロントエンド開発メンバーの手助けに入りやすくなるよう、ES6記法を導入し、Classなどの構文を利用して記述を行う。それによりJavaとの類似性を高め、バックエンド開発メンバーが習得しやすいようにする。
