こんばんは！
今日は未経験からエンジニアに転職し、２ヶ月経過した時点での業務内容を簡単に紹介します。
私自身も入社前はエンジニアって実際どんな業務をしているのか結構気になっていたので、参考になれば幸いです。
主な業務内容は、こんな感じです。
- 自分の抱える案件を整理して進める。
- チームで開発している物は定期的に会議があり参加する。
- パートナー様とのやりとりもビデオ会議やGithubを使ってやりとり。
- 終礼で技術部の情報共有。
もう少し深堀しますね。
自分の抱える案件を整理して進める。
今は自社サービスの保守案件が一番多いです。
日々お客さんから受けるサポートやクレーム対応をしている営業さんから、サービスのこういう箇所を改善して欲しいとの声が届きます。
私たちはその内容を洗い出し、営業さんの案を採用して改修する場合もあれば、他の方法も提案し話し合うことで、問題の本質を捉え、解決方法を考えます。
そのやりとりはGithub上で行うことが多いです。
自分の提案が採用された時は素直に嬉しいですね。
修正方針が決まれば、パートナー様（外注）に内容を伝えて見積もりをお願いしたり、自分でコードを書き換えたりします。
自分で修正する場合はネットで解決方法を探りながら、ローカル環境でああでもない、こうでもないと試行錯誤し、完成を目指します。
ローカル環境とは実際のサービスとうり２つのテスト環境を自分のPCに作った物です。
自分で調べて進まない時は、上司に相談します。
最初は聞きすぎるのは良くないかなと思っていたんですが、詰まってうんうん唸るよりも、さっさと相談した方が大抵良い結果になると思うようになりました。
それに聞かれた側も、部下のレベル感や状況が分かるので、どんどん聞いてほしいと言ってくれています。
コードが完成したら、テスト仕様書を作ります。
テスト仕様書は簡単にいうと「今回こういう目的でこういう修正をしたから、ちゃんと動くか確かめてね」って他の人にお願いする物です。
テストの他にも技術部の他の方にレビューをしてもらいます。
本当にその修正方針でいいのか、またテスト内容はそれで漏れがないか、第三者の視点から評価してもらいます。
それが終われば最後にQCチェックと言って、責任者に最終確認をとります。
そこを通過して初めて、実際のサービスに修正内容が追加されるといった具合です。（リリースと言います。）
通常リリースは月末に行います。
そのタイミングで技術部のメンバーがその月に行った改修を一気に反映させるようなイメージです。
なぜ一気にかというと実際に稼働しているサービスですので、改修をリリースするとどうしてもその一瞬は上手くアクセス出来ないといった不具合が出る可能性があるからです。
めっちゃ慎重ですよね。
でも利用者がすごく多いサービスなのでそのくらい慎重に進める必要があります。
今は自分で書いたコードが思ったように動いたり、それが実際のサービスに反映されたりするのを見るのも非常にやりがいがあります。
が、ゆくゆくは実際にコードを書く作業は任せて、より良い修正方法や新機能を考えたりする人材を目指していきます。
少し長くなりそうなので、今日はこの辺で！
2021.1.25 ガオ
コメント