いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。

手作業の速度と自動化

»

自動化が早いとは限らない

一般的には手動作業より自動化した作業は早いと言われる。いろいろなところで自動化をやったことがあるが、手動作業の速度に敵わなかったことがある。一日でサーバを何十台もアップデートして再起動する作業だ。再起動する順番やフローがあるので、時間にして五時間くらいだったろうか。

手動作業で特別なツールを使っていた訳でもない。洗練された手順があった訳でもない。ただ彼らは慣れていた。人によっては信じられないかもしれないが、本番作業でもパラレルで五台くらいのサーバを同時に操作していた。何年も同じ作業をやっているので、手動作業でもミスが無いという実績を作っていた。

私が最初に作業を自動化したときに、これらのサーバを一台づつ順番に作業をするようにスクリプトを組んだ。そうしたら、時間が足りずに作業を終了できなかった。結局どうやったかというと、並列で処理が走るようにスクリプトを作成した。パラレルで処理を行うので、最後の出力結果をまとめるのが大変だった。もう、一本ソフトを書いているようなものだった。

並列で処理が走るようにスクリプトを改良して速度的には互角というところだった。自動化したということで、作業の労力は大幅に削減できた。手動で作業をしてた人曰く、速度が同じなので自動化しても大した差は無いとのことだった。確かにそうだが、彼らのような速度は誰にでも出せるものではないと思った。

自動化でどのくらい速度は上がるのか

作業を自動化したらどのくらい作業の速度は上がるのだろうか。いろいろなケースがあるので微妙なところだが、サーバ関連の作業を同じ順番で行うならせいぜいが1.5倍程度くらいだろう。サーバが処理を行っている時間自体が変わらないからだ。時間を縮める要素は、確認をしている時間や手で操作している速度になる。

この時間を縮める要素というのが、実は熟練でカバーできてしまう。スクリプト処理の途中でチェックを入れて指さし確認している時間を熟練者は直感で高速で済ませてしまうからだ。スクリプトで時間を短縮できる要素は熟練でも短縮できてしまう。労力に関しても、人それぞれで感じ方が違うので、軽くなるとは一概にも言えない。

自動化で速度を上げるとすれば、同時にいくつ処理を実行できるかにかかってくる。本番作業でそれをやるかは別問題として、ベテランが同時に実行できる作業の数は大体が五つ程度だ。処理を自動化すれば、この制限を簡単に、かつ安全に突破できる。自動化で速度を上げるとしたら、いくつの作業を同時にできるかにかかってくる。

自動化と言えば、単にbatファイルを書いてポチポチやる程度のものから、高価なツールを使用するものまで様々だ。実のところ、処理の高速化を謳う自動化ツールはあまりない。意外ではあるが、作業時間だけなら根性で何とかなってしまうので、自動化の特権という訳ではない。可能ならば、手段よりもフローを見直した方が作業の時間短縮には有効だ。

作業にスピードが求められる状況

本来であれば、作業時間の短縮というのは個人の努力ではなく、仕組みで解決すべき問題だ。一度にたくさんの作業をするほど、トラブルを起こした時のリスクは高くなる。作業自体の難易度も高くなる。短時間で多くの作業をしなければならないということは、全体の仕組みに何らかの欠陥があるからかトラブルを起こした時だ。

トラブルの際のオペレーションは、よほど高度にシステム化されているところでもない限り、手動の作業が中心になる。手動作業というのは、何かあった際に融通が利くという利点がある。例外処理にも強い。ただし、障害時の対応時間に差が出るのは事前準備やフローだ。自動化か手作業かではない。

問題なのは、全体の仕組みに欠陥を抱えている場合だ。自動化で対応しようと、手作業で対応しようと、頑張れば頑張るほど欠陥を抱えた形になじんでしまう。正しい形に戻す時に非常に苦労する。変に作業時間短縮をクリアしようと考えるより、時間短縮をしなくて済む方法を考えよう。

普通に考えて、時間短縮が求められる状況は非常事態だ。自動化というのは、どちらかといえば非常事態の手段というより普段の作業でとるべきアプローチだ。自動化にスピードを求めるということ自体、考え方にズレがあるのかもしれない。というのが自動化にスピードを追求してみた感想だ。

自動化の実際

自動化というのは思うほど万能ではない。自動化しすぎるとどうしても仕組みが複雑になって、変更への対応がやりにくくなったりする。よく自動化した後で思うのが、「こんなに複雑にする必要はあったのか?」という疑問だ。こんな複雑なスクリプトを書かなくても、もっと上手いアプローチがあったのではないかと悩むことはよくある。

また、どうしても自動化の方が手作業より優れていると思い込むと思わぬ落とし穴にはまる。簡単な話で、手動で作業できないものを自動化することは不可能なのだ。効率の悪いフローを自動化しても、仕組みだけが無駄に複雑になる。作業ミスが生じる要素を抱えたまま自動化すると、間違えた時の被害が逆に大きくなる。

自動化したとしても、トラブルが起きたら手動で対応せざるを得なくなる。結局、自動化と手動の手順はセットで考えていく必要がある。手動で効率良く作業できない人が、自動化で効率を上げることはできない。できたとしたら、人の作った自動化の仕組みを利用して恩恵を得ることだ。

Excelのような演算処理の自動化は劇的な差が出る。一般的に自動化でイメージされる速度はこちらだろう。しかし、サーバの再起動、バックアップ等の作業は処理する時間が長いのであまり効果が実感できない。自動化の速度は体感速度に頼らず、きちんとストップウォッチで時間を計って判断しよう。

Comment(3)

コメント

user-key.

「自動化にスピードを求める」数字しか見なくなってくるとこの考えが強くなっていく様に思います。
私は、自動化の利点は再現性の高さに有ると思っています。
製造業の端くれとして、普段の作業の無理・無駄・ムラを徹底的に無くしてから自動化を行えば劇的に変わります。
この辺はIE(industrial engineering)に絡んできます。

Anubis

> user-key. さん
ご指摘の通り、数字という「時間」に絞って書いてみました。
私も自動化の利点は再現性の高さにあると思います。あとは、Logを残せることでしょうか。

やってみると分かりますが、意外と細かいところを拾うのに時間がかかるんですよね。

ここら辺も考慮に入れると、トータルの時間は手動でやるよりかかることが多い。
何故自動化するかという目的を考えるきっかけになればいいかと思い、このコラムを書きました。

自動化の仕組みを設計・実装させてみるとエンジニアの資質が測れそうな気がした。
実装コスト、稼働コスト、環境構築やツール選定、いろんな要素からどんなベターな解を導き出すか面白そうだ。

コメントを投稿する