見出し画像

開発を時間ではなく成果でマネージメントするには?

フルリモートで事業を成功させるには「時間ではなく成果」という文化を定着させる

フルリモートワークで事業を成功させるためには、どれだけ長く働いたのかではなく、どういう成果を産み出したのかを皆が意識してそれで評価される文化が重要です。

スタートアップなのにも関わらず数千人単位で長年全社員がリモートワークに取り組んでいる「GitLab」さんでは、以下のように会社のバリュー「価値観」が定義されています。

Measure results not hours

We care about what you achieve: the code you shipped, the user you made happy, and the team member you helped. Someone who took the afternoon off shouldn't feel like they did something wrong. You don't have to defend how you spend your day. We trust team members to do the right thing instead of having rigid rules. Do not incite competition by proclaiming how many hours you worked yesterday. If you are working too many hours, talk to your manager to discuss solutions.

引用元: https://about.gitlab.com/handbook/values/#results

時間ではなく結果を測定する

あなたが出荷したコード、あなたが幸せにしたユーザー、あなたが助けたチームメンバーなど、あなたが達成したことを大切にしています。午後に休みを取った人が、何か悪いことをしたと感じるべきではありません。自分の一日の過ごし方を擁護する必要はありません。厳格なルールを持つのではなく、正しいことをしてくれるチームメンバーを信頼します。昨日何時間働いたかを宣言して競争を煽ってはいけません。もしあなたがあまりにも多くの時間を働いている場合は、解決策を話し合うためにあなたの上司に相談してください。

DeepL翻訳

どうマネージメントすべきか?

開発チームのプロジェクトマネージャーは、成果を「チケット」で管理することをおすすめします。

プロジェクトの機能単位などで大まかにタスク化されていると思います。毎週、その週にこなすべきタスクをピックアップして、スタッフが毎日1~数個消化される程度の粒度にチケットに分解してください。

次にチケットをこなす順番はスタッフに任せずにプロジェクトマネージャーが優先順位をつけることを徹底してください。

またチケットは必ずソースコード管理へのコミットやプルリクエストと連動させてください。そしてスタッフにチケットの消化結果を日々報告してもらいますが報告は鵜呑みにせずに、ソースコードのコミット内容と開発環境にディプロイされているシステムの動作を確認しましょう。

人事考課はどうすべきか?

絶対にチケット消化数などで人事考課をしてはいけません。作業の難易度やスタッフのスキルレベルをふまえて、プロジェクトマネージメントしやすく作業が効率良くなるように、チケットの粒度を決めます。だからチケットの消化数で人事考課をすることは不適切です。

エンジニアの規模が数十人程度での僕のおすすめの人事考課は以下の通りです。

チケットの難易度やボリュームを測定して、チケットからエンジニアの成果量を測り人事考課するというアイディアも考えられますが、事務作業が重たくなるし結局評価される側の不満はそこまで解消されませんので、やるべきではないと考えています。

複雑な人事考課は導入しないのがおすすめです。人事考課には、業務のパフォーマンス向上と、人材の教育と、報酬の決定という役割があります。

業務のパフォーマンス向上は、人事考課ではなく上記の日々のマネージメントでやりましょう。

次に教育は、日々の業務でのコードレビューや、プロジェクト単位での振り返りでのフィードバックで担いましょう。

そして報酬の決定は、もしスタッフが退職したとして人材市場から代わりのスタッフを採用する際に必要な相場額より少し上の報酬を目安に、定期的にプロジェクトマネージャーが独断で昇給を決めるのがよいです。


この記事が気に入ったらサポートをしてみませんか?