ヤマムギ

growing hard days.

*

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

   


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

何を可視化したか

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

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

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

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

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

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

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

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

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

これでどう変わるか。

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

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

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

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


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

【PR】 「AWS認定試験対策 AWS クラウドプラクティショナー」という本を書きました。

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

 - AWS, BI , ,

ad

ad

  関連記事

PentahoでMySQLテーブルデータソースを作成しようとした時のエラー対応

PentahoでMySQLのテーブルへデータソースを作成しようとしてエラーが発生 …

AWS認定試験の自宅受験で壁のポスターを注意されちゃいました

AWS認定オンライン受験をしてみましたに書きましたとおり、自宅受験デビューしまし …

EC2 Amazon Linux 2 にAmazon LinuxからWordPressを移行

このブログを新しいインスタンスに移行することにしました。 2015年5月にAma …

AWS Cloud9でJavaサンプルを実行する

リモートで共有開発ができるCloud9便利ですね。 Cloud9でJavaのサン …

スポットインスタンスの削減額情報を見ました

なんだこれ?と思って、検索してみたら、2018年11月からあったのですね。 Am …

AWSアカウントルートユーザーのMFAでYubicoセキュリティキーを設定した

先日Yubico セキュリティキーを購入して、USBにささなければならないのがな …

Redmineの添付ファイルをS3に同期する

RedmineをAWS上で構築するデザインを考えていて、せっかくなので冗長化しよ …

AWS EC2 インスタンスステータスのチェックで失敗して起動しなくなり復旧

EC2のインスタンスに接続出来なくなったので、AMIから作成してElastic …

AWSのサービス数を数えてみました(2020/5/23)

何をもってサービスという単位にするかというのはあるかもしれませんが、とりあえず情 …

Application Load Balancer スティッキーセッションでどれぐらい偏るかを偶然見ました

Amazon Linux2のPHPを7.2から7.3へアップデートしましたでアッ …