
開発速度が求められるスタートアップで培った、
リリースの間に合うように開発を上げる方法を共有します❗️

# 発注者との認識の差を埋める編
## 1. 機能単位で工数を出す

機能単位(1PR単位)で、
何時間かかるかを書き出します。
工数を出すとスケジュールを立てやすくなります。

例. 140h(開発に必要な工数) / 32h(かけられる工数/週) = 4~5週間

簡単な見積もり例↓
(感覚的に見積もっているので、実際に稼働した時間と比較して調整していきます)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/124461/f9e906b5-8964-4546-4c45-e50921e4bc67.png)

## 2. リリーススケジュールは悲観的パターンと楽観的パターンを用意する

早く終わるパターンと時間がかかってしまうパターンの2つのリリース日を設けます。
時間のかかってしまうパターンでは1.2~1.5倍くらい多めに時間を確保します。
リリース日は進捗状況によって変化しますよと伝えることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/124461/aa7e4f28-a719-a5e9-79be-83894386cb84.png)


いつまでにリリースできるかを説明する必要があるので、
クライアントがいたり投資家にリリース日を伝えなければならない時は、リリーススケジュールを立てられると便利です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/124461/518f11f9-60b2-c639-25ea-68a15c10aa88.png)


# 開発速度を上げる編

## 3. Biz側が確認しやすいように、機能開発用(ex. feature-develop)のブランチを切る

コミュニケーションコスト、チェックしてもらうまでの待機時間を減らすために
チェックをまとめて行うようにします。

機能専用のブランチ(feature-develop)を作成し、PRをmergeし、
どこかのタイミングでbiz側にチェックしてもらいましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/124461/846a5e8a-0bba-bf20-374f-fe4b9754992d.png)



## 4. 開発担当者にタスクを渡すときにはPR(下書き・インターフェース)を作成してから渡す

PR(コードの下書き・インターフェース)を作って渡すと、
担当開発者との仕様の認識のずれる対策ができるのと、開発者がすぐに実装を移ることができます。

これらの問題を解決するために、
PRを作って、期待するアウトプット、変更対象のファイルにマーキングしておくのがおすすめです。

### 5. 変更対象のファイルにマーキング
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/124461/a4c3f034-379f-33b1-e1d8-42c9e34a6748.png)

### 最終的なアウトプット
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/124461/93f56cbd-53a1-e656-e720-9aa6bd68adc7.png)



## 5. リリース後に実装でもいい機能を洗い出す

目的とずれている機能や設計途中でおまけで追加されたような機能は、
書き出してリリース後にまとめて着手します。

なるべく早くリリースすることを目指します。

## 6. コードレビューは行わない

コードレビューを行う時なるべくコードを提示するようにします。
それか、お互いの合意が取れていればレビュアーが修正してpushします。

pr上でコメントの往来があると、
とても時間がかかるので時には避けるのも一つの手です！


以上です！

発注者との認識の差を埋める編

1. 機能単位で工数を出す

続きを読むには単価診断を受けてください（30秒）