1. フロントエンド
エクメルンではサーバサイドのデベロッパーもフロントエンド開発に参画しました。開発を通じて感じたことなどをサーバサイドデベロッパー視点で紹介していきます。
1.1. 著者背景
経験領域
- メインはサーバサイドのアプリデベロッパー
- HTML, CSSは独学である程度習得している
- 業務でJavaScriptを使ったことがある
- gulpやwebpackを使ったチュートリアルレベルの環境構築をしたことがある
未経験領域
- デザイナーと一緒に仕事したことはなかった
- CSSやJavaScriptのきれいな設計までは考えたことがなかった
- チームでのフロントエンド開発をしたことがなかった
1.2. フロントエンドデベロッパーについて考える
1.2.1. 必要と思うスキル
- デザイナー、サーバサイドデベロッパーとのコミュニケーション
- デザイナーの意図を汲み取り、実装に落とし込む能力
- サーバサイドのデベロッパーと連携してサービスを作り上げていく能力
- サービスについての理解
- 作成する画面や演出がなぜ必要なのかについて理解し、必要な場合には提案までできること
- デザインの知識
- デザイナーとの意思疎通に有効(グリッドデザイン、シャドウ、Flexboxなど初めて聞く用語がたくさんあった)
- サーバサイド技術の知識
- クライアントサイド、サーバサイド両方の特徴を理解しておけば幅広い視点でベストな実装を選択できる
- エクメルンではAPI設計にフロントエンドのデベロッパーも加わることで、両サイドが実装しやすい形でAPI設計することができた
- フロントエンド開発全体の設計
- HTML, CSS, JavaScriptといったフロントエンドに関わるすべての要素をメンテナブルに設計できる能力
- Webサービスでは立ち上げ後も長期的に保守、追加開発をする必要があるためこの能力は欠かせない (単発のキャンペーンサイトと異なり、作れば終わりというわけではない)
- UI作成
- フロントエンド技術を駆使してデザインに沿った画面作成ができること
- ローンチ後の保守
- ローンチ後の保守対応も見据えて、フロント側で発生するイベント(エラー、操作ログなど)を収集する仕組みづくり
- ビジネスロジック作成
- サービス要件を満たすロジック作成ができること
参考情報
- エンジニアからデザイナーに向けて、デザインカンプを作るときにしておいて欲しいこと。
- 実装を引き受ける前に詰めておくべきWebフロントエンドの想定漏れチェックシート
- Front-end Developer Handbook 2017
要約すると
- デザイン~サーバサイド領域の橋渡しを行い
- フロントエンド領域に関する設計、実装すべてを担い
- ビジネス要件に応じて最適なUIの実装、考察、提案を行う
これらの要素を併せ持つのがフロントエンドデベロッパーだと考えました。フレームワークを使ってJavaScriptが書けたり、CSSやSVGを駆使してアニメーションが作成できたりするだけでは少し足りないと思います。著者はサーバサイドから派生したタイプのエンジニアだったので、特にデザイナーさんの考える事や演出へのこだわりについては色々と勉強になることが多かったです。
1.2.2. エクメルンでのフロントエンド開発担当
すべてをカバーする人材を探すのは難しかったため、チームに不足しているスキルセットを洗い出し、全体を補えるような人材配置をしました。最終的にフロントエンドデベロッパー2人とフロントエンドを中心にデザイン、サーバサイド間の連携をするマネージャーの3人体制で進めることになりました。
また、エクメルンではフロントエンドデベロッパー2名のスキルセットを踏まえ、フロントエンドデベロッパーのタイトルを以下の2つに分類しました。
デザイン寄りのフロントエンドデベロッパーマークアップオリエンテッドフロントエンドデベロッパー（MUO）
- 主にデザイナーと連携して画面モック作成や演出の実装を担当
- 最適な画面演出実装方法が選択できるスキルがある(CSSで可能なのか、JavaScriptが必要なのかなど)
- フロントエンドUIデベロッパーに近い存在
サーバサイド寄りのフロントエンドデベロッパーサーバーサイドオリエンテッドフロントエンドデベロッパー（SSO)
- 主にフロントエンドの開発環境構築やビジネスロジック作成を担当
- サーバサイドの技術にも長けているため非同期通信によるAPI連携もする
- フロントエンド DevOps に近い存在
SSOの方はサーバ側の技術に詳しく、ビルドスクリプトによるデプロイをしたことがあるサーバサイドエンジニアであれば馴染みやすい領域だと思います。(実際に著者が担当したのはこの領域)
フロントエンドデベロッパー人材確保で思ったこと
フロントエンドというタイトルに惑わされず、フロントエンド領域の何ができるかを重視する必要があると思いました。もしエクメルンの開発でMUOフロントエンドデベロッパーが不在だった場合、デザイナーとの連携がうまくとれず、SSOが何十人いたとしても最終的によいサービスを完成させることは難しかったと考えています。
1.3. エクメルンでのフロントエンド開発のポイント
1.3.1. 画面作成
画面作成ではデザイナーとフロントエンドデベロッパー間の 確認↔修正 のサイクルを速く回すことを心がけました。具体的には以下の方法でこのサイクルを速く回すことに成功しました。
- 開発者が画面、演出を作成
- webpack-dev-serverを使ってローカルマシンで確認
- Browsersyncを起動してデザイナーが確認
- 確認完了したコードをリポジトリにプッシュ
- リポジトリのプッシュを契機にHeroku環境を更新
- デザイナーやデザイナー以外のチームメンバーがいつでもHeroku環境にアクセスして最新の画面を確認
業務時間中には1~3のサイクルで開発者とデザイナーが頻繁にやりとりして開発を進め、業務時間後にチームメンバーの誰か(ウチのチームではプロダクトマネージャが特に多かった)が確認したい時には自動更新されているHeroku環境が大活躍。
関連技術
webpack-dev-server
- ローカルマシン上で動く簡易サーバ。※ 開発環境の章でも紹介。
-
- 開発マシンに対し、ネットワーク内の他のマシンからアクセスができるようになるツール
- デザイナーが開発者のマシンに直接アクセスして確認することで、リアルタイムでの修正が可能。
- 成果物をFTPなどでアップロードする手間がなくなった。
-
- 本来はPaaSとして使うサービス
- GitHubを連携することでプッシュを契機にHeroku上で自動デプロイが走り、常に最新の確認環境が用意できる
- Browsersyncの場合は確認してもらうために開発マシンを起動する必要があったが、こちらの方法であればチームメンバーが気が向いた時にいつでも確認できる
振り返って思うこと
実際の画面で動きを含めて確認すると「思ったよりも違うかった」ということが多くあったため、決められたデザインを作成する工数だけでなく「作成したものを実際に確認する」ということもあらかじめ考慮したスケジュールを立てるのが重要だと思います。(デザイナーさんのこだわりは半端ない)
1.3.2. フロントエンドデベロッパー間の連携
スタイルガイドを使ってMUOフロントエンドデベロッパー ↔ SSOフロントエンドデベロッパーの連携を促進しました。具体的には以下の方法で実現。
- デザイン側の開発者が完成したデザイン(コード)をリポジトリにプッシュ
- リポジトリのプッシュを契機にスタイルガイド用のHeroku環境を更新
- ロジック側の開発者はHeroku環境にある最新のスタイルを確認しながら実装
振り返って思うこと
仕上がったデザイン使ってクラス名を記述するだけで画面ができあがるのでビジネスロジック作成に専念できました。
CSS-in-JS、、もしたかったですが、CSS設計をしっかりしたのでなくてもそんなに困ることはなかったです。(要は設計が大事)
また、著者にHTMLやCSSについての知識があり、HTMLタグ追加などの軽微なマークアップ修正ができたので、全体としてスムーズに進めれました。(自分の担当領域だけで完結してはいけない)
1.3.3. 開発、結合がしやすい環境の構築
開発開始からスタートダッシュができるようにgulp, webpackを使った環境構築はプロジェクト初期の段階で済ませておきました。
- 効率のよい開発環境構築開発環境の章でも述べたとおり、webpack-dev-serverを使って開発効率を高めた。
- フロントエンドとサーバサイド間の結合サーバサイドと結合して動作を確認する際には gulp を使い1コマンドでコードコンパイルと配置ができるように。本番、ステージング環境以外ではJavaScriptやCSSの圧縮をオフにすることで、コンパイル時間も短縮化。
振り返って思うこと
開発途中にサーバサイドとの結合方法で躓かないように、プロジェクト開始時からある程度の結合方法を決めておくのがよいと思います。開発環境や結合手段を構築するにはフロントエンド、サーバサイド両方の知見が必要なため、著者のようなサーバサイド領域に長けた存在が重要だとあらためて思いました。
CoffeeBreak 〜Railsとフロントエンド連携について〜本ドキュメント執筆中にRails5.1がリリースされ、webpackerなどのフロントエンドとの連携を向上する機能が追加されました。
参考ブログ: Railsフロントエンド技術の今とこれから
エクメルンでは以下の理由でAsset PipelineやSprockets などのフロントエンド連携技術は使用しないことにしました。
初期のプロジェクトメンバはRuby on Rails初心者が多く、Asset Pipelineなどを使いこなせる自信がなかった。→ 疎結合なサーバサイド、フロントエンド実装には長けていたのでRailsの機能を無理に使う必要もなかった。
フロントエンド、サーバサイド開発担当が明確に別れていた→ gulp, webpackを活用することで連携ができると判断し、不慣れなAsset Pipelineなどを無理して使わないことにした。
チームメンバの構成に応じて最適な方法を考えていくのも今後のフロントエンドデベロッパーに求められるスキルだと思います。
1.3.4. フロントエンドの技術調査、選定
先行調査と実装方針決定をする担当者を決め、得た知見などを各エンジニアに展開することでスムーズに開発に取り掛かれるようにしました。
- JavaScript メインとなるライブラリにReact, Reduxを採用。 AngularJSやVue.js と比較すると学習量や実装に必要なコード量が多くなりそうであったが、使いこなすことで保守性の高いコードになると判断。マークアップ含めほぼJavaScriptだけで実装が可能なため、ビジネスロジックを担当するエンジニアにとって処理が追いやすく使いやすかった。
- CSS Sass(SCSS)を採用。従来のCSSに慣れているエンジニアにとってはCSSの記述も可能なSCSSは心強かった。
jQueryなどを使う従来の実装方法案もあったが、新しい方法を取ることを決意。リスク回避のためには慣れた方法を取るべきであったが、実践事例紹介などサービス開発の先にある価値を重視。
振り返って思うこと
Reactだけでもおぼつかない状態で、Redux, ES6, Babel, Sass, PostCSS... といった慣れない用語が沢山出てきたときは、少しフロントエンドに嫌気がしました。。ですが各要素の関連性を分析して１つずつ理解することでフロントエンドの全体像をなんとなく把握することができました。最近のフロントエンド技術は進歩が速くトレンドについていくのが大変という意見もありますが、開発者としての価値を高めるためにコンスタントにトレンドを追い続けるという姿勢は大切だと思います。
1.3.5. フロントエンド全般の設計
HTML, CSS, JavaScriptのコーディングガイド、規約を作成してメンテナブルなコードになるように設計しました。
- HTML
世の中に公開されているコーディングガイドを参考にチーム用のガイドを作成。 - CSS
クラス命名規則として「BEM」 全体の構成案として「FLOCSS」を参考にして設計。 - JavaScript
AirbnbのJavascript Style Guideを参考にコーディング規約を作成。 ESLintによる構文チェックを導入。
参考情報
- HTML, CSSコーディングガイド
- BEM
- FLOCSS
- AirbnbのJavascript Style Guide
- ESLint
- Google HTML/CSS Style Guideを全部日本語に訳してみた【HTML編】
振り返って思うこと
それぞれのベストプラクティスを調査、理解するのは大変だったが将来の保守、機能拡張を考えてこだわり抜きました。調査の過程でHTMLやCSS、JavaScriptに関する理解も深まったので、フロントエンドデベロッパーとなるためには重要な過程だと思います。(「動く」だけでなく「美しい」コードも書けるように)
1.3.6. ビジネスロジック実装
React, Reduxを使った実装について、苦労したポイントや便利なライブラリを紹介します。
(基本的な情報はチュートリアルや書籍などで豊富に紹介されているので割愛)
- コンポーネントのライフサイクルに気をつける開発初期の頃は画面更新処理の起点をすべて
componentWillReceivePropsに記述してパフォーマンスに影響が出たりしました。。ライフサイクルについては早めに理解を深めておくのがおすすめです。 - state管理は Immutable.js を使うネストしたオブジェクトでstate管理をしていると意図せずデータが消えるなどの問題が度々発生。。開発初期からImmutable.jsを使ったstate管理をするのがよいです。
- reducer分割とreselectでコードをすっきりさせるアプリで扱うstateが肥大化すると1reducerでは管理が圧倒的に苦しくなってくるので、reducerを分割し、selectorを設けるのがよい。コードやファイルが増えてしまうが、どの画面がどのstateに関わりがあるのかが把握しやすくなります。
- サービス規模、開発メンバー人数によってはTypeScriptも検討静的型付けにより思わぬ不具合を防止。特にReactでは小さなコンポーネント単位での開発が多くなるため、自動でチェックできる機構があると助かる。
参考情報
- Immutable.jsを使ってReactで入れ子になってるstate更新をするとかそういったときに楽しよう的なお話
- immutableのメリットとImmutable.jsでのModel定義
- Understanding the React Component Lifecycle
- Reduxのreselectとは
- ReactとTypeScriptで半年間サービスを走らせてみてよかった点を振り返って見る
Reactの勉強に役立った書籍
振り返って思うことと反省
Reactはフレームワークではなくライブラリなため、ロジック部分については試行錯誤しながら実装を進めていく必要がある。実装開始時にロジックの実装方針までは考えきれておらず、開発途中にコードがめちゃくちゃになりかけたこともありました。。ライブラリを導入することで自然と設計も仕上がると期待するのではなく、仮プロジェクトの段階である程度の設計方針を設けておくべきだったと反省。
1.3.7. テスト、ログ収集
フロントエンド側のテストは画面テストを実施。Selenium & Headless Chrome & Capybara を使い基本機能の正常系テストをしている。
テストを書きすぎない画面テストは実行時間もかかり、画面の仕様が変わるとテストの修正量も多くなる。テストを書きすぎるとサービス開発よりもテストコード作成の方に時間がかかってしまうため本末転倒にならないよう注意する。
正常系を中心に、異常系はほどほどにエクメルンでの画面テストでは「何かしらの不具合があっても正常系の動作は保証する」というポリシーのもと、正常系テストを中心としている。サーバサイド側の不具合の方がよりクリティカルな問題につながりやすいためこの方針にした。(その分サーバサイドのテストコードでは正常系、異常系の両方を手厚く用意している。)
参考情報
フロント側のJSエラー、操作ログの収集には Sentry を利用。現在ではフロント側で発生した不具合を検知するためにのみ利用しているが、ユーザの操作ログ(どのリンクをクリックしたかなど)も見ることができるため、UI改修後の操作性確認などにも利用できそう。
Sentryの類似サービス
1.4. SSOフロントエンドデベロッパーとして携わった今回の開発を振り返って
フロントエンドデベロッパーと言っても担当領域が広いため一言で表すのは難しい
肩書ではなく何が得意であるかを重視して担当を決めるのが大事
コード設計や環境構築はサーバサイドの開発者も触れやすいのでフロントエンドに興味がある人はこのあたりから始めるのがよさそう
最低限HTML, CSS, JSについて知っておけば全体像の把握がぐっとしやすくなる
開発期間中も技術が進歩していくので「次はコレを、、！」という楽しみが増える