Microsoft MVPを20年連続で受賞させていただいたのですが、今回 Microsoft TechCommunity のブログで20年を迎えた世界のMVPの紹介記事にコメントを寄稿させて頂き、無事に掲載されました。
最初に受賞したのが20代後半で、そこから今はアラフィフです。なんの派手さも特出した技術があるわけではないのですが、SharePoint を軸に技術を地味にコツコツと追いかけ続けてきたこと自体は誇らしく思っていいかなと思っています。大人になると継続することが大事なんですよね。意外と続かないものですし。
よかったらお手すきの時に私だけでなく各国のMVPの方のコメントを読んでみてくださいね。
MVP Milestone Series: Celebrating MVPs Achieving their 20+ Year Milestone | Microsoft Community Hub
ソフトクリエイト社のイベント「情シス Update Day 2024」が2024年12月5日に開催されます。去年に引き続き今年もこのイベントで登壇させていただきます。
イベントのキーノートは日本マイクロソフト社の西脇さんです。
私の方はスペシャルセッションとして「Microsoft 365 Copilot を使った組織ナレッジの活用」について話をします。
[イベントの概要]
ご興味をお持ちの方は、事前申し込みが必要ですので下記のリンク先からどうぞ。
SharePoint ドキュメント ライブラリ内に作成するフォルダーは検索でヒットしにくいのをご存じでしょうか?
実はフォルダーは検索エンジンが必ず言語を英語として判定します。そのため英語圏のユーザーは問題ないのですが、それ以外の言語圏では不利になります。
試しに SharePoint Search Query Tool で検証してみましょう。このツールは下記の場所から入手できます。
https://github.com/pnp/PnP-Tools/releases
検証のためにあらかじめ「中秋の名月」というフォルダーを作成しているのですが、これを検索するために「中秋* ContentType=フォルダー」というキーワードで検索します。すると、検索結果からDetectedLanguage という管理プロパティの値が “en” になっていることがわかります。これは英語を意味します。DetectedLanguageはフォルダー、アイテム、ファイルなどを検索エンジンが解析する際の言語判定の結果です。通常はファイルなどであれば、日本語として判定するのですが、フォルダーに関して例外で必ず “en” 判定です(昔から)。
本来であれば、日本語判定されて日本語として単語分割が行われて、検索インデックスに単語が登録されていくはずなのですが、日本語のフォルダー名を英語判定されていますから英語のルールで解釈しようとするとうまく単語登録ができないはずです。
実際に、単に “中秋の名月” と検索するとヒットしません。そのためワイルドカード検索をするとヒットしやすくなります。例えば、「中秋*」というように「中秋～」で始まるコンテンツを検索するようにするわけです。さらにフォルダーのみを検索したい場合は「ContentType=フォルダー」という検索キーワードを指定すると、簡単に絞り込めます。実際に試しているので次のビデオを確認してみてください。
[SharePoint 豆知識]
— HIRANO Ai | MVP 👉 ❤️ SharePoint (@ai_yamasaki) October 30, 2024
SharePoint のドキュメントライブラリにフォルダーを作ると、あれ、検索エンジンは必ず "en" で判定する。つまり英語だと判定するので、日本語検索があまりうまくいかない(英語で単語分割しようとする)。これがフォルダーの多用はあまり勧めない理由のひとつ。… pic.twitter.com/eZrnFKstGA
では、英語でフォルダー名をつければうまく検索できるのかという話がありますが、その通り。わざわざアスタリスクで工夫しなくても、単語でズバッと検索できます。フォルダーの命名ルールが英語なら検索のもどかしさはないはずです。
じゃ、フォルダー名が英語なら検索がしやすいの? というコメントをいただきましたが、その通り。ばっちり検索できます。 pic.twitter.com/8Zq9CbMnhY
— HIRANO Ai | MVP 👉 ❤️ SharePoint (@ai_yamasaki) October 30, 2024
なお、フォルダーを多用せずに適切にサイト、ライブラリを分けておくことが重要であることは忘れずにいてください。ライブラリ1つで、その中にフォルダーを複数作成するのは利便性があまりよくありません。ファイルサーバーとは考え方が異なります。
なお、Microsoft 365 での効率的なドキュメント管理を考えている方はぜひ弊社のオリジナル研修をご受講ください。エンタープライズ検索の概念や検索の仕組みを一から学べます。オンプレサーバー時代からの検索の知見を含めてあれこれ説明するので、知らない情報がたくさんあるはずです。ブログや書籍にも載せていないものも多いので。
【オフィスアイ株式会社】Microsoft 365 ユーザーのための検索基礎
ファイル管理の研修とセットでご受講いただくと、ファイルを見つけやすくするドキュメント管理戦略にも役立ちます。併せてご検討ください。
SharePoint モダンサイトサイトのショールーム的に利用されてきた Microsoft SharePoint の Look book サイトは従来は以下のURLでアクセスできていました。
lookbook.microsoft.com
ですが、これが実は 2024年6月にひっそりとシャットダウンされています。その代わり新しい SharePoint ルックブックサイトが用意されており、こちらは日本語化もされています。
https://aka.ms/SharePointLookBook
Power Automate を使って複数の Excel ファイルを一括生成し、それぞれの Excel ファイルで特定のOffice Scripts を実行するようにフローを組んでいたとします。Office Scripts を実行するわけですから、 Excel Online (Business) コネクターを使います。このコネクターには次の2つのスクリプト実行アクションがあります。
このコネクターに最初に追加されたのは「スクリプトの実行」であり、スクリプトはユーザーの OneDrive に格納されている前提でした。ですが、そのあと、スクリプトを SharePoint のドキュメント ライブラリに格納して複数ユーザーで共有利用ができるようになりました。そこで新たに追加されたアクションが " SharePoint ライブラリからスクリプトを実行する" です。
さて、従来からある "スクリプト実行" アクションは、スクリプトがOneDrive (Business) に格納されていることが前提であるため同時アクセスは考慮されていません。
たとえば、ファイル作成をする際に Apply to each を使って処理するときに Apply to each には「コンカレンシー制御」オプションがあります。既定ではオフで最大50まで指定できます。
これを使えばファイル作成をバトンリレー式に1つのファイルが作成されてから次のファイルを作成するという処理を複数のファイル作成を同時に一斉作成できるようになります。ならば、このオプションを有効にしてファイル作成後にいっきに各ファイルで Office Script も動かそうか考えるわけですが、この場合はスクリプトファイルへの同時アクセスが生じることになりフローはエラーとなります。
ですが、後発のアクションである「SharePoint ライブラリからスクリプトを実行する」を利用する場合は、最初から複数同時アクセスを考慮しているため Apply to each のコンカレンシー制御を有効にしても問題なくフローが実行できます。
試しにコンカレンシー制御をおこなわずに5つのファイルを一括作成してみたところ、Apply to each には42秒ほどかかりました。
ですが、コンカレンシー制御を有効化したところわずか9秒に短縮されました。
このようにコンカレンシー制御はフローのロジックによって向き不向きがありますが、うまく活用できればフローの実行時間が短縮できます。