プロジェクト立ち上げの話（webサービス）

プロジェクト立ち上げのタイミングで参画したので、
最初に決めておくとよいものや心に留めておくとよさそうな事柄を順不同で記載。

・ブランチ戦略

自分が思っていた方法がセオリーの運用だと思っていたらそうじゃなかったこともある。
セオリーと異なる方法を選択する場合でもそうでなくとも、ドキュメント化しておくことで確実に混乱を避けられる。
また、git自体の運用も（例: developブランチに最新の変更をマージする）明確にすると良い。
今のプロジェクトではある程度走り出したら大きな機能（スクラムなのでスプリントが跨るようなものは大きい機能として判断している）は開発ブランチをきってそこに集約するようにしている。どこでバグが出たかわかりやすくなる。

・キャメルケースなのかスネークケースなのか

永遠の論争。フロントエンドとバックエンドで一貫性を保つ必要は私はないと思うが、
一定のルールはあったほうがよい。
後々気持ち悪くならない。
自分はキャメルケースで書くことが多いが本当に正解はわからない

・仕様書に漏れが多い場合が多い

立ち上げ時となると特に考えることが多く、
最初に仕様をあれこれと決めていても実装し始めてから仕様が固まっていない箇所があることに気づくことが多い。
見積もりは余裕をもって行ったほうが良い。
途中で仕様自体が変わることも多く、このあたりは立ち上げ特有な気がする。

・急いでいるときこそドキュメント（場合による）

立ち上げ時はバタバタしているので、
暗黙の了解のような仕様が生まれてしまうことがある。
そのままコードとして残っていると、
落ち着いたころ「なんでこれこうなっているんだっけ？」となりがちなのだ。
本当に切迫した状況であれば致し方ないが、暗黙の部分はなるべく文書化しておくと後々困らない。
絶対にリファクタは入るものなのだ

・モックサーバーが便利

stoplight/prismという、OpenAPIのyamlファイルからモックサーバーを作成できるアプリがある。
事前に定義ファイルに記載しておくとPreferヘッダーにステータスコードを指定すれば任意のレスポンス（例:404エラーなど）にもできるので、
バックエンドはこれを作成してから開発に移るとフロントとの連携がとりやすい。
開発時にバックエンドの開発を待つ必要もなくなる。
これは立ち上げに限った話ではないが、立ち上げ時はのんびりバックエンドの開発を待ってる間に他のことを、などということはまずできないため。

・リリーススケジュール

これは立ち上げに限らないことだが、
決まっていることが多いのに結構重い機能が直前まで共有されないまま唐突に来週リリース予定でと言われたりするので、
いつなんの機能をリリースするのか早めに確認をとって、
最悪納期を伸ばすか仕様を妥協するか決めたほうが良い。
共有ブランチにマージするときも事前にリリースする範囲がわかればrevertやらcherry pickやら面倒なことが減る。

・予定は未定になりがち

最初はリリースする予定だった機能を途中で取りやめたり、
確実に必要不可欠な仕様が抜け漏れていて追加で実装する必要があったりしがちで、
かなり予定がずれ込むことが多い。
想定していた機能の総数の半分ほどでリリースに踏み切ることも多いので、
仕様を決める人と開発は早い段階で認識をすり合わせないと残念なことになる。