かけだしピープルマネージャーとしての2021年振り返り
明けましておめでとうございます。
2021年を振り返ると、社会人経験の中でも比較的、未知分野の業務を行う年となりました。その中でもマネジメント業務に関しては試行錯誤しながらチャレンジを行う一年となったので、今後に活かせることを期待しつつ一年間の行動・結果・考え方の変化などを振り返っていこうと思います。
前提として、エンジニアのマネジメント = エンジニアリングマネジメントと想像する人は多いと思いますが、個人的には、エンジニアリングマネジメントという業務はその下位レイヤーにあるいくつかの役職をまとめたものだと考えています。
他記事からの引用ですが、以下のような分類になるイメージです。
・ピープルマネジメント ・テクノロジーマネジメント ・プロジェクトマネジメント ・プロダクトマネジメント
本記事ではピープルマネジメントの話に絞って書きます。各種マネジメント業務の定義については以下記事が非常に分かりやすく書かれていますので、そちらを参考にしてください。
ピープルマネジメントについてですが、ざっくり言うとチームビルディングや採用に関する業務です。その他、組織に関する良いところや課題などの意見を社員から収集し、組織体制を整えるための計画・実行などを行います。
実行したアクションと考察
社員の給料を上げるためには
マネージャーとして一番最初に行ったことは、目標の制定と、その目標を達成するためのタスクリスト作りです。
会社自体のフットワークが軽く、マネージャーとしての動き方が決まっている訳でもなかったので仕事はすべて自分で考えて実行する必要があったのですが、目標を決めなければ何をすべきか分かりません。そのため、第一に目標を決め、そこから何をすべきかを逆算していくことにしました。
品のない表現になりますが、会社員としての仕事を要素分解すると「いかに稼げるか」に尽きます。エンジニア単体で考えると、「いかに仕事を早く終わらせられるか / いかに難しい課題を解決できるか / いかに想像し難いアイデアを打ち出せるか」といったものになるでしょう。このあたりのサポートを行うのがエンジニアリングマネージャーの仕事だと思うのですが、ピープルマネージャーとしては「稼ぐための施策をいかにエンジニアが実行できているか」という事柄が重要になります。稼ぐためのビジネスプランは組織全体で考えるものですが、そのビジネスプランという名のレールを走り続けるモチベーションを維持し、レール上で止まってしまった人やレールから逸れた動きをしている人が出ないようにする、というのがピープルマネージャーの主な仕事だと考えています。
モチベーションについてはとりあえずお金がないとやってられんでしょうということで、私の2021年の目標は「社員全員の給料を上げる」ことに決めました。（結果としてこの目標は達成できませんでした。詳細は記事末に記します）
給料を上げるためには組織の経常利益を増やす必要があります。私が所属している部署では受託開発がメイン業務となるため、利益を上げるためには「開発人員の単価を上げる / 社員を増やす 」という手段が候補に挙がります。 （別件として仕事を受注し続けるというのも重要ですが、ありがたいことにそこは既に達成できており、開発リソースがないためお断りするという状態でした）
「開発人員の単価」を上げるという目標達成のため、まずは主に単価の低い新人エンジニアをフォローすることにしました。また、弊社の場合はクライアントに対してリード・提案をしていくオーナーシップも求められているので、そのあたりのプロジェクトマネジメントや顧客折衝のためのコミュニケーションなどについてもサポートしていく必要がありました。すでに新人よりも水準が高いエンジニアについては自分の得意な分野を伸ばしてもらうように伝え、フォローはテックリードに依頼しました。
「社員を増やす」という目標については会社のブランディング化が必要だと考えました。元々弊社ではリモート・フルフレックス可能というのが強みだったのですが、今となってはフルリモートは当たり前の時代です。フルリモート・フルフレックス以外の強みや魅力を打ち出さなければなりません。開発部の情報をより詳細に伝えるため、テックブログを通じた外部発信やコンパスでの勉強会開催を増やしていくことにしました。
毎週1on1を行うメリット
上記目標の達成についてサポートするため、毎週1on1を行うことにしました。
私がマネージャーになる前は、1on1は希望者のみに実施されていたのですが、「レール上で止まっている人 / レールから逸れている人」を迅速に見つけるために毎週定期的に行うことにしました。実際に行ってみて、自分の行動が成果を出せていないことに気づけない人は意外と多く、最短一週間で軌道修正できることは大きなメリットでした。また、課題に対してどういうアプローチが適切か答えが出ないような場合に、「とりあえずこの方法でやってみよう（上手くいかなかったとしても一週間後にまた考え直せば良い）」という感覚でカジュアルに行動を決められることも良かったです。
副作用的な話ですが、フルリモート勤務のため同じプロジェクトの人以外は話す機会がなかったものの、一週間に一回は「最近どう？」的雑談をする機会ができ、個々人の意見や問題を抽出するためのイベントとしても機能しました。ただし、本来1on1というものは強制的に行うべきものではないはずです。その人自身が課題を持っていない場合に1on1をしてもただ言われたことをやるだけの進捗確認イベントになってしまいます。今回の場合、課題を見つける力の弱い新人エンジニアのみ定期的に1on1を行い、その他エンジニアについては日常的な雑談で解消していました。このあたりは組織の状況に応じて1on1に何を期待するのか明確にした上で、フレキシブルに実施するのが良いかと思います。
ただ、日が経つにつれ私自身の業務負担がきつくなったため、現状、1on1は隔週で行っています。
互いにフォローし合えるためのチームビルディング
業務負担がきついという流れの中で、各種フォローを社員同士で行ってもらえればより良いな、という考えが生まれました。「誰々さんよりも誰々さんの方が話しやすい」という状況は誰にでも発生しうるし、私よりも他の人の方が話しやすいのであれば自発的に他の人同士で相談し合ってもらった方がより良い成果につながります。さらに言うと気の合う人同士の相乗効果で勉強会イベントの発生や新規プロダクト提案などがされるようになれば理想的です。
ただ、フルリモートということもあり、そもそも話したことがないという社員の組み合わせがほとんどでした。会社で利用しているDiscordサーバ上には「雑談」というルームがあり、時折そこで雑談をしたりして一服するのですが、雑談ルームに入ってくる人はほぼ決まっています。雑談ルームに入らない人同士で話す機会は基本皆無で、「自発的に相談し合える人」という存在も見つけづらくなっていました。
そんな中、同種の課題を持っていたであろう上層部から「業務中でも交流のためならゲームして良い（むしろ強制でも可）」とお達しを受け、月一で部署内でのオンラインゲームイベントを開催することになりました。ただ、参加者の多くは雑談ルームに入ってくる人で、ゲーム選びも参加者のプレイヤースキルに合わせる必要がありました。コミュニケーションが発生しつつ、全員プレイ可能なハードウェアを所持しており、操作スキルが重要ではなく、無料でプレイできるゲームというものがほとんど見つけられませんでした。
毎月ゲームを探しつつイベントを開催していましたが、条件を満たすものはAmong Usというゲームのみとなりました。
上記ゲームは、ある程度人数がいないと面白さを発揮できないということもあり、定常的に参加者を集めることが難しく、スケジュール調整のコストも相まって運営を中止することにしました。イベントとしては当初の目的は果たせませんでしたが、他部署との交流機会となり、イベントを続けることの難しさも学ぶことができたため、個人的には良いリターンがあったと思います。
イベント運営側としては初めに「どうすればみんな参加してくれるか」を考え続けていましたが、そもそも参加対象となる人たちがイベントに意味を見出していなければ意味がありません。どれだけ時間を使って試行錯誤しても参加者が増えなければ運営側も疲弊するだけです。誰も得をしません。実のところ、興味のない人にとって、興味のないイベントはどうやっても興味を持てないのです。
基本的にこういったイベントについては「やりたいことをやり続ける」のが一番だと感じました。参加者が来ることを期待せず、誰かが来ればラッキー程度の考えで良いと思います。そうやって会社の中で勝手にやりたいことをやっていれば、「自分も何かやってみよう」という空気感が醸成され、各々が自発的に動き出し勉強会や趣味の部活動的なものが発足し始めることを期待しましょう。
上記反省を活かし、今は毎月個人開発で作ったアプリ（その他なんでも良い）を見せ合うイベントを毎月開催しています。自分としてはそのイベントに向けてネタを考えたりアプリを作ったりするのは楽しいですし、誰も来なくてもインターネット上に公開すれば誰かしら見てくれるので損はないなと思っています。他の人が参加してくれれば、追えていない技術トレンドや開発の苦労話などが聞けてなお面白いです。ありがたいことに、毎回誰かしら来てくれるのでイベント自体は1年間継続することができました。そういったアクションを他の人が見て、「自分も何かやるか」と思うきっかけにしてもらうことが重要だと思います。
続かないテックブログの対策
「社員を増やす」という目標に対して、テックブログが続かないという問題を解消したいとも考えていました。
そこで、会社のテックブログに個人ブログが自動で載せられるようにするプロジェクトを進めることにしました。
会社のテックブログとなると、記事投稿に対するの心理的ハードルが上がるものと思われます。また、エンジニアにおいて自分の技術記事は自分で開発したプロダクトに似た感情を持っている人も少なくないのではないでしょうか。個人的に、技術記事は自分の資産なので権利は手元においておきたいです。
この問題に対する対策が以下記事で書かれていました。 zenn.dev
上記記事を参考に個々人のアウトプットを自動的にテックブログへ集約する仕組みづくりを構築したいと考えていました。
ただ、これについては会社の経営方針変更により宙ぶらりんとなってしまっています。時間ができればやりたかった施策です。
2022年の抱負
やってきたことを色々と書いてきましたが、結果的には「社員全員の給料を上げる」という目標は達成できませんでした。
理由としては、採用にコミットできず結果につながらなかったことが挙げられます。
カジュアル面接にあたって、会社の情報を魅力的に伝える必要があるのですが、自分自身会社に対して「嫌いではないが好きでもない」という気持ちがあり、カジュアル面接に来てくださった方の「この会社に入りたい」という気持ちを刺激することができませんでした。採用に携わる業務を行うのであれば、会社を好きであるという気持ちは必須ではありませんが、非常に強い説得力が得られます。また、人間的に魅力があるかというとそうでもないため、「この人と一緒の会社で働きたい」という経路パターンも確保できていなかったと反省しています。
顧みて、採用業務にあたって自分にとって不足しているのは「人間もしくはエンジニアとしての魅力や、会社に対する強いこだわり」だという結論に至りました。そして自分の得意/苦手分野・趣味レベルで集中できる分野・キャリアプランのために伸ばすべき分野を分析した結果、今の会社にはマッチしていないと考え会社を辞めることにしました。マネージャーとして仕事をしていく上で何かしらの突出した能力もしくは実績がないとこの先辛いと考え、個人的に伸ばしたいスキルも今の会社では必要とされていなかったためです。これはネガティブな決断ではなく、自分の能力分析ができたことと次にやるべきことを達成するためのプラン変更と考え、意味のある成果だと感じています。
そもそもマネージャーではなくクリエイティブな領域の仕事がしたいという未練があったので、今年は心機一転でフロント・デザイン・3Dなどの学習に時間を割く予定です。一方で、チーム成果を最大化することのやりがいや難しさも経験できたため、PMとしての知識やアイデアは引き続きキャッチアップしていきます。
本記事で書いたのは個人的な経験談程度のものですが、今年からマネジメント業務を始める方の参考になれば幸いです。
それでは今年もよろしくお願いいたします。
参考文献
findy-code.io
メッセージを伝え続ける重要性を参考にし、「会社の目指す方向性」や「して欲しいこと」を常に1on1で伝えるようにした
tune.hatenadiary.jp
1on1や採用に関する活動を参考にし、業務の実行計画を整えた
scrumcommunity.pbworks.com
スクラムアンチパターンまとめ。コミュニケーションや対話を適切に行うための参考
medium.com
社員にとってのテックブログの価値観とモチベーションに関する考え方を参考
www.diamond.co.jp
組織課題を解決するために1on1は適しているか、また効果を最大化するための土台作りの参考
www.njg.co.jp
こちらから指示するのではなく、自分自身で課題を見つけ動けるようになってもらうための手法として参考
