はじめに
受託開発の会社から、事業会社の社内SEに転職して、半年以上経ちました。
転職前の自分は、わりと素朴に「技術力さえあれば評価されるっしょ」くらいに思ってたんですが、入社してみると技術力以前のところで躓きまくりました。
今までずっと「プログラミング楽しい!」だけでやってきたので、技術以前のところでこんなに躓くんだ、と知った半年でした。
毎日新しい考え方を知る日々で、その学びを未来の自分のために整理しておきます。
頭に入れておく・知っておくだけで全然違うので、自戒も込めて書きます。
想定読者:
- 受託 → 事業会社の転職を考えてる、または転職したばかりの人
- 入社して間もなくて、立ち回りに迷ってる人
- 技術以外でなぜか評価されない気がしてる人
- いずれリーダー層を目指したい若手エンジニア
ここに書くのは、あくまで自分が今いる事業会社で教わったことと、自分が元いた受託の現場との対比です。
受託にも事業会社にもいろんな現場があるので、「全部の受託がこう、全部の事業会社がこう」という話ではありません。
気軽に、ピンときたところだけ拾ってもらえたら嬉しいです！
1. マインドセット
「仕事は降ってこない」を肝に銘じる
- 事業会社では、自分から動かないと進まない場面が多い。
- 「これ困ってる」のつぶやきを拾う、業務フローを見て「これいる？」と疑う、「仕組み化したらラクなのでは？」と提案する — これをやらないと作業者ポジションで固定される。
- 「自分ごと化」は事業会社で生き残るための具体的なスキル。
「信用貯金」を貯める
- 入社直後は実績づくりの期間。振られたタスクを期待値より一段上で返して、信頼を積んでいく。
- 「クオリティ重視で時間をかける」より、スピードを優先しつつ、合格点+αで返す方が、結果的にフィードバックループが回る。
- ここで信頼を積めないと、後から提案しても通りにくい。
- ただし、これを2年も3年も続けると便利な作業者で終わるので、あくまで初期戦略。
80点は簡単、100点が難しい
- 合格点(80点)を超えてからが本番。
- ※ まだ合格点に届いてない部分があるなら、当然そっちが先。これは合格点に届いた後の話。
- 「○○といえば自分」という看板になる領域を作るには、その+20点を取りに行く意識が必要。
「自分がいなくても回る状態」を作る
- 属人化を排除して、マニュアル化・仕組み化する側に回る。
- 作業者ではなく、仕組みを提供する側を目指す。
- 暇を作っておけば、重要度の高いタスクに手を挙げられる。
インプット・アウトプットと行動量
- 学んだことを継続して発信する。内容問わず、止めないことが大事。
- アウトプットすることで初めて、インプットしたことが自分のものになる。
- 「ちゃんとした内容じゃないと出せない」と思いがちだが、まずは出すことが先。
- 環境があっても、行動量がなければ成長しない。受け身でいる限り、どれだけいい環境でも成長は鈍る。
2. 思考について
なぜ？を繰り返す(深掘り)
- 結果ではなく理由を考える習慣。
- 「なぜミスが起きた？」「なぜこの納期？」「なぜこの仕様？」を3回繰り返すと、本質に近づく。
- 何かやっている途中で「これなんでやってるんだっけ？」と立ち止まる癖をつけるところから。
具体と抽象を行き来する
- 具体的な出来事から法則を抜き出して(抽象化)、別シーンに当てはめる(具体化)往復運動。
- 例:Slackの通知漏れ(具体) → 人依存の運用は属人化して必ず漏れる(抽象) → 請求項目の入力フローでも同じことが起きていないか？(別の具体)
- 文章を読むときに「これは具体？ 抽象？」と意識するだけでも目線が変わる。
視点を変える(多角化)
- 反対の立場や他人の視点から物事を考える。
- 「自分が依頼者だったら？」「エンドユーザーだったら？」「反対派なら何を言う？」
- 「業務初日の人がこの画面を触ったら、どこで詰まる？」と問うだけで設計の解像度が変わる。
構造化したいときは絵に描く
- 言葉だけで考えても整理しきれないとき、絵にすると一発で見える。
- いわゆる「ホワイトボード仕事術」。MTGでも、自分の頭の中でも、まず絵を描く。
- 構造を絵で持っておくと、相手にも伝えやすい。
3. 視座と視野
視座を上げるな、視野を広げろ
視座を上げようとするな。視野(横)を広げることだけ意識しろ。視野が広がれば、視座は自然と上がる。
- 「視座を上げろ」はいきなり言われても何をしていいか分からない。「視野を広げろ」の方が行動に落としやすい。
- 視野を広げる行動例:
- 自分の部署以外の業務を理解する
- 普段話さない人と意識的に話す
- 他のチームの課題を聞きに行く
- 業界の動向にアンテナを張る
業務理解が、提案力の天井を決める
- 業務が何のためにあって、どこにボトルネックがあって、関係者は誰か — これを知らないと技術ありきの的外れな提案になる。
- 技術力を磨くより先に、まず話を聞きに行く方が提案の質に効く。
- 「Chrome拡張で解決できそう」と提案しても、本当の課題が「フロー設計の話」だったらHOWを誤った提案になる。
おわりに
書き出してみると、半年で多くのことを学んできたんだなあと、改めて思います。
本当はまだまだあるんですが、一気に出すと多すぎるので、小出しにしていこうと思います。
転職前の自分が一番勘違いしてたのは「技術力さえあれば認められる」でした。
実際は、技術はベースとして当然必要ですが、その上で
- どう動き出すか
- どう考えるか
- どう伝えるか
- どう関係を作るか
の方が、ずっと大事だなと思いました。
今後は、ここに書いたことを「自分でできること」、さらに「人に教えられること」へと持っていきます。
同じように転職したばかりの方や、立ち回りに悩んでる若手の方に、何かひとつでも引っかかるものがあれば嬉しいです。