DeskGate ヘルプセンター
DeskGate 業務可視化ツール
業務可視化ツールを導入する前に、確認したい業務と判断基準を整理。DeskGateの記録を改善の対話につなげる手順を解説します。
業務可視化ツールを導入しても、組織の仕事が自動的に理解できるようになるわけではありません。仕事の量、処理の流れ、相談に必要な時間、利用するアプリケーションなど、見たいものによって必要な情報は異なります。最初に決めるべきなのは、どの画面を使うかではなく、何を改善するために何を把握したいかです。その問いが明確になると、集めた情報を眺めるだけの運用から、具体的な判断につながる運用へ進めます。
DeskGateは、PC上で記録されたアプリケーションやウェブサイトの利用状況を確認し、仕事の進め方を検討するための情報を提供します。Work AnalysisやDaily Activityを使う際も、表示される活動と仕事全体を同一視せず、現場の説明と組み合わせることが重要です。ここでは、業務可視化を企画する担当者が、対象業務の選定から試行、関係者との対話、改善後の振り返りまでを組み立てる方法を紹介します。
見えるようにしたい問題を選ぶ
業務を見えるようにしたいという要望の背景には、さまざまな問題があります。担当者しか手順を知らない、問い合わせ対応が特定の人に集中している、システムを増やしたのに使い分けが整理できていない、といった事情です。これらを一つの指標で解決しようとすると、必要な情報と関係の薄い数字が混ざります。まず、現場が困っていることを具体的な言葉で聞き、一つの問題から始めます。
問題を選ぶときは、数字を見た後に取れる行動を考えます。利用が少ないアプリケーションが見つかったら、使い方を案内するのか、業務手順を見直すのか、契約の検討材料にするのかを整理します。行動が決まらない場合は、目的がまだ広すぎる可能性があります。可視化の成果を「グラフができたこと」で終わらせず、誰がどの判断を行うための情報かを明確にします。
一方で、最初から改善策を決めつけないことも大切です。たとえば、利用時間が長いアプリケーションを減らせば効率が上がる、と仮定してしまうと、必要な作業まで削ろうとするおそれがあります。作業量の増加や、他の手順からの移行が理由かもしれません。調査前には複数の説明を考えておき、記録と現場の話を確認しながら、どの説明が妥当かを検討します。
対象の問題がPCの外で起きている場合もあります。承認がなかなか返らない、相談先が分からない、資料の保管場所が統一されていないといった状況では、PC利用の記録だけで全体を把握できません。可視化ツールの得意な範囲を使いつつ、必要に応じて業務の聞き取りや手順の確認を組み合わせます。最初の段階で分からない範囲を認めることが、現実的な設計につながります。
仕事の流れと端末上の活動を描き分ける
仕事の流れには、依頼を受ける、内容を確認する、処理する、承認を受ける、相手へ返すといった段階があります。PC上の活動は、その各段階で使う道具や操作の一部を表します。両者は関連しますが、同じものではありません。アプリケーション名が変わったから工程が切り替わったと判断するのではなく、実際の手順との対応を確かめる必要があります。
最初の整理では、現場の担当者に普段の仕事を順番に説明してもらいます。細かな例外をすべて列挙する前に、通常の流れを把握します。そのうえで、PCで行う部分、会話や確認が中心になる部分、他部署の返答を待つ部分を区別します。どの段階ならDeskGateの利用情報が役立つかが分かれば、レポートに現れない部分を無理に数字へ置き換える必要がなくなります。
たとえば、同じウェブサービスを複数の工程で使う仕事では、サービス単位の利用時間だけで工程ごとの負荷を分けることはできません。別の業務資料や担当者の説明が必要になります。逆に、アプリケーションが工程ごとに分かれている場合でも、起動していた時間がそのまま工程の所要時間になるとは限りません。ツール間の対応を慎重に確認し、観測できる範囲だけを説明します。
業務の流れを整理するための図やメモは、DeskGateが自動生成するものとして紹介するのではなく、組織側で行う分析の資料として扱います。利用レポートを使って現場の説明を補い、図やメモの内容を点検します。製品の記録と人が作成した解釈を分けて残すと、後から仕事の進め方が変わったときにも、どの部分を見直すべきか判断しやすくなります。
対象部署を小さく選び、例外を把握する
全社の業務を一度に可視化しようとすると、職種ごとの違いが多く、目的も曖昧になりがちです。まず、業務の説明が得られ、改善について話し合える部署やチームを選びます。人数の少なさだけで決めるのではなく、対象の仕事に一定のまとまりがあるか、運用を確認する担当者がいるかを重視します。試行で得た理解を、次の対象へ広げるための材料にします。
対象部署を選んだら、その中にどのような働き方があるかを確認します。複数の端末を使う人、共有PCを使う人、現場作業が多い人、外出先で対応する人など、記録の見え方に影響する条件があります。平均的な一人だけを想定すると、実際の運用で説明できない結果が増えます。重要な違いを把握し、試行の対象に含めるか、別の確認が必要かを決めます。
試行する部署が全社を代表しているとは限りません。事務中心のチームで分かったことを、訪問業務の多いチームへそのまま当てはめることはできません。対象を選んだ理由と、対象外の働き方を記録しておきます。この記録があると、試行の結果がよかったという理由だけで、条件の違う部署へ急いで広げることを防げます。展開時の確認点も明確になります。
例外を見つけることは、試行が失敗したことを意味しません。通常の業務説明では見えなかった条件が分かったのであれば、導入前に得られる重要な情報です。例外がどれほど頻繁に発生し、どの判断へ影響するかを整理します。すべての例外に別の手順を作る必要はありませんが、主要な結果を大きく変える条件は、レポートの説明に含めるようにします。
現場と管理側で共通の問いを持つ
管理側が知りたいことと、現場が改善したいことは必ずしも一致しません。管理側はアプリケーションの利用状況を知りたい一方、現場は入力の重複や資料探しの負担を減らしたいかもしれません。双方の関心を共有し、今回の可視化で扱う問いを決めます。目的を一方的に説明するだけでなく、記録を使うことで現場にもどのような検討材料が得られるかを具体化します。
共通の問いは、誰かの行動を評価する言い方より、仕事の仕組みに注目した言い方にすると話し合いやすくなります。「使い方が遅い人は誰か」ではなく、「どの作業で同じ情報を繰り返し確認しているか」と考えます。ただし、ログだけで重複作業の理由まで分かると期待しないようにします。現場の説明を聞くための問いとして扱い、記録から確認できる点と分けて整理します。
話し合いでは、部署全体の傾向を見てから、必要な範囲だけ詳細へ進む順番を検討します。はじめから個人別の細かな記録を広く共有すると、改善の議論より数値の説明に時間を取られることがあります。誰がどの粒度の情報を見る必要があるかを決め、目的に合った資料を選びます。参加者全員が同じ量の情報を持つことより、同じ問いを理解していることが重要です。
説明への反応も、設計を見直す材料になります。対象者から「この作業はPCに表れない」と指摘されたなら、その仕事が全体の中でどの役割を持つかを確認します。記録に含まれないことを理由に仕事の価値を小さく扱わず、必要な補足情報として整理します。現場の知識を取り入れることで、画面だけでは作れない実用的な業務理解に近づけます。
導入前の状態を説明できるようにする
改善の前後を比べるには、変更前の状態を記録しておく必要があります。しかし、数字があれば何でも基準になるわけではありません。対象期間が繁忙期だったのか、担当者の休暇が多かったのか、システムの移行中だったのかによって解釈が変わります。基準となる期間を選んだ理由を記し、その期間の仕事の条件を確認します。後から同じ条件を完全に再現できなくても、違いを説明できる状態を目指します。
Work Analysisを使う場合は、対象のグループ、ユーザー、日付を決めてレポートを実行します。アプリケーションとウェブサイトの利用状況を確認し、今回の問題に関係する情報を選びます。使っている道具の数が多いこと自体を問題とせず、それぞれがどの仕事を支えているかを確かめます。利用状況は基準の一部であり、案件数や成果物などの業務資料も必要に応じて合わせます。
基準を作るときには、分からない項目も記録します。たとえば、一つのアプリケーションが複数の業務に使われているため、仕事別の内訳は判断できない場合があります。無理に割合を作るより、現状では区分できないと示したほうが、次に必要な確認が明確になります。細かい表を埋めることより、説明できる情報と説明できない情報の境界を守ることが重要です。
基準資料は、改善前の組織を固定的に評価するためのものではありません。後で変化を確認するための参照点です。試行中に業務の理解が深まり、基準の選び方に問題が見つかった場合は、理由を残して修正します。ただし、施策の結果がよく見えるように都合のよい期間へ置き換えることは避けます。変更の理由と影響が分かるように管理すれば、分析の信頼性を維持できます。
利用アプリケーションの役割を整理する
アプリケーションの一覧を見ると、使われている道具の多さに目が向きがちです。業務可視化では、数を減らすことを先に目的とせず、各アプリケーションが何を担っているかを整理します。受け付け、処理、確認、報告など、仕事の段階と関係付けます。同じ目的に複数の道具を使っているように見えても、担当者や案件の違いで必要な役割が分かれている場合があります。
DeskGateのWork Analysisで利用の傾向を見つけたら、実際の手順を知る担当者と確認します。利用が集中しているアプリケーションに重要な業務が集まっている可能性もあれば、使いにくさのため時間がかかっている可能性もあります。利用時間の長さだけでは両者を区別できません。どの仕事で使い、何が終われば次へ進めるのかを聞くことで、改善の候補を具体化できます。
新しいアプリケーションを導入した場合には、利用が確認できることと、仕事が期待どおり変わったことを別々に確かめます。起動や利用があっても、従来の手順と二重に作業している可能性があります。現場の負担を確認し、旧手順をやめる条件が整っているかを検討します。可視化によって導入の進み方を確認できても、運用を切り替える判断は仕事の内容を踏まえて行います。
利用が少ないアプリケーションについても、すぐに不要とは判断しません。月末だけ使う、特定の例外案件で必要になる、緊急時に備えているなどの用途があります。調査した期間に使用がなかった理由を確認し、役割と利用頻度を分けて整理します。ソフトウェアの見直しに情報を使うなら、使用実績の数字だけでなく、業務上必要な条件や代替手段の有無も検討します。
ウェブ業務をサイト名だけで分類しない
ウェブサービスを使う仕事では、同じサイトの中に連絡、資料共有、申請、検索などの機能が含まれます。サイト名だけで業務の種類を決めると、現場の使い方とずれることがあります。Work Analysisで確認できるウェブ利用を、まず仕事の説明と照らし合わせます。記録された情報の範囲を確認し、表示されていない内容まで推定しないようにします。
業務用と私用を分ける分類を使う場合でも、その分類が仕事の実態に合っているかを点検します。ある部署では情報収集に必要なサイトが、別の部署ではあまり関係しないこともあります。未分類の利用を問題とみなす前に、新しいサービスや例外的な業務の有無を確認します。分類は判断を補うための整理であり、個々の利用理由を完全に説明するものではありません。
ウェブ利用が長くなったときは、仕事の負荷だけでなく、手順の変更も調べます。以前はメールや紙で処理していたものをウェブへ移したなら、利用の増加は移行の結果かもしれません。また、一つの仕事に必要なサイトが増えた場合は、情報の移し替えや確認の往復が増えていないかを現場に聞きます。記録の変化をきっかけに、具体的な作業の説明へ進めると有用です。
資料を共有する際は、調査担当が見た詳細をそのまま広げず、会議の目的に必要な粒度にします。業務の流れを検討する会議なら、サービスの役割や利用の傾向が分かれば足りる場合があります。必要以上の詳細は議論を複雑にし、取り扱う情報も増やします。何を省略し、何を残すかは、情報を隠すためではなく、判断に必要な焦点を保つために決めます。
活動時間を負荷の手掛かりとして扱う
アクティブ時間は、PC上の活動について考える手掛かりですが、そのまま業務負荷や成果の大きさを表すわけではありません。難しい判断をする時間や、他者を支援する時間など、操作の多さと一致しない仕事があります。活動時間が多い人を必ず優れていると見たり、少ない人を問題視したりすると、可視化の目的が業務改善から離れてしまいます。数字が表す範囲を説明して使います。
Daily Activityは、一日全体のアクティブ・パッシブ時間を確認するためのレポートです。対象は一日の千四百四十分であり、PCの電源オンとオフの時間を示すものではありません。この結果だけで始業、終業、欠勤を判断することはできません。勤怠や労働時間に関する管理が必要な場合は、組織が定めた別の記録や手続きを参照し、利用レポートとは目的を分けて扱います。
負荷の偏りを検討するなら、活動時間に加えて、担当案件の種類、支援の役割、手戻りの有無などを確認します。処理件数が同じでも、案件の難しさが異なれば必要な仕事は変わります。ログから説明できない部分を現場の情報で補い、単純な比較を避けます。数字を使う目的は、誰かを一つの順位に置くことではなく、負担が生じる条件を理解して見直すことです。
傾向の変化が小さい場合にも意味があります。新しい手順を入れた後、仕事の質を維持したまま利用状況が安定しているなら、運用が定着しつつある可能性があります。ただし、それだけで成功と断定せず、成果物や問い合わせの状況など、最初に決めた確認事項と合わせます。指標を一つだけ選んで結論を作るのではなく、判断に必要な材料がそろったかを確認します。
待ち時間の原因を現場と確かめる
PC操作が少ない時間帯を見つけても、それが業務上の待ち時間なのかは別途確認が必要です。電話や会議、紙の資料を使う作業、現場での対応など、操作が記録されにくい仕事かもしれません。接続や収集条件に関する事情もあり得ます。活動が少ないという観測から、仕事が止まっているという結論へ飛ばず、その時間にどのような業務があったかを聞きます。
実際に待ち時間があると分かった場合は、誰の返答を待っているかだけでなく、次へ進むために何が必要かを整理します。承認内容が不明確なのか、依頼時の情報が足りないのか、確認する時間帯が決まっているのかで対策は異なります。DeskGateの記録は変化を確認する補助になりますが、業務上の条件を自動的に説明するものではありません。人が仕事の流れを確かめる工程を残します。
待ち時間をなくすこと自体が正しいとは限らない場面もあります。品質確認や安全確認など、必要な点検のために設けられている時間があります。見直しでは、待ちを短くした場合に何が失われるかも考えます。処理の速さだけを目的にすると、後工程の修正や問い合わせが増えるかもしれません。改善前後の比較には、時間以外の業務上の結果も含める必要があります。
対策を試す場合は、一度に多くの条件を変えず、何を変えたかを分かる形で残します。依頼の様式をそろえた、確認の担当を明確にしたなど、実施した変更を記録します。その後に利用状況と現場の説明を確認すれば、変化を検討するための材料になります。数字が改善したように見えても、対象の仕事量が減っただけではないかといった別の可能性を確認します。
短い試行で運用の負担を測る
試行では、製品の画面が開くことだけでなく、運用担当者が必要な情報を取り出して説明できるかを確かめます。対象者と期間を選び、レポートを実行し、既知の利用記録と照合する一連の作業を行います。どこで迷い、どの条件を確認し直したかを記録すると、正式運用の手順に必要な説明が見えてきます。機能の一覧より、実際の判断に至る過程を重視します。
試行期間の長さは、対象業務の周期に合わせます。毎日発生する仕事なら比較的短い範囲でも理解できることがありますが、月次処理が中心なら必要な日を含めなければ判断できません。短い期間で結果を急ぐより、何を確認できて何が未確認かを整理します。期間を延ばす場合も、ただ多くのデータを集めるのではなく、追加で確認する問いを明らかにします。
運用の負担には、レポートを作る時間だけでなく、結果を説明し、問い合わせに答える時間も含まれます。管理担当が数字をまとめられても、現場が毎回同じ誤解を解く必要があるなら、資料の作り方を見直す余地があります。用語や対象範囲を明示するだけで負担が減る場合もあります。試行の段階で、継続して使える頻度と資料の粒度を検討します。
試行を終える条件は、数字が大きく変わったかどうかだけでは決めません。対象の仕事を説明できたか、必要な閲覧範囲を定められたか、出力資料を適切に扱えるかなども確認します。分からない点が残る場合は、正式運用へ進む前に誰が判断するかを決めます。試行の結果を成功か失敗かの二択にせず、運用に必要な条件がそろったかという観点で整理します。
改善の仮説を一つずつ検討する
業務可視化で見つかった傾向は、改善策を検討する出発点です。特定のアプリケーション利用が長いときには、操作説明が必要なのか、仕事が集中しているのか、手順を変えられるのかを考えます。最初に思い付いた対策が正しいとは限りません。いくつかの可能性を挙げ、実施しやすさだけでなく、目的に合っているか、別の負担を生まないかを確認します。
仮説には、期待する変化と確認方法を添えます。「資料の場所をそろえると、確認の往復が減るのではないか」と考えたなら、現場がどのような変化を感じるか、利用レポートで何を補助的に確認するかを決めます。ログに直接表れない変化が中心なら、無理に数値へ置き換えず、別の業務資料や聞き取りで確かめます。確認方法と仮説の対応を明確にすることが大切です。
改善後の結果を読むときは、施策以外に変わった条件を調べます。人員の増減、案件数、休日、繁忙期、使用する端末などが変わっていれば、単純な前後比較はできません。変化を一つの施策の効果として断定せず、どの条件をそろえられたかを説明します。数字に根拠があることと、因果関係が確認できたことを分けて書くと、次の判断に使いやすくなります。
期待した変化が出なかった場合も、現場で何が起きたかを確認します。新しい手順が利用されていないのか、別の問題が残っているのか、指標が変化を捉えていないのかで次の対応は異なります。結果が出ないことを理由に測定項目を増やし続けるより、最初の問いと確認方法を見直します。何が分かったかを残せば、同じ試行を繰り返す負担を減らせます。
会議資料を判断に必要な形へ整える
可視化の結果を共有する会議では、情報を多く載せるほど議論が進むとは限りません。まず、今回の問い、対象部署、期間、利用したレポートを示します。その後に観測された傾向と、現場で確認した事情を分けて説明します。結論だけを先に示すと、読み手が前提を確認できません。逆に、すべての詳細から説明を始めると、何を判断すればよいかが見えなくなります。
Work AnalysisのPDFを使う場合は、概要と詳細のどちらが会議の目的に合うかを選びます。出力後に対象ユーザー、日付、必要な記録が含まれているかを確認します。件数の制限が関係する場合には、その範囲を理解して説明します。画面で見た内容を出力したから完全な履歴になっている、と決めつけず、資料として使う前に内容を照合する手順を入れます。
会議資料には、まだ判断できないことも載せます。利用時間が増えた理由が複数考えられるなら、その状態を示し、追加で何を確認するかを決めます。不確かな部分を消して分かりやすくするのではなく、決められることと保留すべきことを分かりやすくします。この整理があると、会議の場で根拠のない推測が広がることを防ぎやすくなります。
個人別の詳細が必要でない会議には、必要な傾向だけを持ち込みます。情報の粒度を変える場合は、どのように対象をまとめたかを説明できるようにします。単に名前を隠せば扱いが同じになるとは考えず、資料の内容と共有先を確認します。会議が終わった後の保管場所や参照する人も含めて、組織の情報取り扱い方針に沿って管理します。
権限と責任の分担を設計する
業務可視化に関わる人には、端末を管理する担当、レポートを確認する担当、仕事の内容を説明する担当、改善を決める担当がいます。一人が複数の役割を担う場合でも、役割を言葉にしておくと、どこで確認が必要か分かりやすくなります。情報システム部門が技術的な設定を行えることと、業務上の評価を決めることを同一視しないようにします。
閲覧範囲は、職位の高さだけで一律に決めるのではなく、担当する仕事と利用目的に合わせて検討します。必要なユーザーや部署の範囲を明らかにし、実際の環境で想定どおりに参照できるかを確認します。権限の設計に関して未確認の製品機能を前提にせず、利用する版と設定で確かめます。資料を出力した後の共有ルールも、画面の閲覧と合わせて決めます。
運用中に担当者が変わる場合は、レポートの操作だけを引き継がないようにします。対象部署を選んだ理由、分類の考え方、未確認の事項、過去の改善の経緯なども必要です。数字を見る作業は同じでも、背景を知らないと以前と違う解釈になることがあります。手順書には、変更してよい条件と、変更前に関係者へ確認すべき条件を整理しておきます。
問題が見つかったときの連絡先も定めます。対象ユーザーが見つからない場合、表示値に疑問がある場合、利用目的について相談がある場合では、対応する担当が異なるかもしれません。問い合わせを一つの窓口で受けるとしても、内部で誰が何を確認するかを明確にします。対応が滞らないことが、日常的な可視化を維持するうえで重要になります。
記録と対話の両方で変化を評価する
改善後の振り返りでは、レポート上の変化と、現場の仕事の変化を別々に確かめます。利用時間が減ったとしても、作業を別の担当者へ移しただけかもしれません。反対に利用時間が変わらなくても、確認漏れが減り、担当者の不安が小さくなっている場合があります。可視化の目的に応じて、どの変化を重視するかをあらかじめ決めておきます。
現場の感想を聞くときは、「よくなったか」だけではなく、どの作業がどう変わったかを尋ねます。依頼の内容を確認する回数が変わった、必要な資料にたどり着きやすくなったなど、具体的な説明を得ます。こうした説明を記録の傾向と照らし合わせることで、次の改善候補を考えやすくなります。感想だけ、数字だけのどちらかに寄せず、両者の関係を確認します。
施策を続けるかどうかの判断には、維持する負担も含めます。毎週の資料作成や確認会議が増えたなら、その負担に見合う判断ができているかを検討します。一定の理解が得られた後は、確認頻度を下げてもよいかもしれません。改善のために始めた可視化が、新たな作業を増やし続ける状態にならないよう、運用自体も見直しの対象にします。
成果の説明では、実際に確認できた範囲を守ります。利用レポートが変わったことから、利益や生産性の向上まで自動的に計算することはできません。金額や効果を示す必要がある場合は、その計算に使う業務上の根拠を別途確認します。根拠のない効果を盛り込むより、どの判断がしやすくなったか、どの作業の問題を理解できたかを具体的に示すほうが有用です。
展開範囲を広げる前に条件を確認する
一つのチームで使い方が定着したら、次の部署へ展開する条件を整理します。対象となる仕事、端末の使い方、管理する担当者、必要な資料の粒度が似ているかを確認します。似ている部分は手順を再利用できますが、異なる部分は改めて設計します。全社で統一することが目的ではなく、各部署で同じ意味の情報を適切に使えることを重視します。
展開時には、以前の試行で使った分類や比較基準がそのまま当てはまるかを確かめます。部署によって同じアプリケーションの役割が違う場合、共通の数字で評価すると誤解が生じます。比較する必要があるなら、仕事の違いを説明できるようにします。比較が不要な場合には、無理に全社の順位表へまとめず、それぞれの部署で改善に使える情報を選びます。
端末やユーザーの管理も、展開が広がるほど重要になります。対象者の異動、端末交換、新しいアプリケーションの利用などが反映されているかを確認します。利用レポートの対象が正しくなければ、どれほど丁寧に分析しても結論はずれます。各部署で変更を伝える担当と、設定や対象範囲を確認する担当を決めることで、拡大後も記録の意味を保ちやすくなります。
可視化の対象を増やす判断と、記録の詳細を増やす判断は別に考えます。新しい部署へ展開するからといって、すべての情報を同じ粒度で集める必要があるとは限りません。目的に対して必要な範囲を検討し、関係者への説明や組織の方針と一致させます。運用を大きくするほど、当初の目的からずれていないかを確認する機会を設けることが大切です。
続ける指標とやめる資料を決める
可視化を継続すると、資料や指標は増えやすくなります。以前の疑問に答えるために作った表が、そのまま定例資料として残ることもあります。定期的に、誰がどの判断に使っているかを確認し、使われていない資料を整理します。作成をやめることは情報管理の後退ではありません。必要な問いへ時間を使えるようにするための、運用の改善です。
継続する指標には、意味、対象、確認頻度、変更時の扱いを添えます。アプリケーション利用を見るなら、何の仕事に関係し、どの期間と比較するかを示します。Daily Activityを使うなら、その時間がPCの電源情報や勤怠を示すものではないことを共有します。担当者が変わっても意味が変わらないようにしておくと、長期的な比較の読み違いを減らせます。
新しい課題が出た場合には、既存の資料へ項目を足す前に、その課題に今の記録が適しているかを確認します。別の業務情報が必要なら、可視化の設計も変わります。DeskGateで確認できる利用状況を有効に使いつつ、製品の外で確認すべき事実は分けて扱います。一つの仕組みにすべてを求めないことで、情報の意味が明確になり、現場との対話も進めやすくなります。
業務可視化ツールを活用するためには、画面の情報を仕事の問いへ戻す習慣が必要です。対象と期間を確かめ、記録の限界を理解し、現場の説明を聞き、改善を小さく試します。DeskGateのレポートをこの流れの中に置くことで、数字を集める作業にとどまらず、仕事の仕組みを理解し、次に何を変えるかを考えるための資料として使うことができます。