「手作業で30分掛かるものを3秒で終わらせるために3時間掛ける」のは正解なのか？
いやまぁほぼそのまんまな内容で、元ネタも、以前にツイッターで拝見した
https://twitter.com/wakamesoba98/status/1020496602132180992
手作業で30分掛かるものを3秒で終わらせるために3時間掛けるのがエンジニア、という持論を大切にしていきたい
https://twitter.com/poyopoyochan/status/1021258011724079105
これ非難してる人がいてびっくりしたんだけど、6回実施で収支がほぼあって、7回目以降は使えば使うほど効率が高まることに気が付いてないらしい。
あたりのお話なんですが。
端的には「正解なケースもあれば誤りなケースもある」という、まぁ、身も蓋もないお話になります。
ただ、どちら側にも割とバイアスのかかりやすいケースかなぁ、と思うので、軽く。
とりあえず
・「作業」がある：作業
・手作業だと30分：手作業時間
・コード組んで自動化したら3秒：自動作業時間
・でも自動化するコードをくみ上げるのに3時間：コード作成時間
と仮定します。
また、上述のうち「自動作業時間」は「他でなにか別のことが出来る(と思う。3秒で何が出来るかはアナタ次第だｗ)」ので、ほぼ無視してよい時間だと思われるのですが、まぁ。
さてまず「自動化が圧倒的に正解」なのが
・「作業」が、毎日とか週1とか週2とか
・作業内容が定型なので、コード化が100%可能
・定型作業なので、そう簡単には変わらない
ようなケース。
このケースだと割とすぐに「作成コストがペイ出来る」ので、自動化しない理由が特に見当たらない感じですね。
まぁごく稀に*1「コンピュータは信用できない」とかいう御仁がいらっしゃるようですが、じゃぁ人間はそこまで信用できるのか？ と、小一時間。
さて、議論と考察はここから。
前提条件が少し変わってくると、当然ながら出力にも変動が見られます。
まず
・作業頻度が月1
とかの場合。さらには
・作業頻度が年1
とかの場合。
一端、前提条件だと「6回の作業でトントン、7回以上で自動化のメリットあり」になるのですが。半年、あるいは6年の間に「定型作業に全く変更がない、かどうか」が、鍵になってきます。
半年くらいならなんとかなりそうな気もしますが、6年だと、微妙な感じがしますねぇ。っつか「6年間、全く変わらない業務」ってのも……ありそうなんですが、同じくらい「なんだかんだ、毎回微妙に差異がある」ケースもあって、汎化しにくいように思われます。
でまぁ上述にかかってくるのですが。本来的には
・作業内容は、本当に不変か？
というのが出てきます。
細かく変更があったりする場合、変更に応じて、もしかすると「コードをメンテナンスする」必要があるために、コード作成時間が「3時間」ではなく、もうちょっと*2かかるようになります。
この「コードの修正時間」が積み重なると、結局は「トータルして、手作業のほうが早くない？」って突っ込みが入る可能性と危険性が懸念されたり危惧されたり。
さて。
この手の話題が出てくる時に、割とあるのが
・非エンジニアは「作成コスト」に神経質になる
・エンジニアは「手作業をすること」に神経質になる
傾向があるように思われますが、どんなもんでしょうか？
言い方を変えたり追加したりすると
・非エンジニアは「作成コスト」が気になるので、どちらかというと「手作業したほうが早いじゃんなんだよ30分の作業に３時間とか」ってお話になり
・エンジニアは「手作業」を忌避しがちなので「手作業とかありえないでしょ一度作れば以降ずっと同じ処理をほぼ一瞬で出来るのに毎回30分とか正気ですか？」ってお話になり
まぁここにいくつかスパイスとかポイントとか会員ランク( https://gallu.hatenadiary.jp/entry/2018/10/11/234610 )とかの変数が合わせ技になると、割といい感じでバトルになります。
で。いったん「To エンジニア」な発言をしましょう。
「手作業を忌み嫌う」気持ちがわからんではないのですが、「トータルコストとのバランス」を放置すると、あんまり良い顔をしてもらえない事も多いと思うのですねぇ。
で、そんなエンジニアには、こんなアドバイスと入れ知恵を。
まず
・「ある程度変わりそうな所」があったら「手作業と自動化のハイブリッド」でうまいことやる
ってあたりが、一つのポイント。
よくわからん仕様を「100%コード化」するのは、色々と難儀です。
なので「よくわからん、かつヌルヌルと仕様が揺れ動く所」は一端手作業にしてしまって、それ以外の「明らかに機械的な処理」から順次機械化していくです。
ゆっくりゆっくり、業務を侵食していけば、そのうち100%が機械の身体になる日だって、訪れようというものです。
次にもうちょっとえぐるような話をすると
・修正や追加がしやすい、キレイで素直なコードを書く
・少し丁寧に、コメントやドキュメントを残す
あたり。
そのコードを「誰かが引き継ぐ」事までを考えて、あんまりテクニカルにややこしい事はせず、素直にキレイに書いておくと、追加もメンテナンスも引き継ぎもしやすかろう、ってもんです。
こんな風にすると、これらのスキルって「普段の開発」でも普通に役に立つのではなかろうか、と。
で、ここで「非エンジニア」勢にお伝えしたいのが
・「自動化」は、上述のスキルを鍛え上げるために割と便利なので、「トントン」くらいなら、社内のエンジニアのスキルが磨かれるから、十分にメリットがある
って事。
「どこまでを教育コストとして飲むか？」ってのもあるのですが。
ちゃんと意識して書かせたりチェックしたり成果物の批評をしたりすれば、エンジニアのスキルが伸びる方向に行く可能性はとても高いので。
せっかくの機会ですし、単純に「目の前の成果物」だけではなくて、少し中長期的な視野とかを持ってみてもよいかと思うのですが、如何でしょうか？？
もう一つえぐると
・「業務のルーティンの見直し」になる
ってのも、案外と見逃せないポイントです。エンジニアの「厄介でうざい質問」って、見方を変えると「今まで何となく、適当に決まり事なく人によってばらばらに作業している」箇所だったりしませんかね？
そういった箇所を一端「他人の目で洗いなおす」ってのも、業務運用において、割と重要なんじゃないか、とかおもってみたりします。
でまぁその辺を考慮したうえで
・完全に手動がいいのか
・部分的に手動、部分的に自動がいいのか。その場合、どの部分を自動化するか
・完全に自動がいいのか
を、冷静に冷徹に、コストとメリットを天秤に載せながら考えてみるのも良いのではないか？ と思うのですが、どんなもんでしょうか？
