この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。
私は元エンジニアもしくは現役エンジニアで人事組織領域に関わっている方々と継続的に交流しています。
その中で時折みられる表現として「全社施策・各部施策の関係と抽象クラスを用いたTemplate Methodパターン」というものがあります。
今回は「全社施策・各部施策の関係と抽象クラスを用いたTemplate Methodパターン」の考え方について説明します。
抽象クラスの特徴
話の前提としてまず抽象クラスについて説明します。抽象クラスは抽象メソッドを持つクラスです。
抽象メソッドは実態がなく、メソッドの意味のみをメソッド名とともに定義し、継承時に中身を実装してもらう想定のメソッドです。
よくTemplate Methodパターンを実現するために利用されますが、この構成が全社施策と各部施策の関係によく似ているのです。
組織におけるTemplate Methodパターン
Template Methodパターンを実装する際は、基底クラスとなる抽象クラスに共通の処理を記述します。
そして、継承先ごとの特徴を加味して実装する部分は抽象メソッドを定義します。
そして、個別の継承先ごとに中身を実装します。
親クラスの内容がテンプレートにあたり、それを継承して中身を実装するので「Template Methodパターン」というわけです。
この構成を組織施策で例えるならば、全社施策では全社で共通のルールや手順を整備します。
そして、運用先となる各部では全社共通のルール・手順は引き継ぎつつ、各部特有の運用詳細を整備します。
1人の社員目線だと「全社のルールや手順が詳細に決まっていないので、すべてを決めて欲しい」という場面があるかもしれません。
一方で、全社目線だと統一したルールや手順にならない部分もあり、そこは抽象メソッドにあたる「これをやってね。中身は各部で最適にできるようにあえて決めていないので、残りは任せるよ」という状態にすることで、各部の前提を踏まえた運用にできる余地を残しておくこともあるのです。
全社人事と事業部人事
人事組織が全社機能としての人事の専門家集団であるCoE(Center of Excellence)と、各事業部での人事機能であるHRBP(Human Resources Business Partner)に分かれる構成になっている場合
- 全社の人事施策はCoEの組織施策担当が抽象クラスとして定義する
- 各事業部は、事業部内のことをよく把握しているHRBPが事業部内のマネージャーと連携し、全社の人事施策(=抽象クラス)を継承して、抽象メソッドにあたる事業部特有の部分を実装する
という形になります。
まとめ
「全社施策・各部施策の関係と抽象クラスを用いたTemplate Methodパターン」という考え方についてまとめました。
無理やり全社施策にすべてを詰め込むと
- 各部の間で整合性の取れないルールや手順
- 各部で柔軟に決めることができないルールや手順
ができてしまいます。
それを加味して全社施策はできるだけ薄く共通部分に止め、各部で現場にマッチした内容を決める余地を残しておけるとよいでしょう。
5
