どうも非ソフト・非技術サイドからだと、一口にソフト屋といっても、いろんな人がいることがわかりにくいようです。というか、ソフト屋でもよくわかってないことが多い気がします。
ソフトと一括りにしてしまうと、組み込みでドライバー作っている人に、「Webクライアントアプリ書いてよ。ソフト屋なんだからできるでしょ？」みたいな話が罷り通ってしまいます。これは悲劇です。ソフト＝コード書く人くらいな意識です。
ということで、ちょっとソフト屋区分を整理してみました。厳密ではなく、ああ、ソフトといっても結構幅が広いのね、くらいな気持ちで。
Webクライアント屋
Webブラウザ用アプリを作成する人です。今はhtml/css/js一択でしょう。jsと一口にいっても、jQueryをはじめ、AngularJSやReactJSなど、色々なライブラリが用意されてきている上、TypeScriptやCoffeeScript、CSSでもSCSSといった技術が最近矢継ぎ早に公開されており、それなりにキャッチアップが必要な分野でもあります。
こんなに技術の変化が激しくなったのも、Webブラウザの進化によるものです。Webクライアント用言語と言えばJavaScriptなものの、JavaScriptは仕様的にあまり大規模開発に向かないため、ライブラリがJavaScriptの欠陥を補う形で、要求に合わせてどんどん変化しているといった具合です。
また、デザイナーとのやり取りが多く発生する技術分野ということもあり、デザイナーとのコミュニケーションや納入、実装がかなりのウェートを占めると思います。一昔前のjQueryのみでのAjax実装だと、JavaScriptコードにhtmlやcssのコードが散乱して、めっちゃくちゃなことになっていました。そういうこともあって、ReactJSなどの技術が生まれているのではないかと思います。
Webサーバ屋
Webサーバ上のアプリを構築する人です。言語はPHP, Perl, Ruby, Javaあたりがメジャーで、最近ではNode.jsやPythonなども。大抵は外部公開部分(WebAPI)→コントローラ→データベースまでの処理を書くことがほとんどです。Webサーバにはデータベースがつきものなので、SQLの知識は必須です。
Webサービスがビジネスの根幹を担うことが多いこともあって、JavaかPHPが書ければ食いっぱぐれないと言われるくらい、お仕事が見つかる分野でもあります。
フルスクラッチですべて書き起こすことは稀で、大抵はRailsやCake, Laravelなどのフレームワークに乗っかって実装を行います。最近は、サーバレスと言われるアーキテクチャが登場しており、それを使うならば機能モジュールの組み合わせでシステムを実装することになります。
Webサーバアプリは、コントローラ層のアーキテクチャ、データベース処理、セッション管理、セキュリティ、並列化あたりがカギだと勝手に思っています。この辺の設計が適切に行えるかどうか。
昔は、負荷分散や冗長化、デプロイやステージングといったインフラ部分を含むことが多かったですが、最近ではその部分はインフラ担当として明確に分けられていると思います。
サーバインフラ屋
サーバのインフラ担当です。あまりコードを書くことはしませんが、OSとネットワークの知識（主にLinux）が必須で、各種開発支援ツールのconfファイルの編集、シェルスクリプトなどを組んで自動化したりといったことを担当します。また、サーバ保守も大抵の場合担当します。
クラウドサービスが主流となったことで、インフラ周りも随分様変わりしたように思います。クラウドサービスが流行る前は、自社内でブレードサーバを物理的に組み上げて、サーバ自体の冗長化、NICの冗長化、ハブ・スイッチの冗長化など、自分たちで色々考えて信頼性を担保していました。いわゆるオンプレミスというやつです。
昨今のクラウドサービスでは、冗長化はもちろん、スケールアウト（負荷に応じてサーバを増やす）も自動でやってくれますし、スケールアップ（サーバ自体の性能を上げる）もポチポチするだけで終わってしまいます。凄い時代になったものです。
かといって、インフラ屋がやることなくなったかというと、そんなことはなく、物理的な心配がなくなっただけです。デプロイやステージングを考えたり、JenkinsやGit、SlackやRedmineといった開発支援のためのツールをうまく組み合わせて導入したり、シェルスクリプトを書いて自動化したりと、結構大変です。特に、ツールは流行り廃りもあるため、常にアンテナを高く張っておかないと、ついていけなくなったりします。
また、最近のクラウドサービスでは、普通のサーバインスタンス(AWSならec2)だけでなく、色々なモジュール(AWSならLambdaやAPIGatewayなど)が用意されるようなってきています。どういったものがあるかといった知見も広げておく必要があると思います。
DeepLearningなどでビッグデータを扱うとき、クラウド上で実験すると課金死するため、HadoopやSparkなどの分散処理システムを組み上げる必要に迫られます。この辺をスッとできると途轍もないイケメンです。
Webクラサバ・インフラをひっくるめて一人でできるスキルを持った人を、フルスタックエンジニアと呼んでいたこともありますが、最近でも言うのかどうか不明。
システムエンジニア
いわゆるSEです。この人は基本的にコードを書きません。要求されたシステムをどう組み上げればよいか、どういう技術と人が必要で、どれくらいかかりそうかを見積もって、スケジュールを立てる人です。QCDの番人。
コードを書かないからと言って、コードが書けなくてもいいわけではありません。自身の経験が、それぞれのタスクがどれくらいかかるかの工数見積もり精度に跳ね返ってきます。
また、浅くても良いので広い知識が必要です。「IoTデバイスから収集したデータをスマートフォンで閲覧できるシステム」の構成を考えなければならない時、IoTデバイスはサーバにどうやってデータを上げるのか、iOS/Android特有の癖、データベースはどうするのか、リアルタイム性はどこまで求められるのかなどを把握する必要があります。OSI参照モデル7層って何？httpなにそれ、iOS/Androidよく知りません、RDBMS/KVSって何？WebAPIって何？では仕事にならないでしょう。
システムが担うドメインの知識も必要になりますが、そこは知らなくても、客先やプロダクトオーナーから話を聞き出したり、不明な点を洗い出したりすることで補うことは可能です。逆に言うと、「不明な点」を正確に捉える能力が必要です。
プロダクトオーナー（プロデューサー）との連携も密に取る必要があり、場合によっては客先に技術説明をしに行ったり、技術的な不明点をヒアリングしに行くこともあります。
フレームワーク屋・ソフトウェアアーキテクト
こういう区分でいいのか迷うところですが、大き目の社内開発プロジェクトのソフトウェア構成を統括する設計者です。
この世には汎用フレームワークやSDK、例えばUnityなんかもそうですが、そういったものが数多あります。しかし、それらはあくまで汎用であって、個別プロジェクトに最適化されているわけではありません。そのため、SDKだけ無計画に社内プロジェクトに導入しても、即座に破たんします。そのため、全体的なソフト設計、および適切なルール作りが必要になります。
この役割の人は、オブジェクト指向やデザインパターンを適切に行使でき、プロジェクトで使用する言語のイディオムを把握している必要があります。ドメインの知識も必要で、開発チーム間の調整も多く発生します。決断力がない人や手持ち選択肢の少ない人にはあまり向きません。また、この役割の人が適当な指示を出すと、開発後段になって工数が雪だるま式に増えていき、バグつぶしがモグラ叩きの様相を呈するようになります。そしてメンバーは終わりの見えないプロジェクトに嫌気が差し、心を病むようになります。
また、同じ業務をずっとやっている人より、色々なシステムや言語を触ったことのある人の方が適任です。
フロントエンド・アプリ屋(Web以外)
これもまた定義が難しいところではありますが、提供されたSDKやプラットフォームAPIをたたいて、GUIアプリケーションを作り上げる人です。フロントエンドと一口に言っても、Windowsなら大抵C#.NET、MacならCocoa、マルチプラットフォームならJavaやAIR、Qtなど、多岐にわたります。インタフェース記述言語もFormデザイナ、InterfaceBuilderやXAML, Flex, QtQuickなどバラバラです。
GUI設計においては、どうすれば使いやすいかといった、ユーザビリティ的な考えだけでなく、どうすれば楽しく操作できるかといった観点も結構重要で、UIの工夫がそのまま強力な特許となることが多々あります。ソフトウェア特許でUI発明というのは、侵害検知が非常に簡単なため割と重宝されます。
GUIとプラットフォームとを繋ぐ部分については、システムによってサイズが大きく異なります。1人で開発できる程度のものから、1モジュールだけで1チームが割り当てられるものまで様々です。1チーム必要なレベルのモジュールが入っている場合、それがその企業のソフトウェア価値に直結することが多いのではないかと思います。専門部隊とか呼ばれたりします。
スマホアプリ屋
フロントエンド・アプリ屋の一種で、スマホ、主にiOS/Androidアプリを作る人です。スマホアプリといっても、FGOやデレステみたいな大規模なものではなく、ここでは１，２人程度で作成する小規模なものを想定しています。
iOSならばObjective-C/Swift, AndroidならJava, UnityやXamarinなどを使用するならC#も絡みます。スマートフォンは結構癖の強いデバイスのため、開発言語だけでなく、それぞれのプラットフォーム固有の知識が多く必要になります。開発経験が全くないと、HelloWorldプロジェクトのビルドすら難しかったりします。また、iOSが出来るからと言ってAndroidが出来るとは限らず、逆も然りです。実際、どっちも書ける人はそんなにいません。Androidが出来るんだったらiOS版も作ってと気軽に言ってはいけません。
繰り返しになりますが、スマートフォンは癖の強いデバイスで、完全に独自の世界を構築しています。AndroidもiOSも、ビックリドッキリ機能やお約束があったりするので、開発未経験の人に仕事を振っても、そうそうすぐにアウトプットは出てこないと思った方が良いでしょう。
ミドル・BSP・ドライバー
組み込み系の人たちです。ざっくりまとめてしまいましたが、組み込みといえばここがメインです。大抵の場合、使用する言語はC/C++です。
この界隈の人たちは、バイナリデータを扱うことが多く、デバッグコンソールに表示された16進の羅列を読み取る変な能力が身に付きます。かなりハードウェアに近いところにいるためか、あまりソフトウェアの設計能力は高くなく、C++であっても、Better Cとして扱うことを好む人が多いように見えます。
この人たちのやっていることは、Androidスマホを思い浮かべるとちょっとわかりやすいかもしれません。Androidは、Androidプラットフォームだけが共通で、ハードウェアはそれぞれの会社が独自で用意します。Androidスマホの性能を語るとき、PCと同じようにCPU+メモリ性能で考える人がそれなりにいますが、そう単純ではありません。Androidスマホは組み込み機器です。例えば、SoC基板、WiFiモジュール、GPSモジュール、Bluetoothモジュール、タッチパネル、物理キー、マイク、スピーカー、LTEモジュール、バッテリー、センサー等々が、メーカーごとに異なります。ということで、これらが１つの機器上で動作するように制御するのが組み込みエンジニアの仕事です。
これらのハードウェアをぐさっと繋いだら動くかというと、当然そんなわけはなく、まずは全てドライバーを用意しないと動いてくれません。で、ドライバーが全て用意されたらOKかというと、そんなことはなく、システムとして全体を繋いだり、キャリブレーションしたりする必要があります。システムとして繋いだらOKかというとそんなことはなく、SDK側から呼び出し可能なようにAPIを整理しなければなりません。
音声経路、映像経路（フレームバッファ）も、何もしなくても出力してくれるようなことはありません。ちゃんと制御が必要です。音声ドライバはAndroidだとALSAを使うことが多いと思いますが、音なんか鳴ればいいんじゃない？みたいに設計すると遅延が酷くなります。
Androidスマホの品質がメーカーによって異様なほどバラバラで、PC的なスペックの観点があてにならないのは、これでなんとなく想像つくのではないでしょうか。組み込みエンジニアというのは、こういう世界の人たちです。
マイコン屋
マイクロコンピュータ用の制御コードを書く人で、組み込みエンジニアの一種です。回路屋に一番近い位置にいます。
AVRやH8などの小規模マイコンと、FPGAなどの高性能マイコンがあり、前者はCやアセンブラ、後者はVHDLを使用します。最近では、VHDLの代わりにSystemCが用いられることも増えてきたとかいう話も聞きます。
マイコンが必要になるのは、在りもののモジュールでは事足りず、ハードウェアを独自に制御する場合です。そのため、通信プロトコル仕様も、開発者が考える必要があります。この仕様を、ある程度将来の拡張に備えて設計しないと、通信プロトコルがころころ変わることになり、その度にドライバー屋が苦労します。
ちなみに私はAVRをたたいたことがある程度で、この分野詳しくありません。まあ、7年前に書いた下記エントリー見れば推して知るべしというところではありますが・・・
コンピュータサイエンティスト
計算機科学の研究者です。圧縮技術、映像・音声符号化、暗号、機械学習、最適化、データサイエンスなど、色々なテーマがあります。この分野の人たちは、C++, Python, R, Matlabあたりを使うことが多いと思います。大抵のソフトウェアエンジニアリングの業務は、高等数学や物理の知識なんかほとんど必要ありませんが、コンピュータサイエンティストには必須です。
エンジニアではなく研究者のため、専門以外は実はよく知らないという人も結構いたりします。大学ではなく、コーポレートラボ付きの人であっても、ソフトウェアのトレンドに全く詳しくないということもザラです。ただ、地頭の良い人が多いため、何も知らない状態でも、しばらくするとあっさりキャッチアップしたりします。恐るべし。
終わりに
ということで、最近のソフト技術区分をなんとなく書いてみました。ソフトと一口にいっても、こんなに種類があるのか、と思っていただければ。
