デザイナーがRails製トップページを改修した話
2023年11月に、プロダクトのプラットフォーム トップページをリニューアルしました!(超カタカナ!)
ほぼダミー&ぼかしですいません。しかしレイアウトが大きく変わったことはおわかりいただけると思います!
なぜこのレイアウトになったか、デザインで気をつけたことは置いておいて。テックブログの名の通りテック周り・・・Railsを初めて触って知ったこと、大きめのプルリク作って履歴がえらいことになったこと、その辺りのお話をしたいと思います。
Railsを触ることになった経緯
デザイナーとしてのジョインでしたが、私はコーディングもしてきたので「いける?」「いけ・・・ます!!」と実装も担当になりました。
初めて触ったと言いましたが、数年前にRailsの中をチラッと見たことはありまして。「コントローラ・・・?モデル・・・?静的サイトと全然違うしフォルダ構造よくわからんさよなら」で終わったので、構造や仕組みの把握からしなきゃな・・という感じでした。
実装をしてみて
Railsわかる・・・わかるぞ!
view部分は静的なHTMLだったので問題なく実装できました🙌
.html.erbという拡張子には戸惑いましたが。app/views/
の中が表示のファイルたちなんですね〜。
MVCの概念もなんとなくわかりました!
Mがモデル:DBを触りに行くものたち
Vがビュー:最終表示してくれるものたち
Cがコントローラー:モデルや処理をゴニョゴニョしてviewに渡してくれるものたち
また、文言と外部URLの記述はすべてyamlファイルに書きました。
yamlファイルというものを初めて知ったのですが、とても便利ですね!最初のタグ入れが大変ですが、文字だけ変えるという行為でHTMLを触らなくていいのはリスク軽減な気がします。
グローバルなプロダクトになったら、yamlファイルを言語ごとに作って対応できるものいいなと思います!(翻訳自体大変だろうけど)
プルリクの履歴がえらいことに…
作業途中で開発環境が変わったので、ブランチの変更コマンドなど打っていたらいつの間にか過去他者のコミットが大量に・・・何を間違ったのか・・・。
エンジニアの先輩に相談し、チェリーピック🍒を使った解決方法を教えていただきました。
新たに別ブランチを作って、作業分コミットだけチェリーピックコマンドgit cherry-pick コミットID
でちまちまと持ってくる、ということをしました。合間に修正やアップデートが多々あったので、20個くらいのチェリーをもぎもぎと。
大変だったけど、また一から実装するよりマシだし、変更履歴を残すためのGithubなので自分だけでなんとかしようとしなくてよかったです。ありがとうチェリーピック、ありがとう手取り足取り教えてくれた先輩・・・
テストってこんな感じなんだ〜
リニューアルの際titleの変更も行ったのですが、そのtitleに対してテストが走っていることを知りました!設定したものと一致してるかのテストがあったのです。
describe '#get_title' do
context 'titleが取得できること' do
let(:url) {'/'}
it 'ページtitleが正しいか' do
expect(helper.get_title(url)).to eq t('page.title')
end
end
end
エンジニアさんがよく「テスト」と言っていたのですがどういうものか知らず、動的な挙動(データの追加や削除)だけにやるものと思っていました。
viewのあらゆる箇所全ては大変だろうけど、要所(確かにtitleは大事、かつ忘れがち)で使えば重要なところは漏れなくテスト側でチェックできるのはいいなと思いました。
テストがどんなものか、ちょっとは解像度上がった気がします!
実装はなんとかなる
実装前は「Ruby on Rails」難しそうだな〜大丈夫かな〜という不安があったのですが、だんだん薄れていきました。そもそも実装内容自体は難しいものでもなく静的HTMLが書けたし、疑問点は優しい&頼もしい先輩エンジニアの方々に相談させてもらっていたので!
むしろ実装より、コミュニケーションで苦労しました・・・。
提案段階の説得力不足
リニューアルの構成提案の段階で、上が納得する説明・ストーリーをなかなか提示できませんでした。つまりどこを目指しているの?と。なぜなら手元にあるものだけで構成をつくっていたからです。
理想のゴールはこれだ!を作り、そこから逆算して踏み出すべき方向性を探るべきでした。
社外の方と直接やりとりする緊張感
いくつかの企業さんに協力をお願いすることがありまして、直接やりとりをさせていただきました。
メールを書いて、ミスがないか上から下まで何度も見てドキドキしながら送信をする・・・なんて重圧!
普段はスラックのみで社内の方とフランクに話しているので、久々に緊張感を味わいました。
リリース前のコミュニケーション不足
もうすぐリリースできそう、という段階ではステークホルダーが多い中で抜け漏れなく最新情報の共有ができていませんでした。関係者へ協力要請、ユーザーさんに改修のお知らせをする準備、エンジニアさんの手を借りてリリースするのでその時間の確保・・・未確定の予定日だとしても、もっと早くスケジュールを相談すべきでした。
振り返ると、関係者を常に把握、見えるように積極的な声かけと、Miroなどで管理するとよかったかなと思います。
いろんな人の力を借りて無事完了🎉
変更点全てのコードレビューとjs記述の良くないところを根気強く見ていただいたり、前述のリリース前時間確保がカツカツながらもリリース対応をしていただいた先輩エンジニアの方々。
急な協力依頼にも関わらず承諾、ご協力いただいた社外の皆様。
意見を聞いたりリリースお知らせの準備をしてくださった社内のカスタマーサクセス、セールスの皆様。
ほんとう〜〜〜〜にありがとうございます!!皆様のおかげでリリース当日は何も問題起こらず安眠できました🛌🛌🛌たくさんの人が関わっていただき、支えてもらったからこそです。
プロダクトはどんどん改修していく&コミュニケーションも増えていくので、円滑なプロジェクト進行を提供できるようコミュニケーションの実践と反省を繰り返していきます!!
コードも自分ができる範囲で書いていきたいです👩💻
NE株式会社のエンジニアを中心に更新していくPublicationです。 NEでは、「コマースに熱狂を。」をパーパスに掲げ、ECやその周辺領域の事業に取り組んでいます。 Homepage: ne-inc.jp/
Discussion