私の体験記になりますが、業務システム系のSESやSIで勤務していた方や未経験者向けにWeb系エンジニア(自社サービスのエンジニア)の仕事内容を記載します。中規模や大規模な新機能・改修タスクはスプリント計画などで計画され、実際の業務タスクはRedmineやJira、gitなどで管理されているタスクチケットに分かれて、そのチケットを自分に割り当てたり、指示されて実行していく流れになります。・業務ロジックの変更などです。APIの新規作成や改修などです。要件は決まっているが、実装となると細かい仕様が決まっていない場合があります。その場合は他部署の方と直接コミュニケーションを行い細かい点を決めていく必要があり、適時他部署や複数人とコミュニケーションを行う事が必要になります。この際に相手のシステム理解度やリテラシーに合致した聞き方や話し方をしないとコミュニケーションの齟齬が発生するので、適度なコミュニケーション能力は必要だったりします。PMやディレクターを介して確認するといった方法もありますが、当事者同士で話した方が早い事などは当事者同士てやりとりした方が、全員にメリットがある為この他部署とのコミュニケーションは回避できません。実装を考えてコーディングする実際のチケット内容を実装していきます。自社サービスの会社でも新機能追加よりは既存の機能改修の方が多く、コーディングしている時間は少ないです機能改修の場合は自分のチケットの対応する機能をコードから見つけていき、自分の改修する必要のある部分へ変更を加えます。上記から機能改修の場合は、コードを見ている時間が9割でコーディングは1割程度です。エラーやバグ改修の場合は、発生するエラーメッセージや現象から原因を特定していきます。この場合はエラーメッセージを1日中ググり続けたり、1日中同じエラーメッセージを見続けるなどといった事も普通に発生します。hubへpushしたチケットは、必ず同じチームの他者がコードレビューを実行してくれました。私がSESで業務系のシステム開発をしていた際には、このコードレビューは中々ありませんでしたが、コード開発をする際にコードレビューはかなり有り難いです。いうとコードを実装した際に・もっと簡単な書き方があるか・もっと分かりやすい変数名があるか・共通化できる処理はないかなどは指摘やアドバイスをもらわないと、中々気づけなかったりするので、また、もちろん自身が他人のコードレビューを実行する事もあるので、他者にレビューを実行する事によって気づきもあったりします。このレビューはかなり必要だと感じていますし、転職や就職する際にはコードレビューが実行されているか、確認する事をお勧めします。設計書は存在する紙では無いですが、CMSやレッドマインなど実装前の設計内容や実装後に実装内容を残すことはあります。自社サービスでも運営期間が長くなると、過去の実装内容と照らし合わせて改修しなければならず、そうなるとコードを見る前に過去や現在の設計書などを各員んした現在の毎実装毎に設計書などのドキュメント更新は必要になってきます。その為自身が行ったコーディングの内容も設計書に反映する必要があります。テストコードは必ず実装されるテストコードは必ず実装していました。実装レベルは単体テストから簡単なロジックチェックだけのレベルで様々でしたが中堅以上の企業ではテストコードを書かないといった事はありませんでした。機能自体を消去するので、テストコードを書かずに実装する場合もあります。