101
81

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

新卒未経験からマネージャーになるまで意識してきたこと

Last updated at Posted at 2023-11-04

はじめに

私は2016年に新卒未経験で入社し、今年の1月にマネージャーに就任しました。
私の所属している部署では、新任マネージャーは久しぶりでした。
きっかけこそ、前任マネージャーの退職に伴うものが大きかったですが、今は私の所属部署でも組織改編によって環境が変わり、マネージャーの空きポジションが多くあります。

マネージャーになってみて、もっと若いメンバーがマネージャーになって一緒に働いていきたいと思ったのと(シンプルに仲間が欲しかった)、空きポジションがある今、後輩メンバーには上を目指してほしいと思ったので、経験談を公開することで1つのヒントになるといいなと思い、本記事を書くことにしました。

自分にとって普通にやっていたことばかり書いていますが、案外できていない人が多く、大きなことをやらなくても当たり前のことをちゃんとやっていたらマネージャーになれたので、マネージャーを目指す人だけでなく、自分が思っているように良い評価を受けることができなくて悩んでいる人にとっても参考になれば幸いです。

目次

  1. ざっくり経歴
  2. 右も左も分からないときに意識すること
    2.1 ミーティングで出てくる話が全然分からないとき
    2.2 開発における知識がないとき
  3. 評価してもらえるように意識すること
    3.1 自分の評価をする人をよく観察する
    3.2 自分がやったことは全てアピールポイントとして書き出す
    3.3 他の人と比べて自分が得意なことを見つけてやってみる
    3.4 機会損失しない
  4. おわりに

ざっくり経歴

大学(数学科)卒業後、2016年新卒未経験入社
新卒研修後、タレントマネジメント系の機能開発チームに配属され、2018年夏ごろまで同じチームで働いていました。
その後異動し、現在に至るまで人事帳票を作成する機能の保守開発として働いています。

関わる製品は変わりましたが、内部の機能は似通っていることと、大きな異動は1回だけだったので、周りのメンバーと比べると1つの場所でしっかり力をつけられるように育てられたと思います。
最近分かったことですが、私をマネージャーにしようとしてくれた元上司が、私の性格を見た上であまり異動させないようにしてくれていたようです。
記載している内容は自分がどうするか?に重きをおいていますが、コミュニケーションをとる上で自分のことも深く知ってもらえるので、今では副次効果があったんだなあと思ったりします。

右も左も分からないときに意識すること

まとめると以下のようなことを意識していました。

  • 周囲の人のことをよく観察する
  • 分からないことを分からないまま放置しない
  • 見たり聞いたりすることは分からなくてもメモに残す

以下具体的な場面とともに記載します。

ミーティングで出てくる話が全然分からないとき

  • なるべく単語を聞き取りメモする
  • ミーティング終了後に調べる
  • 調べても分からないものは聞く
  • 分からないものを放置しない

先輩メンバーたちは当たり前に知っているかのように略語を利用したり、社内ワードを利用しながら結構早口で(実際には早口でなくても早口に聞こえると思います)話します。
ミーティングは自分以外の人が分かっている内容のことが多いと思います。そのような場合、1つ1つ質問するのはかなり勇気が必要ですよね。

私の場合、ミーティングの内容が全然分からないときは、できるだけ多くの言葉を聞き取り、メモをしています。
今はオンラインミーティングしかないのですが、タイピングの音で人の声が遮られることがあるので、私は必ず手元の紙に文字を書きなぐっています。
タイピングが速く、タイピングしながらでも会話を聞き取れるのであれば、PCでメモを取った方が後々楽だと思います。

ミーティング終了後、メモを必ず見返し、私は紙に書いているのでテキストにおこす作業をします。
その作業の途中で分からない単語があれば、以下の順序で自分の理解を深めます。

  • 社内のWikiなどの社内用のページで検索する
  • 見つからない場合はGoogleで一般的なワードとして検索する
  • 上記2つで理解できないワードは周りに聞く

同じ単語でも社内ワードと一般的な使い方と異なる場合があるのと、知識が浅いうちは一般的なサイトで検索して得られる情報の内容が分からないことも多いので、まずは社内のサイトを徘徊するのが良いです。

ここで大切なことは以下の二点です。

  • 分かったふりをするのはミーティング中だけにする
  • 次のミーティングまでに前回ミーティングでの不明点はゼロにする

とにかく分からないことをそのままで放置しないようにしてきました。
ミーティングで一度話された内容は、言った側としては伝えたもので、次回以降は分かっている提で話がされます。
分からなかったものを分かったふりしてそのまま放置すると、「なんであのとき聞かなかったの?」と注意されます。

怒られるのが好きな人はあまりいないと思いますが、私は極端に怒られたり注意されることが苦手なので、自分の苦手なことを回避するために、分からないことはそのときに正直に分からなかったので質問したいです、という風にしてきました。

ミーティング中は何もかも分からない感じでいるのはちょっと格好悪いので、分かってる風に過ごしています(が、大体の場合はバレバレです)。

開発における知識がないとき

  • 基本は自力で頑張ってみる
  • 自力で頑張って手が止まったら相談にいくまでの時間を決める
  • 業務終了時には1日にやったことをなるべく細かく報告する

最初は製品知識も開発スキルもなかったので、何から手を付けたらいいか分からない状態によくなっていました。
一番最初の開発こそメンターの先輩に聞きながら手取り足取りやっていましたが、ある程度慣れてきたら付きっきりで聞ける状態ではなくなるので、ここではそういうときにどのようにやってきたかを記載します。

さすがに何でもかんでも聞きまくるのはNGだと思っています。
というより、聞きまくるとこの人は自分で考えられないんだなというレッテルが貼られるのでよろしくないです。

基本は自分で調べて、試行錯誤して、というのを繰り返しますが、最初のころは1日に1回は必ず相談するようにしていました。
1日に1回(2回以上でも良いです)など、区切りがついたらではなく、タイミングを決めてしまうのが良かったです。
今でこそ相談を受ける側になって思いますが、新人は質問や相談にどんどん行くべきです。
先輩に遠慮をしているだけなのであればそれはすぐにやめるべきで、なぜなら先輩は忙しいときは「忙しいからあとにして」と答えてくれるからです。
相談に持っていくことで自分のやったことを整理する癖がつけられ、質問するまでいけなくてもやったことが報告できるようになりますし、最初に癖をつけていくと、相談のタイミングが遅れた日は「今日は大丈夫?」と先輩から聞かれるようになります。
区切りがついたら、というのを新人はやりがちですが、分からないことだらけの状態のときは、その区切り自体が間違っていることも多いです。
毎日1回は先輩に話しにいけるようになると、道が間違っていることにもすぐ気づくことができます。

この相談者を見つけるために周囲の観察は大事です。
それぞれ得意なこと、性格が異なるので、自分が相談しやすい人をいかに早く作れるかが重要です。

またチームで働いている場合には、相談をしにいく先輩以外のメンバーがいると思います。
そういう人たちにも自分がやっていることが分かるように、業務終了時のやったことの報告・悩んでいることなどはしっかりテキストで書くようにするのも意識していました。
ミーティングではなかなか発言しづらくても、テキストで発信するのはハードルが低いのと、エンジニアはちゃんとテキスト報告も読んでくれているはずです。
報告に遠慮は無用なので、どんどん書くことの発言を増やしましょう。

評価してもらえるように意識すること

自分を評価するのはあくまでも人間です。
評価する人に自分のやったことを正しく伝えることが一番のポイントだと私は思っています。

  • 自分の評価をする人をよく観察する
  • 自分がやったことは全てアピールポイントとして書き出す
  • 他の人と比べて自分が得意なことを見つけてやってみる

自分の評価をする人をよく観察する

私は元々人間観察をするのが好きで、仕事においてその好きがうまくいったのを感じたので書いてみます。

弊社の場合は自分のことを評価する人を自分で選ぶことができます。
とはいえ、最初はチームメンバーとしか仕事をしないことが多いので、上司含めたチームメンバーに依頼します。

私の場合はチームメンバーを観察したうえで、直属の上司に評価されることが一番の近道だと判断しました。
チーム内で最も力のある人を選ぶのが良いと思います。
マネージャーがマネジメント専門の場合は、チーム内で開発力が一番ある人を選ぶと良さそうです。

チーム内の力関係の把握は大事です。
相談しやすい先輩があまり力を持っていない場合、その先輩には評価されてもほかの人にはあまり評価されなかったりすることがあるためです。

1年目の頃は上司(マネージャー)がどのようなことを考えているのか、私たちに何を期待しているのか、会社についてどのような考えがあるのか、などなど普段の業務のこと以外のことをランチに行くことで聞いていました。
約3年くらいは時間が合えばランチに行く、というのをやっていました。
1年目こそアドバイスを求めることが多かったですが、2年目以降は自分の気持ちも話せるようになったり、思いつきアイデアを話しあってみたりして、そこから自分主体でチーム内の改善をできるようになったりしていきました。

私の場合はマネージャーがマネジメントをあまり好んでいないように思えたのと、プレイヤーとして働き続けたいという思いを受け取っていたので、私がやれるチームに関する仕事を取っていくという風にマネージャーの仕事を楽にしようとしていました。

自分がやったことは全てアピールポイントとして書き出す

弊社は評価者を指名する際に、やったことを自由記入する欄が設けられています。
自分を評価してくれる人は他の人(しかも大量)のことも評価しています。
1人1人を全て平等に見ることができているか、半年間のやったことを覚えていられるか、を考えると、自分自身でも半年やったことを書くのに振り返らないといけないのに絶対無理だなと思いました。

そこで、自由記入欄には必ず半年のやったことを全て記載するようにしています。
開発チケットだけではなく、ちょっとしたタスクでもすべて書くようにしていました。

ここで大事なのは、箇条書きでやったことを書くことではなく、各仕事においてできるようになったことや、うまくいかなかったこと、どのように克服したか、などを丁寧に書くことだと思っています。
あくまでも評価のための文章の作成ですが、私は自分自身の振り返りと、自分を褒めるためにも今でも自由記入欄はしっかり書くようにしています。

弊社でいうと、評価観点が開示されているので、観点に応じて各やったことを記載し、評価者が評価するときに読みやすいような記載にする工夫をしたりしています。

他の人と比べて自分が得意なことを見つけてやってみる

私の場合は開発はそこまで得意ではないのですが、一度聞いたことを忘れない、とか、得た知識をドキュメントにおこすことや、社会人として当たり前の期限を守ることなどが苦ではない、というのが配属直後くらいに見えてきました。
これは周囲の観察をすることで分かったのだと思います。

開発者として評価されるために、開発だけで評価を得ようとするのは結構難しいと思います。
開発が得意だとしても、レビューでどのように説明するか、とか、レビューの指摘を漏らさないようにするとか、必要な力は開発力だけではないからです。

私は開発自体が自分的には得意ではない代わりに、コミュニケーション面というか、上述のようなレビューの練習や指摘をまとめたりとか、そういうのは得意だったので、自分以外のメンバーのレビューを事前に確認するようにして、上司のレビューをより意味のあるものにしていました。

全社員向けの教育コンテンツ受けましょう、みたいな内容のものが来たときは、自分以外のメンバーに積極的にリマインドしたり、とか、ある意味お節介的な役割を担ってきました。

上司を少しでも楽にするためにやっていたのですが、内容は自分にとっては苦ではなくむしろ得意で、得意なことをやるようにするだけでチームメンバーが楽に働けるような環境作りをできて(と思う)感謝されたので、小さなことでも周りより自分は得意かもしれないと思うことを見つけられるといいと思います。

やっぱり、周りの人と同じように働いているだけでは一定より上の評価は得づらいので、上を目指すのであれば、+αをどのように見つけて実践するかが大事に思います。
もちろん自分ひとりで見つけられない場合は相談してみましょう。

機会損失しない

上司から「こんな仕事があるんだけどやってみない?」と言われたとき、絶対にNOと言わないようにしてきました(今でも言わないです)。
直接自分に提案される場合、提案してくれる人には必ず思惑がありますし、提案するまでに誰に提案するか検討を終えています。
その上で提案してくれている仕事を、今忙しいからという理由で断るのは勿体ないです。

とはいえ、全部YESで回答していると、手持ちの仕事が溢れます。
やりたいという意思表示をした上で、自分の手持ちの仕事と優先順位がどうなるか、期日の調整ができるかを上司と相談しましょう。
中にはどうしてもやりたくない仕事があるのかもしれませんが、明確な理由がないのであればYESで回答する方がいいと思います。

実際、提案されてやってみた仕事は自分にとっては適切な難度のもの(頑張ればできる)が多く、各仕事で得られた人とのつながりや知識、やったという実績のおかげで、確実に良い評価を受けることができました。

おわりに

私が一貫してやってきたことは全て、「どうすればはやく上に上がっていけるか?」をもとにしたことです。
こうなりたい、という目標ではなく、とりあえず評価されたい、XXをできるようになりたい、でも最初は良いと思います。
1つ1つの仕事を振り返ってみると、どのときもがむしゃらにやっていましたし、時間で解決してしまったものも多くあります。
楽をして評価されることは絶対にないですが、少し工夫するだけで、自分のやってきたことを正当に評価してもらえるようになります。
本記事を読んでくださった方が一人でもその工夫点を見つけるきっかけになれば幸いです。

101
81
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
101
81

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?