
非エンジニアがAIで21名チームの約14,700時間の業務を入社から3ヶ月で可視化するまで(全5回:第2回)
全5回の連載内容について
このプロジェクトは以下の順で報告しております。
今回は第2回となります。第1回もよければ以下のリンク先よりご覧ください。
| 回 | 内容 |
|---|---|
| 第1回 | 入社から「悪循環」の発見まで |
| 第2回 | *今回* 可視化の土台「タスクマスター」 — タスク×工程×バリアントの設計思想 |
| 第3回 | 5つのデータソースを統合する基盤設計と実装 — 既存運用をデータ源に変える |
| 第4回 | 約14,700時間の可視化結果による事実とAIとともに策定した40課題の解決策 |
| 第5回 | 再現性の検証 — この手法はどこまで転用できるか |
前回は、21名のチームが抱える「3つの見えない」と、悪循環を断ち切るために「まず測る」という方針を決定しました。
今回は、その「測る」ための土台として設計した「タスクマスター」の設計思想について報告します。
第2回:可視化の土台「タスクマスター」 — タスク×工程×バリアントの設計思想
タスクマスターとは、チームの全業務を「タスク種別×工程×バリアント」の単位で定義した計測基盤です。
「現場への追加入力ゼロ」を条件として既存データのみで構築し、3つの役割を担います。
(バリアント:同一タスク種別内における工程の組み合わせや複雑さによる分類。)
- 計測単位の定義 — 全業務を248種類のタスクに整理し、工程・バリアント単位まで分解
- タスクとマニュアルの紐づけ — タスク処理を行う際にどのマニュアルを参照すれば良いか確認するためのガイド
- スキル評価の基盤 — 誰がどの工程をどのスピードで処理できるかを定量把握
本記事では、この設計に至るまでの経緯を報告します。
なぜ既存のタスク一覧が使えなかったのか
前回の結論「業務量の可視化を最優先・現場への追加入力ゼロ」を受け、まず既存のタスク一覧表を計測基盤として使うことを検討しましたが、3つの問題がありました。
① 完成版ではなく更新状況も不明
名称はあっても「今も実施しているか」「チケット管理ツールのどのタスクに対応するか」が不明なものが多く、そのまま計測基盤として使える状態ではありませんでした。
② タスクの粒度がバラバラ
対象・規模によって複数に分かれるタスクもあれば、複数のタスクをまたぐ横断的な作業もあり、評価軸として揃っていませんでした。
③ 他チームのデータが混在
チケット管理ツールは他チームと共用のため、自チームと外部チームの業務が混在し、単純な集計では正確な業務量を把握できません。
どう設計したか
工程レベルの計測へ
このチームは工程ごとに担当者が変わる運用のため、タスク全体の合計時間では評価できず、工程レベルの計測が必要でした。
チームはすでにチケットのステータス(作業中/保留中)と工程を示すラベルで業務を管理していました。
データ処理時にメンバーリストと照合することで自チームの作業のみを抽出し、混在を解消しました。
ステータス変化とラベル変化のタイムスタンプを組み合わせることで、「誰が・いつ・どの工程を・何分実施したか」を追加入力ゼロで自動算出できるようになりました。
集計の単位は「タスク種別 × 工程 × 作業タイプ × 担当者」と定義しました。

バリアントの定義
同一タスク種別でも工程の組み合わせや複雑さによって所要時間が大きく異なります。
とあるタスクには十数種類のバリアントが存在し、バリアントを混在させると中央値が実態を反映せず業務評価の精度が下がります。
バリアントを明示的に分類することで、同条件での比較が初めて成立します。

設計を支えたAI活用
このシステム設計の過程で、3つの局面でAIを活用しました。
① APIの実現可能性確認と実装
チケット管理ツールのAPIについての知識がなかったため、まずAIに「ステータス変化とラベル変化のタイムスタンプ」の実現可能性を確認しました。
AIにより実現可能性とアプローチ方法を確認した上で、チームリーダーへ提案しました。
同リーダーが検証・GASを提供してくれたことでデータ取得を実現し、あわせて10項目のルールを定義してGASを完成させました。
② バリアント特定のためのデータ分解
バリアントの定義も、AI生成のGASで実際のデータを分解しラベル変化の遷移パターンを自動抽出しました。
出力結果をもとに人間が必要な定義を判断し、タスクマスターに反映——網羅的なデータ処理はAIに、業務の意味づけは人間が担う役割分担が機能しています。
③ マニュアルの自動振り分け
約300件のマニュアルのタスクへの振り分けもAIが担いました。
マニュアルを1件ずつ読み込ませ該当タスクを判定させることで、出力された未分類リストのみをリーダー層が確認する形にし、確認負荷を「全件確認」から「例外確認」へ変換しています。
タスクマスターの3つの役割
役割1:計測単位の定義
タスク×工程×バリアントの組み合わせで全業務を定義します。
チケット管理ツールの記録、カレンダー予定、いずれにも現れない定型業務もカバーし、計測漏れのない全業務把握を実現します。
確定した実稼働タスクは248種類でした。
役割2:タスクとマニュアルの紐づけ
タスクに紐づくマニュアルが確認可能となり、対応タスク処理を行う際にどのマニュアルを参照すれば良いかのガイドとなることを想定し設計しました。
役割3:スキル評価の基盤
工程単位の所要時間データにより「誰がどの工程をどのスピードで処理できるか」を定量把握します。
6段階のスキルレベル評価やアサインの偏り・過負荷の検知を可視化完了後に活用することを想定した設計です。
感覚的な「人が足りない」「属人化している」という声を客観データに変え、リーダー層の意思決定を支えるデータ基盤として機能します。
第2回 まとめ
- 既存のステータス管理・工程ラベル・メンバーリストを組み合わせ、追加入力ゼロで工程レベルの計測を実現
- バリアント分類で困難性の違いを中央値に反映させ、正確な業務評価の基盤を確立
- AI活用(API活用・バリアント特定・マニュアル照合)で専門知識ゼロから設計を実現
- 3役割(計測単位定義・マニュアル紐付けとガイド活用・スキル評価基盤)を1つの構造に統合
第3回は、このタスクマスターを土台として、5つのデータソースを統合する基盤設計の全体像について報告します。
| 回 | 内容 |
|---|---|
| 第3回 | 5つのデータソースを統合する基盤設計と実装 — 既存運用をデータ源に変える |
| 第4回 | 約14,700時間の可視化結果による事実とAIとともに策定した40課題の解決策 |
| 第5回 | 再現性の検証 — この手法はどこまで転用できるか |
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました。










