プログラマは必要以上に自動化しようとする"べきだ"という話
(YOUTRUSTと内容は同じです)
プログラマの悪い癖として、なんでも自動化しようとして、人がやった方が安い&早いものまで自動化しようとするというのがあります。月に一回、1人・時でできる作業の自動化に3日(24時間)かけてしまったら、向こう2年は工数を回収できないことになります。
とはいえ事業がスケールしていくと人力作戦は事業規模に比例して工数がかかっていくので、いつかは自動化するべきであることは確かです。自動化は事業のスケール感と人件費に割ける予算などを総合的に加味して、適切なタイミングで行いましょう。
〜〜〜
といったことをよく耳にするし、これ自体は間違っていないと思う。
しかしながら、自動化のタイミングを逸してもはや取り返しの付かなくなった現場は多々あるし、自分の関わるプロダクトでもいくつか経験してきた。
上の議論で抜け落ちていることは、自動化された業務フローへのスイッチングコストである。コードは事業スケールに比例こそしないものの、事業規模が大きくなれば少なからずコード化の工数が増える。ミスの無いよう厳密に書かなければいけなくなるし、メンテナンスのためにクリーンにもしなければならない。セキュリティ等の問題もあるだろう。
そして、そのコストがどれくらいのものなのかは結局のところプログラマしかわからない。そこまで大きくなってからコードを書き始めても手遅れなので、今のうちに手をつけておく必要がありますよ、というアラートは、プログラマしか出せないと思っている。また、そのタイミングでプログラマの手が空いているかという話もある。
というわけで、プログラマは常に、業務フローのうち自動化できる部分やcode-friendlyなデータの持ち方にできる部分を探し続け、自分から提案し続けるべきだと思う。ビズサイドはテクノロジーで何ができて何ができないか、できるとしてもどれほどのコストがかかるかを分かっていない。それ故に、「手でできることが手でできるうちは手でやった方がいい、詰んできたら考える」という考えになる。会社として「手遅れ」にいち早く気づけるのはプログラマだ。だから、プログラマは常に、要求されている以上の自動化を提案すべきだ。
この記事が気に入ったらサポートをしてみませんか?