Backlogの実績工数をAmazon QuickSightで可視化してわかったこと

今年に入ってから、Backlogで個人タスクを登録しだして、予定工数、実績工数をなるべく入力してます。
そして3ヶ月経って第１四半期分が出来上がったので、Amazon QuickSightで可視化してみました。

何を可視化したか

作業種別、もしくは期日で、実績時間を合計して可視化しました。

仕組みは別の記事に書きますが、BacklogのWebhookからAWSへ連携して更新した課題の情報はリアルタイムでQuickSightで可視化できるようにしています。

「時間は作らないとできない」 可視化してわかったこと

上の円グラフが作業種別別で、下の積み上げ棒グラフが日別です。
左のナビゲートペインで期間、担当者をフィルタリングできます。

• 作業種別は年初の予定工数どおりぐらいのバランスで推移している。
• 昨年からの会社の施策が効いていて、本来自分がやるべきことに時間を避けるようになっている。
• 1~3月はそもそもエンジニアリングが少ない予定だったがそれでも少なすぎるので増やすことが次の課題。
• 1データ(課題チケット)に1つの工数なので、3日タスクを1課題にしてしまうと日別で見たときに見辛い。課題チケットの粒度を1日未満にする。

ということで、エンジニアリングの時間を増やすために、ドキュメンテーションとミーティングの時間を見直してみることにしました。
ここから先は課題単位ですので、Backlogの課題検索で見てみます。

結果としてはルーティンではなく、スポットでかつ必要不可欠な対応がQ1では多数発生していたのだなあと振り返り。
削れないので効率を上げることと、スキマ時間を作ることです。

ですのでQ2の方向性としては、油断せずに時間をフル活用する。
そのためにさらに正確な工数管理と、油断している時間(空白の時間)発生を、日や時間単位で振り返って流されないようにする。
移動時間の有効活用も。

このへん全部体調次第なことでもあるので、必要以上に呑まないというのもQ2の指標にする。

これでどう変わるか。

あと、予定工数でも同様に可視化しして、その時点で見直せるかも必要。

結論としては、「時間は作らないとできない」でした。

どうすれば作れるかのトライをQ2ではしていきます。

この仕組みについては別記事で書きます。

最後までお読みいただきましてありがとうございました！

【PR】 「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

【PR】 「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第2版」という本を書きました。

【PR】 「ポケットスタディ AWS認定 デベロッパーアソシエイト」という本を書きました。

【PR】 「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

【PR】 「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。