SESでしか得られない、設計者の適応力とは
はじめに
私はこれまで、プロパー（正社員）としても、SES（客先常駐）としても働いてきました。
いま振り返ると、「設計者としての基盤」が本当に鍛えられたのはSES時代だったと断言できます。
なぜSESなのか？
なぜあの環境でしか得られないものがあったのか？
SESという働き方に対して、どこか「スキルがつかない」といった印象を持つ方もいるかもしれません。
ですが私にとっては、むしろ設計者としての適応力を獲得する場だったように思います。
この記事では、そんな「SESでしか得られない力」について、自身の経験をもとに記録しておきます。
1. 初期状態は「無知・無力・無信頼」
SESでの現場入りは、例外なく "ゼロベース"の戦い です。
- 知らない業務
- 見慣れないコード
- 開発フローもツールも異なる
- 資料が古いか、そもそも存在しない
この中で、何が求められているかを自分で察知し、形にし、信頼を勝ち取る。
このサバイバルの中にこそ、"設計者の適応力"の種がありました。
2. 適応とは、環境に合わせることではない
ここで言う「適応力」は、ただの従属ではありません。
- 要件が曖昧なら、逆に問いを立てて構造を仮設する
- 現場文化に流されるのではなく、その構造的癖を理解し、翻訳する
- 抽象度が合わない会話を、設計やフローの言語に置き換える
つまり、適応とは 環境を読み解き、設計者として"再定義"できる能力 です。
3. 現場事例：私を育てた5つの案件
・車両管理の業務案件
初期は専門用語が分からず、データ構造の全体像も掴めなかったが、業務フローを起点に構造を立て直し、現場での設計に昇華。後に「どうやってこの構造を思いついたんですか？」と驚かれる。
・設備レイアウト同期案件
クラウドとWebアプリでの位置情報同期において、通信障害などの例外系も含めた設計を提示。期待されていたレベルを超える対応力を評価された。
・マルチプラットフォームUI移植案件
ゲームアプリの構造をネイティブアーキテクチャにマッピング。コードレベルではなく、「構造レベルで翻訳する」という経験が得られた。
・エッジ⇄クラウド通信設計
クラウド側の通信ロジックにデザインパターン（Factory）を導入。設計と拡張性の両立を自ら示し、チームのベースラインに組み込まれた。
・データベース構造設計案件
現場で混乱していたDB構造に対し、「業務フローから導出される多重度と正規化／非正規化のトレードオフ」で説得力のある再設計を実施。現場に即した"納得できる構造"が信頼を得た。
4. なぜSESでしか得られないのか？
それは「責任の不在と信頼の不確実性」が同時に存在するからです。
- プロパーでは「前提が保証」されることが多い
- SESでは「前提が曖昧 or 変動的」であることが多い
この状況で生き残るためには、設計者として前提を読む力、補う力が必須です。
そしてそれは、現場で鍛えられるしかない力なのです。
5. 適応力とは、設計者の人間力である
結局、設計とは「問いにどう答えるか」です。
SES現場ではその問いが絶え間なく、しかも構造化されずにやってくる。
その中で磨かれるのが、「再定義する力」「翻訳する力」「意図を読み取る力」。
これらは、設計者としての応答性であり、人間力です。
おわりに
SESは、決して華やかなキャリアではありません。
ですが、私はこの環境で「設計者としての足腰」を鍛えられたと本気で思っています。
もし、環境適応型の設計者になりたいなら、SESという選択肢は"本気であり"です。
Discussion