メンバーの成長が事業成長に直結する。そのためには?〜エンジニアのマネジメントどうしてる? #09〜

メンバーの成長が事業成長に直結する。そのためには?〜エンジニアのマネジメントどうしてる? #09〜

ひと口にマネジメントといえど、そのスタイルは様々。チームメンバーや部下、組織や技術、やり方も多彩にあります。このシリーズでは、“エンジニア”のマネジメントを担うメンバーに焦点を絞り、「エンジニアマネジメントってどうしてる?」と悩みや独自のやり方などを赤裸々に語ってもらい、メンバーの多種多様な“マネジメント観”を中心に、そのノウハウをお届けしていきます。 

第9回目は、デジタルエンターテインメント(以下DE)事業本部 横断推進部の部長を務める山浦に話を聞きました。

山浦 大輔 デジタルエンターテインメント事業本部 横断推進部 部長
2000年大手ゲーム会社に新卒入社。コンシューマ、アーケード、スマートフォンのゲームプログラマーとして従事したのち開発ディレクターに。2017年にIT系ゲーム会社にてエンジニア組織のマネジメントを経験した後、2020年7月ミクシィ入社。ポストソーシャルゲーム創出を担う部門において2021年より横軸支援部門を立ち上げる。認定スクラムマスター(CSM)、CEDEC運営委員。

 

 

理想はゴールに向かって自走できる「自己組織化」されたチーム

━━山浦さんが所属している「横断推進部」とは、どういうことをされている部門なのでしょうか。

簡単に言うと、DE事業本部内で各事業部が別箇に動いている開発を、横串を通して見ていくことで組織のアウトプットを高めていくことを推進している組織です。
例えば、他部門から「人が足りない」と相談があれば、単純にエンジニアを派遣するのではなく、どういった作業やタスクがどれだけスタックしているのかなど、ワークフローを見直すような根本的な課題の解決から取り組みます。

━━なるほど。組織の課題解決支援を担っていると。では、山浦さんが考える、理想の組織像はありますか。

ミクシィに入社する以前は、2社のゲーム企業でエンジニアのマネジメントを担当しました。マネジメントしていた人数は多い時で150人ほど。そうなってくると、細かい部分まで見るのはほぼ不可能に近いんです(笑)。
それで暗中模索するうちに、チームを「自己組織化」していくことが重要だと考えるようになり、それが今のベースになっています。

━━「自己組織化」とは、どういうことですか?

端的にいえば、マネジメントせずともゴールに向かっていく組織、メンバーそれぞれがゴールを明確にわかっていて、そこに向かって自走できるチームです。
前職で自己組織化を進める際には、『
Management 3.0 (2010,Addison-Wesley Professional)』で紹介されている考え方を参考にしました。書籍では、マネジメントがこのように区分けされています。

1.0―
ヒトを機械(リソース)のように扱う考え方。言われたことをやる、トップダウンでのマイクロマネジメント
2.0―
「ヒトは大事である」という認識のもと、サーバントリーダーなどを立てたりするが、報酬をエサに能動的に行動しろと命じるようなマネジメント
3.0―
ヒエラルキーに頼らず、自己組織化したネットワークが活躍する、組織システムにフォーカスしたマネジメント

1.0や2.0のような旧来のヒエラルキーありきなマネジメント手法に違和感を感じていて、3.0のマネジメントを目指すようになったわけです。

━━「自己組織化」となると、それぞれの視座が高くないと難しい気もしますが…。

もちろん、そうですね。単に“視座を高く持つ”といっても、個人的には「視点」と「視界」の両方をうまくコントロールすることが重要だと思っています。
「視点の上げ下げ」はいわば目標設定で、向上力や想像力の調整です。「視界を拡げる」ことは、興味や意欲の対象範囲を広げることですね。目標に向かって走る力をつけてもらいながら、それぞれの関心領域を広げる。この両方を達成することで、ようやく“視座を高く持つ”ことができ、自己組織化に向かっていけるのかな、と思います。

 

目標設定シートをカスタマイズして、メンバーのやりたいことを深堀る

━━自己組織化に向けて、具体的に取り組まれていることはありますか。

DE事業本部では全社共通の目標設定シートを拡張して、個人の「意味報酬」、つまり働く理由や仕事のやりがい、強みと弱み、個人的なゴールなどを記入する項目を設けています。チームメンバー、一人ひとりの「こうなりたい」を深堀りしたうえで、目標を設定しているんです。

━━目標設定の前提を整理するということでしょうか。

そうです。例えば、「面白いゲームを作りたい」と言っているエンジニアがいたとします。その理由を深堀っていくと、実はプランナー寄りの仕事がしたいと思っていることに気が付ける場合もあります。それならば、プログラミングのスキルだけではなく、面白さの表現力や企画的な提案力も伸ばしていくべきですよね。…という風に、本人の願うベクトルを一緒になって掘り下げて、無理なく目の前のタスクに取り組んでもらえるようにする、という感じでしょうか。

━━それが実現できれば、メンバーとマネージャーの間での齟齬もなくなりそうですね。

はい。それに、自分のやりたいことをやれているメンバーの背中は押しやすいですし!これを自らできるメンバーが増えれば、自然とチームへ貢献しようとする動きが出てくるでしょうし、強い組織になる。そして、業務を通してメンバー自身も望んだかたちで成長できるのかな、と思っています。

━━マネジメントする側として、他にも重要だと思われることはありますか?

自分だけでは何も出来ないことを自覚しておくこと、でしょうか。マネジメントのレイヤーが上がれば上がるほど、関わる人数が増え、その分カバーすべき職域も広がります。ゲームづくりだと、エンジニアリング、デザイン、企画、QA…と到底一人でカバーできない範囲の方々と仕事をするわけです。そうなった時、マネージャーが出来ることは「皆がのびのび働けるためにはどうするか」を考えて、彼らに「いかに任せられる状態を作れるか」が鍵となります。なるべくそうした場づくりに力を入れることだと思います。

 

今回の学び

山浦にマネジメントについて聞いてみたら、こんなポイントがありました。

 「本人の働きがい、やりたいこと(意味報酬)を意識することを皆の共通認識にしておくことで、無理なく組織のゴールへ向かっていける動機を作る」

山浦は、マネージャーとメンバーといったヒエラルキーではなく、本人のモチベーションが原動力となって動けるチームを理想として挙げていました。そこで必要になるのが、メンバーそれぞれのやりたいことや働きがいをオープンにできる文化にしていくこと。そのためには手始めに、目標設定を行う面談のシートを改良する、といった些細な工夫がマネジメントに大きく関係しているのかもしれません。

このシリーズでは、引き続き、ミクシィグループ内の”エンジニアのマネジメント”の実態やノウハウを紹介してまいります。

 

*バックナンバーはこちら

マネジメントはプログラミングに似ている?どちらも情報の“流通”が鍵〜エンジニアのマネジメントどうしてる? #08〜

マネジメントに成功パターンはないが、不得意はカバーできる〜エンジニアのマネジメントどうしてる? #07〜

マネージャーとメンバーがお互いに成長していく「徒弟制度」を取り入れる〜エンジニアのマネジメントどうしてる? #06〜

PAGE TOP