Teamsなんて大嫌い!だが、できる範囲は多いのでまず基本は抑えてくれや
定期的にTeamsに発狂、SPOに発狂して、Microsoftくんにたいする怨嗟と呪詛を吐いている私ですが、O365スペシャリストでもなくIT運用管理者でもない一般的な会社ユーザーとしてはそこそこ使っている部類に入ると思います。
IT管理者でもないのにバイブルを読み解き、触る日々
noteでも以下の記事を書いており、様々な情報管理を実施していく上での「なんでそこが、ケアされてないの?」というMS仕草にブチ切れながら、マニュアルを読み、ブログを漁り、MSが開催するイベント・セッションを確認してなんか無駄に知識を付けてきたわけです。
個別情報だけだとケアできない部分も当然あり、わっけわかんねぇな!?体系的に教えてくれや!!!と、会社で全面導入している点をフル活用してMicrosoft japanを札束で殴ってMSの金でトレーニングをやってもらったり(300万くらいのやつ)、IT管理者の机にはあるやつだよね?っていうO365運用マニュアル本を購入(会社の金で)したりして、中小企業のTeams導入コンサルはできるのでは?(やりたくない)みたいな気持ちがわいてくる程度には、Teamsを中心としたO365世界観の各種ツールをミリミリ触っています。
正直、トレーニングを受けても「この使いにくさはやっぱり公式なんだ…」と思う部分がいっぱいあり、標準形として推奨される使い方自体に「お前さー!?」と机を叩いて歯ぎしりする部分がありながらも、その他個別ツールを選定・購入、導入するコストやらなんやらが高いのは実際理解はできるので、大企業が「O365&Teams標準」になっていくのは理解しますし、全員これは使えや!ができる暗黙の了解を作れるあたりはMicrosoftくんがやはり非常に強い部分だとは思います。
また、まだまだOffice及びOutlook製品が標準な部分が強い以上、連携という面では揃えたほうがいいんよというのもわかる。大企業であればあるほど、ITリテラシーとスキルが一定ではないので、その上で「とりあえずこれを使え」する分の機能には決して不足はないどころか、ちゃんと理解すれば使える範囲は大変広いものでもあります。
ただアクセス権管理とか、Teams / SPO / Onedriveの連携と住み分けがマジで意味わからん(わかるけど)とか、その辺は使っている中で「死んでほしい★」とは常々発狂しています。
仕事で管理したい観点は限られる
常々「ナレッジマネジメント!」「コミュニケーション設計!」「コンテンツマネジメント!」みたいなことを発狂しながら管理しているのですが、組織-部門-部-チーム / プロジェクト という管理単位の違いがあれど「これが欲しい」と思う構成要素に大きく変わりはありません。単位によって抽象度が上がるので、詳細の度合いが変わるだけで、カテゴリとしての要素はほとんど同一でしょう。
何が欲しいの?というとだいたいこんな部分で、括弧 ( ) 内は実現してくれる機能です。
メンバー情報 ( Excel、List、Onenote)
ファイル情報 ( PPT,Excel,doc類 )
テキスト情報 (議事録、ルールなどサマリ情報を含む) (doc、List、Onenote)
ToDo、課題管理情報 (Planner、List、Onenote)
スケジュール情報 (Excel、List、Onenote)
上記を実施していく上でのコミュニケーション・プラットフォーム (Teams上)
で、まぁ曲りなりにもTeams上で全部できるので、使って設計してくれやという話になるわけです。
誰にでもできる!Teamsでコミュニケーション管理をする5つの観点
めちゃくちゃビジネス記事っぽい感じですけれど、とりあえず「日常業務」の中ではこの5つの観点を理解して運用したらどうにかなるから!逆にこの観点での管理すらできてなくて、有象無象のファイル管理になっているならそれはもう人間が悪い。Teamsの悪口を言う前にやることをやれ!の世界観です。
一定の塊ができたらチームを作り管理する
1で親をつくったら子関係になる塊はチャネルで管理する
見せたくない(管理職限定とか)領域はプライベートチャネルで切り出す
タスクはplanner、テキストはwiki(Onenote)で登録し、「チーム」単位の管理を設計する
ちょっとイマイチな感じになったら壊して新しく作り直す
大事なのは2と5でしょうか。特に5。
チームを作るのは良くも悪くも簡単なので、当初目的からイマイチになったなぁと思ってきたらさっさと作りなおしちゃったほうがいいです。考えるの面倒だし。
具体的な設計方法例
基本的に業務の「塊」が何かしらで発生したら、さっさとTeamsを作ってしまえ!です。いらなくなったら消すなりすればいいので。
ここでは「TEST部」のチームとしてTESTを作ったと仮定しましょう。内容は業務によりますけど、ざっくりこんなかんじ。
TEST(チーム)
一般:会社広報や部門全体のお知らせ用(チャネル)
管理職(鍵):管理職のみのコミュニケーションページ、業績やconfidential情報など(プライベート・チャネル)
勤怠・休暇連絡:チーム全体の勤怠・休暇連絡用(チャネル)
週次定例会議:部週次の資料、議事録用(チャネル)
予算・数値管理:年度、月次、週次の数値関連情報の連絡、格納用(チャネル)
チームはタンス、チャネルは引き出しみたいなイメージです。
チャネルごとに対象チャネルに格納する情報のジャンルを決めて整理してく…というイメージです。これをすると少なくとも「この話題の時はこのチャネルを見たら何かがある」という状況になるわけなので、やれこっちのメール、やれあっちのメール、そっちのTeams、個別で持っているファイル…的な一番面倒な「情報の点在」は避けていけるはずなんです。はずなんです…!
また、各チャネルごとにアプリケーションを選択肢、タブに登録できる形になるのですが、これが便利なのか不便なのかは若干悩むところです [ Teamsのイケてないポイント0.5]
一般チャネルはデフォルトで作成され、メッセージ投稿などもシステム管理者権限がないので間違えると後戻りできないです。『一般』は名前も変えられず、先に述べたようにシステム管理者しかコメント削除ができないためゴミ掃除ができない。そのため『一般』は本当~~~~~にgeneralで一般的な内容の利用に留めて、細かいやりとりは各チャネルで実施することをオススメします。このへんの暗黙の了解みたいな部分が発生するのが [ Teamsのイケてないポイント1] 。
所有者しかコメント投下できないようにしちゃったほうがいいかもしれませんね。何も考えずにgeneralにバンバンコメント投下するアホとか発生したりするので。実際するんですよ。そうするとチームの顔というか、トップページにあたる部分がすごく汚くなって気持ち悪いので、制限しちゃう方がいい気がします。特にルールが浸透するまでは…。
プライベートチャネルの設定
管理職チャネルのように、一部の人にしか見せたくない領域は「プライベートチャネル」として切り出しましょう。
ちなみにプライベートに追加できるのは250名までで、かつ一括登録できないという地獄のような仕様です[ Teamsのイケてないポイント2]。さらにちなむと、Generalはメーリングリストであれば一括登録できますが、ない場合は手動かPower Automateで登録するしかありません[ Teamsのイケてないポイント3]。さらに登録メンバーのエクスポート機能なども標準ではなく、Power Automateでどうにかするしかありません[ Teamsのイケてないポイント4]
ファイル / タスク / テキスト管理
先に述べたようにチャネル単位でのアプリ登録設定ができるため、ある程度の業務単位、目的ベースでチャネルを切るか、グループ単位で設計するほうがよいでしょう。グループ単位とは例えばTEST部配下のマーケティング部、営業部、管理部、みたいなチーム単位みたいなイメージです。
ただし、グループ単位だと結局それぞれの部なりチームなりの単位でチームを作ったほうがいい…ということになりがちなので、この辺りの設計や管理はちょっと頭をひねる必要があります。この「ちょっと考えなきゃいけないけど、汎用性があるので悩む」的な事象が頻発するのが私がTeamsが嫌いな理由です。
話がそれました。チャネルの目的に沿って、ファイル管理、タスク管理、テキスト管理(議事録、ちょっとした集計など)ができるので、「この業務はここに行けば関連ファイルとテキスト情報が全部ある」状況は作ることができます。
なので、例えば「週次定例」チャネルには週次定例で投影したファイル、議事メモ、ちょっとしたアナウンスをそのチャネルで完結させることができますし、そこまでできていてTeamsの使いづらさや機能制限で発狂するなら、丸ごと移行を考えればよろしいと思います。
また、ライセンスによりますが、Power platform (apps、Automate、BI)を併用できるメリットはあります。もちろん重かったり癖があったりはするのですが、目的特化ツールを個別導入することでのコストは増えるので、一定の形が出来上がった上で検討することが重要です。
O365ライセンスを利用している中での他ツール利用のハードル
個人的にめっちゃ嫌いなのはお伝えしてきた通りなのですが、実際「全社員がこのライセンスを持っている」便利さというのもあり、とりあえず誰かにアカウント発行したり、ライセンスコストを考えなくていい(会社側で管理してくれている)というのはとても便利です。
逆に言うと、Teamsの限界を感じて別のツールに移行して、チーム内では快適になっていっても他部門連携をしようとした瞬間に結構な手間がかかる(教育コスト含めて)という部分はめちゃくちゃにあります。Notion好き好き大好き愛している!と思ってるし、wikiが廃止されたonenoteに統合されたせいで50年ぶりにonenoteを触ったら相変わらずすぎて死ぬ!!!となったのですが、それでも新ツールを全体で使わせていく部分の導入・運用設計って本当に手間がかかるので結構大変です。
以下は社内で移行の話が出た時にNotionの説明しろっていわれたのに、マジでファシリができない人間に振り回されてお蔵入りしたReportの一部です。マジで失礼なことしてくれるな…という気持ちで思い出してもイラつくな。
私はNotionが大好きだし、もう全部揃えてぇなぁ…と思いつつ、NotionはDB機能やマークダウン記法などの一定のリテラシーが必要だし、そこを理解しないで使ってもただのメモ帳なので、だったら「Onenote使えば?」という話になるんですよね…。導入コスト(運用、勉強含む)を無視して導入して、NotionがOnenote以下のゴミクズになっている状況を今みていて私は泣いています。
資格取ろうかな…
MSの資格って何気にもっていなかったのですが、無駄に関わっているし初級の資格を取ってみるのはちょうどいいお勉強になりそうな気がしますので、上期を目標にどっちかに着手してみようかなと思います。
ここから先は
ありがとうございます。『あなたの課金は、私の課金』を標語に経済をまわしていきましょう。