SPIDERPLUS Tech Blog

建設SaaS「スパイダープラス」のエンジニアとデザイナーのブログ

エンジニアリングマネージャー1年目の開発チーム運営思想

はじめに

こんにちは!スパイダープラスでエンジニアリングマネージャーを務めている本田です。

私は入社して3年目、エンジニアリングマネージャーとしては1年目になります。
これまで約10年間ソフトウェアエンジニアとして働いてきましたが、開発リーダー的なポジションの経験はあるものの、マネージャーとして明確に自分のチームを持つのは弊社が初めてでした。

マネージメント職にチャレンジした理由は、エンジニアとして培った「こうすればもっと良くなる」というアイデアを、弊社の持つ環境でなら実現できると確信したからです。

この記事を書くことにした動機は、長い間マネージメント職を敬遠していた私が、今ではとても楽しくマネージャーとして仕事をしていることが挙げられます。

本記事のテーマは私が開発チームの運営をする上で大切にしている価値観や考え方です。
もし、この記事を通じてエンジニアのマネージメント職に対する新たな視点や魅力を感じてもらえたら嬉しいです。

チーム運営の軸

早速ですが、チーム運営の軸は「チーム全員が楽しく仕事すること」です。

弊社では『“働く”にもっと「楽しい」を創造する。』というミッションを掲げており、私自身、この価値観に共感して入社したことも背景の1つです。

もちろんこのミッションは主にお客様に向けられたものですが、私は社内やチームに対しても同じことが言えると考えています。

エンジニアとしての経験から、楽しく仕事してる時ってどんな時かを考えた結果、集中して仕事をしている時が最も楽しいと感じました。
集中して仕事するということは生産性にも良い影響を与えます。

チームの本質的な役割を考慮し、プロダクトの価値を高めるための開発業務に集中できる環境を作ることが私の使命だと思っています。
油断するとタスクはどんどん増えていくので、やることを引き算で考え、本質に集中する時間が減らないように注意しています。

Note: 具体的にやったこと
  • 無駄な会議を作らない。目的不明の会議に呼ばない。
  • マルチタスクにならないようにタスクをコントロールする。
  • プレッシャーが大きくならないようにスケジュール管理する。
  • 明らかに別チームの仕事を受け持っていた場合はきっちりメンバーの手から離れるように調整する。

チームビルディング

チームの力を最大限に引き出すために、最初に信頼関係の構築に取り組みました。
1on1(※メンバーと上長が定期的に行う面談)や定例会議などのイベントはもちろんなのですが、日常の中でのコミュニケーションを何よりも重視しています。

私は、メンバーが自信を持って主体的に動けることが健全な状態だと考えています(スポーツのチームをイメージしてください)。
そのために重視していることは「共通認識の形成」と「期待値の調整」です。
この価値観を共有した上で、率直な意見を送り合うことができるような雰囲気を醸成することが良いチームの土台に不可欠だと考えます。

このような動きは、自分のチーム内だけでなく、他のチームとも協力して行うことも意識しています。
なぜなら、仕事の多くは自分のチームだけで完結しないからです。
なお、弊社の開発を担うチームは実際の部署的には事業チームと横断チームのメンバーで構成されています。
開発組織の構成について、詳細はVPoEによる記事「スパイダープラスの開発組織構成について」をぜひご覧ください。

techblog.spiderplus.co.jp

Note: 具体的にやったこと
  • 最初のうちは特に口頭でのコミュニケーション機会を増やす。
  • メンバーからの質問や相談を最優先で誠実に対応する。
  • すぐに返せない場合でも、リアククションを惜しみなく駆使する。
  • slackのチャット、ハドル、対面、Google Meetなど、使えるものはなんでも使う。
    slackのチャットで相談があれば即座にハドルをかけて通話を開始するなど。
  • 自分が忙しそうな時でもカレンダーの空いているところに自由に予定を入れて良いことを伝えておく。
  • 定例や会議にはメモを必ず用意し目的を必ず明記する。その場で認識のズレを埋められるよう同じGoogleドキュメントを見ながらメモを取り会話する。
  • 期待値を伝えるだけでなく、相手からの期待値も聞き、すり合わせていく。

プロジェクト管理

プロジェクト管理のハードスキルについては私自身が最も苦手意識を持っており、マネージャーになることを敬遠していた最大の理由でもあります。

スクラム開発に憧れて勉強や思考実験をしてみたものの、いくら考えても環境面で足りないピースがあり、結局導入しないという判断をしました。
その代わり、スクラムの三本柱

  • 透明性
  • 検査
  • 適応

そして5つの価値基準

  • 確約(Commitment)
  • 集中(Focus)
  • 公開(Openness)
  • 尊敬(Respect)
  • 勇気(Courage

この考え方には大いに影響を受けており、これらを運営方針の至る所に反映しています。

プロダクトの価値向上を主目的としたフィードバックループ確立のために、商品企画チーム、デザイナー、テスターを含むチーム全員に定期的に動くものを見せる機会を設け、その中で得たフィードバックを開発に反映するようにしています。

また、透明性を確保するために、必要な情報を明記したIssueテンプレートを準備し、メンバーに必ず項目を埋めてもらうよう促しています。

プロジェクト管理と言えるほどのことではないかもしれませんが、日常の中のリスクをまだ小さいうちにキャッチアップできるようにし、必要な意思決定をするタイミングを早めて問題対処するようにしています。

意思決定の際には、スピードだけでなく意図や理由を明確にして伝えることも心がけています。

意思決定をする機会が増えて感じたことは、決断はした時点で正しいかどうか決まっていることはそんなに多くなく、決断した後にそれを正しいものにしていくんだという心構えが大事であるということでした。

Note: 具体的にやったこと
  • デイリーミーティングでは「タスクをブロックしている問題を明らかにすること」「共通認識を形成すること」を目的として掲げ、必ず毎日の議事録の見えるところに記載している。
  • 週一で関係者全員(約10人)を集めて、開発中のプログラムが動いているところを見せて全員でフィードバックを送り合う開発レビュー会を実施している。
  • Issueテンプレートには「背景を明確にすること」「詰める必要があることを明確にする」などのポイントとその理由や例を記載している。

技術的リーダーシップ

EMだからといって、メンバーの誰よりも高い技術力を持っている必要があるとまでは思いません。非常に高いスキルを持つメンバーがいる場合は特に、です。

一方、対等に議論できるだけの知識や理解力、経験の浅いメンバーを教育するための経験と指導力があると生かせる場面は非常に多いと思います。
特に、エンジニアとしてスペシャリストを目指してきた方ほど、大きな強みになるはずです。

正解がない中で、問題解決方法の引き出しの多さ、設計方針を決めるための軸、コード品質に貢献するためのプログラミングに対する考え方などはメンバーの成長にも強い影響を与えるのではないでしょうか。

また、技術選定においても一定のこだわりをもち、自分がやりたいからという理由でエゴイスティックに決め、それを言語化した上でチーム内外と合意を形成しながら推進するような行動もしています。

私が参画した当時に「整っていない」と感じていた開発者体験に継続的に手を入れ続けていることは、チーム内からもポジティブなフィードバックがあります。

変化の激しい世界ですが、変化を待って適応するだけでなく、自分たちでアグレッシブに変化を起こしていくことが技術的負債の解消、チームの責任感やオーナーシップに繋がると信じています。

Note: 具体的にやったこと
  • 相談があったらなるべくその場で問題解決に導き、思考過程をなるべく言語化しておく
  • ブランチ戦略の策定と戦略に合わせた開発環境整備
  • DBマイグレーションツールの導入
  • CIの導入(ユニットテスト、Linter、GitHub Action)
  • クラスコンポーネントで書かれていたReactプロジェクトに関数コンポーネントの導入
  • 状態管理にSWRの導入
  • JavaScriptプロジェクトでTypeScriptを導入中(現在進行形)
  • 隙をみてライブラリのバージョンアップデート
  • 本番環境と他環境の癒着を分離

チームの成長

会社やプロダクトがより成長していくために、チームの成長および個人の成長を意識しています。

私がメンバーに仕事を渡す時は、ゴール・背景・方針を伝え、進め方は自由にお任せしていることが多いです。
基本スタンスとして、価値のあるプロダクトを作るためにできることはなんでもやってよいという方針を取っています。

そのため、メンバーには進め方に関して裁量が大きいのですが、信頼関係の構築を怠らなければ問題になることはありません。

Will/Can/Mustについてはメンバー自身に考えてもらうこともありますが、1on1や普段の会話・行動の中から感じたこともすり合わせることにしています。

得意な分野(Can)でバリューを発揮してもらい、伸ばしたい部分(Will)の仕事にできるだけ時間を割くことができるようにタスクを配分しています。
たとえ未経験の業務だとしても、基本的に任せてサポートする方針を取り、なるべく経験値を奪わないよう心がけています。
Mustの仕事は負荷がかかりがちのため、増えすぎないよう調整や業務の見直しを行い、余裕のある時に消化します。

チームの人々の士気を高め維持することはマネージャーとして重要な役割の一つだと思っています。
私のチームはメンバー全員が成長意欲に溢れており、こういった方針とも相性が良いことを幸運に感じています。

Note: 具体的にやったこと
  • 進め方の裁量はありつつも開発のガイドラインやフローの原型を考え方と共にWikiに明記しておく
  • 仕事を渡す時は方針と一番最初にどこから手をつけるべきかというところについて認識をすり合わせてからスタートする
  • 抽象度が高い状態で仕事を渡す分、全力で支援することを約束する
  • 渡した仕事に価値があることとその理由を伝える
  • メンバーのエンジニアとしての市場価値向上にも寄与するという観点でも開発者体験を向上する取り組みや技術選定を積極的に行う
  • 提案に対しては実現するために何が必要なのか一緒に考えたり、チーム全員で全力で支援する

さいごに

ここまでお読みいただきありがとうございます。

まだまだうまくいかないことも多く日々学びの連続ですが、尊敬できる優秀なメンバーはもちろん、的確なフィードバックや裁量を与えてくれる上司、共に良い物を作ろうと協力的な他部署の方など、いい人たちにいつも助けられ非常に恵まれた環境で仕事をできていることに感謝しかありません。

ありがたいことに、私のチームは非常に高いエンゲージメントであるということがwevox(※調査項目を元に従業員のエンゲージメントを可視化するツール)の数値に表れていました。

最初は自分の判断に不安を感じることもありましたが、トム・デマルコの『デッドライン』を読んで価値観が変わり、今では少しずつですが良い方向に進んでいると確信しています。(この書籍の魅力についてはまた別の機会で紹介できればと思います)

これからは、マネージメントにおいて、最も重要な仕事の一つである採用にも積極的に関わっていきたいです。
今後もよろしくお願いします。

スパイダープラスでは仲間を募集中です。
スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。