Teams リソース管理機能とは、Gluegent FlowとMicrosoft Teamsを連携し、Gluegent Flowのワークフローからチームサイトの設定・管理を自動的に処理できる機能です。Microsoft 365ユーザーが抱えるTeams チームサイト管理の課題を解決すべく、2024年9月25日より提供が開始されました。

以下がTeams リソース管理機能で追加された自動処理の一覧です。

• 外部ユーザー招待 (Microsoft Entra IDに外部ユーザーを招待する自動処理)
• サイトストレージ上限更新 (Microsoft SharePointのサイトストレージを更新する自動処理)
• チーム作成 (Microsoft Teamsのチームを作成する自動処理)
• チーム更新 (Microsoft Teamsのチームを更新する自動処理)
• チームアーカイブ/復元 (Microsoft Teamsのチームをアーカイブまたは復元する自動処理)
• チーム削除 (Microsoft Teamsのチームを削除する自動処理)
• メンバー追加 (Microsoft Teamsのチームに所有者やメンバーを追加する自動処理)
• ゲスト追加 (Microsoft Teamsのチームにゲストを追加する自動処理)
• メンバーロール更新 (Microsoft Teamsのチームの所有者をメンバーに、メンバーを所有者にロールを更新する自動処理)
• ユーザー削除 (Microsoft Teamsのチームの所有者やメンバー、ゲストを削除する自動処理)
• 有効期限設定 (Microsoft Teamsのチームに有効期限を設定する自動処理)
• 有効期限更新 (Microsoft Teamsのチームの有効期限を更新する自動処理)
• 有効期限削除 (Microsoft Teamsのチームの有効期限を削除する自動処理)

そのほかに、マスターデータを用いたMicrosoft Teamsのチーム一覧を取得する機能が追加されました。この機能を使うことで、チームID、チーム名、チームの説明といったチーム情報を取得し、入力フォームに反映することができます。

Microsoft Teamsとの連携にはMicrosoft Graph APIを使用しています。Microsoft Graph APIとは、Microsoft 365のさまざまなサービスやアプリケーションを操作することのできるAPIです。
例えば、チーム更新自動処理では、以下のようなリクエストを投げています。{id}のところには、チームのIDが入ります。

このリクエストが成功すると、指定したチームIDのチーム名が「Gluegent Team」、チームの説明が「Gluegentのチームです。」というプライベートなチームに更新されます。

以前、Microsoft Graph APIを用いてチームを作成するさまざまな方法にてGraph Exploreやcurlコマンドを用いてチームを作成する手法についてまとめたブログ記事を執筆しました。チーム作成に絞って、Microsoft Graph APIについて説明しているので、そちらも読んでいただけると嬉しいです。

Teams リソース管理機能の開発は、主に、私と同期、先輩エンジニアの3人で行いました。当初は先輩がメインで担当しており、途中から私たちが加わった流れになります。
まず、私たちはMicrosoft Graph APIについての知識がなかったため、Microsoft Graph APIについての調査から始まりました。ドキュメントを読んでみたり、認可や権限についての調査したり、実際にAPIを叩いてみたりして、Microsoft Graph APIについて勉強していきました。Microsoft Graph APIのアクセス許可には委任されたアクセス許可とアプリケーションの許可の2種類があるのですが、この2種類のアクセス許可の違いを理解するのが難しかったです。実際にcurlコマンドでAPIを叩いてみることで、理解が深まったので、実際に手を動かすことの重要性を改めて感じました。
次に、私たちでフロントエンドとバックエンドに分かれてチーム作成自動処理の開発を行いました。私はバックエンド側を担当しました。Gluegent Flowの新機能の開発は初体験だったので、初めて機能が動いたときは嬉しかったことを覚えています。その後は、一人で一つの自動処理を担当していきました。一方で、先輩は認可処理やチーム一覧取得機能など難易度の高い箇所を担当しました。

Teams リソース管理機能の開発はフェーズ1からフェーズ4の4つのフェーズに分けて開発が進められました。以下に各フェーズの主な開発内容について紹介します。

• フェーズ1
  • チーム作成自動処理
  • メンバー追加自動処理
  • ゲスト追加自動処理
  • 有効期限設定自動処理
  • Microsoft Teams認可処理

• フェーズ2
  • チーム更新自動処理
  • チーム削除自動処理
  • ユーザー削除自動処理
  • 有効期限更新自動処理
  • マスターデータを用いたチーム一覧取得機能
  • 同様な処理の共通化
  • ゲスト追加でメールアドレスでも追加できるように修正

• フェーズ3
  • メンバーロール更新自動処理
  • チームアーカイブ/復元自動処理
  • 有効期限削除自動処理
  • チーム作成自動処理におけるチーム作成の保証
  • エラーハンドリング共通化やExceptionの修正

• フェーズ4
  • 外部ユーザー招待自動処理
  • サイトストレージ上限更新自動処理
  • SharePoint REST API認可処理

開発を進めていくうえでやって良かったことについて紹介したいと思います。
まずは、序盤のフェーズの段階でKPTによる振り返りを行ったことです。KPTとは、Keep (継続したいこと)、Problem (解決するべき問題点)、Try (挑戦したいこと)の3つの観点から振り返りを行うフレームワークです。早期に課題点の発見や改善ができたので、スムーズにプロジェクトを進められたと思います。
次に、毎日の進捗報告です。タスクはどこまで進んだのか、どこで詰まっているのかなどの情報を共有することで、それぞれのタスクの進み具合などをチーム内で共有することができました。また、毎日何か進捗を出さなければという意識を持って開発が進められたのも良かったです。
そのほかにも、Backlogに仕様や内容を細かく記載することで検証を進めやすくしたり、Slackの課題スレにccとしてメンションすることで情報を共有することもやっていて良かったです。

開発するうえで大変だったところは、チーム作成自動処理におけるチーム作成の保証です。
最初、チーム作成自動処理にはチームが作成されているかの保証がありませんでした。そのため、チーム作成と有効期限設定の自動処理を連続して設定した場合、チームの作成が確認されていない状態で有効期限設定の自動処理が走るためエラーが発生するという問題が起こりました。これは、Microsoft Graph APIでのチーム作成が非同期処理であったことが原因であり 、チームが作成されたことを確認してから自動処理を完了させる必要がありました。

まず、非同期処理のステータスを確認するAPIがあったので、そのAPIとリトライ処理で問題に対処しようとしました。リトライ回数を何回にするか、待ち時間はどれくらいにするか、どのステータスのときにリトライにするかなど、先輩エンジニア方と相談しながら決め、開発を進めました。しかし、開発を進めていくうちに非同期処理のステータスを確認するAPIで成功とステータスが返ってきてもチームが作成されているとは限らないということが判明しました。そのため、非同期処理のステータス確認に加えて、チームの存在確認の二重チェックをすることになりました。チームの存在確認でもリトライ処理をするので、思っていたよりも複雑な処理になってしまい大変でした。

今回はTeams リソース管理機能の開発の裏側について紹介しました。
Teams リソース管理機能について知らなかった、使ってないという方がいましたら、これを機会に是非使ってみてください！
最後まで読んでいただきありがとうございました！
(Yuito Hayashi)