こんにちは。
2024年卒の稲永然です。

入社から1年が経ち、4月1日には2025年度入社の新しいエンジニアたちがたくさん入社しました。
彼らに先輩らしい振る舞いができるか、少し不安に思うこともあります。

そこで、この1年間で私がどんな課題に直面して、どのように解決したのか。
それを自分自身で振り返るため、
そして、このブログを通じて誰かの助けになればと思い、
筆、もといキーボードを手に取りました。

1年間の振り返り

大雑把に24年度の自分の所属を見直すと、

新卒研修
既存システムの運用保守
新規webシステム開発

と、大きく3つに分けられます。
入社後2ヶ月間は研修を受け、
6月に部署に配属され、既存案件にアサインされました。
その後しばらくたって、新規案件に移行しました。

この1年間での課題とその解決策についてまとめていきます。

学生時代のプログラミング経験による同期との技術差

入社当初、私は機械系出身でプログラミングの基礎をほとんど知らず、
情報系出身の同期に比べ技術も劣っていました。
そのような中で私が重視したポイントは以下の2点です

1. 技術研修で多くの技術をインプットし、実装とレビューを積極的に受けること

新卒、ましてや研修なので、間違い覚悟で積極的に実装してみましょう
研修だから、簡単なことだから、適当に済ませるのではなく、
研修だから、簡単なことだからこそ、色々な手法を試して、先輩や同期からレビューを受け、自分の知識として取り込んでいくべきだと思います。

私は、その努力をある先輩に見つけていただき、基礎から細かいところまでレビューをしていただくことができました。
そこで得た開発知識は、今も有効活用できています。

2. 自分の考えや実装の過程を可視化すること

作業を止めて難しいことを考えていたとしても、それをアウトプットしていなければ、ただ作業していない人に見えてしまいます。
また、自分の考えを文字に起こすことで、自分で文章にする中で何かに気づくこと、それを見た周りの人からアドバイスや指摘を受けることもあります。
自分の考えが、誰かの悩みを解決することすらあり得ます。
このブログすら、私が自分の1年間を振り返り、その中での思考を文章に起こしているわけですから...

タスクがない（回ってこない）

これは配属先などによると思いますが、新卒の多くが直面する課題かもしれません、と感じます。
ここで、私はタスクを貰いに行く、タスクを作りに行く手法を取りました。
タスクをこなしていくうちに、任せても安心と思われるようになりました

1. 周りを見ること

上に、同期や先輩に見える箇所で自分の考えや思考を開示した方が良い。と書きましたが、
逆の立場で、自分に見える箇所での同期や先輩の発言を見ていきましょう。

　・複数のタスクを抱え、その中に自分でもできそうなタスクを持っている人がいるかもしれません。
　・やる余裕はないけど、この作業がしてあると今後楽になるなと嘆いている人がいるかもしれません。
　・定例の報告で、作業過多で止めているタスクを持っている人がいるかもしれません。
　・周りから見るとわかる凡ミスに、気づかないまま作業をしている人がいるかもしれません。
　そこに、自分のできることはありませんか？

　ただし、自分にタスクを任せてもらうということは、
　自分が作業に慣れるまでは、指導や監督をする。といったタスクをその人に課してしまうことでもあります。
　それを決して忘れてはいけません。

2. タスクを受け入れられることをアピールすること

　自分がタスクを受け入れられることをアピールしましょう。
　発言はしていないが、任せられるタスクを抱えている人がいるかもしれません。

　私は、Slack上に「タスク受入可能」と赤文字で書かれたリアクションを作成して自分の作業スレッドにリアクションをつけておき、
　定例MTGの最後に手空いています。と発言していました。

3. 自分の長所や特技をアピールすること

　まるで、面接対策のような項目名ですが、あながち間違いでもありません。
　面接で話すような自分の長所や特技を、自分がどんなタスクに向いているのかを、どんな技術を持っているのかを、
　少しずつアピールしていきましょう。
　それは雑談の中でも構いませんし、タスクをこなす中でも構いません。
　また、タスクをこなす中で長所を、得意なことを見つけたのなら、それもアピールしていきましょう。

　私は、学生時代に学生会でOfficeを使った書類作成や会計管理をやっていたので、
　それをアピールすることで、資料作成や、Excelを用いた調査用のツールを作成など、特技を活かしたタスクを貰えるようになりました。
　※Excel関数を利用した記事（業務で使えるExcel関数テクニック − 関数を使った動的な範囲指定のコツ）も書いているのでよければご覧ください。

チーム開発がわからない

詳細は省きますが、この1年の後半はWebシステム開発の案件にアサインされ、
開発経験の浅い4名が開発の主軸となりました。

そこで私は、システム化を行う業務への理解から始まり、設計、開発、クライアントとの調整、納品、と。
開発の始まりから終わりまで、実質的な開発管理を行いました。

1. 設計がわからない

設計がわかりません。まともにやったことなどありません。
初めから難しい課題ですね。
でも、正しい開発設計など、きちんと学んですらいないし、きちんと学ぶ時間的余裕もありませんでした。

1.1. 業務フローの作成から機能・画面一覧へ

まず、全ての関連資料を読み漁り、業務フローを作成しました。
次に、作業者ごとに業務を分割し、具体的な業務イメージを脳内に構築します。
システム化前後の業務フローを比較して、必要な機能と画面の一覧を作成し、
この一覧を基に、チームで意見を出し合い、設計を進めます。
進行中は、チームのレビューを受けつつ、自分の考えを文字で記録していました。

1.2. ワイヤーフレームから画面デザインへ

脳内で構築した業務イメージと機能・画面一覧を基にワイヤーフレームを作成し、システムの構造を視覚化しました。
各画面が完成するごとに必要なコンポーネントを開発を依頼し、設計と開発を同時進行で効率的に進めました。
デザインは後回しにし、先に全体のフレームを固めることで、開発の手が止まらないように工夫しました。

そこから、デザイン性を考えつつ、ワイヤーフレームから画面デザインに起こしますが、
画面デザインは研修で触った程度で、ツールの操作程度しかわかっていませんでした。

しかし、ここで私の学生時代の経験が活きました。
ここまで脳内で空想だったものを、現実の図面として起こしていく。
機械科出身の私は、CAD(Computer-Aided Design)で図面を作っていた経験を活かすことができました。
"素材"を用いた実物の設計も、"機能"を用いたシステムの設計も、実態としては似たものだと気付きました。

部品(コンポーネント)を作って、組み立てる(画面に配置する)
そうやって、私は脳内イメージだったシステムを視覚化していきました。

2. 開発がわからない

開発がわかりません。まともにやったことなどありません。
大丈夫です。誤って同じところを読んでいるわけではありません。
開発の知識など、研修時のものしかありません。
研修は個人開発を行っていたので、チーム開発の経験などなかったのです。

2.1. ルールを決める

開発前にチームで厳格なルールを設定し、コードの一貫性とシステムの品質向上を図りました。

厳格なルールには、ルールに縛られ、思ったように実装が進まない可能性がありましたが、
小規模な4名のチームでは、ルールが合わなければ容易に変更できる柔軟性があったため、この方針を取ることにしました。

命名規則（英語名の命名）や関数の書き方。記法の順番や、コメント・サマリの入れ方。
それらをはじめとして、多くのルールを決めました。

また、開発の人員4名を2:2でフロントエンドとバックエンドの開発に分け、
PRのマージには2名のレビューを必須とし、スピードと品質のバランスを取ることを重視しました

2.2. 最初こそ厳しいレビューを

最初のころのPRへのレビューは、最初だからこそ厳しく行い、
ルールの遵守やコードの一貫性、適切なサマリの確認を徹底しました。

必要なルールは即座に追加し、基礎を固めることで後の問題を防ぐ方針を取りました。

3. 開発管理がわからない

開発管理がわかりません。まともにどころかやったことがあるわけありません。
正解があるものではないと思いますが、一つの正解の形もわかりません。
ただ、自分の案件は取りあえずはうまくことを進められた自信はあります。

3.1. 案件全体を把握する

開発状況を把握するため、ほぼすべてのPRにレビューし、作業が見えない人の状況を確認、必要に応じてMTGを開催して問題解決を図りました。
また、少人数開発のため、定例MTGは必要時のみ開催し、効率を重視しました。

そして、把握漏れが起こらないように、全ての関連MTGに参加し、案件全体を把握することを心掛けました。
理解できない話も多くあり、知識不足を感じつつも、自分が全体を理解する必要があると考え、努力しました。

3.2. 手を止めない環境作り

作業の停滞を防ぐよう努めました。
クライアント会議での対応事項は即座に要点をまとめ、可能な箇所から開発チームに伝達して作業を開始できるようにしました。
案件全体を把握し、必要な情報を適切なタイミングで共有することを常に心掛けていました。

3.3. 自信を持つ

開発管理者は方針を決める先導役ですが、自身を持たず、ネガティブだとメンバーに不安を与えます。
そのため、自信を持って、安心感を提供することが重要です。

ただし、先導役の選択に対して指摘できないような環境も良くありません。
間違うなら一緒に間違った方が良いですが、そもそも間違える前に気づいた人が指摘できるような環境が最も好ましいです。

私の場合は、開発メンバーが同期で、数ヵ月共に仕事をしてきた。という前提に救われていたとは思います。

チーム開発がわからない　小まとめ

正直、やっている間は必死に動いていただけだったので、理論的に動けていたとは言い切れません。
ただ、落ち着いて整理してみると、きっと私はこのように考えて動いていたのだと思います。

慣れない開発管理でとても大変でしたが、簡単にはできない良い経験を得られました。

その一方で、杜撰な開発管理についてきてくれた、開発メンバーには頭も上がりません。
先の見えない二択の道で、私が直感で選んだ道を信じて、何度もついてきてくれたようなものですから...