Download SlideShare for Android. 15 million presentations at your fingertips  Get the app
×
  • Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
 
« ‹ › »
   

『運用屋さんのためのVBA入門』 ～ 運用方法論 運用工程設計・自動化概論 〜

on

  • 178 views

See also http://rsh.csh.sh/text-scripting-vba/ (vi で書こう VBA)

See also http://rsh.csh.sh/text-scripting-vba/ (vi で書こう VBA)

Statistics

Views

Total Views
178
Views on SlideShare
177
Embed Views
1

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 1

http://s.deeeki.com 1

Accessibility

Categories

Upload Details

Uploaded via SlideShare as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
Post Comment
Edit your comment

    『運用屋さんのためのVBA入門』 ～ 運用方法論 運用工程設計・自動化概論 〜 『運用屋さんのためのVBA入門』 ～ 運用方法論 運用工程設計・自動化概論 〜 Presentation Transcript

    • 『運用屋さんのためのVBA入門』 ∼ 運用方法論 運用工程設計・自動化概論 ∼ 波田野 裕一 （日本UNIXユーザ会) Shinagawa Seaside kara 2eki-me-de Meeting 2012-08-31
    • 運用現場の諸問題 1. 高負荷 2. 属人的 3. 見えぬ費用対効果 ブラックボックス化 低付加価値化 業務が複雑化 「費用」は一定で「効果」は経年劣化する 「費用対効果」は勝手に低減していく 現場では制御不能状態
    • 制御不能状態を加速する 運用でカバー 運用でカバー運用でカバー運用でカバー
    • 問題解決へ 「問題を根性で解決するのは馬鹿です。 問題をエンジニアリングで解決するのが エンジニアの仕事です」 by Yoshiori
    • 運用を「工程」として捉える
    • 基本 設計 Step1 運用作業を「工程」として捉える 開 始 機能 設計 Step2 詳細 設計 Step3 コーディング Step4 テスト Step5 完 成 サービス 工程 Step1 開 始 サービス 工程 Step2 サービス 工程 Step3 サービス 工程 Step4 サービス 工程 Step5 提 供 「前の工程の成果」を「後の工程が加工する」という点において! プログラム開発と運用の工程は似ている 前処理inbound 本作業 後処理 outbound 「パイプでつないでいる」と考えれば極めて「UNIX的」
    • サービス工程(運用プロセス)のQCD 運用プロセス (サービス工程) D デ リ バ リ C コス ト tool 人力定常業務 費用勘定 (人件費) 自動定常業務 資産勘定 (減価償却) Q サービス品質 Interface/API inbound から outbound ! (時間) ? 前提: 「運用」とはサービスデリバリである。 時間という 物性 お金という 物性 顧客満足度 という「?」
    • OOA的運用プロセス (仮説) 運用プロセス (サービス工程) Interface/API 前提: 「運用」とはサービスデリバリである。 inbound outbound 作業 (処理) Queue (チケット) datamethod 処理内容自体 は外部から隠 化 (カプセル化) 外部とのメッセージ の定型化 外部とのメッセージ の定型化 類似業務の統合に よる(疑似)多態化 標準業務(クラス)から 類似派生業務への継承
    • サービス運用全体の流れ inbound チケット outbound の繰り返し 各組織
    • 運用プロセス = サービス工程 inbound outbound 作業 (処理) D デ リ バ リ C コス ト tool Q サービス品質 Interface/API Queue (チケット) datamethod 工 程 設 計
    • 運用を「エンジニアリング」で問 題解決&改善していく
    • 運用をエンジニアリングする 作業の手順化 手順の抽象化 手順の自動化 とにかく手順を書 いてみる レベル3: 脱属人化 レベル2: 客観化 レベル1: 整理 類型化された 各工程モデルを コード化する 「書く」という作業により、 主観的に「整理」されていく 「抽象化」することにより、業務に詳しくない第三者 でも概要の理解が容易となり、「客観化」されていく 「自動化」により作業ロジックが明確になり、時 と空間を超えて「業務仕様」が共有されていく 工程に分割し各 工程を類型化して みる
    • 運用をエンジニアリングする 作業の手順化 手順の抽象化 手順の自動化 とにかく手順を書 いてみる 工程に分割し各 工程を類型化して みる 類型化された 各工程モデルを コード化する プログラミング言語 レベル3: 脱属人化 レベル2: 客観化 レベル1: 整理 + actdiag + actdiag
    • 運用をエンジニアリングする プログラミング言語 VBA2012年初までずーっと避けてきたのですが、諸般の事情により最近VBAに手を染めています。 実際さわってみると、運用現場の改善に大きく貢献しそうなポイントが見えてきたので、運用業務にVBAをどう活かすかについてここ にまとめてみたいと思います。
    • このネタの対象者 ‣ プログラミングの基礎知識は持っている。 ‣ 業務でWindows/Office利用の比率が高い。 ‣ 提出書類の多くが、PowerPoint/Excel だ。
    • Out of Scope • 業務におけるマクロ利用が禁止されている人。(ごめんなさい) • PowerPoint/Excelでのレポートを作らない人。(Shell Scriptがいいと思われ) • 自分達でサーバ/クラウドリソースの確保および利用が自由にできる現場。 (Office以外で実現した方が幸せかと:-) • .NET や VB や PowerShell でWindowsの処理を何でも書ける&引き継げる相手 が周囲にいる人。(VBAよりたぶん楽です)
    • Let'sVBA
    • なぜVBAか? 1. Windows環境であれば、たいていExcel入っている。 (一般の人が使える唯一?のインタプリタ) 2. Mac でも動く。 (Office for Mac 2010) 3. ユーザが多い。 引き継ぎ相手がいる可能性が高くなる。
    • VBAのメリット • 普及 ◦ MS Office の普及率が高く、たいていの運用現場で利用されている。 ◦ MS Office がインストールされていれば、開発/実行環境は含まれている。 ◦ Windows系の運用現場では引き継ぎがしやすい。受け入れられやすい。 • 集計・分析の自動化 (Excel) • Web操作の自動化 (Excel & IE) ◦ JavaScript の知識が無くても DOMを利用したWeb操作の自動化が容易に実現できる。(IEモジュール利用: Windowsのみ) • レポート作成の自動化 (Execl & PowerPoint) ◦ PowerPoint での定期定型レポート提出について自動化がしやすい。 • メール受信トリガーによる自動作業 (Outlook & Excel -> PowerPoint & IE) ◦ 手でやらなくても良い作業を簡単に自動化できる。 • 作業トリガーによるメール自動送信 (Excel -> PowerPoint + IE -> Outlook) ◦ 手でやらなくても良い作業を簡単に自動化できる。 • Webに情報が豊富にあるため、コーディング時の参考にしやすい。 • 媒体がファイルであるため、修正や機能強化が容易にできる。
    • VBAのデメリット • ソースコードがバイナリ内部に存在し、バージョン管理が難しい。(回避可能) • ソースコードがバイナリ内部に存在し、ドキュメントからの参照引用が難しい。(回避可能) • モジュール共有と保守の同期が難しい。(回避可能) • 好きなエディタでソースコード編集ができない。(回避可能) • 正規表現が利用できない (Windowsの場合は外部ライブラリにより利用可能) • バージョンが変わると動かなくなることがある。 • 媒体がファイルであるため、複数存在する場合に、どのファイルが真正のファイルかわからなくなってしまう。更 に更新が分岐しやすい。 • 媒体がファイルであるため、置き場に永続性がなく、失なわれやすい。 • テスト駆動開発に関する知見がほとんどみあたらない。
    • 救世主 登場!!
    • 拡張してみました!! ' 1. 手動リロード関数(reloadModule)を追加 ' 2. Mac版Office でも動作するようにした。 (backslash の扱いが安定しないので chr(92)で指定) ' 3. ライブラリリストについて、 ../ を使った相対指定(例: ../common/hoge.bas)への対応を追加 ' 4. ライブラリリストについて、パス区切りなしの指定(例: hoge.bas)への対応を追加 ' 5. ライブラリリストについて、絶対指定("C:" & chr(92), chr(92) & chr(92) & "server" & chr(92), /hoge, :hoge)への対応を追加 ' 6. ライブラリリストで使うパス区切り文字について、Windowns(chr(92))/Mac(:)/UNIX(/) のどれを使っても良いように した。 ' 7. ライブラリリストの改行コードが Cr(Mac) でも CrLf(Windows) でも良いようにした。 ' 8. 定数 ENABLE_WORKBOOK_OPEN の値でファイルオープン時の挙動をON/OFFできるようにした ' 9. このソース自体をexportする関数(exportThisWorkbook)を作成した。 ' 10. このExcelファイル自体のUNITテスト用関数を追加してみた。(試験的) http://rsh.csh.sh/tmp/excel-text-template.tar.gz
    • VBAのデメリット(再) • ソースコードがバイナリ内部に存在し、バージョン管理が難しい。(回避可能) • ソースコードがバイナリ内部に存在し、ドキュメントからの参照引用が難しい。(回避可能) • モジュール共有と保守の同期が難しい。(回避可能) • 好きなエディタでソースコード編集ができない。(回避可能) • 正規表現が利用できない (Windowsの場合は外部ライブラリにより利用可能) • バージョンが変わると動かなくなることがある。 • 媒体がファイルであるため、複数存在する場合に、どのファイルが真正のファイルかわからなくなってしまう。更 に更新が分岐しやすい。 • 媒体がファイルであるため、置き場に永続性がなく、失なわれやすい。 • テスト駆動開発に関する知見がほとんどみあたらない。
    • VBA利用における視点 ‣ 視点1. 業務プロセス分析/自動化の1ツールと考える ‣ 視点2. 暫定的かつ気軽な自動化ツールと考える ‣ 視点3. 肥大化させない。(管理不能になる案件多数)
    • To Be Continue VBA Let's enjoy