はじめに
お世話になっております！
この度転職を経て、今までと少し異なった環境で働くこととなりました。
そこで、予め今までのマインドセットからの切り替えを行うべく、このような記事を投稿しております！
🔁 1. 意識すべきマインドの変化
-
成果の「納品」よりも、「継続的価値提供」が重要
- SESでは成果物納品がゴール → 自社ではユーザー価値の継続的向上がゴール。
-
「お客様目線」から「ユーザー目線」へ
- 発注元ではなく、最終ユーザーにとっての価値を考える姿勢が必要。
-
「仕様をこなす」から「仕様を考える・提案する」へ
- 上流工程やプロダクト企画にも関与する機会がある。
2. 開発スタイルの違いを理解する
-
ウォーターフォール → アジャイル開発への適応
- スクラム・カンバンなど、短サイクルでの開発と改善が主流。
-
長期運用・改善を前提とした設計が求められる
- 一発納品で終わらず、バグ対応・改善・ユーザーフィードバックがループする。
-
自分の書いたコードが"運用され続ける"責任を持つ
- 技術的負債への配慮、保守性・拡張性が重要。
3. 期待される役割の変化
| SES経験者がよくやる業務 | 自社で求められる業務 |
|---|---|
| 仕様書通りに開発 | 仕様の提案・調整 |
| 言われた技術で実装 | 技術選定・調査 |
| テスト工程に参加 | 自動テスト・CI/CD運用 |
| チーム内で黙々作業 | チームと協力・フィードバック文化 |
| 納期重視で開発 | UX・価値重視で改善重視 |
4. 技術以外で身につけたいこと
-
プロダクト視点
- 何を作るか、なぜ作るかを考えられる視座。
-
コミュニケーション能力
- PM・デザイナー・CSチームとの連携も発生。
-
ドキュメンテーション力
- コード以外の仕様・技術的意思決定も記録・共有。
-
ユーザー志向
- 「自分が作りたいもの」ではなく「ユーザーに喜ばれるもの」を意識。
5. キャリアアップの視点
-
スペシャリスト／ゼネラリスト、両方の道がある
- 技術を極める or プロダクトマネジメントを目指すかの選択。
-
副業・OSS参加なども経験価値に直結
- 自社内での実績だけでなく、外部貢献も評価されやすい。
-
「プロダクトの成果＝自分の成果」になる環境
- 成果へのコミットは報酬・役職にもつながりやすい。
⚠️ 6. ありそうなミスとその対策
| よくあるミス | 原因 | 対策 |
|---|---|---|
| 言われたことしかやらない | 指示待ちマインドが残っている | 「なぜやるのか」を考え、課題提案・改善の意識を持つ |
| 技術的に最短・最速の実装だけを選びがち | 短期納期を前提とした経験 | 中長期の運用・保守を見越した設計やリファクタリングを重視 |
| ドキュメントや設計を軽視する | SESでは完成すればOKな風潮が多い | 他の開発者や未来の自分のために「残す」意識を持つ |
| 「自社サービス＝楽そう」という誤解 | 客先常駐より働きやすそうな印象 | 目的達成のために裁量と責任が増えることを理解しておく |
| 仕様の不明点を放置する | 客先案件では仕様は固めてから始まる | 不明点は積極的に聞き、整理して共有する習慣をつける |
| プロダクト視点を持たず「実装タスク消化」になりがち | システム受託型の開発フローに慣れている | 「この機能は誰のため？どんな価値がある？」を常に自問する |
| フィードバックを避ける／受け身になる | 現場での上下関係や評価文化に慣れすぎ | フラットな意見交換を歓迎し、技術レビューを成長機会と捉える |
| ユーザーを意識せずUI/UXを適当に作る | エンドユーザーと直接関わらない環境に慣れている | 自分がユーザーだったらどう感じるか？と常に想像する習慣を |
最後に
自社サービスの開発は、SESのときとかなり勝手が違います。
納品が目的ではなく、リリース後の改善やユーザーの反応までを含めて仕事になります。
「終わらせる」よりも、「育てていく」ことが求められる印象です。
正解が決まっていないことも多く、仕様が曖昧なまま進むこともあります。
最初は戸惑うと思いますが、それは自然なことだと受け止めておきたいです。
ご覧いただきありがとうございました！