Interact2019に行ってきました。

Interactとはうるしまさんが個人的に開催している、MS系技術を中心としたイベントです(合ってるよね?) 当日は、生うるしまさんを遠目から見れてありがたかったです。

Interact 2019 – connpass

PR05 SharePoint Online SharePoint Online モダンサイトの全体設計

SharePoint Online モダンサイトの設計 – SharePoint の利用計画 – #‎MSInteract19‬ #PR05

  • SharePointを魔改造して何でも作る → 他のO365サービスを組合せ、SharePointはそれらをつなげる時代に
  • SPOモダンサイトは、いろんな所にある情報をSharePoint上で再整理、発見しやすくすることが価値
  • SharePoint一択だったオンプレ時代と違って、YammerやTeamsなど別の形の”グループコミュニケーションサイト”も出てきているので、SPOにこだわる必要はない。

ということで、このコンセプトが一貫して話されていた非常に分かりやすいセッションでした。

分かりやすかったのですが…。Office 365で飯を食うプロとしては、各製品の特長を理解して、お客様の業務・ニーズも理解した上で、最適な製品構成をお客様に提案する。…ってめちゃくちゃ大変やんけ。顧客の業務を理解する能力、それに合わせてどのようなデジタルツールを利用するかのコミュニケーション論も語れないといけないし、各サービス・コンテンツをSharePoint上で再整理、発見しやすくするためのポータルデザイン能力、ある程度ユーザーに任せる場合も、どこまでユーザーにやらせるかっていう線引きをシステム管理面でやらなきゃいけないし。もしかしてSharePointエンジニアは神、いわゆるゴッドじゃないと務まらないのでは!?!?!?!?!?! Exchangeエンジニアなんて客に言われるままにメールボックスぽちぽち作成してるだけなのに…。

そんなわけで、最近SharePointに足突っ込んでる私としては、沼の深さにガクブルしてしまったセッションでした。社内のSharePointエンジニアをもっと尊敬しようと思います(ここまで考えてるのかな)

さて、セッション中で”モダンサイトはできる事は少ないのは事実だが、それは管理者視点であり、ユーザー視点だと今までよりできる事が多くカスタマイズも容易”という話がありました。確かにそうだなぁ…と思いますが、ユーザーがポータルを何となく作ってみたが、これで本当に大丈夫なのか?という疑問は出てくると思います。例えば、WordPressのテンプレートでも、デフォルトのものをカスタマイズして使えるのは使えますが、ユーザービリティ高くてSEO対応してて、セキュリティも万全なテンプレートがあったりするわけで…。

そんなわけで、社内サークルのサイトなんかは勝手に作ってもらっていいが、部門用のサイトとか、会社肝いりのプロジェクトのサイトなんかは、プロが考えた、ユーザーが扱いやすいデザインで、コミュニケーション論とかも考慮され、コンテンツ更新運用も考えられたテンプレートを使いたい気持ちになるなぁ…と思いました。

また、全てをSharePointでやる必要はなく、TeamsやYammerなど適切なツールで実施すべきはそうだが、それこそエンドユーザーにとっては難しいのでは?ひとまずTeamsで始めるとして、どういうタイミングでSharePointを使い始めるかが分からない。そのためには、SharePointで何ができるかユーザーが理解しておくべきであるし、そうじゃなければ管理者が”こういう方法でSharePointを使いましょう”とレクチャーする必要がある。

ということで、ユーザーでいろいろできるからプロは必要ないよね、ってのじゃなく、自由にいじれる上での悩みを解決するためにプロが何ができるかを考えなきゃな、と思いました。

とにかく普段Exchangeのぬるま湯でメールボックスをぽちぽち作っていただけの私にとっては非常に考えされられたセッションでした。

あと読もうと思ってたノンデザイナーズ・デザインブックをちゃんと読もうと思いました。

LT01がデザインの話だったので、そちらも聞きたかったが…。

自分用メモ:モダンサイトの種類

  • スタートページ
  • チームサイト
    • Teamsの裏で出来るサイト
  • コミュニケーションサイト
    • SPOのサイト。より組織内に広くニュースなどの情報を発信する。
  • ハブサイト
    • 関連するサイトの”ハブ”となるサイト
    • 例えば、総務部のサイトと電話管理のサイト、備品管理のサイトがある場合、総務部のサイトを”ハブサイト”と定義する
    • Teamsもこういう概念がほしい…。
  • ホームサイト
    • 今年の終わりくらいに出てくる
    • テナント内に1つだけ設定できる
    • ユーザーが数分で作成でき、組織のポータルとなるサイト

DE01 AAD B2Cでゆるっと真面目に認証しょう

Office 365 でAzure AD B2Cの話題を聞くのでこのセッション。感想としては、競合の製品に比べて価格は安そうだが、使い勝手や他の競合mBaaSの連携(Firebaseなど)に比べると貧弱で、ちょっと流行らないんじゃないかなぁ…と思いました。多分、AAD B2C単体で使いたい、というより、mBaaSの一環としてこのサービスがある、というのが世間の視点なので、う~ん、どうなんでしょ。

個人的には、セッションを聞きながらB2C向けのIDaaSの競合製品をいろいろ調べて「ほほーん」とできたので良かったです。

DE02 Azure Functionを利用している場合の運用監視 Azure Functtion Operation monitoring

個人的にFunctionsを使って動作不能になったりすることが多かったのでこのセッション。なお私のFunctionsは要所要所(笑)でSendGrid使ってメールを投げる、という原始時代な監視の仕組みです。

結論としては、Azure Monitor(Application Insights)を使えば便利だよ、と。Application InsightsはAzure Function作成時にデフォルトで有効で、使い始めるのにハードルはない。世の中的にはNew Relicなどもあるが、Application Insightsを使ってみて不満があれば検討すれば、という所。

なお使い始めるハードルは低いが、調子に乗ると無料枠を超えることがあるぽいです。

Application Insightsのデータ転送量に気を付けよう – Qiita

実際、個人開発だと成功した時はどこかのログファイルに吐いて、失敗した時だけメールを飛ばす処理をAzure Function上のアプリに組み込めば十分なのですが、エンタープライズだとアプリケーション自体の動作と監視の要件が一緒になると、監視の要件が変わった時にアプリの再デプロイが必要になり、アプリ管理という面ではイケてない。

そこで

Azure Function -> Application Insights -> LogicApps

とあえて役割を分けさせることで、開発と運用を分けることが出来ていいよね、という話でした。

ただ、セッションでライブコーディングされている時、空気のように標準出力と例外出力を使い分けられていたのですが、運用バッチしか書いてないインフラエンジニア的には「例外出力?テキストログに記録できればいいんじゃない?」みたいになるので、そこはアプリ開発の基礎の勉強が必要だな、って思いました。単に例外出力するのはもちろん、致命的なエラーと、後で調べればいいエラーは戻り値(?)を分けて出すとか。

※ どーでもいいけど、開発者ってどのタイミングでこういったコーディング以外の要素を勉強するんですかね?今、ジョブ管理システムのシステム要件定義をやってんすけど、戻り値が正常・警告・異常の3段階でいいのか、もっと細かくカテゴライズすべきなのか、論拠がないんですよね…。

そうそう、セッションの半分くらいがライブデモだったんですけど、非常に良かったです。上手く動かない所があったけど、それも含めて安心というか、あ~やっぱりクラウドって上手く動かないことがあるとブラウザ再起動したら直ってるよね~、みたいな分かりみが深くて良かったです。

まとめ

以上、途中で帰ってしまったのですが大変楽しい文化祭みたいな雰囲気のイベントでした。うるしまさんとサポートメンバーの方、登壇者の方々、大変ありがとうございました。

個人的によく使うMicrosoft Teamsショートカット集

/saved

保存済みのメッセージに移動。マウスでやるとアイコンクリック→保存済みをクリックするしなければならず、誤クリックも多いのでショートカットキーを重宝

Ctrl+1,Ctrl+2,Ctrl+3

それぞれ、最新情報・チャット・チームに移動。マウス動かすのが面倒な時に利用するが、チームなんかはその後必ずマウス選択が必要になるので、あまり使わない。Ctrl+1はよく使う。

Ctrl + E

上部の検索窓に移動。誰かとチャット始める時はここから人の名前を入力すると捗る。

Ctrl + Shift + X

新しい会話を作成ボックスモードで開始。基本的に、拡張ボックスモードでしかTeams会話しないので個人的には必須。あと、マウス操作でやると通常入力モード ⇔ 作成ボックスモードがトグルで切り替わるが、Ctrl + Shift + Xを押すと必ず作成ボックスモードになるのでユーザビリティ的にもよい。

Ctrl + Shift + V

隠しショートカット。クリップボードにコピーした文字列を書式情報なしで張り付けることが出来る。WordやExcel、Webの情報をペーストする時におかしいフォントになってしまうのを防げて便利。

おまけ:試したけど使えないショートカット集

/goto(Ctrl + G)

チームまたはチャネルに一発で移動できるが、候補のチームが表示/非表示構わず出てくるのでマウスの方が早いし、移動した後結局マウスで会話を選ぶので無意味。

R

スレッドに返信。うまく使いこなせば便利かも?と思ったが、そもそもスレッドにフォーカスを当てないとRが効かないし、それならフォーカスを当てるタイミングで返信開始すればよいので非効率。

会議と通話系のショートカット

いろいろと揃っているが、そもそもTeams会議の開催自体が1日に1回くらいなので、マウスで十分。唯一、Ctrl + Shift + M(ミュート実行/ミュート解除)は、ミュートで会議に参加していて突然話しかけられた時に、素早くミュート解除するのに使うくらいか。

以上。同僚にはチームの並びを変更するとCtrl + Shift + ↓(or↑)も評判が良いが、個人的にはそこまで使用頻度ない。全てのショートカットは/keysまたは以下のページで見れます。

Microsoft Teams で使用するショートカット キー – Office サポート

#decode19 の #PR06 から考える、今みんながMicrosoftTeamsについて知りたい事

表題の通りdecode19のPR06というセッションに参加したのですが、個人的にはあまり得るものがなくtwitterを見ても同じように感じた人が多かったようです。

PR06 最前線での Microsoft Teams の実践的活用を学ぶ ~ 医療現場から

じゃあどういうセッションだったら満足だったのか?俺は(みんなは)Teamsについて何が知りたかったのか?と少し考えてみました。

セッションへの期待とギャップ

セッション内容は2つの医療団体がMicrosoftTeamsを採用し、医療の働き方改革を進めました、というアウトライン。これに対して私が抱いた期待を振り返ってみると…

  • 医療現場でどういう風にTeamsが利用されているかを知りたい
    • 例えば、手術現場の写真を撮影し、Teamsで撮影しているのか?
      • 医療現場という、自分がよく知らない業界への興味
    • 24時間の業務もありそうだし、顔を合わせてコミュニケーションを取れない中での情報の残し方などのノウハウ
      • 導入の成功事例とされる法人は、上手くTeamsを使いこなしているに違いないからノウハウを持って帰りたい
    • wikiとかOneNote、何をどう使っているの?
      • 単純に、使っているツールに興味あり。ツールの使い方のTipsも
  • MicrosoftTeamsを導入したことによる、目に見える効果
    • 例えばカンファレンスの頻度が1日2回から4回出来るようになって、1回当たりの時間が短くなった
    • 勤務時間が○時間短くなった

ただ実際は…

  • 医療現場へのMicrosoft Teamsの浸透のさせ方
    • お医者さんは新しい物好きだからすぐに広まった!
      • 何の参考にもならない
    • アンバサダー制度を導入し、部署で2名を選抜してTeamsを好きになってもらった
      • 個人的にこのやり方は知っていた
  • Microsoft Teams導入の効果(割と浅め
    • 今までは電話とメールしかなかったのが、チャットでメッセージを残せた
      • それってビジネスチャット導入したら普通に発揮される効果だよね…。

ここらへん、セッションのモデレーターであるマイクロソフト社の社員さんが、Teams利用率を高めることがミッションのカスタマーサクセス担当者だったので、「Teamsの利用率がUPした後の”利用のされ方”は注視しない」というスタンスだったの…かもしれません。

みんながMicrosoftTeamsについて知りたい事

俺達はMicrosoftTeamsをまだ使いこなせてないという気持ちが強いのではないか、と思いました。ビジネスチャットの中でも特に多機能なTeams。タブを追加したりコネクタを追加したり、自由に拡張できる。それなのに、自分のチームは”一般”チャネルで会話しているのみ。Plannerを入れてみたけど、浸透せずに終わってしまった。どうか、俺にうまいTeamsの使い方を教えてくれ!

みたいな。

私の考え

Teamsの利用について誰かに答えを求めるのは間違いかな、と思えてきました。PR06に何を期待していたのか、自分自身でも反省し振り返ると、たとえ医療現場での利用方法を知ることが出来たとして、それをSIerの業務にそのまま適用できるのか?は否であるし、結局、答えは自分(組織)の中にしかないのかな、と思いました。

そういった意味では、後続のPR92は、

  • アジャイル開発
  • カンバン方式のタスク管理

と業務定義を行った上で、実際のロールプレイを交えて話していただいたので、自社の業務がぴったり合致しているなら腹落ち感が大きかったのではないでしょうか?

PR92 Agile Project での Microsoft Teams 活用例

ああいうのをみんなが求めていたのかな、と感じました。

MicrosoftTeamsをうまく利用する方法

1. 自社の”集団行為”を分析する

例えば自社がエンタープライズ向けのウォーターフォール側プロジェクトが主な場合、ウォーターフォール型のプロジェクトの業務を分析する。

2. 該当の業務で、Teams以前はどうしていたかを分析する

例えばファイルサーバーで資料を管理していたら、その階層構造などを分析する

3. Teamsの構成を決め、誰かが旗を振る

1と2を参考にTeamsの構成を決める。例えばプロジェクトフェーズ毎にチームを作る、というやり方もありだし、顧客毎・案件毎でもよい。メモはwikiではなくOneNoteを使うルールとし、既定で存在するwikiは削除する。課題管理は顧客と共有するからExcelで実施する、など

PowerPlatform界隈なども「自社の業務を分かっている人がアプリを作るべき」という論調が強いですし、MicrosoftTeams界隈も「自社の業務を分かっている人が自社のTeamsの構成を決めるべき」なのかなぁと感じました。

MicrosoftTeamsの既読通知機能を有効にすべきかどうか問題(通知機能の選択)

今までのエントリ

現状のまとめ

対象 既読通知機能 既読表示タイプ
チームチャット ○有効(有効/無効/ユーザー選択可能から選択可) 不明
プライベートチャット ○有効(変更不可) 不明
  • チームチャット、プライベートチャットとも既読機能が有効になる
  • 既読表示タイプは以下の2タイプがあるが、どちらが実装されるかは不明
    • タイプ1. 読んだ人数が分かるが、ユーザーは分からない
    • タイプ2. 人数も、ユーザーも分かる

機能利用の選択

プライベートチャットは強制的に既読が有効になるため、チームチャットの既読動作について選択できる。選択肢は以下の5択。

既読通知機能 既読表示タイプ
有効 タイプ1. 人数しか分からない
有効 タイプ2. 人数も、ユーザーも分かる
ユーザー選択可能 タイプ1. 人数しか分からない
ユーザー選択可能 タイプ2. 人数も、ユーザーも分かる
無効 なし

ここでまずユーザー選択可能は選んではいけない事を主張したいです。前のエントリで

  • 既読機能に対して、違った解釈が発生するのはリスク
  • 既読機能の使い方はルールを決めてつかうべき

と書いた通り、チームによって既読がつく/つかないが変わる場合、組織全体として統一された動作にならず、ルールも文化も統一されないからです。

つまり事実上の選択肢は以下3つ。タイプ1かタイプ2かはマイクロソフト社の実装によるので、こちらに選べるのは有効か無効かだけですね。

既読通知機能 既読表示タイプ
有効 タイプ1. 人数しか分からない
有効 タイプ2. 人数も、ユーザーも分かる
無効 なし

プライベートチャットと組み合わせるとこんな感じかな?

パターン プライベートチャットの既読通知機能 チームチャット既読通知機能
1-1 ○有効 ○有効(タイプ1. 人数しか分からない)
1-2 ○有効 ○有効(タイプ2. 人数も、ユーザーも分かる)
2 ○有効 ×無効

それぞれについて評価してみます。

パターン1-1. プライベートチャット(○有効) / チームチャット(タイプ1. 人数しか分からない))

この場合ですが、実質パターン2みたいなものじゃない?と思います。なぜなら10人程度のチームで5人が既読をつけても、誰が既読したかが分からないので何も判断できない。そして、一般的にチャットと違ってチームは多数のユーザーが所属するものであり、全体のユーザーと比較してアクティブなユーザーは少ない。

ひとまずプロジェクトに関わりそうな人をチームに追加したが、今アクティブなのはシステム構築メンバーのみ、のようなパターンだと、40人中7人が既読、33人が未読、みたいな状態がありうる。

なので、チームチャットがLINE型で実装された場合は、チームチャットをオンにするメリットはないため、オフにするのがよいと思います。

(もちろん、組織内のユーザーが少なく、チームのユーザー数 = アクティブユーザー数な会社はそうではありませんが)

パターン1-2. プライベートチャット(○有効) / チームチャット(○有効(タイプ2. 人数も、ユーザーも分かる))

一番シンプルな形。ユーザーの混乱は少ないですが、チャットもチャネルも既読が有効になって息苦しいかもしれません。Teamsの動作は統一されますが「Teamsは既読機能が有効になってて嫌だ!」という理由でメールが使われ続けるリスクもあり…。

パターン2. プライベートチャット(○有効) / チームチャット(×無効)

プライベートチャットは既読が有効だが、チームチャットは無効な構成。パターン1-2ほどシンプルではないですが、混乱する設計ではないと考えます。チームチャットの既読機能が無効なため、平穏に過ごせます。外部ユーザーをチームに招待しているパターンなどは、この構成がいいかもしれないですね。

欠点は、プライベートチャットがチームチャットの上位機能になってしまうため「チームチャット使わずに、プライベートチャット使おうぜ!」勢が生まれそうなこと。これを欠点とするかは会社によりますが、仕事に関するコンテンツが個人ではなくチームに保管されるべき、という観点で、原則チームチャットでコミュニケーションするべきだと僕は考えています。

よってこの構成では

  • 仕事のコミュニケーションは原則チームチャット
  • プライベートチャットの使いどころは在籍確認や電話で不在だった時の伝言メモ程度
  • あるいは、仲のいい個人での業務外の会話程度

という文化の形成が大事かな、と思います。

ユースケース

最後に、ありそうなユースケースと利用例を考えました。

ケース1. 相手が自分のメッセージを読んだか、確実に確認したい

この場合はパターン1系の通り、チームチャットで既読機能を有効にするのがよいと思われます。しかしながらチームチャットの既読タイプが「タイプ1. 人数しか分からない」場合、誰が読んだか分からないのでこの目的は達成できないです。そもそも、このようなケースでは個人チャットでメッセージを送れば既読が有効なので、チームチャットの既読機能を有効にするまでもないかもしれません。

ケース2. 業務時間外にTeamsを読んでいる事を知られたくない

例えば、BYODの私用スマホにTeamsが入っていて、ついつい通知が気になって見てしまった、けど返信は会社でしたい場合。これは既読通知をオフにするのがいいですね。

ケース3. 社外にいるメンバーがちゃんと仕事をしているか確認したい

これをTeamsの既読機能で管理するのはナンセンスでしょう。既読をつけるだけならスマホからでも出来るし、逆に真剣に仕事する時はTeamsを見ずに集中するので、全く当てにならないと思います。

ケース4. メールよりも気軽なコミュニケーションツールとしてTeamsを使いたい

“気軽”の定義にもよりますが、既読機能が”気軽さ”の足かせになるなら無効にするべきでしょう。例えばメールに慣れた年配の方にTeamsを使ってもらう時に「既読通知があるから、返信するための時間を確保してからじゃないとメッセージを読まない」と敬遠されるのはもったいない事です。

ケース5. 既読だけついて返信がなければ”了解した”という文化を形成したい

なんか一見良さそうですが、メッセージの送り手が気を付けないと誤解が生まれそうです。例えば

6月10日は午前中外出します

のような単純な内容ならいいですが、

来週のミーティングの資料を××に保管したので、みなさん必要に応じて追記してください

のようなアクション内容があいまいなメッセージや

昨日購入した××社の製品ですが、かなり高性能で市場に受け入れられそうです。つきましては、どこか時間のある場所で説明させていただいたのち、××社にフィードバックを行いつつ、拡販を進めていこうと検討しております。

のような多様な内容が含まれるメッセージに対して、既読だけで理解の有無をジャッジするのは無理です。この場合、メッセージの送り手が、読み手に期待するアクションを指定する、例えば「問題ない場合は”いいね”をお願いします」や「賛同いただける場合はコメントで候補日時をください」などとする必要があります。

やはりコミュニケーション能力が高い、あるいはチャットコミュニケーションに慣れているメンバーが多くないと、既読機能を使いこなすのは難しいのでは?と思いました。

MicrosoftTeamsの既読通知機能を有効にすべきかどうか問題

現状のまとめ

対象 既読通知機能 既読表示タイプ
チームチャット ○有効(有効/無効/ユーザー選択可能から選択可) 不明
プライベートチャット ○有効(変更不可) 不明

※ 2019/5/23現在、既読機能は未実装ですが、予告されたロードマップから仕様を推測しています。

  • チームチャット、プライベートチャットとも既読機能が有効になる
  • 既読表示タイプは以下の2タイプがあるが、どちらが実装されるかは不明
    • タイプ1. 読んだ人数が分かるが、ユーザーは分からない
    • タイプ2. 人数も、ユーザーも分かる

詳しくは前エントリを参照

Teams以外のビジネスチャット開発会社のスタンス

考察にあたって、先行する各ビジネスチャットの既読機能の有無と主張を確認しました。ざっくりまとめると既読機能を肯定する内容は少なかったです。理由としてはいかが考えられます。

  • 既読機能がついていないビジネスチャットの方が多い事
    • 自社の製品を正当化するため、既読機能を否定
  • 一般論的に若年層に比べて年配層の方が既読機能に抵抗があるため
    • おそらく社外に公開する文章を書くのは年配層に近い人物であるため

既読機能は不要だよ派

チャットの「既読」が生む仕事のミス! | ビジネスチャット「知話輪」

「知話輪」に既読機能がないのは、「自分のメッセージを相手が読んだことがわかるので、安心する」というメリットに疑問があるからです。ビジネスコミュニケーションにおいて、「既読がついた」という事実だけで安心できるでしょうか。本当に重要なのは「伝わったかどうか」です。 私たちは、既読がつけばメッセージを読んでくれたと思いがちです。しかし、既読がつくことでわかるのは、「そのタイムラインを開いた」ということだけなのです。開いただけで、読んでいない場合でも既読がついてしまいます。 (中略)既読機能で得られるのは「自分は伝えた」という安心感のみです。しかし、本当に大切なのは「伝わる」ことです。

既読機能はありますか? – サポート | Chatwork

すぐに返事をすることがメインのコミュニケーションツールと違い、Chatworkは自分のタイミングでメッセージを確認できるツールです。

ビジネスチャットに既読は必要?今求められている機能とは

立場によってもプレッシャーの感じ方は様々で、上司と部下、取引先への返信など、既読をしているにもかかわらず返答が無いと相手に対して何らかの不快感を与えてしまう可能性が出てきますし、そういった不安を残したまま業務を行わなければいけません。

既読機能は必要だよ派

疲れないためのビジネスチャット運用のコツ – LINE WORKS

LINE WORKSは仕事用なので、業務連絡が誰に伝わったか、誰に伝わっていないかが分かるというのは、実は業務効率にすごく影響します。なぜかって、「了解です」という返事が来なくても、既読がついていれば「あ、この人は読んでくれた」とわかるから、送った方は「読みましたか?」って確認しなくて済むからです。

この機能を活用して、既読がついていれば、「了解です」の返事をしなくて良い、というルールで運用している企業、聞いてるとけっこう多いんです。

既読がつけば返事をしなくても良い、のメリットは2つあります。

一つは単純に返事をする手間が省けること。多忙な業務の合間に返信する手間がこれで省けます。

二つめは、これが実はけっこう重要なんですが、大人数のグループチャットで「了解です」の返信やスタンプを返すと、返事だけがひたすら連続するトークルームになってしまうんです。

その他

高校生のLINEでのやりとりに対する認知に現代青年の友人関係特徴が及ぼす影響

日本パーソナリティ心理学会の論文。高校生400名にアンケートを取ったところ、既読機能の存在により行動に制約を受け、ストレスとなることが有意に認められる。

LINEの「既読」機能はなぜ無くならないか | Books&Apps

かなり痛烈に既読機能を批判していますが、ロジカルだったため紹介。

本来、メッセージの処理は「受け手」に任されてきた。無視しようが、返事を返そうが、いつ反応しようがそれは、「メッセージを送る相手」に任されてきた。「返事を返さない、という返事」も選択肢として存在していた。

その権利を、LINEは取り上げたのだ。

「LINEはメッセージ送信者のワガママを叶えます!」

そういうことだ。

しかし、本来メッセージは「受け手」を中心に考えなければならないものである。コミュニケーションとはそういうものだ。

それを壊し、「メッセージの送り手」のワガママを助長する。LINEはますますコミュニケーションの下手な人を増やすことを助長していると私は思う。

ひとまずの結論

組織所属メンバーのコミュニケーション能力に自信がない場合、既読機能はONにしない方が良い

正直、今回いろんな記事を探すまではうまく既読機能を使えばコミュニケーションがよりスピーディーに、円滑に進むのではないかと思った。しかしながらそういったメリットよりも、既読機能のデメリットの方が大きく作用しそうに思えます。

リスク1:既読機能に対して、違った解釈が発生する

同じシステムでも、部署や事業所によって使い方が違う事はよくあります。文化の違うチームメンバーが混ざった場合「うちのチームでは”既読”がついたら”了解”のニュアンスだった。」「いや、うちのチームは”既読”は関係なく、明示的にレスポンスを返すルールだった。」など、混乱が発生する可能性があります。

リスク2:コミュニケーション下手なメンバーの存在

例えば、相手の事を考えずに話に割り込んでくる、いつでもすぐに電話をかけてくる、相手が納得したかを確認せず言いっぱなしでその場を去る、などコミュニケーション能力に問題がある人は既読機能をメッセージの送り側が都合の良いように解釈する可能性が高いと考えます。となると、既読機能反対派が懸念する問題が発生する可能性が高いと思われます。

以上の2つの理由より、ユーザー属性がばらばらである、あるいは組織規模が大きければ大きいほど(確率的にコミュニケーション下手なメンバーが存在する確率が高くなり)既読機能を使うのは難しい、と言えるのではないでしょうか。半面、スタートアップなど数人の会社なら、既読機能の解釈もブレにくいでしょう。

図にするとこんな感じでしょうか。

しかし既読機能をオフにしようとしても、個人チャットは強制的にオンになっちゃうぽいですし、困りますね…。

既読機能をうまく使える条件

条件1. 既読機能に対する解釈を組織内で統一できる事

例えば以下のようなルールを制定して、管理者が宣言する

  • 既読機能は相手に何らアクションを強制するものではない
    • 何かアクションを指定する場合は、メッセージ内にその旨を記載し、望むアクションを指定する事
  • 既読をつける行為は、相手に何かを自分の意思を伝えるものではない
    • 何らかの意思表示をする場合は、いいねやコメントをつける事

宣言するだけではなく徹底させなければいけないため、組織規模が大きいと大変そうです。

条件2. 既読機能を都合の良いように解釈するメンバーがいないこと

管理者が宣言したルールを破る人がいた場合、ルールを破られた周りのメンバーの不快感が非常に大きくなるため、既読機能の利用は停止したほうがいいでしょう。

ということで、次のエントリでは既読機能を使う前提として、Teamsでの既読機能の構成を考えていきます。

MicrosoftTeamsの既読通知機能を有効にすべきかどうか問題(用語の整理)

そもそも既読”通知”機能とは

メッセージを表示(=開封する/読む)すると、会話相手に分かるよう、通知が行われる機能です。代表的なものはLINE。そしてこの機能には2種類の表示タイプがあります。

タイプ1. 既読にした”人数”だけが分かるもの

例えばLINE。10人のLINEグループがあるとして、既読が5人になってもだれが既読になったか分かりません。


※ 画面ショットは8人のグループで7人が既読なので、みんな読んでいる事が分かります。

タイプ2. 既読にした”ユーザー名”まで分かるもの

ビジネスチャットによっては、既読した人がリストアップされるものもあります。例えばLINEWORK。

トークの既読確認 – LINE WORKS

上記ページから写真を引用させていただきます。

Teamsでは”いいね”がこのタイプですね。赤枠のように”いいね”した人が分かる。

MicrosoftTeamsの既読通知機能

MicrosoftTeams(以下Teams)の既読関連機能を整理します。なお、機能の中には未リリースのものもあるため、後で変わる可能性があります。

機能1. Teams管理画面から設定できる「開封確認」機能

この管理機能は現在動作しておらず、何を管理するものなのかは2019/5/23現在分かっていません。とはいえ、機能2を考えると、これはチームチャットの開封確認を管理するものと予想されます。

機能2. ロードマップでリリース予告されている「プライベートチャットの開封確認機能」

https://www.microsoft.com/ja-jp/microsoft-365/roadmap?filters=&searchterms=51552

全文を転載し、日本語訳も掲載します。

(原文)
Microsoft Team – Read Receipts in private chats

Increase communication transparency with Teams. Do you often wonder if your teammates saw your message? Read receipts in private chats allow senders to know when a message was read by the recipients.

(日本語訳)
Microsoftチーム – プライベートチャットで領収書を読む

チームとのコミュニケーションの透明性を高めます。あなたのチームメイトがあなたのメッセージを見たかどうか不思議に思いますか?プライベートチャットの開封確認メッセージを受信者が読んだときに送信者は知ることができます。

この機能は2019年6月にリリース予定で、現在開発中となります。(2019/5/23時点の情報)

まとめ

機能名 対象 既読通知機能 既読表示タイプ
機能1 チームチャット ○有効(有効/無効/ユーザー選択可能から選択可) 不明
機能2 プライベートチャット ○有効(変更不可) 不明

ここまでの推測より、チームチャットもプライベートチャットも、既読機能が有効になると思われます。そしてどちらの機能も、既読表示タイプは分かっていません。

既読”管理”機能との違い

Teamsでは、自分自身の管理のために、チャット・チャネルメッセージの未読・既読を切り替えることが出来る。一度読んだメッセージを”未読”に戻すと、画面のように未読状態となる。自分専用の”しおり”的な機能だと理解すると分かりやすいです。

本ブログの一覧の議論ではこの機能は扱いません。

IPアドレスが分かっている自社メールシステムからのメールをEOPでスパム判定されたくない

概要

以下のような構成の際に、自社メールシステムからのメールを確実にExchange Onlineで受信したい

構成1:自社メールシステム(IP特定可能)から、自社Office365へのメール送信

構成2:自社メールシステム(IP特定可能)から、自社Office365や他社へのメール送信

EOPの仕組み

ポイント

大別すると、EOPは以下の2つの観点でスパム判定を行っている。

観点1. メールの送信元

まず

  • 接続フィルター
  • Microsoftブロックリスト
  • Spamhaus

で、不正なIPからのメール送信ではないことを確認する。また、不正なIPからでなくても、短時間に大量のメールを送信するようなメール送信元はここでブロックされることもある。

観点2. メールの中身

送信元チェックを潜り抜けたメールは

  • マルウェアフィルター
  • スパムフィルター
  • フィッシングフィルター

の3つでコンテンツのチェックが入る。フィッシングフィルターについては昨年登場した新機能でブログに書いた↓

ATP AntiSpoofingについて

スパム判定されたくない方法

観点1. メールの送信元

接続フィルターに送信元メールシステムのIPアドレスを記載することで、

  • Microsoftブロックリスト
  • Spamhaus

を回避できる。

観点2. メールの中身

ルール(トランスポートルール)に送信元メールシステムのIPアドレスを記載することで、

  • スパムフィルター
  • フィッシングフィルター

を回避できる。ただし

  • マルウェアフィルター

は回避できない。

まとめ

以下のようなメール経路が、最もスパム判定されない経路である。

実装方法についての議論

接続フィルターの代わりに受信コネクタを作成する

Exchangeエンジニアの中には、受信コネクタを作成する事で、Microsoftブロックリストを回避できると案内を受けた人もいると思う。私もその1人であるが、受信コネクタはそもそもMicrosoftブロックリスト回避のための機能ではないし、どちらにせよSpamhausは通ってしまうので、確実にスパム判定を回避できるとは言えない。また、Exchange Onlineエンジニアの間で言われる引き込みの法則という副作用により、冒頭の2の構成で、他テナントへのメールも自テナントに引き込んでしまう動作となる(2,3年前の話。仕様が変わってなければ今も)

受信コネクタがさまざまな条件でメール送信元を指定できるのに対して、接続フィルターはIPアドレスしか指定できない弱点があるが、確実な回避・引き込みの法則を避けるという点で、IPアドレスが判明しているなら、受信コネクタより接続フィルターを利用するのが良いと考える。

接続フィルター 受信コネクタ
対象 CIDR(IPアドレス) ドメイン、トランスポートルール
効果 Microsoftブロックリスト、Spamhausの回避 対象のメールが受信コネクタを使うため、Microsoftブロックリストに追加されにくい?
副作用 なし 引き込みの法則により、広範囲のメールを自テナントに引き込んでしまう

トランスポートルールの代わりに、SPFレコードを登録する

社内メールシステムといえどインターネットを通って(自社の)Exchange Onlineに着信するので、SPFレコードを記載し、スパム信頼レベルを下げる(=信頼できるメールである可能性を高め、スパム判定されにくくする)施策は有効である。しかしながら、SPFレコードはメールの信頼度を高める手段の1つであり、SFPレコードを登録してもその他の要因によってスパム判定されてしまう可能性はないとはいえない。確実にスパム判定を回避するなら、トランスポートルールの方が有用である。

トランスポートルール SPFレコード
対象 さまざまなルール IPアドレス
効果 スパムフィルター、フィッシングフィルターの回避 メールの信頼度の向上
スパム回避効果 確実 ほぼ確実

果たしてOutlookだけで100時間の時短を達成できるのか?

それを確認するには、自分がOutlookを使っている時間数を調べる必要がある。上記の本によれば一般的なホワイトカラーのOutlook利用時間は500時間/年であり、この場合に100時間/年の時短が出来る、とある。

関連エントリ:「年間100時間の時短を実現した32のテクニック アウトルック最速仕事術」を読み込んで改善点を考える

Outlookを起動している時間を調べる

RescureTimeというソフトをインストールする事で、PCで使用しているソフトの利用時間を計ることができる。以下、2019年3月の私のデータ。

Outlookの使用時間は16時間12分。年間使用時間にすると194時間24分。これを100時間にするのは難しそうだが、50時間減くらいなら期待できそう。

ちなみにOutlookより上位のソフトウェアは

  • Microsoft Teams:25時間45分(年換算:309時間)
  • Excel:25時間1分(年換算:300時間12分)
  • PowerPoint:24時間58分(年換算:296時間24分)

なので、Outlookよりも上記ソフトの時短の方が効果があるのだが、以下の理由で時短が難しそう。

  • PowerPoint
    • 手を動かすというより、資料を見たりアイディアを練ったりする時間が大半なので時短効果はなさそう、
  • Excel
    • 既にいろいろExcel本を読み漁ってこの時間なので、単純に触れてる時間が長いだけ、
  • Microsoft Teams
    • アプリ自体がもっさりしており、満足なショートカットキーも用意されておらず時短しようがないので諦めます。マイクロソフト様、時短ハックできるTeamsクライアントをお待ちしています。

それにしても、Teamsがない時代はほぼすべてのコミュニケーションをOutlookでやっていたので、Outlook利用時間(194時間24分) + Microsoft Teams利用時間(309時間) = 年間約500時間もOutlookを利用していたことになる。これならマジで100時間くらいは時短できるかも。

メールの利用時間を調べる

Office 365 を利用しているなら、MyAnalyticsという機能で自分が読んだメールの数・送信したメールの数をカウントする事が出来る。以下は3月第1週目の私のデータ。

2019年3月第1週~第4週の集計は

  • 送信メール:129通
  • 既読メール:1299通
  • メール利用時間:21.4時間

であった。なお時間は単純計算で、送信メールは1通につき5分、既読メールは1通につき2.5分、ただし、連続して既読操作、例えば10通一気に既読にしても2.5分加算となる。詳しい計算方法は以下参照。

MyAnalytics ダッシュボード – Workplace Analytics Office 365 | Microsoft Docs

RescureTimeの16時間42分に比べると少し多いが、メール1通を2.5分かけて読むことはないので、少しMyAnayticsの計算が過剰なように思える。

まとめ

次エントリ年間100時間の時短を実現した32のテクニック アウトルック最速仕事術の紹介をするが、そもそも自分がOutlookを利用していないと意味がないので、事前に調査しておくのが良い。僕に本当に必要なのはMicrosoft Teams時短ハックです。

余談:RescureTimeについて

上でも書いた通り、起動しているソフトウェア毎に起動時間を取得し、レポートしてくれるソフトウェアである。ブラウザでのアクセスの場合、アクセス先のサイト情報も取得してくれる。

元々、ダラダラとyoutubeを見てしまう自分を戒めようと思い導入したのだが、生産的なソフトウェア(Outlook・Excel)、非生産的なソフトウェア(Chromeでyoutubeを見る、LINE)を分けて集計してグラフィカルに表示してくれるので便利。月毎の比較もでき「前月に比べてX時間生産的な時間が増えた」というレポートも出してくれる。PCのフロントウィンドウになっているソフトウェアの情報を取得しているだけなので、Excelを起動したまま離籍したり、youtubeを流したまま寝落ちするとその時間も加算されるのだが、絶対時間ではなく週毎、月毎のデータで比較する事で肌間隔的に分かる(今週は先週に比べて頑張ったな)ので、ひとまずいいかな、と。

今後、ここで取得したデータを元に自分の行動を変えていけたら、と思っている。

「年間100時間の時短を実現した32のテクニック アウトルック最速仕事術」を読み込んだ

はじめに

年間100時間の時短を実現した32のテクニック アウトルック最速仕事術は時短ハックの対象としてOutlookにフォーカスした本であり、その着眼点と内容もすばらしく、年間のOutlook利用時間が多いが特に使い方を工夫していないユーザー、また工夫しているがより良い使い方があるかを確認したいユーザーは購入必須である。

私としては、自分なりにOutlookを工夫して使っており、Outlookを人に教える事もある立場であるため、あえて批判的な視点で本書のテクニックを確認していくが、本書の基本的なコンセプト「普段意識しないOutlookの使い方を見直し、時短につなげる」は大賛成であることは記載しておく。

これを機にOutlook時短ハックブームが起こり、みんながOutlookの効率的な考え方についてあーでもないこーでもないと議論できる世の中になれば私も本望である(それはなさそう)

本書のテクニック一覧と、私の評価

2章:画面の使い方編

Case1:予定表を固定する

著者の意見

メール一覧画面の右ペインに予定表を固定し、いちいち予定を確認するために予定表ビューに移動しなくてよいようにすべし

私の意見

ディスプレイが広い場合は賛成だが、狭い場合はメール一覧画面が小さくなって、「メッセージのプレビュー」機能による本文表示(≠閲覧ウィンドウ)領域が小さくなり、かえって情報量が少なくなる。タスクバーを立て置きにしている場合はなおさら。自分の予定の量の多さと相談して、何をランディングページ = メールの一覧画面に表示するかを検討すべし。

下に比較画像を配置した。

・メール一覧画面だけ
右側の領域に情報量が少なく非効率な気がする

・メール一覧画面 + 予定表ビュー
ちょうどいい情報量

・メール一覧画面 + 予定表ビュー + タスクバー
メール一覧画面の情報量が少ない気がする。

Case2:添付ファイルは最初につける

著者の意見

クリップボードにファイルを選択した状態でメールに張り付けると、ファイルが添付された状態の返信メールが立ち上がるので有効活用すべし

私の意見

私の添付ファイル付きメールの送信数を調べたら月に20通くらいだったので、仮にこのテクを利用してもあまり時短は望めないように思えた。また、メール処理のプロセスが

  1. 受信トレイのメールを見る
  2. 対応必要そうなものは返信メール画面を起動
  3. 本文を書いて添付ファイルをつける

なので、2の時点でこのテクニックは使えない。このテクニックを使うには、自分のメール処理のプロセスを変える必要がある。

Case3:予定表から新しいタスクを起動しない

著者の意見

クリップボードにテキストをクリップして予定表ビューの時間帯を選んでペーストすると、予定が作成される機能を使うべき

私の意見

反映されるのはクリップボードのテキストだけであり、添付ファイルはペースト出来ないのが欠点。本書では「イベントへの招待のメールを予定表に張り付ける場合」に便利とあるが、それに添付ファイルがあった場合、結局.msgファイル自体を予定表に張り付ける必要があるので、

  1. 受信トレイの招待メールをクリップボードにコピー(この時点で、.msgファイルとしてクリップ)
  2. Ctrl + Shift + Qで空の予定表アイテムを起動
  3. ペースト(.msgファイルがペーストされる)

が最速の手段となる。.msgファイルを新規アイテムに張り付ける”入れ子のメッセージ機能”はメッセージそのものを完全に保管できるので結構優秀。余談だが、Office 365 の場合、30入れ子までの動作をサポートしている。

Case4:メールの閲覧ウィンドウは使わない

著者の意見

メールの閲覧ウィンドウは画面占有率の割に情報量が少ないので閉じるべし

私の意見

賛成。余白が多く、無駄である。私は「メッセージのプレビュー」機能を利用し、2行ほど本文を表示しサマリが分かるようにしている。全文を読みたい場合は、著者の意見通り、別ウィンドウで開いている。

Case5:リボンは閉じる

著者の意見

ショートカットキーを使いこなせばリボンは不要だから閉じるべし

私の意見

メールの読み書きなら不要だが、予定表を利用するときはショートカットキーだけでは操作できない事が多いので閉じない方がよい。例えば予定を「非公開」にしたり、公開方法を「空き時間」にするのはショートカットキーが用意されておらず出来ない。

私からはリボンの代わりによく使うボタンをクイックアクセスツールバーに集約する事を提案したい。PC毎に設定が必要という欠点はあるが、これでリボンを表示させなくても済む。

例えばTeams会議開催ボタンをツールバーに追加したり。

3章:ショートカット(基本編)

この章のショートカットは知っていて当然レベルでマスターしたい。以下を本書への補足。

  • 返信(Ctrl + R)で紹介されている全員返信(Ctrl + Shift + R)はCtrl + Lでも可能。→Alt + Lでした。
    • ビジネスでは全員返信でメールを作成する事が多いので、返信 = Ctrl + L→Alt + Lで覚えた方がよい。
    • (2019年5月2日追記)著者から指摘あり、全て左手で操作できる統一感と、なるべくCtrl系でショートカットは統一したかったのでAlt + LよりもCtrl + Shift + Rにしたとの事です。
  • 閲覧ウィンドウを閉じる(Esc)はAlt + F4でも代用可能。
    • Alt + F4はWindows全般で有効なので、これで閉じてしまってもよい。
  • 次 or 前のメールへ移動(Ctrl + < or >)は、Ctrl + 4 or 5でもOK。
    • これはショートカットバーに前後のメールに移動するボタンが標準で表示されているから使える。
    • <と>はPCによっては位置が探し辛いので、4と5で覚えるのがよい。

4章:メール整理

著者の意見

仕訳ルールは使わず、アーカイブフォルダを上手に使え。仕訳したくなったら検索フォルダを使え。

私の意見

仕訳ルールを作ってフォルダ分類派 VS メール処理状態で整理派の仁義なき戦いである。まず大事なのは、どちらも試して、自分に合った方法でやってみる事である。また、環境が変わった場合、やり方を見直すのも重要である。

なお私はどちらも試して仕訳ルールを作ってフォルダ分類するやり方に落ち着いたが、この本を読んで数年ぶりに仕訳ルールを全削除し、メール処状態でフォルダ整理運用にした。なぜなら、数年前に試した時はビジネスチャットツールであるMicrosoft Teamsがなく、全てのコミュニケーションをメールでやり取りしていたが、今は大半がTeamsに移行し、メールの総数が減ったからである。新規OAツールが導入されたり転職したりして環境が変わった場合、今までのやり方が最適ではなくなる可能性があるため、環境が変わる前に自分のやり方を見直すことが重要である。

なお著者が推薦している検索フォルダはOWAやOutlook for iOSでは利用できないため、ブラウザやモバイルデバイスからメールを利用することが多い場合、検索フォルダに頼ることは出来ない。本書は全般的にデスクトップ版Outlookでメールの処理をする事に主眼が置かれているため、自分の使い方がどの程度合致しているかを見極めて読む必要がある。

5章:もっと時短したい人のためのスーパーテクニック

クイック操作 / クイックパーツ

著者の意見

自分好みにクイック操作やクイックパーツを利用すればもっと時短できる。

私の意見

この2つの機能は自分のOutlookの利用方法を分析して、使い方を検討する必要がある。例えば「クイックパーツで定型文を登録すれば時短になる」と著者は主張するが、私の場合、月のメール送信数は129通(前エントリ:果たしてOutlookだけで100時間の時短を達成できるのか?の調査結果参照)。この129通のうち、定型的な内容で返信しているメールが何通あり、クイックパーツによってメールを作成する事で短縮できる時間は何分か?

日本人の平均タイピング速度は100文字(ひらがな)/分らしいので、クイックパーツが100文字程度であれば、1通につき1分ほどの時短。クイックパーツで作成できるメールが10通あれば10分の時短、年間では120分の時短となる。しかしながら、そのためにテンプレートを作成し、クイックパーツを設定し、送信するタイミングでクイックパーツを思い出すコストはどうか?ついつい手打ちしてしまうこともありそう。

なお私の場合、129通のメールで定型的な内容で返信しているメールは2通だけだったので、絶対に普通に返信した方が早いです。自身の毎月のメール送信数を調査し、効果を算出してから、取り組むのがよい。

Oftファイルでのスケジュール確認機能

著者の意見

Oftファイルの宛先に同僚のメールアドレスを登録することで、スケジュールアシスタントから簡単に予定を確認できる

私の意見

予定表グループでも同じような事ができるのに、なぜOftファイルでスケジュール確認をするのかよくわからなかった。
もし、(予定表グループの)予定表ビューを使った予定表閲覧は時間がかかるから、あえてスケジュールアシスタントから確認したい、というのなら、同僚のメールアドレスを連絡先や連絡先グループに登録して、会議出席依頼から確認すればよいと思った。

なおOftファイル自体は有用な機能であり、例えばヘルプデスクで定型文をグループで共有する場合、グループでアクセス可能なディレクトリに返信テンプレートを配置し、それを元に返信する、という事が出来る。

(2019年5月2日追記)著者から指摘あり、Oftファイルは、部内のファイルサーバーなどで共有して利用する想定、とのことでした。確かにこの使い方なら、自分の予定表グループをメンテするより、グループ全体で利用できるからいいかも。一番いいのは、システム管理者が組織構造に合わせたグループを作成し、グローバルアドレス帳に公開することだと思うが。

メールの1分遅延ルール

著者の意見

クライアントルールで1分遅延ルールを設定すると無料で誤送信防止ができる

私の意見

これはマジお勧めで、著者の提案する例外ルールを設定するのも併せてお勧め。注意点としてOutlookで送受信タスクが走るタイミングで、送信トレイに1分以上保管されたメールが送信されるので、最速で1分、最遅で2分くらい、送信にかかること。あと、Outlookのクライアントルールになるので、OWAやOutlook for iOSの時には適用されないので注意。

6章:もっと時短したい人のためのショートカット

気になったところだけ。

Ctrl + Space = 標準書式に変換

これは知らなかったので活用している。Outlook以外から文章をコピーした場合にMeiryoで統一されたフォントにMS ゴシックがまざってイラっとしてしまう所がこれで直せるのは便利。

Ctrl + Shift + I で受信トレイに移動

これは知らなくて便利だと思いました。が、送信済みトレイに移動するショートカットもほしかった。

署名のショートカット

クイックアクセスツールバーに登録する事で、Alt + 1で署名のショートカットを呼び出せる、というテクニック。だが私はOutlook標準のショートカットである、Alt -> N -> AS で署名を呼び出してます。慣れれば1秒かからない。

仕事柄、複数のPCでOutlookを使うことがあるので、ソフトウェア固有の設定をいじるのが煩雑で管理しづらく、出来るだけ標準ショートカットで済ますようにしています。

Shift + 右クリック = パスをコピー

これは自社の共有ストレージが

  1. 全員が同じUNCパスでアクセスできるファイルサーバーか
  2. https://~でアクセスする、オンラインストレージか

で有用性が変わってくる。うちの会社はほぼファイルサーバーが廃止されSharePointが主要ストレージ。SharePointのファイルにアクセスするには

  1. ブラウザからファイルを選択する
  2. OneDriveで同期して、ローカルファイルとして開く

の2通りがあるのだが、2で同期したファイルのパスは自分のPC固有のパスとなり人に送っても開けない。

よって、https://で始まるパスを人に伝えなければならないが、この時に便利なのが「ドキュメントの場所」というクイックアクセスツールバー。

Alt + 数字で、ドキュメントを開いたままパスをクリップボードにコピーできる。

編集し終わったファイルのパスを誰かに伝える、という利用シーンを考えても、わざわざエクスプローラーに戻ってパスをコピーするよりも有能。「ソフトウェア固有の設定をいじるのは嫌」といいつつ、これだけは代替のショートカットがないので、設定している。

また余談だが、book1.xlsxのような一時的なドキュメントを他人にシェアしたい時、一度PCに保存してからメール添付ではなく、ワンボタンでメール添付できるような機能も設定している。

まとめ

本書の基本的なテクニックは抑えるとして、応用編は自分のOutlookの利用分析を行った上で適切なテクニックを覚るのがよいと思う。特にクイック操作、クイックパーツ、クイックアクセスツールバーは使う人と設定内容によっては福音になる(SIerとしても一度これを使った業務改善を提案した = カネが取れる)ので、Outlook利用頻度が多い人は研究してほしい。

一方、予定表の活用テクニックがあまり記載されていなかったのが弱点かと思われるが、Outlookでメールは使っているが予定表は使っていない会社は意外と多い事、メール利用に比べて予定表利用の方が個別最適化されて汎用化しづらい事から、書籍として出すのは難しかったのかな、と思う。

全てのテクニックが有用だとは思えないが、冒頭にも書いたが、みんながなんとなく使っていたOutlookに光を当てたという点で、本書は素晴らしいです。著者は「Excelのスキル本はあったがOutlookはなかったので書いた」と言っているが、ExcelはVLOOKUPを使わなければ出来ないことはあるが、本書のOutlookテクを使わないと出来ないことは、正直言ってない。しかしながら、Outlookは万人が使用し、VLOOKUPと違って全員に効果があるテクニックが本書には書かれてますので、Outlook主体の業務の人は是非チェックしてみてください。

なお私はMicrosoft Teamsの使い勝手が良くなることを心より期待しています。

onmicrosoft.comがバレると何が困る?

前回のエントリの続きです。

onmicrosoft.comをどうしても隠蔽したい – ぷりどうぐ

前回のエントリの結論:xxx.onmicrosoft.comを隠し通すのは難しい

onmicrosoft.comがバレると何が困る?

困る事もありますが、別にそうじゃなくても既にバレてるので困らないこともあります。

Office 365 を利用している事がバレる

xxx.onmicrosoft.comがバレる = Office 365を使っている事がバレるので、フィッシングメール送って偽のログイン画面に誘導できたりする。ただOffice 365利用しているかどうかは会社のメールアドレスを知っていればnslookupで一発で調べられるので、xxx.onmicrosoft.comを隠しててもバレます。

結論:どっちにしてもバレてるので無影響

AADログインIDのonmicrosoft.comドメイン部分がバレる

会社のログイン用ドメインはメールアドレスと同じ場合が多いので当然外部にバレてるとして(※)、新たにxxx.onmicrosoft.comのドメインがバレると、xxx.onmicrosoft.com を利用したユーザーIDを探してログイン施行することが出来ます。企業のもつアカウントの99%くらいは会社ドメインのログインIDなので問題なさそうなのですが、xxx.onmicrosoft.comを持つIDはシステム導入時やテスト時に作ったまま放置しているアカウントだったりして無防備なことが多いので、事実上、問題になる事があります。

※ まれに「悪意のある外部ユーザーからログイン施行されないため、ログインする会社ドメインをメールアドレスと別のものにしたい」という要望を受けますが、ゼロトラスト理論を考えるとそれこそ隠し通すことが難しく、ユーザー利便性だけが低下するのでやめた方がいいと思われます。

結論:アカウントが存在する場合は問題あり

onmicrosoft.comのセカンダリメールアドレスがバレる

Office 365 の仕様上、各ユーザーのセカンダリメールアドレスに[ユーザー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がバレることによる新たなデメリットと考えます。

ログインIDがonmicrosoft.comのアカウントってどんなの?

xxx.onmicrosoft.comを利用したユーザーIDを抹殺すればよいですが、そんなことはできるのでしょうか?どのようなアカウントがonmicrosoft.comを使うのでしょうか?

認証回避

結論から言うと、一般ユーザーアカウントに対して多要素認証などを仕掛けている場合に、多要素認証トラブル時のシステム復旧用に、多要素認証を回避するためのアカウントを用意するパターンでonmicrosoft.comドメインを使う場合があります。

フェデレーション認証環境の場合

O365の世界でフェデレーション認証は認証ドメイン単位で設定するので、例えば会社ドメインはフェデレーション認証、としてしまうと、緊急回避用アカウントは会社ドメイン以外で作成する必要があります(※) ここで、既定で用意されているxxx.onmicrosoft.comを認証用ドメインとすることがあります。

以下の記事でもそれが推奨されています。

緊急アクセス用管理者アカウントの管理 – Azure Active Directory | Microsoft Docs

※ 緊急回避用アカウントを会社ドメインで作成しつつ、フェデレーション先のIdPで多要素認証をかけないこともできるが、どちらにせよIdP自体が死んだときは影響あり

AzureAD認証環境の場合

AzureAD認証環境の場合、認証制御はEM+Sの機能で行います。EM+Sの制御単位はユーザー個別orセキュリティグループであり、認証ドメインがなんであるかは関係ありません。よって、緊急回避用アカウントを会社ドメインで作成しても問題ありません。

結論

  • フェデレーション認証環境の場合は、会社ドメイン以外のドメインで、緊急回避用アカウントを作成する必要がある
  • AzureAD認証環境の場合、会社ドメインで緊急回避用アカウントを作成すればよいので、onmicrosoft.comでログイン可能なアカウントを抹殺できる

一歩進んで考察

さて、フェデレーション認証環境ではonmicrosoft.comのアカウントが必ず必要なのでしょうか?会社ドメイン以外のドメインで、緊急回避用アカウントを作成する必要があるという条件を満たせばいいので、例えば @hogehogetest36512345678.com というドメインを取得し、Office 365 に紐づけ、emergencyadmin@hogehogetest36512345678.com みたいなアカウントを作成し、、この条件を満たせますよね。

よって、ADFS環境でonmicrosoft.comの緊急回避用アカウントを作成する必要はなく、会社ドメインとは別の、AzureAD認証を利用するドメインを用意すれば、ADFS環境でもonmicrosoft.comも抹殺できます。

しかし果たしてこれに本質的な意味はあるのでしょうか?

emergencyadmin@hogehogetest36512345678.comと、
emergencyadmin-hogehogetest36512345678@xxx.onmicrosoft.comは「複雑で推測されにくい」という点で、何が違うのでしょうか?

上司に「なんでhogehogetest36512345678.comってドメイン取るの?」って聞かれて、ロジカルに答えられるでしょうか?
hogehogetest36512345678.comのドメインを維持する労力や、ドメイン失効リスクの方が、onmicrosoft.comを利用されるリスクよりも高いんじゃないでしょうか?

相次ぐドメイン事件、目的のWebサイトが表示されない原因 | 日経 xTECH(クロステック)

と考えると、素直にxxx.onmicrosoft.comのドメインを利用し、緊急回避用アカウントのIDを複雑にすることで(もちろんパスワードも)十分に要件を満たせるのではないでしょうか?

AzureADの素のセキュリティ

EM+S使わないと脆弱だ!みたいな説もありますが、AAD素の機能でそれなりのセキュリティレベルは担保しています。例えばID/Passwordを複雑にする、という対策は、IdPが総当たり攻撃を許してしまえば全くの無力ですが、当然その対策はされています。

詳しくは以下エントリを読んでもらいたいし、私も昔に説明エントリ書いてました。

Azure AD と AD FS のベスト プラクティス: パスワード スプレー攻撃の防御 – Japan Azure Identity Support Blog
Azure AD スマートロックアウトのカスタマイズ機能について-ぷりどうぐ

よって、IDもパスワードも複雑にしておけばまず大丈夫、と言えるでしょう。

結論

  • ADFS環境でもonmicrosoft.comのログインIDは抹殺できるが、ナンセンスで無意味なので、onmicrosoft.comのIDを抹殺する意味はない。
  • AzureADのセキュリティ機能を信用し、辞書攻撃にヒットしないようなID/Passwordを作れば、AzureADが総当たり攻撃には対応してくれる。