ZOZOTOWN開発本部 ZOZOTOWNアプリ部 Androidブロックの山田です。現在、私を含めた10名チームのブロック長としてZOZOTOWN Androidアプリの開発に取り組んでいます。
私がチームのマネジメント業務に携わったのは2019年4月からです。それ以降、常に7名以上のチームでマネジメント業務を務めてきました。経営学の用語で「スパン・オブ・コントロール」というものがありますが、そこにおいては「1人のマネージャー管理できる人数は5〜7人が適切」とされています。私個人の感覚では7名でも正直多く、5名ぐらいが適切のように感じています。
ともあれ、その状況を2年以上続けてきました。この経験を通し、多人数チームのマネジメントにおいて存在する課題が2つ見えてきました。
- 各個人に対するコミュニケーション時間減少に伴う、フィードバック量の低下と評価の難しさ
- チーム全体のパフォーマンス向上に伴う、リーダーのボトルネック化
本記事では、これらの課題解決のために実施した2つの施策を紹介します。
施策1：今週のいいね
各個人に対するコミュニケーション時間減少に伴う、フィードバック量の低下と評価の難しさを解決するための施策です。
本施策は、チーム内で毎週実施している振り返りの中で行っています。一言でまとめると「お互いの良かった行動を褒めたり感謝を伝え合う」ものです。
方法は簡単です。まず5分時間を測ります。その間にチームメンバー全員が他のチームメンバーの良いと思った行動や尊敬する行動を、以下のように書き出していきます。
そして、5分経過したら書き出しタイムは終了です。次に、1つずつそれを書いた人が読み上げて行きます。
本施策のポイントは下記3点です。
フィードバックが効率化される
1つ目のポイントは、行動に対するフィードバックを公に行うことで、フィードバックした本人以外にも間接的にフィードバックができるという点です。「間接的なフィードバック」というと少し大袈裟な表現ですが、要は1人の人を褒めることで、他の人にも「ああいう行動が求められているんだ」ということを伝えられるということです。特に、組織・チームが必要としている行動をピックアップすると効果的です。
例として、現在のZOZOTOWNのAndroidチームで考えてみます。チームには10名所属しており、チーム分割できる体制作りを目標に掲げています。しかし、具体的な手段はこれからアイデアを出していく段階なため、明確になっていません。そんな中、メンバーが属人化解消につながる行動を見せてくれたとします。属人化解消もチーム分割には重要な要素です。そのため、それを公の場で賞賛することにより、他のメンバーへのアイデアの共有につなげます。少し改変していますが、以下のような内容を「今週のいいね」でフィードバックしたことがあります。
XXの案件振り返り実施ありがとうございます。いつもは資料などリーダーが準備していたのですが準備方法を確認しに来てくれてスケジュールの設定から司会進行までやってくれてありがたかったです。どんどん周りの業務を奪いに行く姿勢が良いと思いました。
ここではまず感謝を伝えるとともに、その行動の具体的に何が良かったのかをフィードバックしています。伝えたい良かったポイントは、今までリーダーがやっていた業務を全てメンバーが代行してくれた点です。それをメンバーの前で伝えることにより、「それはリーダーがやるもの」と思い込んでいた人の意識改革につなげ、同時にチーム分割へのヒントとなるアイデアを共有したことになります。その結果、他の案件でも別のメンバーが同様に代行してくれるようになりました。このように、公の場で良い行動を称賛することは、その良い行動を連鎖させることにつながります。
評価へ活用できる
2つ目のポイントは、評価への活用が可能な点です。本施策を始めたきっかけも、評価への活用のためでした。
評価のエビデンスとしての活用
弊社では、「他のメンバーに良い影響を与える」ということが評価軸の1つにあります。評価は半期ごとに行い、自己評価を上長に評価面談でアピールしていく形式です。そこで自身の行動が他のメンバーに良い影響を与えていたかをアピールします。しかし、それを客観的に判断することは容易ではありません。
評価面談の際に、この項目について「わからない」と言ってくるメンバーもいました。私はメンバー全員との日頃の1on1の中で「あのピンチのときに○○さん（「わからない」と言っていたメンバー）が、ああいう行動をしてくれて救われた」という話を聞いていました。そのため、まったく該当する行動ができていなかったわけではないはずです。
しかし、それを感謝している本人から直接ではなく、上長経由で伝えたとしてもエビデンスにはしにくいです。そこで、毎週の振り返りでメンバー同士で直接伝え合ってもらい、それをエビデンスにしようという試みを始めました。
「毎週行う」というのもポイントです。メンバーの良いところを指摘するのは義務ではないため、忘れてしまったとしても罪ではありません。しかし、せっかく気付いていたのに、それらを忘れられてしまうと、みんなが損をしてしまうことになります。それを防ぐためにも毎週行うようにしました。実際には、1週間の期間でも忘れてしまうことはあります。もし、半期ごとの評価のタイミングだけ実施するようにした場合は、おそらくほとんどの有益な内容が忘れ去られているでしょう。
その結果、評価時にこれをエビデンスとして利用するメンバーもいました。活用事例まで出てきたので、本施策はやって良かったです。「メンバーがエビデンスを用意しやすい」ということは、「評価する側も判断しやすい」と言えます。そのため、多くの人数を評価すればするほど、この効果による恩恵の差はより大きく出てきます。
活躍のキャッチアップ
上記の評価への活用と同時に、上長が見逃した活躍のキャッチアップにも活用できます。現在、私のチームでは案件ごとに、さらに小さいチームを作って開発に取り組んでいます。その小さいチームには、私自身が参加する場合も、参加しない場合もあります。その結果、同じチームで活動しているかどうかで、そのメンバーの活躍に気付けるかどうかの差が生じてしまいます。そのため、個人の活躍を「今週のいいね」を利用して共有してもらい、上長である私が評価の要素として取り入れることを可能にしています。
そして、これは「自分が評価する立場でなくとも他の人の評価に貢献できる」ことを意味します。そのため、次のリーダー候補を見つけるのにも活用できます。それは、私個人としては、メンバーの良いところに目を向けられる人が、次のリーダーになって欲しいからです。
雰囲気が良くなる
当初から狙っていたわけではありませんが、「今週のいいね」の時間により、チームの雰囲気が良くなりました。お互いを認めあっていることが表面化され、より信頼関係が構築しやすくなっています。
施策1「今週のいいね」のまとめ
誰かを褒めることで他の人へ意識改革を促したり、アイデアのヒントを共有したりすることで、フィードバックの効率化を図りました。さらに、メンバーの活躍に対するフィードバックを上長だけでなく、他のメンバーからもできるようにすることで、上長が見逃してしまいがちな活躍をキャッチアップできるようにしました。また、副次的な効果として、チーム内の雰囲気向上にもつながりました。
続いてもう1つの施策を紹介します。
施策2：オーナーシップ制
本施策は、案件に対して各部署（Android、iOS、バックエンド、デザイナー）ごとに案件オーナーという名目で代表者をたて、その案件の仕様決定をオーナー間で行うという施策です。
以前は、上記の代表者の役割を各チームリーダーが担っていました。そして、リーダーが決まった内容をメンバーに展開し、開発するスタイルでした。その際に課題が2つ出てきました。1つ目は、やりたい案件が増えていったときにリーダーがスケールのボトルネックとなってしまう課題です。2つ目の課題は、社員でありながらも、メンバーから見たら受託開発のような形になってしまう課題です。
そんな折、メンバーのひとりが1on1で本施策のオーナーシップ制を提案してくれました。とても良いアイデアだと思い、一緒に詳細を詰め、部内で合意をとり、取り組みを開始しました。
ここでは、本施策のポイントを3つ紹介します。
クオリティ低下を予防しながら施策を進める必要がある
本施策の開始当初は、プロダクトマネージャーやリーダーが仕様検討に参加することもありました。他にもオーナーが一度チームに持ち帰ってアイデアを議論をしたのち、他のオーナーと仕様のすり合わせを行うこともありました。そうすることで、急激なクオリティ低下のリスクを予防しながら進めていました。
その結果、取り組みを始めて1年以上経過しましたが、現在までに大きな問題が発生することはありませんでした。並行して権限委譲も進み、今では仕様をリーダーと相談するかどうかは、そのオーナー自身が判断するようになりました。そのため、私が仕様検討にまったく関わらずにリリースされた機能も存在します。
リーダーが仕様検討に関わることへの是非を考える
もちろん、リーダーが全ての案件の仕様検討に関わった方が、より良いサービスになる可能性もあります。しかし、それは「リーダーだから」というわけではなく、リーダー以外の全員が当てはまります。そのため、現在は「リーダーだから全ての案件の仕様検討に関わる」という考え方はしていません。こう考えるようになった理由の1つに、私の育休取得があります。実は、この取り組みを始めた直後に、私は2か月ほど育休を取得しました。しかし、その際にも問題は発生しませんでした。
この「リーダーが仕様検討に関わるべきか」に対しては賛否両論あると思います。私のチームでは、本施策を実施した結果、大きな事故も起きずにスピード感を手に入れられたため、このスタンスは継続していきます。
チームワークの和を広げられる
本施策でも副次的な効果を得られました。それは、チームの枠を越えたメンバー同士の理解が深まったことです。
これまでは、他チームの状態や考え方は、リーダーを介してメンバーに伝わっていました。しかし、それだけでは全ての情報を伝えきることはできません。そのため、他チームメンバーの考えを理解することが難しくなっていました。本施策を開始し、メンバー同士が直接やりとりするようになりました。そこでは、仕様以外の情報もやりとりできるようになりました。その結果、お互いのことをより知ることができ、チームワークの和がチームの枠を越えて広がっていきました。
業務量のコントロールが難しくなる
ここまでは良かった点を紹介してきましたが、課題も存在します。それは、案件が並行して行えるようになったことにより、メンバーの業務量コントロールが難しくなったことです。仕様検討をリーダーが行なっていた頃は、リーダーのスケジュールが空いているタイミングでしか、仕様の議論ができませんでした。そのため、結果としてリーダーの業務量が増えてくると、自然とメンバーの業務量増加のブレーキがかかっていました。
一方、現在ではリーダーのスケジュールが空いてなくとも、メンバーのスケジュールが空いていれば議論を進めることができます。そのため、どこかで意識的にブレーキをかける必要がでてきましたが、今はそのタイミングがかなり掴みにくくなっています。この課題は部長・リーダー陣で共通して認識しており、対策を検討中です。
施策2「オーナーシップ制」のまとめ
メンバーが上流工程に関わる機会を増やすことで、サービス全体の開発スピード向上や、メンバー1人1人の主体性の向上を図りました。その結果、現在のAndroidチームではその目的を達成できている状態です。さらに、リーダーが関わらずとも問題なく案件が進行される場面も増え、リーダーのボトルネック問題も解消したと言えます。ただし、メンバー1人1人の業務量が増え、そのコントロールが難しくなる新しい課題に現在は取り組んでいます。
最後に
メンバーの人数が多くなってくると、リーダーが1人1人に関わることのできる時間は少なくなってしまいます。そこで生じる課題を解決するために、効率的にフィードバックと評価をする方法として、「今週のいいね」の施策を紹介しました。また、メンバーの人数が多くなってくるとリーダーがボトルネックになってしまう課題を解決する手段として、「オーナーシップ制」の施策も紹介しました。
どちらも副次効果として、人間関係の構築にも良い影響を与えることができました。この他にも、1on1やDiscord活用などの取り組みもあるので、「それらの話も聞いてみたい」という方は、まずはカジュアル面談でお話しましょう！ hrmos.co
もちろんAndroidエンジニアの採用も積極的に行っています。ご興味のある方は、以下のリンクからぜひご応募ください！ hrmos.co
