はじめに
スタートアップ(自社開発サービス)での開発風景を記事にしたものです。
※これが正解というものではありません。
目次
Issueの取り方
Issueは重要度が高いものをとることになります。
重要度において顧客満足度を上げるものが最重要になります。
そのIssueをやることで顧客が満足してくれる->ユーザーの定着、増加を促す->金になる
時間とはお金です。その時間をどのように使うかを考えた時にサービスがより儲かることを考えてIssueに取り組まねばならないです。
ユーザーが求めていない機能追加よりも小さなバグを治すだけでユーザーは喜ぶということが往々にしてあるのでもし自分がユーザーだったらを考えて重要度を判断する必要がある。
大体は上長やリーダーに任されたIssueをやれば問題ないが自身でIssueを立ててやる場合は一度他の人に重要度を客観的に見てもらってアサインする
いいIssue
テンプレ
その1(機能追加ver)
## 概要
<!-- 例：メールアドレスログイン機能を作成 -->
## 目的
<!-- 例：システムにメールアドレスでもログインできるようにするため -->
## やること
<!-- 例：
- デザイン追加
- メールアドレスのログイン機能実装 -->
その2(バグ対応ver)
## ⚙ 発生している問題・現象
## 🔨 期待する挙動
## 🖥 再現手段
## 📸 スクリーンショット
- 概要がざっくりしすぎてあとから見返したり他の人に初見でわからないような記述の仕方は避ける
- 複雑なIssueにアサインするときはこの方向性であっていますかと確認を取るとよい
=>最初の方向性やIssueの思惑を勘違いするとその時点で差し戻しが確定する
いいプルリク
テンプレ
## 🖇 関連Issue
<!-- GitHub Issueのリンク -->
## 🎂 やったこと
## ⛔ やってないこと
## 💡 確認したこと
## 🏃♂️ その他
レビュワーに負担をかけない
- テーブル形式で「やったこと」に画像を載せてぱっと見でどんな変更があったかわかるようにする
| 変更前 | 変更後 |
|---|---|
| 画像1 | 画像2 |
- Issueと関係ないところはコードを変更しない
=>変更する際は事前に変えてもよいか上長などレビュワーに了解を取る
ついここもリファクタリングできるからしてしまおうで変更ファイル数が大量になりレビューが大変になって最悪差し戻しになる可能性もあるので事前に確認を取る
変更箇所の大量増加が見込まれる場合は別でIssueを立てる - 変更処理で何かファイルを追加したり関数を追加する際にどんな目的で変えたかを書いておくとよい
※レビュワーの時間を取らないのも大事だがIssueが進まないほうが問題なので100%完成していないくても適宜進捗報告や実装に詰まった時は聞こう
おわりに
会社というのは基本的に営利企業であって限られた資源(時間、資金、人材)の中でより多く稼ぐことが目的になります。夢だけ追いかけてあれやりたいでビジネスを無視すればサ終(スタートアップだと破産か倒産)するのがオチなのでそのあたりを理解して開発しよう(自身への戒め)
まとめ
- ビジネス視点を持ってIssueに取り組もう
- レビュワーの時間を取らない(負担をかけない)