AWSエンジニアがきつい・つらいと感じた時

答えのわからない調査系のタスクが多いことです。障害調査や運用上の改善調査などがありますが、そのどれもが解決策が提示されているものではありません。

そもそも、それに解決策があるのかどうかも、調査してみないとわかりません。

また、調査して自分なりの解決策を見つけたとしても、先輩に報告した際に手順が複雑すぎる、管理し続けないため不可、などダメ出しがきます。

ただ解決策を考えるのではなく、コスト・手間・管理のしやすさなど他の点もクリアして初めて調査完了となるので知識も必要で、難しいと感じています。

1日のスケジュール例

1. 10:00
   始業（リモート勤務）
2. 10:00
   事務作業・メール確認
3. 11:00
   作業（調査・手順書作成など）
4. 13:00
   昼食
5. 14:00
   会議（打ち合わせ・作業期限確認等）
6. 15:00
   作業（調査・手順書作成など。リリース作業等も行うが、曜日が固定）
7. 17:30
   会議（業務内容報告・共有事項確認・質問）
8. 18:30
   退勤

AWSエンジニアがきつい・つらいと感じた時

スタートアップでもシード時期であり、その中で自社サービスを運用している状況でした。自分が入社した当時に当時の副業の人から引き継ぎを行い、運用のエンジニア負荷が高い状況でありました。

一人インフラエンジニアというような環境だったため基本的に24時間365日の運用を一人で回さなければ行けない状況が長い時間続き、眠りが浅くなる日が多くなってしまいました。また、採用も小さい会社だったので、他者に任せているとうまくいかずに自分でも採用のスカウトを行う必要があったり、サービス開発もしなければいけなかったりと自身にかかる負荷が非常に高かったです。

1日のスケジュール例

1. 10:00
   リモート始業・デイリースクラム
2. 10:30
   作業開始
3. 14:00
   昼食
4. 15:00
   昼休み終了、作業再開
5. 17:00
   夕会, 1on1
6. 18:30
   退勤

AWSエンジニアがきつい・つらいと感じた時

サーバに不具合が発生した際、不具合が解消するまで帰ることができませんでした。また、私が勤めていた時はちょうどVMwareからAWSへ移行する期間であったので、これまでのノウハウが無く、自力で何とかしなければいけない状況が常に続いていたことがつらかったです。

また、クライアントから工数の削減を迫られていたため、夜遅くまで仕事をすると「なんでこんな時間までかかっているの？」と詰められることがよくあり、かなり苦しかったです。

1日のスケジュール例

1. 8:45
   出社
2. 9:00
   始業・朝礼
3. 9:15
   業務開始・事務作業
4. 10:00
   システム変更作業
5. 12:00
   昼食
6. 13:00
   システム変更作業
7. 14:00
   作業書作成
8. 17:00
   ミーティング
9. 18:00
   事務作業
10. 20:00
    退勤