ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった～自動化の現場の真実（前編）。システムテスト自動化カンファレンス 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的、ウォーターフォール的に優秀な人だったことと、手動テストの労働量をこなせて、それに特化した考えの人々だったと。

ただ、デプロイ自動化だけは最後まで使われていました。それは単に自動化の効果が高いところだったから、と言えそうです。ここは一度作ればほぼメンテナンスフリー、使用頻度もソコソコでした。

個人的な結論としては、お客と雇い主が望む状態でなければ、自動化したくないなあ、という感想です。

≫現場で自動化に苦労した話をする三浦氏の壇上に、マネージャが乱入します！ 怒濤の中編に続きます。