新しくウェブ系のシステムを開発するときにやったことがいいことを書いておきます。コードを書くスキルとはちょっと別なのでこういうのは経験がないと身につかないけど超重要です。
1. システム構成図を描く
どんなシステムがあってどんな流れで処理が進むのかを絵に描く。かっちょいい設計書じゃなくてもいい。手書きの雑なやつでもいい。一個一個の処理に「〇〇君」のような名前を付けていくといい。「JSON書き出し君」みたいな感じ。
2. 誰が何をやるかを明確に
タスクを洗い出すだけではなく、誰がどこまでやるかを明確にする。1で描いた絵に担当をアサインしていくと漏れがない。
3. リリース日を決める
リリース日を決めずに開発を始めるとパリッとしない。リリース日を決めて、アプリの申請、 QA の予定などを埋めていくと、何日までに開発を終わらせておかなければならないかが逆算的にわかる。間に合わなそうであればリリース日を動かして調整する。
4. 確認環境・デモ環境を作る
ローカルではなく、本番と似た環境で動作確認できる環境をまず作る。ローカルで動いたけど本番で動かないをなくす。本番サイトを非公開にできるならリリース前からガンガンデプロイしてもいい。CSSが当たってなかったり、APIがモックでもいい。動くものを関係者間で共有し、早い段階でイメージのズレを補正することが超重要。
CI/CD の仕組みまで初期に整えておけるとなおいい。
5. リスクの高いところから開発する
システムの処理の中で重要かつ難易度が高い、もしくは実現できるかわからない（不確実性が高い）部分から開発する。簡単なところから先にやって不確実性（リスク）の解消を先送りにするのは超危険。
6. APIのJSONのフォーマットを先に決める
こうしておくことでバックエンドとフロントエンドがパラレルで開発できるようになる。誰かの作業が進まないと他の人の作業が進まないというような依存関係を作らない。
7. コードはこまめにリポジトリにプッシュ
他の人が作業状況をわかるようにする。小さくプルリクエストを作ってマージしていくとかは今更言わなくても常識ですよね？
8. 朝会か夕会をやる
超ラフにコミュニケーションしてお互いの進捗を共有する。可能ならオフラインで話す。一緒に寿司を食べるのも効果的。
↑は作るものが決まってからの話なので、作るものが合ってるか（正しいか）はまた別の話（プロダクトマネジメント）。
