はじめに
- 本記事は、はじめてのアドベントカレンダー Advent Calendar 2023 22日目の記事です。
- 対象読者は、実務未経験からエンジニア転職を目指されている方、また、そのようなエンジニアを採用する可能性がある企業の方を対象としています。
- また、本記事では技術的な深い内容の言及は控えて記載します。
この記事の結論
- 1年間の学びを振り返り、技術的なギーク(スキルセット)とスーツ(ビジネスのスキルセット)の双方が必要であることに気付きました。ギーク面ではチーム開発やプログラミング言語の基本的なスキルの不足があり、スーツ面では問題解決の言語化能力やチーム意識が重要であると認識しました。
自己紹介
- 元々は、機械系のエンジニアとして自動車メーカーへ就職し6年間勤めていました。
- 2020年11月頃からweb系のエンジニア転職を目指して勉強を始め2023年1月に ourly株式会社という自社開発企業でバックエンドエンジニアとして転職しました。
- ourlyは、Web社内報やプロフィール機能を通して、インターナルコミュニケーションの活性化を目的としたSaaSを提供しています。
1年間の概要
1~3月
- リリース済みの既存実装のAPIを実装
- rspecでAPIのテストの書き方を獲得
- チーム開発におけるGitやGitHubの使い方を習得
4~6月
- 小規模な既存実装の改修
- 要件定義まで完了したプロジェクトを仕様整理、実装、テスト、リリースまで対応
- 開発の全体の流れを体験を通して把握
- プロジェクトにおいて認識齟齬が生まれる可能性や、vsPOとvsエンジニアとで説明の仕方を変える必要があることを学ぶ
- またQCDSの内、Sの部分を細かく確認してアジャイルに対応することを学ぶ
7~9月
- 中規模な新規開発のメンバーとしてアサイン
- 要件→設計をレビューする立場で参画し、設計時の進め方を認知する
- 実装時に参画/本格的にPRレビューをするようになる
- スクラムでリードタイムを短縮するための施策やマインドセット面で貢献する
10~12月
- 大規模な新規実装にアサイン
- 要件→設計の部分も担当するようになる
- 実装においても、PR分割を意識してこれまでより、細かい単位で多くのPRを出すようになる
- PRレビュー数も大幅に増え、そのリードタイムも短縮された
- (弊社の開発チームではFindy Team+を導入して日々開発生産性を可視化してます。2Q(左)vs3Q(右)で比較してもPR作成数、レビュー数、そのリードタイム全てが軒並み向上しました)
学び
- この1年間で様々な学びがありました。
- 学びを俯瞰して見た時に、技術的なスキルセット(ギーク)とビジネスのスキルセット(スーツ)の2面性があると考えたので両者に分類して記載します。
ギーク面
チーム開発の経験不足
- 個人で独学していた時は、ブランチ切ってPRを作る意味が少なくその機会がなかったです。
- レビューをしたり、してもらう経験もなく、特にレビューをする際の感覚を掴むのには時間がかかりました。
- そのためGitflowでの開発やGitHub上での画面操作は入社後に初めて体験したので最初戸惑いましたが、業務を通して徐々に習得していきました。
自社で扱う技術スタックの全般的な知見は持っておいた方がよい
- AWS, Docker,SPAの仕組みなどの知見があった方が良いです。
- 自社開発企業だと、RailsもAPIモードで開発してFEはモダンなフレームワークを用いている企業が多いと思います。
- 私の場合は、ポートフォリオ作成時に、プレーンなRailsでの学習だけでなく、APIモードでの開発を体験しておいたことが入社後にキャッチアップの必要がなくてスムーズでした。
プログラミング言語自体の単純なスキル不足
- 私はRubyを用いて普段開発をおこなっています。
- 転職前に独学した時に、Udemyの教材で学習してアプリケーションを作れるようになりましたが、Rubyの基礎的なメソッドを使わなくても作れます。
- 極論、each doを使わずに、for文で全てのロジックを作ることができるますし、不要な変数を毎度定義すればmapやtapなどのメソッドを使わなくても処理が実現可能です。
- しかし、実際の現場ではよりRubyっぽい記述や、よりパフォーマンスが高い記述への変換が必要です。
- これらの言語自体のスキルが不足していると2Q終わり頃に感じ、もっと早くから手を打つべきだったと思っています。
- 初学者は、競プロ用のサイトで訓練のように繰り返し反復することがMustで必要だと思います。
生成AIの恩恵を受けながら開発
- 仕様を論理演算に変換できた後は生成AIに投げておく。投げた結果を修正してプロジェクトのコーディングルールや慣習に直すという方法を使ってロジックを実装するように意識しています。
- また、 「〇〇って□□って意味であってる?」などの質問は生成AIに聞くことで納得感を増したり、「Railsで〇〇の条件下で□□を実現することはできない?」という質問で手段を獲得することができます。
- このようにして生成AIの恩恵を受けながら効率的にアウトプットを出すことを意識して開発しています。
スーツ面
言語化能力が大事
- 自分が置かれてる状況ややりたいことを要約して簡単に説明できるようにする力で、issueを自己解決ができない初学者にはより必要なスキルだと思いました。
- 特に「問題を因数分解する力」と「等価な問題を抽象的に置き換える力」が言語化の本質だと思います。
- 幸い私の場合は、理系漬けの人生だったのでこのあたりのスキルは自分の得意分野で特に苦労はしませんでした。
質問やコミュニケーションをとって円滑に仮説の壁打ちをする
- 弊社では普段からビズサイドのメンバーが役職や職能に関係なく、質問や提案やフィードバックがオフィスの中を行き交っています。
- エンジニアはビズサイドに比べて、1つの問題に出会した時に自力で解決するべきというカルチャーが強く、質問して相互に解決に向かう方法が軽視されていると思います。
- 彼らがもし同じエンジニアだった場合に、取るアプローチは果たして、「時間をかけて自身の頭で考えることなのか？」「もっと早く見切りをつけるのではないか?」「そもそも自身で考えるという行為はビジネスを進める上で最適なのか？」「むしろ早く質問をして壁打ちを増やしていくことの方が良いのではないか？」 という葛藤が何度もありました。
- このスキルについては今だに正解が分からず、これから自分のエンジニアとしての成長において特に重要な要素になるという直感があるので最適な方法を模索していきたいと考えています。
チーム意識 (スクラム力)
- チームでスクラム開発をしているので、振り返りの際にどれだけチームとしてのネクストアクションを持てるが重要だと感じています。
- 自分ができていることでも、チームでできていないことをどうやったらその問題を解決できるか? 考えたり、スキルが不足していることでも、マインドセットや仕組み/運用によって改善できる部分へのアプローチを考えることはチームに参画した日からできることです。
- これらの意識は、「自分という1人の個体」として捉えるのではなく、「チームという1つの個体」として捉えることが本質であると考えています。
- この意識がスクラムを回すうえではより重要であると感じました。
エンジニアである前にビジネスマンとしてできることを考える
- エンジニアなのでエンジニアリングで貢献することは当然期待されています。
- 一方で、社内イベントや社内の組織開発に関するプロジェクトへ有志で参加することはできます。
- 私の場合は幸いなことに社内の全社イベントの運営や社内のタスクフォースの立ち上げなどに運良くこれらの機会に巡り合うことができました。
- 自分が貢献できることを職位や職能に限定せずに挑戦することで、企画/プロジェクトの設計における視点を獲得できました。
- 特に「目的設計して施策を考える」という流れはエンジニアの業務で完全に等価なものは少ないと思います。
- そのため、これらの体験を通して学んだことはとても価値がありました。
- モノづくりの作り手として、そのモノには「どんな思いで設計がなされれたのか?」「どんなストーリーがあって生み出されたのか？」を考える際の視点が加わりました。
さいごに
- 私は社会人歴7年目にして転職しましたが、1年間がとても濃厚であっという間に過ぎ去っていきました。自分が中学卒業時点で意思決定して選択したエンジニアリングの道がハードウェアからソフウェアトに変わりましたが、今も僕の前を切り拓いてくれてる事に感謝して、これからもこの道を前のめりに突き進んでいこうと思います！