データを求める管理者と、業務を遂行する現場のすれ違い
そのデータは、誰が入力しているのか
例えば、障害から復旧した直後を考えてみます。担当者はログを確認しながら、インシデント管理ツールを更新します。その後、報告書と管理者向けの週次レポートにも、同じ発生時刻や対応内容を入力する。サービスは戻っても、仕事はまだ終わりません。
管理者には、障害の傾向や未完了の対策を把握したい理由があります。現場も、記録の必要性は分かっています。それでも、見る側が便利になるほど、入力する側の仕事が増えるなら、システムは使い続けにくくなります。
私は本業でITシステムの運用・監視・統制を効率化するシステムを開発し、SRE領域を経験しています。副業ではHR業務を支援するAIプロダクトを開発しています。両方を考える中で気になるのは、データを使う人と作る人の価値が一致しない問題です。以下の業務場面は、構造を説明する例です。
IT運用：記録は必要。でも、何度も書く必要はあるのか
IT運用の現場では、復旧と安定稼働が優先されます。一方で、障害報告、変更管理・構成管理の記録、監査や統制のエビデンス、稼働状況・対応状況のレポートも必要です。これらが別々の様式で求められれば、確認や転記が増えます。
Google SREのインシデント管理では、復旧作業と関係者への連絡を役割として分け、対応中の状況を共同編集できる文書に残します。その文書は引き継ぎや事後分析にも使われます。記録は管理者への報告だけでなく、対応を続ける現場自身の道具です。 [1]
ポストモーテムも、発生したことを記録して終わりではありません。影響、原因、対応、再発防止策を整理し、個人を責めずに学ぶためのものです。 [2]
HRでも、可視化の前にデータを集める仕事がある
人事評価の進捗を知るには、各部署の提出状況が要ります。採用選考の状況は面接官の評価待ちかもしれません。従業員情報の更新、研修受講状況の管理、組織サーベイの実施・集計でも、人事担当者だけでは情報が完結しません。別ツールやメールに情報が散らばれば、関係部署への確認、催促、転記が増える可能性があります。
リクルートマネジメントソリューションズの2023年調査でも、データ活用の課題に、分析スキルの不足や社内への開示範囲の判断の難しさが挙がっています。従業員300名以上の企業の人事管理職325名への調査です。 [4] これらはデータの運用上の課題を示しますが、ダッシュボードが入力負担を増やしたという因果関係まで示すものではありません。
| IT運用 | HR業務 |
|---|---|
| 復旧・再発防止・監査を支える | 採用・育成・配置などの判断を支える |
| 操作履歴や判断の経緯を残す | 個人情報・機密性・評価の公平性に配慮する |
HRでは、つながる情報をすべて見せればよいわけではありません。利用目的に合わせて閲覧範囲を絞り、小さな部署のサーベイでは個人が推測されないよう配慮する。評価データも、未入力を低評価と混同せず、判断の根拠や訂正の手続きを用意したいです。これは私の設計上の考えです。
組織横断の業務は、APIだけではつながらない
採用担当者は候補者対応、面接官は担当業務、管理者は採用計画を優先します。誰かが非協力的でなくても、更新の優先順位はそろいません。「面接が終わったら更新する」だけでは、誰が、どこを、いつまでに直すのかが曖昧です。
例えば面接官が評価を入力し、採用担当者が選考段階を確定する、と責任を分けます。担当変更時には未完了の案件と更新権限も引き継ぎます。技術的に連携できても、何をもって完了とするかが違えば、誤った進捗が速く共有されるだけです。
戦略的人事とSystemic HRから考える
Ulrich：管理の効率と戦略的価値を両立する
Dave Ulrichの『Human Resource Champions』（1997年）は、人事の役割を、戦略的パートナー、管理業務の専門家、従業員の支援者、変革の推進者の4つから捉えます。出版社の紹介も、4領域で同時に役割を果たす必要性を説明しています。 [5]
私の解釈では、戦略に使うデータを増やす一方で、人事担当者の作業を増やしてしまう設計は、この両立から離れます。集計できたかに加えて、現場の仕事が進みやすくなったかも見たいです。これは同書が入力システムについて直接述べた主張ではありません。
Bersin：機能別の施策から、事業の課題へ
Josh BersinはSystemic HRで、採用、育成、報酬などを個別に最適化するだけでなく、事業課題を中心に連携させる考え方を示しています。共有する優先順位や責任、分野をまたぐ協働も重視しています。 [6]
“problems” not “programs”
Josh Bersin（2023） [6]
私はこれを、何を集計するかより先に、何を改善するためのデータかを共有する必要がある、と読みます。例えば離職への対応なら、サーベイの集計だけでなく、配置や育成の担当者も使える情報が要ります。Systemic HRは単なるツール統合の理論ではなく、ここから先のプロダクトへの応用は私の考察です。
現場にも価値が返るシステムにするには
例えば、変更管理の承認記録と実行ログを関連づければ、報告のたびに証跡を集め直す負担を減らせます。ただし、ログだけでは変更理由や影響の判断は残りません。人が明示的に記録する部分と、自動取得する事実を分けます。
採用でも、面接の予定時刻が過ぎただけで「評価完了」にしてはいけません。評価が確定したことを人が記録し、その結果を進捗表示へ反映する。自動化できたかより、実際の仕事とデータが一致するかが大切です。
データを集めるために、仕事を増やしてはいけない
正確なデータがあれば、管理者は支援が必要な現場を見つけられます。現場も、その情報で仕事が進むなら、記録する意味を持てます。目指すのは、どちらかに我慢してもらうことではありません。
第1記事では、改善する余力がない構造を考えました。今回は、可視化のための追加入力が、その余力をさらに削りうる点を考えました。次回は、従来のSaaSによる業務標準化と、AIエージェントによる業務遂行の違いを掘り下げます。
関連記事：なぜ現場は、業務改善する余裕すらないのか
参考文献
[1] Andrew Stribblehill／Google（2016）Managing Incidents。
[2] John Lunney・Sue Lueder／Google（2016）Postmortem Culture: Learning from Failure。
[3] 経済産業省（2024）人的資本経営に関する調査結果（2024年調査・概要）。
[4] リクルートマネジメントソリューションズ（2023）人事データ活用に関する実態調査。
[5] Dave Ulrich（1997）Human Resource Champions。
[6] Josh Bersin（2023）Redesigning HR: An Operating System, Not An Operating Model.。
Ulrichは出版社の紹介・公開書誌を参照しました。1997年版の書誌に対し、出版社の発売日表記は1996年10月30日です。本文未確認部分の逐語引用はしていません。Googleの2章はSRE書籍（2016年刊）を参照。資料の要約と、私の解釈・設計例を区別しています。
コメント