この記事はMicrosoft Power Automate Advent Calendar 2022 カレンダー2の6日目です。
ここではPowerAutomateを使って社内の開発チームのワークフローを少しだけ改善した話をします。
前提となる状態
- 社内のコミュニケーションにはMicrosoftのTeamsを採用している
- 開発チームは課題（issue）をBacklogで管理している
- ビジネスサイドの別チームはBacklogの扱いに慣れているチームもあれば、
慣れていないチーム（Backlogを使ったことがないチーム）もある
まずこんな状況がありまして...
＜Aさん＞
システムのこの部分うまく動いてないみたいだから開発チームに修正を依頼しなきゃ。
普段、他のチームとはTeamsでコミュニケーションとってるから、
開発チームに対する修正依頼も同じようにTeams上で投げちゃっていいよね。
え？Backlog？なにそれ？
＜Bさん＞
システムのこの部分うまく動いてないみたいだから開発チームに修正を依頼しなきゃ。
普段から開発チームへの依頼に関してはBacklog上で進捗を管理してもらってるので
今回もBacklog上に課題を作って進めよう。
＜開発チーム＞
依頼がいろんな方面からバラバラに来て困る・・・。
タスクは全部Backlogで一元管理しておきたいなぁ・・・。
開発チーム的には（本当は）こうしたいが...
＜開発チーム＞
Aさんに頼んで今後はBacklog上で依頼を出してもらうようにお願いしよう。
これでタスクをすべてBacklogに集めることができて管理しやすくなったぞ。
＜Aさん＞
なんか新しいツール増えた・・・。
Teamsですぐ連絡とれるのになんでわざわざ別のツール使わないといけないんだろう。
使い方よくわからないし、めんどくさいなぁ。
そんな時はこうしよう
＜Aさん＞
今まで通り開発チームへの依頼はTeamsで行うよ
＜Bさん＞
今まで通り開発チームへの依頼はBacklogで行うよ
＜PowerAutomateくん＞
Teamsに来た作業依頼は自動でBacklogに流すよ
＜開発チーム＞
課題が全部Backlogに貯まってくれるから管理が楽になったよ
この話のポイント
この手のワークフローを考える時、人とツールとの心理的距離を考えるのってめっちゃ大事、と個人的には思ってます。
開発チームやBさんは普段からBacklogを常用する立場にあるためツールとの心理的距離が近い一方で、AさんにとってBacklogという新しいツールは心理的な距離が非常に遠い。AさんにBacklogを使ってもらうよう促すことは簡単ですが、この距離感の違いを考慮に入れておかないと、大抵の場合運用がワークしません。
元々「●●というツールを使って何かをする」という行為自体が、その人の日々の業務フロー（習慣といってもいいですが）の中に存在しない場合、それを新たにフローの中にねじ込むというのはコストが高いものです。それが毎日使うことになるツールなら慣れるのも早い（＝習慣化ができる）のでそれほど問題にはならないかもですが、月に数回しか使わないとかなら特に難しい・・・。
もちろんトップダウン的に、2番の例のようにエイヤで組織全体に統一したツールの導入を促すことが必要なこともありますが、ボトムアップ的にやるなら、双方が慣れているツール（インターフェース）は変えずに、裏側でその間をPowerAutomateのような自動化ツールでつなぐという視点もWin-Winの関係を築くためには大事かなと。
このあたりの最適解は組織文化にもよると思いますが ^^;
実際にどうやるか
タイトルが「ライトな使いどころ」なのでライトに２ステップだけで行きます。
外部からBacklogに課題を登録する場合、APIを使う方法とメールで課題登録する方法と2通りがあります。より柔軟にできるのはAPIですが、単にTeamsで投稿された内容をBacklogにコピーするだけであれば、メールでの課題登録でも事足ります。
①Backlogの設定
プロジェクト設定 -> インテグレーション -> メールによる課題登録
「課題登録用メールアドレスの追加」でメールアドレスを発行します。
②PowerAutomateの設定
今回はあるTeams上の特定のチャネル（開発チームへの依頼用のチャネルを想定）に新しくスレッドが投稿された時に、その内容をそのままBacklogへ登録することを考えます。
フローは最低限以下の２つだけ。
- 「チャネルに新しいメッセージが追加されたとき」で対象のチャネルを選択
- 「メールの送信」で宛先に①で発行したメールアドレスを指定し、件名・本文にチャネルに投稿された内容（件名・本文）をセット
もしAPIでやるなら、メールの送信の部分をHTTPの送信とかに変えてBacklogのAPIの形式に合わせてリクエストしてやればいけると思います。
まとめ
結局やってることは単純で、双方のインターフェースを変えることなく、あるプラットフォーム上のデータを別のプラットフォームのデータにトランスフォームしてるだけです。なので、今回はTeams→Backlogの連携を例に取りましたが、どんなツールに置き換えても同じパターンが適用できると思います。
使用するツールの違いによりチーム間での運用がうまくいっていない、とか、チームごとにワークフローがサイロ化していて統一が難しい、という場合の参考になれば。