SlideShare a Scribd company logo
1 of 124
情報共有ツールの使い分けの
考え方とアプローチ
”Office 365 を使い始める/使い倒す“ シリーズ
BIZ UDP Gothic のフォントが埋め込まれておりますので、
不必要な方はファイルのオプションからフォントを保存するというチェックを外してご利用ください
”Office 365 を使い始める/使い倒す“
シリーズについて
本シリーズの資料は、
Office 365 のサービスを使い始めたい / 使い倒したい
という時に見て頂く “読み物” です。
サービスの仕様などは公開されておりますが、
使う前にどのようなことを考えておけば良いのか?
という資料がなかったため、ご要望を良く頂くテーマごとに
シリーズとして徐々に増やしていく予定です。
また、テーマごとの資料も更新予定です。
”Office 365 を使い始める/使い倒す“
シリーズの公開予定のテーマ
SharePoint で
始める情報共有と
そのアプローチ
情報共有ツールの
使い分け
使ってみよう
OneDrive
for Business
Teams を
展開して使い倒す
情報共有ツールの
費用対効果を考える
未定公開済み
未定
本資料
ファイルサーバーを
SharePoint に
移行するための
アプローチ
公開済み 未定
Creative Commons の 「表示 4.0 国際 (CC BY 4.0)」です。
以下にどんな利用条件なの?という説明があります。
https://creativecommons.org/licenses/by/4.0/deed.ja
https://creativecommons.org/licenses/by/4.0/legalcode.ja
資料の再編集(説明用に文字減らすとか一部利用するなど)は
実施して頂いて構いませんが元の私の意図とずれてしまうような
使い方だけ避けて頂ければと思います。
この資料の再利用について
本資料について
本資料は、 Office 365 を導入した後に、投資を考えるとすべて使い倒したいが、
一方で、ツールの使い分けについて質問をよく頂きました。
情報共有ツールの世界とは、実は特殊で考え始めるときりがない世界なのですが、
一方で考えるだけで何も活用されずに終わってしまうともったいないので、
参考になるところをうまくご利用頂ければと思います。
少しだけ補足(というか言い訳)
こちらの資料は、私の過去の経験と弊社含めたいくつかの事例を基に、
基本的な考え方と利用するための考え方をこのように考えておけば良いのでは?という資料ですので、
使えるところを使って頂き、皆様の会社の状況という視点を加えて頂き、
本資料をご活用いただければと思います。
(表現がゆるいのは、気軽に読んで頂きたいという思いだとお考え下さい)
2018年1月時点の情報をもとに本資料は作成しております。
Customer Success Marketing 担当:Masaru SUMI
本資料の効果的な使い方
• “生産性の向上” = “主に効率化” に焦点を当てています。
もちろん、それ以外の要素はありますが、皆様の会社の状況を鑑みて
付け加えることができるように作成したつもりです。
たとえば、無駄な印刷物がなくなるというメリットとか
• いくつか説明の中で、理由を記載していますので、理由が皆様の会社に
合わない場合はそこで考えて頂けるように作成してあります。
• 私が出している結果および理由は、記載はしておりませんが、
根拠のあるものであり、理由の出典は Web で検索すると
ゴロゴロ出てくるものです(出典を記載することをさぼったわけではなく、
記載するほどの粒度になっていないため)。
本資料の期待値
皆様、読んでいただいた結果、おそらくですが、ほとんどの方が
“もともと(なんとなく)思っていた通りの結果” になると思っています。
では、なぜ作ったかというと、記載したすべてのことは
考えていないと思っているからです。また、効率性だけではなく、
“そのほかの効果も当然あります“ が話の軸をぶらさないために
本資料では言及していません。
正直、情報共有ツールによる “生産性の向上” は “実現したい人の高い志と稼働“ で
成り立っているのが私の過去の経験です。
そのような人が増えればという思いで、そのような方の訳に立てばと
本資料で誤解頂きたくないこと
この資料で述べているのはあくまでツールの利用における
効率性であり、なにがなんでも効率性だと言っているわけでは
ありません。
どういうことかというと、新しい利益を上げるのは難しいですが、
コスト削減は確実に実現します。
ただ、ツールの利用の効率性の向上だけがあるべき姿だと
考えており、以下のような図式は一切想定しておりません。
効率性を上げる = コスト削減 = 人を削減する
そもそも情報共通ツールとは?
この資料での“情報共有ツール”って何?
業務アプリ
情報共有ツール
会計
人事系
生産系
メール
ファイル共
有
チャット
例
…
・
・
業務アプリの特徴
• 使う人が決まっている
• 会社のビジネスに直結
• これがないとビジネスがまわらない
情報共通ツールの特徴
• 全員使う
• 会社のビジネスに間接的に貢献
• 最低限あればビジネスはまわせる
“情報共有ツール”のへの投資
情報共有ツール
業務アプリ
ここの改善がダイレクトに
ビジネスの貢献につながる
(プロセスも併せて変わるという
ことも含みます)
ここの改善がダイレクトに
ビジネスの貢献につながる
と言い切れるか?
¥(投
資)
¥(投
資)
メール
極論言うと
電話
あれば...OK?
ということは 100% ありません
と が
が会社を作り、動かしています。
会社は利益を上げないと生き残れません。
誰が会社を作っている・動かしているの
か?
• “何” が新しい利益を生む発送を作るのか?
• その新しい発想を形づくるのは “何” か?
“何” = なのです。
情報共有ツール=人の価値の最大化
会社が生き残る ≧ 売上げ ー コスト
ということは皆様ご存知ですが
がコラボレーションして、“ムダなく早く” /
“新しいアイディアを出してビジネスを創る”
社員が集まる環境を創ることを可能にするのが
情報共有ツールなのです。
(細かい話は別の資料で)
もちろん情報共有ツールだけではない
情報共有ツール導入したら、“ムダなく早く” / “新しいアイディアを出してビジネスを創る” 環境が
できるわけではありません。 皆様もイメージするのは例えば以下だと思います。
• より早く回答を得ることができるようになる
• より早く作業を完了させることができるようになる
• より早く見つけたい情報や人を見つけることができるようになる など
ただ、“新しいアイディアを出してビジネスを創る” は企業の文化も本来は併せて考える必要があります。
勘違いしないで頂きたいのは、文化が良くないと情報共有ツールを入れても意味がないか?ではありません。
情報共有ツールをいれることにより、目指すべき文化醸成をサポートするという側面もあります。
良い文化
コミュニケーション
の向上
オープンな文化であれば情報共有ツールを
うまく使いこなすことでさらにコミュニケーションが向上する
情報共有ツールによりコミュニケーションが
向上することでさらに良い文化が醸成される
左記のポジティブ
フィードバックループを
つくることができればベス
ト!
今までの説明の意図と情報共有ツールの必要性
今までの説明は、 Office 365 の情報共有ツールの使い分けを決める重要なポイントであるた
め
明文化して説明をしました。もう少し具体的に触れておくと以下の 2 点の観点で
考えてみると頭の整理をつけやすく、どのように考えるべきかがわかると思います。
• “あるべき組織の姿” → どちらかというと新しい利益を考え出すこと(=売上増加)
新しいアイディアを創ることができる雰囲気や組織の環境とは?
• “望むべき人/チームの行動“ → どちらかというと効率性(=コスト削減)
人やチームが、状況に応じて柔軟に迅速に活動ができる状態とは?
情報共有ツールの使い方を最大化することは
会社を支える人の価値を最大化するものであることは間違いない!
(↑ は皆さま総論としては賛成されます。
ただし、投資対効果となると止まるケースも多いのは事実です...)
とは言いつつ
“あるべき組織の姿“ は会社のビジョンなどがあると思いますが
現実問題なかなか難しいです。ですので、
“望むべき人/チームの行動” = 効率性を出す
ということを確実に実現できるように考えつつ進めるのがベターです。
すなわち、
”社員を全員 100 m を 9 秒で走れるようにしておく”
ことにこしたことはないのです。ちなみに現実進めていくとツールの使い方で
”あるべき組織の姿“ を考えるフェーズも必ずでてきます。
改めて本資料の目的を
この資料では情報共有ツールの使いこなしを考える際の
土台になる考え方を提供できればと考えています。
情報共有ツールの
使い分けについての土台
となる考え方や指針
各お客様の現状や
文化を通す
各お客様ごとの
目指すべき文化と
ツールの使い分け
ツールの使い分けを
考える前提
情報共有ツールの歴史をざっくりと
メー
ル
+ + +
+
手紙
固定電話
FAX
手紙 手紙
固定電話
+
FAX
コミュニケーションという観点では下記のように変遷していると思います。
メー
ル
携帯電話
+
電話
現在
ちょっとまとめてみると
情報の
やりとりの早さ
(ビジネスの早さ)
同じ作業を
実施する上で
必要な資源
必要なコスト
(1人当たり)
手紙 手紙 電話 電話手紙 FAX メール スマホ
電話分減った
FAX 分減った
メール分減った
時間
電話メー
ル
FAX
新しいツールを導入=追加の投資なので、以下のように投資対効果を見てきたは
ず
手段が増えた
手段が増えた
ツールが変わった
ツールが変わった
+
場所の制約がなくなった
場所の制約がなくなった
電話分増える
FAX分増える
メールに変更分増え
る
スマホに変更分増え
る
ポイントは
今までの説明した電話やメールなどは会社としてのインフラとして
必須のもの(になった)という側面があります。
ただ、変わらない点として、情報共有ツールを導入する(投資する)という
ことは
“ツールの数は増える = 今までできなかった処理ができるようになる”
が必須であり、結果として投資に見合う分の “作業効率が良くなる” が必要で
す。
これは最低限効果として出さなくてはいけないものです。
そして、電話やメール以外の情報共有ツールは、
さらなる効果を出していくことを狙うことになります。
では、情報共有ツールのチャレンジと
は?
以下のような作業の効率化もそうですが、
• 調整事(予定とか)が楽になる
• コミュニケーションが早くなった
• 場所を選ばす働ける
• 探したいものが見つかる
本当の目指すべきゴールは以下です。
“人のコラボレーション“ が会社にとって新しい価値を創り出すことを
実現する土台になることが最後のゴール
Office 365 のツールの使い分け
Office 365のツールの使い分けについて
さて、ここからは Office 365 ツールの使い分けについての
考え方を説明していきます。
これから導入する方に向けても記載しておりますので、
導入済みの方からすると少し冗長な箇所がありますので、
適宜飛ばして頂ければと思います。
ツールの使い分けを意識する
必要があるサービスとそうではないもの
Exchange Online
SharePoint Online
OneDrive
Microsoft Teams
Yammer
Office 365 Groups
ここをある程度まとめれば、その他のサービスは
より便利にするために追加するだけ
Stream とか Planner とか
メール・予定表な
ど
ポータル・ファイル共有など
個人のファイル置き場な
ど
グループチャット・個人チャット・ Web 会議
など
社内ソーシャル
チーム用のメール・予定今日・ポータルなど
・
・
・・
・
・・
・
・・
・
・・
・
・・
・
・
O365 の
コアのサービ
ス
大まかにコアのサービスをまとめると
Exchange SharePoint Skype Teams Yammer
今まで 社内外にメール 他製品のポータル
チャット
Web 会議
なし なし
これから
社外メール
>
社内メール
ファイル共有
お知らせ
ディスカッション掲示
板
ポータル
Teams に
(より便利に
という意味で)
個人/グループチャット
Web 会議
ファイル共有
ポータル
社内ソーシャル
(グループチャット)
機能だけ羅列しても当然わかりませんので、なぜか?という点で
目的とサービスの性質を入れて考える必要があります。
大まかにまとめると以下のようになります。この先はとりあえず、Exchange と Skype を
既に利用しているという前提で今後の話を進めます
(自社環境と違う場合は、違いを前提に読んで頂ければと)
SaaS を含むソフトウェアの利用の大前提
少し一般論になりますが、以下をまずは意識してください。
“クラウドの SaaS(ソフトウェア) はそんなに柔軟性がない“
ソフトウェアというのは、もとの目的がありそれを実現するために作られるものです。
ある程度本来の用途ではない利用の仕方は可能ですが、
SaaS は共用している上で動いているソフトウェアという観点ではさらに制約がでます。まとめると
“SaaS、特に情報共有ツールに関してはもともと用意されている設定レベルでの利用が無難”
(ソリューション、SaaS自体が開発することを前提にしている場合は別)
ここで言いたい本来の用途ではないものの例
Excel は万能すぎるのですが、帳票を作るものではありませんし、地図をつくるものでもありません。
(かなり昔は印刷時のレイアウトなどの件があり帳票を作っていたというのはありますが、
昨今は、そもそもの仕組みが変わっており、Excel じゃないとダメということは減っております)
ここからの説明は
Exchange SharePoint Skype Teams Yammer
今まで 内部・外部でのメール 他製品のポータル
チャット
Web 会議
なし なし
これから
外部メール >
内部メール
ファイル共有
お知らせ
ディスカッション掲示
板
ポータル
Teams に
(より便利に
という意味で)
個人/グループチャット
Web 会議
ファイル共有
ポータル
社内ソーシャル
(グループチャット)
3 つのツールについて
説明をします
※ この資料を読んだ時点で Skype を利用していない場合は、Skype のことは抜いて読んでください。
なぜ 3 つのツールからはじめるのか?
使い分けの議論のポイントは
以下のサービスは明確に用途の違いがあり、
皆様の異論はないと思われます。
• Exchange:メール
社内外の人とのやり取り。社外とのやり取りには必須
• SharePoint:ポータル(一旦そのほかの機能は無
視)。
きちんと作ると情報を探すということが非常に楽になる。
ただ、極論言うと必須ではない。
ここしか使わないのであれば
そもそもあまり使い分けの
議論は出ません。
(昔はありましたけど
次のスライドに参考として
情報記載しています)
結論から言うと Skype / Teams / Yammer の使い分けが
ポイントになります。この 3 製品については、あれば便利で
すが、
一方で、極論言うと必須ではないツールであり、できること
も
なんとなく似ている...のでこの 3 つを何のために使うかを
チャットツールを使う
ことが最初の使い分けの
議論のポイント
↓
似たようなツールを
どう使い分けるか?が
次の議論のポイント
(参考)ツールの使い分けの歴史
弊社製品をソフトウェア時代からご存知の方に補足をすると
Exchange の後に SharePoint Server が発売された時に同じ話がありました。
“何故か?” というのは当時の SharePoint の機能の1つに
掲示板やソーシャル(ブログ、マイクロブログ(Facebook のような機能))な
どがあり、
メールだけを利用していた人から見てもどちらのツールで
どのような会話をすれば良いかがわからないという話がありました。
その後、クラウドになり、 Yammer が出てきたときにも同じ話があり
更にその後 Teams...
とりあえず、この資料を読むうえでは既存の考え方は一度横においておいてください
(この後の説明は、必ずしも既存の考え方を否定するわけでもありません)
そもそも、チャットツールの導入は必要
か?
先に記載した通り、Exchange、 SharePoint の利用について
は
否定されるものではないと思います(SharePoint かどうかはおいておいて、
皆様ポータルは利用されていると思うので)
Skype や Teams、Yammer のようなチャットツールがなぜ必要か?
という点については、結論から言うと
“ツールは増えるがコミュニケーションの効率は良くなるから” です。
ここでいう、効率が良くなるのイメージはスマホで移動中とかに
LINE や Facebook でちょこっと返信する便利さのイメージです。
チャットツールが実現する効率性
チャットツールは
• メールなどの返信よりも回答が早い
• わざわざ、その人に会いに行かなくても
簡単な確認であればチャット上でできる
そのほか副次的なものだと
• 人との距離感が近く感じる
(メールよりも表現がくだける)
• チャットのようなメールに巻き込まれない
などが効果としてあります。
メールを
出す
(上のほうが
確率的に多
い)
電話をする
(繋がれば)
数日
1 日
勤務時間内
数時間
即時
回答が欲しい期待値の時間
電話をする
(繋がれば)
メールを
出す
(上のほうが
確率的に多
い)
チャットをす
る
回答が欲しい期待値の時間
電話とメールの間にある
回答が欲しい期待値の
時間をカバーできる
ユーザーの視点で考えると
メールを
出す
(上のほうが
確率的に多い)
電話する
(繋がれば)
数日
1 日
勤務時間内
数時間
即時
回答が欲しい期待値の時間
在籍情報で
次の手段を
判断
メール
出す
チャットをする
電話する
ビデオ
チャットで
会話する
ほかの人を
追加して
Web 会議を
する
コミュニケーションの効率
化
「もやもや」する時間を軽
減
新しい
コミュニケーショ
ン
もやも
やする
回答が早くほしいとき Skype / Teams には在籍情報という機能があるので
回答が欲しい期待値の時間
プレゼンスを
確認する
そもそも回答
を
もらうまで
待てるなら
メールを出す
人の行動のステップ
内容に応じて
手段を変える
…
“情報“ が “流れる“ を考える
当たり前ですが、“情報自体” の “流れ” をまとめると以下になります。
“情報” の “流れ” の早さ
チャッ
ト
メール コンテンツ公開
公開される
(一方向かつ
公開して終わり。
必要に応じて見に行く)
お知らせ ニュース
OR
メール送信
返信もらう
(時間が空く)
早い
メールからチャットに変える
メール送信
返信もらう
(時間が空く)
チャットを
導入すると
チャットツールが導入されると
• 会話の応答までの時間が早くなる
• 社内のコミュニケーションが増える
については結果的に、社内メールは減り社外とのやり取りの割合が増え
る
また、チャットにすることで
• 会話の応答までの時間が早くなる
• 社内のコミュニケーションが増える
本当?
メールからチャットに変える
会話の応答までの時間が早くなる
「会話の応答までの時間早くなる」のは当たり前と言えば当たり前でして
仮想的な会話であるということと
+
短文でのコミュニケーションになるので質問や返事が楽
〇〇の件進めて
よいですか?
はい、良いで
す!
そのほかチャットの方が良いという点は
• チャットのようなメールは見るのも流れを追うのも見る気が失せる
• 「絵文字」、「ステッカー」や「いいね」 で反応できる
• メンションなどで反応すべきタイミングがわかりやすい
• とりあえず CC に入っているメールを受信する / 確認するということが減る
など
たとえば、良いと頃の例として
• 短文になるのは、メールのような冗長な表現がいらない
• 話の流れが追いやすい
• 短文なのでモバイルからでも返事がしやすい
メールからチャットに変える
社内のコミュニケーションが増える?
電話をかける
メールを出す
ちょっと良いですか?という形でアプローチができる
チャットをする
「チャットでの社内のコミュニケーションが増える」 は以下のようなイメー
ジです。
例えば、電話とメールしかない状態
相手に
迷惑かかるか
も
若干急いで
回答がほし
い
回答がいつに
なるか
チャットは一度でも
使い始めた人は使いますので、
コミュニケーションは増えます
相手のところに行く
席にいる?
チャットツールがあると
ここには”世代”によるツールの壁もあります。
“若い世代にとってのメール”
=
“中高年世代にとっての手紙を書く”
若い世代にはメールを書く行為自体が負担
(補足)チャットツールを導入すると遊
ぶ?チャットツールを入れる際に昔は偉い人から
「チャットツール入れると遊ぶじゃないか」
という話がよくあり、導入を断念されているお客様が多かったです。
最近はこの手の話はあまり言われなくなりました
( LINE / Facebook などの普及で利便性を肌身で実感できている効果かと思います)。
ただ、もし、上記のようなことを言われた場合にどのように切り返すかですが、
• チャットツール入れようが入れまいが、遊ぶ人は遊びます。
• 遊ぶ人はメールであろうと、個人の LINE でも利用して同じことをします。
なので、もうすこしポジティブなほうに目を向けて
• 全体の普段のコミュニケーションの回転が早くなる
• 忙しい人がより効率良く仕事ができるようになる
• シャドウ IT で会社の話をされるよりは良い
ということをそれっぽく話せばだいたい説得できているのが現状です。
ここまでの説明で
チャットツールを導入するとコミュニケーションの効率が上がるというのは
ご理解いただけたと思います
(まだ、”う~ん” ...という方はとりあえず一度だけでも使ってみてください)
そのほか、チャットツールには、モバイル利用の親和性が高いとか
Teams だとさらに、 Web 会議、ファイルの共有など作業が
集約されるのでチャットするだけではない効率性が見込めます。
では、 3 つあるチャットツールってどう考えたらよいの? という話をここからし
ます
(ツールが増えることによるユーザーへの懸念は?
と思った方はごもっともです。そのトピックは後程触れます)
Skype / Teams / Yammer の違い?
Skype も Teams も Yammer もユーザー視点では
“簡易的なコミュニケーションで回答を効率よく得る” というメリットがありま
す。
ただし、“チャットという観点での機能的な違い”としては、
• Skype は過去の “会話履歴が継続しない蒸発型” のチャット
• Teams と Yammer は “過去の会話が残る永続型” のチャット
というわかりやすい違いがあり、会話をするという観点での
継続したコミュニケーションを実施する上では間違いなく
Teams と Yammer のほうがより使いツールとなります。
Skype< Teams と Yammer
はい。この時点で実質議論するツールは
Teams と Yammer になります。
では、 Teams と Yammer は?
Teams と Yammer の違い - 1
製品の “思想“ として以下の前提があります
同じトピックを共有する人が
ゆるく会話を開始し、
人がつながる
人をつなげる作業を効率良く実施する
Teams Yammer
目的に基づいて
作業をする
テーマを共有できる
オープンな場が先にあるだけ
同じ目的を持ち、一緒に作業をする
グループが先にある
ここまでの説明について
チャットで作業の効率化という点については、
永続的な会話履歴があるチャットの方が作業がより効率的になる
ということも皆様賛成かと思います。
一方で、Teams と Yammer については “機能の違い” で見ると、
同じようなことができるのでは?ということになります。
では、使い分けをするには何が必要なのか?という話になります。
それが、最初で示した “あるべき組織の姿” をどうしたいのか?です。
“あるべき組織の姿” とは? - 1
例えばですが、以下のような組織だったら嬉しいでしょうか?
1. ある部門で、クーラーが壊れたことをツールで共有したら、隣の部門の人が扇風機貸してくれ
た
2. ある店舗で、〇〇の在庫がなくて、その状況をツールで共有したら、
近くの店舗在庫が余っていることを教えてくれ、お客様にお渡しができた。
3. ある営業が、自分の提案の成功体験を他の地域を
担当している人に共有したことによって同じように成功した
真逆の対応(1.ライバル部門にネタにされる/2.見て見ぬ振り/3.自分の成功は自分のもの)の
会社と比較するとどちらが良いでしょうか?
もし、自分が会社の社長だと考えた際には、答えは明らかだと思います。
(世の中のあるあるとして、2はついでに、そのお客様が対応に感動して
その対応をインターネットを拡散してくれたとかもおきたりしますね)
“あるべき組織の姿”とは? - 2
前述したような “部門を越えた人の助け合い” とか
“なんか新しい発想が出てくる” を会社内で実現をしたい!と
少しでも考えた際には “社内ソーシャル” という概念を
ツールの使い分けに入れ込む必要があります。
では、そのツールはなにか?ということについては、
一旦ここでは Yammer として説明を続けます。
Yammer じゃないとだめなのか?という点については後述します。
(また、“あるべき組織の姿” 論の詳細について別資料で説明します)
(補足)人の繋がり = 関係性の向上
Innovation を起こすためには、
最近の研究では様々な種類の人が関わる
ということが 1 つの要素と言われています。
また、人の繋がりの良い関係があることは
社員も幸せで、さらに Innovation を
起こしやすい環境になると言われています。
(ま、シンプルに言うと個々の人が個別で
作業をしているといろいろな視点で限界があるのは
皆様も肌身で感じていると思います)
人の繋がりが
強くなる
多くの人が
関わる
Innovation が
起きやすい
成功するので
雰囲気が
良くなる
社内ソーシャル=人の繋がりをつくることがなぜ必要なのか?
実現するとうれしい Positive Loop
ここからは
そろそろ具体的な話をしていきます。
ある 1 つの観点でツール群をまとめようとすると失敗というかまとめきれませ
ん。
たとえば、
• データのストックとフローとか
• 情報の共有範囲の大きさでまとめてみるとか
上記は誤りではないですが、これを単にテクニカルな観点でまとめると
失敗します。ポイントは “ユーザー作業の効率化“ であり ”ユーザーの目線” を
考慮した上で考えることがポイントになります。
皆様の気にされるポイントは
複数のツールができることによる
以下の 3 点に集約されるのではないでしょうか?
• 作業効率が下がる
• いつ / 何に対して / どのツールを使うのか?
• 情報の伝達性に問題が出る
あと、苦労されているのは上記のような懸念点ががあるので
できるだけ 1 つのツールに集約されているからではないでしょうか?
(あとは、現実としてユーザーへの周知やサポートの面もあると思います
が)
複数のツールは非効率を産む?
ご指摘の懸念はもっともです。ただ、 基本となるロジックはツールが増えようが
全体の効率性は良くなるということです。
すなわち、 “仕掛ける側” が意識する必要があるのは 2 つです。
1. ツールの使い分けの “模範例” を示すこと
2. “成熟度” (こちらの概念が意外と重要です)
「1」 も 「2」 も、本当に考えるのであれば、“各職種の仕事の仕方” と “企業文化(世代含
む)” の
視点が必要です。ただ、ここは全部実施しようとすると大変です。
ただ、一方で情報共有ツールの世界はそこまで厳密に考える必要がなく、
「2」 の “成熟度” を考えると、意外ときれいに整理することができると思います(と、思ってま
す)。
厳密に考える必要がない?
“情報共有ツールの成熟度が一番下“ = “基本的な使い分け“ は
厳密に考える必要がない理由ですが、エイヤーで言ってしまうと
全体を見た時にそんなに違いがないといえるからです。
使いこなし成熟度 Lv1
使いこなし成熟度 Lv2
使いこなし成熟度 Lv3
使いこなし成熟度 Lv4
営業 研究開発 経理
使いこなし成熟度 Lv1
使いこなし成熟度 Lv2
使いこなし成熟度 Lv3
使いこなし成熟度 Lv4
使いこなし成熟度 Lv1
使いこなし成熟度 Lv2
使いこなし成熟度 Lv3
使いこなし成熟度 Lv4
・・・
・・・ ・・・
・・・各職種 →
成熟度 →
成熟度モデルはだいたい 4 段階が多いですね。
全体を見た時にそんなに違いがない??
“情報共有ツールの成熟度が一番下“ = “基本的な使い分け“ ですが、
だからまとめて全社員に同じルールを全部適用すればよいと
言っているわけではありませんのでご注意を!
基本的な
使い分けが
適用できる範囲
基本的な
使い分けが
適用できる
範囲
会社によってカバーできる範囲は少し違う
なので、ここら辺の見極めは
実際に仕掛ける際には考慮して下さい。
ただ、この一番下のレベルでは
経験上大きく分けても 3 個ぐらいかと
ざっくりで言うと
• 情報共有ツールを使う仕事で外出が多い
• 情報共有ツールを使う仕事で内勤が多い
• 情報共有ツールをあまり使わない仕事で
接客や肉体作業とかが中心
ということで、この資料では
“基本的な使い分け“ を以下に設定
使いこなし成熟度 Lv1
使いこなし成熟度 Lv2
使いこなし成熟度 Lv3
使いこなし成熟度 Lv4
営業 研究開発 経理
使いこなし成熟度 Lv1
使いこなし成熟度 Lv2
使いこなし成熟度 Lv3
使いこなし成熟度 Lv4
使いこなし成熟度 Lv1
使いこなし成熟度 Lv2
使いこなし成熟度 Lv3
使いこなし成熟度 Lv4
・・・
・・・ ・・・
・・・各職種 →
成熟度 →
メールは最低使う(デバイス問わず)
ここにチャットとか各種ツールを加えてみる
もう少し現実を考慮した
ツールの使いわけを考える
さて、ここからは良く頂く質問に回答をしつつまとめていきます。
ツール視点だと 業務観点だと
• メールとチャットをどのように
使い分けるのか?
• ポータルとしての SharePoint と
コミュニケーションツールとしての
SharePoint
• Yammer と Teams は何をもって
使い分ける? Teams だけでよくない?
• 誰かに確実に情報を伝えたい
• 業務上必須の連絡は何を利用すべきか?
• ノウハウ共有
• 正式なコンテンツ など
が、良くいただく質問と皆様が考えて結論が出ないところかと思います。
ツール視点でまずは使い分けを考える
まずは下記の表の左側から
ツール視点だと 業務視点だと
• メールとチャットをどのように
使い分けるのか?
• ポータルとしての SharePoint と
コミュニケーションツールとしての
SharePoint
• Yammer と Teams は何をもって
使い分ける? Teams だけでよくない?
• 誰かに確実に情報を伝えたいとか
• 業務上必須の連絡は何を利用すべきか?
• ノウハウ共有とか
• 正式なコンテンツとか
まずは SharePoint から
“ポータルとしての SharePoint” と
“コミュニケーションツールとしての SharePoint” って何?
“ポータルとしての SharePoint” = 片方向の情報発信
コンテンツが整理整頓されて表示されているもので、ファイルやページなどの
コンテンツは完成形になっているものや会社としての公式の情報であるもの
例)製品資料、契約資料やFAQ など
“コミュニケーションツールとしての SharePoint” = 双方向の情報発信
昔で言う Feed などが該当しますが、今後は会話のようなものは画面に
Yammer などを画面にはめ込んで使う。 敢えて SharePoint の機能で言うと
“ポータルとしての SharePoint” がディスカッションリストで使われているもの
(今後はほとんど “コミュニケーションツールとしての SharePoint” はない...)
“片方向” の情報を公開する場所
こちらは SharePointで
• 全社向けのお知らせやニュース
• 就業規則の公開 など
完成した / 公式なまとまった情報を範囲を問わず公開する。
そして、文字だけではなく、動画などのリッチコンテンツを
利用して情報の伝達力を上げる
今後の SharePoint は一方向の
整理された情報発信の度合が多くなる
貯められた情報を探す場所
• 現在必要で使われるべきファイルなどの情報を集約して
見つけやすい状態で情報を公開する
• 検索や Delve のような Graph と連携した必要と思われる
情報を Push することで気付き与える
コンテンツ公開
公開される
資料
お知らせ ニュース
OR
資料の利活用
動画
全文検索
捕捉ですが
この資料では、
”プチ業務アプリの延長で SharePoint を利用する“
場合については、データとしては双方向のやり取りが当然ありま
すが、
コミュニケーションツールの “基本的な使い方(成熟度Lv1)” に
は
含めておりません。
上記の例はちょっとした在庫管理や申請業務を
PowerApps や Flow などを組み合わせて利用するイメージです。
チャット
メールとチャットツールの両方使うの?
「メールとチャットツールの両方使うの?」
という突っ込みを受けたらどうするのか?という話をよく聞きます。
これについては、両方使うというのが回答になります。
というのは全体としてみた時に “作業効率が上がるから” です(前述)。
ここは “会社としての方針” としてメッセージアウトすることがお勧めです。
社内メール
社内メール
社外メール 社外メール
・ 回答がメールよりも早
い
・ 会話量が増える など
ものごとが
早く進んでいることが
ポイント
総時間が同じ前提で
社内のコミュニケーションに
チャット入れた場合は
一見ツールだけが
増えているように見えるが
では、メールは何に使うのか?
当然ですが、すべてチャットで実施する必要はなく
現実問題以下のような場合は必然とメールが必要になります。
• 長文で複雑な説明が必要な内容で相手がじっくり読む必要がある内容
• 就業規則や組織変更など、公式に近いことに重要な変更などがあったとき
(これは相手に届いている必要がある情報と理解しても構いません。
読んでいる・理解しているかどうかはおいておいて)
など
業務の通達系については、範囲が広い場合や内容が少し
センシティブな時や重要な時はメールを使うと良いかと思います。
この時にそもそもツールが 2 つある場合に、見落とす人がいるのではないか?
という話が良く出ますが、この話は後の “業務観点” のほうで
個人視点のメールとチャットの利用割合
は?
高い
低い
頻度低い 高い
• 業務上の重要性
• 内容の説明の複雑性
• 公式な情報の度合い
全体という観点ではこのように割合がかわると効率という観点では成
功
高い
低い
• 業務上の重要性
• 内容の説明の複雑性
• 公式な情報の度合い
頻度低い 高い
個人視点のメールとチャットの利用
の
成熟度は?
社外の人とのやり取りの量:メール
使いこなし成熟度 Lv1
使いこなし成熟度 Lv2
使いこなし成熟度 Lv3
使いこなし成熟度 Lv4
社内の人とのやり取りの量:メール > チャット
たとえば左のような感じになると思います。
もちろん、利用環境によっては、
社内の人としか利用できないかもしれませんが
その場合は、組織内と組織外などのように
成熟度を考えてみれば良いと思います。
社外の人とのやり取りの量:メール
社内の人とのやり取りの量:メール = チャット
社外の人とのやり取りの量:メール
社内の人とのやり取りの量:メール < チャット
社外の人とのやり取りの量:メール + チャット
社内の人とのやり取りの量:メール << チャット
個
人
視
点
で
の
効
率
向
上
チャットツールが 2 つあるけど?
Teams(Skype) と Yammer の使い分けは
今までの理屈があっても説明がつかないことは
皆さまのご理解のとおりです。
そして、このツールの使い分けを考える際に以下の点で
考慮をすることが必要です。それは
• 会話の “濃さ” (背景が共有されている度合いというイメージで
す)
• 会話の “早さ”
• 会話の “規模”
会話の “濃さ” という観点から見た
Teams と Yammer
会話がより濃くなる
仕事で同じ目的をもったチーム
が
業務を進めるために使うから
会話が薄くなる
テーマに対して興味がある人が
集まって参加するから
同じテーマを共有する人が
ゆるい会話でつながる
人をつなげる作業を効率良く実施する
Teams Yammer
テーマを共有できる
オープンな場が先にあるだけ
同じ目的を持ち、一緒に作業をする
グループが先にある
目的に基づいて
作業をする
製品コンセプト
使う人の想定
結果として
(必ずという
意味ではなく
大体の傾向として)
・・・
・・・
・・・
“会話の早さ”という観点から見た
Teams と Yammer
会話がより濃くなる
仕事で同じ目的をもった人が
業務を進めるために使うから
話が薄くなる
テーマに対して興味がある人が
任意で参加する
Teams Yammer
特定の目的を共有した
チーム内の業務を進めるたの
仮想的な会話なので
一般的には
会話の回転は当然速くなる
テーマごとに集まった
テーマに沿ったよもやま話の
仮想的な会話なので
一般的には
会話はゆるやかになる
前のスライドの続き・
・
・
質問者の回答を
もらえる期待値も
そもそも低い
結果の理由 ・
・
・
会話の速さは ・
・
・
“会話の早さ”という観点から見た
Teams と Yammer
もう 1 つ想像してみてください。10 人のチームが
“同じ時間の間” に “同じ量の会話” があった時に
どちらが使いやすいかどうか??
Teams
1 つのチームの中に
複数のテーマが持てる
チーム
テーマ
テーマ
…
…
例えば 1 つテーマで
チーム活動を実施すると...
Yammer の 1 つの
テーマの中に
左記の “Teams の
複数のテーマ” が
混ざるイメージ
テーマ
テーマ
テーマ
テーマ
テーマ
テーマ
…
…
チーム
テーマB
…
テーマA… テーマ C
…
Yammer
………
…
1 つのテーマに
関心がある人が集ま
る
(補足)Teams と Yammer の機能名称
会話のテーマ
↓
Teams の機能の名称
チャネル
チャネル
チャネル
チーム
…
チーム
(人の集まり)
Yammer の機能名称
グループ
Teams の と Yammer の は同じ=人の集まり
会話のテーマ
↓
チーム グループ
チャネル
チャネル
チャネル
チーム
…
グループ
(人の集まり)
グループ
グループ
チーム
(人の集まり)
グループ
(人の集まり)
グループ
(人の集まり)
テクニカルに階層が 1 つ違う
“規模” という観点から見た
Teams と Yammer
ここで言う “規模” = “社員数” を指します。
例えば、 Teams で 1 つのチームを作成し、
業務上頻繁にコミュニケーションをとる場合(= “濃さ“ )は、
だいたい 20~30 名程度になると思われます。
仮に、1 つのチームで 100 名が参加しているチームを作成した場合、
全員がコミュニケーションするという観点でいうとテーマがより汎用的になるの
で
コミュニケーションの “濃さ” が薄くなることは避けられないので
全員に向けたお知らせのような一方向の使い方が増えることになります。
であればテーマの内容次第では Yammer でもよいということになります。
“規模” を考慮した際に何が変わる?
会社の “規模” が小さい場合に、Teams もしくは Yammer のどちらか
一方で良いのでは?という考え方があります。その考え方は正しいです。
ただ、“規模” が小さく、どちらかのツールに寄せる場合は Teams を使います。
理由は、人が集まって作業をするには Teams のほうが機能的に
会話をする以外の機能があきからに充実しているからというのが回答です。
例として、 Web 会議とかファイル編集作業などです。
注意点として、 Yammer の “人をつなげる” という目的は
Teams 使っても同じことが実現できるの?というところは
少し考えてみた方が良いとも思います。
“規模” が小さい場合の意思決定
“チーム作業の効率化“ と “人のつながり“ を強くしたい
機能的な観点で Teams をメインに使うほうが効率化の効果が出る
“人のつながり” をどちらで実現するか?
Teams だけ or Teams と Yammer
どちらでも構いませんが、どちらの場合も
実際の “規模” により考慮点があります。
何を考慮する必要があるのか?
今まで “規模” の具体的な数字を言わずに進めてきましたが
結論から言うと、 “規模” が 200~300 程度なら
Teams と Yammer の 2 つを使って
“チーム作業の効率化“ と “人のつながり“ にアプローチしても
良いかなとという感覚です。
なぜか?というのは以下の 2 つの視点があるからです。
• 人のつながりをつくる
• ツールのイメージ
“人のつながりをつくる” を考える
“人のつながりをつくる”は大まかに 2 つのパターンがあります。
• パターン A: 業務上一緒に “濃い” 仕事する人
• パターン B: 業務上一緒に “緩い” 仕事をする人もしくは一緒に仕事をしない
人
目的 パターン A パターン B
効率化
チームで、より便利に / より早く仕事を
回せるツールが必要となる
部門や組織の垣根を越えた
必要な人に早く容易にアクセスできる
ツールが必要となる
(困っていて誰かに助けてもらいたい、
普段仕事していない人にヘルプが欲しい、とか)
つながりをつくる
チームでのコミュニケーションの
回数を増やせるツールが必要となる
(そのほか成功体験を共有することや、
スタンプ / ステッカー / 絵文字 が使える、とか)
繋がりがないところで繋がりをどのようにつくる
か?を目指す。ここは Vision とかに合わせて
部門や組織の垣根を越えて人がつながれる
ツールが必要となる
“パターン” x ”目的“ でマトリクスをつくるとほしいツールが見えてきます。
(ついでに効率化という観点もいれています)
ツールと “人のつながり” が目指すところ
ゴールに対しての
かたいつながり
TeamsTeams
ゴールに対して
ゆるいつながり
Yammer “かたいつながり” は業務で作られるので
“ゆるいつながり” をどのように作れるか?
がポイントになる。
極論すると、“つながりをつくる”
きっかけは何でもいい。
部門とかチームとかのカベ
…
ゆるいつながりから
かたいつながり
かたいつながりから
ゆるいつながり
双方向に
有機的に
ツールのイメージって?
先の説明で、ある若い年代にとってはメールは
“手紙(言葉の使い方がフォーマルで季節の挨拶がいるとか)”
を書くほどの敷居があると記載をしましたが、
皆様がツールを利用する際に自然とそのツールで
“実施して良いことの前提条件“ができます。
なので、 Teams は “濃い” 作業をする場という事実ができると、
その同じツールの中で、 “人を繋げる” ための “緩い会話” が
発生するのか?ということになります
(“緩い会話” じゃないと敷居が高くて参加がしづらいということも実際にありま
す)。
そして、 “人のつながり” を作ることが重要だと考えられた場合には、
そのために仕掛けをしないといけません。
(参考)ツールのイメージは世代の観点で
違う
頭脳作業
肉体作業
単純な作業 複雑な作業
バックオフィス
サポート/
コールセンター
秘書
会計/SWエンジニア
クリエイタ
営業
運輸業/
店舗スタッフ
製造ライン
HWエンジニア
SI
“世代“ を意識した
コミュニケーションの方法に対して
考慮が必要
いろいろな職種で
働き方が異なる
同じ職種でも
様々世代が存在
今までのコミュニケーションツールを使うときに考えていたこと
部門や職種による使い方の違い
これからは“世代”も考慮にいれる
ここまでの話で
“人のつながりをつくる” / “ツールのイメージ” については
何を言わんとしているかはご理解頂けたと思いますが、
また、次のスライドから “Teams だけ” / “Teams と Yam
mer” の
パターンのまとめを一回しておきます(大枠のテクニカルな点も)。
Teams と Yammer の組み合わせ条件
1
Teams だけ Teams と Yammer
“濃い”会話をする場所
(業務)
Teams を利用
Teams を利用
(下記の Yammer の用途以外)
“緩い”会話をする場所
明確な利用のルールを作ってあげると
ユーザーが判断しやすいようにします。
• チームの命名規則で冒頭に “S”(Socia
l) とか、クラブなら “クラブ”、趣味なら
“趣” とか
• “パブリック” のチームを作る
• チャットのグループは期間が短いなら
良いですが、1ヵ月以上使うとかなら
チームを作る方がよいです。
ツールごとのガイダンスを出すと良いです。
というか必須ですね。そうしないと、
ユーザーさんからどちらの場所で何を話すのか?
という流れから使われなくなります。
Yammer の用途は
• 全社員に共通する問い合わせ
商品、製品、IT の QA とか
• プライベートな趣味などの会話をする場所
(極端な話をするとプライベート Only で
も)
映画、写真は鉄板ですね。あと、働くママ的
なものも実用度が高くにぎわいます。
Teams のチームと Yammer のグループにはそれぞれ以下があります。
• パブリック:誰でも参加することが可能。Yammer は基本パブリックで使うことが多い(既定の設定。そういう製品思想なの
で)
• プライベート:招待された人のみが参加可能。Teams は基本プライベートで使うことが多い
ざっくりですが、200~300名規模の会社だと
Teams と Yammer を用意しても良いと思います。
Teams と Yammer の組み合わせ条件
2
いままでは、どちらかというと実現したい目的で説明を
してきましたが、当然テクニカルな違いもあります。
Teams Yammer
1 つのグループに
参加できる
ユーザーの数
• 組織全体:5,000 名まで
• プライベート/パブリック:5,000 名まで
制限なし
プライベートグループ 表示されるので、承認されれば参加可能
表示されるので、承認されれば参加できる
(ここが製品思想の違いとしてあります)
ただし、非公開にするグループも作成できます。
グループ作成の制限 運用や設定で可能 制限不可(誰でも作れるのが製品思想)
Teams
https://docs.microsoft.com/ja-jp/microsoftteams/limits-specifications-teams
Yammer
https://support.office.com/ja-jp/article/Yammer-
%E3%81%A7%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B-b407af4f-9a58-4b12-b43e-
afbb1b07c889?wt.mc_id=O365_Portal_MMaven
(参考) Teams と Yammer の
外部共有の使い分けの基準
Teams
Yammer
(外部ネットワーク)
Yammer
(外部グループ)
外部の人と
何をするか?
“濃い”会話であり、
資料の作成や Web 会議や
スケジュール調整など
チームで密に仕事をする
“緩い”会話であり、ファイル共有や、
より大多数の外部の人への情報発信、
複数の会話のテーマを利用して
お知らせなどを実施する場合
“緩い”会話であり、
1 つの会話のトピックの中で
ファイル共有やお知らせなどが
完結する場合
Yammer ネットワーク、グループ、ユーザーの概要
https://docs.microsoft.com/ja-jp/SharePoint/administration/yammer-networks-groups-and-users-overview
Yammer 外部グループの利用イメージ
https://docs.microsoft.com/ja-jp/yammer/work-with-external-users/create-and-manage-external-groups
まずは、Teams か “Yammer の外部ネットワーク” での利用を考えるで
OK です。
明らかに外部ネットワークのように、多数および複数のネタがない場合は
“Yammer の外部グループ“ で。 外部ネットワークと外部グループの違いは
使いやすさです。外部ネットワークは “ネットワークを切り替える” という
作業が発生しますが、外部グループは自社のグループの 1 つのようにみえます。
Teams と Yammer の
使い分けをまとめると
今までの話をまとめると理想は Teams と Yammer を
両方利用することになります(特に、数百名を越える場合は)。
そして、 Teams は当然ながら Yammer を使いこなしたあるべき状態にする方が
会社の存続という点では重要なツールになのですが、
アプローチや使いこなしの成熟度という点ではかなり難易度が高くなります。
ただ、これも “成熟度” を定義してあげて少しずつ高めていけば良いのです。
ちなみに、次の “業務視点” の話でもう少し使い分けは具体的になると思います。
たとえば、以下のような使い方も
サポートデスクメンバー内の世界
例)サポートデスク Ver 1.0
Office 365 Groups と Teams でサポートデスクをする場合
簡易タスク管理
(Planner)
サポートポータル
(Office 365 Groups)
ファイル共有
(Office 365 Groups)
チャット
(Teams)
サポートデスクの
メーリングリスト
(Office 365 Groups)
FAQ を確認
サポートメン
バー
同士の相談
過去の問い合わせを
FAQ として
ポータルにまとめて表示
サポートメンバー内の
タスク管理と負荷状況の確
認
サポートメンバーが
作成したドキュメントを保管
サポート
デスク
エンド
ユーザー
チームの予定表
(Office 365 Groups)
サポートメンバーの
全体スケジュール
メーリングリストで
問い合わせを受け付け
サポートデスクメンバー内の世界
例)サポートデスク Ver 2.0
Office 365 Groups と Teams、Yammer でサポートデスクをする場合
簡易タスク管理
(Planner)
サポートポータル
(Office 365 Groups)
ファイル共有
(Office 365 Groups)
チャット
(Teams)
サポートデスクのメーリングリスト
(Office 365 Groups)
FAQ を確認
サポートメン
バー
同士の相談
過去の問い合わせをFAQ として
ポータルにまとめて表示
サポートメンバー内の
タスク管理と負荷状況の確
認
サポートメンバーが
作成したドキュメントを保管
サポート
デスク
チームの予定表
(Office 365 Groups)
サポートメンバーの
全体スケジュール
質問があるユーザー
ソーシャルの問い合わせ口
(Yammer)
ソーシャルでの
問い合わせ
ソーシャルへの
質問を回答してくれる
ユーザー
ソーシャルでの
問い合わせに回答
Teams と Yammer の連携
https://support.office.com/ja-jp/article/%e3%83%81%e3%83%bc%e3%83%a0%e3%81%a7%e3%83%81%e3%83%a3%e3%83%b3%e3%83%8d%e3%83%ab%e3%82%92-yammer-
%e3%81%ae%e3%83%9a%e3%83%bc%e3%82%b8%e3%82%92%e8%bf%bd%e5%8a%a0%e3%81%97%e3%81%be%e3%81%99%e3%80%82-9fdca2b6-f03f-4632-87d1-e83b87b458b2?ui=ja-JP&rs=ja-JP&ad=JP
サポートデスク Ver 2.0 の補足
Ver 2.0 の何が良いかというと、サポートする側は Teams の画面に
Yammer をはめ込むとかコネクタで追うことができるのと、
エンドユーザー系の機能の使い方は詳しいユーザーも回答できるので、
サポートする仕組みの成熟を待つ必要がないと。
が、この仕掛けは業務の方が実は非常に意味のある使い方になります。
データ処理のルールとか大変さを思い浮かべるのではなく、
この仕掛けがもたらず多様性と回転の速さを妄想してみください。
不幸なことに、少しでも妄想ができた方はさらに Flow、PowerApps
も
いれるとさらに妄想が膨らみます。
そして、これは難しくないのです。エンドユーザーの視点で考えることができれば
業務視点でまずは使い分けを考える
つぎは下記の表の右側から。こちらが現実のはなしですね。
ツール視点だと 業務視点だと
• メールとチャットをどのように
使い分けるのか?
• ポータルとしての SharePoint と
コミュニケーションツールとしての
SharePoint
• Yammer と Teams は何をもって
使い分ける? Teams だけでよくない?
• 誰かに確実に情報を伝えたい
• 業務上必須の連絡は何を利用すべきか?
• ノウハウ共有
• 正式なコンテンツ など
ここからの話のポイントは
ツールが増えることにより、生産効率が上がるという前提で、
一方でツールが増えることにより情報共有ができなくなる?
ということに関して、いくつかのよくあるテーマで説明をします。
ただ、前提として
• そもそも、社員全員が 100 % ルール通り動くことはない
• 今でも、全員がお知らせや通達系を確実に確認して、
その内容を理解しているわけではない
• 一方で、ツールの数が増えたとしても、通常業務で現在実施している
必要なコミュニケーションを死守をする
• 間違っても、完璧な MECE を作らない。多少かぶりがあった方が良い
業務視点でのツールの使い分けは
下記の点は最低でもやっておいた方が良いポイントを
記載しておきます。
80% ぐらい
カバーができそうと
思えれれば OK
情報共有ツールをの効果を出せる領域は
偉い人・声のでかい人向けではありません!
80% のユーザーにとって ”?” な
状況になるのは意味がありません。
• ツールごとの位置づけを周知する
(完璧を目指さないでください)
• 声の大きい 5% や過去の失敗に
目を向けないでください
昔のツールだけを使う人がいる。
メールだけ見るだけでよかったのに
“業務視点” での話を開始する前に、情報の伝達という観点で、
昔のツールしか見ない人への懸念があります。
たとえば、“メールだけ使い続ける” です。
このような “メールだけ見ていればよかったのに” という人を
新しいツールを使わせるようにする必要があります。
そこで、まず事前に何を周知をすべきか?ということですが、
“メールは 1時間 / 2時間おきに見る” です
メールは 1時間 / 2時間おきに見る”?
なぜかというと、正しい展開ができれば、チャットツールについては
どこかで、ユーザー自身が効率性や便利さに気が付き、
下図のようになる(LINE や Facebook など何かしら使ってますし)。
社内
前のスライドの
図を少し変えると
社内外
社内メイン
社外メイン
時間が経つと
時間を 1~2時間と言っているのは、1つの作業を集中して実施する
目安の時間を指しますので、時間の設定は柔軟に。
ちなみに “時間が経つと” の状態の前にどうするかがポイントです。
メールだけを使い続ける人のために
展開直後やそのあとしばらくそういう人がいるのは間違いないです。
そのような人に強制することは難しいのが現実です。
これは、チャットを使う人に “広い心をもってご奉仕” して頂くことが必要です。
メールしか見ない
@Aさん
@Aさん
メールしか見ない人
メールが
届く
・・・ ・・・
メールの URL をクリックして
チャットツールで返信せざるえない
• みんなが使っている
• 応答が早いことに気が付く など
利用経験を通じて、チャットツール
で
返信することが多くなる
生産性を上げるために目指すべきは内部コミュニケーションは以下ということを忘れないでください
(参考)利用の割合について
今までの話は、あくまで俗に言われるホワイトカラーなどの方で
60% ~ 80% ぐらいはカバーできる前提でのお話です。
業務によっては、外部とのやり取りがメインの職種もあり、
メールが業務のメインになる方もいると思います。
ですので、チャットの利用割合の増え方は当然ことなります。
社内メイン
社外メイン
なのか
社内メイン
社外メイン
理想は
あとすべてのパターンを
出す必要はありません。
最高 3つぐらいからでも OK
あと、最適な使い方の割合は
正直利用者にまかせておけば
最適に落ち着きますが、
そもそも使わない状態は
絶体に避けてください!
誰かに確実に情報を伝える
話を “業務視点” の話に戻しますが、まず、 “確実に情報を伝える”
を
厳密に言うと100% 実現することはできません
(メールの TO に入れたから見てるとは限らないから)。
ポイントは “伝えたい人に情報を届けた状態にできるか?” です。
なので、ツールごとに最低限これだけは実施してください
ということを周知することは必要です(最初から全部できなくても
徐々にできるようになりますのでご安心を)。では、次のスライド
伝えたい人に情報を届けた状態にする
ツール 最低限教えておくこと 捕捉
メール TO / CC の使い分け
若干企業により意味合いが違いますが、
CC は FYI 程度ですね。
ポータル 見に行くしかない
• SharePoint だとメールの
通知機能を利用するなどもできます。
• Teams / Yammer にもコネクタや Flow で
情報が届くようにすることもできます(推奨)。
Teams メンション(@山田さん)
• 個人へのメンション以外に、チームメンション
や
チャネルメンションがありますが、
徐々に使ってもらうで良いかと
• メンションがあった場合は、通知のメールを
届くようにしておくことは必須
Yammer メンション(@山田さん)
• 個人へのメンション以外に、フォローなども
ありますが、徐々に使ってもらうで良いかと
• メンションがあった場合は、通知のメールを
届くようにしておくことは必須
本当に最低限の機能は以下となります。
業務上必須の連絡は何を利用すべきか?
“必須の連絡 = 相手に届きかつ確認をしてほしい” 情報となります。
情報の内容 手段 考えるときのポイント
組織や就業規則、人事、
製品情報など
対象が広範囲になる情報
メールが基本
(ポータルをユーザーが
参照しに行く文化が
できている場合は
ポータルでも OK)
“比較的対象が広範囲になる“ のと、
“長文での説明が多い” ため、メールが適していると考えます。
メールで出した後に Teams や Yammer でさらに共有するのは
当然 OK です。必須の連絡は、とにかく見てほしいのでいろいろなツール
で共有するのは悪いことではありません(メール出したから確実に
見ているわけではないため)。ただし、“情報の源流はメールにしておく”
が
ポイントです。ここが統一されないと何を見れば良いのか問題になるので
製品情報とかで
対象が広範囲ではない場合
• ポータル
• Teams / Yammer
情報が複数の部門やチームにまたがる場合は、最初の認知という意味で
メールを出しても良いとは思います。特に部門などをまたがらない場合は、
部門のポータルや Teams / Yammer で良いと思います。
ただ、効率性という意味では、ポータルは情報を参照しに行く必要がある
ので、
Teams / Yammer にもコネクタや Flow で情報を届くようにするのが
推奨です。
ノウハウの共有
こちらは “何の” ノウハウ共有をするかがポイントになりますが、敢えて大きく分けると
以下になります。 前提は、ある程度情報として、吐き出せるものになります
(実際の人対人の対応はなかなかその場の空気などもあるので)。
ノウハウの種類 手段 理由
会話の中でのサポート Teams / Yammer
これは、口頭で誰かに聞くということを、 Teams や Yammer で
バーチャルに実施しているだけです。
ある程度情報として
まとまった資料化された
ノウハウや FAQ などの
まとまった情報
ポータル
こういうある程度まとまる情報については、ポータルがやはり便利です。
皆様が実施されたいことで良くあるのが、会話で発生したノウハウの情報をまとめていくですが、
のような使い方がベースとなりますが、ポイントは “公式・非公式の専任の人” が情
報を
まとめるという観点で必要となることです。組織として用意されていない場合で
実現できている場合は、“志の高い人” がやってくれているからです。
(Graph やアプリ、Flow を利用して、まとめる候補のノウハウとして申請するというのは作れると思いま
正式なコンテンツ
ここで言う正式なコンテンツは、広く利活用ができる一旦完成した
情報をイメージしています。 Teams や Yammer で共有するのも良いですが、
やはりここはテーマに沿ったポータルを用意して整理をして公開するのが
良いと思われます。Teams に紐づている場合は、 Public のチームや、
SharePoint のアクセス権だけは全社員が見ることを意識して
作成および公開をしてください。
ただ、Teams の中で共有された資料を上記を意識して利用する場合は、
最初のアップロード先も含めて共有するユーザー意識をする必要があるため
前スライドの “志の高い人” が必要になるのは変わりません。
(Graph やアプリ、Flow、SharePoint を利用して、送り先を決めるということは
できると思いますが少し壮大な設計が必要です)
ノウハウの共有と
正式なコンテンツの内容についての言い
訳
実は、この 2つについては要望があるのですが、これを自動化しようと思うと、
受け入れ側の情報の設計と情報を送付する送り込む側の運用プロセスなどを
非常に真剣に考えないといけません。
そして、さらに組織の変化に対応するため、共有範囲などが変わるので、
正直な意見としては “人力” が一番かなと考えています。
ただ、会話での共有やポータルでの共有でも良いのですが、
モデレーター的な人は明示的に置いてあげるのが良いと考えています。
(これだけの仕事をする人はあり得ない一方で、
こういうことがまとまっていると現場では非常に助かりますので。
ある意味、このような利他的な行動がこれが全員の意識にある会社は最強です)
まとめ
ここまでいろいろ説明をしてきましたが、“今まで細かい理屈を前提” にあえて
情報の種類という観点でまとめると以下になります。
情報の種類
内部コミュニケーションの視点
メール
(Exchange)
ポータル
(SharePoint)
チャット
(Teams)
チャット(ソーシャル)
(Yammer)
堅い情報
(完成に近い情報 /
1方向で情報を扱うイメージ)
例として、組織関連の情報、通達や
商品やサービスの紹介資料など)
〇
• 文章が長い
• 頻度はたまに
• 広範囲、もしくは
部門やチームを
またがるときに利用
〇
完成したドキュメントや情報を
整理して広範囲に公開
△
左記のメールやポータルで
公開した情報を
あらためて共有する
(情報の自動連携の
構成は推奨)
△
左記のメールやポータルで
公開した情報を
あらためて共有する
(情報の自動連携の
構成は推奨)
緩い情報
(未確定の情報 /
双方向で情報を扱うことが多いイメージ)
例として、会話や議論のようなイメージ
△ × 〇 〇
対象範囲
主にチームから全社員
(ただ、個人へのデリケートな
対応も状況によってはありま
す)
部門~全社員
1~20, 30
(チームの大きさ)
全社員
(ネットワークの対象)
外部にも活用範囲を広げるとさらに生産性があがるのは間違いありませんが、
企業のポリシーがあると思いますので、対象を限定して実現できるのであれば
是非、トライをしてください!
終わりに
ここまで読んで頂け方はありがとうございました。
おそらく、思ったより新しいことはなかったのではないでしょう
か?
情報共有ツールの話は不思議で、正論が正論で通らないために
変な方向にどんどん曲がっていき、結果ユーザーが使いづらい状態
に
なることが多い不思議な世界です。
ただ、一方で仕掛ける側も腹落ちしていないので突破できない
というケースも過去に多々見られたため、この資料が皆様の
ここからは延長戦
今までの説明の中で触れてこなかった以下を少しだけ
• 仕掛け方(資料が作れなさそうなので...)
• テクニカルな観点での考慮事項
• IT の方が Blocker ?
• 私が考えるおおもとのロジック
新しいツールの利用を
強制させる? or 現場から広げる? 1
まず、前提で忘れてはいけないことは、
“新しいツールを入れることによってユーザーの作業が便利になる” です。
なので、たった 1人のためにそのほか全員の作業効率を
落とすことはナンセンスなので、必須の悪意なき強制の例として
上記の “メールだけ使い続ける人のために“ を出しました。
そして、強制もしくは現場のどちらが良いかの回答はありませんが、
次スライドに少しパターンを書いておきます(魔法の杖はない)。
← のスライドで、半ば無理やり使わせているという
イメージを持たれた方がいるかもしれませんが、
これは、悪意なき強制だと考えています。
新しいツールの利用を
強制させる? or 現場から広げる? 2
アプローチのポイントは誰が Blocker か?です。
なので、 シンプルに Blocker の上を攻略する必要があります。
一方で、このような状況でも、現場からのボトムアップで広げるとい
う
形が想定されます。 “成功事例としては両方のパターンがあります”。
では、何が壁になるかというと、えらい方を巻き込む際には
きちんと説明ができることや、現場が困っている場合は、
仕掛ける側は明示的にどうしたいかをきちんと説明する必要がありま
す。
新しいツールの利用を
強制させる? or 現場から広げる? 3
“志の高い人を現場におけるか?” ですが、どういうことかというと、
以下のシーンを想定しています。
• そもそもツールが認知されていない場合は、それを認知させる人が
現場の同僚にいた方が良い(IT からのメールは全部スルーとか)
• 新しいツールを使いたくない人に、最初に手取り・足取り
サポートする人がいた方が良い(トレーニングなどを受けて
勝手にやる人は良いのですが、仮にトレーニング受けても
使わない人もたくさんいます)。そのような場合は “人の繋がり” で
実施するしかないんです。
このような役割りの人の名称は様々ありますが、一般的には兼任で実施する方
が
多いですね。海外だと専任だったりします(社内ファシリテーターみたいに)
新しいツールの利用を
強制させる? or 現場から広げる? 4
“志の高い人を現場におけるか?” は検討して
頂きたいですが、成功するパターンとしては、
“チーム内で特定の業務を Teams で強制する”
から始めてみるのは、あまりはずれがない印象です。 というのは、利便性がすぐにわかるから
です。
なので、 “志の高い人” の役割の方を中心にワイガヤで使い始めてみるのが良いですね。
あとは、 コンプライアンス(Shadow IT とか)は使いやすい御旗ですが、
一方で、便利なツールを提供してこなかったということや、
制約が多すぎるという突っ込みを受けてしまうかもしれませんが、
過去のことはたとえご自身が実施したことでなかったとしても、
将来の良い世界を作るために受け入れて前に進むことを覚悟してください。
新しいツールの利用を
強制させる? or 現場から広げる? 5
少し話はそれますが、そのほかのツールはどうするの?という点です
が、
そこで、出てくるのが成熟度をどう考えておくか?です。
部門ごとの成熟度や会社全体の成熟度をラフに考えておいて
成熟度は都度変更する可能性があることを前提に進めればよいのです。
“強制 or 現場?” には回答がありませんが、“志の高い人” という
役割や、時間軸と成熟度をもとに進めるのがある意味回答になると
思われます。
IT 部門の方が Blocker
こういう話も少なくはありません。というのは、利用ユーザー側か
らは
IT 側がどのようなところまで考慮して、日々どのような対応を
しているかが見えないからです。
ただ、一方で本当に現場から見ると制約だらけで使いづらい状態の
お客様も数多く見てきました。
なので、このタイミングで一度リセットして進めれるなら
是非、進めてほしいと考えています。
では、リセットをするとして何を考えるかを考えてみます。
ツールへの制限を考える際に
• まずは、標準の設定で考えてください。
• ただし、社内ポリシーで全体で設定する社外とのやり取り禁止や、
何かしらのルールというのは考慮が必要です。
• 絶対にやってはいけないのは、すべての機能を確認して、
すべてのポリシーを決めるということです。
管理者側の全体への制御は会社のポリシーなので決めて
良いのですが、それ以外のユーザーに関係するものは標準で
提供することが良いです。
たまに、すべてのユーザーのおすすめの設定を考えようと
する方がいるのですが、そんなものはできるわけがないので、
ユーザー側のものは委任します
(制御を入れる=利用できる範囲を狭くする=不便になるなので)。
(参考)全体で考慮するポイントは
• 社内 / 社外から接続して利用する
• 社外の人と共有することを許可するか?
• ログの取得の設定
• ツールごとの利用できる機能の制御
• ツールの利用自体を全員が自由に利用できるようにするか?
上記が最低限の考慮ポイントになりますので、それをもとに
ブレークダウンしていく形になりますが、
常にユーザーの作業の効率性を考えてあげてください。
よくあるコンプライアンスの話
たまに、新しいツールを入れるときに、必要以上にシビアに考えることを実施するケースがあ
ります。
少し、問いかけになりますが、以下の点で考えてみて頂ければと
• 今のツールでそもそもできていないことをする必要がありますか?
• メールってメールアドレスを持っている人と世界中の誰とでも
情報の共有やファイルのやりとりできますよ?
• 電話での会話って録音されているのですか?
完璧なコンプライアンス対応を目指すのも良いですが、将来的に対応することや、
問題がおきたら制約がでることを前提に、まずは、使いやすい形でユーザー最初に
提供することを考えてみてください。
だって、人の悪意による行為は完璧に防ぐ仕組みは存在しませんから。
なので、最低限は何か問題があったら追える状態にすることをゴールにしませんか?
(参考) Yammer のモニタリング機能
Yammer はソーシャルなので、ほかのサービスのログ監視
とは
少し毛色の異なる機能が追加されています。
• キーワード監視(特定のキーワードが出たら通知)
• 使用ポリシー(利用条件を承認しないと利用不可)
ただ、これも抜け道いっぱいありますし、何を設定したら良いか
の
回答はありませんので... 利用ユーザーの良心をまずは
前提に考えることが必要です。
参考情報
https://docs.microsoft.com/ja-jp/office365/servicedescriptions/yammer-service-description/administration-and-security-
features-in-yammer
Groups と Teams の運用の注意点
Groups のグループメールやグループ予定表を使いつつ
Teams を使いたい場合は以下の順序で作成
1. Office 365 Groups 作成
2. 既存の Office 365 Groups を選択して Teams を作成
先に Teams を作成した場合、
Groups のグループメールやグループ予定表は利用不可
イメージはこういう使い方 →
Office 365 Groups と Yammer
• Yammer 側で Office 365 Groups との連携を有効化する
• 既存の Yammer グループにはこの機能は有効にならない
• 既存の Office 365 Groups に Yammer は追加されない
• Yammer を作成すると Office 365 Groups が作成される。ただし、
メールや予定表の機能は利用できず、
Teams の Groups に対して作成することもできない。
Office 365 Groups を利用する
仕組みの連携について
最初に
作成したもの
グループメール
の利用
グループ予定表
の利用
そのほか
(共通ノート
ブック、Planner、
SharePoint サイ
ト)
Teams
Yammer(Office
365 Groups 連
携)
Groups 利用可能 利用可能 利用可能
Teams 作成時に既
存の Groups を選択
既存の Groups に対
して Yammer の関
連付けは不可
Teams 利用不可 利用不可 利用可能 ー
既存の Teams の
Groups には
Yammer の
関連付けは不可
Yammer 利用不可 利用不可
利用可能
(ただし、既定の
もの以外は追加不
可)
既存の Yammer の
Groups には Teams
の
関連付けは不可
ー
今回の資料の土台は?
効率性という観点でこの資料をつくっていますが、
さらにそのロジックがどこから出てきているかを共有しておきま
す。
下記の 2 点を共有させて頂くことで、さらに私が言いたかった
ことの背景が伝わればと思います。
・会社の目的と理想とする会社について
・効率性の根幹となるロジック
会社って何のためにあるのか?
さて、会社の目的は?という質問をよく耳にすると思いますが、
皆様回答はご存知かと思います。
はい。そうです。「回答はお金を儲ける」です。
これ以上でも以下でもありません。
勘違いしないでください。別に会社の目的が営利ではなく、
「自社の利益を削っても世の為 / 人の為に貢献したい」でも良いんです。
(ここらへんは俗に言われるビジョンの話ですね)
でも、「お金がないとそもそもその目的もできない」
ということは忘れないでください(人間もですけど)。
会社は変化する必要があるのか?
会社の目的=ビジョンはどうであろうと絶対に変わることはありません。
では、もう1つ。会社は「変化する必要」があるのか?
特定の条件を除いてすべての会社は変化をする必要があります。
変化しない場合を考えてみると必然性がわかります。
変化しない場合
~ 同じものを作り続ける ~
わかりやすいのでメーカーを考えてみます。
を作って を貰ってるとして、ずーっと同じものと作り続けると…が
が流行にあわせて が作った
(同業他社) (買う)
を ようになると、
が作った
(海外の会社) (安く買う)
を ようになると、
(おしゃれ)
の売上が減る
がお金がないので
(同じ品質)
の売上が減る
時代が変わり、
(タブレット)
で事が足りるようになり、
(いらなくなる)
と、 の売上が減る
の がなくなり、そもそも を作れなくなる
同じものを作り続けも良いじゃないか
良いのです。そして必ずしも売上が減るものではないのです。
を作って を貰ってるとして、ずーっと同じものと作り続けると…が
ものすごく良い なので がずーっと買い続けてくれる
(ファン)
この場合は を作る原価より が貰えているのであれば良いのです。
ただし、もうちょっと現実を見てみると、この場合は売上の上限はどこかで止まり、
働いている人は から までずーっと同じ
(給料)
かもしれませんね。
もう少し現実を見ると
今まで例を出しましたが、現実はもっともっとたくさんの変数がありますね。
景気とか、少子高齢化とか、地球の裏側の小さな競合がすごい早さで成長するとか、
で、現実は先ほどの例だと「かばん」メーカーも色変えたり、
いろいろな用途を変えた「かばん」を変えたりとかでリスクヘッジしてます。
で、会社は生き残るために、いろんな視点があると考えるのが難しくなるので
フレームワークとかを活用して、分析をして、新しいことを考えています。
代表的で皆様聞いたことがあるものを挙げると SWOT とか
そんなに会社って、新しいことに取り組んでいるイメージがないんですけど…
と思われるかたもいるかもしれませんが、会社の平均寿命は約 30 年とか言われてますよね。
(これ、あくまで平均ですよ)
日本の大会社って寿命が長いと言われてきましたが
そもそも、数を作れば売れる時代に始まった会社だから…という説もよく聞く話です。
たしかに、昔は大会社だった皆様ご存知の会社も潰れる時代になったのです。
そして、現実の現場を考えるともーっといろんな悩みがありますね。
社外の環境の変数考えすぎるのもそうだけど、そもそも何を作れば売れるのか?とか
そして、何か新しいことを始めるのでも既存の環境によって悩みは様々
さて、そもそも何の話をしていたのか?
会社が潰れるリスクだけを考えると、それこそ星の数ほどありますし、
そうしないために何か新しいことを始めるけど、それにもリスクとか壁があって…
で、当たり前のことですが、「生き残る」という結果を得るためには
「結果に至るプロセス」を成功させる以外ないのです。
小さいプロジェクトだろうが、会社自体だろうが
「プロセス」で「よくわかんないけど腐るほどある失敗するリスク」を
回避して成功に導くだけなんですよ。
さて、一度ここで以下の結論をだします。
・会社の目的はお金を得ること
・会社が生き残るためには変化が必要
ここまで、説明したことはちゃんと考えたことがある人もいれば、
なんとなく考えたことがある人もいると思いますが、
なんでこんなことをくどくど説明したかというと
この「正論」が何故か「情報共有変革」の途中で忘れ去られることが多いからです!
(ほかのプロジェクトもそうかもしれないけど)
プロセスをうまく進めるとか言ってるけ
ど このプロセスをうまく進めるために、市場分析とか製品開発とか、
フレームワークとかいろいろ使って挑戦してるけど失敗するんだ!
と言われるかもしれません。はい。これ、無限ループです。
あと、ある程度プロセスが上手くいっていても、
会社全体でお金儲けに目がくらみ始めて、悪いことしちゃって潰れるとか
たまたま社員が何らかの理由で悪いことに手を染めて、
その影響で会社もダメになるとかありますよね。
おいおい、また話がループするよと思ったあなたは正しいです。
何を言いたいかというと、失敗は不可避ですし、避けれないリスクもあるので
そんな確率的に予測不可能なことまで考えて、時間使って利益を減らして対策するとか
考えたくないですよね?
もう 1 つ結論をだします。
大半の働いている人が満足していて、失敗しても前向きに対応ができて、
失敗を重ねても常に新しいこと考えれるのであれば変化に対応できるのでは?
はやとちりしないでください。
「大半の働いている人が満足していて、失敗しても前向きに対応ができて、
失敗を重ねても常に新しいこと考えれるのであれば変化に対応できるのでは?」
上記の言葉のイメージは
・社員の大半が別に皆がイケイケで明るくて Happy なやる気に満ち溢れている
・世の中を変えていく最新の製品 / サービスを作る意欲で合増えている
・社員がたくさんいて、いろんな役割の部門がある会社
ではありません。創業100年以上続いている会社を必ずしも皆様が名前を知っている訳ではないですし、
規模が数千~数万という訳でもありません。
参考)
ちなみに、調査会社によってこの手の数はかなりぶれてますが100年以上の会社は日本が多いのは共通してますね。
日本の老舗一覧https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E3%81%AE%E8%80%81%E8%88%97%E4%B8%80%E8%A6%A7
世界中の老舗一覧
https://en.wikipedia.org/wiki/List_of_oldest_companies
私は学者ではないので、創業100年以上生き残ってきた会社の理由はどうでも良いのです。
ただ、間違いなく言えることは、製品やサービスを提供してお金を稼ぎ100 年以上も生き残っていることは
間違のない事実です。
効率性の根幹となるロジック
会社の目的はビジョンに沿ってお金を稼ぐことです。では、“お金を稼ぐ” こと
は
極論を言うと以下の 2つのプロセスで完結するがスタートポイントになります。
• 作っているモノやサービスが完成する
• 完成したモノやサービスが売れる
私のロジックはこれを前提に考えています。
そして、効率化という意味では、“作ったものが全部売れる” が最大化ですし、
会社が変化に対して生き残るためには、“新しいビジネスを産む時間の確保“ が
必要です。ですので、この 2つは誰も否定できないと思いますし、
情報共有ツールでできること
“作ったものが全部売れる” はサプライチェーンの考え方に近いですが、
当然、このサプライチェーンは 1つのプロセスを司る営業活動やバックオフィス
の
対応がすべて含まれます。では、例に出した営業やバックオフィスで
実現すべき情報共有ツールの在り方はどうなるのか?
一方で、 “新しいビジネスを産む時間の確保“ とは何でしょうか?
たとえば、案件の社内ミーティング、資料作成などは売り上げに貢献する
補佐的な活動でしょうか?これは新しいビジネスを産む時間でしょうか?
と、考えて頂くと、情報共有ツールで目指すべき在り方はどうなるのか?
土台について
私が考える以下の 2つのことが前提にこの資料は作成されています。
・会社の目的と理想とする会社について
・効率性の根幹となるロジック
本来はもっと細かくロジックを説明すべきだとは思っているのです
が
本資料から逸れるのと時間がないため最低限の内容を
共有させて頂きました。基の資料で ? となったときは
前提は上記 2つで考え、ロジックを作っているとお考え下さい。

More Related Content

What's hot

ファイルサーバーの棚卸から考える SharePoint Online を使ったファイル管理
ファイルサーバーの棚卸から考える SharePoint Online を使ったファイル管理ファイルサーバーの棚卸から考える SharePoint Online を使ったファイル管理
ファイルサーバーの棚卸から考える SharePoint Online を使ったファイル管理Hirofumi Ota
 
SharePoint モダン ポータル 徹底解説 !
SharePoint モダン ポータル 徹底解説 !SharePoint モダン ポータル 徹底解説 !
SharePoint モダン ポータル 徹底解説 !Ai Hirano
 
Microsoft 365 を使い、よりよい業務環境の在り方と仕事への向き合い方を考えよう
Microsoft 365 を使い、よりよい業務環境の在り方と仕事への向き合い方を考えようMicrosoft 365 を使い、よりよい業務環境の在り方と仕事への向き合い方を考えよう
Microsoft 365 を使い、よりよい業務環境の在り方と仕事への向き合い方を考えようAi Hirano
 
第34回Office 365勉強会 : Microsoftサポート活用術 ~ Microsoft Azureを中心に ~
第34回Office 365勉強会 : Microsoftサポート活用術 ~ Microsoft Azureを中心に ~第34回Office 365勉強会 : Microsoftサポート活用術 ~ Microsoft Azureを中心に ~
第34回Office 365勉強会 : Microsoftサポート活用術 ~ Microsoft Azureを中心に ~Genki WATANABE
 
[SharePoint Online / OneDrive for Business] 効果的なファイル共有
[SharePoint Online / OneDrive for Business] 効果的なファイル共有[SharePoint Online / OneDrive for Business] 効果的なファイル共有
[SharePoint Online / OneDrive for Business] 効果的なファイル共有Ai Hirano
 
Microsoft 365 Virtual Marathon 2021 - SharePoint サイトの自動作成あれこれ
Microsoft 365 Virtual Marathon 2021 - SharePoint サイトの自動作成あれこれMicrosoft 365 Virtual Marathon 2021 - SharePoint サイトの自動作成あれこれ
Microsoft 365 Virtual Marathon 2021 - SharePoint サイトの自動作成あれこれHiroaki Oikawa
 
メタデータのファイルの管理
メタデータのファイルの管理メタデータのファイルの管理
メタデータのファイルの管理Sylvain Gantois
 
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18Yusuke Suzuki
 
AngularとSpring Bootで作るSPA + RESTful Web Serviceアプリケーション
AngularとSpring Bootで作るSPA + RESTful Web ServiceアプリケーションAngularとSpring Bootで作るSPA + RESTful Web Serviceアプリケーション
AngularとSpring Bootで作るSPA + RESTful Web Serviceアプリケーションssuser070fa9
 
よく聞くけど、「SharePoint リストの 5,000 件問題」ってなんなの?
よく聞くけど、「SharePoint リストの 5,000 件問題」ってなんなの?よく聞くけど、「SharePoint リストの 5,000 件問題」ってなんなの?
よく聞くけど、「SharePoint リストの 5,000 件問題」ってなんなの?Hirofumi Ota
 
これからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきことこれからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきこと土岐 孝平
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
Office 365 管理者が押さえておきたい PowerShell コマンド
Office 365 管理者が押さえておきたい PowerShell コマンドOffice 365 管理者が押さえておきたい PowerShell コマンド
Office 365 管理者が押さえておきたい PowerShell コマンドMari Miyakawa
 
データモデリング・テクニック
データモデリング・テクニックデータモデリング・テクニック
データモデリング・テクニックHidekatsu Izuno
 
SharePoint Online へのアクセスを制限しよう
SharePoint Online へのアクセスを制限しようSharePoint Online へのアクセスを制限しよう
SharePoint Online へのアクセスを制限しようHirofumi Ota
 
SharePointリストのフォームのカスタマイズを利用したときにハマること
SharePointリストのフォームのカスタマイズを利用したときにハマることSharePointリストのフォームのカスタマイズを利用したときにハマること
SharePointリストのフォームのカスタマイズを利用したときにハマることた な
 
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDayマイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay都元ダイスケ Miyamoto
 
FastAPIのテンプレートプロジェクトがいい感じだった話
FastAPIのテンプレートプロジェクトがいい感じだった話FastAPIのテンプレートプロジェクトがいい感じだった話
FastAPIのテンプレートプロジェクトがいい感じだった話NipponAlgorithm
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -onozaty
 

What's hot (20)

ファイルサーバーの棚卸から考える SharePoint Online を使ったファイル管理
ファイルサーバーの棚卸から考える SharePoint Online を使ったファイル管理ファイルサーバーの棚卸から考える SharePoint Online を使ったファイル管理
ファイルサーバーの棚卸から考える SharePoint Online を使ったファイル管理
 
SharePoint モダン ポータル 徹底解説 !
SharePoint モダン ポータル 徹底解説 !SharePoint モダン ポータル 徹底解説 !
SharePoint モダン ポータル 徹底解説 !
 
Microsoft 365 を使い、よりよい業務環境の在り方と仕事への向き合い方を考えよう
Microsoft 365 を使い、よりよい業務環境の在り方と仕事への向き合い方を考えようMicrosoft 365 を使い、よりよい業務環境の在り方と仕事への向き合い方を考えよう
Microsoft 365 を使い、よりよい業務環境の在り方と仕事への向き合い方を考えよう
 
第34回Office 365勉強会 : Microsoftサポート活用術 ~ Microsoft Azureを中心に ~
第34回Office 365勉強会 : Microsoftサポート活用術 ~ Microsoft Azureを中心に ~第34回Office 365勉強会 : Microsoftサポート活用術 ~ Microsoft Azureを中心に ~
第34回Office 365勉強会 : Microsoftサポート活用術 ~ Microsoft Azureを中心に ~
 
[SharePoint Online / OneDrive for Business] 効果的なファイル共有
[SharePoint Online / OneDrive for Business] 効果的なファイル共有[SharePoint Online / OneDrive for Business] 効果的なファイル共有
[SharePoint Online / OneDrive for Business] 効果的なファイル共有
 
Microsoft 365 Virtual Marathon 2021 - SharePoint サイトの自動作成あれこれ
Microsoft 365 Virtual Marathon 2021 - SharePoint サイトの自動作成あれこれMicrosoft 365 Virtual Marathon 2021 - SharePoint サイトの自動作成あれこれ
Microsoft 365 Virtual Marathon 2021 - SharePoint サイトの自動作成あれこれ
 
メタデータのファイルの管理
メタデータのファイルの管理メタデータのファイルの管理
メタデータのファイルの管理
 
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
 
AngularとSpring Bootで作るSPA + RESTful Web Serviceアプリケーション
AngularとSpring Bootで作るSPA + RESTful Web ServiceアプリケーションAngularとSpring Bootで作るSPA + RESTful Web Serviceアプリケーション
AngularとSpring Bootで作るSPA + RESTful Web Serviceアプリケーション
 
よく聞くけど、「SharePoint リストの 5,000 件問題」ってなんなの?
よく聞くけど、「SharePoint リストの 5,000 件問題」ってなんなの?よく聞くけど、「SharePoint リストの 5,000 件問題」ってなんなの?
よく聞くけど、「SharePoint リストの 5,000 件問題」ってなんなの?
 
これからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきことこれからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきこと
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
 
Office 365 管理者が押さえておきたい PowerShell コマンド
Office 365 管理者が押さえておきたい PowerShell コマンドOffice 365 管理者が押さえておきたい PowerShell コマンド
Office 365 管理者が押さえておきたい PowerShell コマンド
 
データモデリング・テクニック
データモデリング・テクニックデータモデリング・テクニック
データモデリング・テクニック
 
SharePoint Online へのアクセスを制限しよう
SharePoint Online へのアクセスを制限しようSharePoint Online へのアクセスを制限しよう
SharePoint Online へのアクセスを制限しよう
 
SharePointリストのフォームのカスタマイズを利用したときにハマること
SharePointリストのフォームのカスタマイズを利用したときにハマることSharePointリストのフォームのカスタマイズを利用したときにハマること
SharePointリストのフォームのカスタマイズを利用したときにハマること
 
Confluence と SharePoint 何が違う?
Confluence と SharePoint 何が違う?Confluence と SharePoint 何が違う?
Confluence と SharePoint 何が違う?
 
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDayマイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
 
FastAPIのテンプレートプロジェクトがいい感じだった話
FastAPIのテンプレートプロジェクトがいい感じだった話FastAPIのテンプレートプロジェクトがいい感じだった話
FastAPIのテンプレートプロジェクトがいい感じだった話
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
 

Similar to 情報共有ツールの使い分けの考え方とアプローチ

【企画書】チャットワーク:社内検討用資料
【企画書】チャットワーク:社内検討用資料【企画書】チャットワーク:社内検討用資料
【企画書】チャットワーク:社内検討用資料Find Job Startup
 
Office 365 とのつき合い方
Office 365 とのつき合い方Office 365 とのつき合い方
Office 365 とのつき合い方Hirofumi Ota
 
Microsoft Ignite 2021 前夜祭 – 注目のIgniteセッション
Microsoft Ignite 2021 前夜祭 – 注目のIgniteセッションMicrosoft Ignite 2021 前夜祭 – 注目のIgniteセッション
Microsoft Ignite 2021 前夜祭 – 注目のIgniteセッションRie Moriguchi
 
sitTokyo2022_Dev_05_Kawanabe.pptx
sitTokyo2022_Dev_05_Kawanabe.pptxsitTokyo2022_Dev_05_Kawanabe.pptx
sitTokyo2022_Dev_05_Kawanabe.pptxssuser5bff5a
 
01 slack導入の提案
01 slack導入の提案01 slack導入の提案
01 slack導入の提案ssuser68dea4
 
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明資料
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明資料Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明資料
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明資料mokudai masayuki
 
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明会
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明会Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明会
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明会昌幸 目代
 
カタログDTPのデータを活用しよう!
カタログDTPのデータを活用しよう!カタログDTPのデータを活用しよう!
カタログDTPのデータを活用しよう!Masataka Kawahara
 
いまの Office 365 ってこんな感じ?
いまの Office 365 ってこんな感じ?いまの Office 365 ってこんな感じ?
いまの Office 365 ってこんな感じ?Hirofumi Ota
 
Microsoft Ignite 2017 に行ってきました
Microsoft Ignite 2017 に行ってきましたMicrosoft Ignite 2017 に行ってきました
Microsoft Ignite 2017 に行ってきましたHirofumi Ota
 
Microsoft Azure 最新 Update 2014/06/05
Microsoft Azure 最新 Update 2014/06/05Microsoft Azure 最新 Update 2014/06/05
Microsoft Azure 最新 Update 2014/06/05Ryusaburo Tanaka
 
今だから企業に提案すべきMicrosoft SaaSの魅力
今だから企業に提案すべきMicrosoft SaaSの魅力今だから企業に提案すべきMicrosoft SaaSの魅力
今だから企業に提案すべきMicrosoft SaaSの魅力なおき おさだ
 
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化についてDaisuke Nishino
 
SharePoint 2016 最新情報
SharePoint 2016 最新情報SharePoint 2016 最新情報
SharePoint 2016 最新情報Hirofumi Ota
 
どうなる?SharePoint 2016 最新事情!
どうなる?SharePoint 2016 最新事情!どうなる?SharePoint 2016 最新事情!
どうなる?SharePoint 2016 最新事情!Hirofumi Ota
 
Web AppsとApplication Insightsで始めるPaaSの一歩
Web AppsとApplication Insightsで始めるPaaSの一歩Web AppsとApplication Insightsで始めるPaaSの一歩
Web AppsとApplication Insightsで始めるPaaSの一歩Masateru Suzuki
 
SharePoint はグループウェアか?
SharePoint はグループウェアか?SharePoint はグループウェアか?
SharePoint はグループウェアか?Hirofumi Ota
 
アジャイル開発&TFS導入
アジャイル開発&TFS導入アジャイル開発&TFS導入
アジャイル開発&TFS導入You&I
 
Azure Logic Apps で SharePoint をパワーアップしよう!
Azure Logic Apps で SharePoint をパワーアップしよう!Azure Logic Apps で SharePoint をパワーアップしよう!
Azure Logic Apps で SharePoint をパワーアップしよう!Hirofumi Ota
 

Similar to 情報共有ツールの使い分けの考え方とアプローチ (20)

【企画書】チャットワーク:社内検討用資料
【企画書】チャットワーク:社内検討用資料【企画書】チャットワーク:社内検討用資料
【企画書】チャットワーク:社内検討用資料
 
Office 365 とのつき合い方
Office 365 とのつき合い方Office 365 とのつき合い方
Office 365 とのつき合い方
 
Microsoft Ignite 2021 前夜祭 – 注目のIgniteセッション
Microsoft Ignite 2021 前夜祭 – 注目のIgniteセッションMicrosoft Ignite 2021 前夜祭 – 注目のIgniteセッション
Microsoft Ignite 2021 前夜祭 – 注目のIgniteセッション
 
sitTokyo2022_Dev_05_Kawanabe.pptx
sitTokyo2022_Dev_05_Kawanabe.pptxsitTokyo2022_Dev_05_Kawanabe.pptx
sitTokyo2022_Dev_05_Kawanabe.pptx
 
01 slack導入の提案
01 slack導入の提案01 slack導入の提案
01 slack導入の提案
 
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明資料
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明資料Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明資料
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明資料
 
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明会
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明会Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明会
Office365 の Teamsというチャットツールはこうやって使うんだよ 社内説明会
 
カタログDTPのデータを活用しよう!
カタログDTPのデータを活用しよう!カタログDTPのデータを活用しよう!
カタログDTPのデータを活用しよう!
 
いまの Office 365 ってこんな感じ?
いまの Office 365 ってこんな感じ?いまの Office 365 ってこんな感じ?
いまの Office 365 ってこんな感じ?
 
Microsoft Ignite 2017 に行ってきました
Microsoft Ignite 2017 に行ってきましたMicrosoft Ignite 2017 に行ってきました
Microsoft Ignite 2017 に行ってきました
 
Microsoft Azure 最新 Update 2014/06/05
Microsoft Azure 最新 Update 2014/06/05Microsoft Azure 最新 Update 2014/06/05
Microsoft Azure 最新 Update 2014/06/05
 
今だから企業に提案すべきMicrosoft SaaSの魅力
今だから企業に提案すべきMicrosoft SaaSの魅力今だから企業に提案すべきMicrosoft SaaSの魅力
今だから企業に提案すべきMicrosoft SaaSの魅力
 
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
 
SharePoint 2016 最新情報
SharePoint 2016 最新情報SharePoint 2016 最新情報
SharePoint 2016 最新情報
 
どうなる?SharePoint 2016 最新事情!
どうなる?SharePoint 2016 最新事情!どうなる?SharePoint 2016 最新事情!
どうなる?SharePoint 2016 最新事情!
 
Web AppsとApplication Insightsで始めるPaaSの一歩
Web AppsとApplication Insightsで始めるPaaSの一歩Web AppsとApplication Insightsで始めるPaaSの一歩
Web AppsとApplication Insightsで始めるPaaSの一歩
 
SharePoint はグループウェアか?
SharePoint はグループウェアか?SharePoint はグループウェアか?
SharePoint はグループウェアか?
 
アジャイル開発&TFS導入
アジャイル開発&TFS導入アジャイル開発&TFS導入
アジャイル開発&TFS導入
 
TFSを支える技術
TFSを支える技術TFSを支える技術
TFSを支える技術
 
Azure Logic Apps で SharePoint をパワーアップしよう!
Azure Logic Apps で SharePoint をパワーアップしよう!Azure Logic Apps で SharePoint をパワーアップしよう!
Azure Logic Apps で SharePoint をパワーアップしよう!
 

More from 日本マイクロソフト株式会社

【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション 【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション 日本マイクロソフト株式会社
 
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ 【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ 日本マイクロソフト株式会社
 
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発日本マイクロソフト株式会社
 
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!日本マイクロソフト株式会社
 
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101 【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101 日本マイクロソフト株式会社
 
【BS5】帰ってきたハードコアデバッギング ~.NET6 を添えて~
【BS5】帰ってきたハードコアデバッギング ~.NET6 を添えて~【BS5】帰ってきたハードコアデバッギング ~.NET6 を添えて~
【BS5】帰ってきたハードコアデバッギング ~.NET6 を添えて~日本マイクロソフト株式会社
 
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介 【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介 日本マイクロソフト株式会社
 
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること 【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること 日本マイクロソフト株式会社
 
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]日本マイクロソフト株式会社
 
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...日本マイクロソフト株式会社
 
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...日本マイクロソフト株式会社
 
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]日本マイクロソフト株式会社
 

More from 日本マイクロソフト株式会社 (20)

【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション 【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
 
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ 【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
 
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
 
【BS12】Visual Studio 2022 40分一本勝負!
【BS12】Visual Studio 2022 40分一本勝負!【BS12】Visual Studio 2022 40分一本勝負!
【BS12】Visual Studio 2022 40分一本勝負!
 
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
 
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101 【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
 
【BS8】GitHub Advanced Security で実践できる DevSecOps 対策
【BS8】GitHub Advanced Security で実践できる DevSecOps 対策【BS8】GitHub Advanced Security で実践できる DevSecOps 対策
【BS8】GitHub Advanced Security で実践できる DevSecOps 対策
 
【BS7】GitHubをフル活用した開発
【BS7】GitHubをフル活用した開発【BS7】GitHubをフル活用した開発
【BS7】GitHubをフル活用した開発
 
【BS5】帰ってきたハードコアデバッギング ~.NET6 を添えて~
【BS5】帰ってきたハードコアデバッギング ~.NET6 を添えて~【BS5】帰ってきたハードコアデバッギング ~.NET6 を添えて~
【BS5】帰ってきたハードコアデバッギング ~.NET6 を添えて~
 
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。 【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
 
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介 【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
 
【BS2】.NET 6 最新アップデート
【BS2】.NET 6 最新アップデート【BS2】.NET 6 最新アップデート
【BS2】.NET 6 最新アップデート
 
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること 【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
 
【BS6】 マイクロソフトの GitHub との取り組み
【BS6】 マイクロソフトの GitHub との取り組み 【BS6】 マイクロソフトの GitHub との取り組み
【BS6】 マイクロソフトの GitHub との取り組み
 
【BS1】What’s new in visual studio 2022 and c# 10
【BS1】What’s new in visual studio 2022 and c# 10【BS1】What’s new in visual studio 2022 and c# 10
【BS1】What’s new in visual studio 2022 and c# 10
 
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
 
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
 
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
 
S17_25 分でわかる!Windows 365 [Microsoft Japan Digital Days]
S17_25 分でわかる!Windows 365 [Microsoft Japan Digital Days]S17_25 分でわかる!Windows 365 [Microsoft Japan Digital Days]
S17_25 分でわかる!Windows 365 [Microsoft Japan Digital Days]
 
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
 

情報共有ツールの使い分けの考え方とアプローチ