はじめに
前回、受託開発の会社から事業会社の社内SEに転職して、半年で学んだことを書きました。
そのときはマインドや思考・視座まわりの「考え方」の話が中心だったので、今回はその続きとして、もう少し実務寄り、実際に手を動かすときの立ち回りの話を書いていきます。
前回も書いたとおり、転職前の自分は「技術力さえあれば評価されるっしょ」と素朴に思っていたタイプでした。
でも実際にやってみると、技術そのものより「どう聞くか」「どう伝えるか」「どう見積もるか」みたいな、わりと地味な実務スキルのところで差がつくんだな、と痛感した半年でした。
ここでは、その中でも「知っておくだけで明日から効く」ものを、自戒も込めて整理しておきます。
想定読者は前回と同じです:
- 受託 → 事業会社の転職を考えてる、または転職したばかりの人
- 入社して間もなくて、立ち回りに迷ってる人
- 技術はそこそこなのに、なぜか仕事が回らない気がしてる人
- いずれリーダー層を目指したい若手エンジニア
例によって、これは自分が今いる事業会社で教わったことと、元いた受託の現場との対比にすぎません。
「全部の受託がこう、全部の事業会社がこう」という話ではないので、ピンときたところだけ拾ってもらえたら嬉しいです！
1. 質問のしかた
受託の頃は、仕様書や設計書がある程度そろった状態で渡されることが多くて、質問の前提も揃っていました。
事業会社の社内SEだと、口頭でふわっと依頼が来ることも多くて、「質問のしかた」がそのまま生産性に直結するんだな、と気づきました。
「理解しました」を一旦封印する
- 「理解しました」は、実は何も伝わっていないことが多い。
- 本当に理解したなら、自分の言葉で言い換えて返す。「つまり○○という認識で合ってますか?」まで言えて、初めて理解。
- わかったふりは一番コストが高い。その場はやり過ごせても、後で認識齟齬が爆発して、お互いの時間を溶かす。
「理解しました」は、たいてい理解していない。
曖昧な言葉で質問しない
- 「ここらへんどうすればいいですか?」みたいな質問は、相手に解釈コストを丸投げしている。
- 「何が・どこまで分かっていて、どこで詰まっているか」を書く。これだけで相手の回答スピードが変わる。
- 質問の精度は、そのまま自分の業務理解の精度でもある。
「答え」じゃなく「道標」をもらう
- 答えだけもらうと、その場は解決するけど再現性がない。次に同じ壁にぶつかって、また聞くことになる。
- 「なぜその結論になったのか」を聞くと、考え方そのものが手に入る。魚じゃなくて、釣り方をもらう感覚。
- 「これは部署特有の事情なのか、それとも一般的な考え方なのか?」を切り分けて聞くと、さらに応用が効く。
質問文からノイズを削る
- 枕詞・言い訳・過剰な前置きは、相手がフラットに状況を把握する邪魔になる。
- 「事実 → どこで詰まっているか → 聞きたいこと」の順で、削れるだけ削る。
- 丁寧に書く=長く書く、ではない。むしろ削るほど伝わる。
2. 伝え方・言語化
受託の頃は、同じエンジニア同士で通じる言葉でなんとかなっていました。
事業会社では、相手が非エンジニアのことも多くて、「説明力」がそのまま評価につながるんだな、と思い知りました。
説明力 = 相手のレベルに合わせる力
- 難しいことを難しく言うのは誰でもできる。難しいことを、相手が分かる言葉で言えるのが説明力。
- 教える行為は、結局「自分の理解と相手の理解の差分を埋める作業」。だから相手の理解度をこまめに確認する。「ここまで大丈夫ですか?」を挟むだけで全然違う。
- ここが一番大事だと思っていて、いまだに一番伸ばしたいスキルです。
結論から話す
- 背景から話し始めると、相手は「で、結局何が言いたいの?」となる。
- まず結論 → 理由 → 詳細。チャットでもMTGでも同じ。
- 具体例を一つ添えると、相手の中の解像度が一気に上がる。
言語化は才能じゃなく、鍛えられる
- いい文章を読む。ただし量より「何を読むか」を絞って、型を盗む意識で読む。
- 本や記事を流し読みせず、頭の中で要約する癖をつけると、インプットがそのまま言語化の練習になる。
3. 見積もりとタスク管理
受託の頃は、上流の誰かが工数を切ってくれて、自分は割り当てられた分をこなせばよかった。
社内SEになってからは、「何を・どれくらいでやるか」を自分で出すところから始まる。ここがPMへの第一歩なんだな、と教わりました。
まず「工数を出す」癖をつける
- 着手前に、機能をフローに分解する(例:APIを叩く → データを整形する → シートに書き込む)。そのうえで、それぞれにかかる時間をざっくり出す。
- 全部を詳細に出す必要はない。粗くていいから、まず全量を洗い出す(感覚的には30分くらい)。
- 「これだいたいどれくらいで終わる?」に即答できると、それだけで信頼される。
見積もりは「一番長いケース」で取る
- 楽観的に見積もると、ほぼ確実に溢れる。最悪ケースで取っておくくらいでちょうどいい。
- 実装だけでなく、レビュー・修正・検証の時間も最初から見積もりに入れる。ここを忘れがち。
- バッファは規模で変える。小さいタスクに大きいバッファは不要。
見積もり → 実装 → 振り返りで「差分」を潰す
- 見積もりと実績がズレたら、「なぜズレたか」を振り返る。これを繰り返すと見積もり精度が上がっていく。
- この「予実の差を経験で埋めていく」作業が、そのままPMの基礎トレーニングになっている、と気づいてからは振り返りが楽しくなりました。
見積もりは、一発で当てるものじゃなく、ズレを振り返って精度を上げていくもの。
タイムボックスで区切る / 納期は手前に倒す
- タスクに時間の箱を切る。終わらなかったら一旦切って次へ(本当に今日終わらせたいものだけ延ばす)。
- 休憩も「休憩」という箱を入れておくと、ダラダラしない。
- 納期はギリギリじゃなく、数日手前に終わらせる前提で動く。「やったけど遅れた」は、内容が良くても評価上マイナスになりやすい。
4. 技術で学んだこと
受託の頃は、わりとモダンなフレームワークでアプリを書いていました。
社内SEだと、GASやスプレッドシートみたいな「現場にすぐ届く」道具がメインになる場面が多くて、最初は地味に見えたんですが、ハマりどころは普通に多かったです。
スプレッドシート相手でも、構造を分ける
- 処理(コントローラ)とデータ(スプシ・JSON)をファイルで分けるだけで、GASでも保守性が段違いになる。
- 規模が小さいうちから「将来これをいじる人がいる前提」で書く。属人化を作らないのは、コードレベルでも同じ。
「一度やった技術」は再現性を出せるようにする
- 初めてのAPI連携は時間がかかったけど、二度目以降は一気に速くなった。
- 一度詰まったところは、必ずメモして再現性を持たせる。これが「できることが増える」の正体だと思う。
- 自分の強みを聞かれたら「一度やったことは再現性を出せること」と答えられるくらいまで、意識的に貯めていきたい。
ツールが変わっても効く「本質」に投資する
- GASやスプレッドシートは、数年後には別のツールに置き換わっているかもしれない。
- でも、データ構造・SQL・設計の考え方みたいな土台は、ツールが変わっても効き続ける。
- 流行りを追いかけるより先に、まず土台を固める。
おわりに
前回の続きとして、実務寄りの話を書いてみました。
こうして並べてみると、結局どれも「技術そのもの」じゃなくて、技術を仕事として回すための周辺スキルなんだなと、改めて思います。
前回のマインド編とあわせて、転職前の自分に一番渡したかったのはこのあたりでした。
まだ書けてないネタ(MTGでの立ち回りとか、リーダー層を目指すうえで意識してることとか)もあるので、また小出しにしていこうと思います。
同じように転職したばかりの方や、立ち回りに悩んでる若手の方に、何かひとつでも引っかかるものがあれば嬉しいです！