管理や報酬と結びついた目標は“チート”を誘発する　モラルを崩壊させない「目的ベースの目標設定」のやり方

「定量的に判断できる目標が良い目標」なのかはまぁまぁ怪しい話

吉羽龍太郎氏：さて、本題に入っていきたいと思います。今日はどういう方が（このセッションを）聞いているかはわからないんですが、目標設定の時に、特に上司の方からよく言われる話ってこういう話なのかなと思います。

「目標を設定する時は、達成できたかどうかを定量的に判断できるようにしましょう」。「定量的に判断できる目標が良い目標なんだ」と。（言われたことがある方は）リアクションとかで教えてくれるとうれしいです。

僕もいろいろな会社に勤めましたが、若い頃とかによく言われた記憶があります。これは一見正しそうですが、これはまぁまぁ怪しい話なのかなと個人的に思っていて、そこが大事なんじゃないよねと思っていたりします。

「目標」と「目的」

そもそもということで「目標ってなんだっけ？」というところに立ち返って考えてみると、セットになって考えなきゃいけないのって目的なんですね。目的と目標とがあって。それぞれの定義をちょっと見ておきたいと思います。

（スライドを示して）目的って何かというと、（スライドに記載している）これはgoo国語辞典（から引用してきたもの）ですね。良いサービスだと思います。「実現しようとしてめざす事柄。行動のねらい。めあて」「当初の目的を達成する」「目的にかなう」みたいな感じで、最終的に達成したいことが目的ということになります。

一方で目標は何かというと「そこに行き着くように、またそこから外れないように目印とするもの」「島を目標にして東に進む」。あとは「行動を進めるにあたって、実現・達成をめざす水準」「目標を達成する」とか「月産5,000台を目標とする」とか「目標額」ということで、辞書的な定義では目的を達成するための手段だと言っているわけですね。

目標は目的を達成するためにあるということですね。目標単体として存在するというよりは、その上位である目的が必要になってくるという話になります。

そう考えた時に、みなさんのいる会社・企業の目的って何だっけ？というところに、目標設定の時には立ち返って考える必要があると思うんですよね。

企業の目的は「顧客の創造」

「企業の目的って何だっけ？」というと、いろいろなところでさまざまな本が出ていたり記事があったりします。そういう企業の話とか、組織の話とかを調べたり語ったりしようとする時には、やはりピーター・ドラッカーに当たっておくとわかりやすくていいと思います。

ピーター・ドラッカーは『マネジメント』という本の中でどう言っているかというと「利益は、個々の企業にとっても、社会にとっても必要である。しかしそれは企業や企業活動にとって、目的ではなく条件である」と言っています。利益は別に目的ではなくて、企業存続のための条件に過ぎないということですね。「企業の目的の定義は1つしかない。それは顧客を創造することである」と。「企業とは何かを決めるのは顧客である」と言っているわけです。

なので、「顧客」というのが非常に重要なキーワードになってくる。顧客を創造していかなきゃいけない。それが企業の目的である。

企業の目的をチームなどにどう反映させていくか

「企業の目的が顧客の創造だということはわかりました」ということで、じゃあそれを自分の部門とか、部とか、課とか、チームとかにどうやって反映させるのかというと、これはまた難しい話で。どんどんブレイクダウンをして小さく噛み砕いていわゆるツリー構造みたいな感じにしてカスケードさせるのって、非常に難しかったりします。

ただ「難しいからやらない」はまずくて。ここで重要なのは「部とか、組織とか、チームとかも『顧客』をキーワードにしてやっていくのがすごくわかりやすいよね」ということだと考えています。

僕が翻訳した本に『プロダクトマネジメント』という本があって、これは「ビルドトラップ本」とかって呼ばれていたりします。ここの「プロダクトマネジメントってそもそも何だっけ？」というところで、「顧客との価値交換システムをマネジメントするというのがプロダクトマネジメントだ」と言っています。目標設定の文脈においても、顧客との価値交換システムを中心に据えるのがいいのかなと思っています。

それが達成できて、部門単位とかチーム単位で顧客との価値交換システムが実現できていれば、さらに上位の会社としての目的も実現できている。抽象レベルが高いですが、これ自体は言えるのかなと思うので、顧客との価値交換システムという切り口で、目標設定の軸にしていくというのがいいのかなと思います。

それぞれの目標、個人とか組織とかの目標が、その価値交換システムにどう関係あるのかを説明できないといけないわけです。「これを達成できると顧客との価値交換システムにどういうインパクトを与えるのか」を説明できないような目標を設定しても最終的な企業の目的に反映されないので、「これをやると、どう価値交換システムに影響があるの？」をそれぞれの目標で説明できるようにすることが重要になってくるかなと思っています。

これは会社によると思うんですが、個人の目標設定とかをする時に、全部がその価値交換システムの話になるかというと（そうではなくて）、個人のスキル獲得みたいな話が入ってくることもあると思うんですね。

必ずしもすべてが価値交換システムに関係あるかどうかというと微妙なところですが、関係しないものだらけで、そういうのが大多数だと構造としてはおかしくて。個人のスキル獲得みたいなやつはごく一部になるでしょうと。残りの大多数は、顧客の創造に関わるところになるのが自然なんじゃないのかなと思っています。

SMARTの中で大事なのは「Related」

「顧客との価値交換システムを中心に据えて目標を設定しましょうよ」と言った時に、「じゃあ個々の目標ってどんなのがいいんだっけ？」という話に入ります。

ここでよく言われるのが、みなさん聞き飽きているかもしれないですがSMARTというやつです。目標設定の時とか、これは個人とか組織の目標設定の時に限らず、プロダクトマネジメントの文脈とかでどんな時にも言われたりしますが、SMARTというものがよく出てきます。

これは何かというと、SMARTのSはSpecific（具体的）です。Measurable（計測可能）。これがやたらとフォーカスされている。3つ目がAchievable（達成可能）です。夢物語じゃなくて現実的に達成可能じゃないといけない。次がRelated（関連性がある）。ここですよ。Time-bounded、Timeboxと言ったりもしますが、期限があると。これらの頭文字を取ってSMARTと言ったりします。「こういうのを全部満たしているかたちで目標設定をするといいですよ」ということです。

冒頭で言ったとおり、Measurable（計測可能）ばかり強調されますが、大事なのはRelatedです。関連性があるほうが重要で、上位の目的、部門とかチームの目的とどう関連性があるかが切れているとまずいということになります。

目標を管理や報酬と結びつけるとモラルが崩壊する

関連性がないとどうなるかという話をしたいんですが、関連性がないとビルドトラップと呼ばれるものに陥ります。ビルドトラップとは何かというと、組織がアウトカムではなくて、いわゆるアウトプットで成功を計測しようとして行き詰っている状況のことです。実際に生み出された価値ではなくて、機能の開発とリリースに集中してしまっている状況のこと。これをビルドトラップだと言っています。

要は、作ったものの量とかばかりにフォーカスして、実際に生み出した価値とか、顧客の満足度とかを全部無視している。関連性がないとこういう状況に陥りやすいわけですね。

よくあるビルドトラップ的な指標でいうと、作った機能の数とか、リリースの回数とか。あとは「何月何日までにリリースします」みたいな目標。あとは「プロジェクト自体を終わらせます」みたいな目標とか、書いたコードの量とか、クローズしたチケットの数とか。

こういうのって一見すると測りやすいんですよ。できたかどうかがわかりやすいんですよね。全部Measurableです。なんだけど、別にRelatedじゃないんですね。価値交換システム自体が機能していることを何ひとつ示していないので、こういう目標設定は良くないのかなと思います。

僕が若かりし頃、大きめの企業に勤めていた時に、「〇月〇日までにこのプロジェクトをリリースします」ということを目標に書いたことがあります。結果的にどうなったかというと、途中でもっと良いアイデアが出ても、期日までにリリースしないといけない。そうじゃないと評価とかに影響するかもしれない。

「目標設定に書いてあるからとりあえずやらないと」みたいに、やること自体が目的化しちゃうわけですね。結果的にプロジェクトが生み出す成果やインパクトとかに関心がなくなって、「とりあえず終わらせる」とか「目標を満たす」とか、そういうことに非常に気が向いちゃう。これがさらに報酬制度とか人事評価制度とかに結びついていると、そういう力がかなり働きやすいということになったりもします。

そうなると、グッドハートの法則というものが発動するわけですね。これは有名な法則で、「管理のために用いられる測定はすべて信頼できない」と言われている法則です。言い換えると、「測定して、それをベースにして報酬が与えられるようなものは全部改ざんされる。もしくはハックされる」ということですね。

なので先ほども言いましたが、「目標設定に今期中に何かをリリースすると書いたので、何でもいいからリリースしよう」とか、「今期はチケットを100個クローズします」と書いたら、簡単なやつだけを選んでクローズするとか。もしくは水増しして楽そうなチケットをいっぱい作って自作自演をするとか、何でもできちゃうわけですよ。

目標設定の目標を管理とかで報酬と結びつけると、モラルが崩壊することが起こるわけですね。もちろん多くの人はまじめだと思いますが、一部でこういうハックをする人が出てくるということになります。

なので、目的に紐づいた目標を設定して、それが達成できるとどのように目的にインパクトを与えられるのかを説明できるようなやつを選んで達成していかないといけない。

あとは目標設定で「目標って何個ぐらい設定するんだっけ？」というのも昔からよく（あり、僕も）悩んだ話なんですが、基本的に多すぎる目標は良くないですよね。「あれもこれも全部達成したい」と言っても、どれも達成できないわけですよ。これはスクラムとかアジャイルとかで開発している人はよくわかると思うんですが、常にやりたいことに対して時間が足りないので、順番を付けるしかないんですよね。

どれを先にやってどれを後回しにしよう。最悪時間がなければやらなくてもいいやみたいな話で、順番を付けて「これが一番大事だ。これが2番目に大事だ」でやるしかない。なので、本当に重要なことを数個までに絞り込んでおく必要があります。もうちょっと踏み込んでいうと、自分の目標が何なのかを全部口頭ですぐに言えるぐらいの量が理想ですよね。

「すごくたくさんあって全部口で言えません」とか、「数が少なくても自分の口ですぐに言えない」とかだと「日々の行動って何をベースにしているんですか？」という話になるので、自分の目標というのもすぐに口で言えるぐらいの個数、明瞭さを持ったかたちで設定するのが重要になってくるかなと思います。

設定した目標をどのように運用するか

ここまでが設定の話ですが、じゃあどう運用するのかという話で。会社の制度上難しい方も多いと思うんですが、半年前とか1年前に立てた目標がそのまま有効なことって、そもそも多くないと思うんですよね。

もっと重要なことがいくらでも出てくることもあるし、会社の戦略が変わるかもしれない。方針が変わるかもしれない。立てた目標がそもそも役に立たなくなることって、いっぱいあると思うんですよね。

なので、立てた目標が今でも有効なのかは検査しないといけないし、有効だとして「今どういう状況で、このまま行って達成できるんだっけ？」というのも定期的に検査して、その状況を踏まえて適応していかないといけない。これもスクラムっぽい感じですが、検査と適応というのをグルグル回していかないとまずいですよと。

期末になって、覚えていなかった目標をファイルサーバーの奥底から引っ張り出してきて、「あぁ、こういう目標を書いていたな。やばいな」とかになるのがまずくて。自分が頭の中に頻繁に叩き込んでいて、それを上司との1on1とかの中で最低でも月1回ぐらいは「どういう状況で、この目標は今でも有効なのか」「有効だとしてこのままいったらどうなんだ」「リスクはあるのか、ないのか」「もっと重要な目標はないのか」みたいなことを検査しておかないといけないです。

ここが肝ですかね。目標自体は何回も書き直したりアップデートすればだんだん良くなっていくので、こういう運用をするかどうかが非常に重要なのかなと思います。よく聞く悩みとして「いやいや、会社のルールで最初の期初に入れた目標を変えられないんです」と。「なんかツールがあって変えられない」みたいなことを聞いたりもするんですが、それはそれですよね。

会社のツール的にできなくても、上司との運用の中でそういう握りをして「目標管理システムにそうやって投入をされているけれども、お互いの合意の下にこう変えましょう」と。「実態はGoogle Docsで管理すればいいや」とか、いろいろやり方はあるので、運用として検査と適応をやっていくのがいいと思います。

目的との関連性があり、絞り込んだ目標設定を

ということで、今日は基本的なことしか話さなかったので、もっと聞きたいこともあるとは思うんですが、今日の話をまとめておきます。

定量的（目標）だけにフォーカスするのは無意味です。企業とか組織の目的は、顧客との価値交換システムを構築して維持することです。目標自体が目的とどう関係あるかを説明できないとまずいよと。

なので、SMARTの中でもMeasurableよりもRelatedのほうが重要で、関連性がないとビルドトラップになります。

あとは、目標設定を管理に使うとチートを誘発します。あとは「目標設定と報酬を分けろ」ですね。これもチートを誘発する（から）ということです。

あとは（目標が）多すぎるとフォーカスを失うので、絞り込んで検査と適応をするといいのかなと思います。

ということで僕の話は以上になります。ありがとうございます。