はじめに
株式会社カウンターワークスでソフトウェアエンジニアとして働いているchibaです。
この記事では私が「エンジニアとして身につけて役に立った」ことを入社前と入社後に分けて、それぞれ5項目ずつ計10個紹介します。
丁度12月ということもあり、1年の振り返りも兼ねて新しく2024年に新卒の自分が身に着けて良かったことをまとめて、他のエンジニアにも共有できればと思い記事にしました。
「自分にとってこの項目は当てはまるのか？」と考えながら読んでいただけると嬉しいです。
それでは具体例を挙げながら、それぞれ「いつ役に立ったのか」、「なぜ重要だと考えたのか」について説明していきます。
多少項目で矛盾する点もあるかもしれませんが、場面と状況によって使い分けることが重要だと考えているため、各人で自分に合うものを選んでいただければと思います。
想定読者
- ジュニアエンジニア
- 新卒エンジニア
- エンジニア志望の学生
入社前
ほぼ独学でソフトウェア開発を学んでいた中で学んだことです。
知らないことに対する興味と調べる癖
現代のソフトウェア開発はネット上に情報が溢れているため、調べるだけで多くの情報・知見が手に入ります。
新しく何かを開発する際にどこかで聞いたことがあるな...と思うことができれば、それについて詳しく調べることもできます。これが正に自分の頭の中に選択肢を作っておくことの重要性です。
例えば私は以前書いた記事にある通り、 Rubocop という静的解析ツールについてカスタムルールを作ったことがあります。これについて振り返ってみると、構文解析、字句解析についての多少の事前知識がなければ作ることはできませんでした。
ある課題を解決する際に選択肢として選べるためには自分の頭の中にトリガーとなる知識を持っていることが重要です。
チームで議論をする際にも選択肢が増え、より良い議論の土台となります。
英語記事の最低限の読解力
英語記事のと書きましたが、これは一次情報を調べるために必要なと読み替えてもらっても良いです。
アプリケーションについて基本的にリリースされてから時間が経ったものしか日本語の詳細なドキュメントは作られません。また、CVEなどのセキュリティに関する最新の情報も英語で発信されることが多いです。
他にもStackOverflowやGitHubのIssueなど、エラーが発生した際に調べるための情報源は英語が多いです。
実際に私はRailsについて調べるときは必ずRailsのAPIドキュメントを読みます。そうすることであるメソッドにはブロックを渡せることが分かり、それを使ってよりRubyらしい効率的なコードを書くことができました。
個人的に日々の開発の中で一番勉強していて良かったと感じたのはこの項目でした。
読書癖
出版されている技術書は一層信用できる情報源です。一冊の本が出版されるまでには造詣の深い複数名にレビューされ何度も校正が行われた上で著者の伝えたい知識が詰まっているからです。また更新されることも少なく、情報源として信頼できます。
ネット上の記事は頼りになるものも多く存在しますが、誰かが理解・咀嚼し情報の取捨選択が行われた結果のものです。あくまで私は参考程度に考えています。
例えば私は「理論から学ぶデータベース実践入門」という本がRDBを学ぶには非常に良い本だと考えています。しかし、こちらの本についてネット上である箇所は誤っているという指摘を何件か見ました。
これは著者が誤解していたのか、あるいは誤って伝わってしまうような表現をしてしまったのか、それとも読者が誤解してしまったのか、などの要因が考えられますが、本という形式では頻繁に内容が書き換わらないことでこのような健全な議論も生まれます。
月１冊程度本が読めていると自分の知識に関して多少の自信をもって発言でき、チームに貢献出来ると思います。
コンピュータについての基本的な理解
コンピュータサイエンスと一般的に呼ばれる領域についての基本的な知識は、ソフトウェア開発においてより良い設計と問題特定において非常に重要です。
私は学生の時に情報系学部ではないため、多少この点をコンプレックスに感じていたため、資格取得の過程で基礎となる知識を身につけました。
例として、分かりやすいところでは計算量についてです。最大でその処理が O(n) 記法でどの程度の計算量になるかを理解していることで、最適な設計を選ぶことができ障害を防げパフォーマンスの向上に繋がります。
（こう書きつつも私は何度か計算量を無視した設計をしてしまっており、コードレビューで指摘をもらいました...）
ネットワークがどのように構築されているか、OSがどのように動いているか、プログラミング言語がどのように動いているか、などの知識は、より長く動かせるアプリケーションを作るためにあると良い知識の一つです。
今から再学習したいと考えている方がいれば、私は幅広い基礎知識が得られる応用情報技術者試験を受けることをお勧めします。
広い意味でのなぜ自分のアプリケーションが動くのかの知識
一つ前の項目に近いですが、フレームワークを利用して開発している場合、そのフレームワークがどのように動いているかを知っているとより効率的な開発ができます。
例えば、自分がよく使っているフレームワークがどのようにファイルを読み込んでいるか知っていますか？
Railsの場合、 zeitwerk というgemがファイルの読み込みを行っています。これを知っていると、ファイルの読み込みの順番を変えたりカスタマイズすることができます。
あるいはブラウザがサーバーにリクエストを送った時に、どこを経由してどのように処理されているかの流れを知っていると、より効率的で保守性の高い設計ができます。
保守性の高いアプリケーションを作るためには、そのアプリケーションがどのように動いているかを知ることが重要だと考えています。
入社後
ここからは入社後に主にメンターから学んだことについて書いていきます。
選択と集中の判断力
私達の会社で重要視している「選択と集中」と呼ばれる考え方があります。これは目的の達成・課題の解決のために多くの選択肢がある中で、どれを選択し、集中するかを判断することです。
目的を定める能力と読み替えても良いかもしれません。
時間、お金などのリソースは個人も会社も当たり前ですが有限です。短い期間でよリ高い成果を出すためには、どの選択肢が最もインパクトがあり重要であるかを判断することこそが大事です。
これに関して私は入社するまで全くできませんでした。
例えば個人の話でいうと、私はTypeScript, Ruby, Rust、Go など複数言語に興味があります。これまではその時々で興味があることに取り組んでいました。
蓋を開けてみると実際にはどれに対しても深い理解を持つことができず、どの言語も中途半端な理解になっていました。
RPGでいう攻撃力、魔法攻撃力、防御力、魔法防御力のいずれもが中途半端で役割を持てず MMOではパーティに入れにくいイメージです。
私の場合入社した後にメンターと話し、どうやったらチームに最速で貢献できるかを議論しました。
その結果、業務で使うBEの技術に集中して取り組むことを決め、最近では多少チームに貢献できるようになりました。
自分は何を選択し集中しするかを判断することが、より迅速な成長につながると考えています。
問題定義と整理能力
問題が発生した際には、何故問題なのか・要因がどこにあるのかを整理することが重要です。
バグの修正などでは狭い領域での問題定義が必要ですが、新機能の開発などでは広い領域における「何故その機能が必要なのか」などの問題定義が必要です。その際に適切な問題の定義能力と要素分解能力の2つが必要になります。
例えば、私は開発中に問題が起きた際にはロジックツリーのような木構造を思い浮かべ、あるいは書き出して問題の要因を特定するようにしています。このような問題整理を行う方法を自分で決めておくことで口頭で話している際にも整理しやすくなります。
必要な箇所に集中してアプローチを行うことで、余分なリソースの投入を抑えることができます。
また問題の定義を間違えると、全体として間違った方向に議論が進んでしまうことがあります。
例えば転職をしたい時に、なぜ転職がしたいのか、転職後にどのような状態が理想なのかを明確にしていないと、転職先を選ぶ際に自分にとって最も重要な要素を見落としてしまう可能性があります。
これらは私が入社するまでできなかったことですが、入社後にメンターと話す中で意識するようになりました。
質問・説明能力
チームで開発を行い組織の中で働くのであれば、質問能力と説明能力は非常に重要です。
自分が分からないことの方が圧倒的に多い中で、他の人と協業するにあたって質問能力は必要です。
何を知りたいのか・何が分からないのかを明確にすることで、相手にも質問しやすくなります。また、質問をすることで自分の思考を文章化する際に整理されることもあります。
説明能力についても同様に重要です。
なるべく簡潔な文章で自分の意図を伝えます。私はPREPと呼ばれる話し方を最近知り、意識して話すようにしています。（気になった方は調べてみてください。）
またこれらは、誰に問題があるかというより、双方が努力することで改善されるものであるため、まずは自らが努力することが重要だと考えています。
仕事で長時間使う技術の知識
これは選択と集中に近いのですが、当たり前ですが仕事で最も長い時間使う技術については深い理解を持っておくことが必要です。
費用対効果、コスパを考えた時に自分が最も早くチームへの貢献度を高めるには、仕事で使う技術に集中して学習を行うことが良いです。
貢献度を上げれば、自分の給与も多少相関して上がる可能性がありますし、ダイレクトにチームの中での評価も上がる可能性が高いです。また余暇が生まれることで、他に回せる時間も増えます。
例えば、私はDBとRailsの学習を集中して3か月ほど続けています。なぜなら自分が業務の中で最も長時間使う技術だからです。
ここはキャリアプランにも関わる部分であり、自分がどのようなキャリアを築いていきたいのかを考える上で重要なポイントです。
一定の期間集中して学習を行い、その後にキャリアプランを見直すことで、より効率的に成長することができると考えています。
チーム開発についての知識
チーム開発の知識の重要性は私が入社するまで意識すらしていなかったことです。
仕事で生まれる多くの問題は「人対人」にまつわるものだと個人的に考えています。
上手く機能しているチームを作るためには、チーム開発についての正しい知識が必要です。アジャイルでもウォーターフォールでも、チーム開発には共通する部分があり、合意形成、対話による問題解決、コミュニケーション、フィードバックの受け取り方、などがその一例です。
これらの方針をチームメンバーが共有していることで、チーム全体の生産性が向上します。
重要なことは、外部に決められた方法ではなく自分たちにあった方法を選択することです。
例えば、出社頻度、スクラムイベントについても正にその一つです。
理想はチームに適した出社の頻度、スクラムの期間をチーム自ら話して決めるべきです。
気になった方におすすめの書籍は「エンジニアリング組織論への招待」です。
先日チームメンバーのキタデさんが紹介してくださっていました。
チームとして健全に機能するためには自らが常に良い人であることも含めて、チーム開発の知識は非常に重要だと考えています。
今後身につけたいこと
最後に、私が今後身につけたいことについて述べたいと思います。
アウトプット癖
頻繁に記事執筆、個人開発のアウトプットを行うことで知識の定着と目に見える自分の資産を作ることができます。
これは私が今最も身につけたいと考えていることです。過去のこちらの記事も参考にしてください。
例えば、採用という面でも互いの適切なアウトプットは下記のような効果があります。
自分の入社するか迷っている会社がより多くのアウトプットをしていれば、その会社の方針や技術力から適切な判断ができます。
反対に個人としても、アウトプットを行うことで自分の技術力をアピールすることができます。考え方に対してもミスマッチングを防げます。
また周囲の人にとっても知見の共有が行われ、業界全体の技術力向上に繋がります。
定期的な技術の棚卸しとキャリアプランの見直し
自らが学習したことについて定期的な見直しを行い、自分の目指すキャリアを再確認することは人生設計において重要だと考えています。
例えば、EMとしてエンジニアのマネジメントを中心に働きたいのであれば、それに向けて対人技術の学習を行うことが重要です。
あるいはスタッフエンジニアとして技術力を高めたいのであれば、自分が今後どのような技術を学ぶかを考えるべきですね。
私は現時点で後者ですが、今後自分がなりたいものがCEO、CTO、エンジニアリングマネージャー、スタッフエンジニアのいずれなのかを考えて、そのために必要なスキルを身につけるための学習を行っていきたいと考えています。
おわりに
ここまで読んでいただきありがとうございます。
新卒入社からもう少しで1年が経とうとしていますが、今までの経験を振り返りこれからのキャリアについて考えることができました。
本記事を読んでみて、私と近い立場のジュニアエンジニアの方々に得るものがあれば幸いです。
最後に宣伝です！
株式会社カウンターワークスでは一緒に働く仲間を絶賛募集中です。
今後の更なる成長のためには圧倒的に仲間が不足しています。皆さまのご応募お待ちしております！
ポップアップストアや催事イベント向けの商業スペースを簡単に予約できる「SHOPCOUNTER」と商業施設向けリーシングDXシステム「SHOPCOUNTER Enterprise」を運営しています。エンジニア採用強化中ですので、興味ある方はお気軽にご連絡ください！ counterworks.co.jp/
Discussion