「はやくつくる」のに必要だなと思ったこと、とりあえず 4つ。

ぼくは今、とある新規プロダクトの立ち上げを担当させてもらっている。といっても、ぼくは、プロデューサーとかではなく「アプリケーションエンジニア」なので、やることといえば普段と変わらず、「プログラミング・プログラムを書くこと」だ。

ふと振り返ると、全くの新しいプロダクトの開発に、こうして直接携わるというのは、2年ちょっとぶり（今の職場では初めて）だな、ということに気づく。前回のは「社運を掛けたプロダクトを」「自分がリーダーで」、といった開発だったけど、今回は「既存プロダクトとのシナジーを産み出すようなプロダクトを」「いちエンジニアとして」開発してる。

前回と今回、自分の立場も違えばプロダクトの毛色も異なったものであるが、どちらにおいても変わらず求められ、また僕自身もその必要性も肌で感じていることが、「はやくつくる」ということ。

今までの（とはいえ短い）キャリア全てを振り返ると何度かやってきているわけだけど、「これがこうなら、もうちょっとはやくつくれるのに」と思うことで重なる部分も出でてきたように思うので、今回はそれをメモってみる。

「今見えている将来」を都度共有した上で、「できるだけつくらない」。

「できるだけつくらない」。つくるものの絶対量が減れば、「つくれた！」と高らかに宣言できる日もよりはやくなる、というのは、ズルいようだけど当たり前のはなし。

とはいえ、将来的に必ず必要になってくるようなものがその時点でわかっているなら、少なくともそれは組み込みやすい形でつくっていく必要がある。でないと、たとえ 1st リリースがはやく遂げられたとしても、2nd リリース、3rd リリースで入ってくるようなものが組み込みにくい形であったなら、結局トータルで見ると「おそい」、となってしまう。

できるだけつくらない。とはいえ、「今見えている、将来的に必ず入ってくるもの」は入れやすいようにしておく。気をつけなければならないのは、「今見えている将来」は、立場によって違うものが見えている、絶対に。なので、「今、それぞれから見えている将来」を、都度共有することも大事。もちろん、その上で「今はつくりません」ということについて合意を得て、チームとしての意思決定に昇華させることも。

正解がない・まだわからないことはとりあえず決めちゃう

「こういう機能が必要になるかもしれないし、不要なままかもしれない」、なんてことはもう、いくらでもある。無限にあると言ったって差し支えないくらい。でも、つくるにしろ、つくらないにしろ、そこを決めなければ、「つくりおわった！」という状態にはならない。決めないと、「で、どうするの？」という、「はやくつくらなければならないプロダクトなのに待ちの状態が発生している」という、ワケの分からない状況にすらなりうる。なので、「決める」ことが肝要。

肝要、なんだけど、上述の「できるだけつくらない」を踏まえるのも......、、って、もうまだるっこしいからぶっちゃけるけど、「つくらないことを決める」のが大事だったし、大事にしてほしい。要不要にかかわらず「つくる」ことが好きな人もいるかもしれないけど、ぼくは、必要なものしかつくりたくない。

テストはむしろ書きながらの方がトータルで速い

これは結構人によるところが大きいのかもだけど。

たとえ正常系ケースだけだとしても、ぱーっと書いたものが特に問題なく動くようなものを書ける人は、「今はテストを書かない」という判断をするのはアリだと思う。でも、そうじゃないのであれば、「書けた！」というところからがスタート（書けたものをあれこれ動かしてみて間違いを潰す、という作業がある）、という感じになってしまう。そうなると、トータルで見ると結局より多くの時間を掛けることになった、みたいなことも全然あり得るので、テストは書きながら・間違いは即座につぶしながらの方がいい。