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

自動化よりまともに仕事ができるようにしよう

»

■自動化できるかできないかのポイント

 自動化ができるかできないか。これを見極める簡単なポイントがある。まず、自動化が実現されるプロセスを考えてみよう。まず、自動化する対象の業務が整理されているだろうか。手作業でやっても円滑に業務ができるかということだ。

 対象の業務を整理せずに自動化を推し進めると、仕組みが複雑になり過ぎて破綻する。そもそもな話で、整理もされてない業務が自動処理できるというのも、都合が良すぎる話だ。まず業務を整理して安定して行えるようにしよう。自動化の話はその後だ。

 自動化をしたいという要件は多く聞く。しかし、業務の手順を頑なに変えようとしない。こういうケースでは、業務が属人化している、例外処理が発生しやすい、フロー自体が整理されていない等、自動化以前の問題を多く孕んでいたりする。エンジニアではなく、業務に携わる人たちで解決すべき問題だ。

 自動化で改善だ!という前に、まず業務を整理しよう。元の業務効率が悪いは、業務に携わる人の効率が悪いからだ。技術で解決できることなんて、意外と限定的な範囲に限られる。自分たちで解決すべき問題をエンジニアに丸投げしても、しわ寄せでエンジニアが悲鳴をあげるだけだ。

■自動化が実現するステップ

 自動化が実現するには、フローが確定している必要がある。そして、簡単な作業から自動化していくのが望ましい。自動化がうまくいかない現場は、だいたいこのステップを踏み外している。いきなり難しい部分に挑んで延々と悩み続ける。

 簡単な作業を自動化しようとすると、「そんなのをわざわざ自動化するより、手でやった方が早い」と言われる。確かに、それを自動化したところで節約できる時間は数十秒だ。費用対効果云々を力説される。

 だが、簡単な作業の自動化の積み重ねは馬鹿にならない。節約できる数十秒を積み重ねると、数十分が節約できる。また、一度自動化すると、別パターンが出た時に整理しやすい。小さな自動化は、フローの整理にも役に立つ。

 自動化の基本は、簡単にできる小さな事から実現していく事だと考えている。小さなステップを整理できなければ、到底、大きな流れを整理できる訳がない。地道に取り組むと、意外と簡単に実現してしまったりする。

■自動化は新陳代謝する

 これは多くの人が持つ誤解だが、自動化は常にやり直す必要がある。一度、自動化してしまうと、これを永久に使いたがる。そして、自動化した仕組みを忘却してしまい、メンテナンス不能になる。自動化を実現したはずが、技術負債になってしまうのだ。

 自動化は一度やったら終わりではない。そこからが始まりだ。自動化の仕組みがどんなに完成していても、世の中は動く。それに伴って、業務内容も動く。どんなに完成した仕組みでも、時間の流れに伴って相対的に陳腐化してしまう。

 相対的に陳腐化しないためにはメンテナンスが必要だ。自動車や工場の設備、建築物に関しては、こういうメンテナンスの考え方は行き届いている。しかし、コンピュータに関しては、かなり抜けているように思える。

 また、自動化の範囲を広げると、今まで使っていたスクリプトが使えなくなることもある。今あるコードを無理に再利用するより、潔く書き直す勇気も必要だ。古いコードを無理に再利用するためのコストもバカにならない。書き直す際に、どれだけ業務が整理されているかで大きく差がでてくる。

■コーディング力より観察力

 あとは、自動化というとコーディング力が問われそうな気がするが、意外とそうでもない。コーディング力より、業務への観察力が問われる。言われた通りの手順をそのままコーディングしても、無駄な作業がそのまま盛り込まれてショボい事態になってしまう。

 そもそも、コーディングするにしても何をコーディングするか見定めないと動けなくなるだろう。コーディングの対象を見極めるには、観察力を鍛えるのが最短だと思う。対象が何なのかを深く見抜く力だ。

 自動化を行わなくても、観察力が優れていれば業務の効率化は可能だ。むしろ、自動化はおまけくらいだと思っている。コードを書いて役に立つのは、どうすれば最短で最高の効果がだせるか、方針が明確な場合だ。

 そんなことで、エンジニアが観察力を鍛えたらかなり強いのではないだろうか。コーディング力や専門知識を深めるのもいいが、それだけが強みになる訳ではない。まぁ、難しいことばかり言うのもなんだ。「観察力大事!」くらいにいろいろ考えてみると、今までと違った回答が浮かんだりするんじゃないだろうか。

Comment(2)

コメント

宗元 繁徳

夢の計画書に基ずく具現化の設計図を作成したい

何でも屋

>フロー自体が整理されていない等、自動化以前の問題を多く孕んでいたりする。
>エンジニアではなく、業務に携わる人たちで解決すべき問題だ。

言ってることは間違ってもないが、こう言い切っちゃうのはどうかな?
よく、客のせい、SEのせいにして悦に入ってるエンジニアもどきに多い考え方だと思うわ。

業務に携わっている人間が、システムのプロっていうわけでもない。
システムが分からないから、今まで実績のあるやり方に頼るわけで、そこを理解
してあげないと(客でもあるわけだし)。
お互いがお前がやれって言っているうちに、わけのわからんシステムが出来上がる。
お互いバカwww

客の業務を理解しどのように解決できるかを提案、顧客を誘導してやるのが
いまどきの真のエンジニアじゃないのかな。

コメントを投稿する