workhack2.0

**

ランクド・バッジ（Ranked Badge）とは、リキッドな等級の一つです。リキッドな等級については、以下記事を見てください。

リキッドな等級

また、ランクド・バッジはワーク・ゲーミフィケーションの一部となります。こちらについても、気になる方は以下記事を見てください。

ワーク・ゲーミフィケーション ～仕事をガチでゲーム化する～

では内容に入っていきましょう。

概要

ランクド・バッジがどんな仕組みなのかを解説します。

1: バッジという概念

「～～の状況で～～をした」を定めたものをバッジ（Badge）と呼びます。

2: 事前合意と事後合意

社員は、仕事がどんなバッジから構成されているか、また仕事が終わった後にどのバッジを達成したかを評価します。

前者を事前合意（Before Consensus）、後者を事後合意（After Consensus）と呼びます。合意と書いているように、バッジは自己申告で勝手に手に入るものではなく、関係者との合意を持って決めます。

字面を見ると「何らかの合意の前や後に何かするのか？」と思えますが、Before/Afterは仕事をやる前・やった後だと考えてください。

3: ランクに分かれる

バッジは、難易度に応じてn段階に分かれています。ランク = 等級があるということですね。

4: 人事評価はランクで決まる

人事評価はランクで決まります。

これはブロードバンディングの考え方と同じで、あるランク（バンド）帯にいる人は、入手したバッジがどうであっても同等の評価になります。

メリット

リキッドな等級を実現できます。

= 以降は実現に向けた話 =

ランクド・バッジをどのように実現するか、ヒントを整理します。

システム

いつでも誰でも使えること

全社員全員がいつでも誰でも使える、オープンで堅牢なものが欲しいです。

事前・事後合意や、バッジの追加削除更新、その他提案や議論などは動的に行われます。システムは常に使える状態でなくてはならないわけです。

全員のバッジとコメントが全員に見えること

ランクド・バッジの肝は透明性です。

このようなことは全部フルオープンであり、全社員に見えます。ログとして、証跡として、記録は残り続けます。

事前合意・事後合意はシステム上で行えること

通常、業績評価はクローズドな面談の形で行われますが、これは過剰です。業績評価に関する準備や会議に追われてしまうことは、組織が抱える課題あるあるではないでしょうか。

ランクド・バッジのシステムがあれば、システム上で評価が完結します。

本人と関係者がシステム上でフィードバックや議論をすればいいからです。やりとりはすべて見えていますし、バッジを満たしたかどうかの判断もすぐにできると思うので、そんなに手間はかかりません。

たとえば、チーム内であるプロジェクトが終わったとして、バッジB1とB2が欲しい場合、単に事前合意と事後合意で関係者からのフィードバックを書いてもらえばいいだけです。

それ次第で「両方入手していい」とか「B1は入手でいいけど、B2は正直足りないのでは」といった結論が出ます。

最大の争点は「最終的な意思決定をどうやるか」です。やり方は色々あります。

次の争点が「関係者」の定義でしょう。

これはなるべく広い方が良いです。また、必要なら社外の顧客や業務委託先からのフィードバックも募れると良いでしょう（システムにそういう機能をサポートする）。

上司だけが評価する、のような狭い関係者はなるべく控えてください。適切な評価ができません。しかし、全く関係がない人や、ほとんど関係がない人を入れるのも良くありません。極論、ファンの多い人が👍を稼げてしまいます。

こういう小細工は行えないよう、誰を関係者として設定するかは注意深く設定したいですね。

可能ならナレマネとインサイトに繋げる

バッジ情報を以下の情報と結びつけることで、ネットワーク構造的な「価値の眠る」情報になりえます。

たとえば、「このバッジを取得している人物・チーム・プロジェクト」とか「このバッジを最近半年以内に取得した人物が、他に同期間内に取得したバッジ」とかいったことを辿れるようになります。人間関係など「ネットワーク構造」はありきたりで自然なものですが、だからこそ、つくれると、生きたナレッジとして役に立ちます。

もちろん、分析を加えたりAIに食わせたりすることでインサイト（知見や洞察）を得ることもできるでしょう。

バッジの種類を規定する「8S」

最大の争点は「どんなバッジをつくるか」ですが、一つフレームワークをつくりました。8つのSから成るので8S（エイト・エス）と呼ばせてください。

バッジを設計する際の参考にしてください。

全体像

バッジの種類は8個あります。これらは4つのカテゴリ――遂行、獲得、能力、還元に分かれます。

従来では遂行ばかりが評価されがちですが、他のカテゴリーもあることに注意してください。

詳細

8つそれぞれの詳細を整理します。

道中、「スコア」という概念が出てきますが、これは仕事の難易度を示す式を指します。

たとえば金額p、期間Lのプロジェクトのスコアをp*Lとする、などです。

この場合、金額が大きく期間が長いプロジェクトほどスコアが高くなりますね。もちろん、数式次第では調整はどうとでもなります。いずれにせよ、定量的な因子を用いた式としてつくってください。

では詳細解説に入ります。

遂行 > Servive

獲得 > Scale

獲得 > Setup

能力 > Synergy

能力 > Skill

能力 > Style

還元 > Share

還元 > Star

Q&A

よくある議論をQ&A形式で整理します。

Q: ランクに関する議論がないが、どうすればいいか？

Ans: 本記事では扱っていません。

要は等級の設計であり、既存の人事知識でまかなえる（ただバッジを使う点が違うだけです）と思いますので優先度は低めです。

Q: 全社員が日常的にランクド・バッジのシステムを触るようになるイメージか？

Ans: はい。

おそらく、自分が関係者となった場合、システムから「この人がこのバッジにふさわしいかフィードバック書いてください」と通知が届く感じになると思います。

Q: バッジの追加や削除はどのように管理すれば良いか

Ans: 8Sの能力 > Skillの項でも述べたとおり、現時点では良い解決策がありません。

軽く考察すると、まず全社員に任せるだけだと収拾がつかなくなるので論外です。しかし、普通に管理しようとすると、人事制度のように融通が利かないソリッドなあり方になってしまいます。

おそらく、様々な工夫を複合的に組み合わせることになると思います。たとえば:

This site is open source. Improve this page.