テクノロジー部門、STORES ECでフロントエンドエンジニアをしている @daitasuです。
私たちのチームでは、会社全体での人事制度で設定する目標とは別に、チーム内で独自にクオーターごとの目標設定と振り返りをしています。
チーム内での目標設定と振り返りを1年ほど続けてきたので、なぜこの取組を始めたのか、実際やってみてどうだったかを書いていこうと思います。
チームの位置づけ
UI改善チームとは
hey内では、全プロダクト横断的なテクノロジー部門という棲み分けがあり、その中にSTORES ECの開発を進めるECの部隊があります。
私たちフロントエンドチームは、ECのエンジニアチームの中の1つとなっています。
hey社のEC本部では、フロントエンドチームはUI改善チームと呼ばれています。
フロントエンドチームの構成
フロントエンドチームは、大きくプロダクト開発のチームと基盤改善のチームに分かれ、その中でさらにプロダクト開発は3つのチームに枝分かれします。 今回はその中でもプロダクト開発チームの1つであるCライン(仮名称)のお話をしていきます。 人数規模は時期によって変化はありますが、1ライン3~5人くらいです。
- UI改善チーム
- プロダクト開発チーム
- Aライン
- Bライン
- Cライン (今回のお話)
- 基盤改善チーム
- プロダクト開発チーム
チームでの目標設定について
多くの会社では、人事制度というものがあり、個々人の目標設定やエンジニアマネージャーとの面談、目標すり合わせなどがあるかと思います。 heyも同様に会社全体での目標設定の仕組みやエンジニアマネージャーとの面談などの仕組みがあるのですが、今回はこれとはまた別にチームでも目標設定をしているよ！というお話をします。
行っている内容は大きく2つです。
- クオーターの始まりに、チームでの目標設定会を実施(1on1でなく、チーム全体で実施)
- チーム目標に対する進捗に対し、毎月末に振り返りを実施
主たる目的
なぜチームで別途目標設定と振り返りを行っているのか？ 以下のような意図で行っています。
- 我々はなぜここにいるのか、何をするのかを明確にする
- チームで目標を棚卸ししていくことで、Qごとのチーム目標を決め、ゴール目線を揃える
- メンバーそれぞれのやりたいことを共有し、どんな領域に関心を置いているかお互いに理解する
- 月次振り返りでチームとしての課題や改善案を出し、チームの継続的改善を図る
実施内容
目標設定
流れとしては、以下のようになっています。
- チームがこれから3ヶ月かけてやることをチームリーダーが整理し共有
- チームで、組織目標→チーム目標を棚卸し、チームとして取り組む3つの目標を定める
- チーム目標をベースに、個人目標を決める
この際、個人目標はチーム目標をベースに決めますが、全ての目標が沿っている必要はなく、個人で挑戦したいことややってみたいことも混ぜて作成します。
振り返り
毎月末にチームで振り返りをします。
- その月でチームとして取り組んだ活動を洗い出す
- 前月のTryが達成できたかを確認する
- 取り組んだ内容や今月の開発状態を見ながら、Keep/Problem/Tryを出す
そもそもなぜやろうと思ったの？
ここからは、チーム内でのこの取り組みをなぜやろうと思ったのかについて書いていきます。
(1) 過去の取り組みの復活
STORES ECのUI改善チームはもともと1つのチームとして行動していて、目標設定をチーム全体で行っていました。
しかし、組織が拡大しチームがいくつかに分かれるようになって、この目標立てがなくなっていたため、復活させたい思いがありました。
(2) 目標を立てるハードルをもっと下げたい
目標設定って、なかなかエネルギーを使います。 もちろん得意な方もたくさんいると思いますが、苦手な方はどうしても設定が進まなかったりします。 これは私個人の経験なのですが、今までいざ目標設定するとなったとき、「目標かぁ〜、何しよう...」と悩みに悩み、悩むほど書くハードルが高くなるということが多くありました。 そういった背景もあり、以下のような点でチーム全体の目標というものへのハードルを下げたいなという思いがありました。
- 組織 → 部門 → チーム → 個人と大きな母体の目標から棚卸しする
- 何を目指すのか大まかな指針があったほうが目標を立てやすい
- チーム目標をチームで決める
- 上記のように、組織目標から棚卸しして個人目標を決めている企業は割とあると思うのですが、チームの目標についてメンバーレベルで介入し、チームで決めたい
- 人事制度の目標と別にすることでカジュアルに話し合いたい
- PJT目標 と チャレンジ目標 に分ける
- 業務目標だけを掲げていると、期間中に組織編成が起きたり、PJTの差し込み案件などが仮に入った場合達成ができなくなります
- そのため、PJTに関しないチーム改善なども目標に含めることでバランスをとります
- メンバーの目標や関心を把握したい
- 目標の方向性がダブるということがあります。その場合、連携して進められたら理想ですが、読めないと重複作業になったりします
- また、誰が何に関心を持っているか理解することはチームコミュニケーションとして大事だと考えます。互いに得意分野や関心が分かれば、信頼してお互いに任せることができ、やりたいことができた方がモチベーションも高く保てます。
(3) チームで定期的に自分たちを見直す機会を作りたい
チームはスクラムで開発を進めており、毎週スプリントの振り返りを行います。 しかし、個々で議論するのは主にスクラムにおける障害(遅延原因) や 開発に関する課題感であり、もう少し広域にチームとしての改善機会を探る時間を設けたい、という思いがありました。
ドラッガーの「現代の経営」でMBOというマネジメント方法があります。自律的人材の形成には目標を自ら設定してゴールレベルを上げていくことが大切というものです。 しかし、目標を掲げる上で、目標を掲げる当人が組織全体の進む方向やチームの進む方向が掴めていないと間違った方向にゴールを置いてしまう可能性もあり、設定の難易度が上がります。 チームとしての「健全は何か」をチームで都度考えて方向合わせをしていきたいという思いがありました。
こんな目標設定がしたい
チーム目標設定のモチベーション
上記のような背景があり、目標設定をチームで実施し始めました。やりたいことをまとめると下記のようになります。
- 人事制度の目標とは別にしたい(チーム独自で動きたい)
- 人事制度が関わる目標と考えるとかっちりする必要があり、しんどさが上がる
- 自身の目標を考える足がかりとして使ってもらうのも良い
- 1on1などでなく、チーム全体で実施したい
- チームは個の集合体なので、チーム目標は全員で決めたい
- 個人のバイアスが入らないようにして、全員で向かう先を考えたい
- オープンに進めたい
- メンバーそれぞれ挑戦したいことを宣言してもらうことで、個人の関心を知れる
- その領域に対する信頼を持ち、普段のタスクもよりモチベーション高いものに挑戦できる状態にしたい
そもそも目標設定って必要なの？
そもそも目標って必要なんでしょうか？ 体力も使います。なくて良いならやりたくないという気持ちもあると思いますが、ない場合はそれはそれで仕事がしんどくなりそうです。
現状の仕事に悩んでいる方のお話を聞くと、「今自分のタスクがなんの役に立っているか分からない」という言葉を聞くことがあります。 これは、組織が目指してる目線が開発者の目線まで届いておらず、なぜ今その仕事をしているのか、我々は何を目指しているのかが分からず生まれた乖離なのかなと感じることがあります。
意味のない仕事というのは現実なく、需要があるから仕事が発生しているはずなので、単にゴールが見づらい状況下にあり、改善もしにくい状態にあるのかと思います。
こうした状態になると、行く先が見えないので、比較ができないため今の状態が良いのか、悪いのかも分からず、自分が貢献できてるかも分からないのでモチベーションとしては下がってしまう場合があります。
誰も悪くないのに、気づけばそうなっていた。それって悲しいですよね。
マズローの欲求段階とか動機付け理論等でモチベーションについてよく文献で語られるので深追いはしませんが、とにかく自分が目指す場所や理想と現実どうなっているかが分からないと仕事のモチベーションは上げづらく、さらに組織のゴールへの道と個人の挑戦が同じ線上にないとしんどいよね、というのが目標設定をやる意義かなと思います。
目標を立てる上でのより良い環境
目標を立てる上で、よくSMARTの法則というものを目にします。 目標は具体的に、測定可能で、達成可能なものが良い、といったものです。
筋トレを例に挙げると、「今年の夏までにマッチョになる」という目標は曖昧で、 「今年の8月までに筋トレで体重を5kg増やし、腹筋を6割れにする。そのために腹筋1000回を毎日行う」のような具体性を持つものが良いとされます。
しかし、これが組織で立てる目標の場合、経営に紐づく必要があります。腹筋が6割れになっても売上が上がることはありません。 そのため、目標を立てるためには、それに即した環境が重要です。
- 会社としてのゴールがチームでも把握できること
- 立てた目標に対し挑戦できる機会があり、挑戦中チーム構造やPJTに変化が起きないこと
- 目標の壁打ち相手がいて、うまく進んでいるか振り返る機会が定期的にあること
heyのとても好きなとこなのですが、会社が目指しているもの、開発ロードマップ、今どんな状況にあるのか、ボードメンバーはどんなことを考えているのかなどとにかくオープンです。 そのため、組織~個人への目標設定というのは1本筋で設定しやすい環境なのかなと感じます。
- うまく進んでいるか振り返る機会が定期的にあること
目標をみんなで一緒に立てること、みんなで振り返ることも重要だと考えます。目標はコンフォートゾーン(快適領域)と呼ばれる範囲の少しだけ外側へ挑戦するのが最も幸福度(ドーパミン)が高いと言われています。
このコンフォートゾーンを想定以上乗り越え、非常に達成困難な目標を立ててしまった場合、挑戦よりも諦めが先に来てしまいます。チームで一緒に目標を見ていくことは、実現可能な、かつ挑戦的な課題をメンバー同士ですり合わせられるため、大きく逸れた目標になりにくいという利点もありそうです。
やってみてどうだった
良かったこと
- メンバーが互いに得意領域や関心領域を知れる
- これが一番大きいです。最近では、Issueを切る際、互いに「多分これはきっとこの人が率先して取るだろうな」と顔を思い浮かべながらIssueを作るくらいイメージが湧くこともあります
- 「よし！やったるぞ！」という思いを持って挑める環境も嬉しいですし、メンバー同士がそれぞれ信頼関係を持って連携しあえるのもとても良いなと感じてます
- チームとしての現状を見直す機会ができている
- 業務が忙しいと目標を腰を据えて考える時間がなく、きっかけにはなっている
- 月1で振り返ることで、チームとしてうまく回っているのかを見直せています
- スクラム開発の振り返りは開発サイクルに焦点を充ててるので、棲み分けができているのも大きいです
- チームのキックオフ要素も兼ねられる
- Qの始めに目標設定をチーム目標から棚卸しすることで、直近のタスクの整理やゴール目線合わせができます
- 以前他チームでドラッガー風エクササイズというメンバー間の期待値をすり合わせる活動がありましたが、似たような成果がありそうでした
悪かったこと
- チーム変動やPJTの変動が激しい
- 3ヶ月に的を置いた目標設定なのですが、1ヶ月単位でやることが変わったり、チーム構造が変わったりということが割とありました
- 変化を加味した目標を立てることもできるのですが、より抽象度が高い目標になり、達成判断が難しくなるという問題があります
- 振り返りがチーム改善に活かしにくい
- 振り返りで出る課題感は漠然としたものが割と多かったり、自チームだけだとどうにもならないものなどもあり、なかなかトライに繋げにくいことがありました
- 課題がどんどん積もり、改善が追いついてないと暗い気持ちになります
- 目標立てをしても、結局施策を打つのが最後の方になりがち。「そういえば」となってしまう
- 振り返り方法をもっと変えていける部分がありそうです
- 振り返りが多くなってしまう
まとめ
チーム内で1年間取り組んできた目標設定と振り返りの取り組みについての背景ややってみた結果を書きました。
チーム内で振り返りをすることで、チーム内でのメンバーごとの得意領域を知り、タスク分担のしやすさや連携のしやすさは良くなった気がします。 一方で、チームで目標を立てることで中長期的なゴールを見据えて定期的に振り返りできる機会を、というのが当初の目的でしたが、どうしても目下のPJTの議題になりがちだったり、出てくる課題感も抽象度が高く具体的なトライへと繋げていけない、など課題も多かったです。
今後のアクションとしては、下記のようなことを検討していく予定です。
- 月末のスプリント振り返りとマージして、振り返りの中でコーナーを明確に分ける
- 1ヶ月を振り返りどうだったか、という観点での振り返りになっていたため、スプリント振り返りと近しくなっていました
- スプリント振り返りを月末だけ拡張し、スプリントとしてどうだったか、目標に向けての進捗とコーナーを分け対比的にやってみることを検討してます
- チーム目標を自分たちだけで解決できるものにしない
- 目標の達成段階を決める
- チーム目標は、個人目標より一層抽象度が高いです
- 何を達成したら満たしたといえるのかが曖昧なため、Tryとしてもぼやけていた感覚がありました
- 決定したチーム目標に対し、 重要度 と 3 or 4段階のゴール設定(S/A/B/C) を定め、目標へのステップの解像度を上げる予定です
チームの改善機会は重要ですが、その分チームの時間もとってしまうものになるので、注意しながらもっとよりモチベーションを上げていける環境をチームで作っていかないとなと思います。
hey社では、こういったチーム内での独自のアイデアなども尊重して新しい挑戦をできる環境があり、日々さまざまな改善アイデアが至るところで生まれています。
カジュアル面談なども行っているので、ご興味ある方はこちらにぜひ立ち寄ってみてください！
