はじめまして、開発部の大沼です。
求人インテリア・内装建築・グルメバイトちゃんなどのサービスの開発に携わっています。
2019年から始まった求人@インテリアデザイン（以下求人インテリア）のRailsへの移行プロジェクト（以下Railsリプレース）が完了したので、それについてお話ししたいと思います。
Railsリプレースの報告と共に他サービスでリプレースを行っていくときの参考になればと思い効率とバグの傾向を分析することにしました。
求人インテリアとは
求人インテリアは2005年にサービスを開始しているインテリアデザイン業界に絞った専門求人サービスです。
以前はJavaとSeasar2を使用して開発していたのですが弊社で現在メインで使っているRubyとRailsへのリプレースを行うことになりました。
リプレースの方針と状況
リプレース初期のバージョンはRubyは2.6でRailsが6.1になります。
サービスの規模はCRUDごとの機能数が107 で画面数が169となっています。
以下の方針でリプレースを進めました。
- CSSとJavaScriptは変更しない
- HTML構造はそのままでviewを移し替える
- バックエンドはクラス設計から見直している
今回のRailsリプレースによって技術的には以下の恩恵が期待されます。
- Seasar2のサポートが切れているためセキュリティリスクがあるがRailsは継続的なアップデートが期待できる
- 黎明期の技術的に未熟なコードが残っているが、それらを保守性や可読性の高いコードに書き直せる
- ビルド環境やアプリケーションが稼働するサーバなどのインフラもレガシーであり置き換えることでデプロイフローの簡素化やセキュリティアップデートを受けやすくなる
- JavaのリポジトリはCIが整備されていないのでRailsリプレースを行い自動テストが常に実行される環境にすることで保守性の向上が期待できる
リプレースは完了して全ての機能がRailsで動くようになり、今後の開発で全ての恩恵を受けれる状態になりました。
具体的な数値があげられるものでは自動テストのカバレッジは約95%と高い水準になっています。
次項からは今回のRailsリプレースの開発について振り返ろうと思います。
開発効率について分析
Railsリプレースでは担当チームが一度変更されました。まずは開発期間などの基礎情報をまとめました。
| 前チーム | 後チーム | |
|---|---|---|
| 開発期間 | 2019年 11月 ~ 2020年 3月 | 2020年 4月 ~ 2024年 4月 |
| 開発人数 | 3人 | 15人 |
| 開発工数 | 832h | 828h |
| 開発状況 | Railsリプレースが中心 | 機能開発の合間で開発 |
リプレース前の状況としては求人インテリアの開発チームの人数が少なく、機能開発が常に動いていたためリプレースがなかなかできずにいました。そこで機能開発をよく行う主要機能のみを先に集中してリプレースをする選択をしました。
前チームは短期間で少数のメンバーが開発して後チームは多数のメンバーが少しずつ開発したことから前チームの方が効率よく開発できたのではないかと考えました。
開発効率の算出の仕方と前チームと後チームの開発効率について分析していきます。
開発効率の分析方法
開発効率を出すためには1タスクごとの粒度を定義する必要がありました。タスクはRailsリプレースを細かく分割したものでデプロイすることで完了します。Railsリプレース全体で77タスクに分けられています。
粒度としてファイルチェンジ数が使えるのではないかと考えてタスクごとの ファイルチェンジ数 / 開発時間 を効率として相関があるのかを調べました。
相関があることが確認できればチーム別にファイルチェンジ数の合計 / 開発時間の合計で全体の効率が算出できます。
補足として主に新卒入社された方が開発を行っていて年次はほぼ一緒でスキルの差はあまりなかったと思います。
抽出の条件は以下になります。
- ファイルチェンジ数は JavaScript・CSS・画像ファイルはそのまま移行するため無視してrbとerbファイルのみを対象にする
- rbとerbファイルの割合はどちらのチームでも7割ほどで差はなかった
- 影響の大きい開発時間が10h以上のタスクを対象にする
- 前半は26タスク・後半は23タスクが該当して全体の9割ほどの開発時間を占めている
- 外れ値を除外するために要件ごとのファイルチェンジ数 / 開発時間を対数にとり箱ひげ図を用いて四分位範囲（第1四分位数から第3四分位数までの範囲）の1.5倍を上下限として判定する
- 5タスクが該当して計算から除外した
結果
結果は以下のようになりました。相関係数が0.7を超えていることからある程度はファイルチェンジ数をタスクごとの粒度として使用できると判断しました。
| 外れ値を除いた10h以上のタスクの効率 | 前チーム | 後チーム |
|---|---|---|
| ファイルチェンジ数（rbとerbのみ） | 1046 | 339 |
| 開発時間（h） | 757.93 | 483.58 |
| 効率 | 1.38 | 0.70 |
| 相関係数 | 0.86 | 0.72 |
前チームの効率のほうが2倍程度高くなっていることがわかります。
全てのタスクとファイルチェンジを対象にした場合でも効率は前チーム2.1で後チームが1.0であり比はほとんど同じになります。バーンアップチャートにするとこのようになります。
結論
以上の結果から多人数で分散して対応すると効率が悪くなることがデータでも確認できました。
長期間で少しずつ開発すると開発メンバーが入れ替わりになるため仕様理解にかかる時間が増えるのが主な原因だと考えました。
リソースが限られている状態では難しいかもしれませんがRailsリプレースを担当するメンバーをある程度固定して短期間で完全に置き換えるまで進めた方が良いと思いました。
Railsリプレースによって発生したバグの傾向の分析
他のアプリケーションでRailsリプレースを行う際の参考にするために発生したバグの傾向を見ていこうと思います。
バグの対応件数は少なくとも22件は確認できました。発生頻度としては 工数 80 hに対して1件ほどの割合になります。
1件ずつ分類したところテストケースが網羅されておらずに起こるバグが全体の半数ほどでした。それらの根本的な原因としては以下のいずれかに該当していました。
- 仕様の理解不足
- 片方の言語の知識不足
- ディレクトリ構成が不適切なことによって影響範囲から漏らしてしまう
- 例: 非同期処理の移行でJavaScriptのファイルが想定外のページから呼ばれていることでそれに気づかずに修正をしてしまいエラーが出る
- ステートフルな実装
- 例: 詳細ページから一覧ページに戻る際に検索条件を残すためにcookieを使っているときにcookieが存在しない場合かつ特定のパラメータがある場合にエラーが発生する
- 入力なしの時の初期値が異なることによって発生するケース
- 例: 空白を初期値としてDBに保存していたところにNULLを入れてしまうことでそのレコードを使う際にエラーが出る
移行元のコードの可読性が低かったり配置が不適切だとバグの発生を移行段階のみで防ぎ切るのは難しいです。またRailsリプレースは経験の浅いメンバーが開発するケースが多くどちらかの言語の知識が不足していてバグが発生しやすくなるのではないかと思います。
まとめ
求人インテリアのRailsリプレースについての分析を行いました。他のアプリケーションで進めているRailsリプレースや将来行うであろうRailsからの移行時に生かしていきたいです。Railsリプレースは完了したばかりなので今後の求人インテリアの開発にも注目していけたらと思います。
