DeskGate 業務分析ツール

依頼内容を分析条件へ置き換える

「先月の状況を見たい」という依頼を受けたら、そのまま全員分のレポートを出す前に、知りたいことを確認します。アプリケーションの利用が定着しているか、特定の部署でウェブ業務が増えたか、以前と比べて利用の傾向が変わったかなど、依頼には異なる目的が含まれます。目的が分かれば、対象のグループやユーザー、必要な期間、参照するレポートを選べます。資料の細かさも決めやすくなります。

依頼を整理する際は、確認する事実と、相手が期待している結論を区別します。「新しい仕組みで効率が上がったことを示したい」という依頼でも、実際に変化があったかは調べなければ分かりません。まず、どの仕事を対象に、どのような変化を確認するかに置き換えます。結果が期待と違っても説明できる分析条件を作ることが、資料の信頼性につながります。

期限と利用場面も確認します。経営会議で傾向を共有する資料と、担当者が具体的な記録を調べる資料では、必要な粒度が違います。すべての依頼に詳細な出力で対応すると、読み手が重要な点を見つけにくくなります。依頼者が判断したいことに対して、概要で足りる部分と追加確認が必要な部分を分けます。詳細が必要になった場合に、同じ条件で再確認できるようにしておきます。

分析の開始時には、対象に含めないものも明確にします。特定の部署だけを確認するなら、別の部署の結果から結論を補わないようにします。勤怠の判断を求められた場合には、PC利用のレポートだけでは答えられないことを説明します。できることを具体的に示しながら、必要な別の情報を整理することで、誤った前提のまま資料を作り続けることを防げます。

利用するレポートを問いに合わせる

DeskGateには、仕事の利用状況を異なる観点から確認するレポートがあります。アプリケーションやウェブサイトの使用を調べたい場合はWork Analysisを参照し、日ごとのアクティブ・パッシブ時間を確認したい場合はDaily Activityを使います。どちらを使うかは、見慣れた画面だからという理由ではなく、依頼の問いに対応しているかで決めます。項目の意味が異なる資料を、同じ指標として扱わないことが基本です。

Work Analysisの概要は、利用状況の傾向を把握する入口になります。そこからユーザー比較や詳細なアクティビティを確認し、概要で見つけた疑問を調べます。詳細を最初から全部読むのではなく、どの数字を説明したいのかを決めると確認が進めやすくなります。細かい記録が多いこと自体は、仕事の背景が分かったことを意味しません。必要な業務情報を別に確認する余地を残します。

Daily Activityでアプリケーションごとの内訳を推定したり、Work Analysisから一日の勤怠を推定したりすると、レポートの目的から外れた読み方になります。複数の資料を並べる場合は、どのレポートのどの項目を使ったかを記録します。資料をまとめた後も、元の情報へ戻れるようにすることが大切です。見た目を統一するために、定義の違いまで消してしまわないようにします。

分析中に新しい疑問が出たら、今のレポートで答えられるかを判断します。画面を細かく見続ければ必ず答えが見つかるとは限りません。端末の接続に関する問題なら状態を確認する必要があり、業務の進み方に関する疑問なら現場の説明が必要です。問いに合う情報へ切り替えることは、分析を中断することではなく、適切な根拠を探すための作業です。

グループとユーザーを照合する

Work Analysisを開いたら、グループとユーザーを依頼内容に合わせます。部署名だけで対象者を判断せず、選択されたユーザーが意図した範囲かを確認します。担当者の異動や端末交換があった場合、以前の条件をそのまま使うと対象を取りこぼす可能性があります。過去の資料と同じ条件を選んだつもりでも、組織の構成が変わっていないかを点検する必要があります。

対象者が一覧に見つからないときは、確認する順序を決めます。まず選択したグループとユーザーの条件を確認し、次に期間と閲覧権限、収集条件を見直します。必要に応じて端末の現在の接続状況も調べます。表示されないことを直ちにデータの欠損と呼ばず、対象から除かれているのか、記録を参照できないのか、別の問題なのかを切り分けます。

共有PCや複数端末を使う環境では、誰の何を表す資料なのかを明確にします。一台の端末を一人の仕事とみなしてよいか、ユーザーの選択が意図した利用を含んでいるかを確認します。分析担当が普段の端末運用を知らない場合は、資産管理や現場の担当へ問い合わせます。名前が似ていることや、過去の資料に載っていたことだけで対応を決めないようにします。

対象者の範囲を変更したときには、その理由を残します。途中で追加された人がいる場合、最初の集計と後の集計を同じ条件の結果として比較してはいけません。対象人数が変わるだけで合計値も変わります。報告の際には、どの範囲を用いたかが分かるようにし、対象の変更による差と利用状況そのものの変化を区別します。

日付と比較期間を先に固定する

日付の指定では、開始日と終了日が依頼内容に合うかを確認します。先月という言葉が暦月を指すのか、直近の一定期間を指すのかは、担当者によって解釈が違うことがあります。比較資料を作る場合は、期間の長さや営業日数も考えます。分析を始めてから都合のよい日を選ぶことがないように、原則となる期間を先に決めておきます。

繁忙期、休暇、月末処理、新システムへの移行など、期間の特徴を整理します。合計値が大きくなっていても、業務量が増えていれば当然の変化かもしれません。利用の効率を検討したいなら、業務量に関する資料が別に必要になる場合があります。PCの利用時間だけで処理の効率を計算できると考えず、どの条件まで確認できたかを明らかにします。

日をまたいだ仕事や異なる地域とのやり取りがある場合は、依頼で使う日時とレポートの日時の基準を確認します。表示された日付を読み取るだけでなく、境界付近の記録がどの期間に含まれるかを理解しておきます。環境で確認していない時刻の扱いを、一般的な経験から決めつけないようにします。比較に使った条件を記録すれば、後から疑問が出たときに確認し直せます。

期間を変更する必要が出た場合は、変更前の目的と整合しているかを見直します。追加した日付に別の業務や対象者の変更が含まれるなら、集計を分けるほうがよいこともあります。長い期間をまとめるほど正確になるとは限りません。今回知りたい変化を説明できる範囲かという観点で、日付の選び方を検討します。

フィルター適用後の表示を読み直す

グループ、ユーザー、日付を選んだ後は、レポートを実行して結果を表示します。画面の条件を変更したことと、その条件で集計が更新されたことを同じものとして扱わないようにします。表示された対象や期間をもう一度読み、依頼内容と一致するかを確かめます。以前の結果が見えている可能性を考えて確認する習慣があると、操作後の読み違いを減らせます。

ページサイズや一覧の表示にも注意します。画面に見えているユーザーだけが、対象となるユーザー全員とは限りません。ページを切り替える必要がある場合には、現在のページだけを見て人数や傾向を決めないようにします。表示されている部分と集計対象全体の違いを理解してから、比較や報告に進みます。少人数の確認でも、意図した対象が含まれているかを点検します。

絞り込みを細かくすると、結果が空になることがあります。この場合は、条件をすべて外して広い資料を出す前に、どの条件が対象を除いているかを確認します。一つずつ条件を見直せば、対象者が違うのか、期間が合わないのかを説明しやすくなります。確認のために対象を広げた場合は、その状態を本来の分析結果と混同しないようにします。

再現できる分析にするには、最終的に使った条件を記録します。途中で試した条件をすべて報告へ載せる必要はありませんが、採用した対象と期間は明示します。別の担当者が同じ条件で確認できれば、数字に疑問が出たときの対応が早くなります。画面の印象を覚えていることより、条件を正確に残していることが重要です。

概要を確認し、調べる点を絞る

概要を読む段階では、すぐに原因を説明しようとせず、確認が必要な変化を見つけます。あるアプリケーションの利用が目立つ、対象者の一部で数値の傾向が異なる、以前と比べてウェブ利用が変わったなど、観測できたことを短く記します。その時点では、理由について複数の可能性を残します。最初の印象を断定的な結論へ変えないことが、後の検討を進めやすくします。

概要には、集計によって見えにくくなる違いがあります。部署全体では安定していても、対象者や仕事の構成が変わっている場合があります。一方で、一人だけの大きな変化を全体の傾向として説明してしまう場合もあります。概要と個別の確認を行き来しながら、どの範囲の事実を述べているかを意識します。全体についての説明と個別の説明を区別して書くことが必要です。

注目する項目は、最初の問いに関連するものへ絞ります。大きな数字や目立つ変化があっても、依頼の目的と無関係なら、今回の資料の中心に置く必要はありません。必要な別の調査が見つかった場合は、その理由を整理して扱います。分析の途中で関心が移り続けると、最初に答えるべきことが曖昧になり、情報の共有範囲も広がりやすくなります。

概要の説明には、何を比較したかを添えます。「増えた」という表現だけでは、前週なのか別部署なのかが分かりません。対象人数や期間が同じか、仕事の条件に違いがあるかを示します。読み手が自分で比較の前提を確認できるようにすると、数字が単独で使われたときの誤解も減らせます。説明の短さより、必要な前提が抜けていないことを重視します。

アプリケーションとウェブを別々に分析する

Work Analysisのアプリケーション情報とウェブサイト情報は、利用状況の異なる側面を示します。両方に時間が表示されていても、項目の定義を確かめずに足し合わせて総労働時間と呼んではいけません。実際の画面の説明や凡例を確認し、それぞれが何を集計しているかを理解します。不明な項目は、独自の意味を与えず確認事項として残します。

アプリケーションの利用を読むときは、業務での役割を確認します。同じソフトウェアでも、資料作成、確認、問い合わせへの対応など用途は異なります。利用時間の増加が、仕事量の増加なのか、手戻りなのか、移行のための学習なのかは別途確認が必要です。レポートで観測した事実を示したうえで、現場に尋ねる質問を具体的にします。

ウェブサイトの利用では、サイト名や分類だけから目的を断定しないようにします。未分類の記録には、新しい業務サービスや部署独自の用途が含まれる場合があります。未分類であることを、私的利用の証拠として扱ってはいけません。どのように分類され、実際には何の仕事に使われているかを確認し、分類と業務の対応を整理します。

二つの情報を合わせて説明する場合も、直接確認できたことと推測したことを分けます。複数のアプリケーションやサイトが使われていても、画面の切り替えが業務の非効率を意味するとは限りません。必要な工程である可能性もあります。改善の提案につなげるなら、記録を基に作業手順を聞き、どの部分に見直しの余地があるかを検討します。

詳細レコードを一つずつ確かめる

概要で確認したい点が見つかったら、関連するユーザーや期間へ絞って詳細を読みます。最初は、実際の利用が分かっている記録を一つ選ぶと、画面の意味を確認しやすくなります。対象者、日時、アプリケーションやウェブサイトの表示などを照らし合わせます。既知の記録で確認した読み方を足掛かりに、他の疑問へ進むと、推測だけで分析することを避けられます。

詳細に表示されていること以上を説明しないようにします。アプリケーション名が分かっても、その中で行ったすべての操作や文書の内容を把握できると推定してはいけません。利用情報と、業務システム側にある処理の記録は別のものです。必要な事実が別の記録にある場合は、その担当者へ確認を依頼します。DeskGateのレポートを、あらゆる事実を復元できる資料として扱わないことが重要です。

一つの記録が説明できても、集計全体の正しさを無条件に保証することにはなりません。確認した範囲が今回の問いに十分かを考えます。特定の端末だけが異なる条件なら、その違いを追加で確かめる必要があるかもしれません。確認する件数を増やすこと自体を目的にせず、結論に影響する条件を優先して点検します。

詳細を確認しても理由が分からない場合には、保留する判断を残します。「原因不明」とだけ書くより、どの事実を確認し、どの情報が不足しているかを示します。これにより、次の担当者が同じ確認を繰り返さずに済みます。資料を完成させるために無理な説明を付けるのではなく、分かっている範囲を正確に伝えることが分析担当者の役割です。

Daily Activityとの違いを明示する

Daily Activityを参照するときは、一日全体のアクティブ時間とパッシブ時間を扱うことを確認します。DeskGateのヘルプにあるとおり、一日の対象は千四百四十分であり、PCの電源オンとオフの情報は含まれません。そのため、画面の数字から出勤時刻や退勤時刻を求めることはできません。時間が表示されているから勤怠資料として使える、という読み方をしないようにします。

パッシブ時間には、PC操作の少ない業務や収集範囲についての説明が必要になる場合があります。会議、電話、相談、現場対応などの仕事を、数字だけで非勤務と見なしてはいけません。必要なら対象者の業務予定や担当内容を確認します。ただし、別の情報を補った場合には、どの部分がレポートに由来し、どの部分が業務側の説明なのかを分けて記します。

Daily Activityでは、グループ、ユーザー、日付に加えて、対象者を含める選択条件も確認します。アクティブユーザーの条件は、アクティブ時間の数字そのものとは異なります。対象者が見つからないときには、どのユーザーが一覧へ含まれる条件になっているかを調べます。名称が似ている項目を同じ意味として扱わないことが、正しい絞り込みにつながります。

Work AnalysisとDaily Activityを一つの説明に使うなら、ユーザーと期間をそろえたうえで、役割の違いを明示します。前者で利用アプリケーションを確認し、後者で日ごとの活動の傾向を確認する、といった使い分けです。二つの画面にある数字を無理に一致させようとする前に、定義が同じかを確かめます。異なる集計の差を、すぐに不具合と呼ばないようにします。

数字の単位と分母を確認する

分析資料で割合を示すときは、何を全体としているかを説明できるようにします。対象ユーザーが変われば、同じ割合でも意味が変わる場合があります。合計時間、ユーザー数、日数など、計算に関わる条件を確認します。画面に表示されている指標を独自に再計算する場合は、元の指標と区別し、どの数値を使ったかを明らかにします。

大きな割合の変化が、必ずしも大きな業務上の変化とは限りません。元の値が小さいと、少し増えただけで増加率が大きくなります。逆に、部署全体の合計では小さく見える変化が、特定の仕事には重要な場合もあります。割合だけを強調せず、元の値と対象範囲を一緒に確認します。数字の見た目の強さと、業務上の重要性を分けて考えます。

合計値が変わった場合は、対象人数や期間の長さに変化がないかを確かめます。新しい担当者が加わった、休日が多かった、記録の対象が変わったなどの事情で合計は変わります。これらの違いを確認せずに、効率化や負担増加と説明すると誤解を招きます。比較に必要な条件をそろえられない場合は、その制限を明示して傾向として扱います。

単位を変換するときにも注意が必要です。分で表示された情報を時間へ直す場合、丸め方によって合計と内訳が一致しなくなることがあります。資料の見やすさのために丸めたなら、そのことが分かるようにします。わずかな差を原因不明の異常と扱う前に、表示単位や計算の方法を確認します。分析の精度は、小数点を多く表示することだけで決まるものではありません。

空の結果と予想外の数値を切り分ける

結果が空だったときには、まず対象条件を確認します。グループやユーザーを取り違えていないか、対象期間に必要な記録があるか、選択条件で対象者が除かれていないかを調べます。そのうえで権限や収集設定、端末の接続状況などを確認します。最初から広い範囲の詳細を出力するのではなく、必要な条件を一つずつ点検するほうが原因を説明しやすくなります。

数値が想定より大きい場合は、期間と対象人数を見直します。日付の終わりを誤って選んでいた、複数のユーザーを含めていた、比較している資料の単位が違っていた、といった可能性があります。数値の大小だけで収集の問題と判断せず、分析条件を先に確認します。依頼者が想定していた業務量のほうに誤りがある場合もあるため、期待値の根拠も確かめます。

接続状況を確認する場合は、現在の状態と過去の期間を分けて考えます。今つながっていることは、過去の記録が完全であることを意味しません。現在接続していないことから、過去の利用がなかったとも判断できません。確認した時点を記録し、調査対象の期間に関する事実と混ぜないようにします。時点の違いを明示すると、担当者間の話し違いを減らせます。

サポートへ相談する必要がある場合は、対象の期間、ユーザー、使ったレポート、期待した内容、実際の内容を整理します。必要以上に広い資料を送らず、問題を説明できる具体例を選びます。機密情報の取り扱いは組織の方針に従います。調査に必要な情報を明確にすることは、相談先が状況を理解する助けになり、無関係な記録をやり取りする負担も減らします。

概要PDFと詳細PDFの用途を分ける

Work Analysisの結果を共有するときは、利用可能な概要PDFや詳細PDFを目的に応じて選びます。部署全体の傾向を確認する会議であれば、概要のほうが適している場合があります。特定の記録について説明する必要があるなら、該当する範囲の詳細が必要かもしれません。詳しい資料ほど優れているとは考えず、読み手が行う判断に必要な情報を選びます。

出力前には、画面上のユーザーと日付を改めて確認します。分析の途中で条件を変えている場合、最終的に共有したい範囲と違っていることがあります。出力の直前に条件を確認する手順があると、別の調査の結果を誤って共有する失敗を減らせます。資料の題名を付ける場合も、目的と期間が分かるようにし、ファイル名だけに頼らず文書の中身を確かめます。

詳細なPDFには、レコード件数の上限が関係する場合があります。出力された文書が、選択した期間の全記録を必ず含んでいるとは決めつけないようにします。実際の環境の出力条件と制限を確認し、必要な情報が含まれるかを点検します。省略された範囲がある資料を完全な履歴と説明しないことが、分析結果を正しく共有するために重要です。

文書を開いた後は、対象者と期間に加えて、既知の記録を一つ照合します。画面の結果と文書の内容が意図した範囲で一致するかを確認します。PDFが生成できたことだけで確認を終えず、利用する資料として適切かを点検します。概要と詳細を両方使う場合には、二つの文書が同じ条件で作成されているかも確認します。

分析メモに事実と解釈を分けて残す

分析メモでは、最初に確認できた事実を書きます。対象期間、対象ユーザー、使ったレポート、観測された変化などです。その後に、現場の説明や考えられる要因を整理します。事実と解釈を同じ文章へ混ぜると、読み手がどこまで確認済みなのか判断できません。短い資料でも、両者の境界が分かる書き方を意識します。

原因について複数の説明が考えられる場合は、一つに絞って断定する必要はありません。案件数の変化、新しい手順、担当者の異動など、確認すべき要因を挙げます。どの情報があれば判断が進むかを示すと、資料が次の確認につながります。「原因を特定できなかった」という結果も、確認した範囲と不足している情報が明確なら、実務上役立つ情報になります。

数字から導いた独自の計算がある場合は、その方法を残します。対象期間の長さで割った値なのか、対象人数を調整した値なのかを明示します。元のレポートに表示される数字と、分析担当が計算した数字を同じものとして扱わないようにします。計算の前提が変われば結果も変わるため、資料を更新する担当者が条件を確認できる状態にしておきます。

メモには、今回の資料を使って判断しないことも記載できます。たとえば、アクティブ時間だけで仕事の質を評価しない、Daily Activityから始業時刻を求めないといった制限です。これらは資料の価値を下げる説明ではなく、適切な利用範囲を示すものです。数字が別の場面で引用されても、元の意図と限界が伝わるように整えます。

共有する相手と保管方法を決める

依頼者が以前の資料との比較を求めている場合には、前回の資料がどの条件で作られたかも確認します。表題に同じ部署名が書かれていても、対象者の範囲や集計期間が異なる可能性があります。元の条件が分からない資料とは、数値を並べるだけで同じ意味の比較ができるとは限りません。確認できた違いを説明し、比較できない場合はその理由を明らかにします。過去の資料に合わせるために、今回の正しい条件を曖昧にしないことが大切です。

資料を確認してもらう相手には、何を点検してほしいかを具体的に伝えます。対象者が正しいかを見る人と、業務上の説明が妥当かを見る人では、確認する観点が異なります。「内容を確認してください」という依頼だけでは、数字の再計算に時間を使い、本来確認したかった前提が見過ごされるかもしれません。担当する確認を明確にし、修正が必要な点と単なる表現の好みを分けて整理すると、資料を確定するまでのやり取りを進めやすくなります。

業務分析の資料には、利用者や業務の詳細が含まれる場合があります。共有先は、今回の判断に関わる人へ絞ります。レポートを閲覧できる担当者が、出力したPDFを誰にでも配布してよいとは限りません。組織の情報取り扱い方針に従い、必要な粒度と共有方法を確認します。資料の内容を理解する責任と、取り扱いを管理する責任の両方を意識します。

会議向けの概要と、調査担当向けの詳細を分ける場合には、どちらが何のための資料かを明示します。詳細版をそのまま会議資料へ添付することが本当に必要かを考えます。参加者が多いほど、細かな記録が判断の目的から離れて使われる可能性も増えます。目的に必要な説明を残し、不要な情報を広げないことが、資料を扱いやすくすることにもつながります。

保管場所を決めるときは、後から参照する必要と、不要になった資料を残し続けないことの両方を考えます。組織で定めた保存や削除の方針に沿って扱います。製品の画面で管理するデータと、別途出力した文書は同じ管理状態とは限りません。出力した時点で運用が終わるのではなく、その後の資料の所在も含めて手順を整えます。

資料を修正した場合は、受信者が古い版と区別できるようにします。対象期間や条件を変えたのであれば、その変更点を説明します。単に同じ名前のファイルを送り直すと、会議の参加者が異なる資料を見て議論することがあります。修正の理由と採用する版を明らかにすることで、数字の食い違いを業務上の問題と誤解することを防ぎやすくなります。

定期レポートの前に手動確認を固める

同じ内容を定期的に確認したい場合でも、最初は手動で条件と出力内容を確かめることが大切です。対象者や日付、資料の粒度が合っていないまま定期運用へ進むと、誤った資料が繰り返し使われるおそれがあります。一度正しい資料を作り、依頼者が必要な判断に使えるかを確認してから、継続的な作成方法を検討します。

DeskGateのヘルプでは、手動の結果を確認した後、定期的な配信が必要な場合にスケジュールレポートを検討する流れが示されています。利用する場合は、実際の環境で対象範囲、配信先、出力内容を確認します。未確認の設定や配信動作を前提に、資料が自動的に適切な相手へ届くと考えないようにします。繰り返す作業ほど、最初の確認が重要になります。

定例資料の条件は、組織の変化に合わせて点検します。担当者の異動、部署構成の変更、新しいアプリケーションの利用などによって、以前と同じ条件では目的を満たせなくなる場合があります。定期的に届いていることと、内容が現在も適切であることは別です。誰がどのタイミングで対象範囲を確認するかを決めておくと、資料が形だけ残る状態を避けられます。

作成の頻度も、判断の頻度に合わせて見直します。毎日読む必要がない資料を日次で作ると、重要な変化が大量の情報に埋もれることがあります。反対に、変更直後の限定した確認では短い周期が必要かもしれません。レポートを作れる回数ではなく、どの判断を支えるために確認するかを基準に、適切な頻度を選びます。

説明できる資料かを最後に点検する

共有前の最終確認では、資料を初めて読む人の立場に立ちます。対象部署と期間が分かるか、どのレポートの数字かが示されているか、確認済みの事実と推測が区別されているかを見直します。分析担当が頭の中で理解している前提は、資料に書かなければ伝わりません。長い説明を増やすより、読み違いにつながる前提の抜けを埋めることを優先します。

特に時間に関する表現を点検します。アクティブ時間を労働時間と呼んでいないか、パッシブ時間を欠勤と書いていないか、利用時間の長さを成果の大きさとして扱っていないかを確認します。レポートの値が正しくても、説明文で意味を変えてしまえば適切な資料ではなくなります。数値と文章の両方が、実際に確認した範囲へ収まっていることが必要です。

質問を受けたときに、元の条件へ戻れるかも確認します。対象ユーザー、期間、使ったレポート、出力の種類が残っていれば、必要な部分を再確認できます。一方で、調査のために保管する資料を必要以上に増やさないことも大切です。組織の方針に従いながら、判断の根拠を説明するために必要な記録を選びます。

DeskGateを業務分析ツールとして使う際には、画面を開く操作から、判断に使う資料へ整える作業までを一続きに考えます。対象を選び、定義を確かめ、概要から必要な詳細へ進み、出力後に検証します。説明できない点は保留し、現場や担当部門へ確認します。この流れを定着させることで、レポートを単なる数字の一覧ではなく、具体的な業務判断を支える資料として活用できます。