Power Apps で電光掲示板のようなものを作る。
はじめに
タイマーコントロールが便利そうだったので、何か作れないかな？と考えたときに、ふと、ラベル動かして電光掲示板みたいなの作れそう、と思ったのがきっかけです。時間の変化が値として取得できるので、これを色々なプロパティやらに当てはめてやれば、動きのあるものを作るのにもってこいです。便利～♪
作ってみたもの
では、作ってみたものです。
スクリーン上に黒い帯(四角形)をバックグラウンドとして配置、その上をテキストラベルがタイマーコントロールの時間経過とともに右から左に動いていく感じです。
テキストのカラーをオレンジにすると電光掲示板チックに見えます。
ただ流れていくだけでは物足りないので、テキストを点滅させてみました。
警報っぽい見た目になったので、テキストもそれっぽい内容のものにw
Power Appsで電光掲示板の様なものを作ってみた。
— Kilroy 365 (@KilroyWaaasHere) 2021年7月22日
大したものでは無いけれど、考えたものが形になって動くのは楽しいなぁ🎶
タイマーコントロールは便利だ👍🏼#PowerApps pic.twitter.com/n4GLqR4ut7
材料
解説用にあとから付け足したラベルとかもありますが、メインのコントロールは以下の4つ。
①テキスト表示用のラベル
- これが電光掲示板に表示されるテキストになります。
②バックグラウンド用の四角形
- 電光掲示板の背景ですね。四角形のFillをBlackにしているだけです。
③テキストを動かす用のタイマーコントロール
- テキストを動かす時間を設定しています。
- Durationの設定で、テキストの動く速さが決まります。
- 解説のため表示していますが、タイマーコントロール自体は表示の必要がないので、Visibleをfalseにするか、XまたはYのプロパティの設定でスクリーン外に表示し、デザイナーでいじるときだけ見えるようにしておけばいいかと思います。
④テキスト点滅用のタイマーコントロール
- テキスト点滅の時間を設定しています。
- Durationの設定で、テキストの点滅周期が決まります。
詳細
まずは、③テキスト移動用のタイマーコントロールの設定です。
AutoStartでタイマーを自動スタートさせ、Repeatで自動的にリスタート。
これで、表示がエンドレスに流せるようになります。
Durationを変えることで、テキスト移動の速さが変わります（仕組みは後述）。
単位はミリ秒になっているので、タイマーの設定時間をを1秒にしたいなら1000を設定。12秒がちょうどよい感じだったので、12000としています。
次に④テキスト点滅用のタイマーコントロールの設定。
テキスト移動用のタイマーと同じですね。点滅の速さ的に2000ぐらいがちょうどよかったですが、この辺りは好みによるところ。
ここから、➀テキストラベルの設定です。動き・点滅ともに仕組みはここの設定で成り立っています。
表示する文字列
まずは実際に表示する文字列。電光掲示板なので、アプリ上で自由に表示を変えられるよう、どこかに入力コントロール仕込むなり、変数使うなり、文字列を可変にする運用がよさそうですね。
WidthにLen関数（文字列の長さを返す関数）を仕込んでおけば、ラベルの長さも文字列に見合った幅になります。使っているフォントサイズ×22でちょうどよい感じだったので22をかけていますが、ここは使用しているフォントやサイズが変われば調整の必要アリです。
文字を動かす
次に、文字を動かす仕組みです。ラベルのXプロパティを時間変化に伴って変化させるとラベルが横方向に動きます。
一定の速度で動かし、タイマーの開始とともに移動がスタート、タイマーの終了と同時に移動も終了するようにするためには、時間経過の割合を使います。
時間経過の割合は、タイマーの時間経過(タイマー名.Value)をタイマーの長さ(タイマー名.Duration)で割ってやると求まります。
このアプリでの場合、以下のように設定をしています。
テキストの点滅
次にColorプロパティを使ってテキストの点滅を表現します。
RGBA（255，191，0，1）がオレンジなので、ベースをこれにして、アルファ値(4番目の引数、透過度を0～1の範囲で指定）を変化させ、点滅を実現します。
時間経過に伴って0〜1の範囲で値を動かすには、文字を動かすのと同様、時間経過割合を使います。
時間経過をの割合をX、色の透過度をYととらえると、色を濃くしていく場合、Y＝X となります（0≦X≦1）。逆に、色を薄くしていく場合はY＝1-Xとなります。変数を設定して、タイマーが終了、又はスタートのタイミングでY＝XとY＝1-Xを切り替えてやれば、
点滅しますね。
グラフで表すと以下のような感じ。
具体的には、アルファ値を
If(
varTextBlink = true,
1-timTextBlink.Value/timTextBlink.Duration,
timTextBlink.Value / timTextBlink.Duration
)
と設定したのですが、変数の切り替え処理の関係か、不安定な挙動だったので、変数を使わなくて済むよう、以下のようにしてみました。
下図実線部分がY＝|2X-1| のグラフで、タイマー開始時はオレンジ、時間経過とともに色が薄くなっていき、タイマーが半分のところで色が透明、今度は色が濃くなっていき、タイマー終点でオレンジに戻る、という感じです。
絶対値はAbs関数を使えばよいので、アルファ値の設定は、
Abs(2*timTextBlink.Value/timTextBlink.Duration-1)
となります。
タイマーを繰り返し動くようにしておけば、点滅してくれますね。
挙動もばっちりでした。
ちょっと改善
ブログでグラフを使った説明を書いてるうちに、2次関数でも行けるなぁと思ったので、ちょっとやってみました。
説明は省きますが、Power関数を使って、アルファ値を
Power(2*(timTextBlink.Value/timTextBlink.Duration-0.5),2)
としてみると、心持ちですが、点滅が自然な感じになったので、コンポーネント化する場合は、こちらを採用しようと思います。
ちょっと点滅の仕方を変えてみた。
— Kilroy 365 (@KilroyWaaasHere) 2021年7月27日
微々たる差だけど…
詳細はブログに載せます。 pic.twitter.com/yq5SXbAgGb
後半のVer.2が2次関数使ったバージョンです。ほんとに微々たる差だw
おわりに
タイマーコントロール、初めて使ってみましたが、アイデア次第でかなりいろいろなことが出来そう。
ネタ思いついたらまたブログに上げてみたいと思います。
しかし、頭の中ではシンプルにやってるつもりでも、いざブログにあげると説明がごたごたしすぎてる…。
Power Automate Blog がupdateされたよ。AI Builder関係の文書処理機能が強化されたみたい。
はじめに
今回のPower Automate blogの内容は、AI Builderの2021年7月のアップデート情報です。
文書の自動化処理機能がだいぶ強化されたみたいですね。
元記事はこちら。
https://flow.microsoft.com/ja-jp/blog/ai-builder-july-2021-update/
ここから翻訳
では、翻訳していきます。
We are excited to announce the general availability of several AI Builder capabilities, new additions which will improve our document automation capabilities, as well as some language and geographic coverage extensions.
新たに追加された、文書自動化機能を改善するいくつかのAI Builderの機能のGA(一般公開)、また同じく、いくつかの言語への展開と(地理的な)範囲の拡大をアナウンスでき、とても喜ばしく思っています。
Scenarios becoming generally available
GAになるシナリオ
Several AI Builder models have graduated out of preview and reached general availability.
いくつかのAI Builderモデルで一般公開されるシナリオは、プレビューから卒業し、めでたくGAとなりました。
In past months, we enhanced AI Builder with new capabilities which are now production-ready:
Invoice processing – Read and save information from invoices which now also include the ability to extract line items.
提供準備が整った新機能を搭載したAI Builderを、我々は過去数ヶ月にわたり進化させてきました：
インボイス(明細書)処理－今では明細情報の抽出機能も含む、明細書からの情報の読み込みと保存。
Receipt processing – Read and save information from receipts, with support now for sales receipts from Australia, Canada, United States, Great Britain, and India.
レシート処理－レシートからの情報の読み込みと保存。オーストラリア、カナダ、アメリカ、イギリス、インドでは売上表についてもサポートされます。
Identity document reader – Read and save information from identity documents.
身分証明書リーダー－身分証明書からの情報読み込みと保存。
You can try out these AI models today directly from the AI Builder page.
これらのAIモデルが、AI Builderページから直接お試しいただけるようになっています。
Generally available products and services are considered production ready.
GAされる製品とサービスは提供準備が整った状態にあります。
By moving out of preview, these models become premium. You will need an AI Builder license or an active trial to continue using them.
プレビューからの卒業により、これらのモデルはプレミアム機能となります。使用の継続には、AI Builder ライセンスか、有効な試用ライセンスが必要になります。
In addition, new features on existing generally available scenarios will now also be production ready.
さらに、すでにGAとなっているシナリオの新機能が同様に、提供準備完了となっています。
Train using documents that have different layouts – This feature was released in public preview last November and allows users to create a unique form processing model that will extract the same information from up to 100 different document layouts.
様々なレイアウトの文書を使った訓練－この機能は昨年11月にプレビュー機能となったもので、ユーザーは100種類までの異なったレイアウトの文書から全く同じ情報を抽出する独自のフォーム処理モデルを作れるようになります。
Ability to specify the page to be analyzed (available mid July) – Form processing, invoice processing and receipt processing models can now specify a page or page range to be analyzed in the Power Automate action.
解析するページの特定機能(7月中旬から利用可能)－フォーム処理、明細書処理、レシート処理モデルは、解析すべきページやページ範囲をPower Automateのアクションの中で特定することができます。
This is useful to process only the relevant parts of the documents reducing prediction costs.
これは、予測についての労力を削減し、文書内の必要な部分のみを処理するのに有効です。
For additional resources on AI Builder, visit Power Apps and learn how your users can make their apps AI enabled, or go to Power Automate and learn how your users can make their workflow solutions better with AI.
AI Builderへの追加リソースとして、Power Appsでユーザーがアプリをどの様にしてAI利用可能にできるか学んだり、Power AutomateでどのようにAIを用いてワークフローソリューションを改善できるか見てみて下さい。
Please visit our pricing pages to learn more about the AI Builder capacity add-on for your appsand workflows.
アプリとワークフローに使えるAI Builder機能のアドオンについてさらに学ぶなら、価格ページを訪れてみて下さい。
Visit our Licensing page for more information on licenses and trials.
ライセンスと試用についての更なる情報はライセンシングページを訪れて下さい。
Support of additional languages
追加言語へのサポート
We have added the support of new languages for sentiment analysis and key phrase extraction.
新規の言語へ、心情解析とキーフレーズ抽出のサポートを追加しました。
See Language support – Text Analytics Sentiment Analysis and for Text Recognition, see Language Support – Text recognition
テキスト解析による心情解析→言語サポート
言語サポート→文字認識
を参照して下さい。
For text recognition, this also includes some OCR performance improvements.
文字認識には、OCRパフォーマンスの改善が含まれます。
AI Builder leverages Cognitive Services Computer Vision.
AI BuilderはComputer Visionの認識サービスを向上させます。
You can access the list of all languages supported with version 3.2 here – Language support – Computer Vision.
バージョン3.2でサポートされる言語リストはここからアクセスできます。
言語サポート→Computer Vision
Coming soon: Form processing will support documents from these 73 different languages later this summer including Japanese and Chinese.
Coming Soon: フォーム処理は今夏の後半には、日本語と中国語を含む73の異なる言語の文書をサポートします。
Making it easier to use your form processing model in cloud flows
クラウドフローでのフォーム処理モデルの使用が簡単になります。
One popular scenario that customers are using form processing for is to automate data extraction from documents received by email.
顧客がフォーム処理を使用するポピュラーなシナリオの一つが、emailで受けとった文書からのデータ抽出です。
Now, after training and publishing a form processing model and selecting Use model a New flow in Power Automate, you will land in an end-to-end functional cloud flow that will process documents from email attachments.
フォーム処理モデルをトレーニングし、発行して、Power Automateの新しいフローからユースモデルを選択すれば、emailの添付ファイルから文書を処理する、一貫した効果的なクラウドフローに乗り入れられるようになります。
You can test the flow right away to see it in action and then tailor it to meet your business needs.
動作テストがすぐに行え、ニーズに合った形にアレンジできます。
Confidence scores and automatic validation in document automation
文書自動化における信頼性スコアと自動バリデーション
The prebuilt end-to-end solution for automating the processing of documents has been updated with new capabilities to enrich and simplify the pipeline.
デフォルトで実装済みの文書処理自動化の一貫したソリューションはパイプラインの効率を高め、シンプルにするための新機能とともに、アップデートされました。
When the data has been extracted from documents, some basic validation rules are now executed to check empty or not recognized fields and detect low confidence.
データが文書から抽出されるとき、いくつかの基本的なバリデーションルールでは空、もしくは認識されていないフィールドのチェックが実行され、信頼性の低いものを検出します。
In this case, the documents must be reviewed by a human, the confidence of each field being now visible in the validation application.
このようなケースでは、文書は人の手で見直す必要があり、それぞれのフィールドの信頼性はバリデーションのアプリで視覚化されます。
Otherwise, the data extracted can be automatically exported to the target system.
そのほかに、抽出されたデータを自動的に目的のシステムにエクスポートすることが可能です。
Availability in US GCC, GCC High, and Switzerland
※ここはあんまり関係ないので割愛。
Other enhancements
その他の 機能強化
We have improved the export and import reliability of solutions containing models retrained multiple times.
何度もの再トレーニングを受けたモデルに含まれるソリューションのエクスポート・インポートの信頼性を改善しました。
Makers on the tenant’s default environment can now enable AI Builder and Dataverse from the AI Builder home page if missing.
テナントのデフォルト環境にいる作成者はAI BuilderとDataverseが見つからないとき、AI Builderのホームページから利用できるようになりました。
おわりに
AI Builderは全く触れたことがないですし、この先しばらくは触りそうもない気がしますが、なんか未来を感じますねー(適当)
専門用語の訳難しいです。
ニュアンスわかってても、フィットする単語がなかなか出てこない...。
そしてGeneral AvailabilityとProduction Readyの違いがよくわからない。
GAが一般公開決定で、実際に実行状態になるのがPRなのか？？？
と、今回はここまで。
出来るだけ続けていきましょう。
※この記事内容は個人の備忘を目的としています。見ての通り英語力はお察しですので、翻訳自体の信頼性もかなり怪しいです。
この記事を参考にしたいかなる結果も責任は負いませんので、ご了承ください。
正確な情報は原文または公式の翻訳をご参照ください。
Power Apps Blog アップデート。 複数テーブル参照がプレビューになったよ。
最新情報のキャッチアップと、英語のお勉強兼ねて、できる時はPower Platform関連の公式ブログなど各種情報を翻訳してみようと思います。
いつまで続くかわからないけれど。
英語力についてはお察しだし、あくまで自分の備忘用というスタンスなので、もし参照されるとしても、参考程度でお願いします。
内容には一切責任を持ちませんので...
(間違いなど指摘してくださる方がおられましたらありがたいです)
では今回の内容に移っていきます。
元記事はこちら。
https://powerapps.microsoft.com/ja-jp/blog/category/new-features/
ここから翻訳です。
Multi-table lookups, a long awaited and much requested feature, are now live (Preview) for use via API.
待望の、リクエストの特に多かったマルチテーブル参照がAPIから利用可能になりました(プレビュー)。
Multi-table lookups (also sometimes known as polymorphic lookups) allow the creation of a lookup in one table that looks up records in multiple other tables at once.
マルチテーブル参照(ポリモーフイック参照としても知られる)は、複数の他のテーブルから一括してレコード参照しているテーブルに参照をかけられるようにできます。
This provides much greater flexibility in retrieving data within your environments.
これはあなたの環境からデータを引き出す際にさらに大きな自由度をあたえてくれます。
Imagine you are trying to create a lookup that lets you check out media to users.
ユーザーにメディアを見てもらうための参照を作ろうとしていると想像してみて下さい。
You have a table of Books, a table of Audio offerings, and a table of Video offerings.
本の情報、音声、ビデオを提供するテーブルがあるとします。
Prior to this, there was no easy way to create a lookup that would pull data from all three tables at once, and you may end up with three separate lookups:
Checkout-> Books
Checkout-> Audio
Checkout-> Video
この機能が出る以前なら、３つ全てのテーブルから一度にデータを引き出す参照を作る単純な方法は無く、本、音声、ビデオそれぞれ個別の参照をするしか仕方がなかったでしょう。
What if you were searching for both the physical book and audio book for a title you wanted?
気になるタイトルを、本とオーディオブック両方探す場合はどうでしょう。
What if you wanted to find the soundtrack to a movie and a movie?
映画と、そのサントラを探したい場合はどうでしょう？
What if a friend recommended a movie to you but also said the book was great?
友人が映画を勧めてくれ、本も良かったと言っていた場合、どうでしょう？
Looking this data up across multiple tables would require individual lookups, require you to search and populate shared IDs into your checkout table, or write a custom solution.
こういったデータを複数のテーブルを横断して見つける場合、個別の参照と検索が必要で、参照するテーブルには共通するIDを設定するか、カスタムソリューション(フローなどかな？)を記述する必要があります。
With multi-table lookups, you can perform a lookup on 2 or more tables at the same time and locate the record you want from the referenced tables.
複数テーブル参照を使えば、二つ以上のテーブルを一度に参照し、参照したテーブルから対象のレコードを見つけることができます。
These lookups are all 1 to many relationships and will work in a similar way as the Customer lookup that is built into Dataverse, where Customer look ups search both Account and Contact.
これらの参照は全て、一対多のリレーションで、Dataverseに実装された、アカウントとコンタクト両方を検索するカスタマー参照と同様に動作します。
Using these multi-table lookups can reduce development time for your apps and provide a more streamlined user interface.
これらの複数テーブル参照はアプリ開発の時間を削減し、より効率的なUIを提供します。
For the current preview:
Lookups can be constructed and managed through API only
Model driven apps currently provide the best experience with the lookups
Maker UI support for creation and management is coming soon, and improved canvas app support is planned for the future.
現在のプレビューでは、
・参照の構築と管理はAPI経由のみ。
・いまのところ、この参照はモデル駆動型アプリでの体験がオススメです。
・構築と管理における開発者UIサポートは近いうちにリリースです、キャンバスアプリへのサポートも予定されています。
おわりに
訳は以上となります。
複数のテーブルから情報を一括で取って来れるのは便利そうですね！
まだモデル駆動型には手を出していないので、今後のキャンバスへの展開を期待しています♪
Power AppsでSharePoint Listに写真を登録
日々の忙しさにかまけて、ずーっとblogをほったらかしにしてしまっていたが、少し余裕も出てきたので、再開してみました。
アウトプットは基本は自分の備忘録だけど、人に見られるかも、というプレッシャーがある程度かかるので、それなりにちゃんとしたことを書かないといけない、という意識が働くのがいいとこなのだと思う。
できるだけモチベ保って、週1回は更新できるように頑張ろう。
今回のお勉強内容
前置きはさておいて、今回はPower Appsのお勉強。
Power AppsからShare Pointに画像登録、表示するのはいくつかやり方があるけど、今回は添付ファイルコントロールを使用した画像登録のやり方を学んでみた。
まだまだ初学者なので、写経するのが一番勉強になります。
参考にさせていただいたのはコチラ。
Rezaさんはyoutubeに沢山動画をアップされていて、どれも素晴らしいアイデア満載なので、最近はずーっと追いかけて勉強させてもらっています。
え、こんなこともできるの！？っていつも驚いてばかり。
そして解説が理路整然としてめちゃくちゃわかりやすいです。
作ったもの
参考にして(ほぼ丸パクリ+ちょっとだけアレンジ)して作ってみたのがコレです。
カメラコントロールを使用して撮影した写真を添付ファイルとしてSharePointに登録するアプリ pic.twitter.com/V97DS4UUQU
— Kilroy 365 (@KilroyWaaasHere) 2021年7月2日
全体の流れ
テスト作成なので、シンプルな構成にしていますが、全体の流れを図示してみるとざっくりとこんな感じ(細かいことは描き切れていませんが…)です。
今回はきっちり勉強する＆blog用にフロー図を作成してみました。
恐らく何らか正規な書き方があるのだろうけど、自己流で構造や変数などがどこでどうなっているのかを整理して書いてみました。
SwimlaneをScreenに見立てて書きましたが、結構わかりやすかった（自分的には）です。
割と単純でそんなに手順無いアプリですが、細かいところまで図示すると結構複雑に見えますね…。
変数の類
添付ファイルコントロールを使ったメソッドの説明は元動画を見てもらった方が良いと思いますが、肝はコレクションを使った添付ファイルの受け渡し。
添付ファイル格納用のコレクションを用意して、これを受け皿に添付ファイルをあれこれするイメージですね。このアプリではコレクションは一つ。
使用しているシーンは以下のようなとき。
変数もいくつか使っていて、以下のような感じ。
アレンジした点
➀カメラスクリーンの拡大モード
画面にスクリーン大きく表示できた方が便利ですよね。
②登録済み添付ファイルの削除
参考にさせてもらったアプリは登録のみで削除には対応していないとのことだったので、対応させてみました。
そもそも、submitした際に受け渡されるデータは何かというと、添付ファイルデータカードのUpdateプロパティで指定したものなので、これを見てみると、コレクションが指定されていましたが、コレクションの内容を削除してsubmitしても、添付ファイルは削除されないようでした。
ならばと、添付ファイルデータカード内で直接添付ファイルを削除し、これをsubmitするように変更してみると(変数を使って消したい時だけ指定)、うまくいき、添付ファイルを削除することができました。
つくってみて
なかなか良い学びになった気がします。
PowerAppsで簡単に写真撮影・リスト登録ができるので、備品やらスマホ持ってポチポチ登録するのに重宝しますね。
Microsoft 365グループ
Microsoft 365グループってなんぞ？
昨日書いた記事でMicrosoft 365グループにちょっと触れたけど、自分でもちゃんと把握できてるか不安だったので、Docs調べてみた。
対象Docsはこちら↓↓↓
Microsoft 365 グループについて - Office サポート
やっぱりちゃんと理解できてなかったですね～。
作成を開始するツールによってほんのちょっと提供されるリソースが異なるらしい。
Docsに書いてあるけど、あやふやだったので、念のため管理センター開いて確認してみました。
詳細は以下の表のとおり。
PlannerとOnenoteについては管理センターで確認ができなかったのでちょっと怪しいけど、たぶんこんな感じ。
ーで示した分も、後付けは出来るっぽいので、ほぼ変わらない。Sharepointが作成起点として機能するのはチームサイトで、コミュニケーションサイトはM365グループと紐づけできない。
どのアプリをメインに使ってコミュニケーションをとってるかによって作成起点が変わってくる感じですね。
なかなか奥が深い…
チームサイトとコミュニケーションサイト
SharePointのチームサイトとコミュニケーションサイトの違い。
ある程度使ってる人にとっては当たり前の内容だと思うけど、ネットで調べるとコンセプトについて解説が抜けてる説明サイトが意外と多い印象。
初心者的には、最初にサイトを作り始める時点でもうちょい理解できてれば...という内容だったので備忘的に書いていく。
初期設定の権限の違いは大事
個人的に一番重要だと思うのは権限関係。Microsoft365グループと連携できるか否か、それがなぜ違うのか。
ここはサイトを作るにあたって「一番重要ですよ～」、とアナウンスすべき事項だと思う。
自分の場合は下調べが足りず、中途半端な理解のもと手を動かし始めたので、後になって、何でだ？とつまずいた。
結果的にはたまたまコンセプトに沿った作成方法をしていたので助かったが、M365グループとの連携は後から変更することができない。（コミュニケーションサイトはM365グループに紐づけられない）間違っていれば、サイトの作り直しもあり得たので、ちょっと冷や汗をかいた。
チームサイト
さて、チームサイト。
こちらは基本的に365グループと連携する様になっており、Teamsでチームを作成すると背後で自動的に作成されるのもこのタイプ。
365グループで他のアプリとも連携する様にできているあたり、コンセプトはチームでM365を横断的に使って作業するためにあると考えるのが妥当。
チームで作業する用途に特化してる=チーム外に見せたくない作業やファイルをここで扱うという、ちょっとクローズドな感じで運用するやり方がしっくりくる。
コミュニケーションサイト
次は逆にM365グループと連携しないコミュニケーションサイト。目立ったチームサイトとの違いは365グループと連携しないことと、サイドリンクバーが上にあり、横方向にページを広く使えるUIの違い。
上にあるのにサイドリンクバーなのがちょっと笑えるけど、ページを広く使えてウェブパーツを配置しやすくなっているのはデザイン上優位で、ここはコンセプトとして、ページを積極的に『見てもらう』ことにウェートを置いていることがよく表れている部分だと思う。
『見てもらう』ことに重きをおくということはある程度オープンな使い方が想定される。その場で作業をするよりも、参照してもらうために情報を置いておいたり、知ってもらいたいことを表示して情報を拡散する、という使い方が増える。
そうなると、そこにある情報を編集できる人、見るだけの人など、色々な権限を設定して運用しなくてはならなくなってくる。つまり、チームサイトのように単一の権限だけでの運用に適していないため、M365グループとの紐づけを行っていない、ということなのだろう。
UIの違いに見え隠れするメッセージ？
上記のようにチームサイトはチーム内でのクローズドな作業に、コミュニケーションサイトはオープンに情報を扱いたい用途に適してそうです。
2つのサイトの見た目の大きな違いはサイドリンクバーの位置ですが、色々作業をしていると、チームサイトのも上にしてくれ～！って叫びたくなります。全部上に統一しないのは、2つのサイトの差を見た目で明確に認識できるよう、敢えてそうしてるんじゃないかと思います。「クローズドな作業に適したサイトだから、デザイン的に少々融通効かなくても、問題ないでしょ、はっきりわかるように、これは横に残しとこう。」なんていう開発者側の声が聞こえてくるような…。しらんけど。
なお、上記は僕個人の勝手な見解です。いや、そんな使い方ちゃうし、とか、もっとこんな違いがあるで、とかあればぜひこっそりと教えてください。
とりあえず現状を…
ブログをはじめてみたということで、まずはどういうことを書いていくのか、決めてみよう。
書いていく内容は備忘録で、Microsoft365を使い倒していく中で気が付いたこと、学習したことなどをつらつらと書いていくことにする。要するにアウトプット。
幸いなことに、所属している企業は365を導入しているものの、利用はTeamsのチャット程度、昔ながらの紙ベースの作業もかなり多い。ITに疎い上司も、やりたいことをおおまかに説明すると理解は示してくれたので、365を使い倒してどんどんIT化してやりたいと思っている。いまのところは歯止めなくやっていけそうなので、ガンガン使って自分のスキルアップもしていければ。
コーディング等の知識はほとんどなく、エクセルのパワーユーザーって感じの自分がどこまでやれるか、これからが楽しみ♪
