１．はじめに
最近、リーダー職となったので、色々と考えることもあり
とりあえずは、役職ってことなので
メンバーの「役」に立つように動ければなとチーム内の自動化を進める事にした
２．日々の面倒な作業、それは報告
こう言っては何ですが、管理するメンバーや作業がある以上は
こんな感じでヒアリングをする必要があり
メンバーも複数いるとそれなりにまとめるのが大変
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) | 目標に向かう意欲を 高める刺激 |
複数種類の 報告の必要性 |
使用者がこのツールが 何をするものかを捉え易い |
| 2) | 選択と幸福度の 対応関係説明 |
言われたから やっているという惰性 |
使用者自身が行っていた 義務作業への開放 |
| 3) | あらかじめ用意された 標準の選択 |
フォーマットや粒度が安定しない | 定型的な操作、デフォルト値、 前回登録内容の継承 |
| 4) | 即時の反映 | 自身が記載した 内容のフィードバック |
結果の即時性、 他者通知とデータ蓄積 |
| 5) | 過ちの予期 | 手作業の為の 記載ミス、報告漏れ |
カードを定期送信する事により記載漏れの抑止 |
| 6) | 複雑な選択の単純化 | 報告する内容が 多いため手作業が多い |
複数の報告(勤怠、タスク、工数)を集約化 |
4.ナッジ6原則で考えたことをPower PlatFormで表現してみよう
提案：アダプティブカードを使用した勤怠報告の連携
課題：毎日、手書きによる勤怠タスク報告を、各個人の義務(ルール)として
Teamsに投稿、個人での管理で行われており記載に対してし時間を要する
加えて送信漏れ、記入ミスなどが発生している
かつ、周知した内容は、Teams上で残したままで、データとしての利用は皆無となっている
4.1 報告をしやすくする為のアダプティブカードを考えてみる
入力内容は
・勤怠予定時間
・勤務状況
・勤務場所
・タスク予定（タスク名※1、作業カテゴリ、割合※2）
・コメント
※1：タスクはリーダが事前にメンテナンスしてメンバーへの割り当てを設定しておく
基本的には毎日チェック、
障害発生時は割り当てられたメンバーにタスクが表示されるように自動設定
※2：割合は、一日の作業量を割合で朝夕で1～10まで入力させて、
夕方の報告後に一日の作業時間に対して時間に算出しなおす
この方が精神的に入れやすいと思ったので(考えさせたくない)
4.2 入力されたデータからデータを生成し朝会に備える
データストアはSharePointを使用して行う
その方が、ビューとして公開しやすく編集も複数人数で行いやすい
5.ついでにアダプティブカードで悩んだことについて
・予定タスクは複数あるので増減できるようにする
・アダプティブカードの28kb制限
5.1 予定タスクは複数あるので増減できるようにする
ヘッダ行は固定で作成済としておいて
行自体は、対象の件数分テーブル行を作成するようにしておく
その際に、各行の変数名(id)には、ループの添え字(何番目)かをくっつけるようにしておく
"id": "taskEx@{items('Apply_to_each_2')}"
{
"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制限をクリアできました
以下のように置き換えして除去してます
replace(replace(variables('AdCardBase'),decodeUriComponent('%0D'),''),' ','')
最後に
報告の方法やツールの内容は現場によってそれぞれですが
私の場合は、今回の方法である程度、満足しています。
読んでいただいた後、こういうやり方や考え方もあるだなぁっていう
感じで受け止めていただけると幸いです
以上