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

『運用屋さんのための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よりたぶん楽です)

なぜVBAか?
1. Windows環境であれば、たいていExcel入っている。
(一般の人が使える唯一?のインタプリタ)
2. Mac でも動く。
(Oﬃce 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版Ofﬁce でも動作するようにした。 (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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

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

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