2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

テスト自動化導入の時の話 by T-DASHAdvent Calendar 2024

Day 18

自動化導入のコツは「百聞は一見にしかず」、見せる、使う、引き継ぐを目指そう!

Posted at

はじめに

自動化は誰もが望む反面、実際に導入をするのが難しい側面もあります。導入のハードルになる例として、「本当に動くのか」、「誰が管理するのか」などいろいろな懸念点があります。そうした懸念点を一つ一つ解決しようとしているといつまで経っても自動化は導入されません。

一方、私自身これまで様々な箇所で自動化を導入してきました。その時の経験から、どのようにして自動化を実現したかまとめたいと思います。ポイントは「百聞は一見にしかず」です。

まずは「見せる」

自動化は、実現すれば夢のような世界が待っていますが、本当に動くのか半信半疑なために導入を躊躇することが多いと思います。そこでオススメなのがまずは「見せる」ということ。

最終的な自動化を完成させる必要はありません。すごく小さなプロトタイプでも良いので、まずは根本になる自動化ができることを示します。例えばログを自動収集する、結果を自動判断する、障害をチャットでつぶやくなど。

本当に動くものを目にすると自動化が身近になり、より話が通りやすくなります。スティーブ・ジョブズの名言に次のようなものがあります。

A lot of times, people don't know what they want until you show it to them.
(多くの場合、人は何が欲しいのかそれを見せてもらうまでわからないものだ)

自動化を実際に見せて「これが欲しかった!」と思ってもらう、これが自動化を成功に導く第一歩です。

次に「使う」

プロトタイプが動いたら、周りに宣伝しましょう。目に見える形で自動化ができると、「それができるなら、これも自動化したい」という形で周りの人を巻き込んで自動化の熱をあげることができます。そうした周りの要望を取り込むことで一丸となって自動化を推進する流れができます。またここで重要なことは疎結合および拡張性があることです。

自動化のゴールを一度に達成するのは難しく、少しずつ開発を重ねる必要があります。その時に、自分の作ったプロトタイプも採用して欲しいものです。そのためには疎結合できるようモジュール化しておくことです。モジュールもわかりやすく、例えば Python であれば pylint を通して標準的なコーディングスタイルにしておくことは、この次に述べる引き継ぐ際にも重要です。

また API など拡張可能な構成にしておくと、様々な連携が容易になります。自動化がそれ単体で完結することは珍しく、既存のシステムと何かしらの連携をする必要がでてきます。その時には API 化をしておき外部から連携しやすくしておくと使ってもらえる機会が増します。またそのようにして既存のシステムと連携すると、自動化を定着させ長く使ってもらえることにも繋がります。

このようにして自動化を実際に使ってもらうこと、また使ってもらうことを前提に拡張可能な自動化にしておくことは、自動化導入のための重要なステップになります。

そして「引き継ぐ」

使う人が増えるとそれをカスタマイズしたいという人がでてきます。ここまできたら、ほぼ自動化をチーム内なり社内で採用してもらえるのは確実です。

しかしその時に、自分の書いたプロトタイプが解読不能では意味がありません。よってプロトタイプを書くにしても他の人が読めるように意識して書くことが重要です。そのためには、読みやすい自動化やコードにしておくことが必要です。

読み易いコードと一言で言っても様々な方法があります。lint などを通しコーディングスタイルを標準的にしておくことも重要です。また読み易いコーディングを書くための本も参考になります。例えば The art of readable code では、どのような内容をコメントにするべきか、また不要なコメントは何かなど、第三者がコードを参照する際に読みやすくする手法がとても良くまとまっています。また条件判断の際、例えば Python で示すと variable == True と書くのではなく True == variable と書くべきといったちょっとしたテクニックも載っています。等価演算子の == はしばしば代入の = のようにタイポしてしまうことがあります。この時 variable = True だと代入が成功してエラーになりませんのでデバッグが難しくなります。一方 True = variable と書いた場合は、True には代入できずエラーになり実行時にタイポを発見できます。

こうした細かな気配りができているコードは多くの人に受け入れやすくなり、自動化が浸透するために大きな役割を果たします。そして自動化を他のメンバーやチームに引き継ぐことができれば、導入は成功したと言えます。

まとめ

シリコンバレーには Fail Fast という考え方があります。失敗はできるだけ早く修正しそこから学ぶという考え方です。自動化導入も同じで、いつかやってみようでは遅いです。

まずは自分が実装して見せる。それが上手くいかなかったらそこから学び次につなげる。上手く行ったら使ってもらい、周りを巻き込んで大プロジェクにする。そして引き継いで導入を成功させる。変化の早い今の世の中、こうしたスピード感を持った対応が必要だと思います。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?