サービスのユーザー品質を上げるために、開発チームに必要なもの
こちらの記事にスラック(余裕)を設けることの大切さが描かれています。
あるとき、ひどい開発をしたことがあります。
寡少な人員と期間で、過大なタスクリストの消化を求められました。
結果的に徹夜や長時間労働でリリースまでには間に合いましたが、ユーザーの評判はひどいものでした。
要するに結果だけ見て酷い言い方をすれば大量のリソースを突っ込んで、ひどいガラクタを一生懸命作っていたわけです。
さてこの開発をして学んだことがあります。
ユーザー品質にかかわることはタスクリストには乗り切りません。動くものを見ないとわからないからです。そしてそれに最初気づくのは、動くプロダクトの最初のユーザーである開発者です。
ですので、通常の場合は開発者がタスクリストにない、ユーザー品質を上げる暗黙的なタスクを認識し、消化します。
ところが過密なスケジュールは余裕がなさすぎるため、「ユーザー品質を上げる暗黙的なタスク」よりも優先度の高い「タスクリストに記載されたタスク」を消化することに全力を傾注します。結果的にユーザー品質を上げる暗黙的でタスクリストに記載されていないタスクはほぼ未消化のままリリースされるため、ユーザー品質は低くなります。
これをビジネスサイドで認知できるのは、ユーザーの悪評や暗澹たるKPIの数字をもってのタイミングになります。
ユーザー品質を上げる方法は３つあります。
１つめは開発者にユーザー品質を改善する時間を与えること。
２つめは開発者にユーザー品質を改善するモチベーションを与えること。
３つめは開発者にユーザー品質を改善するために、リソースを効率的に使える情報を与えること。
せっかく苦労して作ってユーザーに使っていただけないのは非常に残念なことです。
なにしろどれだけ苦労しようと、開発リソースがほぼ無駄になるわけですから。
あの開発を契機に、ユーザーに使ってもらえる開発を重視するようになりました。
