組織のベースラインを引く
元エンジニアリングマネージャで、今は人事をやっています。
この記事は、Engineering Manager vol.2 Advent Calendar 2018 の19日目です。
もはや関係ないのに未だにエンジニアの1on1を何人かの人とやっているのですが、そこで、同じことを何人かの人に説明することが続いたので、きっと同じようなことで詰まってるんだろうなと思い、久しぶりに書いてみることにしました。*1
前提
- 僕が1on1をやっている人は、チームのリーダーもしくはリーダー的な動きを期待されている人
- それぞれのチームは古い人もいれば、新しい人も入ってきて、割とカオス。
- それぞれのリーダーは、なんとかチームを良くしたいと思ってがんばっている。
1on1での話
とあるAさんの1on1から
チームのみんなが技術的に向上したいって思ってくれない
という悩み。聞いてみるとチームとしては業務はそれなりにこなせているが、Aさんとしては、技術的に分かっていればもっといろいろできるはずという思いがある。 日々の業務は、前の仕事のちょっとした改修だったり、似たような機能の追加が多いので、なんとかなってしまうようだ。 ただ、前の仕事の内容を完璧に理解しているわけではない状態で対応しているので、本来は、もっと違う設計だったり、違う対応方法ができるはずなのに、なかなかそういう発想にならないのである。仕様的には動いているし、納期も守っているので、そのAさん以外は、あんまり課題意識がないようである。
とあるBさんとの1on1から
チームで開発に関するレビューをする時にレビューアの指摘が常にネガティブな言い方になってしまうのでチームの空気が悪くなってしまう
という悩み。聞いてみると指摘事項の中にはレベルの高いことから低いことまでいろいろあるけど、レビューアの個人的な観点で目に付く事を指摘してしまっている模様。本来ならここまでできてたらまずは及第点みたいな事でも、レビューアから見るとアラが見えてしまうので指摘してしまう。また、レビューアの中にもいろんなレベルの人がいるので、指摘している内容がレビューイのレベルに合っていないような指摘になることも。
とあるCさんとの1on1から
チームで勉強会をやる時に、初心者のレベルに合わせてしまう
チームの中で、業務で必要なスキルを習得するために勉強会をしようという話になったときに、チームの中の初心者のレベルに合わせて、勉強を始めてしまうそうです。それ自体は別に悪いことではないのですが、「知らなくて当然」「みんなで覚えていこう」みたいな空気になってしまい、当然身につけておくべきスキルでさえも、「誰かが教えてくれる」という空気が出てきてしまいます。そうなってくると、なかなか勉強会も進まないし、 自分たちのスキルとしても、そのレベルでいいんだなという空気になってしまいます。
みんなで勉強しようというところまでは良かったのですが。
1on1でみんなに伝えたこと
Aさん、Bさん、Cさんのケースに共通なことは、その組織やチームでの基準がないことによる弊害が出ているんじゃないかと思いました。*2
そこで、
組織として最低限満たすべき基準を、みんなで意識をあわすために「組織のベースライン」を引こう
という話をしました。
Aさんのケース
Aさんは、チームのみんなに技術的にもっと上を目指してほしいし、その方がもっと業務を効率的にできると思っています。 しかし、他のチームメンバーは、現状でも業務は回っているし、なぜそんなことをしないといけないのか伝わっていないのでしょう。 特にAさんは、技術的にもできる人なので、他のメンバーからは、Aさんが言っていることはだいぶレベルの高い理想論のように聞こえているかもしれません。 Aさんとしては、そんなにレベルの高いことを要求しているつもりもなく、チームとして「こうなって欲しい」ということを言っているだけなのですが、伝わりません。チームとしての最低限満たすべき基準（ベースライン）の認識が、みんなであっていないことから発生していると思いました。
Bさんのケース
Bさんのケースでは、いろんなレビューアが、それぞれの視点で指摘をしています。 レビューする時って、絶対的な正解があるというよりは、このケースでは、どのレベルまで引き上げるのかということが大事だと思っています。*3 しかし、このチームのレビューアたちは、指摘する際の基準である「どのレベルまで」ということが揃っていないので、「あれができていない」「これができていない」という指摘になってしまっているのかなと思いました。*4 つまり、このチームは、チームとして最低限満たすべき基準である「どのレベルまで」というところが、認識があっていないことから発生していると思いました。
Cさんのケース
Cさんのケースでは、チームでわからないことを自発的に勉強会で教え合う姿勢は、とても良いです。 しかし、チームとして、最低限満たすべき基準として、「最低限このくらいのスキルがないとこのチームではだめだよね。」というラインがないので、 初心者レベルから、「みんなでがんばろう」という感じの空気になってしまいます。それでみんががんばれば、まだいいのですが、 現状の自分のレベルと目標のレベルのギャップがないと、「がんばろう」という気にもならないかもしれません。 このケースも、やっぱり、最低限満たすべき基準である「このレベルのスキル」がないことから発生していると思いました。
どうやって組織のベースラインを引くのか
さて、組織として基準となるべきベースラインがないことからいろんな問題が発生していることがわかりました。 では、どうやってそのベースラインを作ったらいいのでしょうか。
結論から言うと「組織やチームによる」です。*5
自立意識の強いチームに対して、頭ごなしに押し付けても反発するでしょうし、逆に、まだまだジュニアなチームであれば、 自分たちからそのベースラインを作り出すことは難しいかもしれません。 だからこそ、その組織やチームをよく見ているエンジニアリングマネージャの力の見せ所なのです。 その組織やチームにあったやり方で、「組織のベースライン」を自分たちのものになるようにしていかなければいけません。
そういう自律的な基準を作れるようになることが、自己組織化の第一歩かもしれませんね。
まとめ
- 組織やチームが最低限満たすべきベースラインが決まっていないと、チームがバラバラになって弊害がおきてしまう
- そうならないために、 「組織のベースライン」を引こう。
- ただし、「組織のベースライン」が自分たちのものと思えないと、すぐ形骸化するよ。
おまけ
「組織のベースライン」という話をしていたのですが、スクラムの「Doneの定義」もある意味ではベースラインなのかなと思いました。 「Doneの定義」が、チームの成熟度に合わせて見直すように、「組織のベースライン」も組織の成熟度に合わせて、見直していかないといけませんね。
