IT部門のメンバーなら、タスク自動化を行った経験があると思います。スクリプトの作成やアプリケーション構築、またはベンダーの既製ソリューションの活用など、形態は様々でしょうが。
自動化は退屈で反復的なエラーを起こしやすい作業から人間を解放し、自動化によって人間はより重要で創造的な作業に集中することが可能になります。ただ、以前自動化を行った経験があるというだけでは、IT自動化が成功する保証はありません。自動化がコスト削減につながるという企業の利益重視の視点で押し切られてしまい、自動化を効果的に進めるのに適切な思考ができなければ、失敗する可能性があります。Active Directory でユーザーを作成するのに費やす時間を削減するといった部門プロジェクトでさえ、適切な自動化アプローチがとられなかったら、予想外に面倒な手間がかかり、困難なプロジェクトになってしまうかもしれません。時間を節約し、エラーを削減し、多くのメンテナンスを必要としない有用なIT自動化を構築することは、想像以上にずっと大変な作業です。
筆者の経験では、自動化を事後処理として取り入れる人が多いようです。つまり、それまで手作業で行っていたことを作業量の増加などのためにやり続けることができなくなったときに、仕方なく自動化に踏み切るというシナリオです。必ずしもいやいや行うというわけではなく、必要になるまで自動化しようと考えていなかったということです。1ヵ月に1回だけタスクを実行すればいい場合、（毎日実行する場合に比べて）自動化の必要性はそれほど強くありません。また、新しいプロジェクトを立ち上げるときには、プロジェクト全体の文書化も難しく、ましてや自動化ルーチンを正しく実装するための特定のプロセスや手続きを考えることなど、できないのが普通でしょう。
スクリプト、アプリケーション、サービスなどを活用して自動化するためには、自動化の対象となるプロセスを理解する必要があります。プロセスを理解するには、プロセスがポイントAからポイントBまで、そしてそこからポイントCまでどのように移行するかのルールを文書化するのが一番です。忙しすぎて記録する時間がないからと言って、ただノブを回したりスイッチをオン/オフしたりしてプロセスを動かそうとしても、実際に何が行われたのか理解する方法がありません。この状況で自動化を実装しようとするのは無駄な努力です。
自動化ファーストで考えると、最優先とすべきは文書化です。プロセスでとられるステップを正確に理解することなくそのプロセスを自動化することはできません。自動化を本当に成功させるためには、少なくとも2回は、最初から最後まですべてのステップを実行してみる必要があります。理解していないプロセスは複製できません。これが第一段階です。
プロセスを複製するためのドキュメントが完成したら、次はパラメータについてよく検討してください。プロセスを１度複製できたとしても、毎回毎回同じようにいくという保証はありません。自動化されたプロセスが、時間が経過したときに変化する可能性があるすべてのパラメータを考慮する必要があります。この考え方は、toolmaking と呼ばれるスクリプト作成のコンセプトに関連しています。PowerShell toolmaking はプルーラルサイトで筆者が提供している人気のあるコースです。このコースで、筆者は、スクリプトを作成するとき、ツールを作成しているという気持ちで取り組むべきだと説明しています。ツールとは、呼び出されたときの様々なコンテキストに対応して、コード自体を変更することなく、繰り返し使用できるものを意味します。
この toolmaking のコンセプトは、さまざまな異なる自動化プロジェクトに拡張することができます。柔軟性があり、さまざまな方法で呼び出すことができるソリューションにするにはどうすればいいかを考えることは重要です。ただ、もし毎回異なる自動化ルーチンを作成しなくてはならないようなら、そのような作業は手動で行うようにした方がいいでしょう。
まとめ
最後に、自動化ファーストの考え方を要約します。
- 最初からすべてを文書化する
- プロセスの各要素が他の要素とどのように相互作用するかを考慮する
- 柔軟性が高いソリューションになるよう設計する
プロセスの自動化は、最終的にうまくいかない場合もありますが、それでも自動化に取り組むことには意義があります。プロセスについての理解が深まり、文書化でそれを他のメンバーとも共有することで効率化につながります。