森理 麟(moririring)

C#での

自動化の

作り方入門

自己紹介

　　 森理 麟(@moririring)● 職業 : ゲームプログラマ● ブログ : 森理 麟(moririring)のプログラマブログ● 自作アプリ : クッキツイート,HashifyWin● 好きな言語 : C#● VSハッカソン倶楽部代表、EffectiveC++読書会

運営、MetroStyleDeveloperスタッフ、TDDBCTA、わんくま同盟スタッフ

自動化ですが

この話は…なし。昨日発売したあの話も…なしです。

今日のアテンド

● 自動化とは

● Visual Studioで自動化する理由

● C#で自動化するための技術

● 自動化完成の後

自動化とは？

What is Automation?

自動化とは？

人間が行っていた動作を機械に代替して作業要員を減らすこと(Wikipediaより)。

パソコンがやるのが一番効率的だから。言われたこと以外出来ないが言われたことは確実にやる。

なぜパソコンにやらせる？

どうやってパソコンにやらせる？

パソコンに作業を命令する必要がある。作業の命令とはつまりプログラミング。

何をパソコンにやらせる？

ルーチンワークと呼ばれるような作業はほぼ全て自動化してパソコンにやらせるべき。

プログラム出来ないことは？

パソコン上で人間がやる作業で、プログラム出来ない作業は理論上ない。

自動化で人間は怠けるか？

以前ある作業を自動化した時に「人間を怠けさせる仕組みだ」と言われた。しかし、これは間違い。

人間がやるべきことは？

人間は言われたことをさらに良くすることが出来る。すなわちクリエイティブなことをしよう。

何のために自動化をするか？

シンプルに言うと今より少しでも良くすること。毎日続ければ今日より良い明日がずっと来る。

まとめ

● 自動化とは作業をパソコンにやらせること

● パソコンにやらせるためにはプログラミング

● ルーチンワークは全てパソコンに任す

● 空いた時間で人間はクリエイティブなことを

● 自動化は今日より良い明日のためにする

ここまでが前回のお話

自動化するための技術としてbat,WSH,jscript,vbscript,PowerShellなどを紹介して、実際にデモ。

現在自動化を作る際これらの技術は勿論使っている。しかし、森理が自動化をすることになった場合に最初起動するツールは決まっている。

森理が最初に起動するツール

最初に起動するツール。それはVisual Studio。

マイクロソフト - Visual Studio - これまでで最も薄く、軽く、速いVisual Studioです。

Visual Studioで

自動化する理由

Technology for Automation

スクリプトから移行の理由

最初スクリプトで作っていて、VSでの自動化に移行しようと思ったのには幾つか理由がある。

● batとVBSでは一度動き出したら止められない● 実運営する人の書き換えハードルが高い● 作った構成を他のパソコンに変更するのが面倒● チェックボックスやボタンで簡単に操作をしたい● いや、だってVS好きだし…

スクリプト言語でも出来るけれど

先ほど出た理由はスクリプト言語でも解決が可能なものもある。しかし、当時スクリプト言語でやろうという発想はなかった。

スクリプト言語のデメリット

そもそもスクリプトはデメリットが多い。遅い、コンパイルがない、実体をコピーでしか量産出来ないなど。でも、これれも絶対的な理由ではない。

統合開発環境のメリット

何より大きいデメリットはIDEがないこと。IDEのメリットはさまざまあるが、個人的にはプログラムをプロジェクト単位でまとめられることが大きい。

まとまっているものは扱いやすい

まとまっている状態だからこそ、関数化したり、クラス化したり、ライブラリを作ったり、ユニットテストをしたり、バージョン管理をしたりとなりやすい。

Visual Studioのメリット

さらにVSはグラフィカルに開発出来る。UIに絡んで、実装を考えるので使い勝手を向上しやすい。

スクリプトが悪いんじゃなくVSが良すぎ

スクリプト言語でも工夫すれば出来る事は多い。でも工夫しなくても、VSとC#なら出来る。

VSの魅力

Visual Studioの最大の魅力。それは最高に使いやすい。

C#で自動化するた

めの技術

Technology for Automation

Visual Studioを使った結果

結果VSを使ったことで以下の機能を実装していくことになった。

● 多くの操作をワンクリックで● チェックボックスによる作業のON、OFF● ドラッグによる直感的な操作● トリガー機能（タイマー、差分）の実装● 現在の進行状況を表示● メールやIMなどのエラー通達● セーブ機能、ローカル設定の保存、パス置換。

ボタン

全ての自動化操作はワンクリックで出来るようにした。細かい動作もワンクリックで出来るし、全動作もワンクリックで出来る。

● 最初はListViewで作っていた● 右クリック操作が意外と面倒?● DataGridViewがオススメ

チェックボックス

ユーザーがカスタマイズしやすいように、ほぼ全ての機能にON・OFFを付けた。チェックが大量の場合は全チェックも忘れずに。

● 作業のスキップは結構重要● でも分かっていないと逆に危険ではある● 1個だけやりたい時はやはりボタンが便利● 全チェックのUI的なコツ

ドラッグ&ドロップ

ドラッグ&ドロップはかなり直感的に操作してもらえる。操作の対象の登録も、順番の入れ替えも全てドラッグ&ドロップで出来るように。

● 実装していないと出来ないか必ず聞かれる● DataGridViewのドラッグ＆ドロップはちと複雑

削除

操作は出来るだけ手軽にして、余計な確認は極力避けた方が良い。ただし、削除だけは別。なるべく手軽である必要はない。

● 削除して良いかは必ず質問を入れる● デフォルトカーソルは動かさないと消せない● キーボード操作は入れた方が良い● 操作のしやすさと削除のしやすさと微妙に違う。

トリガー

手動実行以外で実行する方法を実装。簡単なのはタイマー。指定時間機能と間隔機能

● 残り時間表示が意外と面倒● 指定時間を超えても動作中というケースでも

ちゃんと動作させる● タイマー起動時ロード設定が結構重要● 裏タイマー機能としてエラーチェック● 曜日機能はちょいちょい要望があがる● もっと言うとカレンダー機能

トリガー

間隔にプラスしてリビジョンやファイルチェックをプラスする。変化があった場合のみ動かすように。

● リビジョンチェックはコマンドラインのSVN必須。● Cygwinなど古い場合もある。● ごく稀に英語版の場合もある。● コマンドラインで取得する文字はマニュアルにも

なくバージョンで変わったりするので注意● ファイルチェックでWEB対応なども可能に

マルチスレッド

処理を止めないためにはマルチスレッドが必要。動作中であることの表示、進行状況の見える化という意味もある。

● Task.Killの良し悪し● 今の動作はさせて、次以降の動作をさせないが

無難● でもほとんどの場合ユーザーは容赦ないので一

緒かも。● 実装はBackGroundWorkerが最強

ログ

自分だけでなく、周りも含めてログから得られる情報は多い。ログは最重要と思って作って良い。

● やっている動作をそのまま全部テキストに残していく

● 例外はExceptionのMessageをテキストに● Excelは避けた方が無難かも。全てのパソコン

に入っているわけでないし、文字化けもある。● いろんなログをまとめてHTMLからリンクを張る

のがおススメ

エラー通達

エラー通達で、使用者の多い場所に連絡を入れよう。勿論自動に。

● IPMessagerなどもコマンドラインで対応可能。● メールもSMTPを使えば意外と簡単。● メールは効果的ではあるけれど、受け手によっ

ては迷惑メールと変わらず● お気に入りに入れてなど継続性を訴える● 出す頻度、内容を可能な限り減らすのが成功の

秘訣。

セーブ機能

セーブ機能とXML

● 昔はTXTで生でセーブしていた● レジストリを使っていた時期もある。● 設定ファイルを使うのも結構楽● 位置が変わるので注意。● XMLは最高。XmlTextWriterで書き出し● 変更するたびに対応は面倒でXmlSerializer● その後DataContractSerializer。これ最高● 読みこみは自作が良いかも

自動化完成の後

Application of Automation

自動化は作っただけでは終わらない

自動化は作ってイコール完成ではない。むしろココがスタートだと思うべき

自動テスト知識体系 - TABOK

TABOKという自動テスト知識体系の文章があるが、驚く程自動化以外の話が多い。プロジェクト管理や作業フローへの組み込み方、上司や経営層への説得方法が半分以上。

完全自動化でもメンテは必要

毎日自動で動く状態を維持し続けると、トラブルは起きる。手動でやるより遥かにコストは下がるが、それでもゼロになる事はほぼない。

さまざまなトラブル（一例）

● 作成と上書きで処理が違う。● 呼び出すべきファイルを他の実行ファイルでロッ

クしている。● 長期休みや停電● サーバーへの接続が出来ない● WindowsUpdateで自動再起動される● 自動化するはずのパソコンなのに帰りに電源を

切られてしまう。● 設定がスリープ状態になっている。● ローカルの編集と衝突する● アプリのバージョンが違う● パソコンが故障● 確認ウィンドウで次の動作に行かず

みんなが自動化を好きなわけではない

自動化が最高と思って積極的に関わってくれる人は恐らくチームでも1割程度。7割はどうでも良いと思っている。さらに2割程度の人は余計な仕事を増やすなと思っている。

積極的にふれてくれる人の意見は重要

1割の人にはログのチェックやパソコンのメンテナンスなど積極的に関わってもらう。その人から聞く運用上の手間は特に重要。

安定動作が大事

どうでもよい8割に興味を持たせるためには、常に正常な状態に動いている必要があり、ログやメールなどは簡潔で分かりやすくないと駄目。

アンチも時々鋭いことを言う

後の1割も、話してみてどういう所が嫌なのか聞けると対策が取れることもある。嫌な理由というのは意外と重要。

便利になると怠けるんです

便利になりすぎることによるトラブルもあり、これは推進している側でもかなり考えなければならない問題。

まとめ

GUIで使いやすい自動化を作っても、使ってもらえるかどうかは別問題。

ツールは作っただけでは意味がない。使ってもらって初めて効果が出る。

使ってもらうための方法論は、まだまだ模索中。

以上

ご清聴有難うございました。