人事制度と技術的負債

エンジニア歴7年くらい、人事歴3年くらい（重複あり；現在の主は人事）の高橋です。

直近で社内の人事制度設計に関わっていて、「人事制度設計って技術的負債に対する向き合い方が似ているな」と思うようになりました。

似ているということは、プラクティスを転用できる可能性があるということ。技術的負債に対するプラクティスは非常によく研究・共有されています。これを生かさない手はない。

技術的負債とは何か

ソフトウェア開発における比喩的な概念のひとつです。ややこしいことに、この言葉の定義について複数の議論がありますが、ここでは「時間が経過して増大してしまったシステムの複雑さ」ということにしましょう。

技術的負債があるということは、以下のような困った状態がある、ということです。
・現状を理解するのが難しい（プログラムなどの解読が難しい / 時間がかかる）
・機能を追加 / 変更するリスクが高い（予期せぬ不具合を引き起こす可能性が高い）
・日々の運用のコストが高い（運用に属人的な知識が要求される）
・新たな負債が生まれやすくなる

つまりシステムを継続して運用するのが大変ということです。日々のオペレーションに時間を割かれ、ユーザーからの新たなニーズに対応すべくプログラムを改修すること困難です。あれ？こんな人事制度、見たことありませんか？

焦らないでください。どんなに優れたシステムでも、間違いなく技術的負債を抱えているものです。大事なことは、以下の3つです。

・負債を生み出さない努力をすること
・負債を検知する仕組みをもつこと
・負債を解消すること

人事制度も、これらを守ることで理解しやすく、追加/変更が楽で、運用コストが低いものに繋がるかもしれません。

負債はなぜ生まれるのか

技術的負債が生まれる要因には次のようなものがあります。

・追加開発によりシステムの規模が大きくなった
・開発組織が大きくなり、設計の一貫性が失われた
・当時の開発体制が弱く、熟練の設計者が少なかった

人事制度でも、似たような要因で負債が生まれますよね。

・社員が増え、多様な組織になった / 時代が変化した
・制度設計に携わるメンバーが増え、制度の一貫性が失われた
・当時の制度設計者の知見が足りなかった

これらに対抗するにはどうすればいいか？シンプルに考えると、以下が導かれそうです。

・未来を見通した設計を行う
・制度設計に一貫したポリシー / 思想をもつ
・制度設計の経験、知見をもつメンバーを抱える

また、ソフトウェア開発ではここでコードレビューというプロセスが重要になってきます。新たなプログラムが目的に合致しているか、私たちのシステムの設計思想に沿っているか、をチェックします。人事制度においても、その制度に矛盾が無いか、また制度設計の思想に沿っているか、をチェックするのは非常に重要なように思えますね。

アーキテクトという役割の人も活躍します。システム全体の設計に責任をもつ人です。システムの基盤を整えたり、優れた設計を行うスキルをもっています。どんなにすばらしくできた設計思想も、全てのパターンを予め網羅できるわけではありません。ここで人間がバランスをとるというわけです。人事制度でも、全ての人事制度に一貫性をもたせる役割を明確にもたせてもいいかもしれません。

負債をどう検知するか

どんなに負債を生まない努力をしても、未来を予知することはできないので、当初は負債でなかったものが負債になるということはよくあることです。前提として、負債はどうしても生まれるものであり、その「負債を検知する」という考え方をもつことが重要だと思います。

ソフトウェア開発には「プログラムによってシステムをテストする」というプラクティスがあります。これによって、その時点でのシステムの正しさを保証することに加え、将来その機能を変更したり別の機能を追加したりしたときも安心、というわけです。

人事制度にも転用できるでしょうか？そのまま「プログラムでテストする」ということは難しそうです。しかし、テストを網羅的/継続的に行う、という考え方は拝借できるかもしれません。例えば1年に1回、制度を棚卸しし、以下のような観点でチェックすることは価値がありそうに思えます。

・制度の目的が組織や社会の変化に追いついているか
・制度の適用条件が社員の多様化に追いついているか
・制度を並べて見直したとき、一貫性が維持されているか
・オペレーションコストが割に合っているか、過度に属人化されていないか

負債をどう解消するか

負債が検知できたら、あとは解消するだけのように見えます。しかし、そのリソースは十分にあるでしょうか？既存のオペレーションを止めてまで？これは悩ましい問題ですが、冒頭で触れたように、負債は新たな負債を呼びます。未来のためには思い切ってメスを入れなければなりません。ここでは優先度付けが重要になってきます。その負債を解消したときの効果、解消するためのコストと既存の業務のバランスを取って意思決定をします。負債の解消自体が目的になってはいけません。時間をかけてそれに手を入れてどんな効果があるのかをよく考えましょう。

最後に、技術的負債に対する最も良く知られたプラクティスを紹介します。それは「過去の技術的負債には敬意を」というものです。現状にマッチせずオペレーションが大変な制度には苛立ちを感じることもあるでしょう。しかし、その制度が過去の組織を支えてきたことは疑いの余地がありません。技術的負債の類語として「レガシーシステム」という言葉があります。すなわち「遺産」です。偉大なる過去の遺産に敬意を払い、同時に組織の未来をつくる新たな制度に向き合っていきましょう。