開発組織のTableauによる工数管理

開発組織の工数管理
JTUG スポンサーは Tableau をこう使っている！
2021年5月13日

Copyright© INTAGE TECHNOSPHERE Inc. All Rights Reserved.
2
自己紹介
久保田郁亮（くぼたふみあき）
所属： DXビジネス推進部
職歴：アンケートデータ集計システムの開発・運用
データ統合基盤の開発・運用、啓蒙活動
Tableau パートナー窓口
Tableau歴：
2018年冬はじめてインストール
2019年冬 Desktop Certified Associate
2020年冬 DATA Saber
最近ショックだったこと：
「今日のくぼたさん、まじめですね。」と言われたこと。

3
日本市場で最も信頼される
「売上 No.1」
インテージグループは「生活者を最もよく知る企業」
最近ニュースでよく見る混雑統計
日本最大のリサーチデータ、リサーチ・プラットフォームを揃え、「どの商品がいつからどのくらい売れているのか」「どんな人が買っているのか」等、
市場推移やブームの兆しなど、生活者を360°理解できるデータ・幅広く深い生活者インサイトを提供し、クライアント企業様や報道機関各社様の
CMや番組、記事の中でご活用いただいています
約4,000店
日本最大規模
50,000人

4
「データ価値創造」先進企業へ－インテージテクノスフィア
お客さまの「今」から「ゴール」へ、
多彩なスキルやアセットを組み合わせ、様々な
業界での経験から培った知見とデータ活用にお
ける確かな実績でお客さまに最適な解を提示
しながらアシストしてまいります
創業以来、一貫してデータと共にソリューションを提供し続けてきたスキルとノウハウで、お客さまのデータ活用を牽引します
インテージのマーケティング・リサーチを、
先端技術を駆使し、膨大なデータの収集から
クレンジング、集計、提供を高速処理する
スキルとノウハウで支えています
大量データ高速処理
クレンジング AI
伴走力
エキスパート
ジェネラリスト

5
インテージテクノスフィア技術ブログやってます。
他のメンバーが投稿した記事、
「Webアプリに組み込んでみた – Tableau JS API -」にアクセス数で負けているので、
なんとかそれを上回る記事を投稿しようと思案中です。
https://www.intage-ts.com/

6
お話しすること
⚫ 工数管理でどんな問題が発生していたか。
⚫ データを活用することでどんな変化が起きたか。
⚫ おススメの取り組み方。

7
工数管理あるある
メンバー視点での工数管理
⚫ 規定の残業時間オーバーに気づいたときにはもう手遅れ。
⚫ 実はあのメンバー、無償稼働ばかりで手が空いている。
⚫ 特定のメンバーばかりに業務が寄ってしまっている。
案件視点での工数管理
⚫ 計画工数をオーバーしてしまい、利益を食いつぶしてしまった。
⚫ 進捗がよろしくないと思ったら、兼務メンバーが全然稼働できていなかった。
肌感覚で捉えられる場合もあるが、
見過ごす場合もあるし、それは “管理” とは言えない。

8
問題発生の背景１
組織
⚫ 所属グループを越えて、開発案件のチームは編成される。
⚫ 日常的に距離間が近いのは、所属グループの上長より開発チームのリーダー。
⚫ リモートワークにより、肌感覚が通用しなくなってきている。
Group
1
案件B
案件A
Group
2
Group
3
GL GL GL
PL
PL

9
問題発生の背景２
社内システム
⚫ 社内システムは所属に合わせて権限設定がされている。
⚫ 開発チームのリーダーはアクセスできない場合もある。
Group1
GL
PL
Group2
GL

10
問題発生の背景３
属人化
⚫ プロジェクト管理やメンバー管理の方法はひとそれぞれ。
⚫ 実績工数は PM/PL しか把握していない。（Excel、頭の中、...）

11
どうすれば問題を防げるか
データをみる
⚫ 肌感覚ではなく、データで実態を正しく捉える。
⚫ 多角的に捉えられるデータだとなおよい。
データをみる頻度をあげる
⚫ 予兆に気づく。早い段階で対処することができる。
⚫ 頻度をあげるためには、手軽に確認できる必要がある。
データをみる人を増やす
⚫ なるべくデータをオープンにする。
⚫ メンバー自身による自浄作用も、周囲の人のおせっかいも期待できる。

12
実現するために、こんなダッシュボードをつくった。
実際のダッシュボード（ダミーデータ）をお見せします！

13
ダッシュボードにより得られた変化１
メンバー視点での工数管理
⚫ 今月だれがどのくらいの稼働時間で着地しそうかが早い段階で把握できるようになった。
✓ 15日時点で半分を大きく超えていたら要注意
✓ ラスト1週で残業調整の声掛け
⚫ 無償稼働の状況を目の当たりにしたことで、改善アクション検討が本格的にスタート。
✓ アクション → 効果有無も明確に
案件視点での工数管理
⚫ 計画工数と実績工数のギャップをみつつ、細かくアクションを検討できるようになった。
⚫ グループを越えた開発チーム運営のハードルが下がった。
✓ 別グループのメンバーかつマルチタスクでも “全体” が見える。

14
ダッシュボードにより得られた変化２
意識 / 行動
⚫ リーダーはデータ確認の準備から解放され、アクション検討にすぐ取り掛かれる。
✓ 以前はデータを取得して、Excel などで加工・集計を都度行う必要があった。
⚫ リーダーだけでなく、メンバーひとりひとりの工数意識が芽生えた。
✓ メンバーは自身の実績工数しか参照できなかったのが、他のメンバーの実績工数も見えるようになった。
✓ それにより、相対的にどれだけ稼働しているのか、あるタスクにかかっている時間が多いのか少ないのかが見え
るようになった。
✓ 幹部職にしかアクセス権限がない → メンバーには関係がない → 工数を意識しない → やりたい放題、と
いう状態からの脱却。
組織としては、この意識 / 行動の変化が最重要！

15
泥臭い部分１
データの場所はバラバラ
⚫ 実績工数データは特定ディレクトリに日次で出力される。
⚫ 計画工数は案件ごとに独自管理だったので、共通フォーマットを作成。
勤怠管理
システム
経営情報
システム
Tableau
共通
フォーマット

16
泥臭い部分２
扱いづらいデータフォーマット
⚫ 年月やPL科目が列方向に並ぶ。
⚫ 異なる階層のデータ項目が同列に扱われる。。
社員コード 1月 2月 3月 ...
10001 15.5 23.25 19 ...
10002 12 14.5 12.25 ...
10003 20.75 21 23.5 ...
科目 ...
製造人件費/経費 ...
製_人件費 ...
製_社員人件費 ...
製_派遣社員人件費 ...
製_経費 ...
... ...

17
泥臭い部分３
その他
⚫ 大規模案件は案件単位では捉えづらいので、案件内で細分化。
✓ 案件コード × 工程コードで同一案件を細分化する。
✓ 工程コードの使い分けを決めて周知する。
e.g., フロントエンドは 501、バックエンドは 502
⚫ 日々の工数入力の声掛け。
✓ メンバーが入力を忘れると、誤った判断をする可能性がある。
✓ しかし実際は、「ん？おかしいぞ。入力漏れか？」と気づける。
定期的にデータを見ているので、”カン” が働く。

18
今後のブラッシュアップ
データ加工処理の自動化
⚫ Prep でフローを作成したので、Creator ユーザーが手動でフローを実行している...
⚫ Data Management アドオンか、プログラム実装により、更新運用から解放されたい。
他部署への展開
⚫ 部内では定着したので、他部署にも使ってみてもらいたい。
⚫ 個々にデータ取得して集計している人たちを解放してあげたい。
ワークブックの社内オープンソース化
⚫ アイデアを持つ人がどんどん手を加え、いいものに仕上げていってほしい。

19
まとめ
おススメの取り組み方
⚫ いきなり完全なものを目指す必要はない。できる範囲でまずはやってみる。
⚫ 難しい調整（情シスになにかを変えてもらうなど）は先送りにする。
⚫ 小さくても効果があるものをつくったら、それを発信する。 ⇒ 味方をさがす。
⚫ 発信を受けた人は、讃えつつ、フィードバックをする。 ⇒ 味方になる。
⚫ 味方を増やし、変化の波をつくっていく。。 ⇒ 文化 / 風土になる。
忘れてはいけないこと
⚫ データを見ることが目的ではない。よりよい判断をして、改善を重ねていくことが目的。

20

開発組織のTableauによる工数管理

Recommended

Recommended

More Related Content

Featured

Featured (20)

開発組織のTableauによる工数管理