フロントエンドエンジニア１年生の頃
制作フローがどんなものかあまり理解せずにプロジェクトに参加し
そこそこ大変な思いをしたので記事にしました。

ふわふわした感じでプロジェクトのMTGに参加しても曖昧な返事しかできないですしね！

この記事は次の方を対象としています。

• フロントエンドエンジニア成り立て・目指している人
• フロントエンドの仕事内容がどうなっているか把握しておきたい人(PM・ディレクター・営業など)

また、私見なので内容は少し偏ってるかもです。

フロントエンドの仕事一覧

プロジェクトによって、異なるのですが
私が携わっていた仕事内容をリスト化してみました。

• 案件MTG
• 資料確認
  • 要件定義
  • 仕様書
  • API仕様書
  • ワイヤー
  • デザイン
• 技術検証
• モック作成
• 環境構築
• コーディング
  • コンポーネント設計・実装
  • ルーティングの設計・実装
  • ロジックの設計・実装
  • データフロー設計・実装
  • API通信部分の設計・実装
  • エラーハンドリング設計・実装
• APIとの結合テスト
  • APIモックとの結合
  • APIとの結合
• クライアント確認出し、FB修正
• 公開
• 公開後対応

ざっくりとこんな項目じゃないでしょうか。
次に、これらの作業をプロジェクトの進行順に見ていきましょう。

フロントエンドの仕事一覧（ある程度進行順）

どの時点でプロジェクトに参加するかわかりませんが
要件定義が終わり、仕様書も作られ、ワイヤーもできている想定とします。

各進行上の仕事内容補足

各進行の仕事内容が連想しやすいように、補足していきます。

アサイン開始

要件定義確認

ざっと次のことが確認できれば良いと思ってます。

• 制作の背景と目的
• ターゲット（ユーザー・ブラウザ・OSなど）
• 作業範囲
• プロジェクト体制（不明点など聞く時は誰に聞けば良いか把握）
• スケジュール

その他、無いと困る情報などがあれば質問していきます。

質問が抜けてしまうこともあるのですが
一度要件定義の書き方を見ておくと足りない項目を連想しやすいです。
参考記事: 要件定義書テンプレート・要件定義書の書き方

仕様書確認

画面や動作の仕様書です。
ワイヤーと照らし合わせて確認していきます。

この段階でこの仕様書が無い場合、仕様書の搬入予定があるかどうかも聞きましょう。
仕様書なんてないよ！って時もあります。

SlackやChatwork、MTG上で動作仕様が決まったりします。
その際は、ドキュメント化してまとめておくと後々の確認や、パートナーが入った時の共有に便利なので
時間を見つけてドキュメント化していきます。
（ドキュメント更新作業が発生します）

ワイヤー確認

ワイヤー上でアプリケーションフローを確認し、過不足・疑問点あれば質問します。

技術的な課題があれば技術検証＆モック作成

要件定義、仕様、ワイヤーを確認して、技術的な不安がありそうであれば事前に共有します。
必要であれば技術検証期間を設けてもらうように打診します。

環境構築

技術的な課題が無ければ環境構築を進めます。

• 使用するJSライブラリの選定(React, Vue)
• UIコンポーネント確認ツールの選定(storybook, styleguidist)
• 状態管理ツールの整備(redux, vuex)
• その他ライブラリの用意(非同期処理用のredux-saga, テスト用のJest などなど)
• 開発プラットフォームの準備(Githubリポジトリの用意)
• 開発用のドキュメント作成
• 型定義を利用するかどうか(TypeScript)
• CircleCIの設定
• Netlifyの設定

など設定していきます。

上の項目が全て必要なわけでは無く
必要かどうか分からないものは必要になったら追加していく形が良いと思います。

デザイン搬入

デザイン確認

コンポーネント作成の指針となるものです。
アプリケーションのフローを想像しながら、過不足が無いか確認していきます。

• インプット要素のエラー表示
• APIエラーがあった際の表示の仕方
• メンテナンスページ

など足りないこともあるので、気づいたら共有します。
（フロント側で良い感じに作っちゃって！ってこともあります）

コンポーネント設計・実装

デザインを見ながらコンポーネントを作成していきます。
複数人で開発している際はコンポーネントの粒度を決め、チーム間で共有します。

参考記事: フロントエンドのコンポーネント設計に立ち向かう

ルーティングの設計・実装

ルーティング、画面遷移についての設計・実装です。
Reactならreact-router Vueはvue-routerなどの有名なライブラリがあります。

Webアプリケーションの場合
画面遷移という概念自体が希薄な場合があります。（メニューの切り替わりのみなど）
そんなときは表示ロジックを自分で設計することも考慮していきます。

ロジックの設計・実装 (API通信と関与しない部分)

デザインと動作仕様書のみで実装できるロジックを進めます。

ボタンを押した時のヘルプ表示や、メニュー表示など
API通信と関与しない部分です。

API仕様書レビュー

デザインと照らし合わせながら実際のフローと照らし合わせ、APIに過不足・不明点が無いか確認します。

何が過不足となるかわからない場合は下の記事の 最低限記載すること の項目を見るとわかりやすいです。
参考記事: APIドキュメントの書き方をまとめてみる

この 最低限 が満たされてない場合はどんどん質問していきましょう。

また、それ以外にもAPIのレスポンス構造や、リクエスト構造について希望があればこの時相談すると良いです。

API仕様書搬入

データフロー設計・実装

• アプリケーションの状態
• APIレスポンス
• APIリクエスト
• ユーザーに表示する情報
• ユーザーの入力情報

などをどう管理していくか設計・実装していきます。

APIとの通信機能の作成

API通信機能を実装していきます。
FetchやAxiosを利用して通信機能を作っていきます。

Fetchドキュメント
Axiosドキュメント

プロジェクトでTypeScriptを使っていれば、この時リクエスト値、レスポンス値を型定義しておくと
API側で修正が入った際も修正範囲がエラーで分かるので便利です。

エラーハンドリング設計・実装

API仕様書に記載されているエラー形式を確認しながら進めていきます。
また、APIのエラーレスポンスメッセージをそのまま表示するか
ステータスコードを見て、フロントエンド側でメッセージを出し分けるかなどAPIチームと協議して決めていきます。

フロントエンド側でのAPIモック作成

もしモックがないことで進行に影響が出る場合は
フロントエンド側で簡易的にモックを作ることも考慮します。

JSONを返す無料APIを3分で作る方法

APIモック環境搬入

APIモックが搬入されたらモックとの結合テストです。
モックなのでエラーは返らないのですが
項目名の違いや、API側の更新が入ってる部分などあったりするのでフロントエンド側でも修正していきます。

API環境搬入

API本番との結合です。
ここでは様々な問題が顕在化するので、かなり労力がいります。
APIエラー内容を見て、修正していきましょう。

また、APIのエラー実装が遅れていた場合、結合テストはかなりキツイものになります。
(リクエストパラメータの違いからエラーが返るが、間違ってるパラメータが何かわからない時など、、、)

結合テストのスケジュールにも直結するので
定例MTGなどでは、エラーの実装状況についても把握しておくと良いかもしれません。

内部検証以降

ここからは検証＆修正です。
数ヶ月に及ぶこともありますがここからのフローは修正作業が中心になるため補足説明は割愛します。

おわり

淡々とした感じの説明になってしまいましたが
資料の有無、デザインやAPIの進捗状況によって
フロントエンドエンジニアが稼働できる部分が変わってきます。

制作フローを理解した上で臨むMTGはまた違ったものになるはずです。
お読みいただきありがとうございました！