「人事業務プロセス改革活動」を振り返ってみて
約２年間取り組んで来た、”人事部門の業務プロセス改革活動”について、一区切りついたこのタイミングで振り返ってみました。人事全体を横断的に見て、様々な関係者と一緒に進めた今回の活動はとても学びが多く、記憶が薄まる前に記録に残したいと思い、記事を書くことにしました。
なぜ振り返りが必要だと思ったのか？
今回、思い立って一度記事に纏めておこうと思ったのには理由が２つあります。一つ目は、”整理することで定着するから”です。これまでの経験上、３〜４年毎に新しい環境に移ることが多いですが、そこで得た経験でしっかりと土台を固めて、次のステップに移りたい。そのため、定期的に知識や経験を整理する事を習慣にしています。
二つ目は、”同じような活動をする人の参考にしてもらいたい”と思ったからです。この様な部門横断的な活動は、どの組織でも定期的にあると思います。ただ普段プロジェクトベースでの仕事が多くない人事部門のメンバーは、プロジェクトの進め方に慣れていません。また、そもそも何から手をつければいいのかさっぱり。。ということもあるかと思います。
もちろん、うまくいったことばかりではなく失敗もたくさんありましたが、それも含めて今後取り組む方々の参考になれば嬉しいです。
人事業務プロセス改革が必要だった背景
そもそも、今回私たちの会社でなぜ業務プロセス改革活動に取り組んだ理由は３つあります。
①可視化ニーズ
人生100年時代、新卒から定年まで一社で勤め上げることが当たり前で無くなり、転職が一般的になっています。人の入れ替わり＆引き継ぎがこれまで以上に頻繁に発生するようになり、業務を可視化しておくことの重要性が上がったと感じています。後述しますが、業務プロセス改革の０番地はAsIsの可視化であり、改革とともに現状を見える化することが求められていました。
②生産性向上ニーズ
会社として利益を上げるため、コストカットのニーズは常にあります。定期的に無駄や非効率を洗い出し、効率化を図ることが必要です。もちろん、常日頃から業務改善に取り組んでいて何もすることがないといった状態が一番ですが、現実はそうもいかないです。こういったプロジェクトを立ち上げて、全員で一斉に活動に取り組むことが効率的ですし、”業務改革”の雰囲気が醸成された状態であれば既存の無駄や非効率を関係者巻き込んで変えやすいです。
③業務品質（EX）向上ニーズ
私たち人事部門では、”管理する人事”ではなくEmployee Experienceの向上を目指しています。言葉は悪いですが、人事部門は競合もなく他社に仕事を奪われるわけではないため、従業員満足度がそこまで高くない、従業員からみて分かりにくいといったものがあってもそのままにしてしまうといった殿様商売になり得ます。顧客である従業員に対して価値を提供できているか？日々の人事に関わるサービスの中で不便を感じさせていないか？といった視点を持つように一斉チェックをして、改めて従業員目線になっているかの確認をする必要性がありました。
活動内容
1．プロジェクト企画/準備
■ゴールについて
最初に決めたのは、ゴール（この活動を終えた時に何が達成されていればプロジェクトが成功と言えるのか？）です。今回の活動では、
①全業務のAsIsプロセスが可視化されていること
②全業務についてToBeプロセス（生産性向上/業務品質の向上/従業員満足度向上等に繋っている状態）が検討されていること
※全て実行できるわけではなくとも、まずはあるべき姿を描くことが大事
③人事部門の中に変革マインドが醸成されていること
の３つを目指すこととしました。
AsIs業務プロセス可視化については、全業務Mustでの完成を目指しました。ToBeプロセスについては、業務改革の必要性を考えることは全業務ですが、変革を実際に行うものは必要に応じて優先度を決めるとしました。
また、変革マインドの醸成についてはサーベイを通じた定量化での目標設定となりました。
※生産性の向上を実測するのはかなり難しいです。ここについてはServiceNow等を用いて業務量やタスク処理に関する可視化が必要となるため、今回のプロジェクトでは作業者の体感ベースでの申告にとどまりました。
■期間
期間は１年に設定しました。年度を通して一巡することの多い人事業務の性質も考慮し、この期間を設定しました。
■体制
・PJオーナー(組織長である発起人）1名
・PM（推進リーダー役）1名
・PMO（推進リーダーサポートチーム）10名程度
・ワークストリームリード（各オペレーションチーム幹部社員）20名程度
・テクノロジーチーム（主にSPOWF開発）5名程度
体制構築において一番重要なことは、PMに部門間調整が得意な人物を配置することです。業務改革のサポート役であるPMOは、コツコツ物事を進めていくタイプでも問題ないのですが、実際に業務を変えようとすると各部門との調整が頻発するため、顔が広くて交渉毎が得意なタイプが1人いるとPJの進みが全然違います。
※逆に、他部門調整などが苦手なタイプがPMに配置されると、苦しみます。
もう一つ大事なことは、PJオーナーのコミットです。もちろん、日々PJを進めていくのはPM以下メンバーですが、部門調整時の協力やプロジェクトへのリソース配備といった部分については、PJオーナーもしっかりとコミットしてもらうことを約束して貰わなければいけません。
■会議体
①ステコミ
→PJオーナー/PM/PMOを中心に進捗報告、必要な意思決定。1回/四半期
②PM/PMO会議
→PM/PMOでの進捗確認＆必要な意思決定。1回/週
③PMO/ワークストリームリード会議
→PMOが各ワークストリームリードと個別で設定。回数は任意。
※クイックサーベイ（プロジェクトの理解度や進め方の改善アイデア）
→部署全体の会議にて、その場でクイックサーベイ。1回/月
■ドキュメント/FMTの準備
どんな業務改革の書籍を読んだとしても、”現状の可視化”の必要性が強く訴えられています。また、各チームがばらばらな形式で業務を可視化した場合、「どんな項目について整理するのか？」「どの様な形式で整理するのか？」「どの様な粒度で業務を可視化するのか？」といった点に統一感がなくなり、プロジェクトの効率性がかなり落ちます。
そのため、まずは共通FMTを作成しました。整理する内容は大きく分けて2つ。一つ目は、業務の概要を整理するFMT。細かい点は書き出さずに、「そもそもこの業務の目的は何か？」「何をアウトプットとして出す必要があるのか？」「どんな関係者がいて、どんな役割分担をしているのか？」といった概要部分だけ整理するFMTを用意しました。
二つ目は、プロセスの詳細を可視化するドキュメントです。「何を」「誰が」「誰に対して」「いつ」「なんのツールで」について整理出来るFMTです。
※FMTを作成すると、プロジェクト参加者からは「どんな粒度で業務を書き出せばいいの？」と質問がよく出ます。そこで答えているのは、実際の業務の手順書ではなくプロセスを書き出して欲しいということです。例えば、ある業務で現場から申請があり、人事がシステム上に変更内容を反映させるといったプロセスがある場合、あくまで書き出す粒度は「システム上に反映させる」です。細かく言うと、「〇〇システムにログインする」「〇〇の変更ボタンを押す。」「変更内容を入力する」といった手順の粒度に分けられると思いますが、その粒度で書き出すと負荷が高いのはもちろん、全体の流れが見えづらくなるのでお勧めしません。（ＲＰＡ化などを志向したプロジェクトであれば別）
※フロー図について
フロー図の作成については、ＰＪ内では任意作成としました。フロー図を作成することで非効率な業務や、インプットアウトプットが上手く繋がっていない業務がよく見えるので出来れば作成したいところですが、ここはスモールスタートでなるべく作業者負荷を下げることを優先しました。もちろん、業務改革をサポートする立場のプロジェクトメンバーは、自分の頭を整理するためにぱぱっと業務フローに落とし込めるスキルは是非持っていたいところです。ToBeを議論する際などに、ポイントとなる点のフローを描写して、ビジュアルを見ながら議論すると認識統一が図りやすかったりします。
■Outputの格納フォルダ準備
・成果物格納サイトの構築
成果物を格納する共通フォルダがなければ、進捗状況のトラッキングが出来ません。また、可視化した業務プロセスを”一度作って終わり”ではなく今後も最新化されているか等のガバナンスをかけていくことも見据え、一か所に集約することをお勧めします。
・フォルダ構成の決定＆ファイル命名規則の決定
作成した成果物格納サイトの配下には、しっかりと体系立てて構成されたフォルダを予め準備しておくことが必要です。体系的なフォルダ構成を準備しておくことで、ドキュメントを今後も使いやすい形で保管しておくことが出来ます。
2．プロジェクト期間中の活動内容
■説明会の開催
事前準備が終わり、実際のプロジェクト開始。まずは活動への参加者全体へ説明会を実施しました。（人事部内でも数百人のプロジェクトメンバー）
体制や実際のプロジェクトの進め方、ドキュメント作成方法等の細かい部分まで説明を実施しました。
■AsIsの書き出し
実際に業務側メンバーにまずは共通FMTを用いて自分たちの業務を書き出してもらいました。プロセスを書き出すのは初めてのメンバーも多かったため、体裁や精度についてはこの時点ではあまり気にせず書いてもらうことで、手を動かす側の心理的/時間的負担を下げることがポイントです。（最初からぐちぐち言うと、非協力的になってしまいます）
■AsIsの確認
プロセスを書き出してもらった後は、ＰＭＯメンバーを中心にドキュメントを確認します。主に確認する点は以下の点
・End to Endで業務が書き出されているか？
→自組織だけでなく、業務として完結する部分まで。
※特にＢＰＯを活用している業務については、ＢＰＯ先の業務までしっかりと把握できているかがキーです。
・目的やアウトプットは明確か？
→そもそもこの業務はなぜやっているの？という部分にこたえられない業務については、本当に必要かの再検討が必要です。
・役割分担が明確か？
→ステークホルダー毎の役割分担を確認します。業務によって、複数組織が同じ役割を担っていることがあるため、その業務は今後業務整理が必要になる部分です。
■業務改善PJの優先順位付け
もちろん、すべての業務について時間をかけて改善活動を図っていくことは重要ですが、リソースや繁忙状況などもあり現実はそう上手く行きません。
そのため、優先順位付けをして取り組む内容やレベルに差を付けました。
A：課題感なし→Asisの可視化でPJは完了
B：課題感有＆自部門解決可能
C：課題感有＆複数部門＆自部門を超えた対策が必要→PJ側サポート
■ToBe案の作成
AsIsを可視化し、整理したら今度は「その業務をどうしたいか？」＝ToBeを検討する段階に移ります。ここで重要なのは、実際に業務を担当している人たちにあるべき姿を考えてもらうこと。プロジェクト側メンバーはあくまでサポートであり、業務変革活動における納得度や満足度を上げるためにも、自分たちで変革をしている実感を持ってもらう必要があります。
そこでプロジェクトメンバーが出来ることとしては、ToBeを考える視点を提供すること。こういった視点を提供して、皆同じ視点を持って業務改革アイデアを考えていくと、組織全体としての取り組みに統一感が出てきます。
以下、例です。
標準化
例外が多ければ多いほど生産性を下げます。「●●の場合は・・・」というのが多い業務については、本当にそれぞれ異なる対応をしなきゃいけないのかを考えます。制度設計とオペレーションの部隊が分かれて存在する組織の場合は、制度自体の複雑性によってどれくらいのオペレーション負荷がかかっているかも考慮した上で、設計してもらう必要があります。
従業員目線
従業員を顧客と考えた場合に、分かりやすいものになっているか？といった点について従業員視点で考えます。その際には、実際には業務を担当していないPMOのメンバーなどが従業員目線に立ってコメントすることが必要です。ガイドライン一つにしろ、普段その業務をしている人事メンバーだとわかるけど、初めてその業務をやる従業員でもわかるレベルで用語解説や説明資料を記載する必要があります。
権限移譲
幹部→一般社員。人事→従業員。権限移譲を図ることで業務効率化出来るものも多いです。一定のルール範囲内であればいちいち上司承認をとらず一般社員がＯＫを出していく、人事が承認をしなくてもいいものは性善説にたって現場に権限を委譲していく。
システム化
RPA化やPowerautomateを用いた自動化などを検討します。ここでポイントは、システム化の検討は一番最後であるべきだということです。そもそもやらなくていい業務を自動化しても開発コストがかかるだけですし、業務のあるべき姿を描く前にシステム化がちらつくといい業務改善案が出てきません。
■ToBeの実行
今後その業務をどうしていきたいか？ということが決まれば、その後はToBe案の実現に向けて動くことになります。
細かい変更は除き、結局変革には関係者調整が伴います。そのため、ここでPJチームの人選や立ち位置が重要になってきます。一部門の中にいると、どうしてもその目線で他部門と相対することになるので、部門横断的な組織にプロジェクトチームが位置づけられていることが重要だと感じました。
また、この段階に来ると上を巻き込むことが重要です。関係者間で調整がつかない場合は実務レベルの1個上を巻き込み、公平な観点で結論を下してもらう。そしてその決断には従うことが必要です。
※歴史を理解することの重要性
ToBeを考えること自体は別に過去を知らなくても出来るのですが、関係者調整をするタイミングでは、過去の歴史をある程度理解しておいた方がいいです。非効率に見える今の業務も、何かしら過去の背景があって成り立っており、当時の改善活動の結果かもしれないからです。ここを理解した上で関係者と話が出来ると、「わかってるやつ」と思ってもらえます。
プロジェクトを終えて
1．良かった点/上手く行った点
■業務プロセス可視化の効果
業務効率化のための過程での可視化であったとしても、それが資産となり引継ぎ精度の向上につながりました。人の入れ替わりがあった際も、業務の概要やプロセスが記載されたドキュメントがあることでスムーズに新しい業務を理解することが出来る様になりました。
また、これは副次的な効果なのですが、システム化/BPOへのスムーズな移行に繋がりました。システム化、BPOをする際はまず初めに要件定義が必要となりますが、その第一段階がほぼ完了している状態のため、すぐに開発などや業務委託を進めることが出来る様になりました。
■プロジェクトマネジメント（横並びでの進捗比較）
良かった点の2つ目は、横並びでの進捗比較です。200名を超える大PJであったため、モチベーションの濃淡はもちろんあります。そんな中でも全業務の業務改革活動を進めることが出来たのは、定期的に進捗を可視化して横並びに見える様にしたからだと思います。（営業成績比較みたいなイメージ）
進捗の全体での比較はプロジェクト途中から始めたのですが、そこからの進みは全然違いました。
■PJ中心メンバーが人事全体のオペレーションを横断的に理解＆人脈形成
大きな人事部門になると、機能別にチームが分かれており、かなり上のポジションにつかない限り人事業務全体を理解している人が少なくなっていきます。ただ、このような活動を通じて人事業務全体を理解できたことでPJメンバーの成長に大きく繋がりました。また、このメンバーがハブの役割となって、チーム間を繋げる様になりました。（この組織ではこういうことに困っていて、この組織でこうすれば解決できるかも？といった話が出来る様になりました。）
なので、大きな組織であればあるほど業務横断的に取り組む活動を通じた人脈形成や全体理解を促進していくメリットがあると今回強く感じました。
2．反省点/難しかった点
■プロセス改革よりも制度改革
業務プロセス改革の活動が浸透してくると、効率化レベルが頭打ちになる瞬間があります。それは、人事規則や制度の複雑性によるオペレーションの複雑性です。その部分は、プロセスの改革だけではどうしようもなく、制度自体に踏み込んでいく必要があります。Shared Service化して複数部門・複数社の人事を集約している私たちの会社では、会社毎の制度相違などにより個別対応が発生しており、そこについてはなかなか制度自体を変えるといった部分までは踏み込めなかったです。
■効果測定/説明
「何時間分の効果があったの？」というのは、こういった活動では間違いなく説明が必要になるテーマです。ただ、なかなか人事オペレーションの実際の削減工数などをデジタルに算出することが出来ず、これも自己申告の積み上げを成果として出すことになりました。（こういった改革をしたらこれくらい減るはずだという想定の数字）
ここについては、そもそもの業務自体をServiceNowなどのオペレーション工数や対応件数などを可視化出来る基盤の上に乗せていき、今後計測可能にしていく取り組みが別で必要だと感じました。
3．まとめ
2年間の活動を通じてかなり社内での人脈も構築することが出来ましたし、幅広い業務の実態を理解することが出来ました。また、プロジェクトの立ち上げから推進の経験も通じて、「人事業務への幅広い理解」「BPRへの理解」「プロジェクトマネジメント」の知識も学ぶことが出来ました。
※以下、活動をする上で参考にした書籍を紹介します。