SESで「コードを書く以外」に求められたこと

はじめに

SES（システムエンジニアリングサービス）で働き始めた頃、私はかなり単純に考えていました。

「エンジニアなんだから、コードを書ければ評価されるだろう」

と。

もちろん、技術力は重要です。

ただ、実際に現場へ入って感じたのは、SESでは“コードを書く以外”にもかなり多くのことが求められるということでした。

特に実務では、

• コミュニケーション
• 調整
• ドキュメント
• レビュー
• 障害対応
• 運用
• 引き継ぎ

など、想像以上に「人と仕事を進める力」が必要になります。

今回は、実際にSESの現場で経験した「コード以外で求められたこと」について書いてみたいと思います。

コードを書くだけでは仕事が進まない

最初に驚いたのは、「実装だけしていても仕事は終わらない」ということでした。

例えば、新機能を作る場合でも、

• 要件確認
• 仕様認識合わせ
• 影響範囲調査
• 他機能との整合性確認
• レビュー依頼
• リリース調整

など、多くの工程があります。

実際の作業時間で見ると、純粋にコードを書いている時間は思ったより少ないです。

特に大規模案件では、自分だけで完結する作業はほぼありません。

誰かと連携しながら進める必要があります。

私は最初、

「コードを書いてPull Requestを出せば終わり」

くらいの感覚でした。

しかし実際には、

「その変更で他機能に影響ない？」
「運用チームへの連携必要？」
「監視設定変更いる？」
「リリース手順更新した？」

など、周辺作業がかなり多かったです。

「報連相」は想像以上に重要だった

正直、入社前は「報連相」という言葉に少し古臭いイメージを持っていました。

ただ、実務ではかなり重要でした。

例えば、作業遅延が発生した場合。

初心者の頃は、

「なんとか自分で解決してから報告しよう」

と思っていました。

しかしこれ、実務では逆に危険なことがあります。

特に障害やリリースが絡むと、

• いつ気づいたか
• どこまで影響あるか
• 今どういう状態か

を早く共有する方が重要です。

実際、経験のある人ほど、

「まず共有しよう」

という動きが早かったです。

逆に情報共有が遅れると、

• 周囲が動けない
• 別チーム調整できない
• 障害範囲が広がる

など、問題が大きくなりやすいと感じました。

これはかなり実務で学んだ部分です。

ドキュメントを書く力が必要だった

これも意外でした。

私は最初、

「エンジニアはコードで語る仕事」

だと思っていました。

しかし現場では、むしろ文章を書く機会がかなり多いです。

例えば、

• 設計書
• 手順書
• 障害報告
• 調査結果
• レビューコメント
• リリース資料

などです。

特にSESでは、案件途中でメンバーが入れ替わることも多いです。

そのため、

「他人が見て分かる」

ことがかなり重要になります。

実際、自分しか理解できない構成になっていると、後からかなり困ります。

私自身も引き継ぎ時に、

「これ何をしている処理なんだ…」

となった経験が何度もありました。

逆に、分かりやすい資料を書く人はかなり信頼されていました。

障害対応では“冷静さ”が求められる

実務で特に印象に残っているのが障害対応です。

システム障害が起きると、現場の空気が一気に変わります。

• エラー調査
• ログ確認
• 原因切り分け
• 影響範囲確認
• 暫定対応
• 状況報告

などを短時間で進める必要があります。

最初の頃はかなり焦りました。

特に、

「自分の修正が原因だったらどうしよう」

というプレッシャーは大きかったです。

ただ、経験を積む中で感じたのは、

「まず状況整理する」

ことの重要性でした。

慌てて修正すると、逆に悪化することもあります。

実際、冷静にログや監視を確認しながら進める人ほど、結果的に対応が早いことが多かったです。

技術力だけでは評価されない

これはSESに限らずですが、実務では技術力だけで評価が決まるわけではありません。

もちろん技術は大事です。

ただ、それ以外にも、

• 周囲との連携
• 相談しやすさ
• 進捗共有
• レビューの丁寧さ
• ドキュメント品質
• 安定した対応

などもかなり見られています。

実際、現場で信頼されている人は、

「この人に任せれば安心」

と思われている人でした。

逆に、技術力が高くても、

• 連絡が遅い
• 周囲と連携しない
• 属人化する

と、現場全体では動きづらくなります。

このあたりは、実際に現場に入って初めて実感しました。

まとめ

SESで働く前は、

「エンジニア = コードを書く仕事」

というイメージを持っていました。

しかし実際には、

• 調整
• 報告
• ドキュメント
• 障害対応
• 引き継ぎ
• レビュー

など、“コード以外”の仕事がかなり多いです。

最初は戸惑うこともありました。

ただ、これらを経験したことで、

「システムを動かす仕事は、実装だけでは成立しない」

ということを強く感じました。

特にSESでは、様々な会社・立場の人と関わりながら仕事を進めます。

そのため、技術力だけでなく、

「周囲と協力して進める力」

もかなり重要だと思っています。

これからSESへ入る方がいれば、ぜひ「コードを書く力」だけでなく、「仕事を進める力」も意識してみてほしいです。