組織のゴール
うまく書けるかどうか分からないけど、前々からちょっと気になっていた話です。
うちの会社では半期ごとにゴールを設定します。
ゴールは通常、組織全体で定量化(数値化)できるものが設定されます。
ゴールを達成したかどうかで、特別ボーナスの額が変わることがあります。
この会社に入った時は前の会社のあいまいな(つまり基準がよく分からない)評価制度があまり好きではなかったので、「明確に評価できるのはいいね！」と感じていたのですが、最近その弊害をよく感じます。
一言でいうと、目的と手段が入れ替わってしまう時があるんです。
では具体例を・・・いや、ちょっとその前にコンテキストを説明します。
今から始まる話のコンテキスト
- おいらは社内SEである。
- 顧客はすべて社内の人間である。
- 開発も社内で行っている。外注はしていない。
- 社内開発なので当然、開発に関わる金銭のやりとりは発生しない。
- 期日については「ビジネス上どうしてもこの日まで」というケースは少なく、「早い方が嬉しいけど、特にいつまでというデッドラインはないよ」というケースが多い。
- なので多くの場合、期日を多少オーバーしてもビジネス的に致命的な問題がでるわけではない。
というわけで、社外の顧客を相手にしているSIerなんかに比べると、かなりユルい環境だと思います。
では、最近あった具体例に移ります。
期日を守ったパーセンテージをゴールにするとどうなるか
期日をゴールにするまでの背景
入社当時、そんなこんなで開発業務はかなりユルユルでした。
社内の顧客と打ち合わせして、仕様を決めて、開発して、リリースする。
しかし、リリース日は公式に管理されているわけではないので、成り行きで「だいたいこのへん」と決めて、その日にリリースする感じでした。
しかし、それだと開発業務が遅れがちになって顧客にも迷惑がかかるし、マネージャーも人的リソースの管理がしにくいということで、開発前に期日を決めてそれを守ろう！ということになりました。*1
公式な期日が導入されると、今度はそれをパフォーマンス指標としてゴールにしよう！ということになりました。
つまり、半期内で期日を守った案件と守れなかった案件をカウントし、期日を守れた案件のパーセンテージを出すわけです。
たとえば100%ならば特別ボーナスも100%、90〜99%ならば特別ボーナスは75%、といった具合です。
期日をゴールにしてみると・・・
さあ、このあたりから話がおかしくなってきます。
本来であれば、このゴールは「期日通りにシステムを顧客に提供する」とか「人的リソースを効率よく管理する」といった目的を充たすために存在するはずです。
が！！！
ゴールとして設定されると、
「なんとか100%にして特別ボーナスを上げたい」
「情報システム部は優秀なパフォーマンスを発揮していることを証明したい」
「自分のせいでみんなの足をひっぱりたくない*2」
・・・といった欲求が強くなり始めます。
その結果何が起きるかというと・・・みんなつじつま合わせをし始めるのです。
「期日が守れそうな確信が得られるまで、期日を設定しない」とか「期日がオーバーしそうな場合は、なんとか不可抗力であることを証明して、カウントの対象外にしてもらう」とか。
一番まずいと思ったのは「開発が大きく遅れているのに、期日までにシステムテストが終了すると見込んで強行突破しようとする」ケースでした。
おいらもその案件をサポートするためにシステムテストの一部を手伝ったのですが、急いで作りこんだが故に紛れ込んだと思われる、大小のバグやテスト項目の不備があちこちに・・・。
しかし、その案件で設定されている期日は翌日でした。
その期日にビジネス的な理由はないようなので、おいらは「この品質じゃ明日のリリースは無理だ。リリース日を延期しよう。」と主張したのですが、担当者はゴールが気になるのであまり乗り気ではありません・・・。
何のためのゴール？
これって、良くない傾向ですよね？？
ゴールを達成することが目的になっていますよね？？
昔、何かの本で「目標管理は良くない」という話を読んだことがあります。
当時はそこで挙げられているデメリットを読んでも、明確な指標が得られるメリットの方が上かな、と思っていたのですが、最近はデメリットの方を良く感じます。
さっきも述べたように、手段と目的がよく入れ替わってるんです。
みんながつじつまを合わせようとするんです。
それなのに毎回「ゴール達成おめでとう！！」って喜んでるんです。
たとえば「みんな最近残業が多いみたいだから、残業時間を減らそう。だから今期のゴールは平均の残業時間を毎月10時間以下にしよう」としたとき、ゴールを優先してウソの残業時間を報告したらどうなるでしょう？
「みんな、ゴールを達成できたね！残業時間が減ったんだね！じゃ、今後もこの調子でよろしく」ってなっちゃいますよね？
「残業時間を減らそう」っていう目的が達成できていないのに、それで良かったことになっちゃうわけです。
このように、無理やりつじつまを合わそうとすると、結局自分の首を絞めることにもなります。
最初に挙げた期日の例でいうと、ゴールを優先させることは「品質の高いシステムを構築し提供する」というプロとしてのプライドよりも、組織の評価やメンツを優先したことになるわけです。
じゃあどうするの？・・・答えは出てない
物事の悪いところを見つけて批判したり、もっともらしい正論や理想論を並べることは簡単です。
しかし、代わりとなる答えを提供するのは難しいです。
今回の問題についても、アレがダメ、コレがダメ、と批判するのはたやすいですが、「じゃあどうするの？」と尋ねられるとちょっと困ります。
しかし、おいらなりにちょっと考えてみることにします。
本来の目的を優先させるなら「正直に申告して、正確なパフォーマンスを計測しようぜ。でないと、悪いところも見えないし、何が良くなかったかも分かんないから」ということになると思います。
でも、そうなると評価や特別ボーナスに影響します。
ということは、「思わずつじつまを合わせたくなるパフォーマンス値」はゴールに向いていない(つまり評価や報酬として反映させにくい)んだと思います。
じゃあ、次に「つじつま合わせをしなくてもよいパフォーマンス値」とか「つじつま合わせができないパフォーマンス値」があるのか、となると・・・う〜ん、すぐには思いつきません。
となると、やはりどこかで読んだ本のように「目標管理はNG」ということになるのかもしれません。
あと、現実的ではないかもしれませんが本当にパフォーマンス値を計測するなら、社外の独立した組織に頼んで公平に計測してもらわないとダメでしょうね。
最初「他人や他の組織に計測してもらう」というのを考えたんですが、「同じ社内だったら結局一緒だろうな〜」という結論に至りました。
というわけで、残念ながら自分のなかでは「これ！」というような代替案はまだ出ていません。
たぶん、上層部の人達も色々苦労して考えた末に生み出された現状なんだろうなと推測しますが・・・。
パフォーマンス改善や人事評価って難しいですね。
そうした分野はプログラマの技術力とは直接関係ありませんが、プログラマを仕事とするのであれば意外と無視できない大事な要素であったりするのかなあと思います。
P.S.
このエントリでは話をシンプルにするために、実際に起きた内容を一部変更してあります。
あわせて読みたい
ツールを使うとコード品質を簡単に定量化し、コードの品質に役立てることができますが、ツールを使う人間の品質までは改善できません。
ツールの計測値をゴールにすると、同じような問題が発生する可能性があります。
C#のコード品質を上げるフリーツール8本 - give IT a try
参考文献
あったあった。ありました。
目標管理の弊害を述べていたのはこの本です。
ただし、この本では「停滞状態が多くなり、組織の変化が遅くなる」「本来複雑である企業の貢献度を目標値が過度に単純化してしまう」といった弊害を挙げています。
- 作者: トム・デマルコ,伊豆原弓
- 出版社/メーカー: 日経BP社
- 発売日: 2001/11/26
- メディア: 単行本
- 購入: 14人 クリック: 119回
- この商品を含むブログ (111件) を見る
