入社後、いきなりのサイトリニューアル

はじめに

みなさん、こんにちは。 アルバイト事業部で「マッハバイト」のフロントエンドエンジニアをやっています、山田と申します。 私は7月の頭に入社したばかりなのですが、入社後最初のミッションがサイトリニューアルでした。 今回はその話に触れていきたいと思います。

サイトリニューアルで行ったこと

リニューアルと言っても、フルスクラッチでプロダクトコードを全て書き直すわけではありません。 アーキテクチャの見直しなどは別チームが並行で進めており、僕らの行うことは画面のデザイン変更が主です。

その対応を、9/28のリリースに向けて進めていかなければいけませんでした。

その工程は困りごとの連続

作業を始めたはいいものの、その工程は困りごとの連続でした。

• CSSの修正が想像よりもやりづらい。
• 修正が必要な画面がどれくらいあるの把握出来ていない。
• プロダクトコードがPHP(Symfony)とRuby(Ruby on Rails)に分離していて、戸惑う。
• プロダクトが複雑で、一機能の仕様把握だけでもかなりエネルギーを使う。

一つずつ触れていこうと思います。

CSSの修正が想像よりもやりづらい

デザイン変更を始めて最初にぶつかった問題がこれでした。

マッハバイトはPCとSP(モバイル)でCSSが分離しています。 PCとSPのそれぞれで、CSSの設計思想が違っていたことが初期の参入コストを高めていました。

• PC : FLOCSSベースの設計
• SP : オリジナル設計

といった具合です。

これだけ見るとPCの方が修正しやすく思えるかもしれませんが、そうでもなかったりします。 マッハバイト（当時はリニューアル前のジョブセンスでしたが）はSPの方がユーザーが多く、 CVR向上のためのABテストが繰り返し行われてきました。そのため、設計自体は今風なPC側よりも こまめな整理がされてきたSP側の方が直しやすい場面が度々ありました。

それを踏まえつつ、以下のような方針で地道に修正を重ねました。

• 不要物の削除
  • 使われなくなったページ、CSSがそのままになっているので消す。
• 命名規則の統一
  • 今はハイフン区切りで運用しているが、数年前に作った古いページはキャメルケースになっている。
  • CSS用のクラス名が、JavaScriptのイベントトリガーで使われている箇所があるので分ける。
• デバイス間の設計思想の統一
  • SPの思想を、PCに徐々に寄せていく。
• 後回しにして放置してしまう展開を避けるため、「後で直す」をなるべくやらない。
  • 影響範囲の広い箇所も直すメリットが大きそうなら、恐れずに直す。リニューアル後になると、直しずらくなってしまう。

ありがちな話ではありますが、方針と対応を列挙してみました。 上記以外にも細かい課題はまだ残っているのですが、日々の小さな積み重ねの中で少しずつでも解決していけるように取り組みを進めています。

修正が必要な画面がどれくらいか把握出来ていない

次にぶつかった問題がこれでした。

入社して間もなかった人間が、プロダクトの機能を全て把握しているわけもなく、 画面数がどれくらいか把握しているわけでもない。 どの程度のペースで作業を進めていけばリリースに間に合うのか分からず、頭を抱えました。

しかし、この問題はすぐに解決しました。 僕の入社前に対応が必要な画面の洗い出しは既にGoogleスプレッドシートに纏まっており、 それらを片っ端からやっていけばOKという訳です。

最終的に、画面名を書いたポストイットをホワイトボードに全部張り出し、 修正が済んだらポストイットを剥がすという運用にしました。 （進捗の確認は毎日行っている夕会で各自報告し合う、というルールになっています） こうしておくことで、体の向きを少し変えるだけで残作業が一目で確認出来るようになりました。

「状況はスプレッドシートで確認出来ます」と言っても、案外見てもらえなかったりもします。 場合によっては、こうしたアナログなやり方の方が上手く機能することもあるので、今後も柔軟に考えていきたいです。

プロダクトコードがPHP(Symfony)とRuby(Ruby on Rails)に分離していて、戸惑う

マッハバイトのプロダクトコードはSymfonyとRailsが混在しています。

ジョブセンス時代は元々PHPで開発されており、それらのコードを順次Rubyに置き換えているため、 現在はそれぞれが混在している状況になっているという訳です。

「この画面のViewはPHPだけど、こっちの画面はRailsにあるSlimを触らないといけない・・」

こうした場面が度々あり、参加初期は混乱の連続でした。

PHPは経験があったので、手探りでSymfony実装に潜っていくことが出来たのですが、 Railsは数年前に少し触ったきりだったので、全く実装を追えませんでした。 そこに危機感を感じた僕は、プライベートでやっていた他言語の勉強を一旦全て中断。 PHPとRubyの学習に充てることにしました。

その甲斐もあってか、今はSlimの記法にも慣れ、 RailsのControllerの処理を追うこともなんとか出来るようになってきている実感があります。

これからもPHPやRubyに対する理解を深め、 プロダクトの改善に貢献できるように心がけようと考えています。

プロダクトが複雑で、一機能の仕様把握だけでもかなりエネルギーを使う。

長年続いている事業ならよくある話なのかもしれませんが、 以前はWeb制作の会社で働いていた僕にとっては結構な衝撃でした。

「求人を探し、バイトを見つける」

ユーザがサービス内で行う行動を言葉にするとシンプルに思えるのですが、 それを取り巻く様々な機能や仕様が存在しており、それらは長年の運用によって非常に複雑なものになっています。

サイトリニューアルを行う中で様々な画面を見て、そこに存在している事を知りました。 フロントエンド領域が僕の主戦場ではありますが、事業内で関われる領域を広げるためにも ビジネスロジックに対する深い理解は欠かせないと思うようになりました。

まとめ

3ヶ月弱の期間でサイトリニューアルをやると聞いた時は少し不安がありましたが、 周りの方々の助けを大いにアテにし、なんとか完遂することが出来ました。

今になって思えば、新参者が全画面を一通り触れたのは今後のサービス改善を進める上で 非常に有り難い機会だったとも感じています。

今後はリニューアルのタイミングで手が回らなかったCSS周りの設計整理や、TypeScriptの導入等に挑戦していく予定です。