Feedback Loop

何かつくるとき、最初は伸び伸び自由に作り始める。思い描いたイメージに向かって手を動かし、3-4割くらいまではあっという間。この時間は本当に楽しく、この勢いで完成まで一気に行ってしまうような気もする。

完成度が半分を超えると、進みが少しずつ鈍くなっていることに気づく。それは後に回してきた複雑な機能の実装であったり既存の実装への影響の考慮であったりするが、考えることが増えて手を動かしてばかりではいられなくなる。8割くらいまでくると詳細を詰めたり不具合を直したりで中々前に進まない。当初の想定より時間がかかって焦ったりもするが、ここは辛抱強く乗り切らなければいけない。

登山道には「何合目」という目安が設置されている。標高が高くなるにつれて一合目、二合目と増えていき、山頂が十合目。普通に考えると距離や標高を按分して計算しそうなものだが、そうではなく「体感のしんどさ」で10分割されているらしい。急な坂があるところだと合目の感覚は狭くなる。ものづくりの進捗にも近しいことが言えそうだ。

進みが悪くなったとき、まずはやるべきことを書き出す。思いついたところから着手していると広範囲を同時に相手にすることになりスイッチングコストが高くて疲弊する。まずはここ、次はここというように一つずつ終わらす。基本的には重要な部分から終わらすのが良いが、数が多すぎる場合は細かいものに先に着手して数を減らす。「あれもこれもやらないと」と考えているだけで脳の何パーセントかを使ってしまう。まずは細かいものをバタバタと終わらせ、余白ができた状態で本丸を相手にするのが得策だ。

Webサービスはリリースして終わりではなく、そこからが始まり。リリース後は機能開発とユーザーの声に応えるのと2軸を両方やらないといけない。ギリギリなんとか動く状態で完成させるのではなく、ソースコードや仕様を整理して長く走り続けられるのが見えている状態で世に出したい。Facebookのザッカーバーグが言った「完璧を目指すよりまず終わらせろ」は品質ではなくスコープのこと。リッチすぎる機能は最初から必要ないが、改善を載せていけるだけの土壌は最初から用意しておきたい。