Gunosy Tech Blog

Gunosy Tech Blogは株式会社Gunosyのエンジニアが知見を共有する技術ブログです。

自分なりのマネジメントを言語化してみた

こちらは Gunosy Advent Calendar 2019、22日目の記事です。

はじめに

こんにちは、アライアンスメディア事業部LUCRAチームでアレをアレしている岡田です。

今回はLUCRAのチームマネジメントしている中ででたマネジメントに対する自分なりの理解やアクションを書きたいと思います。

あくまで今の自分の理解です。絶対的に正解だと思っていないし、異なる考え方もあるし、自分自身も1年後に同じことは言っていないかもしれません。

僕が思うマネジメント

僕がエンジニアというプレイヤーからマネージャーとなって一番初めに悩んだのが極論マネジメントとはなんなのかということでした。

ドラッカーの定義とかありますが、今の僕の理解では「チームの地力を上げ、ベクトルを事業の成長方向と合わせること」と捉えています。 頭の中のイメージは完全に力学です。

f:id:okataitai340:20191222232021p:plain

力だけ大きくても事業の成長と真逆に行っていれば目指すべきゴールにたどり着かないし、チームの向かう方向が一緒でもゴールに達するための力が足りていないのであれば成果はでません。そのためマネージャーがやるべきことは

  • チームの自力を上げること
  • チームの合力が向かう先を事業成長の方向に合わせること

だと思います。

チームの地力を上げる

チームの地力を上げる大きな要素は以下の3つだと思っています。

  1. スキル
  2. モチベーション
  3. メンバー間の相互理解

スキルアップとモチベーション

スキルは自主学習など個人の努力で養われるのは当然ですが、マネジメントによっても大きく変わるものだと思っています。

一番明確な方法としては、別領域のスキルが必要とされるタスクを担当してもらうことだと思います。

例としてはクライアントエンジニアにサーバーサイド実装を担当してもらうことなどでしょうか。これにより単純に新しい領域のスキルが身に付くということだけではなく、クライアント開発においてメンテナンス性を下げている実装に対し、クライアントに閉じた解決策ではなく、サーバーサイドの変更も視野にいれた改善提案ができるようになります。

ただし、このアプローチは状況的に余力がある時にしかできず、また別領域に対してハングリーな人でないとモチベーションにマイナスに働いてしまうこともあります。なので、僕が日頃心掛けていることは「ミッションの種を提案すること」です。

アジャイル的にタスクまでの分解は「フィーチャー → ストーリー → タスク」となり、エンジニアにおいてもタスクを消化することが目的となるのではなく、フィーチャーの実現、つまりはユーザー価値の提供がゴールになるよう設計されています。 (余談ですが、通常このタスク消化がゴールではないと伝えることもマネジメントにあたり、一番大変なことだと思っています。ですが、何もしなくてもLUCRAチームの全員は価値提供をゴールとしてくれているので本当にありがたい限りです。)

タスクの消化、ストーリー、フィーチャーの実現を繰り返すことでスキルアップしますが、その中で、改善すべき点や工夫できそうなポイントがミッションになります。なお、ミッションはフィーチャー、ストーリー、タスクそれぞれに付帯できます。

今まで通りであることは停滞と同義なのでそこを壊す視点と考えるきっかけを提案すること、つまりはミッションの種を提案し続けることが、僕はマネジメントの大きな要素であると思っています。

例えば、「A機能のUIデザインを作る」という1つのデザイナーのタスクにおいても、チームの地力を最大化させるためのミッションは山ほどあり、エンジニアがデザインをもとに実装する際、労力を要しているようであれば、そこを解決する方法はないかな?といった感じで話しています。

ただし、ミッションはチームの地力最大化だけを考慮し設定すべきではなく、個々の欲求を加味するべきだと思います。

人それぞれ、喜びやりがいを感じること、苦痛や退屈だと感じることは必ずあります。

そのため、改善すべき課題と個々の欲求がマッチするように、一人一人のモチベーションの根源はどこかを1on1や日頃の会話から理解した上でミッションの設定をすべきかなと思っています。

「フィーチャー、ストーリーの実現」、「ミッション達成の効果」、「ミッションを達成させる中で得たスキル」、「モチベーション」これらはすべて掛け算でチームの地力に加算されると僕は考えています。

メンバーの相互理解

チームの地力を上げる上で最後に重要だと思っているのが、「メンバー間の相互理解」です。今年風に言えば「ONE TEAM」ですかね。

LUCRAにはマーケグループ, 開発・デザイングループ, セールスグループがあるのですが、各グループ内での意思伝達はもちろんのことグループを越えても何をやっていて、どんな成果をあげ、どこに苦しんでいるのかを理解し、LUCRAチームとして解決策を考えるべきだと思っています。

また、メンバー間の相互理解が深まることでモチベーションにも影響すると思っており、個人でやっていれば先に挙げた苦痛や退屈だと感じるようなことでも、チームの誰かが助かると分かっていれば、喜びや、やりがいを感じることに変化する思います。

チームでは相互理解を深めるために、毎週で各チームの状況共有を目的にした週次振り返りとKPTを全員で実施するようにしています。 メンバー間の相互理解が進めば、鼓舞され呼応するチームとなります。これは今の僕の目指すチームの姿なのでいろいろ試して近づけるようにしていきたいです。

ベクトルの向きを合わせる

力の向き先を事業成長と合わせるために必要なことは以下の二つだと思います。

  1. 判断基準の統一
  2. 文化の形成

判断基準が定まっていなければどこを目指せばいいのか不明瞭になり向きが定まりません。また、判断基準が統一されていたとしてもそれが文化と言えるまで落とし込まれていなければ、チームが大きくなるにつれてズレも大きくなってしまいます。

そこでLUCRAでは物事の判断基準は数値とし、その判断に至ったロジックをオープンにすることでチームの文化となるようにしています。 専任のメンバーが施策効果を分析してPOとで判断することはシンプルで効率が良いですが、LUCRAでは採用していません。理由は多々ありますが、今回の主題であるベクトルの向きを合わせることにフォーカスすると以下になります。

  • 定量的判断能力にばらつきが生じる
  • 定量的な判断・説明をする意識が浸透しない
  • 意思決定の経緯が不透明になる

これらを解決する仕組みの一つとして施策オーナー制と数値共有会と呼ばれるマーケター、デザイナー、エンジニア問わず参加する場にて議論、施策採用可否の決定を行う場を用意しています。この中で定性的な話はしますが、判断のみは定量的かつ、思考ロジックを詳細に説明するようにしています。

詳細はこちらをご覧ください

tech.gunosy.io

数値共有会で聞き手だけであると成長限界はあるため、適切なタイミングと案件で施策オーナーを担当してもらい実際に分析・報告を行ってもらうようにしています。これらの仕組みにより文化の礎となるスキルがチーム全員につき、定量的判断が浸透することで、今のチーム文化を形作っていると思います。

最後に

普段考えていることを言語化するのは難しい。あと、書いてて思ったのは、マネジメントの右も左もわからない時いろいろ迷惑かけたと思うのですが今日まで支えてくれたチームのみんなへの感謝ですね。マネジメントは一人の力でなんとかなるものでもなく、チームの協力があってことワークするものでもありますよね。ありがとうございます。

明日はhongmhoonさんです!お楽しみに!!