PGとSEの違いは「誰と向き合うか」
プログラマーの仕事は、
明確な指示をもとにコードを書くことがメインです。
でも、SEになると話が変わります。
お客様が何を作りたいのか。
どういう背景でこのシステムが必要なのか。
「指示を受ける側」から「要件を引き出す側」に変わるんです。
この違いを意識できるかどうかが、
PGとSEの分かれ目だと思っています。
お客様の要望を「引き出す力」
SEとして一番難しいのが、
お客様の要望を正確に引き出すことです。
これって「磨く」というより、
とにかくコミュニケーションを取り続けることが答えに近い。
大事なのは、
- お客様のシステム環境を早くキャッチアップする
- どういう背景でこのシステムが存在しているかを理解する
- その上で、何を言いたいのかを把握する
このベースがあって初めて、
お客様の「言葉にならない要望」まで拾えるようになります。
うちのメンバーも、
初めてのお客様で期限が短かった案件で、
コミュニケーションより作業を優先してしまったことがあったんです。
結果、お客様が想定していたものとズレたものを作ってしまった。
この経験から学んだのは、
どれだけ期限が短くても、
最初の打ち合わせで定期的なミーティングの場を設定しておくこと。
「忙しいから後回し」は、
結果的に一番コストがかかる判断になるんです。
ドキュメントを読み解く力
技術スキル以外で意外と重要なのが、
設計書などのドキュメントを読み解く力です。
現場によっては書き方がバラバラで、
統一されていないことが普通にある。
「書いてあるけど、これ何が言いたいんだろう…」
そういう場面で、ちゃんと自分の中に落とし込める力があるか。
忙しくて声をかけづらい現場でも、
チャットでコミュニケーションが取りにくい現場でも、
ドキュメントから意図を読み取れる人は、それだけで動ける範囲が広がります。
これはPGの段階から意識して鍛えておきたいスキルです。
「今の設計が全てじゃない」という視点
コーディングをしている時でも、
「この設計、こうした方がよくない？」と気づくことがある。
このとき、黙って作り続けるのか、
ちゃんと声に出して伝えるのか。
「今ある設計が全てじゃなくて、
よりよくできる部分があるという考えを持って動くべき」
これ、PGの仕事のようでいて、実はSEに近い動き方なんです。
実装フェーズに入ってから「これだとうまくいかない」と気づくことは、
現場では普通に起きます。
方向転換できるか、改善提案を出せるか。
そこが評価の分かれ目になります。
ちなみに工数の見積もりも同じで、
「思ったより1.5倍〜2倍かかる」は現場あるある。
「こうした方がいい」が積み重なってコストが膨らむ。
だからこそ、最初の見積もりに余白を持たせることも大切です。
チームで動くための「相手を尊重する気持ち」
PGからSEになるうえで、
一番見落とされがちなのがこれかもしれません。
相手を尊重する気持ち。
「自分はこうやってきたからこうだ」と断定するのではなく、
「この人はこういう経験があるから、
こういう声のかけ方をするといいな」
そういう視点で動ける人は、
チームの中での信頼がぐっと上がります。
協調性って、ただ仲良くすることじゃない。
チームにどんな人がいるかを把握して、
その人に合わせて動ける。
チームの輪を乱さない関わり方ができるか。
これがSEとして長く活躍できる人の共通点だと思っています。
最後に
PGからSEへのステップアップに必要なのは、
特別な才能じゃありません。
- お客様の要望を引き出すコミュニケーション
- ドキュメントを読み解く力
- 改善提案を出せる視点
- 相手を尊重してチームで動く姿勢
この4つを意識して積み重ねていける人が、
現場で着実にキャリアを上げていきます。
「今はPGだけど、もっと上流工程に挑戦したい」
「SEとして市場価値を高めていきたい」
そんな想いがある方は、ぜひ一度お話ししましょう。
現役エンジニア兼社長の僕が、
直接お話を伺います。
キャリアに関するご相談はこちら
