DeskGate 稼働管理ツール

管理したい稼働の意味を最初にそろえる

会議で「稼働が高い」「稼働が低い」という言葉を使う前に、何を分母とし、何を数えているかを確認します。勤務予定の時間を指す人と、コンピューターのアクティブ時間を指す人では、同じ数値を見ても受け取り方が変わります。さらに、端末が使われていることと、担当する案件が進んでいることも別の情報です。導入時には、使う指標の名称、対象、含まれない作業を短い説明にまとめ、関係する担当者の理解をそろえます。

DeskGateでは、Work Analysisでアプリケーションやウェブサイトの使用状況を確認し、Daily Activityで日ごとのアクティブ時間とパッシブ時間を確認できます。これらはPC上で収集された活動を把握するための情報であり、組織の勤怠制度や案件別の工数申告を自動的に代替するものではありません。会議、電話、紙の資料を読む時間、現場での作業などは、PCの操作量だけでは説明できない場合があります。利用目的とデータの範囲を合わせて考える必要があります。

具体的な問いを一つ決めると、指標の選択が容易になります。「新しい業務用サービスの利用状況を確認したい」「特定の期間に問い合わせが増えた背景を調べたい」といった問いです。問いが決まれば、必要な利用者、期間、レポートを選べます。逆に、収集できる項目をすべて会議に持ち込むと、数字の解釈に時間を使い、本来の判断が進まないことがあります。稼働管理の出発点は、情報の網羅ではなく、確認したい事項を明確にすることです。

チームの課題を観察できる形に整理する

「チームが忙しそうだ」という印象を、活動レポートだけで証明しようとするのは適切ではありません。まず、忙しさがどの場面で問題になっているかを聞き取ります。問い合わせの返答が遅いのか、担当者の交代時に確認が重複するのか、新しいツールの使い方が定着していないのかで、観察する範囲が変わります。PC上の活動がその問いにどう関係するかを整理し、関連が薄い場合は別の情報を使う判断も必要です。

例えば、業務用アプリケーションの導入後に問い合わせが増えた場合、利用している人と期間を確認し、どの種類の問い合わせが発生しているかを現場の記録と照合します。アプリケーションの使用時間が長いという事実だけで、操作に困っているとは判断できません。そのアプリケーションを長く使う仕事が増えた可能性もあります。レポートは次に確認する対象を絞る手掛かりとして使い、原因の説明は業務の背景と合わせて行います。

確認の計画には、分かった場合に行う作業も含めます。操作説明を見直す、支援の窓口を整理する、業務の担当範囲を確認するなど、数値の確認後に取る行動を考えておきます。改善の方向を決めずに毎週同じ集計を見るだけでは、記録が蓄積しても運用の役に立ちにくくなります。レポートから直接結論を出すのではなく、問いを絞り、背景を聞き、対応を決める流れの中で位置付けることが大切です。

期間をそろえて比較できる条件を作る

期間が異なる集計をそのまま並べると、活動の増減が実際より大きく見えることがあります。一週間と一か月、営業日が多い週と祝日を含む週では、合計を比較する条件が変わります。Work AnalysisやDaily Activityで開始日と終了日を指定したら、なぜその期間を選んだかも記録しておきます。問題が起きた日を確認するためなのか、変更前後を比較するためなのかで、適切な期間の取り方は異なります。

比較対象の期間に、部署異動、機器交換、新しいアプリケーションの導入、収集設定の変更がないかも確認します。表示された数値が変わった理由は、業務の進め方だけとは限りません。対象者の構成やデータが集まる条件が変われば、同じ名称のレポートでも比較の意味が変わります。変更があったことを隠して条件をそろえたように見せるのではなく、どこが違うかを説明し、比較できる範囲を限定します。

毎回同じ曜日に確認する場合でも、単に前回の設定を覚えているつもりで進めないようにします。画面上の期間と対象を読み直し、出力資料にも同じ範囲が含まれているか確かめます。定例の作業は慣れによって確認が省略されやすいため、開始日、終了日、対象グループ、対象ユーザーを確認する短い手順を設けます。条件が明確なら、後で別の担当者が同じ問いを調べる場合も、結果の違いを切り分けやすくなります。

グループとユーザーを集計の前に点検する

短い期間の比較では、一人の対象変更でも全体の見え方が大きく変わることがあります。集計に含める人数が少ないチームほど、人数と利用条件を先に点検することが重要です。新しく参加した人の記録が期間の途中からしか存在しない場合、期間全体の合計を他の人と同列に扱わないようにします。対象が途中で変わったことを説明し、比較が必要なら確認できる期間を整理します。また、一覧の人数と会議資料に記載した人数が一致しているかも確認してください。資料の作成途中に対象を変更した場合、数値だけを差し替えて説明を残してしまうことがあります。対象者の確認は、レポートを実行する前だけでなく、共有資料を完成させる段階でも行う作業です。

チームの稼働を確認するとき、最初に見るべきものは合計値よりも対象ユーザーです。グループ名が部署名と似ていても、現在の部署の全員が含まれているとは限りません。兼務、異動、臨時の支援、貸与端末の変更によって、組織の構成とシステム上の対象がずれることがあります。グループを選んだ後に、目的の人が含まれ、関係のない人が含まれていないかを確認します。人数の違いがある状態では、合計の増減を業務の変化として説明できません。

一人が複数の端末を使う場合や、一台を複数の人が使う場合にも注意が必要です。ユーザーを軸に確認した結果と、機器の管理で確認した内容を結び付けるときは、どの期間の利用関係なのかを明確にします。現在の端末一覧だけを見て、過去のすべての活動を同じ利用者に帰属させないようにしてください。必要な場合は、機器の受け渡しや業務担当者への確認を通じて、対象期間の背景を補います。

対象者を確認する作業は、数字を都合よく見せるための除外作業ではありません。最初に定めた問いに対して、比較する母集団を明確にするための作業です。対象を変更した場合は、変更した理由と影響を残します。複数の会議で同じレポートを利用する場合も、受け手によって対象者を黙って変えないようにします。集計範囲を説明できることが、数字を使った話し合いの前提になります。

Daily Activityを日ごとの状況確認に使う

Daily Activityでは、対象期間、グループ、ユーザーを設定し、アクティブ時間とパッシブ時間などを確認します。ユーザーを絞り込むチェック項目と、アクティブ時間の合計は別の意味を持つため、画面の表示を混同しないようにします。条件を適用した後は、対象となるユーザーの行を確かめ、必要なページを確認します。最初に表示されたページだけを見て、すべての対象者を確認したと思い込まないことが重要です。

このレポートの一日は、零時から二十四時までの千四百四十分を対象としています。PCの電源を入れた時刻や電源を切った時刻を示す情報は含まれていません。したがって、表示された時間から始業や終業を計算したり、パッシブ時間をすべて勤務中の非作業時間と見なしたりすることはできません。勤務の実績を確認する必要がある場合は、組織で定めた勤怠の記録と確認手順を利用し、活動レポートとは目的を分けます。

日ごとの値に違いがあったら、その日に何があったかを確認します。会議や外出、PC以外での作業、接続や収集の状態など、背景は複数考えられます。値の変化だけをもって、本人の働き方を断定しないようにします。異常に見える日を見つけることと、原因を確定することは別の段階です。日ごとの確認で疑問点を絞り、必要な情報を他の担当者や本人に確認することで、レポートを適切に活用できます。

Work Analysisで使用状況の内訳を確かめる

内訳を現場と読み合わせるときには、確認したいアプリケーションやウェブサイトを少数に絞り、その用途を説明できる担当者に参加してもらいます。利用している本人だけでなく、業務の手順を管理する人が背景を知っている場合もあります。画面に出た名称が社内で使う呼び名と異なると、別のサービスだと思い込むことがあるため、名称の対応も確かめます。用途が確認できない項目は、すぐに良い利用や悪い利用へ分類するのではなく、未確認の項目として残します。次の確認先と期限を決めれば、分からない項目を放置することと、不確かなまま結論を出すことの両方を避けられます。この作業を通じて、分類の意味を現場と管理側で共有できます。

アプリケーションやウェブサイトの使用状況を詳しく確認したい場合は、Work Analysisを利用します。グループ、ユーザー、開始日、終了日などの条件を設定し、レポートを実行した後で対象を再確認します。概要の数値が気になったときは、詳細なアクティビティやユーザー比較へ進み、どの記録が集計に関係しているかを見ます。日ごとの活動レポートと、アプリケーションやウェブサイトの内訳を扱うレポートは、問いに応じて使い分けます。

同じウェブサイトでも、部署によって用途が異なることがあります。採用、調査、顧客対応、広報など、業務上の目的で利用する場面はさまざまです。名前だけを見て一律に私的利用と分類すると、実際の仕事を正しく説明できません。分類が未定義の場合も、定義がないという事実をそのまま扱います。分類の不足を、利用者に問題がある証拠として置き換えないことが重要です。必要な確認を行ったうえで、組織内の分類の考え方を整理します。

使用時間が長いアプリケーションを見つけた場合、すぐに減らす対象と考えるのではなく、そのアプリケーションが担う役割を確かめます。主要な業務システムなら、長く使われていること自体は不自然ではありません。反対に、短時間しか表示されていなくても、仕事への影響が小さいとは限りません。PC上の活動時間と業務上の重要度は別の軸です。レポートの内訳は、業務を理解するための材料として読み、単純な順位で結論を決めないようにします。

活動量と成果を分けて説明する

コンピューターの操作が多いことは、そのまま高い成果を意味しません。操作を減らす改善によって、活動時間が短くなっても仕事が進む場合があります。逆に、入力や確認のやり直しが多いと、活動量は増えても効率がよいとは言えない場合があります。稼働管理ツールを使うときは、記録された活動と、完成した成果物、対応した問い合わせ、業務の進捗などを区別します。どの情報が何を表しているのかを説明することで、数値だけの評価を避けられます。

現場の担当者との話し合いでは、数値を提示して理由を迫るのではなく、業務上の背景を確認するための問いとして使います。「この期間に担当業務の変更があったか」「新しい手順の確認が必要だったか」といった聞き方なら、改善につながる情報を得やすくなります。データが示す範囲を先に説明し、分からない部分を認めることも大切です。記録を持っている側だけがすべての状況を理解しているという前提で話を進めないようにします。

共有資料では、観察した事実、考えられる理由、確認が必要な事項、決定した対応を分けます。例えば、特定のアプリケーションの利用状況が変わったことは観察できますが、その理由が業務量の増加なのか、手順の変更なのかは追加の確認が必要です。推測を事実と同じ欄に書かないようにすれば、後で状況が分かったときに説明を修正しやすくなります。数字を使った管理には、数値の正確さと同じように、説明の区別が必要です。

チーム間の比較を急がない

部署ごとの合計や比率を比較したくなる場面でも、まず業務の性質を確認します。PCへの入力が中心のチームと、電話や対面での対応が多いチームでは、同じアクティブ時間が同じ意味を持つとは限りません。対象人数、期間、収集範囲、アプリケーションの分類もそろえる必要があります。条件を合わせられない場合は、直接の優劣を示す比較を避け、それぞれのチームの中で変化や課題を確認する方が適切なことがあります。

比較する場合も、合計だけでなく対象者の構成を読み取ります。一部の人が別業務へ移った期間や、機器の変更によって収集条件が変わった期間では、数値の変化をそのままチーム全体の効率の変化と考えられません。条件に違いがあることを資料に明記し、必要に応じて比較期間や対象を見直します。比率に直せば自動的に公平な比較になるわけではありません。分母と分子の意味が異なれば、計算結果にも同じ問題が残ります。

チーム間の情報共有は、順位を付ける以外にも使えます。業務用アプリケーションの使い方、問い合わせへの対応手順、レポートを確認する条件などを共有すれば、別のチームが同じ問題で迷うことを減らせます。比較の目的を改善の知見を得ることに置くと、必要な情報も変わります。個人の詳細を広く配るのではなく、共通する課題と対応方法を共有するために、適切な範囲を選びます。

在宅勤務と出社勤務の背景を補う

同じ人の勤務場所を比較する場合でも、その日に予定されていた業務の構成を確認します。出社日に対面の打ち合わせをまとめ、在宅日に資料作成をまとめる働き方なら、活動の違いには予定の組み方が反映されます。場所だけを原因として説明すると、改善すべき点を取り違えるおそれがあります。業務担当者には、比較の対象となった期間にどのような作業を予定していたかを確認し、PC上の記録がその一部を示していることを共有します。予定と実際が異なった場合も、その違いを追加の背景として扱います。予定表そのものを製品が自動的に取得したり、活動と対応付けたりすると想定せず、組織の既存の確認方法を使って必要な情報を補います。

勤務場所が異なると、PCの使い方だけでなく、会議や連絡の方法も変わります。在宅勤務の日にPC上の活動が増えたとしても、出社時には対面で行っていた連絡がオンラインへ移っただけかもしれません。反対に、PCから離れて資料を読む時間が増えることもあります。場所による違いを比較する場合は、同じ担当業務、同じ期間の長さ、同じ収集条件であるかを確認し、数値が変わる背景を整理します。

接続状況や利用端末が変わる場合も、活動の値に影響する可能性があります。記録が少ないときは、業務の有無を判断する前に、端末の接続や対象ユーザー、収集設定を確認します。自宅用の端末と会社の端末を使い分けている場合は、今回のレポートにどちらが含まれるかを明確にします。業務全体を確認しているつもりでも、実際には一部の端末だけを見ていることがあるためです。

在宅勤務の確認を目的としても、常に詳細な情報を広く集める必要があるとは限りません。何を改善したいのか、誰が結果を確認するのか、どの情報が判断に必要なのかを具体化します。接続の問題を解決する問いと、業務アプリケーションの利用を把握する問いでは、必要な記録が異なります。場所が変わったことだけを理由に利用範囲を拡大せず、目的に合った確認を行うことが大切です。

欠けた記録を無活動と決め付けない

調査を依頼するときは、どの日に、どのユーザーについて、どのレポートで期待と違ったのかを具体的に伝えます。「数字がおかしい」という連絡だけでは、確認の入口を決めることが難しくなります。設定した条件と実際に表示された内容を整理し、既知の一件を使って説明できると、確認すべき範囲を狭められます。調査を容易にするためという理由で、関係のない人の詳細記録までまとめて共有する必要はありません。まず必要最小限の条件を提示し、追加情報を求められた場合に範囲を確認して提供します。問い合わせへの回答を受け取った後は、原因と対処を自分の組織の手順へ反映し、同じ条件で同じ疑問が繰り返されないようにします。

レポートに必要なユーザーがいない場合や、ある日の値が予想外に少ない場合には、データの読み取りより先に条件の確認が必要です。対象グループ、ユーザーの選択、期間、表示の絞り込み、ページ送りを順番に確かめます。その後、閲覧権限、端末の接続、収集ルールを確認します。どこまで確認したかが分かるように記録しておけば、同じ問題を別の担当者が調べるときにも、最初からやり直す必要が少なくなります。

記録がないことには、複数の説明が考えられます。対象範囲に含まれていなかった、収集できる条件ではなかった、保存されている期間外だったなど、理由を調べずに仕事をしていなかったという結論へ進むことはできません。管理資料では、「活動がゼロだった」と「確認できる記録がなかった」を区別します。この違いは単なる言葉遣いではなく、後の判断の前提を左右する重要な区別です。

不足したデータを埋めるために、近い日の数値や別の人の傾向を本人の記録として扱わないようにしてください。比較のための仮定が必要な場合でも、実測値とは明確に分ける必要があります。DeskGateのレポートを使った事実確認では、実際に確認できた範囲を示します。データの不足が繰り返される場合は、対象の設定や管理手順を見直し、次の期間から必要な情報を確かめられる状態に整えます。

確認会議で使う資料を絞る

定例会議に持ち込む資料は、受け手が行う判断に合わせて選びます。チーム全体の業務改善を話し合う場に、関係のない個人の詳細な活動を並べる必要はありません。反対に、限定された担当者が具体的な問い合わせを調べる場合は、期間と対象を絞った詳細が必要になることがあります。会議の目的、参加者、確認したい事項を先に定め、資料を作ってから用途を考える順序にならないようにします。

資料には、対象期間、グループ、対象者の範囲、使用したレポートを明記します。比率や合計を取り上げる場合は、それが何を集計したものかも説明します。誰でも同じ用語を同じ意味で理解しているとは限りません。特に、アクティブ時間を実労働時間と読み替えたり、分類されていないアプリケーションを不要な利用と解釈したりしないよう、必要な注記を添えます。注記は数字の弱点を隠すためではなく、正しく判断するための条件です。

会議の記録には、数値だけでなく次の行動を残します。追加で確認する人、見直す手順、再確認する時期を決めておけば、次の会議で同じ疑問を繰り返すことを減らせます。対応の結果を確認するときも、前回と同じ条件を再現できるか確かめます。条件が変わっている場合は、その違いを説明します。レポートの確認を、継続する業務改善の一部として扱うことが重要です。

PDFの範囲と詳細の上限を確認する

DeskGateからレポートを出力したら、PDFを開いて対象ユーザー、日付、合計値を画面と照合します。出力操作が完了したことだけで、共有用の資料が完成したとは考えないようにします。受け手が必要とする情報が含まれているか、不要な対象が含まれていないかを確認します。ファイル名だけでは条件を十分に説明できない場合もあるため、資料の内容そのものを確認することが必要です。

Work Analysisで詳細を出力するときは、概要と詳細の違い、対象となる期間やユーザー、詳細レコードの制限を把握します。上限によって範囲が限られる出力を、完全な操作履歴として提示してはいけません。Daily Activityでも、表示している条件と出力条件が一致しているかを確認します。検証には、対象と日付が分かっている記録を一つ選び、画面とPDFで対応が取れることを確かめる方法が役立ちます。

PDFは、作成時点の条件で固定された資料です。後でグループや分類を変更しても、保存済みの文書が新しい条件で作り直されるわけではありません。過去の資料と今回の資料を比較するときは、条件の違いを確認します。また、出力後の資料には別途保管と共有の管理が必要です。閲覧権限を持つ人が作ったファイルであっても、そのファイルを誰に渡してよいかは、目的に応じて判断します。

改善前後を一つの数字で判定しない

改善後の確認時期も、実施した内容に合わせて決めます。新しい手順を案内した直後は、説明を読む時間や問い合わせが一時的に増える場合があります。その短い期間だけで良し悪しを決めず、どの段階の変化を観察しているかを明確にします。一方で、結果が出るまで待つという理由だけで、対象の設定や読み方の確認を先送りするべきではありません。記録が意図した範囲で集まっているかは早い段階で確かめ、業務上の変化は適切な期間で見直します。技術的な確認と、業務の改善を評価する確認を分けることで、必要な対応を遅らせず、短期的な変動を過大に解釈することも避けやすくなります。

業務の改善を行った後、アクティブ時間の増減だけで成功を判断することはできません。作業の手順が整理されて操作が減る場合もあれば、新しい業務を引き受けて利用時間が増える場合もあります。改善前に、何が変わることを期待しているのかを言葉にしておきます。問い合わせの確認が容易になる、同じ入力を繰り返さなくなる、必要な資料へたどり着きやすくなるなど、業務の目的に合った確認を行います。

変更前後の比較では、対象の人、期間、使用するレポート、収集条件を確認します。条件を完全にそろえられない場合は、比較の限界を説明します。忙しい時期と落ち着いた時期の違いを、ツール導入の効果として扱わないようにしてください。数値の変化を確認した後に、現場の担当者が何を感じたか、実際の手順にどのような違いがあったかを聞くことで、改善を複数の面から評価できます。

改善の結果が期待と異なった場合も、すぐに利用者の行動を原因と決め付けないようにします。設定、説明、対象業務、運用の時期などを見直します。何を変えたかが曖昧だと、結果の説明も曖昧になります。変更した事項と変更していない事項を整理し、次に確認する範囲を決めます。レポートは、改善を宣伝するための数字ではなく、次の判断をよりよくするための情報として使います。

権限と共有の範囲を役割に合わせる

稼働管理の目的でデータを使う場合、業務の責任者全員にすべての情報を開放する必要があるとは限りません。DeskGateの管理者権限、対象グループ、適用するルールを分けて考え、担当者の役割に合う範囲を設定します。必要なページを開けることと、必要なグループが含まれていることを、実際の担当者のアカウントで確認します。設定を行った管理者が見られることだけでは、日常の利用条件を検証したことになりません。

結果を広く共有する場合は、誰がどの判断を行うかに合わせて情報を選びます。組織の改善を話し合うために必要な集計と、個別の問い合わせを解決するための詳細は、利用する場面が異なります。共有先が増えるほど、資料の目的や読み方を明確にする必要があります。目的外の利用を避けるためにも、必要な範囲だけを渡し、後から同じ資料を別の目的へ流用する際は、改めて適切かを確認します。

利用者への説明でも、何を確認し、どのような目的で使い、誰が閲覧するかを整理します。製品を導入したことだけで、個々の利用方法が自動的に適切になるわけではありません。組織の方針と実際の設定が一致しているか、必要以上に広い確認を行っていないかを見直します。説明の内容と運用が食い違うと、記録自体が正しくても、管理の仕組みに対する理解を得にくくなります。

試行期間で読み方と担当を確かめる

初めから全社の数値を比較するのではなく、業務内容の分かっている小さな対象で試行します。対象のグループ、代表的な利用者、確認する期間、利用するレポートを決め、日常の問い合わせに答えられるかを確かめます。端末が接続され、記録が表示されることだけでは十分ではありません。担当者が数字の意味を説明できるか、分からない部分を適切に切り分けられるかまで確認します。

試行では、PC以外での作業がある日や、対象端末を使い分ける場面なども含めて考えます。記録だけで答えられない問いを把握することは、失敗ではありません。どの情報を別に確認する必要があるかが分かれば、運用の手順を整えられます。疑問が出たときに、情報システム担当者、業務責任者、利用者のうち誰が確認するのかを決め、調査が一人に集中しないようにします。

試行の終了時には、必要な情報へたどり着くまでの手順、確認に使った時間、説明が難しかった項目、共有資料の範囲を振り返ります。収集する項目を増やす前に、対象条件や説明の方法を改善できないか検討します。手順が固まったら、別のチームでも同じ確認ができるか確かめます。組織内で異なる読み方が広がらないよう、基本となる定義と確認順序を共有してから対象を広げることが大切です。

日常の判断につながる稼働管理を続ける

定例の確認を続けていると、同じ項目を出力すること自体が目的になる場合があります。資料を見る人が変わった、対象の業務が変わった、最初の課題が解決したといった節目には、確認の目的を見直します。以前は必要だった詳細が今も必要か、集計の対象は現在の業務に合っているか、結果を受けて実際に行動しているかを確かめます。目的のなくなった資料を作り続けるよりも、新たに確認が必要な問いを整理する方が有用です。また、担当者の交代時には、操作手順だけでなく、なぜその条件で確認するのかを引き継ぎます。理由まで共有されていれば、次の担当者も業務の変化に合わせて適切に見直しを行えます。

稼働管理ツールを定着させるには、数字を出す作業と、数字を使って判断する作業をつなぐ必要があります。対象期間とユーザーをそろえ、記録の意味を確認し、業務の背景を聞き、対応を決める流れを繰り返します。対応した後に何を再確認するかも決めておけば、毎回のレポートが単なる記録の保管で終わりません。必要な問いがなくなった集計は、目的を見直す余地があります。

DeskGateのWork AnalysisとDaily Activityは、PC上の活動を理解するために、それぞれ異なる角度の情報を提供します。利用する際は、活動時間を勤怠や成果と同一視せず、対象範囲と収集条件を明らかにします。合計の大小だけを追うよりも、具体的な疑問を正しい範囲で確認し、次の行動を決められることが重要です。業務の背景を知る人と記録を扱う人が協力し、説明できる判断を積み重ねることで、稼働管理を日常の支援と改善に結び付けられます。