世の中には「アテにしてはいけないもの」が最低2つあると思っています。
ひとつは iPhoneのお天気アプリ。
当たりませんね、アレ……（笑）
テレビとYahoo!天気が「晴れ」と言うのにiPhoneだけ「雨」とか、その逆もザラ。リモートワークでほぼ外に出ないので、実害は豚が降ってもほぼゼロなんですが、それでも「なんでこんなに当たらないんだろ」と思うわけです。
そしてもうひとつが、エンジニアが毎月申告してくる実績工数。
これがまた、見事なまでの予定調和。アテになりません（泣）
分単位入力の地獄。人間工学どこいった？
私の会社では、エンジニアごとにプロジェクト・日ごとに「3時間24分」とかを時分単位で手入力します。
この“分単位のプルダウン”が特に曲者で、60項目をスクロールしていちいち選ぶ地獄。マウス前提のUIで大量入力とか、開発者は何を思っていたのか……。
その結果、たった1時間の工数申告のために、ログインから27アクション。
こんなUIで「精緻に入力しろ」というほうが無理です。
工数を入力するための工数がかかるという本末転倒っぷり。
そりゃみんな、月末に「予算通り」の工数をまとめて入れますよね。管理者も予定どおりの消化率で喜ぶし、全員幸せ……いや、そんなわけない。
複数プロジェクトを跨ぐエンジニアの工数なんて信用できるの？
1案件にフル投入されているエンジニアならまだいいんです。
勤怠時間を全部案件に突っ込めば終わりだから。
問題は、複数プロジェクトを並行するタイプ。
はい、私です。
見積りを作るとき、過去の実績工数を参考にしたいのに、
出てくるのは“予定調和された数字”。
ぜんぜん当てにならないので、結局エンジニアに個別ヒアリング。
「あの工数でできるわけないでしょ！」的な会話で盛り上がり、やっぱり実績値は信用できない……。
もう自分で仕組み作るしかない → 作りました
ということで、作りました。
backlogで記事投稿 → その場で工数申告させる仕組み
流れはこうです。
-
backlogに投稿
-
メール通知が飛ぶ
-
Power Automateがメールを拾う
-
投稿者に「工数は？」とTeams通知
-
投稿者はボタンで選ぶ
-
データは SharePoint に貯まる
ポイントは“投稿直後に入力できる”こと。
情報の鮮度が高く、作業内容はbacklogのコメントから追えるので、トレーサビリティも完璧。
さらに、アウトプットが伴わない人は工数が付かないので、サボりも可視化されます（笑）
クリック一つで工数登録できる世界
Teams通知には、Adaptive Cardで30分単位のボタンを配置。
2分とか3分とか、あの手の「極小工数」は潔く切り捨て30分単位。
ボタンが10個程度に収まるので、サクッと終わります。
従来のようにログインして、スクロールして、時・分を選んで……なんて不毛な操作は一切不要。
月末の作業報告も、このデータをそのまま使えるのでラクになりました。
APIを避けてメール経由にした理由
実はbacklogと直接API連携したほうがスマートなんですが、
-
APIキーの発行が面倒
-
クライアント管理のbacklogだとセキュリティ審査が発生
-
そもそもメールは枯れた技術で扱いやすい
という理由から、あえてメール経由にしました。
おかげでいろんなプロジェクトに流用できます。
ただし、メールがたまにHTMLで来る問題には悩まされました。こればっかりは投稿者の設定次第なので、HTML使うなとルール付けも困難なので対応したんですけど、メール内容を解析するためにPower Automateで分岐を組むの、地味に大変なんですよ……。
プログラムならif文ちょろっと書いて済む処理をGUIでカチャカチャやる虚無感。
backlogの実績工数フィールドが使えない理由
backlogには工数フィールドがあるんですが、
課題に対して一つしかなく、累積入力を手計算で更新する必要があります。
38時間実績工数が積み重なった課題に5時間追加する必要があるからえーっと、せや、43時間で再入力しよ的な……
いや、それくらいコンピュータがやれよ、と。
設計や実装で頭フル回転中のエンジニアに、こんなつまらん足し算させたくありません。
低コストで“活動原価”が取れるようになった
こうして作った仕組みのおかげで、ほぼお金も手間もかけずに
が実現しました。今のところ、部内の10数名が使ってる感じです。
このデータが積み上がれば、見積の標準化にも使えそうです。
あとは……私のやる気次第ですが（笑）
まとめ
iPhoneの天気予報と同じくらいアテにならなかった工数管理。
それをノーコードツールでここまで改善できるとは、自分でもビックリ。
小さな工夫でも、仕組みを変えれば仕事のストレスは大きく減る。
そんなことを実感した出来事でした。
