Long Life RailsApp in the case of REJOB

2019.02.06
REJOB 山﨑大輔 (Github: @mojao)
Long life RailsApp
REJOB
Copyright (C) REJOB Co.,Ltd. All Rights Reserved.

スピーカー
山﨑大輔（Github: @mojao）
Webシステム開発 / 基幹システム開発 / 各種マネジメント / 採用
2007年からRuby, Railsを触り始めました。
Ruby, Rails, RDBMS, 全文検索エンジン, JavaScript, AWS etc.. 何でも屋さんです。
フルスタックエンジニア。

リジョブ
https://www.wantedly.com/projects/18033
求人メディア事業をメインに、
リジョブを盛り上げてくれるメンバー募集中

Long Life RailsApps
リジョブがRailsでリプレースされてから 4年
コードを書いたエンジニア数約60名
累計コミット数 19,000
累計プルリクエスト数 8,000
有効なコード 220,000行
求人という重いテーブルの構造を変えるというプロジェクトが進行中
を1人KPTしてみた結果

Keep
・リリースしたり、効果が良かったりすると事業側のメンバーから感謝される
・Githubフローをちゃんと回せている
・開発環境をDockerで構築できるようにした
・効率的にレビューをするために色々ルールを設けた
・Jenkinsを使ってデプロイやタスクの実行をできるようにした
・RspecとSeleniumが主要な機能をカバーした
・Reviewdogで自動的にコードの書き方を指摘されるのでロジックに対して議論すること
ができる
・ドキュメント管理システムを導入して非エンジニアも巻き込んだ
・プロジェクトのキックオフをすることでコアメンバーの意識を統一できた
・プロジェクト進行においてシンプルなルールだけ決めて守るようにした
・何のためのプロジェクトなのかを明確にした
・ガントチャートをすぐ更新できるように専用のツールを導入した
・Backlogは基本的にFIXした内容とスケジュールのみ記載するようにした

Keep
何のためのプロジェクトなのかを明確にした
2018年11月から走りだした「求人データ構造改革プロジェクト」では、
キックオフ時に「このプロジェクトは何のためのプロジェクトなのか」を明確にしました。
プロジェクトが進むにつれ、「こんな機能も必要じゃない？」という意見や、
「何のためにやっているんだっけ」といった迷いが生まれてきます。
プロジェクトマネージャーやディレクターは常に判断を求められる場面に直面していくことになりま
す。
セッション数、CVR、SEO 、顧客満足度など、様々なKPIが絡み合う中、
今回のプロジェクトは「SEO」に軸足を置き、「求人を掲載しやすいこと」をサブ目的と位置づけし
ました。
このことにより、意思決定のスピードが向上し、判断の背景が明確となりました。
背景が明確なので納得感を持って進行することができています。

Problem
・マルチドメイン・シングルリポジトリでカオス
・歴史が長いのに属人化がすごいので仕様変更がきつい
・テストのカバレッジが極端に低い
・当初の要件が不明なので設計が理解不能
・ドキュメントが散らかりまくり
・ドキュメントが正しいのかわからない
・暗黒期のコードが理解不能
・複数部署の思惑を加味した機能が大量にあって判断がしづらい
・決めたルールを守り、守られているかチェックする機構がない
・開発工数の内訳が全体的にふわっとしている
・新しい技術にチャレンジできる環境だがリスクがある
・エンジニアリングに対してコストを割きづらい
・開発環境の更新が自動化できていない
・ビジネスロジックに対する学習コストが高すぎる
・部分的に疎結合なアプリケーションがあったりして忘れる
・インフラエンジニアが社内にいないので怖い
・システム障害の毀損額が大きい
・品質管理体制が(まだ)整っていない
・Gemを大量に使っていて身動きが取れない
・諸事情によりRailsのバージョン上げづらい
・オフィス環境が厳しい(移転により改善予定)

Problem
伸び代しか無い

Problem
決めたルールを守り、
守られているかチェックする機構がない
要件、仕様、テスト、コーディング規約etc..
プロジェクトが肥大化してくるとRailsのフレームワークではまかないきれないルールが出てきます。
大量のドキュメントがあれば全てをカバーすることもできると思いますが、いちいち読み込む訳にも
いかずソースコード上のコメントや実装を見ながら各自が学習していくことになります。
ビジネスモデルに直結する箇所に関するルールや、直接は影響しなくとも動かなくなったら困るコー
ドなどはテストを書いていくことになりますが、肥大化したプロジェクトではテストの設計難易度が
向上したり、テストの実行コストが跳ね上がります。
リジョブではドキュメント管理ツールを導入したり、コーディング規約を設けたりしていますが、守
られているかどうかはコードレビューまで気付かない場合が多くなってきています。
こういう状況はレビュアーやテスターの責任が重くなりすぎて進行が遅くなりがちなので、なんとか
仕組みで回避したい。

Try
知見を集める

Try
どのようにルールを決め、周知を行い、
チェックしているかを教えてください

最後に
長生きするアプリケーションかどうかは、
誰にもわかりません。
設計は手を抜かず、全力で考えましょう。
リーダブル&テスタブルであることが超重要です。

最後に
ご清聴いただきありがとうございました。

Long Life RailsApp in the case of REJOB

More Related Content

Similar to Long Life RailsApp in the case of REJOB

Recently uploaded

Long Life RailsApp in the case of REJOB