未経験で入社した新卒エンジニアが初案件で学んだこと

はじめに

こんにちは、エンジニアの小林です！
私は、約1年前の2024年4月に新卒として入社しました。プログラミング未経験でスタートした私ですが、3ヶ月の研修を経て、7月から初案件にアサインされました。

初めての案件は技術的にも精神的にも大きな挑戦でしたが、その分多くの学びを得ることができました。新卒1年目の振り返りとして、初案件で学んだことをまとめてみようと思います。

本記事では、案件の全体像やその中で得られた気づき、経験を詳細に振り返ります。私自身の備忘録として記録するとともに、これからエンジニアとしての第一歩を踏み出す方に向けて、少しでも役立つ情報を提供できればと思っています。

余談ですが、この案件のPMは私が研修時代にペアになってサポートしてくださったN先輩です。背格好も似ていて、たまに兄弟と言われています。この記事で登場したK先輩に後ろ姿を激写されました。似ていますか？笑

初めての案件：業務アプリのリプレイス

私が担当した初案件は、業務アプリのリプレイスでした。このプロジェクトでは、社内で使用されていたシステムの一部を、外部向けのWebアプリケーションとして再構築することが求められていました。

技術的には、C#で書かれた既存アプリケーションをNext.jsを用いて再構築するプロジェクトです。

研修ではJavaScriptやReact の基礎を学んでいたものの、C#とNext.jsについては全くの未経験だったため、プロジェクト開始時は不安と疑問を抱えていました。実際にアサインされた時点では、研修での学習内容を活かせる部分がある一方で、分からないことの方が圧倒的に多く、自信を持てない状態でのスタートとなりました。

システムリプレイスについては別記事で詳しく解説しています。
こちらの記事もぜひお読みください。
＞システムリプレイスとは？背景や移行方式、注意点を解説

言語の壁を乗り越えるー「分からない」を「分かる」に変えるまで

この案件では、まずC#のコードを読み解く必要がありました。
初めて見るC#の記法に戸惑い、初期の段階では「何がどう動いているのか」が全く分からない状況でした。

具体的にC#を読み解くのに大変だったポイントをお話しします。

今回私が見ていたのは、.NETベースのWindowsフォームアプリケーションのC#コードでした。

1．書き方の考え方が違う

JavaScriptやReactでは、小さな部品（コンポーネント）を組み合わせたり、関数を使ってプログラムを作ります。しかし、C#のWinFormsでは「クラス」という大きなまとまりでプログラムを書きます。クラスは複雑なデータや処理をまとめることができ、大規模なアプリケーションを作るのに便利ですが、最初は理解するのに苦労しました。

public partial class MainForm : Form

{

    private string status = "";

    private bool isValid = false;

    // 状態をクラス内で一元管理

}

2．UIをプログラムから直接変更する

Reactではデータが変化すると自動で画面が更新されますが、WinFormsでは画面の更新を自分でコードに書く必要があります。例えば、読み込み中の表示やボタンの有効・無効などをすべて手動で制御する必要があります。その影響で、読み解くコードの量が多かったり、見落としてしまうこともありました。

private async void LoadDataAsync()

{

    loadingSpinner.Visible = true;

    await Task.Delay(2000); // 2秒待つ非同期処理

    loadingSpinner.Visible = false;

}

3．UI（画面）の作り方が違う

Reactは画面を部品として組み立て、状態が変わると画面が再描画されます。一方、WinFormsではボタンやラベルなどをプログラムから直接操作します。ボタンが押されたときの動作などもコードで指定し、UI要素一つ一つにイベントが割り当てられており、読み解くのに時間がかかっていました。

private void buttonSave_Click(object sender, EventArgs e)

{

    MessageBox.Show("保存しました！");

}

４．大きなクラスで管理する

WinFormsでは、多くの処理を一つの大きなクラスにまとめることが多くあります。これにより一見すると分かりやすく見えるかもしれませんが、コード量が増えると修正や変更が難しくなります。この部分が一番苦労した点で、一つのファイルに数千行ものコードが書かれている場合もあり、かなり手間がかかりました。Reactのように機能ごとに分割して管理する考え方とは大きく異なります。

public partial class MainForm : Form

{

    // 数千行ものコードが書かれていることもありました。

}

初めのうちは、何度も間違えてはコードを読み返す、ということの繰り返しでした。まず1つの機能に対して実装を試み、それをレビューしてもらい、実際に動かしながらチェックする動作レビューを行いました。不具合があれば修正を加え、また動かしてバグを見つけて潰していく。これを何度も繰り返しました。

この過程を経て、ようやくC#のコードが徐々に理解できるようになり、余裕が出てきたのは1ヶ月半から2ヶ月が経った頃でした。

また、他の画面との繋ぎ込みのタイミングで新たな不足点が見つかることもありました。その都度修正しながら学びを積み重ね、次第にスムーズにコードを読み解けるようになっていきました。

「分からない」を「分かる」へと変えるためには、粘り強く取り組む姿勢が重要だと学びました。

最大の壁：エラーとの戦い

案件を通して最も苦労したのは、エラー対応でした。
ビルドエラー、ランタイムエラー、Gitのコンフリクト解消など、開発中にはさまざまなエラーが発生しました。エラー解決のためにネットで検索したりAIに質問したりするものの、うまくいかないことも多く、何度も壁にぶつかりました。

そこで、試行錯誤を重ねる中で効果的だったエラー解決の方法を以下にまとめました。なるべく具体的にまとめてみたので、今まさに壁にぶち当たっているという方はぜひ参考にしてみてください。

エラー解決のアプローチ

1行ずつ原因を追う
エラーの原因が特定できない場合、問題が発生する直前の状態までコードを遡ります。特にビルドエラーでは、差分を細かく確認することで原因を特定できました。
- 例）Gitのfile historyで過去の状態を確認し、変更点を比較する。
変数や型を丁寧に確認する
エラーが特定の変数に関連している場合、その変数の状態（undefinedやnullなど）や型の　不整合を重点的に調査しました。
別のアプローチを試す
特定の方法でうまく動かない場合は、別の実装方法を試みる柔軟さも大切です。
同様のコードを参考にする
プロジェクト内で似たような実装例を探し、それを手がかりに問題解決を進めました。
休息を取る
行き詰まったときは、一旦手を止めて頭をリフレッシュしたり別の作業を行うことで、新たな視点が得られることが何度もありました。