新しいサービスを急いで作ると、どこかに粗さが残る。それが当たり前だと、正直ずっと思っていた。on-board typingは、最初のコードを書いてから2週間足らずで、料金プランや権限管理まで含めた形になった。普通なら「急いで作った感」がどこかに残るはずだ。ふり返ってみると、実際にはそうならなかった。理由は、作業を早めたことそのものより、途中で進め方を変えたことにある。
最初は、衝突が起きるたびに個別に直していた
複数の機能を並行して作っていると、地味だけど厄介な事故が起きる。データベースのマイグレーション番号が、別々の作業でたまたま同じ番号にかぶってしまう、というやつだ。一度直したはずなのに、しばらくしてまた別の場所で同じ種類の衝突が起きた。そのたびに番号を採番し直し、CIのテストを直し、また次の衝突に備える。同じ失敗を3回繰り返したあたりで、さすがに「その場しのぎを続けても意味がない」と気づいた。
機能を作ったら、次は必ず「専門のレビュー」を1周走らせる
そこで進め方を変えた。新しい機能を作ったら、すぐ次の機能に進むのではなく、必ずどこかのタイミングでテーマを絞ったレビューを1本挟むようにした。セキュリティだけを見るレビュー、アクセシビリティだけを見るレビュー、初めて触る人の目線でのUXレビュー、コードの複雑さや拡張性だけを見るレビュー。それぞれ別の観点として独立させ、順番に回していった。
「作る」と「粗さを削る」を同じタイミングで同時にやろうとすると、どうしても粗さを削る方が後回しになる。それなら、削る作業をひとつの独立した工程として、機能を作るのと同じくらいの重みで扱えばいい。そう考えてからは、思いつきで直す場当たり的な修正が減り、代わりに「このテーマで一通り見る」というレビューが、開発の合間に何本も積み重なっていった。
結果として残ったもの
ふり返ってみると、最初のコードから12日ほどの間に290回近いコミットと114件のプルリクエストが積み上がっていた。その中には、セキュリティまわりの直しだけで十数件、テストに関わるものだけでも20件以上が含まれている。急いで作った機能の数と同じくらい、地味に固める作業の数も積み上がっていたことになる。
正直、最初は「動いているからいいか」と思いかけた
マイグレーション番号がぶつかった最初の1回は、直せば終わりだと思っていた。2回目が起きたときも、まだ「たまたま運が悪かった」くらいに考えていた。3回目が起きて、ようやく「これは運の問題ではなく、やり方の問題だ」と認められた。地味な仕組みの問題を、根性で乗り切ろうとしていた時間は、正直あまり誇れるものではない。
スピードを出すことと、粗さが残ることは、セットではなかった。ただし、それに気づくまでに、同じ失敗を3回繰り返す必要はあった。on-board typingを触ってもらうとき、機能の多さより先に、こういう地味な積み重ねの話も、どこかで知ってもらえたらうれしい。