仁斤曰く 「”手間業”蔓延り易く、 “楽”成り難し」
•
21 gostaram•8,604 visualizações
DeveLove関西 今日から始める自動化～自動化入門講座～ (2013/07/18) にて発表した資料です。 申し込みサイト : http://devlove-kansai.doorkeeper.jp/events/4500
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (12)
Destaque
Destaque (20)
Mais de Kazuhito Miura
Mais de Kazuhito Miura (20)
Último
Último (9)
仁斤曰く 「”手間業”蔓延り易く、 “楽”成り難し」
- 2. 自己紹介 三浦 一仁(ミウラ カズヒト) ● @kazuhito_m ● ３５歳児、独身 ● 慢性中二病患者 ● 「おもろい＆便利」 至上主義者 ● 自動化厨(Jenkins大好き!) ● 得意技：手段の目的化 ● 弱点：手段の目的化 ● 苦手：英語と算数 ● ハーモニカが好き ● 株式会社ヨドック 所属 ● 興味あるもの – 無入力ライフログ – 組込以上,PC未満ガジェット ● 例：ラズパイ等 – 「自動的に～」な便利な仕組 – 歌(PG)って踊(インフラ)れる エンジニア – “軸”はLinuxとRuby (最近サボリぎみ)
- 3. 自己紹介 三浦 一仁(ミウラ カズヒト) ● @kazuhito_m ● ３５歳児、独身 ● 慢性中二病患者 ● 「おもろい＆便利」 至上主義者 ● 自動化厨(Jenkins大好き!) ● 得意技：手段の目的化 ● 弱点：手段の目的化 ● 苦手：英語と算数 ● ハーモニカが好き ● 株式会社ヨドック 所属 ● 興味あるもの – 無入力ライフログ – 組込以上,PC未満ガジェット ● 例：ラズパイ等 – 「自動的に～」な便利な仕組 – 歌(PG)って踊(インフラ)れる エンジニア – “軸”はLinuxとRuby (最近サボリぎみ) コイツ、胡散臭い
- 4. しゃーから、オマエだれよ？ 青春の思い出 ● 最初に入った会社が「なんでも自社で作ってまう」ヤ ツらだった – テーブルデザイナ&類似クラス生成機＆API ● まだ「概念が無かった」時代のORM – 印刷フォーマッタ＆デザイナ ● まだ「こなれて無い」時代のSVF – RationalRoseから[自社ご作法のVB5]吐き機 ● 今考えるとRailsっぽい – VB5のForm定型化＆独自コールバックパターンセット ● まだ「名前が無かった」時代のGuiFW – 自動インストーラ作成・後チェッカー結合 ● 若干CI、今考えるとスモークテスト ● ぼーっとしてると「共通ツール作り係」に放逐 – 絶えずデスマ→大阪デスォﾝリーランド
- 6. ぶっちゃけ… ● この壇上に立つような人ではない – 自動化なんてそない出来てないし… ● じゃあなんでここに立ってんの？ ● 「自動化したい！」 「自動化大好き♪」 の思いをぶつけにきた！
- 7. チャプター1 1.茶番
- 10. 仁均と言えば… ● 仁均の偉大なる功績 – 自動化に関する ● 書籍 ● 設計図 ● かの有名な「仁均図」 – それが世界中にひろがって いまでは…
- 11. じぇ、Jenkinsさん！
- 15. チャプター2 2.マインド①
- 25. これ アカンヤツ や！ もとい…
- 29. 声を大にして言いたい！ ● さらに「作業のための作業」 に脅かされてない？ – 「何故するのか」を誰も答えられない作業 ● 例： – 電子から紙に出力→ハンコ等→電子に書戻 – A資料の和名→B資料の英名→C資料の和名 言葉を定義します…
- 34. チャプター3 3.やったこと
- 35. 背景となるプロジェクト-あらまし ● 仮に ProjectX とします – 基幹システム(COBOL)のリプレース – 言語はJava、データはRDBMS(某社製) – このプロジェクト用の独自FW ● ５～６年前のJava界トレンドが… –Maven2,Struts,Spring,ORM(自作 – ソース管理はSubversion – Web画面とバッチ処理
- 43. 多少難しいが… ● ＯＫ！ 機 構 作 成 時 間 1度目 実行 自 分 で 手 作 業 再利 用分 ※ただし、 「未来再利用される時間」 を見積もるのは難しい… (要素:人数,回数,単位時間)
- 50. ● 技術者は… – 解らな過ぎ…→ブチ切れる – 親切過ぎ…→気に要らない ● という 「小鹿の様に繊細な生き物」 ● 使用が技術者なら「絶妙なええ感じ」を – ビジネス未満、プログラミング以上 – UIあるものなら「あまり頑張らない」 – ReadMeを越えない程度の使い勝手 わかったこと
- 54. 開発も後半に差し掛かり… ● 「性能対応チーム」に配属され… “バッチの性能問題”と戦う – 機能モジュール ● 「性能対応チーム」(自身)で対策 – 共通モジュール ● 「共通チーム」に打診して高速化 してもらう ● “個々対応”が遅く、順番待ち – 「手間」かつ「非効率」
- 55. そこで ● 「一律」に「簡単」に高速化機構 を入れる方法はないか… – 上流設計者でも手軽に出来るく らい ● AOP/DIに注目 – ProjextX では最初から ほぼすべてのオブジェクトに 仕込済み
- 61. またも問題… ● 事故が多発！ – 本番環境に流出 ● 依存性に「出ちゃダメモジュール」書く ● テスト用設定を残したままビルド ● 何とかしなきゃ – 偉い人ら ● 「チェックシート」「教育」とか言い出す – 俺 ● 「普通機械が何とかしてくれんじゃね？」 ● てことは… – フレームワークか！ ● アーキT「ダメ～変えさせませ～んw」
- 65. でも… ● 「チェックしてくれるモノを作った」けど – 「開発終わり時」に「手動で」じゃ… ● 結局人間系 → 元の木阿弥 ● 「～する時に」「自動的に」 「怒ってくれ」て「それ以上進めない」 を狙わないと… ● 「透過的」にしたいんだ
- 67. ここでさっきの ● ProjectXで扱う「実装するプログラム」は… JavaProject pom.xml Lan内 社内独自リポジトリ 共通pom.xml ※pom.xmlとは ビルドの方法と モジュール同士の依存関係 を書いたMavenの 設定ファイル 個々プロジェクトの 依存関係 全共通の依存 全共通の ビルド方法 のツール・枠組みを使う領域 ● 同じ方法で数千のJavaProjectをビルドしている 継承 ここに注目！ ● 全体共通の「ビルド設定」に 「チェックを蹴る」を追加 – Package or Release時 –不合格はリリース不可 ● 使ってる方は「意識しない」 –ある日勝手に入る、更新される –無エラーの人は今と変わらない
- 70. またまた問題… ● ProjectXは3000を越えるモジュール群 – 影響調査が絶望的 ● 一応「仕様書(Excel)パースしデータ 化」する仕組みもあるが… – それでも「精度悪」かったり 「時間掛か」ったり ● 最終的に「ソースが最後の砦」 – ソース容量→ギガ越え – 個々上流開発者がローカルに落とし て、テキストエディタで検索…
- 74. タイトルなげーわ… ● ProjectXでは「自動テスト」標準装備 – だが回して無い ● 夜間テストして結果を録りたい – そんな環境無い ● Jenkinsを使おう！ ● JavaProjectが日々増えていくのだけど… – Jenkinsのジョブは1JavaProject:1ジョブ – 増えて行くたび、手動で登録？ ● ソース管理に追加されたら、 Jenkins側も自動的に追随する機構を作ろう！
- 75. 続きはWebで ● と、言うモノを以前 「第4回 大阪Jenkins勉強会」で発表しました – まとめサイト ● https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=6566 9255 – 資料 ● http://www.slideshare.net/miurakazuhito/fat-jenkins
- 80. ※pom.xmlとは ビルドの方法と モジュール同士の依存関係 を書いたMavenの 設定ファイル また突然ですが… ● ProjectXで扱う「デプロイする物体」は… Lan内 社内独自リポジトリ 全社基底pom.xml のツール・枠組みを使う領域 継承 システム基底pom.xml Web用 集合体pom.xml バッチ用 集合体pom.xml 継承 継承 ビルド ビルド 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M
- 81. ※pom.xmlとは ビルドの方法と モジュール同士の依存関係 を書いたMavenの 設定ファイル また突然ですが… ● ProjectXで扱う「デプロイする物体」は… Lan内 社内独自リポジトリ 全社基底pom.xml のツール・枠組みを使う領域 継承 システム基底pom.xml Web用 集合体pom.xml バッチ用 集合体pom.xml 継承 継承 ビルド war jar群 ビルド 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M
- 82. ※pom.xmlとは ビルドの方法と モジュール同士の依存関係 を書いたMavenの 設定ファイル また突然ですが… ● ProjectXで扱う「デプロイする物体」は… Lan内 社内独自リポジトリ 全社基底pom.xml のツール・枠組みを使う領域 継承 システム基底pom.xml Web用 集合体pom.xml バッチ用 集合体pom.xml 継承 継承 ビルド war jar群 ビルド 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 共通M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M 機能M ● このセットが「環境ごと」に –本番、ステージング、 テスト、etc...
- 83. まあプログラマーは変わりませんが ● 「自動化業」のおかげか… – 「基底pom.xml管理者」 なる係になりました ● どんな仕事？ – 「ライブラリの整合性を判断 し、号令出す」 – いくつかのpom.xml編集係 & テスト環境一つのお守り
- 91. ここでの知見 ● “作るか否か”の判断 – まずは「世に道具があるか」をググる ● 「悪魔の証明」になり得るので時間を切る ● その結果にて数択の行動 – 1.ドンピシャ(やりたい事を実現したものが既に在り) ● そのまま使う(作らない・改造しない) – 2.一部機能が類似 ● 外科手術 - その一部だけ使う方法の模索 ● 内臓移植 – (OSS等なら)その部分のソースだけ 「上手く取り出せないか」模索 – ライセンスに注意 – 3.世に無なさそう ● フルスクラッチ(完全自作) ● ※1,2でも「頑張りたい理由」があるなら自作でOK
- 98. すこし違う仕事が ● 今までは「自分・チームのため」と提案型 ● 今回、上から「改善の指令」が ● 指令内容：「テスト環境の運用を改善せよ」 – 現在の問題 ● 一つの環境(Webアプリが一つ動く環境)の作成に時間と 人数がかかる – 今後、環境をダース単位で即時に作成する必要あり – 「専門の係」でなく「依頼者」でも環境を作れるように 対応せよ！ ● 今までと違う条件 – アーキテクトチームと協力せよ – 「業務改善」して良い、むしろせよ ● 業務や「環境」の形・定義すら変えて良い
- 103. これで新プロセス完成 ● 業務改善が終了 – →この業務を自動化する ● 自動化 – 個々「現在の担当者」が「コンソールか ら実行」出来る形のプログラム化 ● 全員「何かしらプログラムが組める」 ため ● 引数・戻り値(ファイル)だけは厳密に – Jenkinsで繋いで実行
- 106. 伝えたいこと ● 「局所」「広域」の自動化 – これにより考えるべきことが変化する – 局所 ● 「自分」「自チーム」など ● 自分たちの「良い」を探求 – 広域 ● 「大規模プロジェクト全体」「社全体」など ● トータルデザイン必須 – (既存業務があるなら)業務改善とセット – 親和性を考慮 ● 道具の繋がり・出自の遠さは使う方も苦しい ● CUI行ってGUI行って、MS製品行ってOSS行っ て、OPEN行って汎用機行って…は辛い ● 出来るだけ寄せる
- 107. 仁均曰く「自動家たるもの…」 ● 業務改善が可能なら、 そちらを優先 –「ECRSの原則」等を利用 ● 「広域」「局所」の自動化を意識 する –Project全体で…とかなると 親和性などの考慮必要
- 108. チャプター4 4.マインド②
- 109. なぜ自動化するのか
- 110. なぜ自動化するのか ● 自動化のメリット – 工数削減 – 省力化(簡易化) – ミステイク撲滅 – 作業の明確化（暗黙知の明文化） ● 副産物（技術者視点） – 比較的新しい技術に触れる (事が多い) – 外科手術/内臓移植が得意になり、 先人の「賢い！」を自分のものに
- 114. 自動家の視点
- 115. 自動家の視点 ● 道具や機構、なにか"モノ"を見た場合 – 「～に使えるか」 ● 「繋げるか・繋がるか」「蹴れるか」 「吐けるか」「読めるか」「検知できるか」 「楽に操作できるか」 – コレとコレ組合わせればいけんじゃね？ ● 興味の質はこういうものになってくる例 – 「読める」「吐ける」 ● API,CSV,REST,スクレイピング – 「蹴れる」 ● Webインターフェイス – 「楽に操作できるか」 ● パーサ、オーサリングツール
- 118. 自動家を阻むもの
- 119. 自動化を阻むもの ● 対象作業の性質 – 複雑 – 流動 要は「不確定」→「ファジィ」 なとこ ● 人間 – 「手動が機械より信用できる」 と思ってる人
- 120. 自動化を阻むもの ● 打ち破るために… こう「思いこんで」おく – 「人間がやっていることで 『ファジィなとこ』以外は、 100%自動化出来る」 ● …時間さえかければ – 「技術は万能」である ● とにかく「自分の脳内」でだ けは芯に置いておく
- 122. 自動家のイデオロギー
- 125. 反対の度合い ● ほっとくと…
- 131. 延長戦
- 132. チャプター5 5.最近思うこと
- 133. いろいろやってみて… ● 「自分or他人の仕事をプログラムに書き起こす のは「仕事の方法を文書化する」より、 低コストで値打ちがあるのでは？ – ただし「プログラムが読める」という文化は必須 ● 自動化して時点で数十倍 →さらにワンチャンある – 「仕事をリバースエンジニアリング」 – 「仕事にテストを付ける」 – 「仕事をチューニング」 …という新しい概念が生まれる
- 134. 願望 ● 会社が儲かったらどうする？ – 設備投資 – 増員 – 教育 まあそうですよね… ● その中に 「技術者一人『工夫屋さん』として雇う」 てのがあっても良いのではないか？ …ま、普通は出来ませんけど
- 137. 完全に趣味 ● 現在目を付けていること – メーレット ● メールをトリガーとして動くプログラム ● 古典的だが「意外と無い」「定番が無い」 ● 実現するプロダクト – GAE,James – 全文検索エンジン ● 手軽になったから ● 実現するプロダクト – Apache Lucene/solr , groonga – Linuxが乗るミニPCとプログラマブルなUSBデバイス ● 自動家にとって「物理」を操作→夢がひろがりんぐ ● 「機械」で無く「OS搭載PC」、「装置」で無く「API有 USBデバイス」の土俵なら… ● 実現するプロダクト – RaspberryPi 等
- 138. 今後 ● 自動がさらに進化すれば – 仕様書書いただけで自動テストできるかも？ ● やりたいのは 「思いそのまま劣化させずテストにする」 こと – それが出来ないから 「仕様書(紙)と手動のテスト」 を選択してるだけ ● 道具が進化して 「書/描いたモノがそのままテストになる」 とかになると変わるはず – DSLでなく「自然言語の解析」や「優れた フォーマット」によって
- 139. 自動家が目指すモノ ● 自動化って行きつく先は… – 「センサー学」みたいになるのでは？ ● 「生きてるだけで」「息するだけで」 駆動する、データが取れる –「～を検知して」というpush型考え ● それ無理でも 「一挙手一投足きっかけ」で –ジェスチャーとかの概念に近い
- 142. あまり、詳しくないしな… ● 今回は「ソフトウェア開発の自動化」という観点において 「絶対に必要な」以下の概念をあえて抜きました ● ご興味ある方は対応する勉強会で補完願います ● テスト自動化 – TABOK勉強会関西 ● http://connpass.com/series/151/ – WARAI(関西ソフトウェアテスト勉強会） ● http://kokucheese.com/main/host/WARAI%E5%AE%9F%E8%A1%8C%E5%A7%94%E5%93%A1/ ● 継続的インテグレーション(CI) – 大阪Jenkins勉強会 ● http://connpass.com/series/264/ ● 継続的デリバリー – 【大阪】継続的デリバリー読書会 ※現在は”実践編” ● http://connpass.com/series/190/
- 144. ボツ稿
- 146. もちろん「科学サイド」