ボタン化の進め方
ここまでのステップでは自動化2.0という考え方と、Ansibleで自動化2.0を実現するTower/AWXについて学習してきました。このアイデアをすぐに試したい方もいるかもしれませんが、その前に先人たちの試行錯誤によって生まれた自動化2.0の進め方に関するノウハウを学んでおきましょう。
ボタン化のポイント
自動化2.0で重要なのは「何をボタン化するか」と「誰に使ってもらうのか」です。当たり前のことだと感じたかもしれませんが、特に後者は気をつけていても忘れてしまいがちです。それはなぜでしょうか？自動化1.0で手順を置き換えようとした時には登場人物が自分一人の時がほとんどです。そのため自分中心に物事を考えても問題はありませんでした。しかし自動化2.0では第二の登場人物である「利用者」が存在します。ボタン化においては「自分」が楽になるということも重要ですが、利用者もボタンの利用が嬉しいことが必要であることを忘れてはいけません。
では、利用者が使って嬉しいボタンとはどのようなものでしょうか？残念ながらこの問には正解はありません。どんなボタンがあれば嬉しいかは組織の体制、業務分担、システムの特性などによって大きく異なりなります。それじゃどういうものを作っていいかわからないじゃないか、と思われるかもしれませんが、安心してください。何を作れば良いのかが不明な状態でも効率的にボタン化を進める方法があります。それは「仮説、実証、評価」のサイクルを短い期間で回して探索的に最適解にたどり着く方法です。こんな方法でほんとに？と疑問を持つかもしれませんが、実際にRed Hatではお客様の自動化2.0を支援する中でサイクルを回すために「Outcome Delivery」という手法を採用して実践しています。ここではこの手法から「特に初めてのボタン化」において重要となる考え方をお伝えします。
はじめの一歩
まず「何をボタン化するか」においては、小さく・簡単で・すぐに実装できる（もしくは既にplaybook化した）作業を選びます。これは手順書全体をカバーするものでも良いですし、手順書の一部を抽出したものでも構いません。はじめから大きなボタンを作ろうとすると時間も手間もかかる上に、もし使いにくいボタンに仕上がってしまったら修正するのにも大きな労力が必要になってしまいます。ここはトレイルマップ「YAML山」のSTEP5（失敗しない自動化ガイド）も参考にしてください。
次に「誰に使ってもらうのか」ですが、まず最初は「自分」を選択します。自分でボタンを作って、自分でボタンを押すのでは今までと何も変わらないように感じるかもしれません。しかし、自分がいつどんな状態でも気軽に押せるボタンでなければ、他人はそのボタンを使ってくれません。まずは自分が安心して使えるボタンを目指すことから始めましょう。
次に、作業の〜決まったら、簡単な仮説を立てます。選んだ作業に対して「こういうボタンが出来たら便利に違いない」というアイデアです。これは箇条書きでよいので必ずメモに残しておきます。この仮説をボタンの実装後に検証し、ボタンが想定の効果を発揮したかを確認します。もし思っていたものと少し違うな、と感じたらボタンを修正してまた検証を行います。
このサイクルを小さく回して1つのボタンを完成させることが最初のチャレンジになります。まずはハードルを下げて短い期間で小さな成功体験を積み上げることを目指します。２週間程度を目安にこのサイクルを一巡させてみましょう。
ボタン化の候補選びと仮説
さあこれでボタンを作ってくださいと言われてもいきなり難しいはずです。そこで最初のボタン化の候補を選び仮説、検証を行うワークシートを準備しました。ボタン山のSTEP1ワークシート（２）「ボタン化できそうな作業リストアップ」と合わせて使ってください。
以下の入力例で使い方を紹介します。まずSTEP1のシートから作業を１つ選んでシートの(1)の仮説部分に記載します。繰り返しになりますが、ここで選ぶ作業は小さく・簡単で・すぐに実装できる作業で、手順書全体をカバーしても手順書の一部を抽出したものでも構いません。
作業を選んだら、残りの仮説部分を埋めていきます。まず(2)の部分のに簡単なボタンの動作を記載します。どういったボタンを作りたいかというイメージを記載します。(3)ではボタンの利用者がどのようなインプットを与えるかを想像して記載してみましょう。(4)(5)にはボタンの裏で動くPlaybookが成功時・失敗時のそれぞれで、結果をどのように利用者へと通知するのかを考えます。
これで実際のボタンを作る前の仮説が完了したことになります。難しく考える必要はありませんので、まずはどんなボタンを作りたいか、そのインプットとアウトプットがどうなるのかを想像して文書化しておきます。
入力例（仮説）
| 項目 | 仮説 | 利用後の検証 |
|---|---|---|
| (1)ボタン化対象の作業 | XXサーバーのログの収集作業 | |
| (2)ボタンの動作の概要 | 対象サーバーのログを取得して、ボタンを押した人のメールアドレスへファイルを添付して送信する | |
| (3)利用者の入力 | 取得するログファイルの絶対パス 自分のメールアドレス |
|
| (4)成功時の動作と確認方法 | 成功メッセージを表示し、後にログファイルが添付されたメールが届く。 | |
| (5)失敗時の動作と確認方法 | ログファイルの取得に失敗したメッセージを表示する。メールは送信しない。 |
実際のボタンを作成して、自分で使ってみたら「利用後の検証」部分を埋めていきます。このボタン山では実際に実装するのはこの先のSTEPとなりますが、簡単にどのようような検証を行うかを紹介しておきます。
(1)と(2)については、そもそも選んだ作業が適切であったか、ボタン化に適していたか、実装の難易度はどうであったかを記載します。もし実装に移った段階で、難易度が高さを感じたり、想像していなかった問題が出てきた場合には実装を完了する前に仮説の部分に戻ります。この時にどのような困難さがあったのかを記録しておくことが重要です。(3)以降は実際に実装して使ってみた際の「あれが足りなかった、これもつけたほうがいい」といった実装したことでわかった内容を記載します。
一通りの検証が終わったら、仮説を修正して再度ボタンの実装と検証に入るか、新しい作業に取り掛かるかを判断していくことになります。
さぁ、実際の作業を選んで仮説を立ててください。それが終わったら次は、いよいよ実際に手を動かしてボタン化を実践していきます。色々とわからないこともたくさんあるかもしれません。しかし心配は不要です。体験することが学習の近道です。次の目標へ向けて共に歩んでいきましょう。