パスワード付きZIP暗号化を擁護してみる

「パスワード付きZIP暗号化」とは、ZIPファイル作成時にパスワードを設定し、解凍時にそのパスワードを入力する事で解凍するものである。日本企業では主にメールで添付ファイルを送信する時に利用されているが、セキュリティ的には事実上無意味とされている。

Lhaplusでzipファイルのパスワードを解除しよう | 地デジコピーはじめました。

パスワード付きZIP暗号化のメリット

仕組みが分かりやすく、Windows標準で解凍できる

キャッシュカードなどで慣れている暗証番号の延長線上であり「大事な情報にパスワードをかける」という分かりやすさ。またWindows標準で解凍できるので、相手が読めない、ということがほぼない。

情報がたくさんある

「MacOSではどうかな?」と思って調べたところ、標準のFinder(Windowsのエクスプローラーみたいなもの)では解凍できず、コマンドを使う必要がある。しかしそういう情報もすぐに見つかったので、方法が分からず悩む事はない。

まるでセキュアに見えるユーザー体験

セキュリティ業界は「セキュリティと利便性の両立を目指す」事を目標にいろんな製品を開発しているが、皮肉なことに簡単に開けすぎると「本当に守られてるのかな?」と思ってしまうのも人間。パスワードを知っている人しかアクセスできない、パスワードは十分に複雑な文字とし、苦労しないと解凍できない、というのは「これだけ面倒なんだからセキュアだろう」と安心することができる。

すぐにパスワードが割れるわけではない

総当たりでパスワードが割れるとはいえ、桁数を多くしてパスワードを複雑にすれば解析にはそれなりに時間がかかる。試しに手元のCore(TM) i7-6600U 2.6GHzのマシンでLhaplusを動作させたところ、秒間280,000パターンの解析が可能であった。一方、ZIP暗号化パスワードに記号を含む文字列を使用している場合、文字数は255パターンであるため、パスワード長が1だと255パターン、パスワード長が2だと、65535パターン…となり、パスワード長と解析時間の関係は以下の通りとなる。

文字列長 パターン数 解析時間
1 256 0.0009秒
2 65536 0.23秒
3 16777216 1分
4 4294967296 4.2時間
5 1099511627776 45日
6 281474976710656 31年
7 72057594037927900 8160年
8 18446744073709600000 2089080年
9 4722366482869650000000 534804496年
10 1208925819614630000000000 136909950942年

もちろん、スーパーコンピューターが自由に使える立場の人ならこの表は無意味だが、一般社員がファイルを受け取って、自分のPCですぐにZIP解凍パスワードを当てる、というのは難しい。よって以下のようなシナリオなら十分に対応可能である。

  • 取引先Aに送信すべき添付ファイル付きメールを、誤って取引先Bに送信。
  • 取引先Aには、ZIP暗号化の解凍パスワードだけを送信
  • 取引先Aから、添付ファイルの実体が送信されてない事の連絡を受ける
  • メール送信履歴を確認し、メール宛先間違いに気づく
  • 取引先Bに連絡し、宛先間違いなのでメールを破棄してほしい、と連絡
  • 取引先Aに事故報告書を提出

この際、取引先Aには誤って取引先Bに添付ファイル付きメールを送信したものの、ZIP暗号化されており短時間で閲覧できる可能性は少ないため、事実上情報漏えいはないと報告できるだろう(もちろん、取引先Bの協力を経て、メールが転送されてないなどの監査ログを取得する必要はあるが)

パスワード付きZIP暗号化のメリットまとめ

  • 分かりやすい
  • 一般的
  • まるでセキュア
  • すぐには情報漏えいしない

パスワード付きZIP暗号化への対抗ソリューション

一番重要なのは分かりやすくて一般的であること。”一般的”の目安は「マスメディアで話題にできるほど」だと考えていて、パスワードの他には生体認証も市民権を得ているし、最近だと二要素認証も認知され始めた。

これらは認証技術だが、ファイル共有の仕組みとしてはビジネスチャット利用による、限定されたグループメンバー内でのファイル共有、オンラインストレージを利用したファイルリンク共有も広まってほしい。前者は、意識せずともメンバー以外にファイルが漏れない仕組みであり、後者はZIP暗号化と違ってファイルリンクの誤送信 = 即情報漏えいになるものの、アクセス履歴が取得でき、アクセス権をすぐに削除できるメリットはある。

また”一般的”の定義も時代によって変わってくると思っている。仕事のメールをスマホで閲覧する時代「ZIP暗号化メールはスマホで見れないから送信しないで or オンラインストレージで共有して」という流れができるかも、と思っている。

ということで、パスワード付きZIP暗号化ソリューションはそこそこ浸透しているが、世の中の潮目が変わる時が覇権の代わり時なのかな、と思っています。会社にパスワード付きZIP暗号化をやめさせたい場合は、これを意識して論じる必要があるな、と思いました。

OWAで受信した添付ファイルを3rdパーティー製クラウドストレージに保管できてしまう

件名のような驚きの機能がリリースされました。以下、マイクロソフト社のリリース全文です。

Microsoft 365 ロードマップ | Microsoft 365

We’re updating how 3rd party storage providers work in Outlook on the web. To offer an enhanced experience and easier management we are retiring the ThirdPartyFileProvidedrsEnabled and OneDriveAttachmentsEnabled parameters and replacing them with the new AdditionalStorageProvidersAvailable parameter.

This message is associated with Office 365 Roadmap ID 52597.

This feature is not available for Office 365 subscriptions in GCC.

How does this affect me?
This update includes the following changes:

The parameter ThirdPartyFileProvidrsEnabled will no longer control 3rd party storage providers
The parameter OneDriveAttachmentsEnabled will no longer control OneDrive for personal accounts
The new parameter AdditionalStorageProvidersAvailable adds additional 3rd party storage providers to the ones you had before in Outlook on the web, new providers include OneDrive for personal accounts, Google Drive, and Facebook.
This new paramater will be set to $True (“on-by-default”) starting on August 15 for Targeted Release customers and 8/30 for Standard Release customers.
The parameter will be available for you to change it in late July, and the change in the availability of 3rd party storage providers will be gradually rolling out to Targeted Release customers on August 15, and to Standard Release customers on August 30.

Note: OneDrive for Business is not affected by this change or included in this new parameter.

What do I need to do to prepare for this change?
If you want your users to have access to 3rd party storage providers in Outlook on the web, there is nothing you need to do. They will see the providers when we make the update.

If you don’t want your users to have access to 3rd party storage providers in Outlook on the web that are not part of your Office 365 commercial subscription, then:

1. If you are in Targeted Release – Before August 15 you will need to make a change in the set-OwaMailboxPolicy cmdlet using PowerShell.

2. If you are in Standard Release – Before August 30, you will need to make a change in the set-OwaMailboxPolicy cmdlet using PowerShell.

Please, read the additional information link to learn what parameters you need to change from $true to $false in set-OwaMailboxPolicy.

この機能、実は以前よりOWAに実装されていましたが、規定値がOFFなのであまり気にされてこなかったもの。今回は、パラメーターが一新され、規定値がONの状態でリリースされるとの事で、問題と感じます。

実際の動作(想定)

現状、まだ機能がリリースされていないため想定ですが、現状でも3rdパーティー製クラウドストレージへの認証情報入力はできますので、以下のようにOWAの設定画面より認証してみます。認証に成功すると、添付ファイルの保存先として3rdパーティー製クラウドストレージを選択できます。以下の図はとあるテナントで機能を有効にし、Dropboxの認証を設定した状態。

Dropbox側にもばっちり連携出来てます。

現状、添付ファイルをそのまま保管する事はできませんが、3rdパーティー製ストレージのファイルを添付ファイルとして送信することができます。

制御方法

先行リリース有効なテナントは8/15まで、通常テナントは8/30までに

Set-OwaMailboxPolicy -id [ポリシー名] -AdditionalStorageProvidersAvailable $false

を実行すれば機能をOFFにできます。手元のテナントでコマンドを発行しましたが、見た目は何も変わってません。先行リリーステナントでも8/15に機能がリリースされるので、それ以降に検証することになりそうです。

おそらくですが、OWAで3rdパーティー製ストレージの認証情報を入力できなくなるのかな…。

問題点

そこそこの規模の企業だと、情報流出対策として許可されていないクラウドストレージにデータが保管できないような対策を行っています。今回のアップデートはその対策に穴をあけるような機能であり、セキュリティインシデントの原因となる可能性があります。しかも、アナウンスからリリースまでが1か月弱と短く、短期間で対応する必要があります。

最近のマイクロソフト社はこの手の機能をリリースする際は規定値OFFかつアナウンス期間も長めに取っていたのに、今回の変更は規定値ONかつ急なリリースで驚いています。どういう力学でそうなってしまうのか…。

Teamsのライブイベントの3大メリット

Microsoft Teamsには、Web会議の一種として”ライブイベント”というものがあります。

Microsoft Teams のライブ イベントについて | Microsoft Docs

従来のWeb会議と比べて大規模なミーティングに最適…という売り文句ですが、いまいち使い道が分かりませんでした。しかし、一度使ってみて場面によっては非常に使える事が分かったので、実際に使ってみたメリットを書きます。

想定利用シーン

会社の人事制度が変更されることになり、人事部門がセミナールームでプレゼンテーションを行うことになった。セットでTeams会議(今回は、ライブイベント)が設定され、リモートで視聴する事が出来る。

ライブイベントの三大メリット

匿名QAが使える

一番のメリットがこれだと思います。この手の会議で「最後の質問ある人~?」と言っても誰も手を上げず、会議が終わった後にコソコソ聞きに来る。それ、やめーや。とはいえ、人事制度の改定ともなると「私、2年以内に昇進しようと思ってるんですけど、今回の改定って影響します?」なんて聞き辛い。

そこでライブイベントの匿名QA機能。ライブイベントで使えるQAは、参加者が匿名で質問を投稿することが出来ます。これ、本当に匿名で、ライブイベントが終わった後に主催者がQA一覧をcsv形式でダウンロードできるんだけど、そこにも名前は入りません。もちろん、監査ログレベルで追っていけば調査する事は出来るかもしれないですが、コンプライアンス管理者権限が必要なので、通常は好き勝手見れるものではない。

匿名QA、技術イベントでも使えると思います。「こんなつまらない事、みんなの前で質問するのは恥ずかしい」という場合は匿名で質問する。実名でも気にすんな!と思いますが、後で聞きに来られるよりはマシでしょう。

なお、発生した質問は主催者が匿名のまま公開して「よくある質問」にピン留めすることが出来ますし、特に公開するほどの質問でもなければ回答だけして終わる事も出来ます。この場合、QAが見えるのは質問した人と主催者だけで、他の参加者は見ることが出来ません。

不要な参加者を黙らせることができる

20人くらいTeams会議参加すると一人くらいはマイクがONになってて「誰か~マイクOFFにして下さい~」「わっはっは俺だった」みたいなやり取りが発生しがちです。ライブイベントだと参加者に発言権がないので、必然的にこういう事は防げます。機能としてはみなさん知っていると思いますが、体感するとストレス低減されて意外と便利。

画質向上

実際にうちの会社でライブイベントを利用したところ、ほぼ全ての参加者より「普通のTeams会議より明らかに画質が上だった」と感想をもらいました。普通のTeams会議もCDNは利用しているはずだし、何がそんなに差が出るのだろう…と思って考えてみたのが以下。

  • Teams会議は双方向通信、ライブイベントは一方向通信。
    • 双方向の場合、全ての参加者がメディアを発信する可能性を考慮する必要があるが、一方向なら主催者からのデータ発信に最適化したトポロジを利用できる
  • Teams会議はリアルタイム、ライブイベントは10秒~20秒遅れている。
    • リアルタイムだと発生したメディアを即伝達する必要があるが、遅延が許されるのなら、エンコードして最適なサイズになったメディアを配信すればよい

ということで、ロジック的にライブイベントの方が有利だから、画質も良くなるんだなと思いました。

ライブイベント利用の注意点

利用シーンによっては非常に強力なライブイベントですが、注意点もあります。

死んでもライブイベントを途中終了させない

終了したライブイベントは二度と再開することが出来ません。Teams会議の時のクセで「なんか画質悪いって意見あるから、いったんイベント終了させますね~」とやると終わり。ちなみにPCの調子が悪い場合は、ライブイベントを終了させずPCだけ再起動すれば、ライブイベントは継続したままとなります。

QAが動作しない場合を想定して対策を取る

ライブイベントには現状「参加者からQAが見れない」というバグが存在します。こうなってしまうと、参加者から主催者に意思を伝える手段がなくなってしまうので、QA以外のバックアップを用意するのがよいです。例えばイベントに対する問い合わせ窓口のメールとか、匿名投稿が可能なFormsとか。

お勧めとしては、SharePoint Onlineのサイトページ、またはYammerの投稿を作成し、そこにライブイベントのURLを投稿する。全社にライブイベントのお知らせをする際に、ライブイベントのURLではなくSharePoint OnlineのページまたはYammerのページを案内し、ライブイベントで何か不具合があればそこに書き込んでもらう。これなら、万が一間違ってライブイベントを終了させてもページを通じて参加者にアナウンスできるので安心です。

まとめ

Teams会議より前準備が必要で気軽ではないように見えるライブイベントですが、シーンを選べば非常に強力なので、みなさん使ってみてください。

Teamsのチャネルメッセージを完璧にエクスポートしたい

Teamsのチームは用途が終わったら削除する前提で設定されていますが、削除前に会話のエクスポートが出来ません。なのでこんな感じで困ります。

  • 情報システム部「もうそのチーム使い終わったでしょ!成果物のファイルを整理して、チーム削除して」
  • チームオーナー「削除してもいいけど、会話は後で参照したいから残しといて」
  • 情報システム部「ぐぬぬ」

よっていつまで経ってもゴミチームが残ったままです。

Teamsのチャネルメッセージをエクスポートする方法

1. セキュリティ/コンプライアンスからエクスポート

セキュリティ/コンプライアンスを使えば、Teamsのチャネルメッセージをエクスポートできます。しかしながら

  • チャネル毎にエクスポートできない
  • 親投稿や返信の関係性をうまくエクスポートできない

という問題があります。あくまで監査用であり、ユーザーが見やすい形でエクスポートはできないようです。

2. GraphAPIを使ってエクスポート

APIを使えばチャネル毎に親投稿や返信の関係性も含めてエクスポートできます。

ということで、2でやります。

技術的な話

APIはこちら。

こんな感じで取得します。

  • チーム特定(ID取得)
    • GET /groups/
  • チーム/チャネル特定(ID取得)
    • GET /teams/{id}/channels/
  • 指定したチャネルの親投稿一覧取得
    • GET /teams/{id}/channels/{id}/messages/
  • 指定した親投稿への返信取得
    • GET /teams/{id}/channels/{id}/messages/{id}/replies

他の事例はこちら。

てことで、取るだけなら割と簡単です。

完璧なエクスポート

ここからが本題です。Teamsのチャネルメッセージにはさまざまな形式で投稿できるため、完全な再現を目指すとそれらを全て取得する必要があります。考慮すべきメッセージ種別を一覧にしてみました。

  • ユーザーの投稿
    • メッセージ属性
      • 投稿者
      • 投稿日時
      • 編集日時
    • メッセージヘッド
      • 投稿/アナウンス
      • アナウンスヘッド
      • アナウンス背景画像
      • サブヘッド(件名)
    • メッセージ重要度(重要/普通)
    • メッセージ本文欄
      • メンション
        • 個人メンション
        • チャネルメンション
        • チームメンション
      • メッセージ本文
        • 日本語
        • 日本語以外
        • 絵文字
        • Giphy
        • ステッカー
      • HTML装飾
        • 太字/斜体/下線/取り消し線
        • ハイライト/フォントの色/フォントサイズ
        • 段落(見出し1/見出し2/見出し3/段落/等幅
        • インデント/箇条書き/段落番号
        • 引用/リンク/コードスニペット
        • 段落罫線/表
      • 画像挿入
        • 画像
        • gif画像(そもそも挿入可能?)
      • 添付ファイル
      • リアクション(いいね)
        • いいね/ハート/笑い/びっくり/悲しい/怒っている
        • リアクション者
  • ユーザー以外の投稿
    • botの投稿
    • コネクタ
    • IncomingWebhook
    • メール投稿

うーん、めんどくさい。

単純な取得

ひとまず少しやってみましょう。

こいつをエクスポートしたのがこちらです。ちなみに以下のAPIをGETで叩いてます。

https://graph.microsoft.com/beta/teams/738f192b-de2d-4cb2-bda8-0273cc7299ba/channels/19:51b38c312f234daa9bb8e9d05aafd796@thread.skype/messages/1565397760720/replies

{
“@odata.context”: “https://graph.microsoft.com/beta/$metadata#teams(‘738f192b-de2d-4cb2-bda8-0273cc7299ba’)/channels(‘19%3A51b38c312f234daa9bb8e9d05aafd796%40thread.skype’)/messages(‘1565397760720’)/replies”,
“@odata.count”: 5,
“value”: [
{
“id”: “1565398720134”,
“replyToId”: “1565397760720”,
“etag”: “1565436221717”,
“messageType”: “message”,
“createdDateTime”: “2019-08-10T00:58:40.134Z”,
“lastModifiedDateTime”: “2019-08-10T11:23:41.717Z”,
“deletedDateTime”: null,
“subject”: “”,
“summary”: null,
“importance”: “normal”,
“locale”: “en-us”,
“webUrl”: “https://teams.microsoft.com/l/message/19%3A51b38c312f234daa9bb8e9d05aafd796%40thread.skype/1565398720134?groupId=738f192b-de2d-4cb2-bda8-0273cc7299ba&tenantId=1ae8725b-e1ff-45f3-b4ff-fb21ab4dc17f&createdTime=1565398720134&parentMessageId=1565397760720”,
“policyViolation”: null,
“from”: {
“application”: null,
“device”: null,
“conversation”: null,
“user”: {
“id”: “72c2cf01-fc7b-4b30-8020-798e87831dcc”,
“displayName”: “Administrator MOD”,
“userIdentityType”: “aadUser”
}
},
“body”: {
“contentType”: “html”,
“content”: “<div><div>\n<div>\n\n<div itemprop=\”copy-paste-block\”>\n\n<div style=\”font-size:14px\”>\n\n<div style=\”font-size:14px\”>10_convでの返信です。いいねなどを付与します<span class=\”animated-emoticon-20-smile\” title=\”スマイル\” type=\”(smile)\”><img itemid=\”smile\” itemscope=\”\” itemtype=\”http://schema.skype.com/Emoji\” src=\”https://statics.teams.microsoft.com/evergreen-assets/skype/v2/smile/20.png\” alt=\”😄\” style=\”width:20px; height:20px\”></span></div>\n</div>\n</div>\n</div>\n</div>\n</div>”
},
“attachments”: [],
“mentions”: [],
“reactions”: [
{
“reactionType”: “heart”,
“createdDateTime”: “2019-08-10T00:58:44.29Z”,
“user”: {
“application”: null,
“device”: null,
“conversation”: null,
“user”: {
“id”: “72c2cf01-fc7b-4b30-8020-798e87831dcc”,
“displayName”: null,
“userIdentityType”: “aadUser”
}
}
}
]
},
{
“id”: “1565398694352”,
“replyToId”: “1565397760720”,
“etag”: “1565398707790”,
“messageType”: “message”,
“createdDateTime”: “2019-08-10T00:58:14.352Z”,
“lastModifiedDateTime”: “2019-08-10T00:58:27.79Z”,
“deletedDateTime”: null,
“subject”: null,
“summary”: null,
“importance”: “normal”,
“locale”: “en-us”,
“webUrl”: “https://teams.microsoft.com/l/message/19%3A51b38c312f234daa9bb8e9d05aafd796%40thread.skype/1565398694352?groupId=738f192b-de2d-4cb2-bda8-0273cc7299ba&tenantId=1ae8725b-e1ff-45f3-b4ff-fb21ab4dc17f&createdTime=1565398694352&parentMessageId=1565397760720”,
“policyViolation”: null,
“from”: {
“application”: null,
“device”: null,
“conversation”: null,
“user”: {
“id”: “72c2cf01-fc7b-4b30-8020-798e87831dcc”,
“displayName”: “Administrator MOD”,
“userIdentityType”: “aadUser”
}
},
“body”: {
“contentType”: “html”,
“content”: “<div><div>\n<div>\n\n<div itemprop=\”copy-paste-block\”>\n\n<div style=\”font-size:14px\”>10_convでの返信です。</div>\n\n\n<div style=\”font-size:14px\”>改行付き。HTML形式(拡張ボックスを開かない)</div>\n</div>\n</div>\n</div>\n</div>”
},
“attachments”: [],
“mentions”: [],
“reactions”: []
},
{
“id”: “1565398692352”,
“replyToId”: “1565397760720”,
“etag”: “1565398692352”,
“messageType”: “message”,
“createdDateTime”: “2019-08-10T00:58:12.352Z”,
“lastModifiedDateTime”: null,
“deletedDateTime”: null,
“subject”: null,
“summary”: null,
“importance”: “normal”,
“locale”: “en-us”,
“webUrl”: “https://teams.microsoft.com/l/message/19%3A51b38c312f234daa9bb8e9d05aafd796%40thread.skype/1565398692352?groupId=738f192b-de2d-4cb2-bda8-0273cc7299ba&tenantId=1ae8725b-e1ff-45f3-b4ff-fb21ab4dc17f&createdTime=1565398692352&parentMessageId=1565397760720”,
“policyViolation”: null,
“from”: {
“application”: null,
“device”: null,
“conversation”: null,
“user”: {
“id”: “72c2cf01-fc7b-4b30-8020-798e87831dcc”,
“displayName”: “Administrator MOD”,
“userIdentityType”: “aadUser”
}
},
“body”: {
“contentType”: “html”,
“content”: “<div>\n<div itemprop=\”copy-paste-block\”>\n\n<div style=\”font-size:14px\”>10_convでの返信です。</div>\n\n\n<div style=\”font-size:14px\”>改行付き。テキスト形式(拡張ボックスを開かない)</div>\n</div>\n</div>”
},
“attachments”: [],
“mentions”: [],
“reactions”: []
},
{
“id”: “1565398674509”,
“replyToId”: “1565397760720”,
“etag”: “1565398674509”,
“messageType”: “message”,
“createdDateTime”: “2019-08-10T00:57:54.509Z”,
“lastModifiedDateTime”: null,
“deletedDateTime”: null,
“subject”: null,
“summary”: null,
“importance”: “normal”,
“locale”: “en-us”,
“webUrl”: “https://teams.microsoft.com/l/message/19%3A51b38c312f234daa9bb8e9d05aafd796%40thread.skype/1565398674509?groupId=738f192b-de2d-4cb2-bda8-0273cc7299ba&tenantId=1ae8725b-e1ff-45f3-b4ff-fb21ab4dc17f&createdTime=1565398674509&parentMessageId=1565397760720”,
“policyViolation”: null,
“from”: {
“application”: null,
“device”: null,
“conversation”: null,
“user”: {
“id”: “72c2cf01-fc7b-4b30-8020-798e87831dcc”,
“displayName”: “Administrator MOD”,
“userIdentityType”: “aadUser”
}
},
“body”: {
“contentType”: “text”,
“content”: “10_convでの返信。HTML形式です。ただ、投稿はただのテキストでやります。”
},
“attachments”: [],
“mentions”: [],
“reactions”: []
},
{
“id”: “1565397786658”,
“replyToId”: “1565397760720”,
“etag”: “1565397786658”,
“messageType”: “message”,
“createdDateTime”: “2019-08-10T00:43:06.658Z”,
“lastModifiedDateTime”: null,
“deletedDateTime”: null,
“subject”: null,
“summary”: null,
“importance”: “normal”,
“locale”: “en-us”,
“webUrl”: “https://teams.microsoft.com/l/message/19%3A51b38c312f234daa9bb8e9d05aafd796%40thread.skype/1565397786658?groupId=738f192b-de2d-4cb2-bda8-0273cc7299ba&tenantId=1ae8725b-e1ff-45f3-b4ff-fb21ab4dc17f&createdTime=1565397786658&parentMessageId=1565397760720”,
“policyViolation”: null,
“from”: {
“application”: null,
“device”: null,
“conversation”: null,
“user”: {
“id”: “72c2cf01-fc7b-4b30-8020-798e87831dcc”,
“displayName”: “Administrator MOD”,
“userIdentityType”: “aadUser”
}
},
“body”: {
“contentType”: “text”,
“content”: “10_convでの返信です。”
},
“attachments”: [],
“mentions”: [],
“reactions”: []
}
]
}

返信が降順に並んでるなぁとかいろいろ思う所はありますが、本文欄に注目してみましょう。

拡張メッセージボックスを展開せず、一行だけで記載したメッセージはHTML形式ではなくテキスト形式で保管されるようです。

“body”: {
“contentType”: “text”,
“content”: “10_convでの返信です。”
},

一方、改行を含めたメッセージを投稿すると、HTML形式になるようです。まぁ一行だけで記載したメッセージ以外はのきなみHTML形式になるのでしょうか。つーか文字の大きさはfontで定義されてるのですね。

“body”: {
“contentType”: “html”,
“content”: “<div><div>\n<div>\n\n<div itemprop=\”copy-paste-block\”>\n\n<div style=\”font-size:14px\”>10_convでの返信です。</div>\n\n\n<div style=\”font-size:14px\”>改行付き。HTML形式(拡張ボックスを開かない)</div>\n</div>\n</div>\n</div>\n</div>”
},

絵文字なんかも再現されるようです。Unicodeで定義されてるやつなんでしょうか?

“body”: {
“contentType”: “html”,
“content”: “<div><div>\n<div>\n\n<div itemprop=\”copy-paste-block\”>\n\n<div style=\”font-size:14px\”>\n\n<div style=\”font-size:14px\”>10_convでの返信です。いいねなどを付与します<span class=\”animated-emoticon-20-smile\” title=\”スマイル\” type=\”(smile)\”><img itemid=\”smile\” itemscope=\”\” itemtype=\”http://schema.skype.com/Emoji\” src=\”https://statics.teams.microsoft.com/evergreen-assets/skype/v2/smile/20.png\” alt=\”😄\” style=\”width:20px; height:20px\”></span></div>\n</div>\n</div>\n</div>\n</div>\n</div>”
},

いいねも取得できますが、いいねをしたユーザーはIDでしか表現されないので、名前まで表示するなら別途ユーザー情報とマッチングしなければいけないですね。

{
“reactionType”: “heart”,
“createdDateTime”: “2019-08-10T00:58:44.29Z”,
“user”: {
“application”: null,
“device”: null,
“conversation”: null,
“user”: {
“id”: “72c2cf01-fc7b-4b30-8020-798e87831dcc”,
“displayName”: null,
“userIdentityType”: “aadUser”
}

…ということで、完璧なエクスポートをしようとすると

  • Teamsのメッセージ種別に対してAPIでどのようにエクスポートされるかを確認
  • それをどのように再現するかを設計

する必要があります。

さて、個人でこれを全てフォローするのはかなり面倒なことが分かったので、後は弊社開発部門のメンバーに丸投げしようと思います(がんばって…) 気分が向いてくれればサクっとツール作って外販できるようになってるかもしれません。あるいはBitTitan社のような3rdパーティー製ソリューションを利用するのもアリですね。

まぁこの手のツールは目的から考えたクオリティにすればいいので、ひとまずメッセージが見れればいい、いいね!なんかは要らない、など要件を定義して、エクスポートする要素を限定するとツールが作りやすいと思いました。

【改悪】Office 365 Baseline Policyで、除外アカウントが設定できなくなる

Office 365 Baseline Policyの概要はこちら。

ベースライン ポリシー: 管理者に MFA を要求する – Azure Active Directory | Microsoft Docs

2018年6月にプレビューが開始された機能です。

Office 365 管理者アカウント 強制MFA機能(Baseline security policy)と対処法

この昨日は、Office 365 で特定レベルの管理者権限を持つアカウントに強制的にMFAをかけつつ、除外するアカウントも指定できるものでした。これが、ここ1週間くらいで

  • 全ての管理者アカウントに対してMFAを有効にする
  • 全ての管理者アカウントに対してMFAを有効にしない

の2択となり、除外アカウントの設定が出来なくなってます。

問題点

現実的には、全ての管理者アカウントに対してMFAを有効にするのはリスクがあるため、MFA除外アカウントを作成するのがセオリーでした。マイクロソフト社も推奨しています。

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

これを実現するためには、素のOffice 365アカウントではなく、Azure AD Premium 1以上のライセンスが必要でした。貧乏人はOffice 365を守ることが出来ません…。

回避法

twitterで裏側のAPIを叩いて設定変更できるぜ!と言っている人がいるけど…。

ライセンスに違反する可能性もあるし、やめた方がいいでしょう。おとなしくAzure AD Premium 1のライセンスを買うか、マイクロソフト社の推奨通り、1要素認証のアカウントのパスワードを複雑にして対処するしかなさそうです。

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での既読機能の構成を考えていきます。