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

▼過去の記事はこちら

スキルにあった人材は、探すのではなく、育てる〜エンジニアのマネジメントどうしてる？ #01〜

自由に働いてほしいからこそ、責任も意識してもらう〜エンジニアのマネジメントどうしてる？#02〜

「自分で気づく」経験が学びにつながる〜エンジニアのマネジメントどうしてる？ #03〜

第4回目は、 『モンスターストライク（以下モンスト）』事業本部の開発室を統括する白川に、マネジメントのノウハウを聞いてみました。

マネージャーは“暇そう”なほうがいい？

──開発室の部室長になってから、結構長いのでしょうか？

2016年にマネージャー、2018年に室長になったので、マネジメントの経験でいうと丸4年経ったところですね。

──開発室の統括、というと見られているメンバーも多いですか？

緻密にコミュニケーションをとっているのは、マネージャーの4名が中心です。各グループのメンバーについては基本的にマネージャーに任せているので。

──なるほど。そのマネージャー陣はどのような構成なのでしょうか？

大まかにいうと、サーバー・クライアント・技術支援のエンジニアが各1名、QAが1名、の計4名です。事業部の中の位置づけでいうと、モンストのアプリ開発に携わる部分全般と、今後リリース予定のスピンオフ作品への開発支援を担っている、というと分かりやすいでしょうか。

──エンジニア組織ですね。マネジメントを行ううえで、普段はどのようなことを意識されているのでしょうか？

“意見を言いやすい環境を作る”ことですね。

──そのために、どうされているのですか？

率直に言ってしまうと、忙しそうに見せないことですね。ある程度暇そうに見えるように振る舞うというか。

──暇そうに振る舞う？

そうです。もちろん、暇なことってなかなかないんですけど（笑）。要は、部下から話しかけてもらいやすい上司でいる、ということですね。上司があくせくしていると、部下からすると声をかけづらい。「今聞いていいのかな…」「ちょっと待ったほうが良いかな…」と思われないようにしています。

──声をかけやすい雰囲気を作るわけですね。

雰囲気もそうですね。具体的には、ちょっとバタバタしている場面で何か相談を持ちかけられても、なるべく「ごめん、もう少し後で！」とか、先延ばしにしないようにしています。

──でも、タスク的には「もう少し後」でもよかったりしませんか？

そういう場合もありますね。ただ、部下が上司に声をかけるタイミングって、つまりは相談したいタイミングじゃないですか。本人からすれば、大きな決心をして、やっと声をかけてくれたかもしれないので、なるべくその場で応えたいと思っています。

──なるほど。

「もう少し後で！」を繰り返されると、部下からも声をかけづらくなるはずなので、そうならないように気をつけています。部室長という立場上、そこにはどうしても勾配ができてしまい、メンバーに話しかけるよりも少しエネルギーがいるはず。だからこそ、“相談しにくい人”だと思われないようにしています。

ミスは責めない。それが鉄則

──他にも気をつけている部分ってありますか？

“失敗を責めない”ことでしょうか。複数人でなにか作業に取り組んでいる以上、ミスは必ずといっていいほど起きます。ゼロにすることは、ほぼ無理ですよね。そこで重要なのは、ミスをいかに活かすか、だと思うんです。

──ミスを活かす？

簡単に言うと、同じミスが起こらないようにすること、ですね。起こったミスを本人だけではなく、なるべく複数の立場から検証し、どうすれば防げるかを仕組みから見直す。そうすることで、一人が起こしたミスが、今度はチーム全体の安全網を強化する可能性だってあるんです。

──おお…！

そう考えると、ミスをした場合に本人を責めることがいかに無意味か、と思いますよね。ミスが起こるのを避けるのではなく、再び同じミスが起こるのを避ける、というと分かりやすいでしょうか。ある本の中で、大勢の命を預かる航空業界では失敗をした人を非難しないことが前提になっている、と書かれていました。失敗した状況を徹底的に検証し情報を公開することが習慣づけられていて、一度の失敗から多くを学ぶことで、飛行機は安全性が格段に増し、安全な乗り物になっているという話ですね。

──とはいえ、部下の許せないミスもある…？

それでも責めることはしません（笑）。バグを憎んで人を憎まずですね。サーバーやクライアントのバグで問題が発生したりするときも、誰のせいでというよりも、どうすればこの問題が解決するのか、何が最善な解決策なのかと言うのを全員が考えてくれていると思います。また発生してしまったたバグや不具合に関しても定期的に関係部署のメンバーが集まって振り返りをし、再発防止策を検討してもらっています。

──責めないことそれだけ徹底しないといけないのでしょうか？

そもそも個人を責めても意味がないし、なにより、ミスをした時に責められると思うとミスを隠す意識が働くようになりますよね。「◯◯してしまいました」と周囲に告白した時、「なぜ◯◯してないんだ！」と責められると思うと、どうにか自分でリカバリーしようとしたり、黙っていようとしたりする。そうすると、より大きな事故に繋がりかねない。

──たしかに。

先に話した“意見を言いやすい環境を作る”ことは、ミスを隠さないようにして、リスクを共有できるという副作用もありますね。

ある意味の“諦め”からのスタート

──マネジメントする上で、ベースになっている考え方はありますか？

“人は思うどおりに動くことなんてない”ですね。

──ずいぶんサッパリとした…。

（笑）。冷たい意味ではないですよ。言い換えると、チームでものづくりをするのは、それぞれのスキルや考え方、趣味嗜好が違うから集まっているわけですよね。様々な個性がいるメンバーを、すこしでも自分の思った方向に、いかに動かしていくか。そこで生まれてくる、想像との差異をどれくらい楽しめるか。“人は思うどおりに動くことなんてない”ことを面白がれないと、基本的にマネジメントはやれないと思います。

──ポジティブな意味合いで、ということですね。

そうです。そう思っていた方が、自分自身の気が楽なのもありますね。意見が食い違うことがあっても、「人は人だしな」と、良い意味での諦めをスタートにして、じゃあそこでどう伝えれば動いてくれそうか、自分がどう動けば進んでいきそうか、を建設的に考えやすいです。

──マネジメントのスキルを伸ばしたい思いもありますか？

もちろんです。今思っているのは、社内外もっと様々なマネジメントのスタイルや組織のあり方を間近で見て勉強したいと思っています。本を積極的に読んだり、他社の方とカジュアル面談をして組織のマネジメントについてヒアリングしたり…。最近入社された方も、それぞれ雰囲気や商習慣が少し違っているからこそ、話を聞くだけでも勉強になります。

──それは、単純にスキル向上のため？

それもありますが、結局のところ、自分自身がどれほどいいエンジニア組織を作れるのかを模索していきたい思いもあります。そのためには、キャッチアップを続けて、自分としての最適解をしっかりと見つけ、アップデートし続けること。これが重要なことだと思っています。

今回の学び

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

「ミスを責めず、意見の言いやすい環境を作ることで、チーム全体で事故を防ぐ」

ミスを責めない。意見の言いやすい環境を作る。それぞれは、決して真新しい考え方ではないかもしれません。それだけに、2つを徹底して行うことで普段から意見しやすい空気を作り、ミスをしても安心してチームに共有、是正ができる環境を作る。それぞれの相互作用がチームに大きな安心をもたらし、いい組織に導いているのだと思いました。

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