結局全部ここに帰ってくる
仕事の進め方について色々考えてきたけど、結局言いたいことは一つ。チームで価値の認識を揃えて、小さく作って早くフィードバックを得る。テストの種類もストーリーの切り方もAPI設計の順番も、全部そのための手段でしかない。
まず「価値」を定義する
何を作るにしても、最初に考えるのは「誰にとってのどんな価値なのか」。
デザイン検証のためにモックを作ることが価値なのか。機能として動くことが価値なのか。それを明確にする。価値の定義が曖昧なまま進めると、どんなにテスト書いても設計頑張っても「で、これ誰が嬉しいんだっけ？」ってなる。
価値が定義できたら、それをどう小さく分割して、どれを優先すると一番インパクトが大きいかを考える。簡単だけど難しい。
「確認できるまでの距離」を意識する
どこから実装を始めてもいいけど、早く動くものにして確認できる状態にするのが大事。
たとえばバリデーションを作るなら：
- UIから入る → ユーザーが「エラー出た」を確認できる
- 単体テストから入る → 「マイナスならエラー」がコードで確認できる
- API定義から入る → 定義だけだと振る舞いは確認しづらい。実装して、テスト書いて、やっと動きとして確認できる
どれも最終的にはやる。でも確認できるまでの距離が違う。API定義から入ると確認までのステップが多い分、「あ、この定義違った」ってなったときの手戻りが大きい。
API定義から入ること自体は悪くない。まずいのは、定義だけ作って満足して次に行くパターン。定義したらすぐに実装・結合テストで叩いて、動きとして確認するところまでセットでやる。
タスクの切り方はそこまで気にしなくていい
ストーリーとして、ユーザーや関係者が得られる価値に漏れがなければいい。それが実現できたら、タスクの粒度なんてなんでもいい。いや、なんでもいいは言いすぎか。でも粒度で悩んでる時間が一番もったいない。
ストーリーの中で「金額がマイナスならエラーにする」をタスクに入れるか、別タスクで追加するかは好きにすればいい。品質をどこまで担保するかはチームで合意していれば、細かいやり方は自由。
一番大事なのは、とにかくやり始めること。チームで「今こうなっていて、こう進める」って共通理解ができていれば、それでいい。
TDDは設計手法の記事でも書いたけど、TDDも結局この「小さく作って早く確認する」の具体的なやり方の一つ。テストを書くことで、確認できるまでの距離を短くしている。考え方は同じ。