導入のポイント

　筆者が自動化に限らず何かを導入するときに気をつけていることは次の3つです。

• ボトルネックになっている部分から手をつける
• ゴールの大きさに関わらずゴール設定をする
• 方法論や基本のセットがある場合には、可能な限りそのセットのすべてを導入する

　この3つに気をつけたうえで、好奇心やリスクとうまく付き合うことで組織やプロダクトが成長できると考えています。もちろん組織によってそのバランスはさまざまでしょう。

　ではこれらを明確に意識して自動化をすすめていけば問題がないかというと、そうではない場合も往々にしてあります。組織における慣習的な問題でうまくすすまないこともあれば、思いもよらない技術的な問題にぶつかることもあります。そのときにそれらを変えるべき事象と捉えるのかどうかによって、何を変えたいのかがより明確になります。

　Agile、DevOpsなどのキーワードが自動化とセットで語られることはもちろんありますが、その一方で「組織作り」のキーワードとしても語られます。コンウェイの法則でも言われているように組織構造と製品や課題というのは相互に関係しあいます。一気に手広くやらなければ解決しないことのようにも捉えられますが、小さく挑戦し始めましょう。見ないフリをするのではなく、解決すべきことのために協力して小さく成功と失敗を繰り返しましょう。組織的な課題に対しては『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』や『組織パターン』といった書籍が役に立ちます。

　ボトルネックの見つけ方にはさまざまな方法論がありますが、筆者のオススメはValue Stream Mappingで図示することです。表記のルールも少なく、まず簡単に描いてみて共有し、現実との差異を反映していくためのツールとして役立ちます。

そのステップを次は何分後にやるのかで選定することも

　基本はボトルネックを探しだしては、そこを解決するという方法で進めていきます。ただ、その自動化にどれくらいのコストを使えるのか、どんなリターンが得られそうかも考えたほうがよりよいです。

　詳細に考えるのであればROIを算出して数値で比較すると分かりやすく、例えばテスト自動化のROIについて言えば、＠ITの連載『テスト自動化のROIを計算してみよう』を参考にしてみてください。「まずは試してみる」ということも大切ですが、可能な限り全体最適を考えて小さく挑戦することが重要です。

　ただ、ボトルネックになっている部分から手をつけるといっても、それを特定するのは困難なことが多いです。ボトルネックを簡単に特定できない場合は、筆者は「自動化で代替されるそのステップをまたやるのは次は何分後なのか」で選定しています。大抵はファイル変更が最も頻度が高いので、まずはバージョン管理の導入になります。その次にビルド、テスト、CI、デプロイと続いていきます。必ずしもこの順番である必要はなく、テストの自動化よりもシステム内の連携が多く設定するのが大変な場合もあり、そのときはオーケストレーションに注力したほうがよいです。

　各ツールの導入順もそうですが、特定ツール内での導入パターンも最近ではまとまりつつあります。例えばデプロイに関しては『Deployment Automation Patterns』のように簡易で分かりやすくまとまっているものもあります。

まとめ

　自動化に使えるツールやサービスを分類し、導入のポイントを紹介しました。

　筆者が自動化をすすめるときには、「その作業をなくす」ことを念頭においています。手動から自動にすることは2番目です。「なぜ自動化したいのか？」と「なぜその作業が必要なのか？」は同じ原因をもっているとは必ずしも言えません。例えば組織に応じて先ほどのような仕事や情報やモノの流れを図にして、どの部分をどのように変化させていくことが自分達のビジネスに適合するのかを考えましょう。

　例えば、自動化のツールを自分たちでどんどんカスタマイズしたり開発したりする組織もある一方で、自分達がリリースしている製品以外のツールはあまり開発しないという組織もあります。どちらが優れているということはありません。

　そして自動化の方法によって得られるものもあれば、失うものもあります。例えば、手動でやっていた部分の技術的な知識が受け継がれなくなる場合もあります。自動化が悪いわけではありませんが、何が大切なのかを考え、どう進めるのかを合意しましょう。

　本稿ではすべてのツールや分類を列挙することはできませんでしたが、全体としてどんなツールやサービスがあるのか把握するエントリポイントになっていれば幸いです。