【PL】新機能をリリースするまでのバックエンド・フロントエンドでの開発手順/PJ進行管理についてのまとめ

この記事は？

Web業界は個人主義が強い世界で、できるエンジニアだけ仕事が属人化することもある。一方会社での完全分業化が進み、かつ、リモート勤務が進んできたことで、自分がやっている分野以外よくわからないといった声を聞くことが多くなった(たとえば、フロントエンドしかわからない。とか、プロジェクト管理回りしかわからないなど)。著者はフロントエンド、バックエンド、PLそれぞれ現場で経験する機会に恵まれたので、この機を振り返って基礎を各分野にまとめてみた。

プロジェクトの進め方

・要件定義: ビジネスの優先順位に基づいて作る機能を定義する
・基本設計: 要件を満たすために必要なシステム仕様を決定する
・実装: 設計で考えた内容をもとに実際に手を動かして作っていく
・テスト/ QA: 品質保証を行い、世に出せるかどうかの検証と修正
・運用: 作ったシステムが止まらずに安定稼働させるように運用する

新機能開発 vs ゼロイチ開発

ゼロイチでの開発のようにインフラをゼロから構築したり、ゼロからアプリ構造を考える大きなアーキテクト的な話は少なめな一方、バックエンド・フロントエンド双方では機能を実装するために設計が必要。本記事では、主に新機能追加でのフロントエンド•バックエンド開発によリ沿う。

要件定義/ 基本設計

ビジネス的な要求から実装したい機能をビジネス陣とエンジニアで話し合い、まずはできるかどうか、できるならシステムとしてどう作っていくかを話し合うフェーズ。作るものの全体が見えればスケジュールをひき、実装フェーズに入っていく。

実装手順(バックエンド)

実装手順については言語やFWは違えど基本は大体の実装手順が似通っているように思うので、基本的な実装を想定して、噛み砕いてそれぞれ書いていきます。

・開発環境を構築する。大抵会社にはドキュメントがあるのでそれに従って構築していく。
・サーバーを起動する。まず、マイグレーションを行い、DBを最新にしたら次にDBを確認する。
・まずはModelを作成する。テーブルがなければ適切なデータ構造でテーブルを作成する。テーブルがある場合、新規追加するテーブルを特定してそこにカラムを加えていく。ユニークやNULL制約が必要な場合追加し、マイグレーションファイルを作成することで差分を管理する。
・次に、Controllerを作成しよう。特定のパスでAPIを叩いたときに走るメソッドの処理を定義し、おおまかな処理はController層に書き、詳細はService層で書く。
・DBとの接続が必要な場合、接続し、操作はORMやあるいは自分でSQLを書いて操作できる。確認にはMySQLならSequelAce、PostgreSQLならPGAdminが扱いやすい。
・パフォーマンス向上が期待できるなら、インデックスを貼ったり、SQLを検討し直したりする。
・ここまでうまくいかなかったら、デバッグなどを活用して原因特定しつつ実装を進める。
・次に、各層でのバリデーションやテストなどをそれぞれ書く。
・curlを叩いてAPIが叩けるか確認。作ったAPIを共有するためにAPIDocを書く。

実装手順(フロントエンド)

・デザインができているか確認し、改善が必要なところがあればデザイナーと連携して改善する。
・大体のUIと情報構造を確認し、どれくらい実装にかかりそうか、どこで開発すれば良いか特定。
・どんな状態管理が必要か？どのようなディレクトリ構造で開発すれば分かりやすいか。どんなライブラリを使えば良いか？パフォーマンスやセキュリティなど各方面最適な実装を考える。
・ある程度の粒度で切ってUIを作っていく。UIができたらそこに動きを加える。
・APIの型を定義し、画面からAPIが叩けるかどうか確認。叩けなければ、APIDocを見たりバックエンドのソースコード、(パラメタやURL指定など)を見て原因を確認。
・DevToolでAPIの結果、console.logなど活用して関心のある変数の値を見つつ進める。
・ビルドしエラーが出ないか？コンソールでWarningが出ていないかなど？確認。

プロジェクト進行

1ヶ月後に、確実にリリースしたい機能があるとする。その場合たとえば、2週間で実装、1週間でQA、残り1週間は見積誤差としてバッファをとるようにするなど考えられる。

・ロードマップで大枠を立て、各工程にかかりそうな時間をガントチャートで視覚化する。
・各タスクに優先度を振って優先度の高いものから終わらせるようにしていく。
・リリース日を意識する。いつまでにどのタスクを終わらせてマージする必要があるのか。
・リリースに間に合わない場合は、サポートを依頼したり、代案を練ったりする。
・Dev環境、Staging環境、Production環境の順にリリースしていく。Devは開発、Stagingは本番環境に似せて作った環境で、本番(Production)環境へのリリース前に不具合などがないかを調査。
・Staging環境ではQA(品質管理)を行う。致命的なバグは確実に潰さないとリリースが難しい。
・リリース手順は各会社のプラクティスに従う。例えば、バックエンド→フロントエンドの順にリリースすれば、フロントエンドを先に出してAPIがなかった場合のエラーを防げる。
・マージやリリースが終わった後は各メンバーに周知しておくことを忘れない。
・マージの途中でコンフリクトすることがあるので適度に対応する。コンフリクトしそうな場合は事前にメンバー間で共有したり共同で対応して解消できる。

インフラ(その他運用周り)

スピード感は大事だが目先の実装だけやるのではなく、中長期的に見て安全性や開発効率を高めるツールや、バグを減らしたり、バグ対応に活用できそうなものをやっていく。

・適宜総合テスト、負荷テスト、脆弱性診断などをおこなってアプリの安全性を高める。
・Dependabotなどをディレクトリに導入し、ライブラリを適切にアップデートする。
・GitHub Actionsを活用して自動でマージやデプロイができるようにしておく。
・IaCを活用して自動でリリースができるようにしておき、リリースの属人化を防ぐ。
・CloudWatch/ Sentryなどクラウドサービスでログを追跡しつつ、エラーなど緊急事態があった場合にエンジニアがすぐに原因を特定できるようにしておく。
・エラー通知、リリース結果などを適宜Slackと連携してすぐ確認できるように。

まとめ

分業制だとフロントエンド、バックエンド、インフラ、PL(リリースやスケジュールまわり)と別れがちで、リモートだと尚更他のメンバーが何をやっているのかわかりにくい。しかし本来技術に垣根はないはずで、分業制に関わらず技術とプロジェクト全体を見通せるようになっておきたい。