未経験でITエンジニアとして入社してから、約1年。
この頃には、詳細設計から実装までを担当し、ほかの実装者のコードレビューも経験していました。上司からも「できるようになってきている」という話があり、自分でも**「まあまあできるかな」**と思っていた時期です。
そんな中で別の案件を経験し、終わったあとには「結構できるかもしれない」と感じるようになりました。
何か一つの技術が使えるようになったから、という感覚ではありません。
それまで担当していなかった基本設計に関わり、要件から仕様を考え、自分が作った設計を別のエンジニアへ渡すところまで経験した。その一連の仕事を振り返ったときの感覚でした。
今回は、そこに至るまでにどんな仕事を経験したのかを書いてみます。
入社直後に最初に担当した仕事については、別の記事で書いています。
別の案件も経験してみたいと相談した
今回の案件へ移ったのは、自分から「そろそろ別の案件も経験してみたい」と相談したことがきっかけでした。
当時は、所属しているユニットのリーダーと毎月1対1で面談する機会がありました。そこで別の案件も経験してみたいと伝え、約3か月に1回あったDivリーダーとの面談でも同じ話をしています。
そこから検討してもらい、相談してから約2か月後に別の案件へ移ることになりました。
その頃、「この案件を乗り越えられれば、経験として大きい」という話も聞いていました。
それまで自分が担当していたのは、基本設計ができたあとの詳細設計から実装まで。今回の案件では、要件を受けて仕様を決め、それを設計へ落とすところまで経験することになります。
そういう案件を任せてもらえたことは嬉しかったですし、「頑張りたい」と思っていました。
今回は基本設計から担当した
新しい案件では、PMから「こんなことがやりたいらしい」といった形で要件を受け取り、必要なことを調べ、不明点を確認しながら仕様を決めていきました。
そこから画面やDBの基本設計へ落とすところまでが自分の担当です。
最初から細かい仕様が決まっているわけではないので、自分で考えられる部分もありました。
たとえば画面設計では、導線やボタン、初期値など、使いやすさを良くするための提案もできます。こういう部分を考えるのは「楽しいな」と感じていました。
一方で、関わる人が増えたことで、ややこしく感じる部分もあります。
打ち合わせをしていても、仕様について少しずつ認識がずれていることがありました。
自分で考えられる楽しさがある一方で、複数人で認識を合わせながら仕様を決めていく必要もある。その中で基本設計を進めていきました。
仕様を考え、別のエンジニアへ渡すところまで経験した
仕様の認識がずれた場面の一つが、他システムとの連携を検討していたときです。
打ち合わせの中で、「どのパラメータが欲しいのか」といった部分に認識のずれがありました。
その情報は認証側から取得できるものだったため、追加でパラメータを渡す必要はないと提言しました。この認証で使っていた仕組みがOIDCです。
提言したのは、レビューで指摘を受けたあとではなく、連携方法を検討している初期の段階でした。
その後、OIDCの設計についてリードから具体的なレビュー指摘は0件で、修正も発生していません。
基本設計ができたあとは、実装を担当する別のエンジニアへ渡し、内容を説明しました。特に追加の質問や確認はなく、その設計をもとに実装が進んでいます。
自分が実装するのではなく、自分で考えた基本設計を別のエンジニアへ説明して渡す。これも、この案件で初めて経験したことでした。
実装まで含めて、大きな戻りなく進みました。
案件を終えて「結構できるかもしれない」と感じた
「結構できるかもしれない」と感じたのは、案件の途中に何か一つ大きな出来事があったときではありません。
案件が終わったあと、一連の仕事を振り返ったときでした。
要件を受けて仕様を考え、基本設計に落とし、それを別のエンジニアへ渡す。何か一つができたからというより、こうした経験を一通りできたことを総合して**「結構できるかもしれない」**と感じていました。
この案件で初めて「できる」と思ったわけでもありません。
入る前から「まあまあできるかな」という感覚はありましたが、案件を終えたあとは、そこからもう少し自信が大きくなった感覚に近いです。
とはいえ、「もう何でもできる」というような強い自信ではありませんでした。
当時の感覚をそのまま表すなら、やはり「結構できるかもしれない」が一番近いと思います。
今振り返って、この案件で特に残っているのは、仕様を検討する段階で、不要なパラメータを増やさないよう提言できた経験です。
現在も仕様を整理したり、変更による影響範囲を考えたりするときに、このときの経験は活きています。
コメント