最近実践した開発プロセスで気づいたことがある。
所属している会社特有なのかわからないが、ないと困る、以外の機能も最初のスコープに入れがちだなーって最近思う。
「小さく作る」って言葉はよく聞くが、実際その「小さい」を他に言語化するとどうなるのか、あまり自分自身もできていなかった。
たとえば一覧画面を作りなさい、ってなった時も、最初から「検索機能」や「ソート機能」を含めて一覧画面を開発するのは、果たして「小さく作る」に該当するか？多分違うと思うんだけど、でも一概には言えない気もする。
ある体験を提供するときに、検索機能がないと、あまりにも不便だ、とかそういうことがあるかもしれない。
そこで「小さく作る」をもう少し考えてみると、
価値のある体験自体を提供できない、を避けるために何が必要か
を考えることになるのかなーって最近自分の中で違う言語化ができた。
つまり何が最小単位かを考える際は「これがないと一番提供したい体験が提供できないか？」を自問自答すれば良さそう。
僕は実務で Software Engineer in Test って肩書きで一応業務をこなしている。開発のプロセスを改善したり、テストの自動化やテストコードの教育なども同時に行っている。どうしたらテスト書きやすいコードを書けるようになるか、などの設計の段階から関わることもある。
そんな立場なので、上記で言語化した考えをある機能の開発プロジェクトに適用してプロセスを組んでみることにした。すると、以前から続いていたリリース前日までに開発が終わらずバグも多数出てしまう、という状況から脱却できた。
一番提供したい機能を優先して余分なものは削ぎ落として提供するので、バグは出たとしても早い段階で検出されるし、関係各所に動くものを見せることができるので、フィードバックも早くもらえる。もちろん、機能が足りない状態ではあるので、そこは優先順位を考慮して進める必要はある。
それだけではなく、その開発に関わる人たちにも幸せになってもらえた。
以前は QA や開発が残業するのが当たり前になっていた。しかし、この QA も開発も誰も残業することなく、リリースの一週間前にはほぼほぼ QA の検証まで完了していた。もちろん以前と比較することが適切かはわからない。実装の難易度も違うし、関わる人も違う。
ただ、プロセスを変えるだけで、関わる人たちが幸せになれることがあるんだなー、とは感じた。こういうのを見ていると、プロセスというか仕事の進め方を工夫することの大切さを実感する。
最近『自分の仕事をつくる』という本を読んでいる。モノが出来上がるまでのプロセスは本当に人によって違う。魂込めてモノを作る人たちはみんな、プロセスを大切にしていた。