1年目エンジニアがバリューを出すためにした工夫、結果が出たモノのみ具体的にまとめてみる。

はじめに

私事ながら....
今年・2022年3月でフロントエンドエンジニア2年目を迎えました

技術力がまだまだ足りなく、現在進行形で奮闘中ですが
この１年間で、技術がない中でも自分のバリューを発揮するために工夫して、これは結果が出たな、という取組をまとめてみたいと思います！！

すぐに実践できるよう具体的に書いていますので、よければチラ見していってください。

• ひよっこエンジニア仲間で何か出来ることがないか悩んでいる方(わたしだけ？🐥)や
• これからエンジニアになるので策を練っている方

などなどの方に１つでも習得のある記事になれば幸いです。

1. 技術力を少しでも上げるために

(1) あたり前田のインプット

まずは、いやそリャそうだろと言われてしまいそうですがインプットをすることです。

先輩エンジニアとの会話が理解できるようになるところから始まり、良いコードの書き方が学べたり、自分の作っているアプリがどう動いているかの仕組みを理解した上でコードを考えれるようになったり、の役に立ちました。

これまでに私が読んで、もっと早く読んどけば読みたかった...と思った本を紹介 したいと思います📙

リーダブルコード

言わずもがな、リーダブルコード(著：Dustin Boswell, Trevor Foucher)
先輩エンジニアにレビューで指摘されまくっていたのに対して、
これを読んで、「良いコード」を初めて"自分で"考えて書けるようになったのを覚えています。

ひよっこでもすぐに試せることが多く書いてあり、とても役に立つ本だと思います。

Webを支える技術

Webを支える技術（著：山本 陽平)
Webの仕組みを理解して、自分がフロントでどうデータを受け取っているのか、それをどう画面に表示しているのかの仕組みを理解するのに役に立ちました。

それまでは「天からデータが降ってくるな〜😀」と思いながら実装していたり(ダメです)、「Restってよくいうけど結局なんなんだろう〜」と思っていたのが解決された本でした。自分が書いているものがどう動いているのか、どうデータを受渡しているのか考慮しながら開発することが時にできるようになりました。

教養としてのコンピューターサイエンス講義

教養としてのコンピューターサイエンス講義 今こそ知っておくべき「デジタル世界」の基礎知識 (著：カーニハン,ブライアン)
Webを支える技術でウェブの仕組みを理解できるのに対して、こちらでは「コンピューターの仕組みから理解する」のに役に立ちました。

自分が書いたコードが画面に表示されるまで、コンピューターが何をしているのか、コンピューターがどうやって動いているのか、一連の仕組みが理解できる本でした。
セキュリティについての知識もざっと学べますし、文章も読み易く、エンジニアになりたての頃に読んで根本理解しておきたかったな〜と思わされた本でした。

HTML解体新書

HTML解体新書(著: 太田 良典, 中村 直樹)
こちらは最近出たばかりの本で、私自身もまだ読み途中なのですが
自分が今まで疑問に思っていた細かいけど大事な点が解き明かされる本だと感じました。

例えば、h1で囲うべき見出しをpタグで書くのはどうなのか。こういったよくある細かいミスだけどフロントエンドとして知っておくべきことが丁寧に説明されており、じゃあそれをなぜ気をつけるべきなのかまで解明される本でした。

以上がこの１年で読んでよかった！と思った本です📙

(2) ガンガン質問ベースレビュー

質問ベースのレビューはかなり勉強になったなぁと思います。

質問ベースレビューとは、GitHubなどで上がったPRで、この書き方はどういうことだろう？と疑問に思ったらどんどん質問をしていくことです。

私の場合は、１日のうちに15分くらいこの時間を取り入れ、自分のアサインされていないPRを眺めて、この書き方はなんだろう？なぜここはこうしたんだろう？などと疑問に思ったことをレビューコメントに残しています。
こうすることで、自分の範囲を超えてより良い実装を学んでいけました。

ちなみに、ひよっこエンジニアとしてレビューコメントを入れるのは大変恐縮だと感じる場合もあると思うので、
私の場合は
レビュー外からすみません🙏自分の勉強としてPRを見ていて、気になったので質問させてください🙏
などの一言を添えてコメントさせていただいています。今までは全員が快くコメントに返してくださってます！（ありがたい...😭)

さらにちなみに、この方法はアピールにも繋がるのでおすすめです。自分では特に意識はしてませんでしたが、外に向けてやっていくことなので、多くの人の目に留まっていたようで、プラスの声を貰うことが多々ありました。勉強しながらアピールしたい方にはおすすめの勉強法です！🧚‍♂️

(3) 自問自答実装

3つ目は、自問自答しながら実装することです。
「なぜこれを書くのか」「なぜここに置くのか」を自分に説明してから実装をしようということです。

私はコードの責務を考えるのが特に苦手なのですが
先輩エンジニアアドバイスを貰い、「なぜここにこれを置くのか」を言えるようにしてから実装するようにしました。そうすることで、実装する前に「どこに」「何を」置くべきかの責務を意識的に考えられるようになりました。

自分なりの考えで大丈夫です。自分なりに考えてから書くことで、まず責務を考える癖がつき、それを繰り返していくことでどう責務を考えていくかも学んでいけます。

2. 技術がないなりにできる工夫　 スピード編

次は、技術力を伸ばすための工夫ではなく
技術力以外の面でバリューを出すためにしてきて結果が出た工夫を紹介します👧🏻

まず、スピードを上げるための工夫です🚄

(1) 必殺事前相談 で手戻りさせない

技術がない中の実装では、あーでもないこーでもないと時間をかけて実装して、頑張ってPRをあげてその結果、レビューで「設計からおかしいです」となり、イチからやり直すことが私は多々ありました。🥲🥲🥲

せっかく頑張ったのに勿体無いですし、事業も遅れてしまうのでどうにかしたい...それを防ぐべく実践しているのが事前相談です。
実装で自信がなかったら、実装前に先輩エンジニアに先に実装の方向性を確認しています。特に設計が間違っているときはイチから直さなくていけなくなるので、設計に関することは少しでも不安があれば事前に方向性だけ相談しています。

少し手間だったり、相手の時間も取ってしまいますが、レビューをもらってイチからやり直すよりはチーム全体で効率が良いはずです。

(2) 15分シンキング、1リサーチ、ハイ聞く　の法則

法則なのに全然語呂が良くないな？というのはさておき、
(1)と少し似ていますが、沼にハマって永遠に１人で考え続けて時間を無駄にすることのないようにこれを意識しています。

実装で詰まった時に、
まずは15分自分で考えます。コードを見返したりログを追ってみたり。その15分の中で、自分で考えるだけでなく、１度はググります。そしてその15分の中で解決できなかったら、迷わず先輩に質問です！

こちらも相手の時間をもらうので申し訳ないと感じますが、事業の全体効率的には聞いてしまう方がよっぽど良いはずです。一人で無駄に沼にハマって、時間を無駄にすることだけは避けるようにしています。

ちなみに15分ルールは、Googleの機械学習研究チームでも採用されているようです。

(3) 未知順で進める

いくつかタスクがある時は、実装方法や工数が未知なものほど先に取り組むようにしています。
こちらはエンジニアリング組織論への招待でも説明されています。

何かに取り組む時、ついつい
「どうやるか、どのくらいで終わるか」が明確なものを先に片付けて、未知なものは後回しにしてしまいガチです。。。

が、未知なものほどどのくらい時間がかかるのかわかりません。時間がどのくらいかかるか分からないものほど先に終わらせてしまって、予想の付くものを後に残しておくことで、全体の工数が読み易くなると考え、この方法を意識しています。

(4) 実装メモを残す

PRに、なぜこう実装したのかのメモを残すことです。
後から修正が必要になった時などに、「あれ、、、なんでこうやって書いたんだっけ、、、」となり、
記憶を辿って、PR見返して、コードを上から追って...と時間をかけて自分を追うことがありますが、その二度手間な時間を防ぐためにやっています。

自分が後から疑問に思いそうなことをメモに書いておくと良いです！

3. 技術がないなりにできる工夫　 自分を活かす編

今度は、自分だからこそできることを実践していくための工夫です🧚‍♂️

(1) そもそも、活かす強み・防ぐ弱みを知る

専門テストを受ける

自分を活かすにも、まず活かせる自分を知る必要がありました😀👍
ということで、私の場合はストレングスファインダーを受けて自分の強み、弱みを明確にしました。
ストレングスファインダーは、自分を表す34の特性が示され、どの考えが強い/弱いのか、同じ特徴でもその人の特性にカスタマイズされており、その人だけの強み・弱みを教えてくれるのでおすすめです。ただし有料なので、もう少し気軽に始めたい方には16personalitiesもおすすめです。

自分の感情を振り返る

自分の思考の癖を知るために、ある行動から次の行動に移るときに「自分がどう感じているか、またそれはなぜか」を振り返ることもしました。
これによって、自分がどのような仕事を楽しいと感じているのか、どのような時にストレスを感じているのか、またその時にどのような行動をとってしまうのか、などの自分の思考・行動の癖がわかります。

自分の思考や行動を振り返る方法は他にもあり、行動探求という本で紹介されているので気になった方は見てみてください。

この感情の振り返りでは、自分の思い込みやどういう時にそれが出るのかが分かるので
普段人と話しているときに余計なことをするのを防ぐのにも繋がり、仕事だけにとどまらず自分の人生で役に立っています。

(2) チャンスの時は迷わず出す、ピンチの時はしっかり抑える

(1)で強み、弱みがわかったのでこれをどう活かしたかを書いてみます！

まず、強みは「チャンスの時に迷わず出す」 にようにしています。
例えば、私の強みの１つに「ポジティブ」があります🌟イエイ これが「自分の強み」だと認識しているので、今までなんとなくランダムで出ていたポジティブさを、自ら意識して出しに行けるようになったり、「あ、今出すべきかな...」と迷った時も「これが自分の秀でている面で、自分の役目だ」と考え、強みを"活かせる"ようになりました。

自分で意識して活かしていくことで、周りから「場の空気が良くなった」などの声をいただき、結果が出ているのではないかと感じています。

次に、弱みは「しっかり抑える」 です。
例えば、私の弱みの１つに「完璧主義」があります。この思考癖によって、実装で迷ってもなかなか相談しない、それ故に開発が遅れてしまうことがありました。1時間毎の振り返りでこの思考癖に気がつき、開発の遅れを防ぐべく、WIPでもPRを出すようにしたり、自分が思っているよりも早めに相談するように意識するようになりました(上記で触れた事前相談などもその１つです)。

絶対に誰にでも弱みはありますが、パフォーマンスに極力影響が出ないように、弱みを理解してそれを防ぐ行動が取れるようになりました。

(3) 「分からない」を担う

ひよっこエンジニアとして 「私は皆の分からない担当だ😤！！！」 と考えるようにしています。笑

何かの説明があった時に、「分からないけど、聞きずらいな、、、」ということが多くあります。こういう時に自分が率先して質問する役になるのです。

説明がある時って、大抵の人が本当は理解してないと思います。(私だけ？🥲）
そこで、ひよっこエンジニアで分からないことが許されている自分こそ、質問を率先してすることで、同じ疑問を持っていた人への回答を提示したり、質問をしやすい環境を作るのです。

恥ずかしいな....、今言いづらいな....、と思うこともありますが、
あくまで「分からない役を担っているだけ」と考えると、私の場合は恥を捨てて聞きやすくなります！

自分のためでもあり、周りのためになることでもあり、意識していることの１つです。

(4) Don't take it as it is

急な英語。フレーズに困ったことが伺えますね。🙋🏻‍♀️🙋🏻‍♀️🙋🏻‍♀️

4つ目に工夫していることは、そのタスクを「そのまま受け取らない」ことです。

例えば、デザインをもらったときにそれをそのまま実装することが私の任務、と思わないこと。実際に実装してみたら、こっちの動線の方がわかりやすそうだな？とか、アニメーションつけれそうだな？とか、もらった仕様が全てではなく何か付け足せるものがないかを意識して開発しています。

もう少し具体的には、「そのまま受け取らない」を実践するために、開発したらユーザーの動線でその挙動を一通り確認するようにしています。
そしてそこで気づいたことを、重くとらえず、「こっちもありかなと思いました〜」と軽く相談してみてます。「提案」と聞くと構えてしまいますが、この雑談ベースで自分の考えを伝えるのが私的にはやりやすいです。

その結果、実際に案が通り、微々たるものですがより良いプロダクトに繋げられたことがあるので、今後ももう少し工夫していきたい取り組みです...🔥

(5) 仕事作り屋さんになる

自分で仕事を作り出す意識をするということです😅🙏🙏
これはそこまでまだ実践しきれてないものの、実行できた時に周りからの評価が高く、バリューを発揮するために今後頑張っていきたい、と思っているものの１つです。

今の環境に違和感を感じることはないか、もっとこうあればいいな〜と思うことはないか、日々の違和感をタスクにしてしまうのです。上からタスクが降ってきたわけじゃない課題に対して、自分で動いてみるのです。

「課題」と聞いて難しく考えすぎず、「もっとこうなればいいな〜」くらいを考えるようにしています。

課題には感じているけど、「いつか解決するっしょ〜」となぁなぁにしている時には
昔先輩社員からもらった言葉ですが 「自分が思っている悩みは、自分が一番ペインを感じている」 という言葉を頭に入れ、自分じゃなきゃ"この課題"は解決できないと思って自分のお尻を叩いています👵🏻🍳

後は、周りを巻き込むようにできたら成功率が高まるな、と感じています。
自分一人ではめんどくなったり、案も出ないので🥲、
同じような考えの人と一緒にやる、1on1で相談してみる、など他の人の手を借りることで取り組みやすくなるな、と感じています。

4.　課題を知る

(1) 振り返りタイム 1パーweek

1on1や、チーム定例などで１週間を振り返る時間があるのですが、自分の課題はここで大体出て、予防策を打てるようになるので、これがなかったら恐ろしいな...と思います。

１週間に１回の振り返りタイムはこれからも常にしていきたいなと思います。

(2) レギュラーFB

定期的にフィードバック(FB)をもらうことです。

自分の思う課題についてアドバイスをもらうだけでなく、
先輩社員から見て自分は今どこを足すべきなのか、逆に良いところはどこか、悪いところ良いところの両方をFBとしてもらいます。
自分より上の視座を持つ人から見た意見をもらうことで、自分だけの反省で出てこない、自分の幅を超えた視点から自分を振り返ることができます。

ちょっと最近できていなかったのですが、過去には自分では気づいていない技術課題とそのアプローチ法がわかったり、自分の思考癖を教えてもらったり、かなり効果があったので、反省してまた再開させたいと思う取り組みです。
(リーダー、してないよね？とか思わないで。）

5.　チームでバリューを出す

(1) 自分の強みのチャンス2

3-(2)と同じです。チームでは自分の強みをだすチャンスがたくさんです。自分の強みを知って、それを意識的にどんどん出していくことを意識しています。

(2) 「ニッコリ→うんうん→またウェルカム」の心理的安全性

心理的安全性とは、他者からの反応に怯えることなく、自然体の自分をさらけ出し各自が安心して自分の考えを自由に発言したり、行動に移したりできる状態のことです。

人が安心して意見を言えるようになるには、相手からの最初のリアクション、話している最中のリアクション、話終わった後のフィードバックが大切であり、それによって次からの心理的安全性が変わってきます。

そのために取り入れているのが、
まず声をかけてもらった時に良いリアクションを返す→話している最中は相手が安心できるリアクションを返す→最後に今回もウェルカムだったし今後もウェルカムという全体フィードバックを返す
という流れです。

心理的安全性は、2015年に米グーグル社が　「心理的安全性は成功するチームの構築に最も重要なものである」 と発表するほどチームでは大切なものです。今回紹介した方法も然り、自分と相手だけではなくチーム全体でも改善していけるアプローチを今後していきたいと思います！

さいごに

さいごまで読んでいただきありがとうございました！

この１年、本当に色んなことがありました。。。
初めて任せていただいたちょっとしたタスクに１ヶ月間苦しんだり、同じ指摘を何回も貰ったり、責務が全然考えられてなかったり...うぅ....技術力が追いつかずずっと奮闘しています。
そんな苦しい中で、どうにか会社で自分のバリューを出すために実践し、結果が出たものだけまとめてみました！

２年目もこれらを実践しつつ、新たな領域に行けるよう引き続き頑張る意思表示をこちらにして終わりたいと思います。The End