ネットの海の片隅で

技術ネタの放流、あるいは不法投棄。

スピード感のために品質を落とすということはチームの成長を諦めるということ

サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。

そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。

ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。

ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。

しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。

技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとしてもその人の技術力以上の品質のコードは書けない。

では、品質と速度についてのトレードオフが意識されるとき、実際には何と何が秤にかけられているのか。

それは各個人ではなくプロダクト全体の品質と速度が秤にかけられているのではないか。 言い換えれば、プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているのではないかと思う。

先述の通り、個々人の速度は品質を上下させたところで大きくは変えられない。 しかし、レビューの工数を削減したり受けたフィードバックを反映する時間を削ったりすれば、PR をマージするまでの時間は大きく短縮できる。そして、結果として短期的な開発速度は向上する。

一方でレビューやフィードバックの時間やそれらを実際に適用してみるために考えて手を動かす時間を削ると、メンバー同士がお互いを高めあっていくことができなくなる。 すると、プロダクト全体の品質はいつまでたっても上がらず、チームも成長しないままになる。

現実世界はつらくきびしいので、チームの成長のために無限に時間を使うことはできない。しかし、価値を素早く届けるためには、それを可能にするチームを作っていくことも間違いなく必要なのではないか。 そんなお話。