[Tech Blog] AnyMindでのエンジニアチームのマネジメントの紹介

こんにちは。AnyMind GroupでEngineering Dept.のマネージャーをしている柴田です。 この記事では、当社のEngineering Dept.（以下、わかりやすさのためエンジニアチームと表記）のマネジメントや評価で考えていることについてお伝えしたいと思います。

AnyMindのプロダクト開発組織について

AnyMindでは "Make every business borderless" というMissionの元、多様なソフトウェアプロダクトを展開しています。 これらのプロダクトを開発しているのが Product DevelopmentというBusiness Unitで、その下に Product Manager Dept., Engineering Dept., Creativeというチームがそれぞれ分かれています。 ちなみに、先日の記事の竹本が部門全体＆Product Manager Dept.のマネージャーをしています。

組織体制としては以下のようにプロダクトをまたいでエンジニアやPdMが居る形ですね。

システム開発においての基本的な役割分担としては、PdMが「どんな機能をどの優先度で作るのか」を考え、その要件を元にDesignerが「どんなUIにするのか」を整理し、Engineerが「どのようにその機能を実装するのか」を担当する形です。

チームの目指す形について

組織の中でチームとして機能するために、当たり前ですが「チームとして成果を出し続けること」を目指すのですが、AnyMind Groupでのエンジニアチームの特徴として、

• – スタートアップなので、時間を掛けて育成するより今結果がほしい。
• – まだ新しく変化の激しい分野でプロダクト展開しているため、とにかく素早く作って素早く直せることを重視する。
• – まだまだ新サービスや機能を増やしていきたいため、チームを大きくして生産性を高める必要がある。
• – アジア各国でビジネスを展開しているため、多拠点・多人種のエンジニアを抱えている。が、英語ネイティブのメンバーは多くない。

があります。 また、読者の方も既にご存知かもしれませんが、ソフトウェアエンジニアは一般的に

• – 優秀な人であれば生産性が数倍〜数十倍違うこともある。
• – チームで協力して一つのシステムを組み上げるため、人が増えるとコミュニケーションコストが劇的に増える。（Two Pizza Rule が有名）
• – 技術の進歩が速く、より便利なライブラリやツールが毎年のように出てくる。
• – 転職のハードルが低く、集めやすいかもしれないが出ていきやすい。

といった特徴もあります。 これらの特徴や現状を踏まえて、大きく以下の方針でマネジメントをしています。

• – 自走できるメンバーのみを集める（採用）
• – 多少の失敗は許容した上で多めに任せる（任命）
• – 過程よりも成果にフォーカスする（評価）

以下に、それぞれ個別に背景や具体的な取り組みなど詳しくご説明します。

自走できるメンバーのみを集める（採用）

まずメンバーの採用方針ですが、募集している職務のスキルを持っていることは前提として、他は「自走出来るか」で見ています。 僕自身の感覚で申し訳ないのですが大まかに

• – 自身への改善点などのフィードバックを嫌がらずに受け入れることができる。
• – 今のスキルセットに固執せず、新しい技術を積極的に取り入れることができる。
• – 事実と主観の区別をつけ客観的に判断できる。

などを満たしていることを「自走出来る」とみなしています。

「自走出来る」メンバーであれば、体制に変更があったり新しいシステムを作ることになっても柔軟に対応してくれますし、1から10まで説明しなくても自身でキャッチアップしてわからないところを聞くなどしてくれます。 またソフトウェアエンジニアの特徴として先ほど述べたように、ただ数を増やすより少数精鋭の方が成果が期待できるとの考えもあります。

もちろんこういった人材はほとんどの会社で取り合いになると思いますが、幸いにもAnyMindでは採用担当が優秀なことと、「海外で働ける」「新しい技術を積極的に取り入れられる」という特徴から今のところ順調に採用出来ています。 （それでも昨今は渡航規制など厳しくて困っていますが、、）

多少の失敗は許容した上で多めに任せる（任命）

現状、各プロダクトチームには技術選定からチーム構成やスクラム導入などほとんどを一任しています。 例えばサーバーサイドのプログラミング言語でいうと、Python, Kotlin, Golang, Scalaなどがあり、フレームワークもバラバラです。 これは後述しますが「何を選んでも良いからしっかり成果を出すこと」という評価方針から来ています。 （また、「優秀な人材を繋ぎ止めるため、彼らの嫌がりそうな制約を作らない」という意図もあります。僕自身も色々な技術に触れられるほうが楽しいですし。）

また、現状ありがたいことに短期間でプロダクトが増えてやるべきことが大量にあるため、これまでのマネージャーだけでは手が回らなくなってきます。 このとき、もちろん本人のキャリアプランや意向を考慮した上でですが、テックリードやマネジメント未経験のメンバーにもその役割を積極的にアサインしています。 こちらはマネージャーへ負荷が集中するのを防ぐためと、やる気のあるメンバーに挑戦の機会を与えるために出来る限り大きな役割をアサインしています。 慣れてないであろう役割の場合、しばらくマネージャーも様子を見たりするのですが、意思決定やコミュニケーションは全て担当の方にやってもらい、なるべく口を挟まないようにしています。

ただ、このような方針で進めると、慣れてないのでうまくチームを回せなかったり、プロダクトの品質や開発速度が一時的に落ちて見えるなどが当然起こりえます。 しかし、そもそも「マネージャーは組織拡大に伴って別の仕事をしないといけない」ということで出来る限り任せていくしかないですし、「そのプロダクトにフルタイムで関わっている人の方がチームやプロダクトの現状を把握しているはず」なので、失敗を想定した上で目標設定を行いつつ、長い目で見るようにしています。

もちろんずっと放置するわけではなく、ヤバそうだなと思ったらサポート出来るようにしばらく様子を見ます。 例えば

• – 「スプリントの振り返りはこういうフォーマットにしよう」となれば、「スクラム一般的にはこういうやり方が良いみたいだよ」と伝えてみたり、上手く回ってるかしばらく見守る。
• – 「新プロダクトでは新しい言語を導入しよう」となれば、リスクが大きそうなので想定できる懸念を伝えたり、なぜそれを選んだのかじっくり議論したりする。

などです。徐々に大きなミスをしないだろうという信頼が深まってくるので、それに応じて様子を見る頻度を減らしたり裁量を増やしたりしています。

過程よりも成果にフォーカスする（評価）

目標設定ですが、 プロダクト開発チームそれぞれで『3ヶ月毎の短期目標』と『長期に向けた品質維持の方針』を立てています。

短期目標に関しては、基本的にはPdMが考えている長期プランに則った上でPdM・テックリードが次3ヶ月で実現出来そうな範囲を議論して決め、マネージャーが承認する形にしています。

長期の品質維持に関しては、あまり明文化出来ていませんがテックリードとマネージャーで大まかに

• – 今後のデータ増でパフォーマンスが悪化することが想定されるので、Read系ロジックを分離してチューニングしやすいようにしておく。
• – 今後開発メンバーが増えるので、今のうちにマイクロサービスとして切り離せる準備をしておく。

など非機能要件を考えて目標に入れておく形です。

このようにチームの目標を決めるのですが、そこから先のメンバーの個人目標はほとんど具体化していません。 理由は、最初に述べたように当社がスタートアップで成果を出すことに注力して欲しいから。もう一つは、自分だけ良ければ良いではなく一体感を持って協力しあってほしいからです。 なのでチームとして成果を出すために、『僕はインフラ面で貢献しよう』『この機能は私がリードする』など得意分野を表明する程度に留めています。

さて、これらの目標を3ヶ月毎に振り返って評価するのですが、先述の通り基本的にはチームの達成状況が評価のベースとなります。 大きく以下のように評価しています。

• – テックリードは、 (チームの達成度) = (個人の達成度)
• – メンバーは、 (チームの達成度) = AVG(個人の達成度) という前提の上で等級や貢献度を踏まえてテックリードが判断

現状、このように定性的な目標設定をした上でテックリードが主観的に評価をする形を取っているので、メンバーとの認識ズレが大きくならないようPeer Reviewも行っています。 これは評価には直接反映せず、マネージャー陣が各プロダクトの状況を把握するために使っています。

まとめ

ここまでお話してきましたが、あまり仕組み化しておらずメンバー・マネージャーがそれぞれ自由に動いているように映ったのではないでしょうか。 これは、

• – 優秀なメンバーを採用して、彼らに任せたほうが効率がいい。
• – 目標・評価軸をシンプルにして、それぞれの責務を誤解なく共有する。

という設計にしているためです。

デメリットとしては、細かく指示せずに任せているために期待通り成果が出ないときに調整しにくい事があると思っています。 なので何よりも『自走出来る』メンバーのみを採用することと、この人にリーダーを任せても大丈夫かをしっかり判断するといった人の見極めが重要ではないかと考えています。

ちなみに今後改善したいこととしては、

• – どうしてもPdMにビジネス要件などの情報が集まってしまい、エンジニアは与えられた仕様をどう実現するかにのみ注力しがちなため、もう少し情報共有を活発にしてエンジニア側から仕様の提案をしていきたい。
• – コロナ・多拠点開発などで各メンバーと雑談する機会をあまり取れていないので、もっとメンバーと話してチーム内の心理的安全性を整える。

があります。

AnyMindでは、このように大きな裁量のもと様々なプロダクトを開発しており、PdM、エンジニアの採用も強化しています。グローバルな課題を技術力で解決していきたい方はこちらのページから「Product Development」を選択して募集職種をご覧ください。

https://anymindgroup.com/career/

また、こちらはAnyMindのエンジニア達が書いているブログです。よろしければこちらもご覧ください。

• – 日本語: https://qiita.com/organizations/anymindgroup
• – 英語: https://medium.com/anymind-group/tech-blog/home