少しIT業界に詳しい人とか、そういった人と仕事をしてきた人とプライベートであった時、自分がITエンジニアだと話すと、たまにこう言われます。
「PGとSEどっちなの？」
と。どうやらITエンジニアには、PG（プログラマー）、SE（システムエンジニア）といった区分があるらしいです。
・PGは、仕様書に従ってプログラムを書く、主に下流工程を担当する仕事
・SEは、顧客と対話し、要件定義や設計といった上流工程を担当する仕事
らしいです。PGよりもSEのほうが給料も高いというのが一般的らしいですね。
今日はこのPG、SEについてお話しようと思います。
ITエンジニアのキャリアパス
PGとかSEって言葉を検索すると、
ITエンジニアのキャリアパスとして、はじめはテスターやプログラマーから始まり、システムエンジニア、プロジェクトマネージャーへとステップアップしていくのが基本です
とまとられた記事をよく見かけます。
もちろんそういったキャリアパスもあるらしいですが、ITエンジニアみんながそうではありません。
今一緒に働いているITエンジニアの中には
・業界5年以上いるのに一回もプログラムを書いたことがないって人
・10年以上ずっとサーバやデータベースの管理だけをしている人
・ずっとWeb系現場を転々としてひたすらプログラムだけを書き続けている人
様々です。
僕はプログラムも書くし、インフラも触るし、他の開発メンバーの管理もするし、ステークホルダーと直で要件やスケジュール調整もします。
多分僕は広義のSEです。新卒で入社したときからずっと。
では、PG・SEといった明確な棲み分けって実際にあるのでしょうか？
開発体制によるんじゃない？
システム開発の現場と一口に言っても、現場ごと、ないしはチームごとに開発体制が変わってきます。
開発体制によって、ITエンジニアの役割も変わってくるのではないでしょうか。
まずはポピュラーな2つの開発手法について簡単にお話します。
ウォーターフォール開発
僕が就職する前よりも長くシステム開発の現場で知らしまれてきた開発手法に、ウォーターフォールモデルというものがあります。
・要件定義
・基本設計
・詳細設計
・実装・単体テスト
・結合テスト
・総合テスト
・リリース
など、上流工程から下流工程までのフェーズを一つずつこなしていく開発手法です。
前のフェーズが終わったら次のフェーズに着手し、上流工程には戻ることがない、
各フェーズが上流から下流に流れる滝のように進んでいくことから、ウォーターフォール（滝）と呼ばれています。
この手法では、PL（プロジェクトリーダー）やPM（プロジェクトマネージャー）といった役割の人がプロジェクトの責任を負い、
スケジュールや品質の管理をします。
そして、要件定義から詳細設計あたりの上流工程をSEが担当します。
PLやPGの管理下のもと、自身の経験やスキルを活かし、顧客の要望をシステム要件に落とし込み、設計をします。
そして下流工程をPGが担当します。SEが決めた設計をもとにシステムを実装し、テストを進めていきます。
この時、SEの決めた設計に従うことが原則となります。ウォーターフォールでは実装中に設計、要件定義といった上流工程に戻ることは許されないのです。
下流工程中のSEの役割としては、PGの人員の管理、タスクの管理、成果物の品質管理などがあります。もちろんSEでも実装を担当することは少なくないですが、
大規模開発になればなるほど、実装以降のタスクは下へ下へと請け負いが発生し、SEはその下請けの管理のみとなるケースもあります。
アジャイル開発
ウォーターフォールだとどうしても着工からリリースまでの期間が長くなり、PDCAが回しにくいといったデメリットがあります。
一方でこのアジャイル開発は、短い期間で開発からリリースまでのサイクルを繰り返す手法です。
アジャイル開発といってもその様式は様々ですが、僕のいる開発現場ではアジャイル開発のひとつ、スクラム開発を導入しています。
スクラム、ラグビーで見るアレですね。
チームで一丸となってひとつの目的に対して対応していく手法です。
要件定義や設計、実装、見積もりやスケジュール管理までをチームのメンバー全員がやるわけですね。みんな主役、運動会の徒競走で順位を決めるなと言われる現代社会にはピッタリですね。
この開発手法だと、みんながみんなゼネラリストであることが求められます。
僕はずっとコードだけを書いていたい、要件定義や顧客との対話はやらない、そんなわがままはスクラム開発には通用しません。
ましてや明確なリーダーも存在しません。スクラムチームの中にもプロダクトオーナーや、スクラムマスターと呼ばれる役割はありますが、チームの意思決定はチームメンバーの総意となります。
あれ？冒頭に述べた、PGとSEの棲み分けをしてちゃ、スクラム開発はできなくない？？
そもそもITエンジニアはただのビジネスマン
本題に戻りましょう。
僕はPGやSEといった職を明確に区別する必要はないと考えています。
今の時代って、システムに溢れてて、システ開発の需要が高まっているのと合わせて、システム開発をする上での情報やツールの供給も溢れているんです。
例えばこのブログをひとつ書くにしても、ゼロから作るのであれば、自分でサーバーを用意し、ネットワークを通してサーバを公開し、コードを書いて、自分でデザインをして、やることはつきませんよね？
でもはてなブログのサービスを介して、アカウントがあればスマホ1つで記事の公開まで持っていけます。
システム開発の現場だってそうです。システム要件を満たすために、外部のサービスやツールを利用したり、プログラムのフレームワークに従って開発したり、ゼロからものをつくるというより、いろいろなものを組み合わせてなにかを作ることの方が多いです。
ITエンジニアの仕事ってつまりそういう仕事なんですよね。エンジニアと呼ばれますが、技術者かというと怪しいところです。ビジネスの課題解決にシステム開発を通して貢献する、ただのビジネスマンなのです。
今の時代、自分はコーディングだけしかしない、生涯PGだ、と意気込んでこの業界を生きていくのは、よっぽどハイレベルでない限り難しいと思います。
ITエンジニアがもつ専門性、経験と知識を持って、顧客と対話し、チームメンバーと協力し、ビジネスをする、それが僕の考えるITエンジニアの役割です。
ITエンジニアのキャリアパス
とはいっても、人には得意不得意がありますよね。僕なんか知らない人と喋るのは苦手です。
同じチームの人でも、プログラム書くのが苦手という人、人の上に立つのが苦手な人、十人十色です。
僕の職場ではITエンジニア職のキャリアパスはこんな感じになっています。（着色済みなので実際のものとは異なります）
仮に貴方が新卒で入社し、配属になったとしましょう。始めは開発者としてチームに入り、スクラム開発を通して全工程を担当します。未経験で入社される人も多いので、ある程度経験すると、自分がどの道を進むのかが見えてきます。自分はマネジメントに向いている、自分はもっと技術を極めるのが向いている、と。
僕の職場の場合、スクラム開発と言えど、
・主にマネジメントや仕様調整をメインにする人
・主に実装や技術的課題解決をする人
・なんでもする人
に分かれます。自分の得意なところを請け負い、足りないところをチームで補完するのですね。とはいえ、PGやSEといった分かれ方かというと少し違います。要は何を武器に戦うかの違いだけになります。
まとめ
PGとSE、各々役割はありますが、開発現場によっては明確に区別されないことも多いです。僕は明確に区別したこともなければ、されたこともないです。今の時代、PGでもSEみんながみんなビジネスマンとしての視点を持っていなければいけない、この一言に尽きます。
もし合コンで、「職業はIT系のエンジニアです！」と自己紹介して、ちょっとこの業界に精通した人に、「へ〜、〇〇さんはPGとSE、どっちなのですか？」と聞かれたら迷わずこう答えましょう。
「SEです！」
と。一般的にSEの方が給与が高いらしいので。
今回は簡単にスクラム開発についても触れたので、いつかもっと詳細な話ができればと思います。
