なにこれ
【Mentor Ver.】TechTrain Advent Calendar 2019 の9日目のエントリです。
前回は @fkske_pro さんの アウトプットスキルを加速させる越境学習のススメ でした。
目次
誰
はじめましての人ははじめまして。
はぜ という名前でインターネットをしています。スマートキャンプという、全然キャンプと関係のないWeb事業をしている会社で働いています。
TechTrainのメンターには同僚に誘われて、先月なったばかりです。よろしくおねがいします。
仕事をする上で気をつけていること
現在4社目なんですが、普通に働いていたり、転職をしたり、副業をしてみたりしていく中で、"これは意識してやろう"、と決めていることがいくつかあります。
それらがもしかしたら人のためになるかもなあ、と思ったのでその紹介をゆるくやっていくことにします。
意識してやろうとしていること
- 自己開示
- 正直であること、わからないことはわからないと言う
- 立場と視点を気にする
- ちょっとだけ無理をする
です。
1. 自己開示
入社した時、チームが変わったとき、そういったときに自己紹介は嫌というほどやると思いますが、それ以外でも積極的に自分のことを話すことを心掛けています。
自分がどういう考えで物事を決めているのか、考えているのか、仕事をやっている上でどこを気にかけたか、どこができなくて後悔したか、半年後どうなっていたいか...
1on1でマネージャには伝えても、チームメンバには伝えていなかったりしませんか。
どうしてやるのか
私は特にですが、隣で働いている人がどう考えて、どう思って仕事をしているのかが気になります。
また、一緒に作業をしている人が何を得意としていて、何が苦手かが気になります。
それを知っていることで、
「このタスクは自分よりこの人のほうが得意だから、一緒にやって教えてもらう」 とか、
「この作業はあの人があんまり好きじゃないって言っていた。自分は結構好きだから代わりにやってもらおう！」 とか、そういう動きができたりします。
それは相手のことを知らないとできません。自分のことを知ってもらい、適切な判断を取り合っていけたら良いなあと思ってやっています。
どうやるのか
やり方はいくらでもありますが、自分は可能な限り文章化するようにしています。
自社だとKibelaという情報共有ツールを使っており、そこに色々書きなぐっています。
入社した直後に自分の経歴とか会社でやりたいこと、今後どうなりたいか、仕事以外で何やっているか、趣味とかを書いた自己紹介を投稿したり、
こういうこと全社でやったほうが良くない？と思ったら提案する文章を書いたり、
よく聞かれることをまとめて書いたりしています。
※社内のあだ名文化により、 とってぃ と呼ばれています。まだ慣れません。
.
それとは別に、金曜の夜に週報を書いています。
週報を書くことでチームメンバに今自分がやっていることを共有したり、自分の頭の整理をしたり、タスクが溢れていないか確認したり、といったことが毎週できます。
あとちゃんと書いていると半期評価とかのタイミングでこれを読むだけで大体何してきたかがすぐわかって便利。おすすめです。
(あとは当然、対面でのコミュニケーションもたくさんします。)
2. 正直であること、わからないことはわからないと言う
そのまんまです。
どうしてやるのか
1.自己開示 と被るのですが、正しく人に自分の状況、知識を伝えないと誤解されて大変です。
自分ですぐ調べられる範囲であれば、調べればわかるから大丈夫、と伝えれば大丈夫だと思いますが、そうでない場合は自分でなんとかするしかなくなります。大変です。
どうやるのか
「初心者なので...」とかの前置きをせずに、「わからん！！！」と自信を持って言うと良いです。
むしろ先に「こことここがわからんから事前に教えてくれ、どっかに書いてあるなら文献をくれ」みたいな感じで言うと大体教えてくれます。
業界全体に薄く 自分で調べられないとエンジニアではない みたいな雰囲気がある気がしますが、3年ぐらい仕事をしていてもわからないことは無限にあるし、自分の触ったことのない技術はわからなくて当然です。
自分で数分調べてみて、あと10分かけてもわからなさそうなら軽く聞いたほうが良いと思います。仕事中は特に。
人に説明してもらうより自分でコードを読んだり調べて納得したほうが理解が深まりやすい(はず)なので、自分で調べてなんとかする力は並行して身につけていきましょう。
(自分は考え込んで時間を無にしがちなので、仕事中は意識してすぐ聞くようにしています...)
3. 立場と視点を気にする
いわゆる視座の話です。
(自分が今マネージャならメンバであるこの人にはこう動いてほしいな) みたいな考え方をしたり、
(自分がこう動いているけど、事業部全体で言うと今これやるよりこっちを進めたほうが良いんじゃないかな？提案してみるか) みたいな動き方をすることです。
どうしてやるのか
ざっくり言うと組織のパフォーマンスの最適化のためです。
状況によって "一メンバに徹したほうが良い" ときもあれば、 "チーム外のことまで手を広げたほうが良い" ときもあります。
また 開発者として働いていて、相手が何を求めているかを考えなければならないタイミングは多いです。
どうやるのか
一番良いのは経験してみることだと思います。
マネージャになってみる、チームリーダとして動いてみる、CSの仕事を手伝ってみる、などなど。
(個人的に参考にしている考え方です。)
難しければ当事者に話を聞いてみたり、ある程度想像で考えてみたり、という形になるかなと思います。
自分はよくPdMに1on1で 「先週はこういう目線でこう動いてみたんですけど、あなたから見てどうでしたか？」と聞いています。
4. デフォルトはちょっとだけ無理をする、疲れたらちょっとだけ手を抜く
どうしてやるのか
まだ開発者としてはまだまだ下っ端(だと思う)なこともあり、技術者としての成長速度はもっと上げたいと思っていて、
とはいえ無茶をしすぎて身体を壊したり精神的に疲労するのも嫌なので、適度に難しいことに挑戦しよう、という意識からです。
どうやるのか
定期的に自分の状態を振り返る運用をしています。
部屋の散らかり度合い、気持ちの浮き沈み、一人で酒を飲んだ量、実施したタスクの数や質、スケジュールの空き具合、など。
めっちゃバリバリ仕事ができていると思っていても実はこなしたタスク自体は小さかったり、一週間で部屋が異常に汚くなっていたり、妙に気分が落ちたりしたら次の週は意識して手を抜くようにしています。
体調が悪い(実際こういうときは大体悪い)と言って有給を唐突に入れて一日ゆっくりしてみたり、早めに帰って近場の温泉に行ったり、外食したりすると良いです。
どうしても無理をしないといけなくなる瞬間はあるっちゃあるんですが、一人一日休んだところで事業が死ぬようになることはそうないです。まあ役職がついたり経営者とか取締になってくるとそうも行かなくなるんでしょうが...
疲れてきたらチームに共有して、ちょっと来週はやる仕事減らすと思います、みたいなことを言ったりすると多少は気を使ってくれると思います。たぶん。
逆にチームメンバがつらいって言ってきたら助けてあげる ぐらいのことはやってあげると良いでしょう。徳を積むのも大事です。
最後に
そんなことを考えながら仕事をしています。(できていないときもたくさんあります。)
Engineerと言っても根本的には会社に属して業務に従事する以上はビジネスマンなので、コードを書く、ものを作るだけではうまく行かないことが多いです。
色んな人と協力しながらプロダクトを、サービスを作ることを楽しみつつ、仕事ができると良いですね。
これからソフトウェアエンジニアとなる、なったばかりの、あるいはまた別の誰かの参考になればと思います。
次回は @umikawat さんの 次世代のエンジニアを目指す人に伝えたいこと(IT業界を15年経験してみて) です。おたのしみに。
