はじめに

自社開発のWebエンジニアをしていますが、チームの目標管理においてバランスト・スコアカードを試験導入したので、振り返りとして記事に残します

バランスト・スコアカードとは何か

経営管理手法の一つで、管理会計や目標管理といったカテゴリになるかと思います

20年ほど前に流行しましたが、今はそこまで積極的に新規導入されているものではなく、
BSCから独自進化した業績評価をしている企業が多いように思います

バランスト・スコアカード（英: balanced scorecard, BSC、バランス・スコアカードとも）は、ロバート・S・キャプラン（ハーバード・ビジネス・スクール教授）とデビッド・ノートン（コンサルタント会社社長）が1992年に「Harvard Business Review」誌上に発表した業績評価システムである。
引用：バランスト・スコアカード - Wikipedia

表記について

バランス・スコアカード
バランスト・スコアカード
バランスド・スコアカード
上記の中黒無し
BSC

等、見る文献によって表記が凄くバラけています
原文はBalanced Scorecardなので、この記事ではBSCあるいはバランスト・スコアカードと表記します

BSCは以下4つの視点で構成されます

財務の視点
顧客の視点
業務プロセスの視点
学習と成長の視点

つまり、どれかに偏ることなく業績評価をする点が他の経営管理手法と異なる点です
例えば、目標管理でもう1つの流派は「リクルート式KPI管理」で、そちらはただ1つのKPIを設定することが重要です

リクルート式KPI管理は例えるなら信号機、業績が赤か青かで進む/止まるの判断をする
BSCは例えるなら飛行機のコックピットの計器、たくさんの指標で異常値を検知して対処する
といった違いがあります

ちなみにバランスト・スコアカード自体は基本情報技術者試験の範囲内だったりします
なので、エンジニアには馴染がある方もいらっしゃるように思います

導入の背景

エンジニアおよびエンジニアチームの評価が定性的で、事業貢献や成長を評価することが難しかった
両立すべきものが片方に寄ることが多かった
戦略と戦術の関係性や、各取り組みの関係性が不透明だった

ためです

例えば、

長期と短期
財務指標と非財務指標
外部尺度と内部尺度
成果と行動

等、本来は両立すべき要素がたくさんあります
エンジニアで言えば、業績を上げるための攻めの施策と、技術的負債を解消するための守りの施策、どちらも重要です
ですが短期思考に陥ると、目の前の財務指標、短期指標にすべてが寄ってしまいます
結果として内部の疲弊や、長期での優位性確立が遠のくことにもなります
では逆に、それらを全て捨てて長期の投資にばかり回せば良いのか？と考えると、そういうわけでもないです

そこでバランスト・スコアカードの出番となります
多くの指標の関係性を示し、それぞれの正常値を設定し、それが全て満たせている状態を目指します

導入例

厳密な数値や設定目標は出せないため、だいたいどんなものを導入したのかサンプルを示します

一部抜粋や改変をしたサンプルなので、因果関係が多少おかしかったり過不足がある点はご容赦ください

これら各要素にそれぞれ目標値を設定した上で、それを維持・改善できるように半年間取り組みました

工夫ポイント

「売上目標」と「利益目標」はBSC上に表現しているが、エンジニアチームとしての目標値は設けない
目標ごとのウェイトはかなり差を付ける
全てがストレッチ目標ではなく、現状維持目標も多め

1. 「売上目標」と「利益目標」はBSC上に表現しているが、エンジニアチームとしての目標値は設けない

因果関係を示すためと、常に業績を意識するためにBSC上は表現しています
しかし売上や利益の結果（遅行指標）はエンジニア以外の状況によっても大きく左右されるため、数字を見て行動を変えるための日々ウォッチして追う指標としては適さないと判断しています

2. 目標ごとのウェイトはかなり差を付ける

その時々で組織が何に注力するかが異なるため、各指標の達成が全体の何%を占めるのか調整しています
例えば上記のサンプルだと売上利益以外の11項目を指標として設定していますが、それぞれ9%程度ではなく、3%や5%といった低ウェイトの指標、20%の高ウェイトの指標等を分けています
そしてそれぞれを点数化し、週次で100点満点中何点かを記録し、指標がどのように変化したかを追っていきます

3. 全てがストレッチ目標ではなく、現状維持目標も多め

コックピットの計器に示した通り、正常値を維持するものがBSCです
そのため5個も10個も赤信号だと、飛行機の操縦（組織のマネジメント）がままなりません
よって、現状維持レベルで達成できる指標も入れて設計しています
現状維持レベルであっても、日々追うことでアラートに気付けることが重要です

振り返り

良かった点は、今まで定性的にしか評価できなかった業績が、100点満点の定量指標として落とし込め、週次推移も追えるようになったことです
そのため何が好調で不調か一目瞭然となりました
特に、100点満点中何点であるか…という見方は、組織の健康状態を他職能に説明する際に分かりやすくはなったと思います

逆に改善点としては、後から取り返せない指標を置いてしまったことで、半期の評価で取り戻せない数字が出てしまったことです
つまり100点満点をどうあっても満たせない状態になると、うまくBSCが機能しきれなくなります
言うなれば計器の一つが常にアラート出している状態です
ここは改善の余地ありでした

最後に

本来BSCは全組織で一律導入すべきものであり、チーム、部、本部、全社…とツリー上に構築して運用していくものです
今回は試験導入ということもあり、一部門のみでの導入となりました

実験的な試みではありましたが、現時点では成功例と言えるほどの精度ではないと言えます
今後さらに工夫と改善をすることで、うまくエンジニア組織へ馴染む形にしていきたいと思います