これは Fujitsu Advent Calendar 2016 の 10日目の記事です。
掲載内容は私自身の見解であり、富士通グループを代表するものではありません
はじめに 
@tnaotoさんの２日目の記事がバズったことから富士通のAdvent Calendar があることを知り「これは参加せねば！！」と思い、参加させてもらいました。
とはいうものの、こういったものに参加するのは慣れていないので何を書こうかなーと色々と迷いました。
技術系のお話を書いてもあまり面白そうなことは書けなそうなので、少し前の話ですが私がチームにAnsibleを導入した経緯とかを話したいと思います。
職業プログラマ 
ちょっと自分語り。
2年半くらい前まで、私は「職業プログラマ」でした。
職業プログラマっていうのは、お仕事としてプログラミングをしている人のこと。
私はもともと工業系の学校でプログラミングを学んでいたので、そのままの流れで今の会社に入社した感じになります。
入社してからずーっと、仕事でプログラミングはするけども、家に帰ったら勉強なんかせず。
ゲームするか、ニコニコ見るか、寝るか、そんな感じの日常を過ごしていたと思います。
ちょっとした転機 
そんな自堕落な生活をしていた私ですが、ある時転機が訪れました。
会社の知り合いで趣味でもプログラミングをする人がいて、その人が「Github Kaigiに行ってきた!!」と。
「ほーん、そんなんあるや。」
「ちょっと面白そうやん、調べたろ!!」
「なんやよくわからんな。。。」
「Rebuild.fm?? podcastって普通に使われてたんや。」
「せっかくやから聞いてみるか!!」
そこで、聴いたのがエンジニア界隈では有名な Rebuild.fm Ep 47:Live From GitHub Kaigi (Naoya Ito) でした。
外を知る 
これを聴いて、最初に感じたのは焦りでした。
外の世界はこんなにも進んでいるのか！！と。
入社してからずっとSubversionを使っていて、それが当たり前だと思っていた。
でもそれは自分が知っている世界に閉じた話で、その世界の外ではどんどん新しい技術や概念が生まれていた。
このままじゃヤベェ！！という焦り。
でも、それだけじゃなくて。
エンジニア界隈ってこんなにも楽しい世界だったんだなと。
技術をテーマでめちゃくちゃ楽しそうに会話しているのを聴いてたら、こっちも楽しくなっちゃうじゃないですか 
それでもって、こういった会話に自分もついていけるようになりたいとか、エンジニアとしてちゃんと技術を学んでいきたいとか、新しいことにチャレンジしていきたいとか、ちょっと自分の中で考え方が変わっていきました。
そこで Rebuild.fm の過去回をどんどん聴きあさっていき、25: Immutable Infrastructure (Naoya Ito, Gosuke Miyashita) にたどり着きました。
これを聴いてまたヤベェぞ！！ってなるわけですよ。当時からして２年前の話についていけないとか。
そんなことから、Chef とか Ansible をちょろっとさわって、Infrastructure as Code の概念を学んでいきました。
Ansible を導入できなかった話 
ちょうどそんな時。
それまで私はバックエンドのAPI開発をやっていたのですが、ひょんなことからインフラ構築とか運用がメインのチームのリーダーをやることになりました。
これはチャンスとばかりに Ansible を導入しようとしました。
実はこのチーム、以前 Chef での自動化をやっていたのですがあまり定着せず、手順書作業に戻ってしまってたんです。
コード書いている人なら Chef を使ってのインフラのコード化はそこまでハードルが高くないかもしれないですが、当時の Chef は登場人物が多すぎて訳がわからなくなってしまう感じ、あと DSL がちょっと慣れないものだったのかもしれない。
Ansible はシンプルなので、わかりやすい、こっちなら導入できるんじゃないかと考えました。
とはいえ、既存のシステムがあるところに新しいものを導入するのは簡単ではない。。。
これまでのやり方を刷新して「これからはこうやるんだー！」なんていっても、誰もついてきてくれないだろう、それでもこのままのやり方を続けていたらいけないと悩み続けました。。。
Ansible を導入した話 
そんなある日、AWS上に新しい環境を構築する話が出てきました。
こんなチャンスはもうない、、、こうなったら、一人でも全部自動化してやると。
（この時、チームのメンバーは手順でやる想定でいたと思います）
そんな思いからこっそり一人でAnsibleを導入して、一人でせっせとプレイブックを書いていました。
すると、私の作業が遅いと思ったのか何なのかはわかりませんが、チームのメンバーが何やってんのー？と横から覗いてきてくれました。
そこで Ansible っていうのを使おうとしていて、書くとこんな感じで、手順でやってたのが楽になるんですよーって説明をしたところ、何と！一緒にやってくれると！
実際にさわったところ、その人にもしっくりきたみたいで、すごい楽でいいねこれ！！っとのっかってきてくれました
１回ポッキリの構築の予定だったので、既存の手順を使えばもっと早く終わるはずだった作業なのですが、一緒に残業してまで付き合ってくれたのを今でも覚えています。
そんなこんなで出来上がったのが、拙いAnsibleのPlaybookたちとCloudFormationのテンプレートファイル。
手動でやったら数日かかるような作業が数時間で終わるようになりました。
「１回ポッキリの構築」っていう予定は予定でしかなくて、それ以降も使うことが多々あり、長期的に見たらよかったんじゃないかなと思ってます。
私が実際に一緒にAnsibleしたのはこの人だけですが、今ではその人がAnsibleマスターとなって他のチームにも導入を進めていってくれています。
振り返ってみて
今回の導入例では、タイミングがいいところにいいチームメンバーがいてたまたま導入できた感はあります。
んー、今考えると、実は私がかなり焦っていたのかもしれません。
最初からでかいことをしようとしすぎていた、所詮庶民が１人でなんでもかんでもやるなんてできません。
小さいところに適用して進めていく、当たり前のことですが大事なことだと思います。
もちろん、Ansibleの導入が目的ではないので、チームが抱えている問題をあげて具体的にそれを解決できるっていうところを示すのも大事です。
が、導入自体はこっそりやっちゃってもいいんじゃないでしょうか？
無責任なことを言ってしまいますが、なんだかんだみんな技術が好きだったりするんですよね。
実際にさわってみて、感触的に行けると思ったんだったら、それはありなのでは！？
最後に 
あまりに拙いものを残してしまったので、自分が抜けた後にメンテしてくださっている人たちに感謝です 
あんまり自分のことを職業プログラマって思っている人はいないかもしれませんが、何となく仕事が楽しくないと感じている人がこのブログを見てちょっと社外の勉強会に出てみようかななんて思ってもらえたらなと思ってます。
Fujitsu Advent Calendar を作ってくださった @YasunoriGoto1さん、 @tnaotoさん、関係者の皆様。
拙い文章をここまで読んでくださった皆様。
ありがとうございました。
主に静岡あたりで活動してますので、勉強会などで見かけたら声をかけてあげてください。