1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

米田です。
この記事では、エンジニア1年目の業務を振り返りながら、学んだこと・感じたことを書いてみようと思います!

1年の振り返り

4~5月 Java研修(座学)

担当フェーズ
・要件定義
・設計/開発
・進捗管理

4名チームでシステム開発を行う研修でした。
私はプロジェクトリーダーとして、タスクの振り分けや進捗管理を担当し、チームをまとめる役割を担いました。

苦労した点
それまで個人開発が中心だった私にとって、チーム開発は思った以上に難しかったです。特に、設計における認識合わせや、メンバーのスキルに合わせたタスク振り分けに多くの時間を取られました。
また、メンバー間で設計や進捗に関する認識のズレがあり、出来姿が想定と違う! といった場面も多々ありました。

対応策と改善
そこで、共有スプレッドシートを作成し、設計書やQ&A、メンバーごとのWBSを一元管理しました。
これにより、各自の情報が整理され、認識のズレを減らすことができました。
また、WBSの導入も開発効率向上に大きく貢献しました。
進捗を可視化できるようになり、遅れを速やかに発見できるようになったため、メンバーごとの負担調整やスキルに応じたタスク再分配がスムーズに行えるようになりました。

学んだ点
・認識合わせは丁寧に行う
メンバーによって、前提知識や考え方が異なります。
認識相違は後で大きなトラブルに繋がることがあるため、丁寧な情報共有やこまめな会議が大事だと実感しました。
・困ったらすぐアラートを
手が止まったり、進捗が遅れる原因が出てきた場合は、すぐに報告することが非常に重要だと学びました。遅れの報告はしづらいですが、遅れが大きくなる前に状況を報告することで、チーム全体で助け合いやタスク調整ができ、早期解決に繋がることを実感しました。
・報告しやすい環境づくりを
定例会議や積極的な声掛けを通じて、報告や相談をしやすい環境を作ることが大切だと感じました。作業は個人個人で行いますが、コミュニケーションを取ることで、より良いものを作れると学びました。

6月~ 現場配属!!

担当フェーズ
・開発(実装~単体/結合テスト)
・テスト(ケース検討・作成・打鍵)
・障害調査(ログ/DBからの調査)
・手順書作成
・リリース作業

ついに現場配属!
保険の契約管理システムの運用保守チームに配属され、打鍵作業を任されました。
配属当初は、業務の合間にプロジェクト計画書や設計書をひたすら読み込んで、全体像の把握に必死でした(笑)。
会議でも保険の業界用語が飛び交い、わからない言葉をわからない言葉で説明されるのでずっと混乱していました(笑)。
半年たった今では理解できるようになりましたが、まだ見ぬ後輩のため、オリジナル用語辞書を作成しておきました。

意識したこと
・業務の背景を理解する
当初は、ケース仕様書どおりに打鍵する作業のみの担当でした。
ただ取り組むのではなく、「どの機能をテストしたいのか」「この打鍵によってDBの出来姿はどのようになるのか」等、少しでも多くのことを学ぼうと意識し、仕様書やソースと照らし合わせながらたくさん実験しました。
すると、だんだん構造がわかってくるようになります。
7月頃からは、ケースを連携いただく前に自分で考えてみて本物と比べる、といった練習をひたすらしていました。その姿勢を評価いただき、徐々にケース検討や障害調査を振っていただけるようになりました。初めて任せていただいた日はとにかく嬉しかったです(笑)。
テスト結果が想定と異なる場合にDBやログを取得して、ケースが間違えているのか、仕様が想定と異なるのか、実装不備かといった切り分けができるようになりました。その結果、メンバーの負担を減らすことができ、チームとしての作業効率も大きく向上しました。
コーディングも、「どんな障害が起きたのか」「どうしてこの設計なのか」を確認してから取り組むことを意識しています。
最近では、設計の不備に気付いて改善案を出せるようになってきました。
わかることが増えてくると、成長を実感できてすごくやりがいを感じます!

・報連相の徹底
チームに迷惑をかけぬよう、報連相はとにかく徹底して行いました。
タスクを振っていただいた際は、期限日とその業務の有識者の確認を必ず行っています。朝夕の報告のほか、遅れていなくても定期的に進捗を共有することで、状況を把握いただけるよう心がけています。一人で抱え込むことがなくなるので、精神的な負担を減らせることもメリットかなと思います。
相談をする際も、様々な工夫をしました。
困りごとは基本的に案件に依存するものだったため、相談時に案件の概要から説明する必要があります。なるべく相手の時間を奪わないよう、要点を資料にまとめ、不明点を明確にしてから相談する癖をつけました。
この習慣を通じて、要点を整理する力や相手の立場に立って情報を整理する力が身についたと感じています。
・積極的にコミュニケーションを取る
配属当初、仕事中の会話はあまりなく、あったとしても朝の会議を聞くのみ。配属当初は「見て学ぶ」ことが仕事だったため、一日中誰とも話さない日もありました。
また、現場の新人は私のみで、メンバーはベテランの方ばかりだったため、なかなかチームに馴染めずにいました。
そこで、業務関連の新しいことをどんどん学んで不明点を見つけ、積極的に質問をしました。メンバーの担当案件から得意分野を探り、詳しそうな方に質問するよう心がけました。そこから皆さんがどんな方なのかを知ることができ、相談もしやすくなりました。忙しい中で親切に教えてくださり、チームの皆さんには感謝の気持ちでいっぱいです。

2025年の目標

担当領域をさらに広げる!
これまで担当してきた実装案件は、主に100ステップ程度の小規模なものが中心でしたが、これからはより大規模な実装案件に挑戦し、担当できる領域を広げていきたいです。この目標を上半期の目標として設定し、開発力を向上していきたいです。
また、実装だけでなく、設計工程にも挑戦し、設計における経験を積んでいきたいと考えています。これを達成するために、詳細設計のフェーズにも関わり、実際のプロジェクトで設計書を作成する経験を積みたいと考えています。

paiza Aランク取得!
上記の目標達成のためにも、実装スキル向上は必須だと感じています。
現在Bランクを取得できていますが、体感的なスキルはcランクレベルです。
まずはBランクの設計実装をこなせるようにすることを上半期の目標とし、今年中にAランクを取得したいです!

まとめ

初年度ということもあり、とにかく学びの1年でした。
親切にしてくださったチームの皆さんに、あらためて感謝です。
まだまだ成長の途中ですが、よりチームに貢献しエンジニアとして成長できるよう、引き続き頑張っていきます!

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?