始めに
こんにちは。株式会社ペライチ のエンジニアリングマネージャーの藤代と申します。
半年と少し前にフロントエンドエンジニアとして下記記事を執筆したのですが、その後キャリアをマネジメント方向に進めるする運びとなりました。
本記事では、新米のエンジニアリングマネージャーとしてかれこれ半年ちょっと仕事をしてきた中で実際にやったことやその結果についてまとめます。
マネージャーに期待される成果は「チームで成果を出すこと」や「未来を描いて周りを巻き込み計画・実行すること」や「他者を通じてものごとを成し遂げる」などと一般化されることが多いようです。
ただ、実際の組織内での具体的な役割や必要とされる立ち回りは組織の成長フェーズや担当するチーム、さらにはチームメンバー構成などさまざまな要因によって変化すると考えています。
また、アジャイル型の組織におけるエンジニアリングマネージャーの仕事に関する情報や書籍も欧米やその他のマネジメント職と比較すると少なく、職務の定義自体も定まりきっていないような気がしています。
本記事がひとつのケーススタディーとして、「これからスタートアップのエンジニアリングマネージャーを担当するぞ」という新米のエンジニアリングマネージャーの方の参考になれば幸いです。
背景
詳しくは後述しますが、当社には開発職に対してマネジメントのキャリアパスとエンジニアとしての専門性を極めるエキスパートのキャリアパスが用意されています。
もともとフロントエンドエンジニアとして入社して開発業務に携わる中で、チームを巻き込みながら仕事をしていくことに楽しさを感じ、マネジメントの方向にキャリアを進めることにしました。
また、周囲からの評価においても自身の技術力・開発能力よりもチームの垣根を超えて仕事をする点に評価をいただけていると感じていることも多くありました。
「できること/やりたいこと/求められていること」のクロスポイントに合致していたのもマネジメントにキャリアを進める背景として大きかったように感じています。
前提
当社のエンジニアアリングマネージャーは下記業務を兼務しています。
詳しくは当社採用サイトから確認できますので、興味があればご覧ください。
- ピープルマネジメント（1on1、目標設定/評価、組織設計）
- 開発業務（要件定義, 設計, 開発, ソースコードレビューと、上流から下流まで）
- プロジェクトマネジメント（事業目標に合わせた計画策定、 PJ 推進、スクラムマスター）
- 必要に応じた人材採用へのコミット
- 開発チームのチーム編成や、プロジェクトにおけるチーム管理
- 全社会や役員会など社内ステークホルダーへの適宜報告
ピープルマネジメントからテクニカルマネジメントおよびプロジェクトマネジメント、そしてプレイングマネージャーとして自身も引き続き開発します。
私自身もフロントエンドエンジニアとしては変わらず開発を続けていることが前提です。
プロダクトマネジメントは含まれていませんが、プロダクトマネージャーを兼務しているエンジニアリングマネージャーもいます。
また、プロジェクトマネジメントにスクラム開発におけるスクラムマスター業務も入っていることが前提となるため、詳しくは後述しますがマネジメントとの兼務のメリット/デメリットも存在します。
前提となる、当社の開発体制の全体像については下記記事を参照いただければ幸いです。
なお、当社のキャリアプランにはマネジメントを志向するキャリア以外にも、技術を志向するエキスパートのキャリプランも用意されています。
具体的なコードや設計などによる課題解決によってチームをリードするのがエキスパート。
対して、エンジニアリングマネージャーはチーム目標の設定やリソースの調達やアサイン、チームで QCD(Quality/Cost/Delivery) を担保するのをリードするという棲み分けがされています。
三十の手習い
六十の手習いではないですが、今年年齢も 30 となりマネージャー職にチャレンジするということであらためてどうやって新米フェーズを過ごしているのかを記録しておきます。
今までのキャリアにおいて制作会社などでフロントエンドエンジニアのリーダー職を経験することはあれど、「人/事業/組織/教育」に関わっていく、いわゆるマネージャー職についたことはありませんでした。
また、過去のキャリアにおいてマネジメントに関する教育や研修を受ける機会もなかったため、やったことが正しいかは置いておいて、私のやってみた内容がどこかの新米マネージャーの参考になれば幸いです。
20 代でチャレンジしている子達はすごいなあと感じるこのごろです。
①読んだ本やドキュメント10選
手習いの基本はとりあえずインプットからということで、とりあえず古典と呼ばれている本から最近出版された本まで取り急ぎ必要そうなものをざーっと読みました。
業務をしながら必要そうだと感じた本も適宜読んでいったのですが、比較的ちゃんと読んだもの割と何度も読み返しているものを中心に本やドキュメントを紹介します。
アジャイルソフトウェア開発宣言
アジャイル開発のスクラム開発を採用している組織ですので、開発マネージャーやるならなんにせよこの文章だろということで折に触れて眺めていました。
なんなら、会社のビジョン・ミッションの次くらいに眺めていました。たぶん。きっと。
医学部の学生はヒポクラテスの誓いだったり、ジュネーブ宣言だったりを覚えるとどこかで聞いたことがありますが、そんな感じで読んでおきたい文章だなと。
キャリアの中できちんとした情報工学の教育などを受けてきた訳ではないのですが、職業倫理的な考えの方の拠り所にして、定期的に読み返したいとあらためて感じています。
マネジメント[エッセンシャル版] - 基本と原則
マネージャーと言ったらこの本だろうということで、大学生ぶりに本棚から引っ張り出して読み返しました。
相変わらず読み返しても 1 ミリも内容を理解できていないですが、モチベーションと意識は大学生のころのように高くなったのでお勧めです。はい。
古典なのでその他の本の元ネタはだいたいこれだろうと考えつつ、また経営レイヤと少しでも共通言語ができたらという気持ちで読み返しました。
私が高校生から大学生だったころは「もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら」などが流行したので懐かしい気持ちになりながら本棚を漁り返しました。
だいたい皆さん 1~2 冊はドラッカーの本を本棚に積ん読しているのではないかと想像しているので積ん読消化の意味でもお勧めです。
HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント
こちらもマネジメントの名著ということなので読みました。ドラッカーさんと合わせてたぶん 1 ミリも内容を理解できていないですが、「マネージャーってよいな！」とモチベーションは高くなるのでお勧めです。
マネージャーのアウトプットは「自組織のアウトプット」と「自分の影響力の及ぶ隣接組織のアウトプット」を足したものであること。
またそのためのマネージャーの行動や振る舞いを具体的に示してくれているので普段の自身の振る舞いの規範の参考になりました。
増補版 駆け出しマネージャーの成長論
軽い読み物的な感じでサラッと読めるので箸休めにちょうどよい感じです。日本国内のプレイングマネージャーたちの悲哀のようなものも感じられつつ、新人マネージャーが遭遇するであろう挑戦課題を一般化してくれています。
これから遭遇することに思いを巡らしつつ、「まあ最悪失敗してもええか」くらいの気持ちになれるので事前に読んでおいてよかったなと感じています。
急成長を導くマネージャーの型 ～地位・権力が通用しない時代の“イーブン”なマネジメント
前半に紹介した本が古典やマネージャーの一般論を説いているのであれば、この本は「ベンチャー企業で求められるマネージャーの役割」と「具体的に現場に落とし込みやすいフレームワーク」が紹介されている本です。スタートアップの現場に即した内用なので実感を伴って現場で活用しやすいと感じました。
特に、変化の激しいスタートアップにおける現状把握のための方法論などはチーム運営をしながら何度も読み返したりしていました。というかいまだに身についている感覚がないので折に触れて読み返している...。
会社の研修制度を利用したり、現場ですでに活躍している先輩マネージャーの振る舞いを抽象化して摸倣しながら PDCA サイクルは回しつつも、適宜振り返りをしながら読み返すのにちょうど良い本です。
プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで
当社のエンジニアリングマネージャーの職務にプロダクトマネジメントは明示的に含まれている訳ではありません。（メンバーの中には、プロダクトマネージャーと兼務しているエンジニアリングマネージャーもいますが）。
とはいえ、プロダクトのステークホルダーとの会話が増えるほか、どういった指標をなぜ追いかけるのか？といった理解から、プロダクトマネージャーがどういった目線でもって開発とコミュニケーションを取っているのかをざっくりと理解するために読みました。
エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法
エンジニアリングマネージャーの仕事術や「エンジニアリングマネージャーって何する人やねん！？」という部分に対して、具体からポエミーな内容まで含めて書かれている本です。
オライリー・ジャパンから出版されているのでとりあえず目を通しておきましょうという感じがする本です。
ちょっとつらいことや他の人ってどうやっているんだろうなということがあったときに辞書的に引くのがお勧めです。
その他のマネジメントの本よりもより IT 業界の現場に即した形での世渡りの方法が書かれているのでちょっとだけ心にゆとりができます。
スクラムガイド2020
とりあえず用語やスクラムの各種イベントのおさらいも兼ねてざっと目を通し直しました。
なんなら、入社してからちゃんと読んでいなかったのですが、スクラムマスタを兼任することになってようやくちゃんと用語の振り返りとして読みました。
いちフロントエンドエンジニアとしても追いかけていたドキュメントはたくさんありましたが、また１つ定期的に改訂版を追いかけていかないといけない文章ができたんだなという気持ちで向き合いました。
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
スクラムガイドの補間的なドキュメントとしてざっと目を通しました。
「あー、あのイベントはこういうことをやっていたのね」と実際の自分がいち開発者としてスクラムチームで体験したことをスクラムマスターの視点を想像しながら読み返しました。
現場での動きを振り返りながら読んで、過去 1 年の自身が所属していたスクラムチームの動きを振り返るのにちょうど良い本だったと感じています。
SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ
「スクラムガイド 2020」と「SCRUM BOOT CAMP THE BOOK」を補間する形で「そもそもスクラムマスターって何やねん？」を理解するために読みました。
開発者として所属していたスクラムマスターを想像しながら「あー、たしかにやってくれたわー！」とか思い出しながら読みました。
特定の人物を想像しながら、その立ち振舞を一般化しながら振り返るのに役立ったような気がしています。
また、スクラムマスターがマネージャーと兼務する場合のメリット/デメリットについても明記されており、「しばしば命令的でコーチングせずに、メンタリングに頼ります」という文が印象に残っています。
チーム率いるのではなく、自己組織化、当事者意識をメンバーに持ってもらうようにスクラムマスターとマネージャー業務ではペルソナを変えて立ち振る舞う必要があるのだと意識するようになりました。
②社内研修の活用
自身での学習だけではなく、会社からのサポートもあったので活用しました。
具合的には当社代表の安井の Note 記事を参照ください。
社内で開発部だけではなく、他部署と合同で実施された研修なのですが、実際に参加してみてよかった点は下記と感じています。
- 3 年後の定性目標・定量目標を考える機会が得られた。
- 周りの諸先輩方が事業の未来をバックキャストで考えているのを実際にみて、「あーこういうこと考えなきゃいけないんだ」と思えるようになった。
- 他部署のマネージャー陣と事業について話し、考える機会が得られた。
- マネージャーのアウトプットが「自組織のアウトプット」と「自分の影響力の及ぶ隣接組織のアウトプット」を足したものとするなら、交流って大事だよなとあらためて思った。
社内外の研修制度については、読者の皆様いろいろなケースがあるでしょう。
ただ、一般化しても他部署のマネージャーと事業の数年後の定性目標や定量目標についてディスカッションする場に積極的に参加するのは新米マネージャーとしてやってよかった経験だと思っています。
③社内で評価されているマネージャーの行動の抽象化とひたすら摸倣
本でインプットしたり研修でアウトプットしたりしましたが、結局「何すればええねん！」という状態になりがちです。
なので結局最後は「社内で評価されているマネージャーの行動を徹底的にパクる」ということをやっていました。今でもやっています。
たとえば、スクラムの運営で迷ったら下記記事を執筆したマネージャーのスクラム運営方法を真似していました。
スクラムゴールの立て方から、プランニングポーカーのし方、スプリントの振り返りのし方。
それこそ MTG やプレゼンの前後の雑談でのアイスブレークのやり方まで真似していました。
またたとえば、オンボーディングの方法。
普段の Slack の通話やハドルを用いたコミュニケーションなどは下記マネージャーのスクラム運営を真似したりしていました。
本や研修でインプットして、とりあえず真似してやってみて、定期的な 1on1 でフィードバックをもらいながらなんとかかんとかやってこれた感じが強いなと感じています。
実際にマネージャー業務をする中で直面した課題と解決策
新米としてなんとか半年やってきたわけですが、エンジニアリングマネージャー業務をしながら直面した課題の中でも特に印象に残っていることを 5 つピックアップします。
①新チーム体制でも安定したQCDをまずは実現する必要があった
私がエンジニアリングマネージャーとしてチームを担当した時点でチームの状況は下記の通りでした。
- 旧チームからマネージャーとスクラムマスターを自分が引き継ぎ
- 主要な社員メンバーは新チームへ移籍
- 週 3~4 稼働の業務委託メンバー 3 人と週 5 の自分がチームメンバー
- フロントエンド 3 名 + サーバサイド 1 名でサーバサイドメンバー不足
当社に関わっていただいている業務委託メンバーは皆さん技術力もあり人格的にもすばらしい方ばかりで、旧チームから一定のチームワークは形成された状態での引き継ぎでした。
ただ、フルタイムメンバーが 1 名だけの状態かつ、バックエンドが 1 名という偏りの中でのチームであったため QCD の安定化は喫緊の課題でした。
具体的な対応方法としては至極シンプルかつ普通の内容ではありますが、下記を意識することで一定チーム課題の解決ができたと考えています。
- 稼働を鑑みた issue の粒度やスクラムゴールの設定する。
- チームの平均ベロシティや消化可能な最大 issue のポイント数を数スプリントこなしながら見極める。
- バックエンドもキャッチアップできるようにフロントエンドメンバーをレビューにアサインしながら教育行う（必要に応じて他チームの助力を仰ぎながら）。
②業務委託メンバー中心でも自己組織化していく必要があった
当社は正社員メンバーには半期ごとに目標設定と評価があります。
ただし、業務委託メンバーの方には定期的な 1on1 は実施すれど目標設定と評価は実施していません。
当社は雇用形態の違いと半期に一度の目標設定の有無があるだけで、社員と業務委託メンバー隔てなくビジョンに向かって開発しているところが良いところだと自負しています。
ただ、どうしても中長期目線で開発課題にコミットしていただくためのチームの雰囲気や体制は意図して作っていく必要があると感じていました。
具体的には開発マネージャーおよびスクラムマスターとして下記振る舞いを行うことで少しずつですが自己組織化に向かってチームが動いてこれたのではないかと考えています。
- マネージャーとスクラムマスターを兼務するデメリットを理解し、チームで意思決定していくことを意識する。（最終的なケツ持ちするという覚悟は持ちつつ）。
- チームのナレッジを振り返りで共有し、issue 化したりドキュメント化したものを全社的にチームとして展開できるようにしていく。（まだまだこれからですが...。）。
- 他チームと関わっていただけるようアサインメントを調整する（詳細設計からお渡したり、意図的に他チームとのやりとりが発生するようにアサインを行う）。
③意思決定のレベルを個人からチーム視点に引き上げる必要があった
マネジメント活動は下記の 4 つに分類されるといろいろな本でこすり倒していわれています。
- 情報収集
- 意思決定
- ナッジング
- ロールモデル
その中でも特に課題が大きかったのは「意思決定」でした。
「現状でリリースする？しない？」や「仕様を変える？変えない？」など。
振り返ってみるとまだまだ粒度の小さい可愛い意思決定ばかりでしたが、最終的には「エイヤ」で決めるところは決めるというのがハードル高かったです。
最終的には「チームとしてどうしたいのか？」とチームで議論して決める機会を増やすことでチームとしての意思決定ができるようになっていきました。
（このあたりは 1on1 を通じて上長にうまくコーチングして誘導してもらえたと振り返ってみて感じているので、次は自分も活かしていきたいところです）。
もちろん最終的なチームの意思決定はマネージャーである自分がしますが、私一人が決めるというよりはチームで決めていくように半年間で徐々に自己組織化したチームに近付けたと考えています。
④開発の手を動かす時間がまとまって取れなくなった
純粋に MTG の時間が増えて、まとまった作業時間が取れなくなりました。
MTG や採用面談が増えるのはマネージャーの活動としては普通でしょう。
メンバーには会議で時間を細切れにしてほしくないので細切れになるのは自分だけでよいと思いながらある程度割り切って仕事をするようになりました。
とはいえ開発者としてもやっている手前手放したくない開発があったりしつつも、なかなか時間が取れず自分のところでスタックさせてしまう現象が発生していました。
この点「割り切ってお願いしちゃうところはしちゃう」と自分は自分のできる範囲の開発の粒度の issue を自分自身にアサインする、アサインの調節で解決しました。
とはいえ、「開発者としてこれやりたい！」という気持ちは出てきてしまって大きめの issue を取ってしまいがちな自分も出てきてしまします。
より「本質的な課題の解決のために今自分がやること」にリソースを使えるようによりアサインメントやチームの採用などにも取り組んでいかなければと感じています。
⑤目標を自ら決めて周りに語る必要にせまられた
自身のチームの目標の決定や周知もですし、採用やカジュアル面談の場でも中長期での目標を語る必要に迫られるケースが圧倒的に増えました。
採用でカジュアル面談に出ていると「中長期で事業の今後どう考えています？」などを聞かれる機会も増えたのでいやおうなしに考えなきゃという気持ちになりました。
最初は自身の担当するスクラムチームの名称を決めて担当ドメインを明確化するところから始まり、最終的には半年後次の半期〜 1 年の目標を決めるというところまで。
決めたらそれを自身のチームにたびたび語る場面も自然と増えていきました。
とはいえどうやったら一緒に楽しく仕事をしていけるのだろうか？この目標で本当に楽しく働いてもらえるだろうか？といったことに対しても自問する機会も増えました。
まだまだ道半ばですが、こればかりは場数をこなすしかないのかと思い、一定の諦めとともに引き続き慣れるように精進していこうと考えています。
まとめ
最後に半年間新米マネージャーとしてやってきてよかった点とこれからの課題についてまとめて終わります。
良かった点
- プロジェクトマネージャーとして安定した QCD を実現することは一定できた。
- ピープルマネジメントの中でもスクラムを通じた自己組織化のキッカケはつかむことができた。
- バックキャストで考えて定性目標を立て、チームを巻き込んでいく足がかりはつかめた。
総じてエンジニアリングマネージャーの全業務がすべからく満点ではないですが、なんとかやっていける最低ラインに立てたのではないかと感じています。
これからの課題
- 業務委託メンバーが中心のチームであったため、社員への「目標設定/評価」はこれから（本記事を書いている期から社員メンバーがチームに Join してくれました）。
- メンバーがより意欲をもってチャレンジしたくなる定性目標・定量目標の設定と日々のコーチング・メンタリング
- より本質的な課題解決のためにマネージャーとしての時間を使えるようにしていくためのアサインメントと引き続きの採用活動
まだまだ課題はありますが、開発をベースにしながら、人・事業・組織・教育などに関われるマネージャー職はとても楽しい仕事だと感じています。
本記事が少しでも「スタートアップのエンジニアリングマネージャーに興味がある」という人や「エンジニアリングマネージャーになっちゃったけどどうしよう！」という人の参考になれば幸いです。
採用情報
現在エンジニア募集しています！
▼ 採用ページ
▼ 選考をご希望の方はこちら（募集職種一覧）
▼ まずはカジュアル面談をご希望の方はこちら
募集中の職種についてご興味がある方は、お気軽にお申し込みください（CTO がお会いします）
Discussion