Feedback Loop

作ってリリースするまでは良いが、リリースすると次はそのメンテが始まる。初期の頃にユーザーがついてくれるのは本当にありがたいことだが、要望やフィードバックを受けての改善と新機能開発の2つのレーンを進めることになるので忙しくはなる。初期の頃はスピード重視。要望に応え、不具合をすぐ治し、新しい機能をリリースすることでワクワクしてもらう。サービスを気に入ってくれる人が増えればクチコミが広がる。こうして初期のポジティブなサイクルが周りはじめるが、スピードを重視するあまり品質があまりに下がると大ブレーキがかかってしまう。

同じ作業をしていても、リリース後はリリース前よりかなりスピードが落ちる。これは既存ユーザーへの影響を考える必要があるため。リリース前なら自分たちしか使ってないのでデータをいつでもリセットできるが、既存ユーザーに変更を案内する大変さを考えるとこれまで通りで動くように上手い仕様を考えたくなる。こうして考えられた仕様はすこし変化球となるため開発も時間がかかる。リリース前のテストもより入念に行う必要がある。思わぬ影響でサービスが止まってしまってはいけないからだ。

バグが溢れ始めると負のサイクルが始まる。見通しの悪いコードベースではどこになんの処理があるかわからない。目の前の不具合を治すと別の箇所で3つの不具合が出る。しかしそれには気づけずリリースし、ユーザーからのフィードバックで気づいて慌てて直す。ユーザーからの信頼はすり減る。開発チームは徒労感を覚え、またバグをリリースしてしまうのではないかと自分たちのサービスに自信を失くす。組織の持つ大きな目標になかなか近づけず、ただ毎日タスクに追われる日々となってしまう。

こんな事態を防ぐためにも、リリース前、せめてサービスが本格的に成長する前に安心のガードレールを作っておきたい。ソフトウェア開発におけるガードレールとはテストコードのことで、いろいろな角度や粒度でプロダクトを検証することでバグを未然に防ぐことを目的とする。例えばカレンダーの日付のロジック。「日曜24時」というのは日曜なのか月曜なのか間違えやすい。テストコードを書くことで期待する動作がどういうものか、これはどういう意図で実装しているかを後世に残すことができる。人間がチェックするのと同じようにボタンを順番にクリックし、期待する文字列が画面に表示されているかを確認するテストもある（UIテスト）。これはより実際の環境に近いところで確認できるためユーザーと近い目線でバグを見つけやすい。ただし画面からボタンを探してクリックするような処理は複雑で壊れやすく、原因不明でテストが失敗することもあり管理が難しい。AIが更なる進化を遂げ、「画面の更新ボタンを押すとラベルの色が変わること」などと日本語で書いておけばいい感じにテストしてくれるような未来に期待している。安心してリリースでき、楽しい部分である機能実装に集中できる世界がうれしい。