要求の整理、実装からリリースまでの進め方をまとめました。「参考」にある本を読んだり、1on1 やチームメンバーの動きを見ていて気づいた学びを言語化しておきたいので綴ります。 ここで考えるのは着手する前提のものであって、そもそもの問題設定や問題同士の優先順位を考えることは、スコープ外にします。
※ これが最善ではなく、あくまで現時点でのスナップショットです。
具体的な進め方
問題を理解する（事前条件の整理）
- 要望を受け取る
- ユーザーストーリーと Whyを明確にする
要件の前には要望があるから、まずは要望から聴くとよい。まぁwhyから話してって話でユーザーストーリーをちゃんと書きましょうって話で、なんでユーザーストーリーをちゃんと書いてほしいのか？って説明するのは大事だよね。 #kichijojipm
— そーだい@初代ALF (@soudai1025) July 13, 2024
- 要望から要件を整理し、ステークホルダーとエンジニアで要件の合意をする
- 要望に対してエンジニアはそもそも実現可能か？より実現性の高い方法がないか？のすり合わせを行う
- 合意を得た要件から仕様を整理する
計画を立てる
- 仕様を元に実装方針を計画する
- 実装できる単位で分割する
実装する
- 実装方針をもとに実装を行う
振り返る
- 実装したものが要件を満たしているか確認する
- 事前条件が変わった時に正しく要件を満たすか（もしくはちゃんと満たさないか）も確認する
- 例. 正常系だけでなく、雨の日のユースケースが漏れていないか
- 受け入れテストを行う
補足
- 順番は大事。一番大事なのは「問題の理解」と「計画」だと思っている。逆にここさえ整理できればエンジニアのボールにできるので、あとはやるだけの状態に落とし込める。
- 先に実装方針に対してチームのレビューを通すことで、より良いプランを提案されたり、具体的な実装に対して認識が揃い、その後のレビューを通しやすくなるメリットがある。
- 事前条件の理解が浅い状態で実装を着手することは陥りやすいアンチパターン
- 人は具体的なことから着手しやすい（要出展）
- 要件が理解できていない状態で具体的にわかっている実装から着手すると、全体がぶれて手戻りが発生し、結果的にロスタイムが生まれる可能性がある
- 事前条件が足りず机上の空論で議論して先に進まない場合
- 具体的なものを見せることで前に進むことが多い。例えばPoCなどの叩きを作ってそれをベースに議論するなどが良い案だと思う。
