BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

BASEでエンジニアリングマネージャーから再びエンジニアに戻って感じたこと

f:id:aiyoneda:20190523193208j:plain

こんにちは、CommerceDevというチームでエンジニアをやっています島田です。 このチームは、Eコマースプラットフォーム「BASE」のサービスの根幹を作る事をミッションとし、ショップオーナーの管理画面や決済機能の改善に取り組んでいます。チームができる前は決済チームのエンジニアリングマネージャー(以下EM)をやっていたのですが、いまはEMを移譲しエンジニアとして働いています。

今回はマネジャーを移譲した理由を含め僕がBASEに入社してからのチーム変化を書きたいと思います。

EMになるまで

僕が入社した当時、社内にエンジニアは10名程度でした。現在は約50名のエンジニア組織になりました。

エンジニア以外の社員も増え、それに伴ってかつて問題ではなかったことが問題になったり、これから問題になるだろう課題も抱えるようになっていきました。人が増えると組織としてやることが増えますが、エンジニアも例外ではありません。細かい事の積み重ねにより関心事が増えるとエンジニアが本当にやりたい事に集中してコミットできなくなり、結果としてパフォーマンスを十分に発揮できないという悪循環に陥ってしまいます。

それを解決するためにエンジニアとしてどういった振る舞いをするのが良いのか考えた時、今はマネージャーになりエンジニアがエンジニアとしてちゃんと力を発揮できる環境を作ったほうが良いのではないかと思いました。

EMとして考え実施してきたこと

どういった制度や環境があればエンジニアが事業に一番コミットできるかを考えていました。

自分の背景がエンジニアなので、エンジニアとしてここはこうしたほうが良いと思うことを検討し、関係各所と連携して進めました。実現するためにはエンジニアだけでなく人事や労務など別の部署にも協力をお願いすることが多いので、関係各所との関係性を構築しておくのも大事だと感じました。

ここからは、EMとして考えて実施してきたことをいくつか挙げてみたいと思います。

  • 採用
  • ビジネスとプロダクトと開発の課題調整
  • エンジニアの提供価値に対しての適切な評価
  • エンジニアの生産性向上・スキル向上に寄り添う

採用

組織の規模が小さかったときは各エンジニアが全体を見ることもできたのですが、組織が大きくなるにしたがって並行で進行するプロジェクトが増えたためそれが難しくなっていきました。

当初は1人のエンジニアが開発を複数かけ持ちすることもあったのですが、やはり関心事が増えると一つのことに集中しにくくなり結果的にあまり生産性がよくありませんでした。また、エンジニアが他社との折衝やテストの段取り、カスタマーサポートチームへの共有といった開発自体以外にも工数が取らていることは課題だなと思いました。

そこで、開発時の役割を細分化しエンジニアは開発に専念できるよう、工程管理などは開発ディレクターを立てることにしました。すでに社内にもいましたがエンジニアの数とのバランスが取れていなかったのと、今後さらにエンジニアが増えたときにもっと必要になると思い、組織や会社の状況を考察しながら、どういった人材が必要か検討し人事などと協力し採用を進めました。

開発現場の意見やプロダクトの成長から、今後どういった組織にすべきか、どういった人材が何人必要なのか、人事と協力しながら解決していきました。

ビジネスとプロダクトと開発の課題調整

BASEの機能開発の基点とには、プロダクトマネージャーやBusiness部門(事業開発、カスタマーサクセス、カスタマーサポート、マーケティングなど)の企画・依頼以外に、エンジニアからの課題発見や機能提案があります。

この時に、「この機能を開発してもらいたい」「こっちのほうが優先順位が高いのでは?」とグループの目標や視点の違いによって、組織の課題認識にズレが生じる場合があります。

そこでEMは全体を理解し、その時・その後も最適になるようにうまく調整する必要があると思います。 あるときにはプロダクトマネージャーやBusiness部門からの開発案件を優先し、またあるときには開発側として重要だと思うことの優先度を上げる。そのためにEMがそれぞれが納得感を得られるように調整し目標咀嚼して伝え協力的な職場をつくることに取り組みました。

時々、開発現場からの意見や課題はプロダクトマネージャーやBusiness部門とは別の観点を優先していることもあります。ですが、その課題の解決を疎かにしてしまうとふとした時に事業やプロダクトの成長の足かせになってしまいます。事業とプロダクトの長期的なビジョンをEM自身が理解納得したうえで、エンジニア個人の短期・中期・長期的な成長・変化を想像しつつ、実現するためにどういった環境にすべきか考えていきました。

エンジニアの提供価値に対しての適切な評価

EMの役割として一番重要だと思います。どんな成果物を作ったかという点に偏りがちですが、それ以外にもたくさん評価すべき点があります。例えば次のようなことも評価対象にしていました。

テックブログの投稿、カンファレンスへの登壇

技術力の向上は良いプロダクト作りへつながり、良いサービスを提供できるようなると考えています。私たちが使っているOSSやコミュニティへの貢献もできます。また、社内の別のエンジニアに対しても良い刺激になります。

レビュー時の指摘が的確、コメントが優しい

的確なレビューはそのままコードのクオリティ向上に繋がりますし、優しいコメントはレビューを依頼しやすい空気感がうまれ、心理的安全性に繋がります。また、レビューは教育的要素があるので技術の底上げにも繋がります。

自分以外の人でも分かるようにドキュメントをまとめた

ドキュメントは大事な資産だと思います。開発の経緯や使い方などをきちんとドキュメントに落とし込んでおいてもらえると誰かに作業を依頼するときにも調査などの時間を削れますしミスも少なくなります。また、自分でも半年くらいすると記憶が曖昧になるので、そういったときにも役立ちます。

メンバーの普段の活動を通じてどういった価値を提供しているかをしっかり見続けて、適切に伝えていくことが大切だと思います。メンバーとの1on1や上長とのミーティング時の他、普段からピアボーナスのUniposを使ってメンバーの良かったことを伝えていました。

エンジニアの生産性向上・スキル向上に寄り添う

  • 性能の良いPCや自分にあった椅子を推奨
  • 技術書の購入補助
  • カンファレンスやテックイベントへの出席・登壇を推奨

このあたりの制度や文化はすでにベースがあったので僕の方では大きなことはしていません。もしこれから検討する場合は総務や労務の方と一緒に進めていったと思います。

組織がどう変わっていったか

組織構築の一環として採用を強化しことによりメンバーが増えました。メンバーが増えたことによってノウハウも増えましたし、メンバーが自主的に行っていた勉強会やイベント登壇などに賛同する人も増えました。

各メンバーが会社や社外に提供してくれた価値をきちんとポジティブ評価することによって流れが加速し、新しいことへ挑戦するモチベーションと技術の向上のにつながりました。

EMはメンバーが活躍できるフィールドを作り、そしてメンバーを集め、活躍できるようにフォローし、適切に評価することが大事だと思いました。

EMとエンジニア文化

EMはメンバーの評価や組織作りを通じて会社のエンジニア文化を作ることができます。良い文化ができると良いエンジニアが集まってきます。

エンジニア文化は一夜ではできないし1人で作ることは難しいです。メンバーの協力がなくては実現できないので、メンバーやEM仲間にも協力してもらいながら少しづつ積み重ねていくと良いと思いました。

一方でエンジニア文化は定期的に見直すと良いと思いました。時間がたつとその時の最適解が今の最適解ではないことが多いです。また、グループごとに培った良い文化を交換留学のように取り入れあうのも良いです。そのためにはEMはローテションさせ、定期的に客観的な視点で見直しを行うのが良いと思いました。

EMの先のキャリア

社内にはEMの先の事例がないことにも気づきました。 「プログラムを書くのは好きだけどマネージャーになってからコードを書く時間が減ってしまった。」という言葉も良く聞きます。

エンジニアからEMになった後に再びエンジニアになるというのは、正直なところネガティブな印象があるかもしれません。ただその印象を少しでも変えられたら、エンジニアのキャリアパスを広げられるのではと思っていたので、自ら実行することにしました。あわせてEMが居なくなってしまうと組織のバランスが崩れてしまうので権限委譲も合わせて行いました。

エンジニアに戻ってみて感じたこと

プロダクトは日々成長していたので、再びエンジニアとして途中から開発に合流することは不安でした。

それを救ってくれたのが意外にも自分でやってきたことで、たとえばドキュメントやログをちゃんと残すことや、他の社員へのノウハウの共有を評価項目としていたおかげで調べたり聞けばなんとかなる環境ができていました。

エンジニアのためにやってきたことが正しいことだったのか、自分がその立場になることで結果検証できたのがよかったです。

おわりに

当時はEMになろうとは思っていませんでした。ただ結果的に自分のやってきたことを振り返ってみると、CTO藤川の記事にもある、 「事業、プロダクトに貢献しながら、チームのエンジニアの活躍にコミットすることで、メンバーの評価を上げる仕事」 になっていたなと思います。

(参考:エンジニアとしてワクワクし続けるためのエンジニアリングマネージャという役割分担

エンジニアの働きやすさというのは組織の変化や個人のライフスタイルの変化によっても変わってきますので、その時々で課題を感じた人がEMの役割を担い自分が働きやすい環境に改善していける文化があると良いのではないかと思います。

BASEではEMによるエンジニアのためのエンジニア組織の改善を日々行っています。エンジニア、EMの仲間を募集中です!もしこの記事を読んでご興味を持った方はぜひご連絡下さい。

herp.careers