見出し画像
Photo by golchiki

エンジニア1年目で評価されたこととやってよかったこと

壮｜Masato Tanaka

こんにちは。壮（@sew_sou19）と申します。

エンジニアになったのが2020年11月で、いつの間にかエンジニア1年生が終わっていたのでその1年間を振り返ろうと思います。

僕が入社した会社は、

  • サービスの歴史が長くレガシーすぎる部分が残っている

  • 独自フレームワークを使用していてGoogle先生でも答えを知らないことが多い

  • メガベンチャーと称されるほど規模の大きい組織なのでどのチームが何をやっているのか分からない

  • フルリモートで心理的にも物理的にも気軽に質問できない

という環境なのもあって、入社直後はかなり苦労しました。

当然、「エンジニアとして評価される」ことは到底考えられない状態でした。

ただ、そこから自分なりに考え試行錯誤して動いた結果、それなりに評価していただけました。

「何が評価されたのか」
「どういった行動を取ったのがよかったのか」

を言語化しておくと、今後の自分のキャリアを積み上げる上でも有用なのと、もしかしたら参考にしてくださる方もいるかもしれないと思ったので、noteにまとめました。

少しでも参考になれば幸いです。

余談ですが、入社8ヶ月までをまとめた前回のnoteはそれなりに反響いただけました（嬉しい）。

評価されたこと

まずは一番気になるであろう1年間働いての評価です。
定量的なことと定性的なことを書くとこんな感じです。

定量的な評価

・等級：1→3へ昇格
・昇給：60万円UP
・年収：1年目の相場の1.7〜2倍

定性的な評価

チームリーダーと部長から言われたことです。

・成長速度が半端ない
　- 半年前はやっと一人立ちしたと思ったら、今や自分で他チームやビジネスサイドと調整して案件ガンガン進めてる
　- 設計や実装も綺麗だし質が高い。未経験とは思えない
・チームをリードできてる
　- 主体性持って行動してくれてる。言う前に既にやってる
　- 周囲へのサポートもしてるし周りからよく頼られてる
・チームのモデルケース
　- 成長の仕方や考え方が理想。他の人にも共有・相談乗ってほしい
　- 採用したい人材像

任されるようになったこと

・バグチケのリソース管理
・中規模案件（開発期間1〜2ヶ月、QAあり）の開発リーダー
・新人のメンター

1年目としてはめちゃくちゃありがたい評価を頂けましたし、結果（昇格や任されることが増える）もついてきたのでかなり自信になりました。

今の会社でリーダーを目指しているので、しっかりキャリアを進められている実感を持てたのと、進む方向が間違っていないことが確認できたのは個人的に一番よかったです。


やってよかったこと

評価されたことの要因分析の前に前提を簡単に説明しておくと、僕がいるチームは

「技術ゴリゴリ！常に最新の技術使ったり新しい機能をいろんなアーキテクチャ用いて実装！」

というよりは、

「会社の売り上げに貢献するための企画対応やビジネス側からの要望に応じて機能の追加・改修を行なう」

チームです。強いて言うなら「BFF層のバックエンド」です。

そのため、関係する部署やチームが多いと同時に、打ち出す企画や施策もかなり多く常に忙しいので、ゆっくり技術と向き合うというよりは、いかに他チームと連携・調整して案件の数を品質高くこなせるか、システムをより良くするための動きができるか、を求められるチームです。

そんなチームの特性も踏まえた上で「今の自分やチームに何が必要か？」「どういう動きをしたら喜ばれるか？」を考えて行動に移しました。

その上で意識したのは大きく2つです。

・ドメイン知識の集積
・上司の負荷軽減

■ドメイン知識の集積

まずはドメイン知識を溜めることに注力しました。

なぜやろうと思ったか

冒頭でもお伝えしましたが、僕の会社（チーム）はレガシーゆえに特殊なことをやっていたり、独自フレームワークを使っていることもあって、周りに聞かないと分からないことがかなり多いです。

同時に、サービスの歴史が長かったり関係チームが多いこともあって、その機能や実装がなされた経緯を知らないと思わぬところでデグレを起こしたり、どの箇所をどのチームが担当しているかを知らないと、必要なチームにエスカレーションできず考慮漏れが発生したりと、知るべきことが多いかつ知らないと予期せぬミスに繋がりやすい、という状況です（実際僕も何回もやらかしました）。

逆に言えば、知るべきことを知っている＝スムーズに開発ができる、ミスなく案件を回せる、ということでもあるので、「これは必須だ」と思ってかなり意識してドメイン知識を集めました。

ちなみに、社員規模は（たしか）1,000人以上で、エンジニアの数は（たしか）200〜300人ほどで、チームの数は（たしか）50以上あります。


どうやって集めたか

「知るべきことがめっちゃある！知識を集めなければ！」と思っても、最初はどう集めるべきかが分からず、毎日学んだこと・知ったことをただメモする程度でした。

当然、それだと知識が増えるスピードには期待できないですし、自分が経験したこと以上に知識は増えません。

そこで以下を行いました。

・問合せ対応や雑多な対応に対して積極的に手を挙げる
・知識の定着のためにドキュメントを残す
・後輩の質問対応をすることで知識の深堀りを行う

問合せ対応や雑多な対応に対して積極的に手を挙げる

まずは、経験や知識の幅を広げる場を増やすことから始めました。

いくら社内のドキュメントが整っていて「システムの全容はここに書かれている！」という状態だとしても、ドキュメントを読むだけでは知識の集積には繋がりにくいです。

「あ、なんかどこかで読んだな〜」くらいにはなるものの、いざ細かいことを聞かれると「なんだっけ。分からん…」となります。

それを避けるには、目的と当事者意識を持ってコードやドキュメントを読み解く必要がありました。それにうってつけなのが、チーム内外からの問い合わせ対応です。

メリットは経験の場を広げられるだけではなく、「疎かにはできないが、案件とは関係ないので先輩が敬遠すること」なので経験が浅くても手を挙げやすかったり、それを巻き取ることで他のメンバーやリーダーからも感謝されたりなど、多くあります。

僕は実際に自ら手を挙げて動いたことで、以下を得られました。

・機能や仕様について知れた
　- 問い合わせへの回答は前提知識が必要なことが多い
・言語についての理解が深まった
　- コードを読み解くことで言語独自の動きだったりメソッドを知れる
・実装パターンについて知れた
　- とにかく歴史が古いのでパターンが多い
　- 独自FWの癖を知れる
　- きれいな実装とそうでない実装を知れる
・バグやリファクタリングできそうな箇所が見つけられた
・案件で対応する際に知っている箇所だとスムーズになった

知識の定着のためにドキュメントを残す

次に、得た知識を自分のものにするためにもドキュメントを必ず残すようにしました。

一つの問い合わせで一つのドキュメントを残す、一つの実装上の困りで一つのドキュメント残す、というほどありとあらゆることを書き起こしました。

その際に意識したのは「誰が見ても書いてあることを読めば理解できる」ことです。というのも、既存のドキュメントの中には前提知識が多く必要だったり、必要な説明が端折られていて、読んでも「結局どういうことや…」となることが多かったからです（エンジニアとしての経験が足りてないからかもですが）。

また、読みやすさ（誤認しない・短時間で理解できる）にもこだわって書きました。

  • 見出しの粒度を揃える

  • 文章だけで書かずリストなどマークダウンを活用する

  • 必要な情報をロジカルに組み立てた文章構成にする

  • 表でデータ例を示す

  • 文章だけだと理解しにくい部分は適宜miroなどを使用して図解

ことあるごとにドキュメントを残すことで、以下を得られました。

・知識の整理ができる
・曖昧な部分がつぶせる
・あとで見返せる（自分が作ったドキュメントだと自分が一番理解しやすい＆思い出しやすい）

また、ドキュメントを数多くかつ分かりやすく書いていると、「この資料の作成者に●●さんのお名前があったので聞きたいのですが…」みたいな問い合わせが増える→更なる知識の深掘りになる＆他チームとの関係を多く作れる、という副次的な効果も生まれました。


後輩の質問対応をすることで知識の深堀りを行う

後輩が入ってきたことで、自分が知っていることを周りに伝えようと思いました。

色んなことに手を挙げて活動的な印象が強かったり、ドキュメントを数多く残したりしてると後輩から質問されることが増えます。

僕自身、入社したては分からないことが多くて困った経験があったので、「おそらく後輩も同じ思いをしてるだろうな」という予測は容易でした。だからこそ「自分が知ってることは全部教えたい」と思いましたし、自分が辿ってきた道だったので、解消方法などを伝えるのも容易でした。

特にメリットを求めず後輩の質問対応を行っていたのですが、結果的に多くのことを得られました。

・当時の調査では足りてない部分をさらに深掘れる
・自分が知らないことも一緒に調査することで効率的に知識を集積できる
・「利他意識のある人」という印象付け→頼られる機会が増える


このように、コードを読む場を増やす→ドキュメントに残す→それについてさらに深堀る、というサイクルを回していると雪だるま式にドメイン知識が溜まっていきました。

そして、ドメイン知識をどんどん溜めることによって、

ドメイン知識が溜まる
↓
知らないことが減る
↓
不安が減る
↓
行動しやすくなる
↓
成果が増える
↓
評価される
↓
自信になる

ということも身をもって体感したので、やはりやってよかったなと。

僕が得たドメイン知識をあえてカテゴライズするならこんな感じかなと思います。これをもとにメンターとして新人教育を行っていますが、短期間で立ち上がりつつあるのでよさそうだなと思っています。

・組織・チーム
　- 組織図の把握
　- 各チームが何やってるか
・プロダクトのアーキテクチャ
　- 既存のアーキテクチャ
　- 今後のアーキテクチャ戦略
・プロダクトの機能・仕様
　- どんな機能があるか
　- それがどんな仕様か
・コードの読み解き
　- 言語・FWの仕様
　- ライブラリの仕様
　- ミドルウェアの仕様
・コードの設計・実装パターン
　- 「こういう時はこういう実装」という経験値

自ら情報を取りに行かず、指示された範囲内だけで知識を得ようとしていたら、短期間ではここまでドメイン知識を溜められなかったと思います。


■上司の負荷軽減

なぜやろうと思ったか

一言で言えば「チームで一番必要なことだったから」です。

多くのチームがそうだと思いますが、僕のチームもリーダーの負荷が高くて結果的にリーダーがボトルネックになることが多々ありましたし、やるべきことなのにリーダーのみがボールを抱えていてメンバーに展開できず何も進まない、みたいなこともありました。

そこで、メンバーができるタスクを巻き取って負荷を下げる→チームとしての成果も上げる、ということが必要と思ってリーダーの負荷を下げるためにあらゆることをしました。

やろうと思ったこと

当初は、ひとまず以下をやろうと考えてました。

・リーダーがメンバーに求めることを理解する
・リーダーに頼らずとも案件回せる
　- 自分にできることを着実に増やしていく
・本来リーダーがやることを先んじて行う
　- チームの課題を洗い出し、必要なことを考えてそれを実行に移す
・他チームとの関係構築
　- リーダーというハブを介さずとも案件が進められるようにする

具体的にやったこと

具体的にはこんなことやってました。

・行動がうまい人をTTP
・利他意識：チームの将来を考える
・主体性あるコミュニケーション

行動がうまい人をTTP

TTP（徹底的にパクる）しました。

先ほども書きましたが、僕のチームに求められる動きは「多くの案件をミスなく回せるか」です。

それを実現するためには、綺麗なコードを書くことだけではダメですし、技術的なキャッチアップだけでも足りません。一方で話がうまいだけでもダメですし、調整力を磨くだけでも足りません。

多くの案件をミスなく回すために必要な要素は数多くあり、それぞれの性質がバラバラです。それを一つずつ分析してキャッチアップしようとすると時間がかかるので、まずは「うまく案件を回している人」をよく観察しました。

  • 要件を決める際は認識のズレが起こらないように必ずドキュメントをもって合意する

  • 議事録はテンプレ化して、誰と誰が話してもその内容が伝わるように環境を整える

  • スケジュールは画一的に決めるのではなく、その時のリソース状況や要件の複雑さや案件の性質まで事細かに考えて決定する

  • 実装は保守性と可読性を考慮しつつも、納期や機能などとの優先順位を疎かにしない

  • リーダーに頼るのは「リーダーという立場があってこそ意味がある」ことに限定して、それ以外は自ら行う

  • ボールは長く持たず、一方で一歩先を読んだ回答をして余計なコミュニケーションを減らす

一例ですが、メンバーが上記のような動きをしていると案件がうまく回っていることに気付きました。

一方で、当たり前ではありますが「知っていること」と「実践できること」には天と地ほどの差があります。案件をうまく回す要素を知っていたとしても、それが実践できないと意味がないので、まずは下手でもいいので恥を捨てて真似してやってみました。最初はあまりうまくいかないしミスもしまくりましたが、実践→失敗→原因分析→再度実践、を繰り返すうちにコツを掴めて自信を持って実践できるようになりました。

結果的に、リーダーがメンバーに求める動きを先回りして実践できるようになったので、余計な手間や確認作業を省くことができ、負荷軽減に繋がりました。


利他意識：チームの将来を考える

これは「本来リーダーがやること」のうち、僕でもできそうなことを探し出して行ったことです。

弊社はチームや部署の編成がコロコロ変わります。今のチームも2021年4月にできたばかりで、在籍メンバーもリーダーを除くと最長で社歴3年、とメンバー自体もチームとしても未熟な状態でした。

そんな中でも、チームに求められる業務量は減らないどころか増していく一方なので、それに対応するにはチームとしてのキャパを上げることが必要と考えました。

それに対して自分ができそうだったのは「入社してから困ったことを解消する取り組み」です。

困ったことを挙げると、

  • 実装する際に「ここは定数でおくのか引数を増やすのかどっちがいいんだろう。他の人はどう考えて実装してるんだろう」と迷うことが多かった

  • 他のメンバーが担当した案件の詳細を把握できていないがために車輪の再発明をしてしまった

  • ドキュメントを残す文化はあるものの根付いておらず、担当した人に聞かないと詳細が分からない

  • 納期優先で冗長なままリリースしたコードがそのままになってて読みにくい

  • コード規約はあるものの形骸化している（守られてない）

などがありました。これは”未経験だから”困ったことというよりは、チーム全体の課題だと思ったのと、このまま残っていると自分としても引き続き困る（いわんや、新しくジョインした人をや）と思ったので、改善することにしました。

振り返ってみると、行った取り組みは結構ありました。

・コードレビュー会の実施
　- 実装の知見を共有する
　- 実装方法について共有・議論する
　- コードの品質が人によらず均一に保てる効果が期待できる
　- レビューする時間を確保してレビューが滞らないようにする
　- コード規約の輪読を行う
・案件共有会の実施
　- チーム全体で他の案件詳細やドメイン知識を深める
　- 共有用にドキュメントを作成or更新する
　- それによってドキュメントを正しい状態に保つ
・ドキュメントの整理と作成意識の醸成
　- まず自身がドキュメントを丁寧に作成
　- 問い合わせ対応や質問への回答でもドキュメント作成（余裕あれば）
　- Slackなどテキストベースで回答するのではなくドキュメントを投げる
　- リーダーにその動きを推奨してもらう

結果的に、チームの地力は上がってリーダー頼みな部分は減りました。

リーダーからも周りのメンバーからもこれらの取り組みを褒めていただくことはあったのですが、僕としては大それたことをやったつもりはなく、「自分が困っていることを解消するために周りを巻き込んだ」だけです。めちゃくちゃ大変でめちゃくちゃ頑張ったわけでもないので、やりたいことと求められていることがマッチした結果なんだろうなと思います。


主体性あるコミュニケーション

文字にすると当たり前な感覚になりますが、意外と重要でした。

BFF層のバックエンドは（明示的に言われていませんが）案件全体の設計をリードする必要があります。業務内容的に、

  • マイクロサービス側でDBからデータを取得して、BFF層に渡してもらう際のレスポンス内容や取得条件を決める

  • フロントエンドが叩くAPIのパラメータとレスポンスを決める

  • テンプレート描画時に使用するメソッドの定義を決める

  • 上記を決めるためにビジネス側と細かい要件を詰める

という動きが必要だったからです。

結果、関わるチームや連携する部署が多くなり、必然的にボールがあちこちから飛んでくるしこちらからボールを投げないといけない状況になります。

そんな状況で「言われるまで動かない」「主導権を相手に持たせる」「自チームの領域外のことには我関せず」というようなコミュニケーションを取っていると、対応が後手後手になって手戻りが発生したり、納期直前になって考慮漏れが発覚したりします（実際しました）。

そこで以下を意識して動きました。

・相手に任せずこちらで会話や案件そのものを主導する
・そのために必要な情報をキャッチアップする
　- 開発側に降りてくる情報は必ずチェック
　- ビジネス側のSlackチャンネルや議事録も覗いて意図を理解する
　- 調査段階である程度設計のあたりもつけておく
・相手の反応を見越して準備して、意図する方向に持っていく
・そのために人をよく観察する
　- どういうコミュニケーションとる人なのか
　- その人の優先度はなんなのか
　- 地雷は何か

最初は「まだ入社1年経たない自分なんかがこんなに出しゃばっていんだろうか。未経験だし変に思われないか」とビクビクしていましたが、慣れるにつれてそんな不安は無くなりましたし、むしろ「主体的に動いてくれてありがとう」と感謝されるようになりました。

それに、「そういう動きをしてくれる奴」と周りに認知してもらえるとさらに動きやすくなって、これまでリーダーが行ってきた調整などのタスクも巻き取ることができました。この動きが一番評価されました。

入社1年足らずで社内の知名度もそこまでないのに、それでも周りと丁寧なコミュニケーションをとって主体的に案件を進めている動きがよかったみたいです。


こういった動きができた要因として、先に挙げた「ドメイン知識の集積による自信」も大きいです。

知っていることが増えれば不安は少なくなり、不安が少なくなると「やってみよう」という挑戦は多くなり、挑戦が多くなるとできることも増え、できることが増えると自信に繋がり、自信があると他者とのコミュニケーションにも躊躇しなくなります。

結果的に上司の負荷をかなり軽減できました。

さいごに

ここまで読んでくださってありがとうございます。

前回の記事の方が苦労話があったり、苦しみを乗り越えるために試行錯誤した感じがあるので今回の記事は薄く思えるかもしれません（というより僕自身がそう感じましたw）。

ただ、それでも「異例の出世」と言わしめるほどの評価をもらえた理由を言語化しておかないと気が済まなかったので書き殴りました。

良好な評価をもらえた要因をつらつら書いてきましたが、一言でまとめるなら「チームが求めることと自分が得意なことがマッチしていた」のかなと思っています。

それもあって、エンジニアの最初のキャリアとしては最適な環境にジョインできてラッキーだと思います。

一般的な環境（明確なものはないと思いますがw）に比べると、ハードスキルである技術力や経験よりはソフトスキルが求められたり、それをうまく活かすことで評価されてリーダーに繋がる環境だったりと、特殊なキャリアなのかなと思っています。ただ一方で自分に合っているとも思うので、このままキャリアを進めていきたいです。

また気が向いたらこんな感じでnote書き殴るので、その際は読んでいただけたら嬉しいですし、スキ押していただけるともっと喜びます。

感想等はTwitterでいただけたら泣きます。

ではまた。



いいなと思ったら応援しよう！

壮｜Masato Tanaka
自身のキャリアで得た知見について言語化しています。執筆活動の励みになります！