ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった~自動化の現場の真実(前編)。システムテスト自動化カンファレンス 2015

2016年1月13日

テスト自動化研究が主催するイベント「システムテスト自動化カンファレンス 2015」が、2015年12月13日に、六本木のヤフー株式会社で開催されました。

午前中に行われたセッション「自動家は見た~自動化の現場の真実~」には関西のコミュニティ「おいしが」のメンバーが登壇。テストを含む開発環境を自動化しようとしてきたエンジニアの、現場での苦悩と苦労をリアルに紹介しています。

その内容を前編中編後編の3本の記事にまとめました。この記事は前編です。

自動家(オートメータ)は見た! 自動化の現場の真実。

「おいしが」の前川博志氏。

おいしがから来ました。グループ名にあんまり深い意味はありません。

「おいしが」の前川博志氏

自動化で発表される事例は、わりと恵まれた環境で、すごい能力を持っている人が、無事に自動化をなしとげて「すごいね」という話が多くて、それは素晴らしいのですが、現実にはそういう人たちだけなじゃないよねと。

やっぱり僕たちが聞きたいのは、かっこいい話ではなくて、苦痛にあえいで逆境に立ち向かって苦難を乗り越えながら、自動化をなし遂げんとする人の話を聞きたいのではないかなと。

今日はそんな話をしてもらおうと思います。

三浦一仁氏が登壇。

三浦一仁氏

お前誰やねんということで、「三浦一仁」、通称「みうみう」と申します。

「三浦一仁」、通称「みうみう」

自動家、オートメータと名乗っていますが、オートメータとは、ラクするためには苦労はいとわない、というところがポイントです。要するに“自動化”と提唱している関西の自動化大好きおじさんです。

ソフトウェアの開発の現場には、テスト自動化だけじゃなく、継続的インテグレーションや継続的デリバリなどもありますし、そのあいだをつないで全体を自動化するというのもあります。

その現場をトータルで自動化する人、なんていうとハードルが高すぎるかもしれないので、手間なことがあると「自動化する」のが良い、楽しいと思う人、感じる人、そういうひとは「自動家」(オートメータ)です。

「自動化する」のが良い、楽しいと思う人、感じる人、そういうひとは「自動家」(オートメータ)

もしこういう人がいたら拍手して欲しいんですけど(拍手)

これで会場はみんな自動家ですね。

自動家M氏。某プロジェクトに投入される

ここからは、とある駆け出し自動家の一年ちょいの体験記です。あくまで架空の話です。

自動家を標榜する、とあるエンジニアM氏は、ついに「自動化」していく仕事につきました。しかしその1年と数カ月のあいだにはいろいろなことがあったそうです。

その背景ですが、まず、Javaで作成されたBtoBのWebアプリがありました。

とあるエンジニアM氏は、ついに「自動化」していく仕事についた

しかしなぜか、この開発者たちがいなくなります(笑)。

そのお客さんが、ある「雇い主」に依頼して、その雇い主が開発チームにそのアプリの開発を命じました。

雇い主が開発チームにそのアプリの開発を命じる

開発チームは5~7人くらい、会社もスキルもばらばらの混成チームです。これがなかなかうまくいかんな、ということで、雇い主は自動家アドバイザーを連れてきて、この自動家アドバイザーにより、自動家としてM氏が参加しましたと。

自動家としてM氏が参加

ただしM氏は開発者8割、自動家2割の割合で仕事をせよと言うことでした。

上手くいってるかも? 期

ここから、M氏の歴史を見ていきましょう。まず「上手くいってるかも? 期」がやってきました。

まず自動家は、Javaプロジェクトの構造の整理とか掃除をします。自動家の仕事はだいたいここからはじまりますね。

そこからM氏が実現したものは、Jenkinsを使った継続的インテグレーション(CI)環境、Dockerを使った継続的デリバリー(CD)環境、CDからつながるVNCサーバとSelenium環境とテスト方式、メトリクス記録。

それにステージング環境へのデプロイ自動化、本番環境へのデプロイ自動化などです。

M氏は開発からデプロイまでの自動化を構築

で、すべてのジョブに対して、成功や失敗に関連したパトランプとかも作りました。勢いがありました。

お客さんの組織変更で「自動化などやってくれるな」

しかし続いて「雲行き怪しい期」がやってきます。

お客さんの組織改編で担当者が変わり、いままでのやり方を変えることになったんですね。

基本、従来のものは悪いものとなって、CIやCDは「そんなことに時間割いてくれるな」と直に言われてしまいました。新規の自動テストも「そんなの書いている暇があったらモノを作れと」書けなくなりました。

顧客の組織改編で自動化に反対される

方針としてSIer的、どウォーターフォールちっくなルールが導入され始めます。

M氏はこのとき何をしていたかというと、来たるべき新ソースでのCI/CDに向けて準備をしていました。ただ、テンションはだだ下がりでした。

続いて「死んだ魚の目」期が来ます。

チームは黙々と開発を続け、Excel方眼紙の仕様書やExcelテスト仕様書が続々到着。休日出勤や残業などでメンバーは疲弊。しかし重要でマストな機能群はリリースにこぎ着けましたと。

そしてM氏はプロジェクトを離脱していきました。

自動化への取り組みは、外の事情でご破算になる

ここまでの話で、三浦氏はどう思ったか。愚痴です。

自動化への取り組みは、外の事情でひとたまりもなく「ご破算」になります。「じゃまな作業はしないでくれ」とまで言われます。

どうすりゃよかったのか?

雇い主、お客様ともに自動化の意思がない場合。(自動家としては)3つの考え方があると思います。

  • あきらめてすぐに撤退
  • 自動化の重要性とリスクを説く
  • チーム一丸となって自動化へ向かう

ただ、重要さを説いてもあの状況が変わったとは思えないですし、そもそも混成チームには一丸となって自動化へ向かう意思もなかったわけです。

一方で、プロダクト開発的には重要な機能が間に合って、ある程度成功していました。その理由は、メンバーがSIer的、ウォーターフォール的に優秀な人だったことと、手動テストの労働量をこなせて、それに特化した考えの人々だったと。

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

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

顧客が望まない自動化はしたくない

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

あわせて読みたい

ソフトウェアテスト・品質 プログラミング言語 開発ツール




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本