- サーバーサイドエンジニア
- プロダクトマネージャー
- サーバーサイド
- Other occupations (18)
- Development
- Business
ひと口にマネジメントといえど、そのスタイルは様々。チームメンバーや部下、組織や技術、やり方も多彩にあります。このシリーズでは、“エンジニア”のマネジメントを担うメンバーに焦点を絞り、「エンジニアマネジメントってどうしてる?」と悩みや独自のやり方などを赤裸々に語ってもらい、メンバーの多種多様な“マネジメント観”を中心に、そのノウハウをお届けしていきます。
▼過去の記事はこちら
スキルにあった人材は、探すのではなく、育てる〜エンジニアのマネジメントどうしてる? #01〜
自由に働いてほしいからこそ、責任も意識してもらう〜エンジニアのマネジメントどうしてる?#02〜
「自分で気づく」経験が学びにつながる〜エンジニアのマネジメントどうしてる? #03〜
第4回目は、 『モンスターストライク(以下モンスト)』事業本部の開発室を統括する白川に、マネジメントのノウハウを聞いてみました。
白川 裕介 (しらかわ ゆうすけ)
2012年に新卒入社。SNS「mixi」でアドネットワークを担当したのち、XFLAGのアドテクスタジオへ異動。その後、モンストの開発業務に携わり、マネージャーを経験。現在は開発室の室長として、モンストに関わるエンジニア組織を統括する
マネージャーは“暇そう”なほうがいい?
──開発室の部室長になってから、結構長いのでしょうか?
2016年にマネージャー、2018年に室長になったので、マネジメントの経験でいうと丸4年経ったところですね。
──開発室の統括、というと見られているメンバーも多いですか?
緻密にコミュニケーションをとっているのは、マネージャーの4名が中心です。各グループのメンバーについては基本的にマネージャーに任せているので。
──なるほど。そのマネージャー陣はどのような構成なのでしょうか?
大まかにいうと、サーバー・クライアント・技術支援のエンジニアが各1名、QAが1名、の計4名です。事業部の中の位置づけでいうと、モンストのアプリ開発に携わる部分全般と、今後リリース予定のスピンオフ作品への開発支援を担っている、というと分かりやすいでしょうか。
──エンジニア組織ですね。マネジメントを行ううえで、普段はどのようなことを意識されているのでしょうか?
“意見を言いやすい環境を作る”ことですね。
──そのために、どうされているのですか?
率直に言ってしまうと、忙しそうに見せないことですね。ある程度暇そうに見えるように振る舞うというか。
──暇そうに振る舞う?
そうです。もちろん、暇なことってなかなかないんですけど(笑)。要は、部下から話しかけてもらいやすい上司でいる、ということですね。上司があくせくしていると、部下からすると声をかけづらい。「今聞いていいのかな…」「ちょっと待ったほうが良いかな…」と思われないようにしています。
──声をかけやすい雰囲気を作るわけですね。
雰囲気もそうですね。具体的には、ちょっとバタバタしている場面で何か相談を持ちかけられても、なるべく「ごめん、もう少し後で!」とか、先延ばしにしないようにしています。
──でも、タスク的には「もう少し後」でもよかったりしませんか?
そういう場合もありますね。ただ、部下が上司に声をかけるタイミングって、つまりは相談したいタイミングじゃないですか。本人からすれば、大きな決心をして、やっと声をかけてくれたかもしれないので、なるべくその場で応えたいと思っています。
──なるほど。
「もう少し後で!」を繰り返されると、部下からも声をかけづらくなるはずなので、そうならないように気をつけています。部室長という立場上、そこにはどうしても勾配ができてしまい、メンバーに話しかけるよりも少しエネルギーがいるはず。だからこそ、“相談しにくい人”だと思われないようにしています。
ミスは責めない。それが鉄則
──他にも気をつけている部分ってありますか?
“失敗を責めない”ことでしょうか。複数人でなにか作業に取り組んでいる以上、ミスは必ずといっていいほど起きます。ゼロにすることは、ほぼ無理ですよね。そこで重要なのは、ミスをいかに活かすか、だと思うんです。
──ミスを活かす?
簡単に言うと、同じミスが起こらないようにすること、ですね。起こったミスを本人だけではなく、なるべく複数の立場から検証し、どうすれば防げるかを仕組みから見直す。そうすることで、一人が起こしたミスが、今度はチーム全体の安全網を強化する可能性だってあるんです。
──おお…!
そう考えると、ミスをした場合に本人を責めることがいかに無意味か、と思いますよね。ミスが起こるのを避けるのではなく、再び同じミスが起こるのを避ける、というと分かりやすいでしょうか。ある本の中で、大勢の命を預かる航空業界では失敗をした人を非難しないことが前提になっている、と書かれていました。失敗した状況を徹底的に検証し情報を公開することが習慣づけられていて、一度の失敗から多くを学ぶことで、飛行機は安全性が格段に増し、安全な乗り物になっているという話ですね。
──とはいえ、部下の許せないミスもある…?
それでも責めることはしません(笑)。バグを憎んで人を憎まずですね。サーバーやクライアントのバグで問題が発生したりするときも、誰のせいでというよりも、どうすればこの問題が解決するのか、何が最善な解決策なのかと言うのを全員が考えてくれていると思います。また発生してしまったたバグや不具合に関しても定期的に関係部署のメンバーが集まって振り返りをし、再発防止策を検討してもらっています。
──責めないことそれだけ徹底しないといけないのでしょうか?
そもそも個人を責めても意味がないし、なにより、ミスをした時に責められると思うとミスを隠す意識が働くようになりますよね。「◯◯してしまいました」と周囲に告白した時、「なぜ◯◯してないんだ!」と責められると思うと、どうにか自分でリカバリーしようとしたり、黙っていようとしたりする。そうすると、より大きな事故に繋がりかねない。
──たしかに。
先に話した“意見を言いやすい環境を作る”ことは、ミスを隠さないようにして、リスクを共有できるという副作用もありますね。
ある意味の“諦め”からのスタート
──マネジメントする上で、ベースになっている考え方はありますか?
“人は・・・続きはこちら