大塚流フロントエンド開発の歩き方

フロントエンド開発は考えることが多い。とくに 0 -> 1 の場合だと、何からはじめたらいいのか？が全然わからず、途方にくれてしまうこともあるでしょう。実際、ぼくがそうでした。

そして、そういった情報はなかなか検索しても出てこない。設計方法や実装方法みたいなものはたくさんあるのに。なので、書いてみました。

これは、ぼくがいくつかのフロントエンド開発を経て「これを最初に知っていれば、もうちょっとうまくできたかも？あの失敗がなかったかも？？」をまとめたものです。

フロントエンド開発に不慣れな方の参考になれば、これ幸いです。

まずは仕事のゴールを確認する

プロジェクトや各フェーズごとに仕事のゴールは異なるため「何をもって仕事が完了したと言えるか？」を確認する。たとえば、要件定義フェーズであれば「画面仕様書が完成する」とか、開発フェーズであれば「API結合試験がすべて完了し、バグチケットがすべてクローズされる」とか。確認せずに経験則だけで判断すると「XXがなくない？」とか「おもてたんとちゃう」となって、事故る確率が高くなる。

誰に確認するか？も重要。社内外のさまざまな人とコミニケーションをとり、最適解を見つけなければならない。

ヒント：たぶんまずは PM に聞くのが良いと思われる

よくありそうなやつ

要件定義フェーズ

「フロントエンド開発を開始できる」をゴールとして設定すると、大きく間違えることはなさそう。

• 画面仕様書がある
• デザインがある
• 対象ブラウザが決まっている
• 開発工数見積があり、スケジュールが組める

開発期間フェーズ

• 画面仕様書・デザインどおりのフロントエンドアプリケーションがデプロイされている
• 適切なテストを経て、リリース可能な状態になる
• 必要なドキュメントが揃っている

ゴールまでの道筋をタスク化してこなせば、必ず仕事は終わる！（はず）

必要なマインド

• ゴールを常に意識する
• 不安なものほど先に片付ける
• わからんことは素直に聞く

ゴールを常に意識する

「何をもって仕事が完了したか？」がブレたりわからなくなると、事故る可能性が高まる。「このまま進んだら、ゴールに到着できるか？」を常に考え、問題があれば対策を取る。

不安なものほど先に片付ける

たとえば、インフラの知識がなく、デプロイ方法がわからないとする。構築するのに本来は一週間かかるが、気がつけばあと3日しかない。。。みたいなことがないように、不安なこと（予測できないもの）ほど、日数があるうちに片付けておく。

よくありそうなやつ

• 認証
• デプロイ

わからんことは素直に聞く

手遅れになったり、事故ったりする前に聞け！「自分の力で解決したい」欲求もあるが、聞く力も自分の力。

ただし、調べられるドキュメント等はすべて見た上で！自分なりの答えを持っておくとより良い。

大塚流項目別対処法

開発工数の見積もり

• 思てる1.5倍はかかるという意識を持つ！
  • 2倍、3倍という説もある
• 新しいチームの場合は、立ち上がりに時間がかかることを考慮しておくと良さそう
  • 1.3 〜 1.5くらい多めに見積もってよさそう
• 1人日は6時間で考える
  • 会議とかあるから
• できればアサインされるメンバーのスキルや経験を加味する
  • 不明であれば、全員プロフェッショナルということもないと思うので、一定数アソシエイトが入り、フォローが必要になるという前提があると良さそう
• 規模が大きい場合は、リーダーが手を動かさないかもしれないことを考慮しておく
• 認証は思ってるより時間がかかる（かかった）
• 仕様だけじゃなく、フレームワークやライブラリのキャッチアップの時間も確保する

見積もり時に考慮したほうが良さそうな項目

• フロントエンド開発環境構築
  • ライブラリ選定
  • フロントエンド設計の制定
  • リンターやフォーマッター等の設定
• デプロイ環境構築
  • 開発、ステージング、本番等、複数用意する必要がある
  • CI / CD 設定
• Git リポジトリ用意
• コンポーネント開発
• 画面開発
  • 仕様キャッチアップ・タスク整理
  • 実装
    • 空ページ作成
      • src/pages/xxx/index.tsx を作る感じ
    • マークアップ
      • 見た目はここで作る
    • ロジック
      • まだ API が実装されない場合は Mock を作る
      • 時間が開く場合は、手戻りのことも考慮していく
    • テスト
    • コードレビュー
  • 開発環境確認
    • バグ対応
  • 顧客フィードバック対応
  • API 結合テスト
    • API の疎通テスト
    • API に関わる部分の挙動確認
    • バグ対応と再確認
• 共通処理
  • 認証
  • メンテナンスモード
  • 汎用エラーハンドリング
• リーダー工数（開発とは別に確保しておかないと、リーダーがシぬ😇）
  • 状況把握
    • 各メンバーの進捗
    • 課題とその解決策
    • マイルストーン
      • リリースまでにどのタイミングで何が行われるか？
        • 必要な準備をする
  • 進捗確認＆報告
    • そのための資料作成
  • 各会議体の議題整理＆事前準備
    • 会議前
      • 議事録を作成
        • 会議中の議事録はメンバーに任せる
      • 会話する内容を整理
    • 会議後
      • 決定事項を必要な方に報告
      • 宿題の整理
      • 次回会議の準備を忘れないうちにやっておくと良い
  • 要件・仕様整理
  • チーム窓口
  • 実装フォロー
• その他
  • 朝会等のMTG
  • 開発ドキュメント等作成

仕様理解

• 見られるドキュメントは、すべて読んでおけ！！！知っていて損はなし
• とくに画面仕様や業務フローに関わるところは要チェケ
  • この画面仕様じゃあ業務フローできなくね？みたいなのに気がつけると、バグや後半の仕様変更を防げる

開発系

技術書や技術ブログになさそうな知見を書いてみる。

• フロントエンドアプリケーションが無事にデプロイできて、インターネットで見られる状態をなる早で作るべし
  • 職種的に知見が少ない場合も多いので、後半でバタつかないように早めに対応する
  • Next.js を使うなら AWS Amplify Hosting は強い味方になりそう
• デザインカンプにないことを、デザイナーは考慮できてないと思ったほうがいい
  • 答えを持っていないので、エンジニアから提案したほうがスムーズなケースは多い（実装コストもコントロールできる）
    • レスポンシブの挙動（タブレットサイズとか）
    • タップ（クリック）、マウスホバーしたときの挙動
    • インタラクション関連
      • ダイアログが開いている間は背景を固定したほうがいい？とか
        • 背景をタップしたらダイアログは閉じる？とか
    • API リクエスト中の表示
    • CSS トランジション・アニメーション
      • サンプルサイトをもらっておくと修正が少ない
• メンテナンスモードは確認しづらいので気をつけろ！
  • インフラレレベルでメンテナンス画面を返すようにするだけだと、クライアントルーティング中にメンテナンスモードになったときに困る可能性がある
  • メンテナンスモード画面をどうやって表示するか？
    • API のレスポンスが 503 ？
    • エラーコードがある？
    • HTMLリクエストはどうなる？
  • メンテナンスモードを起こすテストを計画しておく
• 認証に気をつけろ！
  • アクセストークンやリフレッシュトークンを使う場合、リフレッシュトークンによるアクセストークンの再取得処理みたいなのが必要になり、これがそこそこ大変なので実装イメージを持っておくと良し
    • アクセストークンの有効期限が切れても、APIを再リクエストできるか？みたいなテストはやっておくとよい
• アプリケーションで v1.0.0 -> v1.1.0 みたいな更新が入るとき、 SPA ではクライアントキャッシュで古いバージョンが利用され、 API とずれてしまい、最悪 DB が壊れるみたいなことがあるかもなので、気をつけろ！
  • バージョンが違う場合は、再読み込みを促すアラートを出すとか、強制的にリロードをさせるみたいな処理を検討する
• OpenAPI 定義ファイルが貰えても安心するな！
  • オプショナルな値を送信するタイミングとかは、型だけではわからない
• どのフェーズで誰がどんなテストを行うか？を把握しておく
  • ここをおろそかにすると、バグが増える
  • 最悪、バグがリリースされる
  • システム開発でよくあるテスト
    • 開発者テスト
    • API結合テスト
    • システムテスト
    • シナリオテスト
    • 受け入れテスト
• いきなり作り始めるのは難しいので、ある程度の指針やルール・設計、元となる開発環境を用意しておくとスムーズ
  • npm run dev で Next.js が立ち上がるくらいまでは作っておく
    • 最低限のライブラリは入れておく
  • ディレクトリ構造や命名規則をドキュメントにまとめ共有しておく
• 最初に決めた設計は、途中でイケてないと思ってもあまり変えないほうがいい
  • 複数の設計が交じるとコードがカオスになるので、イケてないとしても同じルールなっているほうが可読性は高い
    • イケてる設計を思いついたら、よほど余裕があるときか次のプロジェクトでためそう
      • 保守フェーズでのリファクタリングを提案するとかもいいね！
• 画面で表示するエラーメッセージをフロントで持つか？ or API のエラーメッセージを表示するか？は早めに整理しておけ
  • 誰に向けたエラーメッセージか？によってことなる
    • API 利用者に向けたメッセージであれば、サービスを利用するユーザーにそのまま表示するのは不適切なケースがある

チーム系

• チーム立ち上げ時、ドラッカー風エクササイズはやっておいたほうがいい
  • コミュニケーションが取りやすくなる
  • メンバーの特性がわかるので、タスクを振りやすくなる
• 朝会、振り返りをやりましょう
  • チームメンバーと1日1回は会話しておくと、異変に気がつける
  • 振り返りをしないと、課題が解決しづらい

リーダーの心得

• 開発メンバーが健やかに働ける環境を作れ！
  • その上で、締め切りまでに顧客が求める品質を担保したアプリケーションを作れ！
• 差し込みタスクが多いので、リーダーは計画的な実装タスクを持たないほうがいい
  • 「いつやってもいいけど、いつかはやらないといけない」みたいな実装タスクが向いてる
• 経験が浅いメンバーの状況確認を怠らない
  • かなりやばい状態にならないと、アラートは上がらないと思ったほうがいい
• 「最悪、誰もいなくなっても自分だけで作ることができる」くらいには把握しておくと安心
  • 逆に自分がいなくなっても回るように、各メンバーに共有しておくとより安心

開発前に確認したら幸せになれそうなものリスト

• 仕様
  • 対象ブラウザ
  • Figma 等のデザイン
  • 画面仕様
    • 各画面
    • エラー
    • メンテナンスモード
  • 画面遷移図
  • URL一覧
• 設計方針
  • コーディング規約があるか
    • 命名規則
    • スタイル設計
    • ディレクトリ構造
    • 状態管理
    • 型の書き方
    • Node.js バージョン
• 開発
  • SPA or MPA
  • ライブラリ選定
    • フレームワーク
      • SSG or SSR
    • 状態管理ライブラリ
    • API通信ライブラリ
    • スタイル用ライブラリ
      • リセットCSS
    • テスト用ライブラリ
    • UIカタログ
    • Lint & Formatter
  • コミットやプッシュ時の自動テスト・Lint・フォーマット設定
  • TypeScript の設定
  • Mock サーバー
  • BFF を検討しているか
• API
  • API 一覧
    • エラーコード一覧
  • OpenAPI 定義ファイル等で管理するか
• 認証
  • 認証の実装方法
• テスト
  • Unit Test, Snapshot Test, Integration Test, E2E Test, Monkey Testing 等どこまでやる想定か
    • 自動テスト以外のテストはあるか
• ソースコード管理
  • バージョン管理システム
  • ブランチモデル
• コードレビュー
  • プルリクエストのフォーマット
  • Issue や Projects などの機能も使う想定か
  • レビュー方法
    • レビュアー
    • サイドバーの Reviewers / Assignees / Labels 等の指定方針
    • マージルール
• デプロイ環境
  • インフラはどこを利用するか
    • SSR or SSG
  • 必要な環境
  • CI / CD
  • リリース手順
• アクセス解析
  • GA、GTM
  • イベント送信
  • 検証方法
• タスク管理
  • ツール
  • 運用方法
• その他
  • アクセシビリティ
  • パフォーマンス
  • SEO

おわりに

前述通り、ぼくの経験値に基づく、どちらかというとメモのような内容なので、あくまで参考適度にお使いください。

内容は、随時更新していくつもりですので、気が向いたときに覗いていただくと、新しい発見があるかもです。

大変なことも多いフロントエンド開発ですが、ともに乗り切り、楽しいフロントエンド開発ライフを送りましょう。

それでは、また。