テクニカルマネジメントをはじめ、採用、育成、組織開発など、エンジニアリング組織のあらゆる仕事をカバーするエンジニアリングマネージャー（EM）。

その業務範囲の広さから、「やること多すぎ問題」が“EMあるある”として話題にのぼることも…。

ロールの多いEMが業務を円滑に、かつ最大パフォーマンスで進められるようになるためには、一体何から手を付ければいいのだろうか。注力すべき課題を見極める方法はあるのか。

国内利用者数No.1（※）の中小企業向けビジネスチャット『Chatwork』を提供するChatwork株式会社のプロダクト本部 副本部長 田中佑樹さんと、NTTコミュニケーションズ株式会社で全社のアジャイル開発・プロダクトマネジメントを支援する岩瀬義昌さんに「EMやること多すぎ問題」解決の糸口を聞いた。

マネジメントもテックリードも……すべてこなすのはスーパーマンの領域？

——人員が限られているベンチャーやスタートアップにおいては特に「EMやること多すぎ問題」が顕著ですよね。そもそも、お二人はEMの役割や業務範囲をどう定義されていますか？

岩瀬：多くの方が問題視される通り、EMの仕事はかなり幅広くなってしまっているのが現状だと思います。

チームや個人の目標設定はもちろん、組織の成長に欠かせない採用活動に携わったり、チームメンバーのキャリア形成に寄り添ったりしながら、チームによってはテックリード的な役割を果たすことも求められるからです。

どこまでがEMの業務に含められるかは各企業、そして各事業のフェーズによっても変わりますが、私なりにまとめるなら「組織の中でもっともレバレッジが効くところを探し、適切な手を打ち続ける」ことがEMの仕事だと思います。

田中：ChatworkのEMは大きく二つ、テクニカルマネジメントとピープルマネジメントを担っています。二つと言えど、そこに含まれる細かいタスクは多種多様でどれも専門性の高い仕事ばかり。

そんな役割の多角化を当社では「EMスーパーマン問題」と呼んでいます（笑）。テクニカルマネジメントだけでなく、ピープルマネジメントも100％の力でこなすなんて、スーパーマンの領域であろうと。

岩瀬：分かりやすい例えですね（笑）。しかもEMの仕事の難しさは、業務をパターン化（型化）して負担軽減しづらいところもありますよね。

エンジニアって本来、あいまいな形をパターンに落とし込むことが好き、あるいは得意な人が多い。そこが強みでもあるのに、EMになってしまうと人や組織の変数が多すぎるために、個別的な対応が多くなって強みが生かしきれないんですよね。

ピープルマネジメントなんかは特に抽象化が難しいから、明文化されたノウハウとしてたまっていかず、属人的になりやすい。

田中：そう思います。何か物事を解決しても、例外が多すぎて汎用性がなく、結局定着しなかったり。Chatworkにもそういう時期があって、苦労しました。

特に、テクニカルマネジメントとピープルマネジメントという性質の違う職責を同時に担わなければならないことで、身動きがとれなくなってしまうEMが多い。

これら二つのマネジメントは本来、全く違う能力であるはずなのに、EMは両方求められてしまうので、本人もつらいし、会社としても大きな課題になりえます。

ーー会社としての課題というのは？

田中：この二つを任せられる器用な人の母数はかなり限られるからです。

「なんでも屋さん」は採用が難しいのはもちろん、「しんどそう」と思われて、社内でのキャリアチェンジも敬遠されてしまう。

すると人数が集まらず、いつまでも特定のEMだけに負荷が集中するということが常態化してしまうんです。これでは、持続可能な組織とは呼べません。

岩瀬：マネジメントに限らず、普段の業務でこぼれたタスク処理もEMに集中しがちですよね。まるで「もぐらたたき」のように、あちこちの問題を解決していかなければならなくて、EMの認知的負荷・心理的負荷が高い。

田中：特に、「どこのチームが拾うべきか分からないボール（タスク）」はEMに回りがちですよね。チーム間に落ちたボールは、結局EMやVPoEといった、広く組織を見ている人たちが立場としては拾いやすい。

Chatworkでは、直近取り組んだ「ピープルマネジメント部の新設」を通じて、こうした「結局いろいろなタスクをEMが背負う」場面も”結果的に”減らせると考えています。

フィーチャーチーム導入の際に生まれた発想が、EM負荷軽減の一手にも

——「結果的に（EMの負荷軽減につながる）」というのはどういうことでしょうか？ 新部署の説明もあわせて教えてください。

田中：はい、新部署を立ち上げようという話が出た背景として、開発チームをフィーチャーチーム体制にしたいねという話が持ち上がっていたんです。

というのも、Chatworkはワンプロダクトでやってきた会社なので、システムがかなりモノリスな作りになっていました。そのため、組織も細かくは分割されておらず、職能別の部署に分かれているような形でした。

ですから、何かプロジェクトを立ち上げるときには、各部署から必要な人員を引っ張ってきて即席チームを作っていたんです。

ところが、このチームはプロジェクトが終わり次第解散するので、後から機能改修を行う必要が出てきてもノウハウが散逸してしまっているという課題がありました。

岩瀬：「人を集めます、作ります、リリースします、解散！」みたいな感じですね。

田中：はい。組織規模がごく小さい間はそれでも何とかやってきたのですが、会社が成長するにつれ、毎回チームビルディングをするやり方ではEMの負担も大きくなってきました。

メンバーからも「毎回、知らない人と組まされるのでコミュニケーションコストが高い」という声が上がるようになってきたんです。

岩瀬：ノウハウというのは個人にたまるものだけではなく、チームにもたまるべきものですからね。すでに機能しているチームを壊すと、チームの集合知が失われてしまう状態になっていたということですね。

田中：はい。また、会社としては今後、新規事業にも乗り出していく戦略があるので、その成長に添えるチームになるべく「開発チーム単位で意思決定し、自走できる組織」を目指す必要がありました。その解決策がフィーチャーチーム体制へのシフトだったんです。

ただ、この体制へ移行するにあたって僕はアジャイルなチームの中に評価者（マネージャー）がいるとうまくサイクルが回らないと思っていて。

意思決定をするにも評価者の顔色をうかがっているようでは、本質的にフラットな関係にはならない。それを防ぐために、評価者は外部に置いておきたい、という発想からピープルマネジメント部を新設し、その機能をチーム外に置く発想が生まれました。

田中：ちなみに、Chatworkがフィーチャーチームにチャレンジするのは実は2回目で……。以前とは背景ややり方も違いますが、リベンジになりますね。

——リベンジ？ 失敗の原因は何だったのですか？

田中：当時は職能別の部署は残したまま、その上に重ねる形でフィーチャーチームをつくったんですが、会議体が増え、生産効率がガクッと下がってしまったんです。

社内アンケートをとったところ、「部署とフィーチャーチーム、どちらの目標を優先すべきなのか、混乱した」とか、「人は増えていないのに、タスクと会議が増えた」という声が上がりました。

当時の失敗はドキュメントに残してあります。

岩瀬：ドキュメントにしっかり残してあるんですね。アンチパターン（失敗経験）はなかなか世に出回らないので、これは貴重な資料ですよ。

——その失敗も踏まえて、今回のフィーチャーチーム体制があるわけですね。

田中：そうですね。具体的には、モノリスなシステムをマイクロサービス化などの手法を用いてサービスに分割していくこと（図1参照）。そして、それを推進するために、各サービスにひもづくフィーチャーチームを作り、固定的にサービスを見守れる体制を敷くことを進めています。

固定のチームを置くことで、課題であった「毎回、知見が失われてしまう」ような事態も防げますし、明確に境界のあるサービスを管理するので、アジャイル前提のスクラム開発もやりやすくなります。結果として、自走できる組織へ近づくのではないかと考えています。

岩瀬：フィーチャーチーム制にすることで、意思決定のスピードも速くなりそうですね。意思決定の遅さは地味だけど、かなりのストレスになるので、とても良いチャレンジだと思います。

また、ピープルマネジメント部はChatworkさん独自の手法で、面白い取り組みですね。本格稼働を前にトライアルもされていたそうで。

田中：はい、試験運用の際はトライアルとして1名、ピープルマネージャーを任命し、実際に複数チームを外部からマネジメントしてもらっていました。

業務の分担範囲としては、業務への直接の指示はしない代わりに、勤怠管理や1on1を通した状況把握、コーチング、目標管理などを担う形ですね。

うまく回っていたので、10月からは人数を増やし、「部」として稼働してもらっています。

冒頭で「EMの知見はパターン化がしづらい」という課題が出ましたが、「部」として複数名で取り組むことにより、ノウハウが多少パターン化され、スケールできる体制になっていくのではないかと思っています。

岩瀬：今のお話で、気になるのが評価のあり方です。

テクニカルチームをマネジメントするには、各メンバーの「働き」を何らかの方法で評価しなければなりませんよね。外から働きを評価するとなると、どのように必要な情報を得るのかなと。

田中：おっしゃる通りで、例えば全員のプルリク（プルリクエスト）をすべて確認するとか、チャットでのやりとりに全て目を通すみたいなやり方は現実的に不可能です。その上で、各人が納得のいく評価をどう行うかは悩ましいポイントです。

加えて、離職リスクを避けるには、「個人が会社にどれだけ貢献したか」だけでなく、「会社が個人にどれだけの成長機会を与えられたか」も重視しなければなりません。

つまり、個人から会社への評価もチェックし続けなければならないわけです。

これらの複雑なマネジメントをピープルマネジメント部という「外」のチームが適切に行えるかどうかは、今後注視しなければならないポイントではあります。

——エンジニアの評価について、岩瀬さんは日頃のご経験からどのようにあるべきだと考えていますか？

岩瀬：評価において一番大事なのは納得感だと思っています。

例えば、最近では「ノーレイティング」という新たな評価手法が広がりつつあります。

この手法では、評価のタイミングを「半年に1回」から「毎週や毎月」など頻度を増やした上で、A〜Cの無機質で画一的なランク付け（レイティング）を廃止し、代わりに1on1等で細かいフィードバックや評価を伝えます。名前から「評価しない」と誤解されがちですが、そうではありません。

メンバーからすると、半年前のほとんど覚えていないようなことに対して、無機質なランクで総決算されると、納得感が生まれにくくどうしてもモチベーションが下がってしまいます。

ノーレイティング手法のように、日々の頑張りをアジャイル的に評価できれば、フィードバックに納得感が生まれます。

田中：確かに。良いフィードバックであっても、半年もたつと「今さら？」と感じてしまいますからね。

岩瀬：なおかつ大切なのは、なるべく事実にもとづいた評価を伝えることですね。

僕がやっているのは、Slackでもプルリクでも、その人の発言をとにかくメモしておくこと。良いことも、悪いこともです。

そして、その事実にもとづいて「この働きはうれしかった」「ここは改善してほしい」と伝える。これが徹底できていれば、ピープルマネジメント部という「外」からの評価であっても、そこまで的外れなものにはならないのではないでしょうか。

解決の糸口は、「アンチパターンの共有」と「Howの抽象化」

——今日のお話を踏まえて、「EMスーパーマン問題」の解決の糸口をどうお考えですか？

岩瀬：「EMスーパーマン問題」解決の糸口は会社規模やカラー、事業フェーズによって大きく変わるはずなので、一概には言えないのが正直なところです。

ただ、Chatworkさんの事例を伺って一つ明らかになったのは、EM自身が組織の状況に合わせて常に改善策を模索し、アンチパターン（失敗経験）をドキュメントとして能動的に蓄えていくことは、どの会社でも取り入れられる打ち手だと思いました。

自分たちの失敗をしっかり振り返り、同じ轍を踏まないよう次に生かす。これが実践できている会社は非常に少ないと思っていて。Chatworkの資産とも言えるのではないでしょうか。

田中：ありがとうございます。僕たちChatworkが目指しているのは単なる「ビジネスチャットNo.1」ではなくて、「中小企業DXのソリューションになる」こと。

その目標を達成するためにも、エンジニアのパフォーマンスが最大化されるような体制づくりを引き続き行なっていく予定です。

岩瀬：Chatworkさんのように急成長中の組織では、さまざまなWhat（何をやるべきか）が浮上します。このWhatは会社によって大きく異なるので再現が難しいですが、How（どうやるべきか）はまだ抽象化と横展開の余地はあると思っています。

だからこそ、組織づくりのHowに挑み続け、アンチパターンを含めたノウハウを蓄積しているのは正しい姿勢だと思いますし、EMの負担も減っていくはずです。

田中：現在はどちらかというとトップダウン的な改善に取り組んでいるのですが、今後はボトムアップ的な改善もできるような自律組織になっていきたいものです。

それによって個々のメンバーの活動を強力に支援できれば、既存のメンバーの成長や働きがいにつながるのはもちろん、新たな仲間も迎えやすくなるはずだと信じています。

＞＞＞Chatworkの採用情報はこちら

文／夏野かおる　撮影／桑原美樹　取材・編集／玉城智子（編集部）

撮影場所：Chatwork 東京オフィス（WeWork 日比谷 FORT TOWER）