スクラム崩壊からの復活、神Excel手順書ベースの運用からAnsibleでの自動化へ――泥臭い現場の取り組みに学ぶ、明日から使える開発ノウハウ：明日の開発カンファレンス 2018（2/2 ページ）

より良いサービス、より良いモノを作るため、現場で泥臭く試行錯誤を重ね、前進し続けている現場のエンジニアの「声」を、「明日の開発カンファレンス 2018」で行われたセッションの中から拾ってみた。

[高橋睦美，＠IT]

今までのやり方を尊重しつつ、神Excel手順書ベースの運用からAnsibleによる自動化への移行を実現

フューチャーアーキテクトの齋場俊太朗氏

　金融系プロジェクトとくれば、ガチガチのウオーターフォール方式。システム構築作業も運用も、定められた手順書に沿ってポチポチ入力していくもの……というイメージが強い。しかし、フューチャーアーキテクトの齋場俊太朗氏は、オープンソースの「Ansible」を使ってOSやユーザー管理、パッケージ管理やディレクトリ管理を自動化することに成功した。

　現行のやり方を変えようとすることは、ただでさえ大きな抵抗に直面するものだ。齋場氏自身も、「今までのやり方、文化を変えるのは大変です。新しいやり方に対して、会議では『便利だけれど、難しいんでしょ』『事故やセキュリティは大丈夫？』などといっぱい言われました」と振り返る。

　そんな逆風の中、いったいどうやって新たな文化作りに成功したのかを、「新卒3年目のぼくが、エンプラ金融PJにAnsibleを導入してみた」と題するセッションで紹介した。

「神Excel手順書」への怒り

　齋場氏は2017年4月、ある金融系プロジェクトのシステム基盤の更改作業に「下っ端」として割り振られることになった。このシステムでは約150に上るサーバがそれぞれに「育って」きた結果、いずれもブラックボックス化し、当初作成された手順書が信用できなかったり、逆に複雑怪奇な「神Excel手順書」を読み込んで対応したりしなければならなかった。

神Excel手順書の例（齋場氏の講演資料から引用）

　それだけでも齋場氏にとっては「怒り満載の状態」。その上、インフラチームのリーダーが、当初「サーバ構築は手作業でやろう」と言い出したことに、過去、サーバ構築作業を手動で行ったときの苦い記憶――「設定、間違えてた」「ダブルチェックしたの？」「いつの間にか設定が変わっていた」「ダブルチェックは？」――が走馬灯のように横切り、「絶対に嫌だ」と固く決意し、Ansible導入に取り組むことにした。

インフラ／アプリチームへの布教

　最初に布教活動の対象にしたのはインフラチーム、次にアプリチームだった。

　「まず身近なところから仲間にしようと思いました。サーバに設定ファイルを配布するだけといった形でスモールスタートで始め、そこからだんだんAnsibleファンを増やしていきました」

　もともとインフラチームも、「ユーザー作成が面倒」といった問題を抱えていた。そこで、Ansibleの持つさまざまなモジュールを活用して自動化し、彼らの課題を解決することで、「これ、いいよね」と言ってもらえる場面を増やしていった。「エージェントレス」というAnsibleのアーキテクチャとRed Hatのブランドも後押しになったという。

　いきなり皆にAnsibleを使いこなすよう求めるのではなく、これまでのやり方を大きく変えずに使える仕組みを整えたこともポイントだ。齋場氏は自力でJenkinsとGitを活用し、「Excelの設計書をPythonスクリプトで読み取りAnsibleのファイルを作成してコミットする」までを自動化する仕組みを作成した。Excelの設計書がサーバの変更依頼を受けるインタフェースの役割となることで、皆が使える仕組みにしている。

　「ここは一番頑張りました」

運用チームへの布教

　インフラ／アプリチームの次に取り組んだのが、運用チームへの提案だ。まずプロジェクトリーダーに「ヒューマンエラーやステージング環境と本番環境の食い違い、環境間差異といった今まで抱えていた課題は、Ansibleを導入してInfrastructure as Codeにすることで、人が作業しなくても解決できます」と、現状の問題解決とビジョンを提案。理解を得てから仲間を増やしていった。

　運用チームの現場レベルでは、「任意のサーバに任意のコマンドを一気に発行できますよ」「1つのコマンドで特定のパスのファイルを全サーバから回収できますよ」といった具合に、簡単なことから作業を改善できることを示し、慣れてもらった。この作業も簡単に行えるよう、手順書やスクリプトをどんどん整備した。

　「『今まで自分たちがやっていた手作業が自動化されるのはいいね。活用したい』という声をもらえました」

保守チームへの布教

　次のステップは保守チームだった。

　「ここで大切にしたポイントは、私たちが考えたことを押し付けるのではなく、『一緒に考える』こと。それから、『今までのやり方にはどうしても捨てられないものがあるので、それらと調和させる』ことです」

　そこで、保守チームと一緒になってワークフローを検討した。齋場氏にとっては許し難い存在である「神Excel手順書」も、「これまで5年間も続いていたやり方をなくすのは難しい」と思い、調和させることにした。

　「Excel手順書に記されたコマンドを叩く代わりに、まずAnsibleでサーバのあるべき状態を定義し、Excel手順書にはAnsibleで実行すべきコマンドを書くという形を提案しました」

　今までのやり方を尊重するという意味で、セキュリティポリシーも極力同じものを維持するように試み、パスワード入力やファイル授受の手順なども従来通りとした。

自分がチームから抜けても回るように

　こうして少しずつAnsibleを用いた環境を整備し、プロジェクト本体も無事にリリースされた。

　「ぐちゃぐちゃだったExcel手順書が、Ansibleを実行するコマンドが記されるだけのシンプルな内容になり、全員から、『Ansibleいいね』と言ってもらうことができました。その後、自分がチームから抜けても回るように、ビジョンや使い方などをまとめ、引き継ぎ資料として残しました」

Ansible布教で大切にした2つのこと

　このように、チームごとに異なるアピール方法を取ってAnsibleを導入していった取り組みを振り返って、大切にしたポイントは2つあるという。

　1つは、「ツールの方を今までの文化に合わせていく」ことだ。

　「大切なのは、チームのだれもが使えるようなラクで分かりやすい構成にすること。そのため、今までの考え方に歩み寄るようにして、Ansibleのベストプラクティスは捨てました」

　もう1つは「あきらめない」ことだ。

　「Ansibleとは何か、Infrastructure as Codeとは何か、あるべき姿をソースコードで定義して自動化するとどうなるのか……そういった事柄を一つ一つ丁寧に説明し、時にはデモを通じて効果を示しながら、仲間を増やしていきました」

　Ansibleを導入してサーバ構築、運用作業を自動化するとなると、最初は確かにコストがかかる。しかしいったん自動化できれば継続的にコストを削減できるだけでなく、オペレーションミスがなくなるといったメリットが得られる……そんなコンセプトを丁寧に説明し、理解を得ていったのだ。

　だが、それ以上に伝えたいことがある。齋場氏は、それをもって講演を結んだ。

　「私は、変化しないリスクが一番大きいと思っています。プロジェクトの仲間の中には、今の開発フローがつまらないと思っている人も多く、中にはいなくなる人もいる。システム開発を仕事にしていながら、新しいやり方に乗り遅れていいのか、どんどん新しいツールを使っていかなければ取り残されることを上の人には力を入れて伝えました。まだまだ課題はありますが、チームと“協力して”解決していきます」