ITエンジニアの肩書き、役職を未経験の方向けにご紹介します

こんにちは、フリーランスエンジニアのサカイです。

エンジニアの世界ではいくつかの肩書き、役職が存在します。

世間一般でイメージされているエンジニアって、
数ある肩書きの中の一部に過ぎないんですよね。

今回はエンジニアの肩書きを僕の経験も交えてご紹介したいなと思います。

注意

この記事は未経験の方でもわかるように意識して書くので
「アジァイルならスクラムマスターがいて、、、」みたいなことは一切書きません。

ウォータフォールやアジャイル毎に役割をご紹介するのもいいですが、
それはまた別の機会にします。

1.エンジニアの肩書きをざっくり分けてみる

まずはエンジニアの肩書きをざっくり分けて、そこから細かい話に移っていきます。

今回の分け方は2つです。

  • プロジェクトにおける肩書き
  • 会社の肩書き

なぜ2つの分け方をするのか?というと、
全ての肩書きを同じ軸で説明しようとするとカバーしきれない部分があるからです。

まあ僕のようなフリーランスエンジニアは会社における肩書きは無いんですが、
フリーランスでも「自分がやり取りするメンバーがどんな肩書なのか」
を把握しておく事は重要なので、知っておいて損はありません。

2.プロジェクトにおける役割

まずプロジェクトにおけるエンジニアの役割からご紹介します。

1つのものを開発するには、これだけの人が必要です。

  • 仕様を明確にする人
  • プログラムの全体構造を設計する人
  • 個々のプログラムを設計する人
  • プログラムを書く人
  • プログラムのテストをする人
  • 製品のテストをする人
  • チームをまとめる人

たとえば「顧客の製品Aに新たな機能を追加するプロジェクト」であれば、
まず製品Aに追加する機能がどんな機能なのか?を明確にする必要があります。
これを要件定義といいます。

そして要件を元にどうやってこの機能を実現するか?の設計をします。
基本設計とか詳細設計なんていいます。

設計をしたら設計書を元にプログラムを書きます。
コーディングとか実装なんていいます。

最後にコーディングしたものが要件通りに動いているかテストして完成です。
単体テスト、結合テスト、総合テストと分かれています。

川の水が上流から下流に流れるように仕様→設計→コーディング→テストと進んでいくので、
仕様や設計の作業を「上流」、コーディングやテスト作業を「下流」といったりします。

規模が小さい開発の場合、上流も下流もすべて自分でやる場合が多いですが、
規模の大きい開発だと担当が分かれます。

前置きが長くなってしまいましたが、
上流をメインにやる人がSE(システムエンジニア)
下流をメインにやる人がプログラマーです。

実際はSEでもコーディングすることはありますし、
プログラマーでも基本設計することもあるんですが、
基本スタンスとして上流か、下流かぐらいの違いです。

ちなみにプログラマーはプログラミングのテスト(単体テスト、結合テスト)
までしかやらないケースが多く、
最終的な製品のテストではテスターと言われるテスト専門のエンジニアがいます。

単価の相場でいうと上流の方が単価は高いです。
上流 > 下流 > テスター、という印象ですね。

世の中にはエグいレベルのプログラマーさんやテスターさんはたくさんいて、
鬼のようにコーディングしたり、難しいコードをサクッと仕上げられる人がいます。
また他の人には見つけられないようなバグを出せるテスターさんもいます。

どの肩書きでもそれぞれにプロフェッショナルはいるので、
個人的には肩書き自体に優劣は無いと思っています。

ただ「新人君でもできるか?」という観点で見ると、
上流 > 下流 > テスター、になるのかなと思います。

上流に関しては、やはり下流やテスターを経験してからやった方が良いです。

プログラムのことをわかっていない人が仕様や設計をまとめると、
プログラマーは苦労しますし、仕様や設計に抜け漏れが多くなります。

実際、上流をやる人はプログラマーやテスターの経験者が多いので、
そういったキャリアも考慮されて単価が高くなっているんでしょうね。

さて、最後にご紹介が遅れましたが、
チームがうまく機能するためにはチームをマネジメントする人が必要です!

顧客との見積、スケジュール調整や、
チームメンバーの進捗管理、メンバーが開発しやすくなる為の環境整備や、
メンバーのフォローなど。

ざっくり言うとお金と人の管理ってことなんですが、結構やることがあるんです。

更に世の中にはプレイングマネジャーなる状況の人も多くて、
管理をしながら自分でも開発をやるという人がいます。

僕の経験の中ではプレイングマネジャー時代が一番忙しかったです。
そりゃあそうですよね、色んな役割を一度にやるわけですから(^-^;

この管理系の業務については、
次の「会社における肩書き」で改めて触れますね。

ではおさらいしましょう。1つのプロジェクトにおける肩書きです。

  • システムエンジニア
  • プログラマー
  • テスター
  • マネジメント

未経験であれば、プログラマーかテスターから配属されるパターンが多いです。

3.会社における肩書き

では次にエンジニアの会社における肩書きについてご紹介しますね。

会社の肩書き、つまり「どうやって出世していくか?」ってことにもつながりますね。

会社によってポストや役職名は様々ですが、
ごく一般的な肩書き、役職は以下になります。

  • リーダー(主任)
  • プロジェクトリーダー(係長)
  • プロジェクトマネージャー(課長)

入社してから最初はプログラマーかテスターから始まり、
テスターの人もいずれはプログラマーになります。

ここから出世するには「人やお金」と向き合っていく必要があります。

まずリーダーというチームを管理する立場。

数名のメンバーを抱えて、みんながスケジュール通りに仕事を終えられるように
技術的なサポートをしたり、担当の割り振りを考えたりします。
また新人君には教育したりもしますね。

こんなことをやりながら、
数名のメンバーでできるぐらいの開発を管理しているケースが多いです。
管理業務のはじめの一歩といったところですね。

リーダーの経験値が上がると、
今度はプロジェクトリーダーに任命されます。
今度はチーム単位ではなく、プロジェクト単位での管理になります。

だいたい1つのプロジェクトには複数のチームがありますから、
それぞれがうまく回るような管理が求められます。

プロジェクトリーダーが主にやり取りする相手は各チームのリーダーです。

プロジェクトリーダーになると常に全員に気を配ることは難しくなってくるので、
チーム単位ではリーダーにまかせて、リーダーに指示を出したり、
状況を聞いたりするようになります。

ここから更に上がるとプロジェクトマネージャーになります。

プロジェクトマネージャーは「プロジェクト全体の結果責任を取る人」です。

プロジェクトを成功に導く為の管理を行います。
人とお金の管理がほぼメインになりますね。
また、プロジェクト外の人(経営陣や外部の人)とのやり取りも増えます。

数人程度の小さなプロジェクトの場合、
プロジェクトリーダーとプロジェクトマネージャーを一人の人がやる場合もあります。

さて、以上が会社における肩書きでした。

企業によっては、

  • システムアーキテクト
  • スペシャルエンジニア

みたいな技術よりのポストもありますが、どちらにしても人の上に立つ以上、
「人をまとめる」スキルは必須になります。

「マネジメントより」「技術より」という違いはあれど、
出世したいのであれば、人をまとめるスキルは勉強しておくといいでしょう。

本当に腕一本で稼ぎたいならフリーランスになった方がいいですね。

まとめ

いかがでしたでしょうか?
肩書きによって求められるスキルややりがいが変わってくるので、
今後のキャリアプランはざっくりとでも考えておくことをおススメします。

それでは、快適なエンジニアライフを!

2 件のコメント

  • はじめまして。
    興味深い記事だったので熟読させていただきました。

    日本ではエンジニアの境遇が(海外ほど)確立されておらず、それは理解が進んでいないためと考えてますが、一方で理解してもらう啓蒙も足りてないな、と日々感じてます。

    さてぜひ追記いただきたいなと思う役割として、

    ・プロダクト(サービス)エンジニア
    ・デリバリエンジニア
    ・サポートエンジニア

    というのもあると考えています。

    自社内だけで使うシステムなら、記載いただいたものがほぼ全て半と思いますが、プロダクトやサービスの場合、上に挙げた3種類のエンジニア(あるいはその役割)も必須と思います。

    その役割が明確にいないために、徐々にフェードアウトしてしまう、といった状況はいくつか見てきました。

    (日本独自の産業構造による問題かもしれませんが)開発会社が利益をあげようとすると、実は開発効率が上がりすぎると困る、というおかしな事態になります。

    システムオーナーからすると開発費やサポート費はコストでしかなく、それを使っていかに儲けられるか?が本来のミッションなのにもかかわらずです。

    それを改善するにはプロダクト・サービス指向を上げる必要があると考えます。

    個人的な意見、失礼いたしました。

    • 通りすがりのSEさん

      コメントありがとうございます!
      貴重なご意見、大変勉強になります。

      あげて頂いた役割、たしかにそうですね。
      重要な役割だと思います。

      しかしながら「今回の記事に関しては」
      未経験の方にざっくりとお伝えしたいという意図がありまして、、、
      このぐらいにとどめておこうかと思っています。すいません。。。

      ※決してご意見に反対というわけではなく、
       僕の考えとしてこのぐらいの情報量が適切かと判断した結果です。

      プロダクトサービス指向についての問題提起、勉強になりました。

      頂いたコメントの中には複数のテーマがあると思いますので、
      今回とは別の記事として書ければと思いました。

      コメントありがとうございました!
      また通りすがった際にはお立ち寄りいただければと思います(^^)

  • コメントを残す

    メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

    CAPTCHA


    このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください