はじめに
こんにちは。「HR forecaster」というサービスの開発を行っている新卒2年目の讃岐です。
現在は、フロントエンドエンジニア兼スクラムリードを担当してます。
入社後、以下の3つのサービスで0→1の開発を経験しました。
・社外向け：「トレンド検索」・「トレンドランキング」の2つ
・社内向け：サービス1つ
これら3つのサービスは、いずれもリリースまでに4～6ヶ月規模で開発を行いました。
今回は、0→1のサービス開発における流れや、意識しているポイントについてお話しします。
（※開発の流れは、私が所属するチームでの事例です）
開発体制
開発はスクラムで進めており、フロントエンドとバックエンドの開発は別々のチームが担当しています。
その中でも、合計で5つのチームに分かれています。
私が所属しているチームでは以下の体制で開発を行いました。
・社外向けの「トレンド検索」・「トレンドランキング」：フロントエンドメンバー2~3人
・社内向けサービス：フロントエンドメンバー5~6人（うち、PCT社メンバーが3人）
PCT社とは、パーソルキャリアの海外開発拠点となる「PERSOL CAREER TECH STUDIO VIETNAM COMPANY LIMITED（パーソルキャリア テックスタジオ ベトナム）」です。
リリースまでの流れ
1. Figmaのラフデザインを見ながらタスク洗い出し、リリース可能日を算出
前提として、開発メンバーは、Figmaのラフデザイン（ワイヤーフレーム）がある程度完成した段階で本格的に参画することが多いです。
流れ
・スプレッドシートを使用してタスクを洗い出し、人日を算出
・フロントエンドチームの各メンバーがタスクに対し、楽観値・最頻値・悲観値を設定して見積もりを出し、概算を決定
・企画、デザイナー、バックエンドチームに共有してリリース予定日を決定
※楽観値・最頻値・悲観値とは
タスクの所要時間を見積もる際に使う3つの指標です。
・楽観値：最短で終わる場合の見積もり。
・最頻値：最も起こりやすい場合の見積もり。
・悲観値：問題が発生して最大限時間がかかる場合の見積もり。
目的
・ 各職種にフロントエンド実装完了時期を共有し、リリース予定日を決定するため
・企画側の想定リリース日に全機能が間に合わない場合、以下の対応策を検討する
・機能を1stリリース・2ndリリースに分割する
・メンバーを増員して対応
・リリース日を調整 etc.
・スケジュールから逆算して行動できるようにするため
・いつまでに各画面のデザイン・仕様が完成しておく必要があるか
・いつまでに受入テストを依頼しておく必要があるか etc.
ポイント
・1日5時間の開発時間を想定し、人日を算出する
・仕様やデザインが未知数な箇所は、少し大きめに見積もる
・技術負債解消や追加開発用の工数をスプリントごとに20％ほど確保しておく
・祝日や社内イベントを考慮し、スプリントごとに消化可能なポイントを見積もる
2. 機能別仕様書を作成
前提として、基本的にフロントエンドメンバーが機能別仕様書を記載しています。
※機能別仕様書とは
各機能の仕様を詳細に記載し、企画、デザイン、エンジニア間で認識を統一するための文書です。
例えば、画面遷移やUI構成、入力データの条件、出力結果、エラー処理、ユーザーシナリオなどを記載します。
流れ
・フロントエンドメンバーが機能別仕様書を記載
・企画やデザイナーと認識合わせを行い、仕様を確定
目的
・開発を円滑に進めるため
・仕様が決定しないと、デザインも完了せず開発の手戻りが発生する可能性がある
・デザイナーの負担を軽減し、後のデザイン修正を防ぐ
ポイント
・仕様書作成のタスクは、「仕様記入」と「レビューのフィードバック対応」で分ける
・他職能のレビューまでタスクに含むと、外部要因でタスクが完了するまでの遅延につながる可能性もあるため
・ 事前にレビュー依頼の予定を伝え、他職種のスケジュールを確保する
・質問管理表を作成し、質問と回答をまとめて見返しやすくする
・個別で送るとSlackだと流れていくので、埋もれて確認しづらくなる
・質問と回答をまとめておくと、後に誰でも内容を確認できる
3. APIの仕様策定
前提として、HR forecasterチームでは、スキーマ駆動開発を採用しています。
その中で、基本的にフロントエンドメンバーがAPIの仕様を記載しています。
スキーマ駆動開発については以下の記事に詳しく紹介されています。
流れ
・フロントエンドメンバーがAPI仕様を記載
・バックエンドチームを含むエンジニアにレビューを依頼
目的
・フロントエンドチームとバックエンドチームの認識を合わせるため
・フロントエンド側で利用するAPIの型生成、モックコードの生成を行うため
ポイント
・仕様書を作成した段階で、ざっくり必要なAPIをバックエンドチームに共有しておく
・OpenAPI実装前に、悩む点は気軽にバックエンドチームに相談する
・Figmaを確認しながら全体仕様をバックエンドチームに共有する会議を実施
・ OpenAPIのレビューコスト削減
・認識のズレがあるまま実装が進むのを防止
・バックエンドチーム視点での懸念点を事前に確認
・リリースに必要なAPI一覧をドキュメントにまとめ、明示的に共有
・フロントエンドチーム・バックエンドチーム間での認識のズレを防ぐ
4.実装
流れ
・フロントエンドチームで実装を進める
・各画面が完成したら、デザイナーにモックデータで受け入れテストを依頼
・受け入れテストで得たフィードバックを反映しながら改善
・バックエンドチームの開発が完了次第、結合テストおよび機能の受け入れテストを実施
目的
・都度デザインの受け入れテストを行うことで、リリース直前の修正を減らし、遅延リスクを低減するため
・機能の受け入れテストを通じて、リリース時の品質を担保するため
ポイント
・開発のタスクやプルリクエストは大きくなりすぎないよう分割する
・開発を滞りなく進めるため、できるだけレビュー優先する
・レビュー項目表を作成して、実装やレビュー漏れを防ぐ
・仕様が複雑な場合、仕組み化で対応し、個人の理解に依存しない
・デザインや機能の受け入れテストの時期を事前に共有し、実施者にスケジュールを確保してもらう
その他
・Figmaのmasterデータの更新漏れに対応
・開発側で気づいた場合は、コメントを残してデザイナーに通知
・デザイナーが全ての修正を把握・反映するのは難しいため、協力が必要
・masterデータを「正」として運用するため、最新化が必須
・機能別仕様書は適宜更新すべし、、
・新メンバーが加入した際、仕様と開発コードにズレがあると混乱を招くため、常に最新の状態を維持する
・また、既存メンバーも時間が経つと正しい仕様を忘れてしまう可能性があるため、仕様書を最新化しておくことで、チーム全体で正確な認識を共有できるようにする
・会議は事前準備して時間通りに終わらせるべし、、
・効率的に進行し、時間内で結論を出すことを心がける
※masterデータとは
デザイナーやエンジニアが参照する唯一の「正」となるデータのことを指します。
さいごに
サービスの規模やチームの状態に応じて、開発の進め方や工夫すべき点は変わると思います。
私たちのチームでは、現在も新規サービスの開発を進めており、状況に応じたベストな形を常に模索しています。
変わらず大事なことは、先を見通して行動すること・属人化させない仕組みを作っていくことかなと思います。
この記事が皆さんのサービス開発に少しでも役立てば幸いです。
最後まで読んでいただき、ありがとうございました。
讃岐 美奈実 Minami Sanuki
エンジニアリング統括 クライアントサービス開発部 HR_Forecasterエンジニア
2023年4月に新卒でパーソルキャリアへ入社。現在はHR forecasterの開発に従事。
※2024年12月現在の情報です。
