# 概要
開発リーダーとして
社内向け基幹業務システムに在庫の棚卸しのための機能の追加開発を行った
本プロジェクトは上場に向けて資産を正確に把握するために必要な機能で、かつ
年末の棚卸しに間にあわせるためにスピードとクオリティが求められていた
# プロジェクトを成功に導くために
スピードとクオリティが求められる一方で自分以外の開発メンバーが5人いたが
gitに不慣れなメンバーや開発経験が浅いメンバーや入社して間もないメンバーがほとんどだったため
1次開発の失敗を生かして開発効率やシステムのクオリティをあげるために以下のことを行った
1. 1次開発時よりも時間をかけた詳細なロジック設計書を作成
- 実装者の実力や要件に関する知識の差による影響を最小限にするために
- また、容易にN+1問題を潰せるようなDB設計を行った
2. ドキュメントは必要最低限のものに絞ってリンク集を作って集約
- ドキュメント作成や見る側の時間を短縮するために
3. システムの構成に関するドキュメント作成
- 入社間もないメンバーや途中でプロジェクトに参加する人が出てきた時にインプットの手間を省くため
4. ローカル開発環境の整備
- Dockerの設定が不完全で慣れてない人が構築に苦労する状態だったため
5. 事前に開発ルールを策定して周知
- 開発効率を上げるため
- レビューがボトルネックにならないようにするため
- コミュニケーションコストを減らすため
- 不慣れなメンバーや途中参加のメンバーへのインプットの時間を省くため
- など
詳細
https://qiita.com/rh_taro/items/b56cfab0fc4a84693b85
6. 自分は余力を残しつつレビューに徹した
- 遅延が発生した際に自分の工数を使ってリカバリできるように
- テストコードのレビューに特に注力してシステムの品質を上げるために
7. DBのロックの実装とそれに対するThreadを使用したテストに特に力を入れた
- 数十人が一気に在庫をスキャンしていくためトランザクション周りの実装が甘いとデータ不整合が起きやすいため
- 事前に調査してロックとロックのテストに関する資料などを集めておいた
# 実装以降
フロントエンドを担当する予定だったメンバーが別タスクの割り込みで実装できなくなったため
急遽自分が担当することになった
余力を残していたおかげでリカバリすることができた
また、Vue.jsの開発経験を積むことができた
# 品質
レビューでテストコードに特に注力したため実装フェイズは遅延が発生したが
テスト時に出たバグは数個程度で修正が少なかったためテストフェイズは前倒しで進み、
結果的に予定より早くリリースすることができ、リリース後もバグは0だった
実装時にテストコードに注力するとテスト以降のフェイズが楽になることを身をもって経験することができた
# パフォーマンスチューニング
本プロジェクトでは
- バッチの実行速度
- 棚卸し結果のCSV生成速度
の2点で時間がかかり過ぎていたため開発終盤で修正して高速化した
## Railsで書いたバッチ
当初12万件のデータを処理するために実行時間は1時間ほどかかっていたが、5分まで短縮することができた
行ったことは下記記事にまとめた
https://qiita.com/rh_taro/items/eaec3e16248d88e2ccf9
バッチは在庫のテーブルをロックして棚卸しに必要なデータをまとめるため
「バッチ実行時間 = 在庫データの登録編集ができない時間」となり
業務影響が大きく、ユーザビリティ向上に大きく貢献できた
## 棚卸し結果のCSV生成
6万件ほどあったためCSVのダウンロードに2,3分かかっていたが
10秒程度まで短縮することができた
ActiveRecordによる処理速度の遅さが原因だったため
RailsのDB周りの処理を調べたりSQLの知見を生かして
pluckメソッドや一部SQLを書いてActiveRecordを使わないように修正して高速化を実現した
この機能も棚卸し実施中や実施後に
いろんな部署の人がダウンロードして実施状況の確認や資料作成に使うため
業務影響が大きく、ユーザビリティ向上に大きく貢献できた