border not found

分野・領域などを問わず、何でも綴る雑記帳

Office365 の共有メールボックスから Powershell で送信する

はじめに

Office365 のアカウントから Powershell を使ってメールを送信する記事は多く見つかるのですが、共有メールボックスから送信する記事は見つからなかったので作成しました。 ついでに設定を Script に直に記述しなくても簡単に送信元を切り替えられるよう、設定ファイルを XML で外だししました。(こっちがメインになってしまったかも)

ポイントは下記2点です。

  • 認証するユーザと送信元アドレスを個別設定している
  • 前述の設定ファイルの分離

分離された設定ファイルはデフォルト値を予め設定しているので、引数 (ConfigXml オプション) が指定されていない場合は Script と同一ディレクトリの XML ファイルを呼びに行きます。

余談ですが、最初 Qiita に投稿するつもりで書いていたのですが、はてなブログに載せたらどう見えるかなと思ってこちらでも投稿してみました。 はてなブログでもコードをハイライトできることを発見し、深夜に一人「できる、できるぞー」と心の中で叫んでしまいましたw Qiita で予約投稿できないのが、ちょっと残念。。。

前提条件

  • ExecutionPolicy が RemoteSigned になっている
  • 送信元となる Script 実行ホストから Port587 で Office365 の SMTP サーバに接続可能な状態
  • Exchange Online 側で SMTP が有効になっている

動作確認済み環境

OS $PSVersionTable の PSVersion
Windows Server 2012R2 4.0

実行例

設定ファイルを指定しない場合 ( デフォルト設定の XML を呼び出し )

PS C:\Windows\system32>  C:\Script\SendEmailScript.ps1

設定ファイルを指定する場合 ( 指定の XML を呼び出し )

PS C:\Windows\system32>  C:\Script\SendEmailScript.ps1 -ConfigXml "C:\Script\SendEmailScript1.xml"

Powershell Script

<#
    Script Name                : Send E-Mail Script
    Script File                : C:\Script\SendEmailScript\SendEmailScript.ps1
    Default Configuration File : C:\Script\SendEmailScript\SendEmailScript.xml
    Script Version             : 1.0
    ExectionPolicy             : RemoteSigned
    LastUpdate                 : 2019/01/27

    History :
      2019/01/27 Create New
#>

Param(
    [Parameter(Mandatory = $false)]
    [ValidateNotNullOrEmpty()]
    [String] $ConfigXml = ((Split-Path $myInvocation.MyCommand.path) + '\SendEmailScript.xml')
)

# Check Configuration File
If (!(Test-Path -Path $ConfigXml)) {
    Write-Host ("Configuration file not found.")
    Exit
}

# SendEmail Function
function EmailPreparation {
    # Read configuration file
    foreach ($Param in ([xml](Get-Content $ConfigXml)).Config) {
        # Set Cred Info
        $CredUser           = ($Param.Cred.CredUser)
        $CredPwd            = ($Param.Cred.CredPwd)

        # Set Mail Setting
        $SmtpServer         = ($Param.Mail.SmtpServer)
        $SmtpPort           = ($Param.Mail.SmtpPort)
        $FromAddr           = ($Param.Mail.FromAddr)
        $DestAddr           = ($Param.Mail.DestAddr)
        $MailSubject        = ((Get-Date -format 'yyyyMMdd-HHmmdd') + " " + ($Param.Mail.MailSubject))
        $MailBodyFilePath   = (Get-Content -Encoding Ascii ($Param.Mail.MailBodyFilePath) -Raw)
    }

    # Create Stmp Client
    $SmtpClient             = New-Object Net.Mail.SmtpClient($SmtpServer,[int]$SmtpPort)
    $SmtpClient.EnableSsl   = $true
    $SmtpClient.Credentials = New-Object System.Net.NetworkCredential($CredUser, $CredPwd)

    # Send Mail Processing
    $SmtpClient.Send($FromAddr, $DestAddr, $MailSubject, $MailBodyFilePath)
    $SmtpClient.Dispose()

}

# Write Error Log Function
function WriteErrorLog ($ErrorMsg) {
    foreach ($Param in ([xml](Get-Content $ConfigXml)).Config) {
        # Set Env
        $ErrorLogDirPath    = ($Param.Env.ErrorLogDirPath)
        $ErrorLogFileName   = ($Param.Env.ErrorLogFileName)
        $ErrorLog           = ($ErrorLogDirPath + "\" + $ErrorLogFileName)
    }
    If (!(Test-Path -Path $ErrorLogDirPath)){
        New-Item -Path $ErrorLogDirPath -ItemType Directory -Force
        If (!(Test-Path -Path $ErrorLog)){
            New-Item -Path $ErrorLog -ItemType File -Force
        }
    }
    Add-Content $ErrorLog ((Get-Date -Format "yyyy/MM/dd HH:mm:dd:ss") + " : " + $ErrorMsg)
}


# Send Email
try{
    EmailPreparation
}
catch{
    WriteErrorLog("Failed to send e-mail.")
}

XML

設定する項目は以下の通りです。サンプル XML を改版する際の参考にしてください。

設定項目 設定内容 備考
ErrorLogDirPath ログファイル格納先のパス
ErrorLogFileName ログファイルのファイル名
CredUser 認証ユーザ
CredPwd 認証ユーザのパスワード
SmtpServer SMTP サーバ IP か FQDN で指定
SmtpPort SMTP のポート番号 OB25P で 587 を指定するケースが多いはず
FromAddr 送信者のメールアドレス
DestAddr 宛先のメールアドレス 複数の宛先にする場合はコンマで区切る
MailSubject メールのタイトルに入れる定型文 不要なら空欄で OK
MailBodyFilePath メール本文に入れるテキストファイルのパス 下記サンプル XML では hosts ファイルを指定しています
<?xml version="1.0"?>
<Config>
  <Env>
    <ErrorLogDirPath>C:\Scripts\Logs</ErrorLogDirPath>
    <ErrorLogFileName>SendEmailError.log</ErrorLogFileName>
  </Env>
  <Cred>
    <CredUser>user01@hogehoge.com</CredUser>
    <CredPwd>password</CredPwd>
  </Cred>
  <Mail>
    <SmtpServer>smtp.office365.com</SmtpServer>
    <SmtpPort>587</SmtpPort>
    <FromAddr>info@hogehoge.com</FromAddr>
    <DestAddr>user01@foofoo.net,user02@foofoo.net</DestAddr>
    <MailSubject>Send e-mail test</MailSubject>
    <MailBodyFilePath>C:\Windows\System32\Drivers\etc\hosts</MailBodyFilePath>
  </Mail>
</Config>







Office 365 の機能でお手軽インシデント管理システムを作ろう

はじめに

2018 年も 1 か月を切りましたね。世の情シスさん、 SE さんは年末年始の切替え対応等で多忙なのでしょうか。 久々にブログを書こうとしたら、前回の投稿は 1 年以上前でした。ちょっと怠けすぎました。

ということで、本投稿は Office 365 Advent Calendar 2018 の 12 月 3 日 の記事です。

※本記事は、 2018 年 11 月 25 日 に開催された Power BI 勉強会でお話しした内容のまとめです。スライドデータは、本記事と同タイミングで Slideshare で共有しています。

こんな方へ

例えば、突然やってきた偉い人が情シスさんに「来週からヘルプデスク対応よろしく。メールだからそんな負荷かからないよね。じゃ、頼んだよー。」と「無茶振り」をしてあっという間に去っていく。しかも予算も時間もない。今回は、そんな困った状況に陥る情シスさんに贈る Office 365 に付帯する機能を活用し「お手軽に・追加費用なし」で解消しようという内容です。

f:id:ctrl-alt-delete:20181202092830j:plain
こんな方へ

前提条件

今回のシナリオは、下記 2 点を満たす必要があります。権限回りであれば交渉・調整次第だと思いますので、頑張りましょう。

  • 既に Office 365 の E1 , E3 のテナントが整備されている。
  • Office 365 のテナントの管理者権限を取得できる or 実装にあたって必要な権限を付与してもらえる。

利用する Office 365 の機能

利用する機能は、下記3つです。いずれも追加費用無しで利用可能です。

  • Exchnage Online の 共有メールボックス
    • 問い合わせを受け付けるメールアドレスとして利用します。
  • SharePoint Online のライブラリ
    • Excel データを保存するための領域として利用します。
  • Flow for Office 365
    • 自動化処理の肝です。

本記事のトレースで実現できること

いきなり難しいことに取り組むと、何かと詰みやすいのは何事も一緒。ということで本記事では、問い合わせの受付処理を自動化にフォーカスしています。これで犠牲者が減るかも!?

f:id:ctrl-alt-delete:20181202094507j:plainf:id:ctrl-alt-delete:20181202094511j:plain
ゴール

作り方

概要

準備から自動化の実現までは、下記 7 ステップあります。 オプションの部分は、準備 3 で保存した Excel データに問い合わせ内容 (メール本文) を書き込む際に書式が入るのが嫌な場合に実装しましょう。

f:id:ctrl-alt-delete:20181202101313j:plain
実装概要

いざ実装

まずは準備。

f:id:ctrl-alt-delete:20181202101826j:plainf:id:ctrl-alt-delete:20181202101936j:plain
準備 1: Exchange Online で共有メールボックスを作成

f:id:ctrl-alt-delete:20181202102037j:plainf:id:ctrl-alt-delete:20181202102041j:plain
準備 2: SharePoint Online でドキュメントライブラリを作成

  • Excel でテーブルを作成した際、テーブルに名前を付けておきましょう。 Flow でテーブルを指定する際に、テーブル名を指定することになります。

f:id:ctrl-alt-delete:20181202102151j:plainf:id:ctrl-alt-delete:20181202102155j:plain
準備 3: ドキュメントライブラリに Excel で作ったテーブルデータを保存

ここから本番。

f:id:ctrl-alt-delete:20181202102347j:plain
自動化 0: Flow を作成

  • メールの受信時刻をインシデント番号として採番します。 Office 365 では時刻情報が UTC で扱われているので、日本時間に変換すると同時に yyyyMMddHHmmssfff という書式にしています。例えば日本時刻で 2018 年 12 月 03 日 13 時 23 分 41.180 秒に受信した場合、 20181203132341180 となります。y や M 、 H は大文字・小文字で意味が変わるので、注意しましょう。

f:id:ctrl-alt-delete:20181202102519j:plain
自動化 1: 受信時刻を UTC から JST に変換し、インシデント番号として採番

f:id:ctrl-alt-delete:20181202102644j:plain
自動化 2: 問い合わせメールの本文を HTML からテキストに変換

f:id:ctrl-alt-delete:20181202102753j:plain
自動化 3: 問い合わせ内容を、インシデント番号等と共に Excel データに書き込み

  • 最後に作成した Flow に名前を付けて保存しましょう。これを忘れると最初からやり直しです。

f:id:ctrl-alt-delete:20181202102918j:plain
自動化 4: 受付完了メールを共有メールボックスから送信

まとめ

ということで、 Flow の全体像です。

f:id:ctrl-alt-delete:20181202103038j:plain
自動化 : まとめ

動作確認

メール送受信で確認

共有メールボックスにメールを送ってみましょう。受付完了メールが届けば成功です。

f:id:ctrl-alt-delete:20181202104808j:plain
動作確認 : メール送受信

Flow / Excel データの確認

Flow が成功していれば、 Success と表示されます。失敗していたら詳細を確認し、失敗した処理を修正しましょう。

f:id:ctrl-alt-delete:20181202105139j:plain
動作確認 : Flow 実行結果

Excel のテーブルに狙った値が入力されていることを確認しましょう。

f:id:ctrl-alt-delete:20181202105142j:plain
動作確認 : Flow 実行結果

以上で無茶振り対応完了

無事、無茶振りを回避できたでしょうか。これで世の中の犠牲者 (無茶振りしてきた方 ? 情シスさん ?) が減ることを祈っています (笑)

さいごに

  • 本記事は、 2018 年 11 月 23 日時点の仕様に基づいています。 Flow for Office 365 や Office 365 のサービス仕様が変更される可能性があります。
  • Flow for Office 365 は 5 分間隔で実行されます。リアルタイム処理ではありません。詳細は、公式サイトを参照してください。

4 日目は Yoshihito Machii さんの「運用効率化 (去年の続き&実装編) 」を予定されているそうです。よろしくお願いします。








【解決済み】多要素認証(MFA)を使用して ExO PowerShell に接続出来ない

Office365で多要素認証を設定しPowershellで接続しようとしたところ、当然ながらID/PWDでは接続できませんでした。

で、Googleで検索したところ
多要素認証を使用して Exchange Online PowerShell に接続する
という記事を発見。

いざ手順に従って事前準備を...と思ったらうまくいかない。

うまくいかないのは、多要素認証の Exchange Online リモート PowerShell モジュールの導入。

やっているのは

1. ChromeでOffice365テナントにサインイン
2. Microsoft.Online.CSE.PSModule.Client.application をダウンロード
3. Microsoft.Online.CSE.PSModule.Client.application を実行

何度やってもダメ。「アプリケーションを起動できませんでした。」と出て先に進めず。英語の記事でも探したけれど、解決策は見つけられずちょっと時間を浪費してしまいました。
そこで、もしやと思ってある手順でやってみたらすんなり成功。
成功した手順とは

1. IEでOffice365テナントにサインイン
2. Microsoft.Online.CSE.PSModule.Client.application をダウンロード→自動で実行される
3. Powershellが自動的に呼び出され起動

やっぱりInternet Explorerですよ、IE。MS純正ブラウザ。それを使わずして何を使うつもりなの?とMicrosoftさんに怒られてしまいますね。当然と言えば当然ですが、普段Chomeで色々やっていたのですっかりお作法を忘れてしまっていました。


ということで、忘れてしまっているとドハマリするので気をつけましょうというお話でした。

今回のケースに当てはまる方は少ないかもしれませんが、特にOffice365管理者の方は参考になさって下さい。





断捨離のノウハウメモ

断捨離しないと、しないと。。。と思いつつ、一向に捗らない。理解はしているものの、中々うまく行かず現在進行形です。

そんな悩める日常を過ごす中、BS朝日でやっていた「ウチ、”断捨離”しました!~捨てられない4家族 片づけ密着ドキュメント~」を見たので、個人的な外部記憶として残します。

私以外にも同じ悩みを抱えているであろう方にも、参考になれば幸いです。


捨てる・整理編

  • 使いたいと思うものを残す
  • クローゼットなどは上層・中層・下層で考える
  • 上層はいらないものが多い確率が高いので、最初に着手する
  • 材料や道具は目的別に3分類

収納のルール編

  • 全体の7割で納める 見えないスペースに詰める場合
  • 全体の5割で納める 中身が見える棚などに詰める場合
  • 全体の1割で納める 棚の上などに置く場合

日々の断捨離系続編

  • 1つ買ったら1つ捨てる
  • 本当に不要かは、しばらく脇によけて判断
  • 断捨離日記、書いたほうが(・∀・)イイ!!

収納のコツ編(箪笥に衣類を入れるものを小さくたたむコツ)

  1. 幅をそろえて3つ程度に畳む
  2. 筒状になった部分に、片方の端を入れる

このやり方は正直好きじゃないけれど、できるものは出来るだけやろうと思います。

断捨離の真意

収納を作っても、使いこなすだけのゆとりが必要。そのために、片付ける手間を減らすのが断捨離。

あとがき

番組を見ながら自分自身を照らし合わせると、きっと心を埋める手段がモノだったんだと考えさせらました。何が大事(最優先)なのかを考え行動するのって、分かっているけど中々出来ない。だからこそ、初動が大事なんだなって再認識しました。思い出は形で残すだけじゃない、それを心に刻んで前進する。それが心の整理につながるんですね。

このメモを次の週末からの活動に生かそうと思います。




Jabra Speak 710 MS レビュー

皆さんはお仕事でオンライン会議を利用していますか。
オンライン会議は、1 : n というパターンや n : n : n だったり 1 : n : n だったりしますよね。
1が自分ならヘッドセットで良いですが、n の一員の場合スピーカーフォンが必要だったりします。

SkypeやLyncでオンライン会議するために、Jabra Speak 410とか510が配布されている組織もあるでしょう。
でも、オンライン会議が増えれば欲しい時には貸し出されてないなんてことも。借りるのに手間が異常に掛かったりして、アホらしいとかもあるかもしれませんね。

ということで、スピーカーフォンとしてJabra Speak 410 , 510 , 710を比較した経緯・結果と710の良し悪しをレビューしたいと思います。
特に710は国内でレビューされている方もいらっしゃらないようなので、購入検討中の方は参考にして下さい。
ご質問等ありましたら、コメントなりTwitterでご連絡下さい。

何故Jabra?

Jabraじゃなくても良かったのですが仕事でSkype/Lyncを多用することもあり、MSモデルが用意されていることを前提としていました。その中でも次の4点が決め手になりました。

  1. 他社製品のレビューが微妙だったから(特に音の拾い具合)
  2. 職場で510を使っていて、使用感がわかっていた(音質はまずまず。音はちゃんと拾うから合格)
  3. Jabra STEELを使ってみて、Jabaraが好きになった(これでJabra信者になったと言えば、そうなるけど)
  4. 他社製品と比較し、後継製品をきちんとリリースしていた(これが710。継続した製品開発の姿勢を評価)

Jabra Speak 410 , 510 , 710の比較してみた

私が気にしたポイントをざっくり比較すると、次の通りになりました。

Model 410 510 710
発売年 2010年 2012年 2017年
サイズ 120φ 120φ 158φ
接続方法 USB(ケーブル直結) USB(ケーブル直結),Bluetooth3.0 USB(ケーブル直結),Bluetooth4.2
Bluetooth Profile - HSP v1.2,HFP v1.6,A2DP v1.2 HSP v1.2,HFP v1.6,A2DP v1.2,AVRCP v1.5
Bluetoothドングル - 別売(*1) 付属
Bluetoothインカム接続 - 可能 不可能(*2)
3.5mmヘッドホンジャック あり あり なし
集音性(会議出席人数) 最大4 最大4 最大6
価格 2万円前後(*3) 2万円前後(*4) 4万程度(*5)

*1)ドングル付属モデルもあるようですが、日本国内で販売されていない様子です。ドングルを別途購入も可能ですが、結果高く付きます。
*2)取説等には記載無し。できそうですが未確認。
*3)AmazonJPで確認。場合によっては、1.7万円程度でも入手可能なようです。
*4)AmazonJPで確認。場合によっては、1.7万円程度でも入手可能なようです。Lenovoでクーポンが使えると1.5万程度になることも。
*5)AmazonJPでは並行品のみの為、公式サイト価格を記載しています。

で、どれにする?

まず410と510で迷いましたが、似たような価格かつ今後ワイヤレスでつながるのがStandardになると考え410は落としました。
次に510と710で迷いました。主に↓の項目で大いに悩みました。

  1. 価格 → 510MSが圧倒的。2万円は大きい。
  2. モデルのライフサイクル → 510は発売されて5年も経っており、メーカー修理等が発生した場合のパーツ枯渇が心配
  3. Bluetooth → 510は3.0で永く使った場合、接続先機器の対応を考慮すると710が優位
  4. 音質 → 510はお世辞にも良いとは言えませんでした。710は海外のYoutuberがレビューしていて、ソレナリに良さそうだったので710が優位に
  5. 機能の有無1 → 3.5mmヘッドホンジャックがある点は510に軍配が上がりました(*6)
  6. 機能の有無2 → Bluetoothドングルが付いてくるのは、Bluetooth非搭載PCでも使えるようになるので710が優位に(ドングルを個別で入手も可能ですが、合算すると価格が拮抗します)
  7. 機能の有無3 → 背面スタンドが付いてくる、2機あればステレオスピーカーになるので710が優位に(2台も買う?って話はあるけど)

ということで、710に傾きつつ価格で最終的に悩むことに。
国内で正規品が流通していないこともあり、並行品は保証が心配でした。たいして安くならないし。
そんな訳で公式サイトで購入しようとしたところ、クーポンコード入力欄がありGoogleで検索したところ20%Discountできるコードを入手。
しかし510でも安くなるので結局価格で悩みつつ、最終的には深夜に到着した出張先のホテルで変なテンションでポチる結果(*7)に。最後は勢いでした。

*6)この3.5mmヘッドホンジャックは、スピーカーに出せない会話やシーンがあった場合イヤホンを使って聞けるというもの。仕事で利用する場合、そういったシーンになることもあるかと思います。
*7)4万が3.2万になったと喜んでいたら、税別だったようで結果的に3.5万程度になりました。

配送は?

日本法人が国内から発送されると思っていたら、香港からUPSで日本まで届けられました。日本国内はUPSの委託先としてヤマトが届けてくれました。
UPSのトラッキングでは土日の配送が動いていない様に見えましたがヤマトの拠点間配送は行われていたようで、土日を挟んで5日程度で配送されました。

梱包は外箱が運送用の箱に入っていて、海外からの荷物感はあるものの外箱含めきれいな状態で届きました。

使用してみて

結論から言えば、買ってよかったです。お財布へのインパクトはありましたが、お値段以上の今のところお仕事をしてくれてます。(主に仕事で大活躍)
ということで、良し悪しをまとめました。参考にして下さい。

  1. 良かったところ
    1. 音質がモノラルの割にとても良い(510みたいな電話音質ではない)
    2. ドングルとペアリング済みなので、速攻で使える
    3. 携帯(iPhone7Plus)ともバッチリ接続可能
    4. 集音性がやっぱり良い(大きめの会議室でもちゃんと音を拾ってくれるし、スタンドで発言者に向けることもできる)
    5. Bluetoothドングルが本体に格納できる上に、キャリングケースがあるので紛失の心配が無い
  2. 悪かったところ
    1. やっぱりお高い(510にBluetoothドングルを付けたら、拮抗するので良し悪しありますが。純正じゃ無くても接続できるはずなので、それで試すのもアリです)
    2. 2機無いとステレオにならない(モノラルでも結構音は良いですけどね)
    3. 410/510と比較して、ちょっと大きい

最後に

かなり主観の入ったレビューになってしまいましたが、参考になりましたでしょうか。私が言えるのは「利用頻度が高い方なら購入する価値はある」と言うことです。
会議ではスピーカーフォン、イベントやプライベートではスピーカーといった使い方をされるなら710は良いと思います。
むろん510でも会議に利用するなら問題ありません。価格も底値感が続いているようなので、予算に応じてモデルを選択されるのが良いでしょう。
購入せずに費用対効果を量ることは難しいですが、製品選定の一助となれば幸いです。




ペーパレスの効果とは。

■はじめに

エンジニアの皆さんは、打ち合わせで紙を配っていますか?納品時に紙資料を納めていますか? ベンダに発注する企業の情シスさんは、打ち合わせや納品に紙資料を要求しますか?

紙の資料って良いですよね。視認性が高いし、メモを資料に直接書き込めますし。 とは言え、打ち合わせ資料なんかは最終的にはスペースの問題もあり必要に応じてスキャンしてデータして廃棄となりますよね。

最悪なのは、打ち合わせが終わったら速攻で廃棄される資料。それくらいの扱いしかされないのに、打ち合わせの主催者や関係者は必死に時間(工数)を割いて資料準備に勤しみます。 状況によっては残業してまでやることも。本当は早く帰りたいという人も多いだろうに。。。(生活残業の人は居ないことを前提としています)

巷ではペーパレス会議を推奨する声や働き方変革なんて言葉もよく聞こえてきていますよね。 先日から残業時間の制約で、より効率化と収益UPを両立は難しくなってきているのではないでしょうか。

ということでペーパレス会議を3ヶ月ほど実施したら、どれくらいコストカットできるのかを試算してみました。 ついでに納品物もペーパレスにした場合も試算してみました。 色々な数字が高すぎる等のご意見もあろうかと思いますが、あくまで想定としてご覧下さい。 そして、よろしければペーパレス推進を上層部に数字でアプローチするヒントにしていただければ幸いです。 もう試算したけど、詰めが甘いっ!というご意見もお待ちしております。

では、いきます!

■ペーパレス会議編

前提

試算するにあたり、前提を以下のようにしました。特に金額のあたりは所属される会社等により左右されるので、本記事を参考に試算される場合は置き換えて下さい。 特に印刷時の物的コストは、複合機のリース契約等でも左右されます。私はリース契約には関与していない為、妥当な数字に置き換えをオススメいたします。

  • 週1回程の打ち合わせで、参加者は7名程度
  • 準備は原則主催者
  • 印刷する資料は、A4で両面2UPと1UPを組み合わせた30枚程度の資料
  • 印刷時の紙代は、トナー代込で500枚で700円とする
  • 印刷者は時給2,000円程度で稼働する想定とする
  • 印刷時の体裁修正や再印刷、資料配布のための準備(資料を一式にして運搬する等)は1.5時間/回を費やした想定とする

紙資料を準備した場合の費用

  • 物的費用

    1. 1回あたりの枚数 → 30(枚)*7(名)=210枚/回
    2. 3ヶ月の総枚数 → 210(枚)3(ヶ月)4(週間/月)=2,520枚 ※2,500枚として試算します。
    3. 印刷時の紙代 → 2,500(枚)/500(枚)*700(円)=3,500円
  • 人件費

    1. 資料作成時間 → 試算対象外(打ち合わせがアレば作成するので)
    2. 資料印刷時間 → 1.5(時間)2,000(円/時間)3(ヶ月)*4(週間/月)=36,000円
  • 総費用
    3,500円(物的費用)+36,000円(人件費)=39,500円

ということで、約13,000円/月 程度のコストカットができた事になりました。 実際には電気代とか詳細な計算には材料が幾つかありそうですが。

1つの打ち合わせだけでこの程度ですので、他のプロジェクトや社内会議で同僚も同様の動きをした場合 恐ろしい数字が計上されることもあり得るのではないでしょうか。 特に上層部の方は、紙資料を準備させない方針をトップダウンで指示して欲しいものです。

■納品物編

では、続いて納品物として設計資料を印刷して納品した場合とデータ納品時の試算です。

前提

前段と同様、前提条件を以下のようにしました。

  • 納品ドキュメントは、A4両面1UPで1,000枚程度の資料(キングファイル1冊分)
  • 中表紙の準備を含め、印刷までは各担当者が実施
  • 表表紙や全ドキュメントの見出しは、プロマネが作成する
  • データ納品については、中表紙不要でフォルダ分けしたデータを格納したCD-Rにラベルを印刷する
  • 納品CD-Rに格納するドキュメントは、合計600MB以下となる想定とする
  • 納品CD-Rの作成は、プロマネが実施
  • ファイリングは、プロマネor担当分野のリーダーが実施
  • ファイリングされたものは、プロマネが営業に渡してミッション終了とする
  • 印刷時の体裁不備の修正を含め、担当者が2日間(16時間)・プロマネが半日(4時間)費やした想定とする
  • 納品CD-R作成は、ラベル印刷を含め1時間費やした想定とする
  • 再印刷は全ドキュメントの20%発生するものとする。→1,200枚程度の資料を印刷することになる
  • 各担当者は時給1,500円程度で稼働する想定とする
  • プロマネは時給2,000円程度で稼働する想定とする
  • 印刷時の紙代は、トナー代込で500枚で700円とする
  • データ納品用CD-Rは、ラベル印刷時のインク代・ケース代込みで1枚100円とする

紙資料で納品する場合

  • 物的費用
    印刷時の紙代 → 1,200(枚)/500(枚)*700(円)=1,680円
  • 人件費
    1. 担当者の資料印刷時間 → 16(時間)*1,500(円/時間)=24,000円
    2. プロマネの資料準備時間 → 4(時間)*2,000(円/時間)=8,000円
    3. 人件費合計 → 24,000円+8,000円=32,000円
  • 総費用
    1,680円(物的費用)+32,000円(人件費)=33,680円

データを納品する場合

  • 物的費用
    納品CD-R代 700円
  • 人件費
    2,000(円/時間)*1(時間)=2,000円
  • 総費用
    700円(物的費用)+2,000円(人件費)=2,700円

ということで、データ納品にすると約30,000円程のコストカットが実現できました。 紙資料で納品時にデータも納品する場合、約34,000円程度のコストカットとなります。 同規模のプロジェクトが他にも同時進行していた場合、見逃せない数字になるのではないでしょうか。

■最後に

もちろんペーパレスしなきゃ全否定みたいな事は言いません。 とは言え温暖化云々も叫ばれる世の中ですので、後世のためにも企業の収益性を少しでも改善するためにも ペーパレスでやりくりすることを検討してはいかがでしょうか。




おまけ

完全に余談です。冒頭の書類をスキャンする時、複合機を使った際のお話。 色分けしてメモを取っている都合でカラースキャンしたところ、X社では満足のできるPDFが生成されたのですがC社ではちょっと粗さが目立つ結果に。 最新機種では結果が逆転することもあるかもしれませんが、他社にも情報共有することを考えると綺麗さも大切ですよね。 もし複合機の選定に関わる方は、印刷精度やコスト以外にもスキャン時の精度にも配慮されると良いと思います。



メール・スケジュールの切替えはソレナリに大変というお話(O365編)

はじめに

ようこそ、いらっしゃいませ。
突然ですが、アナタは企業の情シスさんですか?それとも、企業のITインフラを設計・構築するSEさんですか?

今回のエントリは、どちらの方にも参考になると思う内容になっていると思います。

オンプレ環境からの切替ならオンプレ派?クラウド派?

本Postに辿り着かれた方は、H/WやS/Wのサポートが切れるとかが理由で、オンプレかO365を比較検討されているところでしょうか。

とりわけメールって基幹システムに匹敵する重要度という会社も多いので、止まらない(に等しい)ということが必須要件だったりしますよね。

もちろんオンプレからオンプレのリプレースもアリです。ただオンプレ環境で止まらない(に等しい仕組み)を作ってバックアップやら災対とか考え始めると結構お金かかるんですね。しかも運用もソレナリのスキルを要求されます。

情シス部門の方であれば、それらの維持・運用にコスト・リソースを割ける状況ですか。
SEさんであれば、お客さんがインフラの維持・運用していくに十分なリソースを確保できているでしょうか。運用を肩代わりするサービスを提供するのもアリですが、十分な費用をいただけそうでしょうか。

答えが"No"という方、SaaS型のクラウドも選択肢としてアリじゃないでしょうか。
あ、決してMSさんの回し者ではないですよ。念のため。

O365は契約したら直ぐ使える?

クラウドなんだから、契約したら直ぐ使えるようになるんでしょ?」という方が、まだまだいらっしゃいます。
まぁ、使えます。。。使えますけど、使うための考慮とか環境設定ってものがあるんです。メールならDNS切替とか、エンドユーザさんのメーラー設定とか。

情シスさんやSEさんは、そういった方に向けて利用開始までにこんなことをやらないとだめですよってことを説明するネタとして参考にしてください。

で、何を準備するの?

最低限コレくらいは、準備段階で考慮/検討しておきましょうという項目です。要件次第では、更に必要となるものが出てきます。短納期で色々やれます・やりますというベンダさんもいらっしゃるようですが、色々と条件や制約も多いこともあることを念頭にベンダ選定することをお勧めします。
「まだプロジェクト炎上で消耗してるの?」とか言われないためにも是非。

  • プロジェクト体制

メールの仕組みやExchangeだけでなく、ADについても知識を要求されます。情シスさんは既存システムを把握されている方、SEさんは知識をお持ちの方をアサインしましょう。色々できちゃう人を揃えると費用に跳ね返りますが、考慮漏れ等を低減するためには必要な費用です。トラブって対応工数を割くよりもSEの質にお金をかけることを強くお勧めします。

  • 回線

O365ってソレナリに回線の帯域を食います。帯域を確保するために専用に回線を準備されるか、既存回線の増速をしましょう。

利用者数や利用するサービスにもよりますが、環境によっては複数のIPアドレスが必要となります。また、O365への接続を制限する場合、固定IPを取得しO365側で制限する等も必要となってきます。

  • ActiveDirectory

ADのID/PWDをO365でも使いたいという場合、まずはその運用状況を確認しましょう。同期するツールとしてAzure AD Connectが必要となりますが、同期設定やアドレス帳の整備で非常に重要となります。

O365に接続するには、インターネットに接続する必要があります。これまでオンプレ環境だったという場合、切り替えたらProxyが死亡。。。なんてことも。認証Proxyの場合、うまく繋がらないということもあるようです。専用回線を準備した場合、O365向け通信のみ迂回させる策(例えばPacファイル)も検討しておく必要があります。

既にメールを利用されていれば、インターネット向けDNSにMXレコードが登録されています。O365を利用するためには、MXレコードの切替以外にも幾つかのレコード登録が必要です。切替/移行の方法によっては、複数回に分けてDNSレコードの変更が必要となります。DNSレコードを自社で変更できないという場合、変更作業を発注する必要が出てきます。

ExchangeOnlineは2世代前のOutlookまでをサポートしています。もし、Officeのバージョンが古いという場合はOutlookだけ入れ替えも検討しておきましょう。もちろんラインセンスも必要です。ブラウザだけで利用するなら、IEのバージョンを確認しましょう。

  • 移行/切替計画

ユーザさんのデータ移行だとか並行稼動させる/させないといったことを取り決め、マニュアルの整備や切替アナウンス等を計画しましょう。いくら予算や検収の都合があるからといって、急いでも良いことは一つもありません。最終的に振り回されるのは、エンドユーザさんです。そこには役員さんなども含まれますから、是非安全と慎重を重視しましょう。

  • SSOする?

Single Sign Onを利用したい場合、ADFSサーバを構築し認証情報のやり取りをできる環境整備が必須となります。

準備と並行して考えよう

準備が整ったので、切替えだぜっ!という情シスさん、ちょっと待って。会社の様々な方針に沿った検討、できてます?既に考慮済みかもしれませんが、あとで問題とならないために考えておくことを少々。

  • 労務的観点とセキュリティの観点

O365ならどこでも仕事できる!という社畜仕事大好きな皆さんには嬉しいかもしれませんが、労務的観点・セキュリティの観点でアクセス制限をどうするか考える必要があるでしょう。
BYODはNGとか会社以外からの接続は拒否するとか。。。etc

  • 海外の現地法人との連携

海外進出している法人の場合、現地法人との連携も検討課題になるでしょう。その場合、個人情報の取扱い等が現地の法規に沿っているのか確認します。場合によっては、O365のテナントを分ける等が必要になります。

切替えが終わったら

切替え、お疲れ様でした。問い合わせは多かったですか?ユーザさんのリテラシによっては、一時的とは言え対応が増えて大変だっただろうと思います。後は、運用を頑張りましょう。特にADのアカウント管理は、O365側の設定にも影響してきますので慎重に。
設定によっては、管理画面からは設定できないこともあります。Powershellなら設定できるということもあるので、PowershellのスキルUPをオススメします。



いかがでしょうか。結構やることが多いと感じたのでは無いでしょうか。
切替えを検討中という皆さんのプロジェクトが、燃えずに完了できることを祈っています。