F4はWindows全般で有効なので、これで閉じてしまってもよい。これはショートカットバーに前後のメールに移動するボタンが標準で表示されているから使える。<と>はPCによっては位置が探し辛いので、4と5で覚えるのがよい。仕訳ルールは使わず、アーカイブフォルダを上手に使え。仕訳したくなったら検索フォルダを使え。メール処理状態で整理派の仁義なき戦いである。大事なのは、どちらも試して、自分に合った方法でやってみる事である。環境が変わった場合、やり方を見直すのも重要である。私はどちらも試して仕訳ルールを作ってフォルダ分類するやり方に落ち着いたが、この本を読んで数年ぶりに仕訳ルールを全削除し、メール処状態でフォルダ整理運用にした。Teamsがなく、全てのコミュニケーションをメールでやり取りしていたが、今は大半がTeamsに移行し、メールの総数が減ったからである。新規OAツールが導入されたり転職したりして環境が変わった場合、今までのやり方が最適ではなくなる可能性があるため、環境が変わる前に自分のやり方を見直すことが重要である。iOSでは利用できないため、ブラウザやモバイルデバイスからメールを利用することが多い場合、検索フォルダに頼ることは出来ない。本書は全般的にデスクトップ版Outlookでメールの処理をする事に主眼が置かれているため、自分の使い方がどの程度合致しているかを見極めて読む必要がある。自分好みにクイック操作やクイックパーツを利用すればもっと時短できる。私の意見この2つの機能は自分のOutlookの利用方法を分析して、使い方を検討する必要がある。「クイックパーツで定型文を登録すれば時短になる」と著者は主張するが、私の場合、月のメール送信数は129通(前エントリ:果たしてOutlookだけで100時間の時短を達成できるのか?の調査結果参照)。この129通のうち、定型的な内容で返信しているメールが何通あり、クイックパーツによってメールを作成する事で短縮できる時間は何分か?日本人の平均タイピング速度は100文字(ひらがな)/分らしいので、クイックパーツが100文字程度であれば、1通につき1分ほどの時短。クイックパーツで作成できるメールが10通あれば10分の時短、年間では120分の時短となる。そのためにテンプレートを作成し、クイックパーツを設定し、送信するタイミングでクイックパーツを思い出すコストはどうか?ついつい手打ちしてしまうこともありそう。私の場合、129通のメールで定型的な内容で返信しているメールは2通だけだったので、絶対に普通に返信した方が早いです。自身の毎月のメール送信数を調査し、効果を算出してから、取り組むのがよい。予定表グループでも同じような事ができるのに、なぜOftファイルでスケジュール確認をするのかよくわからなかった。(予定表グループの)予定表ビューを使った予定表閲覧は時間がかかるから、あえてスケジュールアシスタントから確認したい、というのなら、同僚のメールアドレスを連絡先や連絡先グループに登録して、会議出席依頼から確認すればよいと思った。Oftファイル自体は有用な機能であり、例えばヘルプデスクで定型文をグループで共有する場合、グループでアクセス可能なディレクトリに返信テンプレートを配置し、それを元に返信する、という事が出来る。(2019年5月2日追記)著者から指摘あり、Oftファイルは、部内のファイルサーバーなどで共有して利用する想定、とのことでした。確かにこの使い方なら、自分の予定表グループをメンテするより、グループ全体で利用できるからいいかも。いいのは、システム管理者が組織構造に合わせたグループを作成し、グローバルアドレス帳に公開することだと思うが。メールの1分遅延ルール著者の意見クライアントルールで1分遅延ルールを設定すると無料で誤送信防止ができる私の意見これはマジお勧めで、著者の提案する例外ルールを設定するのも併せてお勧め。注意点としてOutlookで送受信タスクが走るタイミングで、送信トレイに1分以上保管されたメールが送信されるので、最速で1分、最遅で2分くらい、送信にかかること。iOSの時には適用されないので注意。6章:もっと時短したい人のためのショートカット気になったところだけ。標準書式に変換これは知らなかったので活用している。ゴシックがまざってイラっとしてしまう所がこれで直せるのは便利。受信トレイに移動これは知らなくて便利だと思いました。送信済みトレイに移動するショートカットもほしかった。1で署名のショートカットを呼び出せる、というテクニック。署名を呼び出してます。慣れれば1秒かからない。仕事柄、複数のPCでOutlookを使うことがあるので、ソフトウェア固有の設定をいじるのが煩雑で管理しづらく、出来るだけ標準ショートカットで済ますようにしています。パスをコピーこれは自社の共有ストレージが全員が同じUNCパスでアクセスできるファイルサーバーかhttps://~でアクセスする、オンラインストレージかで有用性が変わってくる。うちの会社はほぼファイルサーバーが廃止されSharePointが主要ストレージ。SharePointのファイルにアクセスするにはブラウザからファイルを選択するOneDriveで同期して、ローカルファイルとして開くの2通りがあるのだが、2で同期したファイルのパスは自分のPC固有のパスとなり人に送っても開けない。よって、https://で始まるパスを人に伝えなければならないが、この時に便利なのが「ドキュメントの場所」というクイックアクセスツールバー。数字で、ドキュメントを開いたままパスをクリップボードにコピーできる。編集し終わったファイルのパスを誰かに伝える、という利用シーンを考えても、わざわざエクスプローラーに戻ってパスをコピーするよりも有能。「ソフトウェア固有の設定をいじるのは嫌」といいつつ、これだけは代替のショートカットがないので、設定している。余談だが、book1.xlsxのような一時的なドキュメントを他人にシェアしたい時、一度PCに保存してからメール添付ではなく、ワンボタンでメール添付できるような機能も設定している。まとめ本書の基本的なテクニックは抑えるとして、応用編は自分のOutlookの利用分析を行った上で適切なテクニックを覚るのがよいと思う。カネが取れる)ので、Outlook利用頻度が多い人は研究してほしい。予定表の活用テクニックがあまり記載されていなかったのが弱点かと思われるが、Outlookでメールは使っているが予定表は使っていない会社は意外と多い事、メール利用に比べて予定表利用の方が個別最適化されて汎用化しづらい事から、書籍として出すのは難しかったのかな、と思う。全てのテクニックが有用だとは思えないが、冒頭にも書いたが、みんながなんとなく使っていたOutlookに光を当てたという点で、本書は素晴らしいです。著者は「Excelのスキル本はあったがOutlookはなかったので書いた」と言っているが、ExcelはVLOOKUPを使わなければ出来ないことはあるが、本書のOutlookテクを使わないと出来ないことは、正直言ってない。Outlookは万人が使用し、VLOOKUPと違って全員に効果があるテクニックが本書には書かれてますので、Outlook主体の業務の人は是非チェックしてみてください。Teamsの使い勝手が良くなることを心より期待しています。2019.04.24onmicrosoft.comがバレると何が困る?前回のエントリの続きです。どうぐ前回のエントリの結論:xxx.onmicrosoft.comを隠し通すのは難しいonmicrosoft.comがバレると何が困る?困る事もありますが、別にそうじゃなくても既にバレてるので困らないこともあります。365を使っている事がバレるので、フィッシングメール送って偽のログイン画面に誘導できたりする。365利用しているかどうかは会社のメールアドレスを知っていればnslookupで一発で調べられるので、xxx.onmicrosoft.comを隠しててもバレます。利用したユーザーIDを探してログイン施行することが出来ます。企業のもつアカウントの99%くらいは会社ドメインのログインIDなので問題なさそうなのですが、xxx.onmicrosoft.comを持つIDはシステム導入時やテスト時に作ったまま放置しているアカウントだったりして無防備なことが多いので、事実上、問題になる事があります。まれに「悪意のある外部ユーザーからログイン施行されないため、ログインする会社ドメインをメールアドレスと別のものにしたい」という要望を受けますが、ゼロトラスト理論を考えるとそれこそ隠し通すことが難しく、ユーザー利便性だけが低下するのでやめた方がいいと思われます。仕様上、各ユーザーのセカンダリメールアドレスに[ユーザーID]@xxx.onmicrosoft.comというメールアドレスが付与されるので、スパムメールを送りやすくなります。いえ、セカンダリメールアドレスを指定しなくても普通に会社ドメインのメールアドレス[ユーザーID]@xxx.co.jpにメールを送り付ければいいので、onmicrosoft.comがバレたことによって新しく困る事ではありません。結論:どちらにしろメールは受信できてしまうので、無影響SharePointサイトのURLがバレる会社のイントラのURLがバレるので気持ち悪い、という意見。いえ、SharePoint外部共有やTeams外部招待、OneDriveファイル共有を許可している会社なら、自サイトへのユーザーアクセスを許可しているわけで、今更会社のイントラURLバレを気にするのもナンセンスかと思います。SharePoint外部共有とかしてないから、イントラのURLがバレるのが気持ち悪い!というのは感覚としては分かりますが、メールと違って権限管理をすれば外部から見れないので全く実害はないです。結論まとめAADログインIDのonmicrosoft.comドメイン部分がバレるのが、onmicrosoft.comがバレることによる新たなデメリットと考えます。結論から言うと、一般ユーザーアカウントに対して多要素認証などを仕掛けている場合に、多要素認証トラブル時のシステム復旧用に、多要素認証を回避するためのアカウントを用意するパターンでonmicrosoft.comドメインを使う場合があります。ここで、既定で用意されているxxx.onmicrosoft.comを認証用ドメインとすることがあります。以下の記事でもそれが推奨されています。緊急回避用アカウントを会社ドメインで作成しつつ、フェデレーション先のIdPで多要素認証をかけないこともできるが、どちらにせよIdP自体が死んだときは影響ありAzureAD認証環境の場合AzureAD認証環境の場合、認証制御はEM+Sの機能で行います。EM+Sの制御単位はユーザー個別orセキュリティグループであり、認証ドメインがなんであるかは関係ありません。よって、緊急回避用アカウントを会社ドメインで作成しても問題ありません。みたいなアカウントを作成し、、この条件を満たせますよね。よって、ADFS環境でonmicrosoft.comの緊急回避用アカウントを作成する必要はなく、会社ドメインとは別の、AzureAD認証を利用するドメインを用意すれば、ADFS環境でもonmicrosoft.comも抹殺できます。xTECH(クロステック)と考えると、素直にxxx.onmicrosoft.comのドメインを利用し、緊急回避用アカウントのIDを複雑にすることで(もちろんパスワードも)十分に要件を満たせるのではないでしょうか?AzureADの素のセキュリティEM+S使わないと脆弱だ!みたいな説もありますが、AAD素の機能でそれなりのセキュリティレベルは担保しています。ID/Passwordを複雑にする、という対策は、IdPが総当たり攻撃を許してしまえば全くの無力ですが、当然その対策はされています。詳しくは以下エントリを読んでもらいたいし、私も昔に説明エントリ書いてました。スマートロックアウトのカスタマイズ機能について-ぷりどうぐよって、IDもパスワードも複雑にしておけばまず大丈夫、と言えるでしょう。結論ADFS環境でもonmicrosoft.comのログインIDは抹殺できるが、ナンセンスで無意味なので、onmicrosoft.comのIDを抹殺する意味はない。AzureADのセキュリティ機能を信用し、辞書攻撃にヒットしないようなID/Passwordを作れば、AzureADが総当たり攻撃には対応してくれる。365)の契約毎に割り当てられる一意のドメインであり、契約後は変更不可。独自ドメインを持っていないユーザーや、検証環境で気軽に使えるようにと用意されたものだが、本番環境では会社のドメイン(xxx.co.jp)を使うのが普通であり、xxx.onmicrosoft.comは不要となる。契約時に割り振られるもの(名前は自分で選べる)。almea.jpが自分所有のドメイン。以下、本番環境であることを前提に話す。隠蔽したいのか?よくある2大理由。見てしまったら「xxx.onmicrosoft.comって何ですか?スパムですか?」とユーザーの混乱を招き、不要な問い合わせが発生する可能性がある。セキュリティ的によろしくない理由はいろいろありますが、onmicrosoft.comを利用してクラッカーに狙われる恐れがある。onmicrosoft.comが表示されちゃう場所SPO、Skype、ExOL、Teamsの四天王を論じる。Swayとかは知らん(私がナレッジなし)SPO(OneDrive)SPOサイト自体にxxx.sharepoint.comという名前付けがされるので、内部ユーザーには見えてしまう。自分のOneDriveを利用するときに見える。SPOやOneDriveで外部共有をする場合、xxx.sharepoint.comが含まれる形で共有するため、外部ユーザーにバレてしまう。SkypeSkypeはテナント側でデータベースのようなものは持たず、あくまで個人の連絡先を情報として閲覧できる形となる。SIPアドレスが見えるため、こいつが会社のドメインであれば、xxx.onmicrosoft.comは見えなかったはず(最近構築してないから怪しいまぁほぼTeamsに置き換わってるからいいや...。ExOL明示的にメールアドレスを付与しなければ、[ユーザー名]@xxx.onmicrosoft.comというメールアドレスが付与される。明示的に会社メアドを付与した場合でも、セカンダリアドレスにというアドレスが強制的に付与されるので、[ユーザー名]@xxx.onmicrosoft.comでメール受信ができてしまう。「明示的にメールアドレスを付与しなければ」というのは、Teamsでチームを作成した時にも当てはまるので、ユーザーが自由にTeamsを作れるシナリオだと、作るそばから@xxx.onmicrosoft.comで送信可能なメールボックスが出来上がっている(※)、ということになる。2019/4/23追記Teamsからチームを作成した際に出来る共有メールボックスに対しては「メールボックス所有者として送信する」権限が付与されないので、設定変更なしにメールを送ることはできませんでした。国井さんのブログにもあったが、メアドを隠蔽してもO365の仕様上、テナントからメール送信時にDKIM署名をするので、ヘッダーにxxx.onmicrosoft.comのドメインが記録されるTeamsユーザーとしても管理者としても利用していますが、onmicrosoft.comが見えてしまう場面はない。これはTeamsのUI上では、という条件付きであり、裏側のSPOやExOLを開いた瞬間にxxx.onmicrosoft.comがバンバン見える。これはSPO,ExOLの項目で説明していく隠ぺいの検討SPO内部アクセスの際にxxx.onmicrosoft.comの代わりにxxx.co.jpを使わせるよう、内部DNSにCNAMEを記載して隠蔽することが出来る。nslookupでCNAMEの変換先を引けばバレてしまうし、ファイル共有を使うと自動的にonmicrosoft.comを含まれるアドレスが発行されるので隠蔽は難しいと思う。ExOLメールフロートランスポートルールでxxx.onmicrosoft.comが含まれるメールは破棄する設定にしておけば防げる。マイクロソフト社からの通知メールなどがxxx.onmicrosoft.com宛に送られてきても破棄するので注意する。前に問い合わせた時は、通知メール系はプライマリメールアドレスを見ているとのことなので、管理者IDをxxx.onmicrosoft.comのまま運用する場合は、UPNはそのまま、プライマリメールアドレスをxxx.co.jpにしておく。セカンダリアドレスユーザーオブジェクトにはxxx.onmicrosoft.comが付与されたままなので、Outlookの連絡先カードを使うと一般ユーザーでもxxx.onmicrosoft.comの確認が可能。DKIM署名DKIM署名にxxx.onmicrosoft.comが記録されちゃう問題は、DKIM署名を無効にすることで回避できる。DKIMを無効にする賛否はあれど、日本国内では4割程度の実装であるため無効にしても即スパムとは扱われにくい事、3rdパーティーMTAをかませて、そこでDKIM署名を行うことで回避できること、DMARKを使うことが代替策となる(DMARKだけは実装したことないので、実はこいつもonmicrosoftを外に出す可能性はある)まとめ内部漏洩SPOのサイト、OneDriveの自領域、Outlookより自分の連絡先情報を見る、など手段がありすぎて隠蔽は難しい。自テナントのSPOサイト(OneDrive含む)にアクセスさせない、メールフローの隠蔽、DKIM署名の削除で対応できる。よって、バレるのは内部ユーザーだけなので安心!...というわけにはいかず。ゼロトラスト理論だと内部ユーザーを信用しないし、仮に信用してもこんだけ埋め込まれてたらどっかから漏れるでしょということで、バレる前提で考える、隠蔽するのに無駄な工数をかけない方がよいと思いました。MS-500,MS-100,MS-101を受験して合格しました。