カテゴリ「Microsoft 365 - SharePoint」の386件の投稿 Feed

2020年7月 9日 (木)

ご存知の方も少なくないようですが、タイトルにある通り SharePoint 2010 ベースのワークフローエンジンが利用できなくなります。といっても SharePoint Online の話で、オンプレミスとは状況が異なるので注意してください。

SharePoint 2010 ワークフローエンジンを使うワークフローは、早急に Power Automate もしくはその他のソリューションに切り替えていく準備をしておく必要があります。とはいえ、全く同等にフローが作れるわけではないのが、なかなか悩ましいところではあります。

Microsoft 社からの公式情報は次の通り。

「Support update for SharePoint 2010 workflows in Microsoft 365」

Sp2010WF engine retired - 01

「SharePoint 2010 workflow retirement」

Sp2010WF engine retired - 02

SharePoint 2010 ワークフロー エンジンとは何か?

SharePoint 2010 ワークフローエンジンと聞いて、ピンとこない方のために、少し歴史的背景をご紹介しましょう。

SharePoint はワークフロー機能を持っています。SharePoint Portal Server 2007からこの機能を利用して承認フローなどを構築できるようになっています。このワークフローを支えているのがワークフローエンジンであり、SharePoint Portal Server 2007 および SharePoint Server 2010ではワークフローエンジンを SharePoint 自体が内包してきました。

SharePoint Portal Server 2007では 2007用のエンジン、SharePoint Server 2010 は 2010 用のエンジンをそれぞれに持っています。それぞれをベースとしたワークフローテンプレートも用意されており、サイトコレクションの機能(フィーチャー)にそれぞれのテンプレートの有効化を行う機能があります。

たとえば、SharePoint 2007 用は次の機能をアクティブ化すると利用できるようになっています(といっても、古いのでもう Online では使っているところはないと思います。今のところ SharePoint Online でも設定は名残として残っていたので参考までに掲載しています)。

Sp2010WF engine retired - 03

SharePoint 2010 のエンジンを使ったビルトインのテンプレートを利用するときは次の「ワークフロー」機能をアクティブ化します。

Sp2010WF engine retired - 04

この機能をアクティブ化するとリストやライブラリにビルトインのワークフローテンプレートを追加して利用できるようになっています。

Sp2010WF engine retired - 01

ビルトインのテンプレートは次の通りであり、フィードバックの収集、署名の収集などがあります。

Sp2010WF engine retired - 05

 

ただし、このエンジンはSharePoint 内で動作していたこともあり、スケーラビリティに欠けるなど課題も見えてきました。そこで SharePoint Server 2013 からは従来の SharePoint 2010 エンジンも利用できるようにしつつ、新たなエンジンとして SharePoint 2013 エンジンを提供し始めます。これは SharePoint 内に含まれてはおらず、別途 ワークフローエンジン用にサーバーを構築してエンジンをインストールする必要がありました。要するに、エンジンが外付けされることになったわけです。これによってスケーラビリティの問題なども解消できるし、従来組めなかったフローロジックも組めるようになるなど恩恵はあったものの、SharePoint のアクセス権限設定が柔軟に設定できないなどの問題も抱えていました。そこで、SharePoint 2013 エンジンと SharePoint 2010 エンジンを組み合わせて、互いのいいとこどりをするようなフロー構築もできるようになっています。

このような背景の中、SharePoint Server 2010 以降では SharePoint Designer 使った独自のワークフロー開発なども盛んにおこなわれました。ちなみに、SharePoint Designer 2013 で独自にワークフローを作るときには、どちらのエンジンをベースにフローを作るのかを選んでから作成するようになっています。

Sp2010WF engine retired - 06

 

SharePoint 2010 および 2013 ワークフローエンジンは今後どうなるのか?

ここまでの経緯で SharePoint 2010 ワークフローエンジンとは何かがある程度、把握できたと思います。

今回 Microsoft からのアナウンスによると、SharePoint 2010 ワークフローエンジンを使ったフローは次のような段階を経て、利用できなくなります。

  • 2020年8月1日から、SharePoint 2010 ワークフロー群は、新たな作成されたテナントに関しては利用できなくなる
  • 2020年11月1日から、既存のテナントから SharePoint 2010 ワークフローの実行および作成機能の削除を開始する

SharePoint 2013 エンジンに関しては利用は非推奨とはなるものの、引き続きサポートされるとのこと。2020年11月以降、新規テナントでは SharePoint 2013 ワークフローエンジンの利用も既定ではオフにされます。ただし、必要があれば PowerShellスクリプトを使って SharePoint 2013 ベースのワークフローをアクティブ化できるそうです。

またオンプレミスの SharePoint 2016 と 2019 サーバーに関してはどちらのエンジンも 2026年までは引き続きサポートされます。

最後に、これからに備えて

以上のように今から10年前に登場したエンジンも終焉を迎えることとなりそうです。既に組織内でこうしたフローを使っている場合は早急に確認をし、対応を考える必要があります。SharePoint の開発コミュニティがモダン化対応をチェックするためのツールとして「 SharePoint Modernization Scanner 」をオープンソースとしてGitHub に公開しているので、まずはこれを使ってフローの洗い出しをしましょうということのようです。ただし、今日もちょうどSharePoint モダンポータルの研修を実施しており、このツールの話をするのですが、このツールは実は SharePoint Online の管理者、つまり組織全体の管理者でないと設定できない部分があります。この部分が少しネックになるかもしれません。大企業だと複数のグループ企業を抱えていますが、要するに親会社側でないとこれらの設定ができないので手軽に試せるとは限らないのです。これに関しては、各組織でうまく連携を取る必要があるでしょう。

それから、今あるフローをそのままPower Automate やその他のサービスに移行しようと考えるようとしているのであれば、ちょっと待ってください!

日本の組織では大抵の場合、その対象が「承認」フローだと思います。是非、次のことを考えてみてください。 

新型コロナにより仕事の仕方も大きく変わってきていて、さらにこうした大きな変化の節目でもあります。この際に可能な限り業務を見直して、本当にそのフローが必要なのか組織内で議論をしてみてはいかがでしょうか。絶好のタイミングとみることもできるかもしれません。

「その承認は本当に必要なのか?」

いろんな方に話を伺うと、フローを作る側の人は、少なからずそう感じているフローがあるようです。

もしかしたら、紙の判子で書類を回していたころから、引き続き今までやってきたからという理由で続けているところはありませんか? 団塊の世代が活躍していたころからあるプロセスだったりしませんか? だとしたら一度見直す時期では? そもそも、その承認プロセスは形骸化していなませんか?

この人手不足の中、少ない人材でいろんな仕事を効率よく捌く必要があります。見直すタイミングも必要ではないでしょうか? 年功序列で、先輩後輩の関係があり、先輩は無茶もいうけど、後輩の面倒もよく見てくれていたという義理人情もまだまだあったころは、承認プロセスには責任の所在を明らかにするとともに、本当に責任もとっていた方々も少なくなかったのではないかと想像しています。ですが、責任の所在といっても形式だけになっていませんか?  承認以外にもやりようがあるかもしれません。本当は迅速な情報の可視化が必要なのに、人海戦術でチェックするために承認フローをつかっていたりしませんか? そうなると場合によっては、承認ではなくて業務プロセスをスムーズに進めることに時間とお金と労力をかけていきたい。

もちろん、承認が不可欠な業務があるのは事実ですが、見直しは必要だと感じています。

業務プロセスを見直しながら、プロセスをより効率よく進めていけるように Power Automate を使って自動化できる部分は自動化することを考えてみてはいかがでしょうか? Power Automate = ワークフロー = 承認と考えている方が、(特に SharePoint ユーザーでは) 結構な確率でいらっしゃると思いますが、そうではありません。Power Automate が真価を発揮するのは、これまでになかった AI との連携やチャットボット連携なども含む、新しい切り口で業務を支援できるポテンシャルを持っています。

そして、Power Automate を独学で学ぶ十分な時間がなかなか取れない方は、是非弊社の研修もご利用ください(最後は宣伝もかねて)。

2020年7月16~17日に初回実施となりますが、「業務効率を向上させる Power Automate 実践演習 (OH-O365-205)」は Power Automate をちょっと触ってみたけど、もう一歩、詳細なフローが組めるようになりたい方向けの中級レベルの方向けの研修内容になっています。Power Automate を使ったフローの移行を考えいる方に最適です。

 

 

 

2020年6月30日 (火)

Microsoft 365 Virtual Marathon セッションの録画公開されています。

全14本の日本語セッションはリストにまとめられており下記のリンクからアクセスできます。

Microsoft 365 Virtual Marathon - 日本語セッションリスト

SharePoint だけでなく、Microsoft Teams や Power Platform などもあります。

上記は日本語セッションだけですが、そのほかにも各言語で 400セッションを越えるセッションの録画が公開されています。

世界中の Microsoft 365 のプロが登壇しているので、どの内容も非常に有用です。英語が得意な方はもちろん、不得意な方も字幕を表示しながらセッションを閲覧してみてはいかがでしょうか。

私が担当した「SharePoint モダンポータル徹底解説! 」は下記の通りです。

よりじっくり学習したい方へ

ポータル構築の詳細をより詳しく知りたい、直接、講師に質問したいという方は弊社の下記セミナーのご受講もご検討ください。

【研修】SharePoint モダン ポータルサイトの設計・デザイン・展開ワークショップ

AdobeStock_194043476この研修を受講することで Microsoft Teams や Yammer などのチームワーク基盤全体を視野に入れながら、モダンサイト全体構成の設計ができるようになります。

 

2020年6月26日 (金)

ライブラリ内に画像ファイルのサムネイル表示をする列を簡単に作れます。

※2025/6/24 修正 --- 対象は画像列だけになったようです。

任意の列を追加し、名前を "Thumbnail" とするだけです。これだけで自動的にサムネイルが表示されます。私が試したのは、「一行テキスト」、「複数行テキスト」、「画像」などです。

画像列を追加し、名前に英語で "Thumbnail" と入力するだけです。

20250624_214222

これで列に画像のサムネイルが表示されます。

20250624_214245

サムネイル部分をクリックするとファイルをローカルにダウンロードします。

サムネイル部分をクリックすると画像を拡大表示できます。

2020年6月23日 (火)

Chrome の新機能を解説する記事を見つけました。最新の Chrome の拡張機能であり、「Link to Text Fragment (文字断片へのリンク?)」が利用できるようになっているというものです。この機能を利用するとWebページ内の任意の文字列に直接リンクできます。

当然 Chrome ベースの Edgeでも対応しています。Chrome を利用している方は試してみると面白そうです。リンク先のページ内で「ここを見て!」と思う部分の文字列をURLの末尾に渡してやることで、ページにアクセスしたときに指定した文字列部分に直接アクセスでき、かつ文字列がハイライトされます。

具体的にはURLの末尾に "#:~:text=" を追加し、リンクさせたい文字列を渡してやります

Chrome-Text-Deeplink

Chrome または最新の Edge を利用している方は、実際に試せます。たとえば、次のリンク先にアクセスしてみてください。私の過去のブログ記事ですが、このページの "mhtは実際には使われておらず" と書かれている部分が直接表示されます。

https://shanqiai.weblogs.jp/sharepoint_technical_note/2020/06/microsoft-teams-wiki.html#:~:text=mhtは実際には使われておらず

前提条件

この機能が利用できるのは、Chrome の version 80 以降。任意のOS上でデスクトップ版の Chrome と Android 上の Chromeのみ。対応していないブラウザーを利用していても "#" は URI フラグメントとしてサポートしているものがほとんどであるため(よくアンカーリンクとして利用している)、この機能をサポートしていなくても無効なアンカーリンクとして無視されるようになっています。ちなみに、渡す文字列に空白スペースがある場合は %20 に置き換えて表現する必要があります。が、この辺は SharePoint を使っている方ならおなじみのところですね。

SharePoint でも動作する?

SharePoint サイト上でも利用できるかどうか確認しましたが、うまく動作していますね。

Chrome-LinkToTextFragment-SharePoint

こうした機能は知っておくと、ちょっとさ便利かも。

 

 

2020年6月22日 (月)

SharePoint ドキュメント ライブラリ内には URLファイルを作成できるようになっており、別の場所にあるファイルへのリンクを追加することが可能です。

リンク

一見すると便利な機能ですが検索に関しては要注意です。

このリンクファイルは検索エンジンが "英語" ドキュメントとして解析してしまうためファイル名が日本語(英語以外)だとうまく検索できません。また、あくまでライブラリ内には実体は存在しないため、全文検索しようにもできないわけです。