SPClientCore 3.9.0 を公開しました。
SPClientCore は PowerShell Core 向けの SharePoint Online 管理モジュールです。
変更に関するコマンドレットを追加しました。
提供されているコマンドレットの数は 261 になりました。
Microsoft Teams と Azure DevOps でリモート スクラム開発を実現する
本記事は Microsoft MVP ブログ企画の記事として投稿しています。その他の記事はこちらからご覧ください。
このブログにもスクラムの資格を貼り付けてありますが、会社ではアジャイル コーチのロールを行っています。今回は、この COVID-19 の状況下で実際にスクラム開発を行った経験を踏まえて、どのようにリモートでスクラム開発を実現したかという話をしたいと思います。
2020 年 1 月からアジャイル コーチとして参画しているプロジェクトでは、中国でのオフショア開発をすることになっており、リモートが前提でした。とはいえ対面のコミュニケーションがないと難しいことは過去のオフショア開発の経験からわかっていたため、日本のメンバーが中国に 1 週間ほど滞在して対面でのコミュニケーションを取る想定でした。しかし、COVID-19 の影響で、会社として海外への渡航は禁止となり、また、中国のメンバーも自宅勤務を強いられることとなりました。その後ほどなくして日本でも自宅勤務となりました。中国と日本でロケーションが別になることは想定していましたが、日本のメンバー同士、中国のメンバー同士が直接コミュニケーションを取れないという自体は想定していませんでした。
そこで活躍したのが Teams です。Teams が提供する多彩な機能については詳細は述べませんが、チャネルでの情報共有や一対一のチャット、あるいはビデオ会議といった、複数のコミュニケーション方法がひとつのアプリで完結するというのは便利でした。
スクラムの重要なタイムボックスのイベントとして、デイリー スクラムというのがあります。開発チームはそれぞれ 3 つの事柄 (昨日やったこと、今日やること、困っていること) を共有するのですが、事前に OneNote に 3 つの事柄を書いておいてもらって、みんなで見ながら進めるとスムーズにできました。対面であればホワイトボードに書いていけばいいのですが、リモートではそういった工夫も必要になります。
スクラムではドキュメントは最低限にするという考え方がありますが、リモートでコミュニケーションが十分に取れないような場合は、ドキュメントはある程度書いておいて、画面共有で説明をしながら情報を共有したほうがよい場合があります。その場合もあとで参照できるようにファイルの場所をチャネルに投稿しておけば済むので簡単です。
チーム内でのやりとりにメールを使う機会はほとんどなかったと思います。
スクラムのプロセス自体を支援するツールとしては Azure DevOps があります。Azure DevOps にはいくつかのプロセス テンプレートがありますが、一般的なアジャイルだけではなく、スクラムに最適化されたテンプレートがあるのが魅力です。
ちなみに会社ではこのスクラム テンプレートをさらに改良した独自のテンプレートがあったのでそれを採用しました。
また Azure DevOps ではスクラムを支援するためのいくつかの拡張があります。例えば、プロダクト バックログ アイテムの見積もり方法であるプランニング ポーカーをするための Estimate というツールや、レトロスペクティブを行うための Retrospectives というツールがあります。*1
Azure DevOps の Boards は慣れていない人には使いづらく、Excel でやりたいというメンバーがいたのは事実です。ただ、やはりそこは結局慣れの問題なので、多少の不満があったとしても、使い続けてもらうというのが大事です。全般的なコミュニケーションは Teams で取っているので、Boards の中の Discussion で会話をするのは情報が分散してしまう煩わしさがあるのですが、それも慣れの問題なのかなと思います。
あと Test Plans で画面ショットが簡単に取れる Chrome 拡張があるのですが、なぜか中国のメンバーから使えないということがわかりました。これは中国特有の事情なのかどうかはわかりませんが、使えていればもっと生産性が上がったと思うと残念でなりません。
今回のプロジェクトではアジャイル コーチとして関わっており、プロジェクトを外から見ていた立場であるので、プロジェクトを実際に進めていたメンバーとは感想が異なるかもしれません。スクラム チームの習熟度の課題などはまだ残っているのですが、少なくともリモート ワークが強制されるという状況の中で、スクラムを進めていくということについては、うまくできたのではないかと思っています。
*1:Retrospectives は一時期なくなる話があったのですが継続して開発されるそうです。よかったですね！
SPClientCore 3.8.0 を公開しました
SPClientCore 3.8.0 を公開しました。
SPClientCore は PowerShell Core 向けの SharePoint Online 管理モジュールです。
SharePoint Webhook に関するコマンドレットを追加しました。
また、Connect-KshSite に Cached パラメーターを追加しました。これによりキャッシュされた前回のログイン情報でログインできるようになりました。
提供されているコマンドレットの数は 260 になりました。
SharePoint Framework の分離された Web パーツを使ってみる
SharePoint Framework 1.8.0 から分離された Web パーツという機能が使用できるようになっています。
リンク先の説明を読んでいただければわかるのですが、簡単な説明をすると、分離された Web パーツは以下の 2 つの機能を持ちます。
- Web パーツに専用の Azure Active Directory のアプリケーションが作成されます。通常の Web パーツでは Microsoft Graph や Azure Active Directory で保護された Web API へのアクセス許可はテナント レベルで共有されます。しかし、これだと特定の Web パーツ向けに作成した Web API が他の Web API から呼べてしまうというセキュリティの問題を抱えることになります。その問題を解決するため、アプリケーションを分離し、独自のアクセス許可を与えることができるようにします。
- Web パーツは iframe に埋め込まれ別のドメインで動作します。これはかつての SharePoint ホスト型アドインの表示方法と同じと考えることができます。別のドメインで動作しますが SharePoint REST API の呼び出しは通常通り行えます。
分離された Web パーツはスキャフォールディングのときに指定できます。
? Will the components in the solution require permissions to access web APIs that are unique and not shared with other c omponents in the tenant? (y/N)
または package-solution.json で isDomainIsolated を true に指定します。
注意点として、Web パーツはサイト コレクションのアプリ カタログにはデプロイできません。テナントのアプリ カタログにデプロイする必要があります。
実際に Web パーツをデプロイしてみます。
SharePoint 管理者ポータルには「分離」としてアクセス許可の承認ができるようになっています。
Azure ポータルからアプリケーションが作成されていることが確認できます。
F12 開発者ツールで見ると Web パーツが iframe 内に表示されているのがわかります。
iframe になることで表示のパフォーマンスは劣化します。そのため、カスタムの Web API を使う場合のみ、この機能を有効にするといいと思います。