はじめに

前回、受託開発の会社から事業会社の社内SEに転職して、半年で学んだことを書きました。
そのときはマインドや思考・視座まわりの「考え方」の話が中心だったので、今回はその続きとして、もう少し実務寄り、実際に手を動かすときの立ち回りの話を書いていきます。

前回も書いたとおり、転職前の自分は「技術力さえあれば評価されるっしょ」と素朴に思っていたタイプでした。
でも実際にやってみると、技術そのものより「どう聞くか」「どう伝えるか」「どう見積もるか」みたいな、わりと地味な実務スキルのところで差がつくんだな、と痛感した半年でした。
ここでは、その中でも「知っておくだけで明日から効く」ものを、自戒も込めて整理しておきます。

想定読者は前回と同じです:

受託 → 事業会社の転職を考えてる、または転職したばかりの人
入社して間もなくて、立ち回りに迷ってる人
技術はそこそこなのに、なぜか仕事が回らない気がしてる人
いずれリーダー層を目指したい若手エンジニア

例によって、これは自分が今いる事業会社で教わったことと、元いた受託の現場との対比にすぎません。
「全部の受託がこう、全部の事業会社がこう」という話ではないので、ピンときたところだけ拾ってもらえたら嬉しいです！

1. 質問のしかた

受託の頃は、仕様書や設計書がある程度そろった状態で渡されることが多くて、質問の前提も揃っていました。
事業会社の社内SEだと、口頭でふわっと依頼が来ることも多くて、「質問のしかた」がそのまま生産性に直結するんだな、と気づきました。

「理解しました」を一旦封印する

「理解しました」は、実は何も伝わっていないことが多い。
本当に理解したなら、自分の言葉で言い換えて返す。「つまり○○という認識で合ってますか?」まで言えて、初めて理解。
わかったふりは一番コストが高い。その場はやり過ごせても、後で認識齟齬が爆発して、お互いの時間を溶かす。

「理解しました」は、たいてい理解していない。

曖昧な言葉で質問しない

「ここらへんどうすればいいですか?」みたいな質問は、相手に解釈コストを丸投げしている。
「何が・どこまで分かっていて、どこで詰まっているか」を書く。これだけで相手の回答スピードが変わる。
質問の精度は、そのまま自分の業務理解の精度でもある。

「答え」じゃなく「道標」をもらう

答えだけもらうと、その場は解決するけど再現性がない。次に同じ壁にぶつかって、また聞くことになる。
「なぜその結論になったのか」を聞くと、考え方そのものが手に入る。魚じゃなくて、釣り方をもらう感覚。
「これは部署特有の事情なのか、それとも一般的な考え方なのか?」を切り分けて聞くと、さらに応用が効く。

質問文からノイズを削る

枕詞・言い訳・過剰な前置きは、相手がフラットに状況を把握する邪魔になる。
「事実 → どこで詰まっているか → 聞きたいこと」の順で、削れるだけ削る。
丁寧に書く=長く書く、ではない。むしろ削るほど伝わる。

2. 伝え方・言語化

受託の頃は、同じエンジニア同士で通じる言葉でなんとかなっていました。
事業会社では、相手が非エンジニアのことも多くて、「説明力」がそのまま評価につながるんだな、と思い知りました。

説明力 = 相手のレベルに合わせる力

難しいことを難しく言うのは誰でもできる。難しいことを、相手が分かる言葉で言えるのが説明力。
教える行為は、結局「自分の理解と相手の理解の差分を埋める作業」。だから相手の理解度をこまめに確認する。「ここまで大丈夫ですか?」を挟むだけで全然違う。
ここが一番大事だと思っていて、いまだに一番伸ばしたいスキルです。

結論から話す

背景から話し始めると、相手は「で、結局何が言いたいの?」となる。
まず結論 → 理由 → 詳細。チャットでもMTGでも同じ。
具体例を一つ添えると、相手の中の解像度が一気に上がる。

言語化は才能じゃなく、鍛えられる

いい文章を読む。ただし量より「何を読むか」を絞って、型を盗む意識で読む。
本や記事を流し読みせず、頭の中で要約する癖をつけると、インプットがそのまま言語化の練習になる。

3. 見積もりとタスク管理

受託の頃は、上流の誰かが工数を切ってくれて、自分は割り当てられた分をこなせばよかった。
社内SEになってからは、「何を・どれくらいでやるか」を自分で出すところから始まる。ここがPMへの第一歩なんだな、と教わりました。

まず「工数を出す」癖をつける

着手前に、機能をフローに分解する(例:APIを叩く → データを整形する → シートに書き込む)。そのうえで、それぞれにかかる時間をざっくり出す。
全部を詳細に出す必要はない。粗くていいから、まず全量を洗い出す(感覚的には30分くらい)。
「これだいたいどれくらいで終わる?」に即答できると、それだけで信頼される。

見積もりは「一番長いケース」で取る

楽観的に見積もると、ほぼ確実に溢れる。最悪ケースで取っておくくらいでちょうどいい。
実装だけでなく、レビュー・修正・検証の時間も最初から見積もりに入れる。ここを忘れがち。
バッファは規模で変える。小さいタスクに大きいバッファは不要。

見積もり → 実装 → 振り返りで「差分」を潰す

見積もりと実績がズレたら、「なぜズレたか」を振り返る。これを繰り返すと見積もり精度が上がっていく。
この「予実の差を経験で埋めていく」作業が、そのままPMの基礎トレーニングになっている、と気づいてからは振り返りが楽しくなりました。

見積もりは、一発で当てるものじゃなく、ズレを振り返って精度を上げていくもの。

タイムボックスで区切る / 納期は手前に倒す

タスクに時間の箱を切る。終わらなかったら一旦切って次へ(本当に今日終わらせたいものだけ延ばす)。
休憩も「休憩」という箱を入れておくと、ダラダラしない。
納期はギリギリじゃなく、数日手前に終わらせる前提で動く。「やったけど遅れた」は、内容が良くても評価上マイナスになりやすい。

4. 技術で学んだこと

受託の頃は、わりとモダンなフレームワークでアプリを書いていました。
社内SEだと、GASやスプレッドシートみたいな「現場にすぐ届く」道具がメインになる場面が多くて、最初は地味に見えたんですが、ハマりどころは普通に多かったです。

スプレッドシート相手でも、構造を分ける

処理(コントローラ)とデータ(スプシ・JSON)をファイルで分けるだけで、GASでも保守性が段違いになる。
規模が小さいうちから「将来これをいじる人がいる前提」で書く。属人化を作らないのは、コードレベルでも同じ。

「一度やった技術」は再現性を出せるようにする

初めてのAPI連携は時間がかかったけど、二度目以降は一気に速くなった。
一度詰まったところは、必ずメモして再現性を持たせる。これが「できることが増える」の正体だと思う。
自分の強みを聞かれたら「一度やったことは再現性を出せること」と答えられるくらいまで、意識的に貯めていきたい。

ツールが変わっても効く「本質」に投資する

GASやスプレッドシートは、数年後には別のツールに置き換わっているかもしれない。
でも、データ構造・SQL・設計の考え方みたいな土台は、ツールが変わっても効き続ける。
流行りを追いかけるより先に、まず土台を固める。

おわりに

前回の続きとして、実務寄りの話を書いてみました。
こうして並べてみると、結局どれも「技術そのもの」じゃなくて、技術を仕事として回すための周辺スキルなんだなと、改めて思います。

前回のマインド編とあわせて、転職前の自分に一番渡したかったのはこのあたりでした。

まだ書けてないネタ(MTGでの立ち回りとか、リーダー層を目指すうえで意識してることとか)もあるので、また小出しにしていこうと思います。
同じように転職したばかりの方や、立ち回りに悩んでる若手の方に、何かひとつでも引っかかるものがあれば嬉しいです！