開発手法は、実験を交えて変えていく。〜エンジニアのマネジメントどうしてる? #05〜

開発手法は、実験を交えて変えていく。〜エンジニアのマネジメントどうしてる? #05〜

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

第5回目は、『TIPSTAR』で開発マネージャーを務める川又に話を聞きました。

川又 義照(かわまた よしてる)
ソフトウェア開発企業に新卒で入社。組み込み・Webサービス・業務ソフトウェアなど様々な開発に従事。その後、世界規模のスマートフォンゲームであるモンスターストライクの開発に携わりたくサーバーサイドエンジニアとしてミクシィへ中途入社。国内・国外のモンスターストライクの開発を経て、現在はTIPSTARの開発を行なっている。

 

プロダクトのフェーズに合わせたマネジメントスタイル

──早速ですが、マネジメントで心がけていることってありますか?

プロジェクト全体の動きは僕が管理していますが、作業担当者レベルのタスクの進め方は各チームのリーダーに裁量を任せるようにしています。細部まで僕の考えやスタイルを押し付けず、ある程度細かいところは皆がやりやすいスタイルでやってもらう。アプリやWeb、サーバーサイドなどでもそれぞれに適したツールや手法は違うと思うので、そこは部分的に最適化してもらえれば良いと思っています。

──やりやすいスタイルとは?

例えば、全体の進行管理には、プロジェクト管理ツールを使っていますが、より細かいタスクやチケットの管理などの進め方はチームによって異なります。なので、ある程度は任せてやってもらう、ということですね。この方法は、それぞれのチームの進めやすさを優先することはもちろんですが、やはり評価の際には、成果が求められるので、ベストな結果を出せるようにメンバーが判断をして柔軟に動ける余地を残しておきたいんです。

──『TIPSTAR』を立ち上げた当初から、このスタイルなんですか。

いえ。初期は人数が少かったので、僕がある程度「これをこういう風にやりましょう」と指示を出して動いていましたね。10人を超えたあたりから、この粒度で全体を見渡すのは厳しくなってきて…少しずつ、細部の進め方やツールを任せるようになりました。

──各グループに任せながら、自身が細かく把握する部分を減らしていくと。

今となっては、サービスの成長に伴い、30人規模に。現在はエンジニアだけのチームですが、これから先、企画担当やデザイナーもチームに入るようになると、将来的には50人、100人くらいの組織になるかもしれません。そのときはまた、動きやすい形にマネジメントのスタイルを変えると思います。

──チームの規模に合わせて、スタイルを変えるんですね。

そうそう。事業のフェーズや開発段階ごとに常に変化させていくのが『TIPSTAR』のスタイルです!その時々に合わせて変化させていかないと、同じやり方では、極端に誰かに負荷がかかるとか、無理が出てしまうので。みんなが楽しく働ける環境ってどういうのだろうと模索しています。

 

役割に特化したチームのあり方を実験しながら模索

──とはいえ、スタイルをガラッと変えるのは勇気がいりますよね。

そうですね。なので、次に試してみたい方法を、以下の段階から現場でテスト的に実践しています。今後チームの人数が増えたときにやってみたいスタイルがあって、そのうち2つは実験している最中です。

──実験…?どのようなスタイルですか。

横串を通してプロジェクトを見られる、独立したチームを作って試験的に稼働してもらっています。プロジェクトの進行だけを追ったり、グッと開発にリソースが割かれるタイミングで助っ人的に登場できたり…。

──なるほど、遊撃チームですね。

そうですね。また、はっきりと方法を思いついているわけではないのですが、将来的には、もっと様々なスタイルが混在しているチームにしていってもいいのかな、と思っています。

──混在?

例えば、普段はアジャイル型で進めているけど、リリースが間近に控えていてスピーディな開発が必要な局面では、部分的にウォーターフォール型にするなど、違うタイプの進め方を取り入れるのも良いと思っています。フロントエンドとバックエンドの作業を流動的に担当できる体制も良いですよね。

──でも、開発手法を変える時はどんな基準で変えるのでしょうか?

チームやそこに所属しているメンバーの経験や適正と、課題に見合った開発手法を見比べて、マッチするものを探す、という感じですね。たとえアジャイルが適したプロジェクトがあっても、実際に作業するエンジニアがあまりアジャイルの経験がないとクイックには動けない。それならいっそ、ウォーターフォールにしてしまって、まずは課題をスピーディに解決することに注力する、とかですね。

 

▲本は通勤時間の合間にiPhoneで読む。今はマネジメントに関する本を熟読中

 

──課題のスピード感と現場の相性がポイントなんですね。でも、なぜそんなに複数のスタイルを試すことにこだわるのでしょうか?

『TIPSTAR』でやりたいことを並べてみると、もっとチームを大きくしていく必要があって、そのためには色んなスタイルやワークフローが混在できる体制を作っていかないと対応しきれなくなってしまうんですよね。マイナーアップデートもあり、メジャーアップデートもあり、もっと大きなアップデートもあると考えると、それぞれの速度に合わせたチームを作っていかないといけないんです。

──『TIPSTAR』はまだまだ大きくなっていくんですね! それはメンバーにとってもメリットがある…?

同じサービスに携わっていたとしても、そのサービスのスケールの度合いによって、そこに参加しているメンバーの対外的な評価も、ダイレクトに変わってきます。『TIPSTAR』を大きなサービスに成長させて、メンバーには、その経験を武器にどこででも戦えるようになってもらいたいですね。でも、ただ大きいだけではダメです。今は広報や採用を始め、ミクシィ社内の皆さんに支えてもらっているので、応援に応えられるように結果も出していきます!

 

今回の学び

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

「開発手法は、チームの規模や適正、事業の局面を見ながら臨機応変に変える」

マネージャーが動かしやすいスタイルではなく、メンバーの働きやすい環境という観点から、常にマネジメントのスタイルを模索し続けているのだと言います。チームの規模拡大を見据えて、新しいスタイルを実験的に取り入れているのもポイントです。

 

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

PAGE TOP