1.
よくある業務開発の
自動化事情
@irof
2015/11/28 - JJUG CCC 2015 Fall
#ccc_cd3

2.
irof
ふつうのプログラマ
関西Javaエンジニアの会（関ジャバ）の人

3.
自動化は好きですか？

4.
好きかはさておき
興味はあるハズ

5.
困ったことがあるハズ
ない人はしらん（ごめん

6.
自動化は話しづらい
自動化は範囲が広すぎる
広いままでもできなくはないけど
例: AAA(A* Automation Alliance)
分野が違うとふーんで終わっちゃう
キレイな事例紹介になりがち

7.
なので絞る

8.
このセッションで言う
“よくある業務開発”
コンテキストを共有します

9.
Java
JJUGだしね

10.
Webアプリケーション

11.
受託開発

12.
10人程度

13.
スキルばらばら

14.
会社もばr（ry

15.
“よくある業務開発”
JavaなWebアプリケーションの受託開発
チームは10人程度
スキルはバラバラ
開発フェーズにおける自動化

16.
そんな現場での
自動化について話します
複数の現場の話を混ぜて

17.
ゴール設定

18.
この話の背景
よく聞く事例紹介はキレイすぎる
もっと泥臭くて生々しいハズ
現実の試行錯誤を聞きたい
けれど、言いにくいとも思う
だから、話してみることにした

19.
私が今日どこかで
自動化の苦労話を聞く
お願いします

20.
<<3分クッキング>>
自動化の知識や知見が存在しない現場での導
入パターン
手軽で有効で派手な自動化ネタを用意してお
き、紹介と同時にデモを行う
想像で話すより実物を体感してもらう
「自動化は手軽」と誤解されないように！
この背景は幕間です。無視してOKです。
関西検証コレクションの「テスト自動化パターン言語プロジェクト」より。
全体は http://kencolle.github.io/AutomationPatternLanguage/ で公開してます。

21.
自動化の目的

22.
パターンA
現在、心を込めて手作業しているものを
自動化する
機械に同じものを作ってもらって
とっとと帰っる。帰って遊ぶ。

23.
パターンB
現在、手でやるのは難しいことを
自動化することで可能にし
非効率な作業の代替とすることで
とっとと帰っる。帰って寝る。

24.
自動化の目的は
早く帰ること！
※個人の見解です

25.
自動化対象は
すべての活動
早く帰るために
なりふりかまってられない

26.
「Javaな開発の自動化」
でもまだ広すぎる！

27.
なので適当に挙げる
構成管理
コーディング
テスト
ビルド
CI
環境構築
こいつらの自動化について

28.
<<ビッグバン自動化>>
一気に全部まとめて自動化しようとする
トップダウンだとなりがち
自動化の構築難度はけっこう高い
不具合があった時、プロダクトの問題なの
か、自動化システムの問題なのかがわかり
づらくなる
余計なものまで自動化してしまう
システムの8割は使われないとかいうアレ

29.
自動化の事情

30.
テンプレート説明
まず
解決したい課題を話します
次に
それっぽい解決案を話します
最後に
「そうは言っても……」な現実を話します

31.
case 環境構築:

32.
環境構築
開発環境
IDE
JDK
ビルドツール
APServer
DBServer
Office
…
検証環境
JDK
APServer
DBServer
各種設定
本番環境
JDK
APServer
DBServer
各種設定

33.
環境構築-課題(1/2)
開発環境の構築は手順書に従って行う
たまに手順書すらない
構築に数日かかったりする
端末の変更や新規メンバーの受け入れ時に
発生する
コストが読みづらい

34.
環境構築-課題(2/2)
複数バージョンの検証環境を動作させたい
検証環境のリソースが取り合いであり、自動
テスト環境も競合している
本番環境と検証環境に差異がある

35.
環境構築-解決
プロビジョニングツール
環境構築をスクリプト化する
複数環境の高速構築や再現が可能
仮想化技術/コンテナ技術
（プロビジョニングに含まれるらしいが）
ハードがなくても専用環境が作成できる

36.
使ってみた話

37.
動機
検証環境を気をつけて扱う必要があった
変更が声かけ運用
人数に比例してつらくなる
よくわからない秘伝のタレ設定
本番との差異で死ぬ
テストユーザーにroot/DBA権限ついてたり

38.
使ってみたところ
クリーンすぎて困った
既存のデータで確認できない
他のデータがあるときに落ちる、なんての
が拾えない可能性が出てくる
テストの手を抜いている証拠だけど、そ
れで賄ってる現実もある
Windowsのせいで苦労マシマシ
32bitだとインストールすら…

39.
環境構築-現実
手順書ベースの環境構築やそれに掛かるコス
トが当たり前になっている
回数の少ないイベント扱い
自動化の優先順位が低い
一プロジェクトだとコスト重い
そのうち状況は変わる（願望

40.
環境構築-現実
仮想サーバーなどは端末のマシンスペックが厳し
かったりする
プロビジョニングツールは足音だけ聞こえる
組織の壁
検証環境と本番環境で管轄が違う
ツールの全面適用が厳しい
経験が積めなくて実績が挙げられなくて
壁を崩せない
break;

41.
case 構成管理:

42.
構成管理-前提
構成管理における課題であるバージョニング
と変更の追跡は、Java以前からバージョン管
理ツール(VCS)が解決している
昔はファイルサーバーで扱って、こんがら
がったりしてた
ソフトウェア構成管理（SCM）だと広がりすぎるので
ソースコードとライブラリに限定します

43.
VCSは使うよね
svnでもgitでもいいけど
Javaで使ってない現場にあったことはない
資産管理とかがファイルサーバーはままある

44.
VCSの変遷
cvs→svnはいつの間にか変わってた感ある
svn→gitは気合がいるっぽい
でも流れは結構強い
git採用してるところも増えてる

45.
git未経験の方は
「git使ったことないです！」って人
どうせsvnでもたいしたことしてない
逆に1ヶ月もあれば遜色なく使える

46.
構成管理-課題
複数人の同時開発でコンフリクトが発生する
予期しない上書きによってデグレが起こっ
たりしているのは避けたい
結果、同じファイルの編集をしないように
ロック的な運用をしている
内部で作成したライブラリの管理が未定義

47.
構成管理-解決
DVCSを使用した上で、プロダクトにあったブ
ランチ戦略をとる
コンフリクトもコミットから修正可能
Gerritなどを導入して検証済みマージを行う
ライブラリはリポジトリ管理ツールを使う

48.
リポジトリ管理ツール
NexusとかArtifactoryとか
内部ライブラリがあるなら使う
centralとかに置けないからね
インハウスリポジトリと言ったりも

49.
構成管理-現実
「コミットしちゃいけないファイル」のある
運用に慣れている人が多い
ローカル用の設定変更とかね……
どのファイルをコミットするか選択してから
コミットする（よく見ますよね？
差分があるのに違和感ない
なのでコミット漏れとかなくならない

50.
構成管理-現実
gitのcommit/push/pullとかはできる
branch操作もそんな問題なく
GUI(IDE)での操作のせいかトラブルに弱い
コンフリクトは手作業マージ、たまに事故
これは変わってない

51.
構成管理-現実
リポジトリ管理ツールは“わかってる人”だ
けが触るものになりがち
Mavenのバージョニングを知らない人も多い
リリースバージョンを上書きしたり
“-SNAPSHOT”知らなかったり
あまり機会ないから仕方ないのかなと思っ
たりもしなくはない
break;

52.
case ビルド:

53.
ビルド
ここでやる
あらゆること

54.
ところで手動ビルド？
コンパイラも自動ビルドツール
だからこれも自動ビルド
でも手動の部分も多い
自動化は手動の部分を減らすこと
javac Hello.java

55.
ビルド-前提
javac/jarによるコンパイル/パッケージング
の自動化は早期にantが解決していた
ビルドツールを使わないことなんてない
ゆえに一番無意識に使われている自動化かも

56.
ビルド-課題
ビルド時に行いたいことはコンパイルとパッ
ケージングだけではない
他にも同時にしたいことが色々ある
依存ライブラリを管理したい
もうjar-hellはこりごりだ

57.
ビルド-解決
プラグインやタスクの追加ができるようになっ
ているので、それで解決できる
Gradleかなり柔軟だしオススメ
依存解決はMavenだとdependencyManagementと
かである程度は制御できる

58.
ビルド-現実
ビルドツールは使いこなされていない
IDEに読み込ませて依存解決する程度
依存階層の出し方とか意外と知らない
pom.xmlとかは特定の人しか触らない
その人がやりすぎて妙に複雑になっている
（私のことだ！）
経験を積みにくいので、知らないのもある程
度は仕方ないのかも
break;

59.
case CI:

60.
継続的インテグレーション
CI
テスト
ビルド 環境構築
構成管理
色々する
色々使って

61.
自動化の執事さん
自動化といえばこれ！
ってイメージもあるのでは
Jenkinsのほかも最近よく聞く
自動ビルドツールを使って自動テストを実行
して、デプロイメントパイプライン通してワ
ンクリックデプロイ云々

62.
CI-課題
自動化された構成管理システムやビルドツー
ル、テストなどと強調して継続的統合を行い
たい
昔はライブラリアンとかが手動で行ってお
り、属人化の代表でもあった
ワンクリックデプロイを実現したい

63.
CI-解決
CIサーバーは市民権を得ている感じ
昔からあるビルドサーバーだけど
プラグインは豊富にあり、他の自動化システ
ムと協調も容易
シェルスクリプトなどにしておけば誰でも何
をしているのかわかる
属人性を排除できる

64.
CI-現実
属人性の排除はできていない
何でもかんでもCI職人に集中する
一方でスクリプトなら読むって人も居る
プラグインは数年のうちに情報ノイズが増え
たり、動作しなくなったりしている
ワンクリックデプロイは環境の壁がやっぱき
つい
break;

65.
case コーディング:

66.
設計書から自動生成だ！
気持ちはわからないではない
設計書のまま実装するのが正ならね？
Javaは冗長とか言われてた
でも *.java を生成するくらいなら低級言
語使ったほうがよくない？
一昔前は必要だったね
XML地獄とかも

67.
*.javaの生成って……
Javaファイルの生成は積極的に避けるべき
するにしてもclass/jarを生成してジェネ
レーションギャップパターン
できない？そもそもを見直そう
画一的な雛形のようなコードを生成したくな
るのはフレームワークの力不足
イマドキは雛形の内側だけ書けばよい
役目を終えた過渡期の技術感ある

68.
IDEによる自動記述
IDEのコード生成もコーディング自動化
単なるクラス名補完機や自動インポートエディ
タではありません
使うフレームワークや作るアプリケーション
によってカスタマイズしてみてもよい
思ってる以上に世界変わるよ
タイピング速度を上げるよりお手軽

69.
IDEを使い倒そう
冗長と言われるコードのほとんどがIDEを使え
ば一瞬で書けてしまう
「Javaは冗長だから実装に時間がかかる」は
「Javaできません」に近い
JavaのコーディングはIDEなしで語れない
そういう言語なので受け入れよう

70.
コーディング-課題
大量のコードを作成する必要があり
大量の設定ファイルを作成する必要があり
品質は均一化しなければならない
……まあお仕事でよくある話。

71.
コーディング-解決
パワフルなフレームワークを使用することで
一昔前より大幅に実装量を削減できる
Javaの表現力も向上しているし、Scalaや
GroovyなどのJVM言語を選択してもよい
IDEの支援を適切に受けられればタイプ量はす
ごく少なく済ませられる
Pluggable Annotation Processingなどでコ
ンパイル時の生成が可能

72.
コーディング-現実
昔に作られたソースコード自動生成ツールや、
その焼き直しが大事に使われている
「昔やったこととまるっきり同じこと」に
安定と安心を求めたり
完全上位互換でなければNGになったり
IDEの機能はあまり使われていない
せいぜいクラス名の補完くらい
妙にデバッガは使われてるけど
break;

73.
case テスト:

74.
“自動テスト”は
よく話題にあがる

75.
今回は
あまり踏み込まない
踏み込めないが正しい

76.
システムテスト自動化カンファレンス
ってのが2015/12/13に……もう満席だけど

77.
jUnitなテスト
見かけることは増えてきた
影も形もないってのは稀な感じ
でもイマイチ上手くいってなさげ

78.
ここにも自動生成の闇
自動生成されたjUnitのコードを稀によく見る
たぶんExcelマクロとかで
メンテ不可
何してるかわからない
再生成の方法も失われてたりする
無駄に量は多い

79.
自動生成は嫌い
Parameterizedとかでカバーできる
一覧性を気にするならSpockとかあるよ
Excelが見やすければ直接読み込めばよい
妙な外部DSL（Excelね）をコンパイルしてJava
コード吐くとか、何したいの？

80.
最近の話題
そいやjUnit5の声も聞こえてきました
未評価なのでなんとも言えないけど
@Test
@Name("My 1st JUnit 5 test! 😎")
void myFirstTest(@TestName String testName) {
assertEquals(2, 1 + 1, "1 + 1 should equal 2");
assertEquals("My 1st JUnit 5 test! 😎", testName,
() -> "testName is injected correctly");
} https://github.com/junit-team/junit5-samples

81.
ブラウザを使うやつ
Seleniumは市民権を得てきてる感ある
けどなかなかうまくできないよね
結構クセ強いし結構不安定だし
Geb突っ込んでみたら意外と馴染んだりする
どこまで画面でテストするか？
全部やろうとして死んでるのよく見る

82.
テスト-課題
テストを自動化してテスト工数を圧縮したい
テストを自動化しようとしているが、実装に
時間がかかるので短縮したい
テストを自動化しているが実行に時間がかか
るので短縮したい

83.
テスト-返答
テスト工数を圧縮したい
自動化してもすぐは工数減らないよ？
実装工数に時間がかかる
道具に不慣れなんだから仕方ない
手動で曖昧に済ませてたツケ
実行に時間がかかる
（これは普通になんとか）

84.
テスト自動化
8つの誤解

85.
自動化は壊れたプロセスを直す
完全に自動化できなければ成功ではない
自動テストは多くの欠陥を見つける
自動テストは手動テストを置き換える
記録&再生は効果的な手法である
ひとつツールで全フェーズをまかなえる
自動化ですぐにスケジュールが前倒しになる
自動化のコストはツールとスクリプトだけだ

86.
テスト自動化扱いづらい
自動化の文脈でも特に話題にあがりやすい
それだけ困っているってことかな
よく話題にあがるけど
方向も様々、深さも結構なもの
他の自動化はそこまで詰められていないとも
言えるかも

87.
テスト自動化は過度な期
待をかけられやすい
8つの誤解の他にも

88.
範囲を限定して
制御してみる

89.
よくあるプロセス
テストケース作成
テストスクリプト作成
テスト実行
テスト結果の検証
テストレポートの作成

90.
自動化範囲検討(1/2)
テストケースの自動化
厳しいってかサポートが得られるくらい
テストコーディングの自動化
こっち方面は闇が広がってるから諦めよう
実行の自動化
だいたいできてる

91.
自動化範囲検討(2/2)
検証の自動化
assertionのないテストスクリプト、まれに
よくある
作った人「目検すればいいじゃん」
報告の自動化
エビデンスの自動取得はできなくはない
その先はなんとかしよう

92.
とっかかりの範囲
テストケースの自動化 -> 範囲外
テストコーディングの自動化 -> 範囲外
実行の自動化 -> ほぼいける
検証の自動化 -> だいたいやる
報告の自動化 -> 補助程度
状況次第ですが

93.
期待マネジメントむずい
うまくいったりいかなかったり
試行錯誤中です

94.
テスト自動化-現実
自動化以前の問題がテストの自動化に取り組
むとあぶり出されるのはよくある
なぜか「自動化で苦労している」とか言い
出す
ふしぎ！
そして「自動化はコストに見合わない」と
か言い出す
ふしぎ！！
break;

95.
<<自動化ハイ>>
自動化してみた
なんか楽しくて仕方ない
あれもこれも自動化したい！！
できたあああああ！！！
次だああああああ！！！！←これ
ここまではいいが、これで作られたものは建
て増し旅館になりがち

96.
自動化事情のまとめ

97.
高速道路はある

98.
たまに途中で終わる

99.
降りてからは迷路

100.
こんな現実
ありますよね？

101.
どう戦っていますか？

102.
理想に近づけてますか？

103.
楽になっていますか？

104.
何のための自動化？

105.
とか煽るだけ煽って、別の話をします。

106.
<<験担ぎ>>
実行だけされている自動テスト
何のための自動テストかわかっていない
エラーが発生したときに「このエラーは大丈
夫」など言い出したら黄色信号
ゲートウェイとして機能しなくなる
テストを通すのが目的になり、不具合があっ
てもテストを修正してしまうように……

107.
“自動化担当”観察記録

108.
この話は妄想です

109.
序章:自動化の夢と現実

110.
自動化に夢を見た
マネージャー

111.
チームに求められた
自動化

112.
経験者不在

113.
手探りの自動化

114.
期待通りの動作！

115.
期待はずれの成果……

116.
徐々に失速

117.
序章まとめ
GettingStartedレベルはそのまま動く。
でも、どのように使ってどう効果を出し、
どう評価するかの手順書は無い。
現場によるしね。
期待マネジメントの失敗。
過度な期待を負わされ、適切なリソースが
得られず、不得意分野で成果をあげられず、
期待はずれと評されるわけだ。

118.
一章:着任、自動化担当

119.
自動化担当を召喚

120.
現状分析

121.
役割の被るもの

122.
やたら時間のかかるもの

123.
半自動（半手動）なもの

124.
不安定なもの

125.
何しているか誰も
わからないもの

126.
運用がおかしいもの

127.
整理した

128.
一章まとめ
浅い知識での自動化は、簡単なことならとも
かく、すぐに複雑化する
Javaコードでいうと「同じコトをする大量の
ユーティリティクラスがコピペで作られる」
状態に近い
まずそのリファクタリング（と言うかリスト
ラクチャリング）を行った

129.
二章:自動化の力

130.
秩序を保つCIサーバー

131.
様々なツールを導入

132.
エラーを知らせる
パトランプ

133.
叫ぶCIサーバー

134.
即時対応するチーム

135.
デプロイメント
パイプラインの構築

136.
本番リリース
ワンクリックデプロイ

137.
順風満帆

138.
二章まとめ
無作為な自動化適用ではなく、強みをより生
かす方向へ成長させる。
自動化されたユニットテストは存在したが、
即時実行と即時通知によりフィードバック
ループは加速。
システムテストの自動化が同じ基盤に追加
され、エビデンスも取得される。
ワンクリックデプロイも可能となり、教科書
的な自動化はこの時点で達成された。

139.
三章:崩壊の足音

140.
自動化を推進してきた
マネージャーの交代

141.
援護射撃を失う
自動化担当

142.
自動化を維持する
フォースの消失

143.
自動化のリソース激減

144.
メンテされなくなる
自動化システム

145.
通らなくなる自動テスト

146.
-Dmaven.test.skip=true

147.
黙らされたCIサーバー

148.
三章まとめ
自動化を維持するにはコストが必要
だけどそれが確保できなくなった
テスト自動化のよくある誤解に「一度自動化
したらあとはずっと動く」があるが、まさに
それ
当然のように開発業務が優先され、自動化の維
持をするよりも1機能でも多く作ることが求め
られた
結果として、放棄されてしまった

149.
終章:残ったもの

150.
自動化担当の解任

151.
朽ちていく
自動化システム

152.
直近の成功ビルド
“10日前”

153.
最新ソース
コンパイル不能

154.
トリガーの残る
ワンクリックデプロイ

155.
完

156.
色々聞いてみた

157.
チームにヒアリング
マネージャーとユーザーが徒党を組んでやめ
させにきた
プレッシャーに抗えない文化がある
指示に反対して失敗しても責任が取れない
責任を取る手段も持たない
だから行動できない

158.
マネージャーにヒアリング
自動化は価値をアピールしづらい
聞いても人によってまちまちな説明だし、
チームは説明下手であり、理解しがたい言
葉で話してくる。
純粋な質問である「それって価値あるの？」
が、チームには止めろという指示に捉えられ
ているようだ

159.
ユーザーにヒアリング
いいものをより早く作ってほしいだけ
なので、無駄なことをやって生産性が下が
るならやめてほしい
期待している成果が挙がらないからやり方に
も口出しせざるをえない

160.
この話は妄想です

161.
考えてみてください

162.
どうしようもない？
マネージャーの交代がなければそのまま順調
にいったのでしょうか？
状況が変わるのは仕方ない
けど、その程度で崩壊していいの？
なんかワンクリックデプロイは残ったけど、
何で残った？

163.
順調だった？
混乱してた自動化システムの統制が取れた
エビデンスの自動取得もできたし
ワンクリックデプロイもできた
……これって順調なの？
なんか落とし穴ない？

164.
経験者は必須？
未経験のチームが作った自動化システムはイ
マイチだったようだけど、経験者が居ないと
だめなの？
必要な情報が足りない？
経験者は他の現場の“スペシャル”を意気
揚々と持ち込んできたりするよ？

165.
なげっぱで次に行きます

166.
私が本当に
言いたかったこと

167.
自動化は好きですか？

168.
楽になっていますか？
早く帰れてる？

169.
苦労してますよね？
楽しいかはさておき

170.
苦労してるの
私だけじゃないですよね？
（必死）

171.
求)苦労話
現実をなんとかしようと
なにかしている
機会があればこうしようと思っている
やってみたらこんなことになった
そういう話をして
次を考える材料にしたい

172.
時間切れのため終了
続きは現場で
考えていきましょ