Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

仁斤曰く 「”手間業”蔓延り易く、 “楽”成り難し」

7,516 views

Published on

DeveLove関西 今日から始める自動化~自動化入門講座~ (2013/07/18) にて発表した資料です。
申し込みサイト : http://devlove-kansai.doorkeeper.jp/events/4500

Published in: Technology

仁斤曰く 「”手間業”蔓延り易く、 “楽”成り難し」

  1. 1. 今日から始める自動化~自動化入門講座~ 仁斤曰く 「”手間業”蔓延り易く、 “楽”成り難し」 Ver 1.1
  2. 2. 自己紹介 三浦 一仁(ミウラ カズヒト) ● @kazuhito_m ● 35歳児、独身 ● 慢性中二病患者 ● 「おもろい&便利」 至上主義者 ● 自動化厨(Jenkins大好き!) ● 得意技:手段の目的化 ● 弱点:手段の目的化 ● 苦手:英語と算数 ● ハーモニカが好き ● 株式会社ヨドック 所属 ● 興味あるもの – 無入力ライフログ – 組込以上,PC未満ガジェット ● 例:ラズパイ等 – 「自動的に~」な便利な仕組 – 歌(PG)って踊(インフラ)れる エンジニア – “軸”はLinuxとRuby (最近サボリぎみ)
  3. 3. 自己紹介 三浦 一仁(ミウラ カズヒト) ● @kazuhito_m ● 35歳児、独身 ● 慢性中二病患者 ● 「おもろい&便利」 至上主義者 ● 自動化厨(Jenkins大好き!) ● 得意技:手段の目的化 ● 弱点:手段の目的化 ● 苦手:英語と算数 ● ハーモニカが好き ● 株式会社ヨドック 所属 ● 興味あるもの – 無入力ライフログ – 組込以上,PC未満ガジェット ● 例:ラズパイ等 – 「自動的に~」な便利な仕組 – 歌(PG)って踊(インフラ)れる エンジニア – “軸”はLinuxとRuby (最近サボリぎみ) コイツ、胡散臭い
  4. 4. しゃーから、オマエだれよ? 青春の思い出 ● 最初に入った会社が「なんでも自社で作ってまう」ヤ ツらだった – テーブルデザイナ&類似クラス生成機&API ● まだ「概念が無かった」時代のORM – 印刷フォーマッタ&デザイナ ● まだ「こなれて無い」時代のSVF – RationalRoseから[自社ご作法のVB5]吐き機 ● 今考えるとRailsっぽい – VB5のForm定型化&独自コールバックパターンセット ● まだ「名前が無かった」時代のGuiFW – 自動インストーラ作成・後チェッカー結合 ● 若干CI、今考えるとスモークテスト ● ぼーっとしてると「共通ツール作り係」に放逐 – 絶えずデスマ→大阪デスォンリーランド
  5. 5. その後… ※事実であり、自虐や「特定の人々」をdisるものではありません。 ● 順調に劣化 – 今は中小企業の「客先常駐」PG ● 俗に言う… –IT土○、 Java○足 とか言われる存在 ● アーキテクトさんとかを 「かっこいー!」って 眺めてる存在
  6. 6. ぶっちゃけ… ● この壇上に立つような人ではない – 自動化なんてそない出来てないし… ● じゃあなんでここに立ってんの? ● 「自動化したい!」 「自動化大好き♪」 の思いをぶつけにきた!
  7. 7. チャプター1 1.茶番
  8. 8. 唐突ですが… 今から 昔話 しまーす。
  9. 9. 自動化の始祖といえば… 仁均(和尚)
  10. 10. 仁均と言えば… ● 仁均の偉大なる功績 – 自動化に関する ● 書籍 ● 設計図 ● かの有名な「仁均図」 – それが世界中にひろがって いまでは…
  11. 11. じぇ、Jenkinsさん!
  12. 12. じぇ、Jenkinsさん! という”テイ”で 本日は どうかひとつ…
  13. 13. ここまでは出れるけ~ど♪(by井戸の魔物) 今日の 発表資料 ツッコミ ドコロ ヌケ・モレ 間違い・穴 ミウラくん、それ穴やない… 未完成品や!
  14. 14. 他力本願(キリッ 今日の 発表資料 ツッコミ ドコロ ヌケ・モレ 間違い・穴 ミウラくん、それ穴やない… 未完成品や! みなさまの ツッコミにより 完成する システム
  15. 15. チャプター2 2.マインド①
  16. 16. さて皆さん-その1 ●「手作業」 は好きですか? ● 「面倒くさいこと」 は好きですか?
  17. 17. そらそうよ ●俺は 「大っ嫌い!」 です。
  18. 18. さて皆さん-その2 ● 「楽」 は好きですか?
  19. 19. そらそうよ ● 俺は 「大好き♪」 です
  20. 20. 安定の「本末転倒」メソッド ●どれくらいか –「楽」の為なら、 どんな苦労/面倒 も厭わない
  21. 21. さて皆さん-その3 ● 「技術」 は好きですか? ●「メカ」や 「自動で動くもの」 に憧れますか?
  22. 22. ええかげんもういいやろ… ● 俺は(ry
  23. 23. ながくなりましたが… ● 今の二つ以上に該当する方は 「自動化を 考える人・作る人」 に向いていると思います ● 言葉を定義します…
  24. 24. このオッサンはまた勝手な定義を… ● 自動化が大好きで、実際に考え、 機構を作り出す人の事を… 自動化厨 と… じ ど う か ち ゅ う
  25. 25. これ アカンヤツ や! もとい…
  26. 26. 自動  とここでは呼ばせてもらいます! 自動家 とここでは呼ばせてもらいます! これは一応引用で… ● 自動化が大好きで、実際に考え、 機構を作り出す人の事を… オ ー ト メ ー タ ー
  27. 27. そんな自動家の妄想は… ● 自動家が考える「これが普通」の世界 ● 仕事は 「極限まで自動化・最速化が効いていて 『人間様しかできません…お願い!』 なとこだけする」ものである
  28. 28. 現実はクソゲー ところが現実は… ● 仕事は 「"物体”を多く使い、動かし、 手作業の繰返しが多い」ものである
  29. 29. 声を大にして言いたい! ● さらに「作業のための作業」 に脅かされてない? – 「何故するのか」を誰も答えられない作業 ● 例: – 電子から紙に出力→ハンコ等→電子に書戻 – A資料の和名→B資料の英名→C資料の和名 言葉を定義します…
  30. 30. すいません、俺が勝手に考えました… ● 仕組/段取の不出来のために、本来 不必要な「手間なだけ」の手作業 手間業 と俺は叫びたい! て ま ぎ ょ う 
  31. 31. 短気かなんて関係ないっすよ! ● “手間業”にやられて 「目の前のPCを叩き割りたい衝動」 に刈られる… OK! その感覚、大事にしましょ♪
  32. 32. 仁均曰く「自動家たるもの…」 ● “自動家”は 「”手間行”の根絶」 を目的とすべし –そのため 「面倒くさい」の声に 敏感たれ
  33. 33. なぁに、簡単です ● おそらく、みなさんは 「お客様の業務を如何に良く…」 って日々考えてると思います ● 「自分達」に向けてみましょう♪ – 俺も苦手な気がします…
  34. 34. チャプター3 3.やったこと
  35. 35. 背景となるプロジェクト-あらまし ● 仮に ProjectX とします – 基幹システム(COBOL)のリプレース – 言語はJava、データはRDBMS(某社製) – このプロジェクト用の独自FW ● 5~6年前のJava界トレンドが… –Maven2,Struts,Spring,ORM(自作 – ソース管理はSubversion – Web画面とバッチ処理
  36. 36. というところに… ● ミウラは7年くらい居ます – 断続的、 1年くらい別のとこ→出戻り – 役目的にはプログラマー
  37. 37. やったこと ● やったこと例1 –勤怠転記機
  38. 38. 最初、きつくてね… ● 勤怠を15分単位で三つの管理表につけなさい 月別実績 日ごと WBS 日ごと 15分ごと 詳細実績 ● 時間が無い – →時間を細かくつけて、管理するんだ!
  39. 39. 最初、きつくてね… ● 勤怠を15分単位で三つの管理表につけなさい 月別実績 日ごと WBS 日ごと 15分ごと 詳細実績 ● 時間が無い – →時間を細かくつけて、管理するんだ! あーもう! イーてなる!
  40. 40. そこで ● 一番小さい「詳細実績」さえつけれ ば、半自動で集計できるように ● ちょっとデモ ● 最終的に 「WBS”自身が”二週に一回 自動的に集計表を送ってくる」 までやったったw ※Open時駆動
  41. 41. ここで言いたいのは… ● 「自動化する/機構作る」 か否かの判断 どうすんの?
  42. 42. 見積りをした上で ● 文句なしでOK! 機 構 作 成 時 間 1度目 実行自 分 で 手 作 業
  43. 43. 多少難しいが… ● OK! 機 構 作 成 時 間 1度目 実行 自 分 で 手 作 業 再利 用分 ※ただし、 「未来再利用される時間」 を見積もるのは難しい… (要素:人数,回数,単位時間)
  44. 44. さらに… ● 自動家ならここまでくらいOKなんじゃね? 機 構 作 成 時 間 1度目 実行 手 作 業 再利 用分 得る 知見 熱い 思い
  45. 45. 仁均曰く「自動家たるもの…」 ● “自動化するか”の 判断は重要視すべし – 個人・チーム・社などで 基準を意識
  46. 46. やったこと ● やったこと例2 –単語変換機
  47. 47. やっと本業 ● 設計・実装でこんな作業(書類書き)が… 実装/SQLに近い 詳細な仕様書 (日本語) SQL仕様書 (仕様とSQL) SQLの列・表 を日本語にし たたもの ● …を、人の手で実装時に作りなさい
  48. 48. やっと本業 ● 設計・実装でこんな作業(書類書き)が… 実装/SQLに近い 詳細な仕様書 (日本語) SQL仕様書 (仕様とSQL) SQLの列・表 を日本語にし たたもの ● …を、人の手で実装時に作りなさい 完全に 手間行だろ コレ!
  49. 49. そこで ● たまたま「全部Excel」だった ので… – 「単語変換機(マクロ)」作る ● ちょっとデモ
  50. 50. ● 技術者は… – 解らな過ぎ…→ブチ切れる – 親切過ぎ…→気に要らない ● という 「小鹿の様に繊細な生き物」 ● 使用が技術者なら「絶妙なええ感じ」を – ビジネス未満、プログラミング以上 – UIあるものなら「あまり頑張らない」 – ReadMeを越えない程度の使い勝手 わかったこと
  51. 51. 仁均曰く「自動家たるもの…」 ● 相手ごと”適度な親切さ” で作るべし –技術者相手なら”ある程度”
  52. 52. 仁均曰く「自動家たるもの…」 ● 「手軽さ」「実行の速さ」も 重要 –普及させたいならば
  53. 53. やったこと ● やったこと例3 –AOPを使った キャッシュ機構
  54. 54. 開発も後半に差し掛かり… ● 「性能対応チーム」に配属され… “バッチの性能問題”と戦う – 機能モジュール ● 「性能対応チーム」(自身)で対策 – 共通モジュール ● 「共通チーム」に打診して高速化 してもらう ● “個々対応”が遅く、順番待ち – 「手間」かつ「非効率」
  55. 55. そこで ● 「一律」に「簡単」に高速化機構 を入れる方法はないか… – 上流設計者でも手軽に出来るく らい ● AOP/DIに注目 – ProjextX では最初から ほぼすべてのオブジェクトに 仕込済み
  56. 56. 主な機能と全体像 AopParamCacher キャッシュ 機能M aopParamCacher. xml 共通M 共通M 共通M 共通M呼出 戻り値をキャッシュ化するBean を、AopParamCacher.javaへ 指示 AopParamCacher.java「クラス名-メソッド名-引数」 の組み合わせで、 共通Mの戻り値を、 内部キャッシュに貯める. 共通Mメソッドを呼び出しを横取り! 「クラス名-メソッド名-引数」の組み合わ せで、キャッシュ内を検索. 過去に戻り値を記憶していた場合は、 それを返す.
  57. 57. 主な機能と全体像 AopParamCacher キャッシュ 機能M aopParamCacher. xml 共通M 共通M 共通M 共通M呼出 戻り値をキャッシュ化するBean を、AopParamCacher.javaへ 指示 AopParamCacher.java「クラス名-メソッド名-引数」 の組み合わせで、 共通Mの戻り値を、 内部キャッシュに貯める. 共通Mメソッドを呼び出しを横取り! 「クラス名-メソッド名-引数」の組み合わ せで、キャッシュ内を検索. 過去に戻り値を記憶していた場合は、 それを返す. AOPを使ったキャッシュ機構 ファイルを一つ加え、 「対象のクラス名」を書けば、 メモリキャッシュが効く仕組み
  58. 58. 仁均曰く「自動家たるもの…」 ● 重複・くり返しの仕事に 最適と思える一手を ● 「着脱式」がベター –新機構を導入も、 すぐ元にもどせる
  59. 59. やったこと ● やったこと例4 –「プロジェクト独自 のチェック」機構
  60. 60. 突然ですが… ● ProjectXで扱う「実装するプログラム」は… JavaProject pom.xml Lan内 社内独自リポジトリ 共通pom.xml ※pom.xmlとは ビルドの方法と モジュール同士の依存関係 を書いたMavenの 設定ファイル 個々プロジェクトの 依存関係 全共通の依存 全共通の ビルド方法 のツール・枠組みを使う領域 ● 同じ方法で数千のJavaProjectをビルドしている 継承
  61. 61. またも問題… ● 事故が多発! – 本番環境に流出 ● 依存性に「出ちゃダメモジュール」書く ● テスト用設定を残したままビルド ● 何とかしなきゃ – 偉い人ら ● 「チェックシート」「教育」とか言い出す – 俺 ● 「普通機械が何とかしてくれんじゃね?」 ● てことは… – フレームワークか! ● アーキT「ダメ~変えさせませ~んw」
  62. 62. どうする? ● じゃあ「チェックしてくれる」道具? – チェックなんぞ 「増える」し「変わる」やん ● そこで…
  63. 63. こんな道具 ● チェック追加時は    の部分のみ変更 •新しいチェック種のCheckクラスを作成後、配列に登録するだけ ● maven-pluginにてこんな設計
  64. 64. こんな道具 ● チェック追加時は    の部分のみ変更 •新しいチェック種のCheckクラスを作成後、配列に登録するだけ ● maven-pluginにてこんな設計● 「変化」「増加」を前提に –ひとところに集める ● 「メンテし易さ」により 手数で勝負 –まちがってたらすぐ直す –シンプルJavaで皆直せる
  65. 65. でも… ● 「チェックしてくれるモノを作った」けど – 「開発終わり時」に「手動で」じゃ… ● 結局人間系 → 元の木阿弥 ● 「~する時に」「自動的に」 「怒ってくれ」て「それ以上進めない」 を狙わないと… ● 「透過的」にしたいんだ
  66. 66. ここでさっきの ● ProjectXで扱う「実装するプログラム」は… JavaProject pom.xml Lan内 社内独自リポジトリ 共通pom.xml ※pom.xmlとは ビルドの方法と モジュール同士の依存関係 を書いたMavenの 設定ファイル 個々プロジェクトの 依存関係 全共通の依存 全共通の ビルド方法 のツール・枠組みを使う領域 ● 同じ方法で数千のJavaProjectをビルドしている 継承 ここに注目!
  67. 67. ここでさっきの ● ProjectXで扱う「実装するプログラム」は… JavaProject pom.xml Lan内 社内独自リポジトリ 共通pom.xml ※pom.xmlとは ビルドの方法と モジュール同士の依存関係 を書いたMavenの 設定ファイル 個々プロジェクトの 依存関係 全共通の依存 全共通の ビルド方法 のツール・枠組みを使う領域 ● 同じ方法で数千のJavaProjectをビルドしている 継承 ここに注目! ● 全体共通の「ビルド設定」に 「チェックを蹴る」を追加 – Package or Release時 –不合格はリリース不可 ● 使ってる方は「意識しない」 –ある日勝手に入る、更新される –無エラーの人は今と変わらない
  68. 68. 仁均曰く「自動家たるもの…」 ● 仕組みは「透過的」が理想 ● 「変化点」「増加点」を見極めよ –その部分は「メンテナンスし易 い機構」にしておくべし ● 「公式物」なら より「メンテナンスし易さ」を考慮
  69. 69. やったこと ● やったこと例5 –「ソース管理」連携 全文検索機構
  70. 70. またまた問題… ● ProjectXは3000を越えるモジュール群 – 影響調査が絶望的 ● 一応「仕様書(Excel)パースしデータ 化」する仕組みもあるが… – それでも「精度悪」かったり 「時間掛か」ったり ● 最終的に「ソースが最後の砦」 – ソース容量→ギガ越え – 個々上流開発者がローカルに落とし て、テキストエディタで検索…
  71. 71. そこで… ● 前から個人的に使ってた機構を公開 ソース一式 (ただしバイナリ) テキスト読んで 順繰grep叩いて 結果出力と集計す るスクリプト提供 週一で、ソース 全量ダウンロード 「全文検索ツール」 で解析・Index作成 「検索エンジン」風 Webページ提供 信憑性の問わない 「手軽」な検索 (1秒以内) ソース一式 (テキスト) +WebDuv (htmlでソース閲覧可能) 結果クリックで ソースに飛ぶ 「内容」と「件数」が 重要な「固い」検索 (15分以内) 「自動」な 範囲 Bash スクリプト ログインして スクリプト叩く 二つの「全文検索」 日ごとに、ソース 全量ダウンロード
  72. 72. 仁均曰く「自動化は…」 ● 「ツール・プログラムで無い 何か」の場合もある –例では「Dir群」「スケジューラ」 ● 「シンプル」に作れば「使う側が 良い使い方を生み出す」可能性 –例では「実装チームの教育」に 活用
  73. 73. やったこと ● やったこと例6 –JavaProjectの 自動夜間テスト &増殖追随環境 (Jenkins)
  74. 74. タイトルなげーわ… ● ProjectXでは「自動テスト」標準装備 – だが回して無い ● 夜間テストして結果を録りたい – そんな環境無い ● Jenkinsを使おう! ● JavaProjectが日々増えていくのだけど… – Jenkinsのジョブは1JavaProject:1ジョブ – 増えて行くたび、手動で登録? ● ソース管理に追加されたら、 Jenkins側も自動的に追随する機構を作ろう!
  75. 75. 続きはWebで ● と、言うモノを以前 「第4回 大阪Jenkins勉強会」で発表しました – まとめサイト ● https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=6566 9255 – 資料 ● http://www.slideshare.net/miurakazuhito/fat-jenkins
  76. 76. 仁均曰く「自動家たるもの…」 ● 「日々メンテナンス」すら 自動化を狙うべし –資源の「追加」「改廃」 などを起点に 追随する必要があるもの は、自動検知&自動作業
  77. 77. やったこと ● やったこと例7 –pom.xml予約編集機構 +ビルド・デプロイ自動化
  78. 78. ※pom.xmlとは ビルドの方法と モジュール同士の依存関係 を書いたMavenの 設定ファイル また突然ですが… ● ProjectXで扱う「デプロイする物体」は… Lan内 社内独自リポジトリ 全社基底pom.xml のツール・枠組みを使う領域 継承 システム基底pom.xml Web用 集合体pom.xml バッチ用 集合体pom.xml 継承 継承
  79. 79. ※pom.xmlとは ビルドの方法と モジュール同士の依存関係 を書いたMavenの 設定ファイル また突然ですが… ● ProjectXで扱う「デプロイする物体」は… Lan内 社内独自リポジトリ 全社基底pom.xml のツール・枠組みを使う領域 継承 システム基底pom.xml Web用 集合体pom.xml バッチ用 集合体pom.xml 継承 継承 ビルド ビルド
  80. 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. 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. 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. 83. まあプログラマーは変わりませんが ● 「自動化業」のおかげか… – 「基底pom.xml管理者」 なる係になりました ● どんな仕事? – 「ライブラリの整合性を判断 し、号令出す」 – いくつかのpom.xml編集係 & テスト環境一つのお守り
  84. 84. で、なにしたら良い? ● 日々の仕事 1.(執務者の)終業時以降に 2.メールとワークフローを調べ 3.取りまとめて 4.Excel台帳更新して 5.pom.xml修正し 6.SVNにコミットして 7.社内mavenリポジトリへとUPし 8.War/jar群(30分ずつ)をビルドし 9.デプロイ(20~30分)を眺めて 10.立ち上がったのを見届け 11.周知メールを…
  85. 85. で、なにしたら良い? ● 日々の仕事 1.(執務者の)終業時以降に 2.メールとワークフローを調べ 3.取りまとめて 4.Excel台帳更新して 5.pom.xml修正し 6.SVNにコミットして 7.社内mavenリポジトリへとUPし 8.War/jar群(30分ずつ)をビルドし 9.デプロイ(20~30分)を眺めて 10.立ち上がったのを見届け 11.周知メールを… ● 意味解らんし、 シンドイわ!
  86. 86. 本質に迫ろう ● でも、やりたいことは ● 出したいモノを ● どっかで指定しとけば ● 勝手に出る(環境配備) のはず
  87. 87. さらに ● 出したい方(上流)も の入力だけで情報足りる はず
  88. 88. さらに ● 出したい方(上流)も の入力だけで情報足りる はず ● 双方ともに “手間行” にやられてる のでは?
  89. 89. Lan内 社内独自リポジトリ そこで… ● 「リリースを予約」して反映する仕組 予約データ (RDBMS) テスト環境 Webサーバ DBサーバ Groovy スクリプト群 pom.xml 予約データから、 適切なpom.xmlを 編集、SVNに登録 pom.xmlから、 Warをビルド・デプロイ 「リリース予約」の データを登録 リリース予定の 入力画面を提供 当日のリリース予約 データを取得「リリース予約」の データをDBに保存 Jenkinsから スクリプトを キック メールで各種 完了をお知らせ
  90. 90. Lan内 社内独自リポジトリ そこで… ● 「リリースを予約」して反映する仕組 予約データ (RDBMS) テスト環境 Webサーバ DBサーバ Groovy スクリプト群 pom.xml 予約データから、 適切なpom.xmlを 編集、SVNに登録 pom.xmlから、 Warをビルド・デプロイ 「リリース予約」の データを登録 リリース予定の 入力画面を提供 当日のリリース予約 データを取得「リリース予約」の データをDBに保存 Jenkinsから スクリプトを キック 当初の 「このポストの仕事」 ほぼ”作業ゼロ”に
  91. 91. ここでの知見 ● “作るか否か”の判断 – まずは「世に道具があるか」をググる ● 「悪魔の証明」になり得るので時間を切る ● その結果にて数択の行動 – 1.ドンピシャ(やりたい事を実現したものが既に在り) ● そのまま使う(作らない・改造しない) – 2.一部機能が類似 ● 外科手術 - その一部だけ使う方法の模索 ● 内臓移植 – (OSS等なら)その部分のソースだけ 「上手く取り出せないか」模索 – ライセンスに注意 – 3.世に無なさそう ● フルスクラッチ(完全自作) ● ※1,2でも「頑張りたい理由」があるなら自作でOK
  92. 92. 仁均曰く「自動家たるもの…」 ● 二者以上が絡む作業にて、 双方「相手のせいで手間だ」 と言う場合「作業の必要性」 自体を疑うべし
  93. 93. 仁均曰く「自動家たるもの…」 ● 「先駆がいるか」を毎回ある程度 調べるべし –作らないで良いなら作らない ● 戦略的に「作りたい」場合は 除く
  94. 94. やったこと ● やったこと例8 –本番リリース 目検チェック自動化
  95. 95. ちょっと一息 ● ※時間切れにて書けず ● ※教訓については簡単なので次頁
  96. 96. 仁均曰く「自動家たるもの…」 ● 「困ってる女子のヒーロー になりたい気持ち」には 素直たれ ● 「機械の仕事を疑う」 ような仕事は疑え
  97. 97. やったこと ● やったこと例9 –環境作成 予約機構
  98. 98. すこし違う仕事が ● 今までは「自分・チームのため」と提案型 ● 今回、上から「改善の指令」が ● 指令内容:「テスト環境の運用を改善せよ」 – 現在の問題 ● 一つの環境(Webアプリが一つ動く環境)の作成に時間と 人数がかかる – 今後、環境をダース単位で即時に作成する必要あり – 「専門の係」でなく「依頼者」でも環境を作れるように 対応せよ! ● 今までと違う条件 – アーキテクトチームと協力せよ – 「業務改善」して良い、むしろせよ ● 業務や「環境」の形・定義すら変えて良い
  99. 99. 現状は ● 一つの環境の作成に時間と人数がかかる 環境一つ くださいな DBスキーマ Webコンテナ 外部連携用 設定群 環境ごと スクリプト ビルド・デプロイ 自動化設定 環境完成 ● パーツごとに作業者が異なり手動で作業してる 依頼者(上流) 受付者 pom.xml一式
  100. 100. 今回は詳しい人も味方に居るので… ● 業務改善も行う ● 用語:ECRS(イクルス)の原則 1.Eliminate-排除:無くせないか? 2.Combine-結合:一緒にできないか? 3.Rearrange-交換:順序変更できないか? 4.Simplify-簡素化:単純化できないか? ● ECRSを使い「環境作成」業務を改善する
  101. 101. ECRS適用例 DBスキーマ 作成 Webコンテナ 作成 外部連携用 設定群作成 環境ごと スクリプト作成 ビルド・デプロイ 自動化設定作成 pom.xml 一式作成 これを現行 業務とすると… 1. 削除 Webコンテナ 作成 環境ごと スクリプト作成 ビルド・デプロイ 自動化設定作成 pom.xml 一式作成 「環境作成」から ・DBスキーマ ・外部連携設定 は、除外とする (削除じゃないけど) Webコンテナ &環境ごと スクリプト作成 ビルド・デプロイ 自動化設定作成 pom.xml 一式作成 2. 結合 Webコンテナと スクリプト作成は 「参照している情報 が似通ってる」ため 同時に行う
  102. 102. ECRS適用例 3. 交換 4. 簡素化 Webコンテナ作成 時の情報を後続が 期待してるので、動 かせない。 交換は無し。 Webコンテナ &環境ごと スクリプト作成 ビルド・デプロイ 自動化設定作成 pom.xml 一式作成 Webコンテナ &環境ごと スクリプト作成 ビルド・デプロイ 自動化設定作成 pom.xml 一式作成 Webコンテナ &環境ごと スクリプト作成 ビルド・デプロイ 自動化設定 コピー pom.xml 一式作成 ビルドデプロイ自動 化設定作成は、「他 環境からコピー」し たほうがシンプルな ので、変更する。
  103. 103. これで新プロセス完成 ● 業務改善が終了 – →この業務を自動化する ● 自動化 – 個々「現在の担当者」が「コンソールか ら実行」出来る形のプログラム化 ● 全員「何かしらプログラムが組める」 ため ● 引数・戻り値(ファイル)だけは厳密に – Jenkinsで繋いで実行
  104. 104. Lan内 社内独自リポジトリ そこで… ● 「環境新規作成を予約」し作成する仕組 予約データ (RDBMS) DBサーバ みんなで作った スクリプト群 pom.xml 予約データから、 適切なpom.xmlを 編集、SVNに登録 テスト環境 Webサーバに ランダムに tomcatインスタンスを 立てる 「環境新規作成予約」 のデータを登録 環境新規作成予約の 入力画面を提供 選択された環境作成予 約データを取得「リリース予約」の データをDBに保存 Jenkinsから スクリプトを キック メールで各種 完了をお知らせ Jenkins のジョブを キック テスト環境 Webサーバ群
  105. 105. Lan内 社内独自リポジトリ そこで… ● 「環境新規作成を予約」し作成する仕組 予約データ (RDBMS) DBサーバ みんなで作った スクリプト群 pom.xml 予約データから、 適切なpom.xmlを 編集、SVNに登録 テスト環境 Webサーバに ランダムに tomcatインスタンスを 立てる 「環境新規作成予約」 のデータを登録 環境新規作成予約の 入力画面を提供 選択された環境作成予 約データを取得「リリース予約」の データをDBに保存 Jenkinsから スクリプトを キック メールで各種 完了をお知らせ Jenkins のジョブを キック テスト環境 Webサーバ群 2日以上の作業を、 誰の手をも煩わさず 5分に
  106. 106. 伝えたいこと ● 「局所」「広域」の自動化 – これにより考えるべきことが変化する – 局所 ● 「自分」「自チーム」など ● 自分たちの「良い」を探求 – 広域 ● 「大規模プロジェクト全体」「社全体」など ● トータルデザイン必須 – (既存業務があるなら)業務改善とセット – 親和性を考慮 ● 道具の繋がり・出自の遠さは使う方も苦しい ● CUI行ってGUI行って、MS製品行ってOSS行っ て、OPEN行って汎用機行って…は辛い ● 出来るだけ寄せる
  107. 107. 仁均曰く「自動家たるもの…」 ● 業務改善が可能なら、 そちらを優先 –「ECRSの原則」等を利用 ● 「広域」「局所」の自動化を意識 する –Project全体で…とかなると 親和性などの考慮必要
  108. 108. チャプター4 4.マインド②
  109. 109. なぜ自動化するのか
  110. 110. なぜ自動化するのか ● 自動化のメリット – 工数削減 – 省力化(簡易化) – ミステイク撲滅 – 作業の明確化(暗黙知の明文化) ● 副産物(技術者視点) – 比較的新しい技術に触れる (事が多い) – 外科手術/内臓移植が得意になり、 先人の「賢い!」を自分のものに
  111. 111. なぜ自動化するのか ● 自動化のデメリット – ロストノウハウ ● 「誰も知らないがなんか出来る」 になりやすい –手動の間は 有る程度の人数に有る程度の理解 –「作った人」がチームから去れば 加速度的に ● チーム全体がトラブルに弱くなる
  112. 112. なぜ自動化するのか ● どんな場合に効果的なの? –元の手作業が ● 多人数 ● 単純でミスしやすい ● 道具作ったほうが早い
  113. 113. 仁均曰く「自動家たるもの…」 ● 「なぜ自動化するのか」を 明確に持つべし –メリ・デメを知った上で やるべきか判断 –「自動化する理由」を 明確にし、狙いを持って
  114. 114. 自動家の視点
  115. 115. 自動家の視点 ● 道具や機構、なにか"モノ"を見た場合 – 「~に使えるか」 ● 「繋げるか・繋がるか」「蹴れるか」 「吐けるか」「読めるか」「検知できるか」 「楽に操作できるか」 – コレとコレ組合わせればいけんじゃね? ● 興味の質はこういうものになってくる例 – 「読める」「吐ける」 ● API,CSV,REST,スクレイピング – 「蹴れる」 ● Webインターフェイス – 「楽に操作できるか」 ● パーサ、オーサリングツール
  116. 116. 自動家の視点 ● キーワード – こう言う単語が出てきたら 「ガタッ『~と聞いて!』」 と飛びかかるようになります パーサ コンバータ デーモン キッカー ポーリング ユーザ定義関数 マクロ 自動記録 スタートアップ エントリポイント検知/センサー eval(yeld) CUI起動 (とオプション) (既に仕込済みの) DI/AOP リフレクション メーレット トークン/ 区切り文字 メタプログラム API メール送信(簡易な
  117. 117. 仁均曰く「自動家たるもの…」 ● 「使えそうなモノ」には、 全方位で アンテナを張っておくべし –「使い方」「組合せ」も 思索すべし
  118. 118. 自動家を阻むもの
  119. 119. 自動化を阻むもの ● 対象作業の性質 – 複雑 – 流動 要は「不確定」→「ファジィ」 なとこ ● 人間 – 「手動が機械より信用できる」 と思ってる人
  120. 120. 自動化を阻むもの ● 打ち破るために… こう「思いこんで」おく – 「人間がやっていることで 『ファジィなとこ』以外は、 100%自動化出来る」 ● …時間さえかければ – 「技術は万能」である ● とにかく「自分の脳内」でだ けは芯に置いておく
  121. 121. 仁均曰く「自動家たるもの…」 ● 「人間がやる事で『ファジィなとこ』 以外は、100%自動化出来る」 と思いこめ ● とにかく「自分の脳内」でだけは 「技術万能」を芯においとけ ● それが「自動化を阻むもの」に、 自動家が挑むのに必要なもの
  122. 122. 自動家のイデオロギー
  123. 123. 冒頭にも言いましたが… ● 自動化 – 放っておくと「やらない方向に動くモノ」 ● たゆまぬ啓蒙が必要なのかもしれない "おまんま食上げ"を 恐れている人 ドSの人 "人のせいに出来る"を リスクヘッジと考える人 それ、 やる必要 あんの? あー、じゃあソレ やめときましょっかー♪ お金もバカにならんし… 話を早く 終わらせたい人 (主に管理層)
  124. 124. 反対の度合い ● 最初に思う「ある程度自動化」が だとして…
  125. 125. 反対の度合い ● ほっとくと…
  126. 126. ということは… ● これくらい言うといて… ググッ…
  127. 127. な感じです(個人的感想) ● やっとこれくらい「成る」 ビョン!
  128. 128. 仁均曰く「自動家たるもの…」 ● やっとこれくらい「成る」 ビョン! 「100%自動化!」 くらい 豪語する/目指す くらいで丁度良い…
  129. 129. 自動化すりゃ”楽”なのに… そう成りにくいもんだね。
  130. 130. そしてタイトルへ… 仁斤曰く 「”手間業”蔓延り易く、 “楽”成り難し」 御清聴 ありがとうございました
  131. 131. 延長戦
  132. 132. チャプター5 5.最近思うこと
  133. 133. いろいろやってみて… ● 「自分or他人の仕事をプログラムに書き起こす のは「仕事の方法を文書化する」より、 低コストで値打ちがあるのでは? – ただし「プログラムが読める」という文化は必須 ● 自動化して時点で数十倍 →さらにワンチャンある – 「仕事をリバースエンジニアリング」 – 「仕事にテストを付ける」 – 「仕事をチューニング」 …という新しい概念が生まれる
  134. 134. 願望 ● 会社が儲かったらどうする? – 設備投資 – 増員 – 教育 まあそうですよね… ● その中に 「技術者一人『工夫屋さん』として雇う」 てのがあっても良いのではないか? …ま、普通は出来ませんけど
  135. 135. それ一番言われてるから 災いを 『未然に防いだ勇者』 は数百あれど、 英雄となれたのは 『発生後に対処した者』 ただ一人である
  136. 136. あくまでも願望 ● でも「未然に防いだ勇者」が重要 – それを多く輩出するために… 「そういうポジション築いて、 泳がせて欲しい」 と思う
  137. 137. 完全に趣味 ● 現在目を付けていること – メーレット ● メールをトリガーとして動くプログラム ● 古典的だが「意外と無い」「定番が無い」 ● 実現するプロダクト – GAE,James – 全文検索エンジン ● 手軽になったから ● 実現するプロダクト – Apache Lucene/solr , groonga – Linuxが乗るミニPCとプログラマブルなUSBデバイス ● 自動家にとって「物理」を操作→夢がひろがりんぐ ● 「機械」で無く「OS搭載PC」、「装置」で無く「API有 USBデバイス」の土俵なら… ● 実現するプロダクト – RaspberryPi 等
  138. 138. 今後 ● 自動がさらに進化すれば – 仕様書書いただけで自動テストできるかも? ● やりたいのは 「思いそのまま劣化させずテストにする」 こと – それが出来ないから 「仕様書(紙)と手動のテスト」 を選択してるだけ ● 道具が進化して 「書/描いたモノがそのままテストになる」 とかになると変わるはず – DSLでなく「自然言語の解析」や「優れた フォーマット」によって
  139. 139. 自動家が目指すモノ ● 自動化って行きつく先は… – 「センサー学」みたいになるのでは? ● 「生きてるだけで」「息するだけで」 駆動する、データが取れる –「~を検知して」というpush型考え ● それ無理でも 「一挙手一投足きっかけ」で –ジェスチャーとかの概念に近い
  140. 140. さて、ここからはダイアログ ● さて、みな様は 自動家(オートメーター) ですよね? ● どんな「自動化」をするorしましたか? ● ご意見・アイディア教えください!
  141. 141. 今度こそ… ご清聴 ありがとう  ございました。
  142. 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/
  143. 143. 調子こいてWebラジオのAD始めました アジャイルラジオ http://www.agileradio.info
  144. 144. ボツ稿
  145. 145. 「自動化」交渉 ● 「Not○sのワークフロー、別のに変えられないですかね?」 ● 「ダメだな」 ● 「じゃぁ、N○tesマクロか、○otesを外部からJavaでAPI叩かせて下さいよ」 ● 「却下」 ● 「じゃ、Exc○l要らんことないですか?なんで使ってんすか?」 ● 「知らん。通例。」 ● 「えー、じゃあ抜けるんじゃないですか?」 ● 「無理。E○celのマクロで"pom.xmlの一部"を吐き、それをコピーするという仕事あるから」 ● 「ん?管理表って何のためにあるんですか?」 ● 「その"pom.xmlの一部"吐くため、その台帳を壊さぬよう、漏らさぬよう、メンテしてかなならん」 ● 「2重管理じゃないですか?」 ● 「そうだ」 ● 「あ、じゃあwarのビルド・デプロイを直接蹴ったりできません?」 ● 「ある端末にリモートログインして、そこにあるクライアントソフトから、某有名スケジューラサーバに入っ てジョブをキックするルールになってるから」 ● 「なぜ故…」 ● 「ライセンス」 ● 「…あ、ジョブはワンキックで、ビルド→デプロイですよね?」 ● 「いや、バラバラ」 ● 「え?」 ● 「だって手編集失敗するのと、編集パターンが複数あるのと未知な部分が多くて、ビルドでコケル事が多いか ら…」 ● 「じゃあ張り付いてなあかんのですか?」 ● 「そうそう、定時後ね」 ● 「…」
  146. 146. もちろん「科学サイド」

×