ナッジ理論とPower Automateを使った報告ツール

## １．はじめに
最近、リーダー職となったので、色々と考えることもあり
とりあえずは、役職ってことなので
メンバーの「役」に立つように動ければなとチーム内の自動化を進める事にした

***

## ２．日々の面倒な作業、それは報告
こう言っては何ですが、管理するメンバーや作業がある以上は
こんな感じでヒアリングをする必要があり
メンバーも複数いるとそれなりにまとめるのが大変

***

### 2.1 ヒアリングするならこんな感じで要点を聞く

| 課題 | 動機 | 対象 | 時間 | 場所 | 手段 | 優先 |
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| 案件1 | 障害 | 担当 A | 1h | 本番 | 対応 | 緊急 |
| 案件2 | 障害 | 担当 B | 2h | 本番 | 改修 | 低 |
| 案件3 | 開発 | 担当 A | 4h | 開発 | 開発 | 高 |
| 案件4 | 開発 | 担当 C | 6h | 開発 | 開発 | 高 |

これに合わせて各案件ごとに各担当者からの経緯も聞く
一日の予定も聞く．．．

***

### 2.2 話すための準備と聞くための準備

毎朝、このヒアリングをするための準備にまぁ時間が掛かっている
**準備**と**ヒアリング**で、一人当たり45分ぐらい拘束時間になっている
ヒアリングは集まって行うので、ある程度の時間は必要としても
話すための準備(個人で報告用のテキスト書き)に時間をかけさせるのは
# **ちょっと嫌**
***

## ３．現状の課題を考えてみる
・複数種類の報告の必要性
・言われたからやっているという惰性
・フォーマットや粒度が安定しない
・自身が記載した内容のフィードバック
・手作業の為の記載ミス、報告漏れ
・報告する内容が多いため手作業が多い

***

### 3.1 ここで気づいたこと

# 面倒な事でも、報告しやすくすればいいのでは？

***

### 3.2 ここで出てくる「ナッジ理論」

以前、ＴＶでみた「ナッジ理論」で、より良い方向に誘導するという話
付け焼刃ながら考えてみた

***

### 3.3 ナッジ理論にある6原則に置き換えを考える

ナッジ理論によると以下の6原則を検討するということ

| # | 原文 | 訳 |
|:-:|:-:|:-:|
|1)|iNcentives|インセンティブ（目標に向かう意欲を高める刺激）|
|2)|Understand mappings|選択と幸福度の対応関係説明|
|3)|Defaults|あらかじめ用意された標準の選択|
|4)|Give Feedback|即時の反映|
|5)|Expect errors|過ちの予期|
|6)|Structure complex choices|複雑な選択の単純化|

***

### 3.4 今回の問題と手間の置き換えを考える
| # |ナッジ|問題|解決|
|:-:|:-:|:-:|:-:|
|1)|目標に向かう意欲を<br>高める刺激|複数種類の<br>報告の必要性|使用者がこのツールが<br>何をするものかを捉え易い|
|2)|選択と幸福度の<br>対応関係説明|言われたから<br>やっているという惰性|使用者自身が行っていた<br>義務作業への開放|
|3)|あらかじめ用意された<br>標準の選択|フォーマットや粒度が安定しない|定型的な操作、デフォルト値、<br>前回登録内容の継承|
|4)|即時の反映|自身が記載した<br>内容のフィードバック|結果の即時性、<br>他者通知とデータ蓄積|
|5)|過ちの予期|手作業の為の<br>記載ミス、報告漏れ|カードを定期送信する事により記載漏れの抑止|
|6)|複雑な選択の単純化|報告する内容が<br>多いため手作業が多い|複数の報告(勤怠、タスク、工数)を集約化|

***

## 4.ナッジ6原則で考えたことをPower PlatFormで表現してみよう

**提案**：アダプティブカードを使用した勤怠報告の連携
**課題**：毎日、手書きによる勤怠タスク報告を、各個人の義務(ルール)として
Teamsに投稿、個人での管理で行われており記載に対してし時間を要する
加えて送信漏れ、記入ミスなどが発生している
かつ、周知した内容は、Teams上で残したままで、データとしての利用は皆無となっている

***

## 4.1 報告をしやすくする為のアダプティブカードを考えてみる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3701343/fd6bf085-fc64-0b34-48f4-c94019fbd4dc.png)

入力内容は
・勤怠予定時間
・勤務状況
・勤務場所
・タスク予定（タスク名※1、作業カテゴリ、割合※2）
・コメント

※1：タスクはリーダが事前にメンテナンスしてメンバーへの割り当てを設定しておく
　  基本的には毎日チェック、
  　障害発生時は割り当てられたメンバーにタスクが表示されるように自動設定
※2：割合は、一日の作業量を割合で朝夕で1～10まで入力させて、
　夕方の報告後に一日の作業時間に対して時間に算出しなおす
 この方が精神的に入れやすいと思ったので(考えさせたくない)

***

## 4.2 入力されたデータからデータを生成し朝会に備える

データストアはSharePointを使用して行う
その方が、ビューとして公開しやすく編集も複数人数で行いやすい
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3701343/9fbcc06d-2496-76b2-cbda-b15a4793a7c8.png)
***

## 5.ついでにアダプティブカードで悩んだことについて

　・予定タスクは複数あるので増減できるようにする
　・アダプティブカードの28kb制限

***

##  5.1 予定タスクは複数あるので増減できるようにする

ヘッダ行は固定で作成済としておいて
行自体は、対象の件数分テーブル行を作成するようにしておく
その際に、各行の変数名(id)には、ループの添え字(何番目)かをくっつけるようにしておく

~~~
"id": "taskEx@{items('Apply_to_each_2')}"
~~~

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3701343/fa446078-709b-d655-e35e-5f9de27fafc8.png)

~~~
{
    "type": "TableRow",
    "cells": [
        {
            "type": "TableCell",
            "items": [
                {
                    "type": "Input.ChoiceSet",
                    "choices": @{variables('TaskList')},
                    "placeholder": "追加タスク",
                    "id": "taskEx@{items('Apply_to_each_2')}"
                }
            ]
        },
        {
            "type": "TableCell",
            "items": [
                {
                    "type": "Input.ChoiceSet",
                    "choices": [
                        {
                            "title": "開発",
                            "value": "開発"
                        },
                        {
                            "title": "保守",
                            "value": "保守"
                        },
                        {
                            "title": "調査",
                            "value": "調査"
                        }
                    ],
                    "id": "categoryEx@{items('Apply_to_each_2')}",
                    "spacing": "None",
                    "placeholder": "作業"
                }
            ]
        },
        {
            "type": "TableCell",
            "items": [
                {
                    "type": "Input.Number",
                    "min": 0,
                    "max": 10,
                    "id": "rateEx@{items('Apply_to_each_2')}"
                }
            ]
        }
    ]
}
~~~

***

## 5.2 アダプティブカードの28kb制限


アダプティブカードの送信には28kbまでの制限があるため、
項目を増やしたり、コンボボックスに選択肢を多く入れると、すぐに28Kbを超えてしまいます
ただ、アダプティブカードデザイナーで作ると、可読性のためインデントの空白、改行などが多く含まれるため
それを除去するだけでもかなりの圧縮になります
圧縮行わないカード内容の変数を作成して格納して起き、圧縮用の変数に対して、余剰文字を除去した結果を格納して送信することで、28Kb制限をクリアできました

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3701343/66213126-fdc4-785e-5494-5627e101c99b.png)

以下のように置き換えして除去してます
~~~
replace(replace(variables('AdCardBase'),decodeUriComponent('%0D'),''),' ','')
~~~

***

# 最後に

報告の方法やツールの内容は現場によってそれぞれですが
私の場合は、今回の方法である程度、満足しています。

読んでいただいた後、こういうやり方や考え方もあるだなぁっていう
感じで受け止めていただけると幸いです

以上