DXの利用ログで定着は分かる？操作回数と仕事の完了を分ける

架空の卸売会社は受注システムの操作ログを見ます。社長はログインが増えたので定着したと考える前に、必要な操作から受注の完了までつながっているか確認します。

ログは利用行動の一部を示す記録です。画面を開いたこと、入力したこと、正しく業務を完了したことは異なるため、定着の証拠として使う範囲を明示します。

利用ログは取りやすい数字ですが、業務の意味がなければ誤った評価になります。イベントと一件の仕事を結ぶことが先です。 参照資料のIPA DX SQUARE：デジタルガバナンス・コード3.0と関連施策で説明される考え方では、DXの現状と課題を関係者で共有し、実行と見直しへつなぎます。 以下の数値・表・判断手順は、その概念を応用した独自の架空教材です。

この章の根拠：出典1

一週間のログイン100回、入力保存80回、確定60件、出荷へ渡った55件です。同じ担当が一日に何回もログインしており、保存は再編集を含みます。

業務責任者が完了と期限、運用担当がイベントの意味、分析担当が重複と対象を確認します。社長は何の定着を確認するか決めます。

集計にはイベント名、対象期間、除外条件を残します。システム更新でイベントの記録方法が変わる時は、比較前後を確認します。

保存80回を80件の受注とせず、受注番号で重複を除きます。確定60件のうち出荷へ渡った55件なら、残る5件の状態を確認します。

利用の多さより、業務がどこで止まったかが分かります。55件を60件で割る約91.7％は確定後の受け渡し率で、全社の定着率ではありません。

確定した5件が出荷日待ちなら異常ではありません。期限を過ぎた滞留と通常の待ちを分け、ログだけで担当の未実行と断定しないようにします。

比較表は横に動かして全ての列を確認できます。

ログイン、保存、確定、受け渡しを別のイベントとして並べます。画面外の承認や手作業が残る場合は、ログにない工程も記録で確認します。

利用されない理由は説明不足だけではありません。不要な入力、業務に合わない状態、権限の不足を分け、対応を変えます。

イベントの意味が不明なら利用率を計算しません。アクセス回数を社員の勤勉さの評価へそのまま使うことも避けます。

比較表は横に動かして全ての列を確認できます。

受注番号ごとに状態と対象日を照合します。止まった案件は入力不足、権限、提供待ち、連携失敗などの理由へ分けます。

ログが想定どおり記録されるか、正常な一件と例外の一件で確認します。利用者が回避操作をしていないか、現場の説明と照合します。

個人を追う必要がない分析では集計単位を絞ります。仕事の改善目的を共有し、必要以上の詳細ログを複製しないようにします。

結果から操作説明、業務範囲、権限、連携の対応を選びます。次の確認では、ログ数より未完了の理由が減ったかを見ます。

確認の完成は、イベントの意味、業務の段階、未完了理由、対応がつながった状態です。アクセス数のグラフだけで結論を出しません。

ログを記録できる範囲は製品や設定で異なります。記事のイベントは架空であり、自社の実際の記録内容を確認して置き換えます。