ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった～自動化の現場の真実（前編）。システムテスト自動化カンファレンス 2015
テスト自動化研究が主催するイベント「システムテスト自動化カンファレンス 2015」が、2015年12月13日に、六本木のヤフー株式会社で開催されました。
午前中に行われたセッション「自動家は見た～自動化の現場の真実～」には関西のコミュニティ「おいしが」のメンバーが登壇。テストを含む開発環境を自動化しようとしてきたエンジニアの、現場での苦悩と苦労をリアルに紹介しています。
その内容を前編、中編、後編の3本の記事にまとめました。この記事は後編です。この記事は前編です。
自動家（オートメータ）は見た！ 自動化の現場の真実。
「おいしが」の前川博志氏。
おいしがから来ました。グループ名にあんまり深い意味はありません。
自動化で発表される事例は、わりと恵まれた環境で、すごい能力を持っている人が、無事に自動化をなしとげて「すごいね」という話が多くて、それは素晴らしいのですが、現実にはそういう人たちだけなじゃないよねと。
やっぱり僕たちが聞きたいのは、かっこいい話ではなくて、苦痛にあえいで逆境に立ち向かって苦難を乗り越えながら、自動化をなし遂げんとする人の話を聞きたいのではないかなと。
今日はそんな話をしてもらおうと思います。
三浦一仁氏が登壇。
お前誰やねんということで、「三浦一仁」、通称「みうみう」と申します。
自動家、オートメーターと名乗っていますが、オートメータとは、ラクするためには苦労はいとわない、というところがポイントです。要するに“自動化”と提唱している関西の自動化大好きおじさんです。
ソフトウェアの開発の現場には、テスト自動化だけじゃなく、継続的インテグレーションや継続的デリバリなどもありますし、そのあいだをつないで全体を自動化するというのもあります。
その現場をトータルで自動化する人、なんていうとハードルが高すぎるかもしれないので、手間なことがあると「自動化する」のが良い、楽しいと思う人、感じる人、そういうひとは「自動家」（オートメータ）です。
もしこういう人がいたら拍手して欲しいんですけど（拍手）
これで会場はみんな自動家ですね。
自動家M氏。某プロジェクトに投入される
ここからは、とある駆け出し自動家の一年ちょいの体験記です。あくまで架空の話です。 自動家を標榜する、とあるエンジニアM氏は、ついに「自動化」していく仕事につきました。しかしその1年と数カ月のあいだにはいろいろなことがあったそうです。
その背景ですが、まず、Javaで作成されたBtoBのWebアプリがありました。
しかしなぜか、この開発者たちがいなくなります（笑）。
そのお客さんが、ある「雇い主」に泣きついて、その雇い主が開発チームにそのアプリの開発を命じました。
開発チームは5～7人くらい、会社もスキルもばらばらの混成チームです。これがなかなかうまくいかんな、ということで、雇い主は自動家アドバイザーを連れてきて、この自動家アドバイザーにより、自動家としてM氏が参加しましたと。
ただしM氏は開発者8割、自動家2割の割合で仕事をせよと言うことでした。
上手くいってるかも？ 期
ここから、M氏の歴史を見ていきましょう。まず「上手くいってるかも？ 期」がやってきました。
まず自動家は、Javaプロジェクトの構造の整理とか掃除をします。自動家の仕事はだいたいここからはじまりますね。
そこからM氏が実現したものは、Jenkinsを使った継続的インテグレーション（CI）環境、Dockerを使った継続的デリバリー（CD）環境、CDからつながるVNCサーバとSelenium環境とテスト方式、メトリクス記録。
それにステージング環境へのデプロイ自動化、本番環境へのデプロイ自動化などです。
で、すべてのジョブに対して、成功や失敗に関連したパトランプとかも作りました。勢いがありました。
お客さんの組織変更で「自動化などやってくれるな」
しかし続いて「雲行き怪しい期」がやってきます。
お客さんの組織改編で担当者が変わり、いままでのやり方を変えることになったんですね。
基本、従来のものは悪いものとなって、CIやCDは「そんなことに時間割いてくれるな」と直に言われてしまいました。新規の自動テストも「そんなの書いている暇があったらモノを作れと」書けなくなりました。
方針としてSIer的、どウォーターフォールちっくなルールが導入され始めます。
M氏はこのとき何をしていたかというと、来たるべき新ソースでのCI/CDに向けて準備をしていました。ただ、テンションはだだ下がりでした。
続いて「死んだ魚の目」期が来ます。
チームは黙々と開発を続け、Excel方眼紙の仕様書やExcelテスト仕様書が続々到着。休日出勤や残業などでメンバーは疲弊。しかし重要でマストな機能群はリリースにこぎ着けましたと。
そしてM氏はプロジェクトを離脱していきました。
自動化への取り組みは、外の事情でご破算になる
ここまでの話で、三浦氏はどう思ったか。愚痴です。
自動化への取り組みは、外の事情でひとたまりもなく「ご破算」になります。「じゃまな作業はしないでくれ」とまで言われます。
どうすりゃよかったのか？
雇い主、お客様ともに自動化の意思がない場合。（自動家としては）3つの考え方があると思います。
- あきらめてすぐに撤退
- 自動化の重要性とリスクを説く
- チーム一丸となって自動化へ向かう
ただ、重要さを説いてもあの状況が変わったとは思えないですし、そもそも混成チームには一丸となって自動化へ向かう意思もなかったわけです。
一方で、プロダクト開発的には重要な機能が間に合って、ある程度成功していました。その理由は、メンバーがSIer的、ウォーターフォール的に優秀な人だったことと、手動テストの労働量をこなせて、それに特化した考えの人々だったと。
ただ、デプロイ自動化だけは最後まで使われていました。それは単に自動化の効果が高いところだったから、と言えそうです。ここは一度作ればほぼメンテナンスフリー、使用頻度もソコソコでした。
個人的な結論としては、お客と雇い主が望む状態でなければ、自動化したくないなあ、という感想です。
≫現場で自動化に苦労した話をする三浦氏の壇上に、マネージャが乱入します！ 怒濤の中編に続きます。
≫次の記事
開発環境の「自動化」に抵抗するマネージャのロジックとは～自動化の現場の真実（中編）。システムテスト自動化カンファレンス 2015
≪前の記事
インフラ自動化ツール「Ansible 2.0」正式版がリリース。リファクタリングによるアーキテクチャの整理、Block文や動的なIncludeなどの新機能