Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2024.1.20気ままに勉強会#75
Search
kobatch
January 20, 2024
Programming
0
3.4k
2024.1.20気ままに勉強会#75
組織全体にScaleさせたいフローに実装するべき工夫についてまとめてみた。
kobatch
January 20, 2024
Tweet
Share
More Decks by kobatch
See All by kobatch
2024.10.26_Power_Platform_Administrator勉強会#2
takafumikobayashi
1
160
2024.3.13霞が関の中心でCryptoをさけぶ
takafumikobayashi
0
20
Other Decks in Programming
See All in Programming
Introduction to kotlinx.rpc
arawn
0
760
How mixi2 Uses TiDB for SNS Scalability and Performance
kanmo
40
16k
生成AIで加速するテスト実装 - ロリポップ for Gamersの事例と 生成AIエディタの活用
kinosuke01
0
120
Rails アプリ地図考 Flush Cut
makicamel
1
130
技術を改善し続ける
gumioji
0
120
負債になりにくいCSSをデザイナとつくるには?
fsubal
10
2.6k
From the Wild into the Clouds - Laravel Meetup Talk
neverything
0
140
はじめての Go * WASM *OCR
sgash708
1
100
Unity Android XR入門
sakutama_11
0
180
仕様変更に耐えるための"今の"DRY原則を考える
mkmk884
9
3.2k
Open source software: how to live long and go far
gaelvaroquaux
0
660
Flutter × Firebase Genkit で加速する生成 AI アプリ開発
coborinai
0
170
Featured
See All Featured
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Git: the NoSQL Database
bkeepers
PRO
427
65k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Faster Mobile Websites
deanohume
306
31k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Why Our Code Smells
bkeepers
PRO
336
57k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
GraphQLとの向き合い方2022年版
quramy
44
14k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Transcript
2024.1.20 気ままに勉強会#75 コバッチ@tariki-code 組織全体にScaleさせたい フローに実装するべき⼯夫 についてまとめてみた。
⾃⼰紹介 コバッチ(kobatch) 2023.04〜某⾏政機関にてDX推進に従事 個⼈事業にてNPOの事業‧デジタル化伴⾛⽀援(他⼒code) (その前は) 暗号資産StartupにてトレードアプリのPjM‧MGR ⽩い⽝の携帯電話会社にてエンジニアリングMGR 👆に買収される前の通信ベンチャーでエンジニア Node.js+Vue, React
/ Java / .NET / SQL プロジェクトマネージャー(IPA) ⽇本美を発信するプチ?インフルエンサー(Instagram) ※Power Platformはピカピカの1年⽣ https://bit.ly/2X2b5s4 @kobatch_tk takafumikobayashi
前提となるフロー Teamsの「作成ボックスから(V2)」のトリガーでフロー起動。 ユーザーが起動したGroupChat or Team参加メンバーより送りたい相⼿を指定。 指定した相⼿をメンションし、AdaptiveCardでランダムにデザインされた感謝のカードが投稿できる。 アイコンは指定されたカテゴリからランダムで選択。(プロフィール画像も⼊れられる) 実⾏権限がある⼈であれば誰でもどのGroupChat、Teamでも投稿することができる。 ThanksCard(サンクスカード) イラストアイコンはAI謹製
何が出るかはお楽しみ お好みでプロフ画像も指定可能 ??
具体的な使い⽅ フォームが⽴ち上がり 贈りたい⼈やメッセージなどを指定 実⾏したGroupChat or Teamにカードが投稿される Workflowsを起動してフローを選択
フローの特性 簡単に⾔えば...たくさんの⼈に使ってもらいたい ThanksCardのミッション 感謝と賞賛をオープンにし合える⽂化を作り、組織のワークエンゲージメント向上に寄与する。 →Scaleしてもユーザー毎の違いに影響されず、サービス品質と効率を低下させない実装とは? 単独で利⽤ 複数名 orチームで利⽤ 組織を横断して⼤⼈数で利⽤
実装に際して気になったポイント ①実⾏権限管理 積極的にたくさんの⼈に使ってもらいたいのに、いちいち依頼もらって 権限付与するなんてお互い⾯倒、他のやり取りを作りたくない。 ②バリデーション メンションを⼊れるためUPNを指定してもらいたいが、⼊⼒ミスや当該 GroupChat or Teamにいない⼈を指定されることがあるかも。 ③プロフ画像取得
そもそも設定している⼈、していない⼈がいる。設定していても画像サ イズが⼤きいと、AdaptiveCardの制約(28KB)を超える可能性も。 ④エラーハンドリング いつどこで誰が実⾏するかわからない、実⾏エラーがあった事をリアル タイムに知り、適切な措置が取れるとサービス品質が上がる。
①実⾏権限管理 対象フローの「実⾏のみのユーザー」にてTeamを指定。 これによりTeamに参加することでフローを⾃動的に利⽤可能となる。 反対にTeam退出で⾃動的利⽤不可となる。 別途依頼をもらって権限付与するなどの対応や管理を不要とした。 Teamへの参加‧退出と連動させることで⾃動付与‧剥奪 ThanksCardのシェア⽤Channelや Q&Aなどフロー活⽤のためのコミュ ニティの場とするTeamを準備
「実⾏専⽤のユーザーによって提供されました」にする Teamsの実⾏ユーザー これによりフローを実⾏したユーザー権限でTeamsの処理が ⾏われる。 すなわち、実⾏者が参加している任意のGroupChatやTeam での投稿が可能となる。反対に「この接続を使⽤する」にす ると指定した接続ユーザー(すなわち作成者)の参加範囲で しか投稿ができなくなる。
②バリデーション(宛先のUPN指定) AdaptiveCardのInput .ChoiceSetにchoices.dataにて データセットを指定する。 これにより、実⾏開始したGroupChatないしはTeamの 参加メンバーから候補を選択できるようになる。 実⾏しているGroupChat or Team参加メンバーの候補から選択できるようにする
任意の⽂字⼊⼒で、GroupChatに参加 しているメンバーの候補を表⽰。 GroupChat不参加者は例えメールアド レス形式で指定してもエラーになる。 実装結果
③プロフ画像取得 有無判定に加え、dataURI(base64)変換後のLength判定を⾏う プロフ画像取得 プロフ画像有無の判定 dataURI(base64)変換 Length判定 AdaptiveCardの28KB制 限によるエラーを避ける プロフ画像が設定されて いても思いの外、⾼サイ
ズの画像を設定している ユーザーがいたことによ る学びから実装。
サイズの判定をどう考えるか? 実際に投稿されたAdaptiveCard dataURI化されたプロフ画像 全サイズ:23,719 byte プロフ画像以外(メッセージ等):1,405 byte プロフ画像:22,314 byte 25〜26KB程度が判定ポイントとすれば良い
….
④エラーハンドリング スコープ内の任意の箇所でエラーになると、 スコープ全体の実⾏結果評価が「失敗となる」 すなわち、フロー最後にエラーハンドリングの処 理を⼊れておくだけで、予期せぬ箇所で発⽣しう るエラーも含め全体的な統制が可能となる。 スコープにメインとなる処理をまとめて⼊れ、全体の実⾏結果評価ができるようにする
GPT君のアイデアで実装 実⾏条件を「失敗した時」に して通知⼊れたらええやん 処理まとめて「スコープ」 に⼊れてしもたらええやん
通知イメージ フロー実⾏結果ページへジャンプ フローに失敗するとリアルタイムに このメッセージが投稿される
今後やりたいこと AI Builderを使うか?OpenAIを使うか? ⽇々のTeams上での会話の内容に対して肯定的、否定的な感情分析を時系列でとることで、組織全体の ポジティブ状態の参考情報の⼀つとして活⽤する。かつ、投稿メッセージ内容にも同じ分析を⼊れるこ とでいわゆる「愉快犯」のモニタリングに活⽤できるかも? 定性っぽい効果測定データの取得+愉快犯対策 試しに作ったGPTs EmoDetect 感謝の度合いをスコアリングしてくれる
AI Builderのアクション
最後に余談(ポエム) 取り組んでいる事 KGI‧KPIの明確化と数字が取れる仕組み化。 ユーザーと対話できる環境と仕掛けづくり。 プロモーションをやめない。 仮説とフィードバックのサイクルを早く回す。 ⾯⽩いと思ったことはとりあえずやる。 フローを「プロダクト」としてGrowthさせる PowerAutomateのユースケースに サプライズを!
200名超 1,000名 2023.12 実績 2024.12 KPI とある組織での 利⽤者数
Thank You!