雑多にまとめておく
MVPとかPocとか
InVisionやFigmaで作る。
それで、プロダクトのコアコンセプトのテスト、仮説検証できるところまでやる。
最初の文化
なぜこのサービスをやるのかを最初からチームで話す
すべてのタイミングで見直すようにする。
最初のチーム
メンバー
少人数でチームを作る。5〜6人くらいがMax。
人を増やして対応するのではなく、作業効率を上げること、やることの取捨選択によってチーム規模を維持する。
リリース後に余裕が出てきたら、改めてメンバー構成を考える。
QAメンバー
QAをメインで担当する人は最初からチームに入れる。
品質をどう作り上げていくかを最初からチームで考える。
テスト観点から仕様の漏れを突っ込む人
CI
最初からやる。 CIのパイプラインを作り、その後に最初のQAをする。
最初のリリース
なんでもいいからQAチームへ受け渡し確認してもらう。
Hello, World! だけ表示される何かだけでもよい
セキュリティ
最初からやる。 専門家がいるなら早めに相談。
評価
目標設定などはチーム全員でやる。 管理方法はなんでもいいけど、チーム全員でやるのが重要。
ユビキタス言語
scrapboxで管理が相性が良さそうと思いつつやってない。
ドメイン
ライブラリとか使わずにPOROとかPOJOみたいなもので作り上げる。
www2.slideshare.net
モノレポ
最初はまとめておく。
分割はあとで
DB
難しいが、DB分割は最初のほうでしっかりやっておく。
ツール群
お金使って便利なものを積極的に使う
IDEとか。
文化と暗黙知と属人性
属人性は排除していく。
ドキュメントで解決する部分としない部分がある。
解決しない部分として、根底に流れるコンセプトは一回書いただけでは浸透しないとかそういう部分。
これはちゃんと資料に起こしつつ、繰り返し事ある毎に言及し、文化として醸成していく。
暗黙知として知識ベースのものは、ちゃんとドキュメント化する
最初の一歩
仮説段階
開発者として考えることはドメインモデルの構築にどこまで時間を割けるか
プロトを作る工数に意外と時間が取られる その時間をドメインモデル構築に当てたほうが軸が定まってサービス開発がうまくいくのでは？という感触がある
読み切れていない資料
ドメイン関連が多い
