株式会社Neverのshoheiです。
株式会社Neverは「NEVER STOP CREATE 作りつづけること」をビジョンに掲げ、理想を実現するためにプロダクトを作り続ける組織です。モバイルアプリケーションの受託開発、技術支援、コンサルティングを行っております。アプリ開発のご依頼や開発面でのお困りの際はお気楽にお問合せください。
前置き
これからエンジニアを目指す人にぜひ見て欲しい内容を書きました。主に次のような方向けに書いています。
- 将来の夢がエンジニア
- エンジニアを目指して勉強している
- エンジニアになって1年未満
念の為、ここで言及しているエンジニアは「ソフトウェアエンジニア」のことです。
また、エンジニアというのはかなり抽象的な表現で、組み込みエンジニア、Webエンジニア（フロント、バックエンド）、インフラエンジニア、アプリエンジニア等さまざまあります。ここは内容を網羅的に説明するためエンジニアと言う抽象的な文言を使い、Webやアプリ開発寄りの説明をしています。
本記事の内容はあくまでも経験に基づいた自分の考えを書いています。賛否両論ある内容になると思いますが、自分の中の答えを正直に書いています。この点を考慮した上で読んでいただければ幸いです。
また、文量がかなり多いので目次を設けています。目次から読みたいタイトルを選んでいただくとスムーズに読めるかと思います。
目次
なぜこの記事を書こうと思ったのか
「もくdev」というもくもく会メインの勉強会を2018年9月から運営しています。
関西と東京と二つ運営しています。私は関西で主催者として参加しています。
関西では毎週日曜日の11時から大阪で開催しており、おかげさまで多くの方々に参加していただいてます。
その中でエンジニアを目指して勉強されている方や業界に入り1年未満の方も多く、色々とお話させていただいてます。
お話して感じたのが、みなさん次のような悩みを持っていました。
- エンジニアは具体的にどんな仕事なのか
- エンジニアとして本当に自分がやっていけれるのか
- 情報が多く何を信じて勉強すれば良いのか悩んでいる
ここで私なりの回答としてこの記事を書こうと思いました。
是非やって欲しい事
まずは先に、エンジニアとしてご自身の技術レベルを上げるために是非やって欲しい事です。
- 直近の目標を決めてみんなに明言する（有言実行）
- 決めた目標に集中する（プログラミングの勉強など）
- アルゴリズムを鍛える（やりたいことをコードで表現できるようにする）
- ポートフォリオを作る、並行して設計の勉強する
ひたすらやってください。誰が何を言おうがやってください。Twitterなどで楽してスキルアップ！年収XXXX万円！とか訳の分からない広告を見ても無視してひたすらやり続けてください。
スキルを上げるためには自分で情報をとってきて試して新しい知見を得てを繰り返しやっていくしかありません。
英語にビビらないでください、英語はちゃんと読んでください。読めなくても読んでください。読むしかないんです。
楽な方法なんてありません、ひたすら勉強するしかないんです。
未経験の方でよくある傾向
プログラミングできるのは当たり前で、誰にでもできます。極論、コードをコピペすればいいだけですから。
1番大事なのはプログラミングできることではなく、
やりたいことをコードで表現する力（アルゴリズム）や保守性の高いコードを書ける（設計力）こと
です。
保守性が高いとは、コードの再利用性が高く仕様変更や追加に強い（影響範囲を抑えて実装できる）ことを指します。
今まで見た未経験の方はそこが全くできていません。
過去に実装方法の質問に対して具体的にこうすればできるよと答えても実装できなかった方を何人も見たことあります。なぜできなかったのかと聞くと「具体的にコードでどう書いていいか分からない」や「どうしてできないのか考えたけど、何が分からないのか自分でも分からない」と言っていました。
おそらく思考停止で写経やコピペして動かしていた影響によるものかと思います。
この記事をきっかけにご自身の理解度を再確認していただきたいです。
設計の話は後述します。
モチベーションの維持
モチベーションが続かなくなったり、難しすぎて挫折しそうになったときは、勉強会に参加してみてください。
注意として、参加するだけは絶対にやめてください。
参加してLTを聞いてなんとなくわかったで考察せずに帰る方がほとんどだと思いますがそれはダメです。なぜなら考察しないのですぐ忘れるからです。なんとなく参加する時間があれば参加せずに家で勉強した方が良いです。
参加する目的をしっかり決めて、参加後は必ず自分の中で考察してください。例えば新しい技術のLTがある場合は参加後にその技術のメリットとデメリットを調べて技術選定として採用するかどうか決めるまで考察していただきたいです。
また、勉強会の中にはより詳しい方もいらっしゃると思います。技術について相談してみてください。門前払いされるかもですがそこは自分の思いを伝えてください。
新しい発見や知見を自身の懐に落とす事がモチベーション維持につながります。
筆者の自己紹介
このような記事を書く場合、今までどのような経験をしてきたのかお伝えしないといけないと思い自己紹介させて頂きます。
私の経歴です。
| 期間 | キャリア | 何をしていたのか |
|---|---|---|
| 2004/4 - 2009/3 | 詫間電波高専（現：香川高専） | 情報工学専攻 |
| 2009/4 - 2013/3 | 徳島大学・大学院 | 知能情報専攻 |
| 2013/4 - 2017/12 | 製造メーカー | エンジニア（組み込みソフトウェア） |
| 2018/1 - 2018/6 | ベンチャー | エンジニア（アプリ） |
| 2018/7 - 2020/4 | フリーランス | エンジニア（アプリ・Web） |
| 2020/5 - | 法人 | エンジニア（アプリ・Web） |
学校の勉強は仕事で活かされている
高専から情報工学を学びました。高専・大学の在学中は遊び狂っていたせいでプログラミングは全くしていませんでしたが、情報工学の基礎は学ぶことができました。
ここでいう情報工学の基礎というのは
- C言語・Linuxコマンド
- アルゴリズム（ソートや探索など）
- なぜコンピュータが動くのか（電子・論理回路、デジタル・アナログ信号変換など）
今となってはここの基礎が仕事（特にデバッグ作業）に活かされています。
会社員時代に得たこと
製造メーカー入社後、組み込みのソフトウェアエンジニアとしてC++を使った開発やチームリード等のディレクションをしていました。
C++のオブジェクト指向での開発経験を得れたのもそうですが、開発する製品の規模がかなり大きかったので大規模開発（400人以上）の経験を得られたのが1番良かったです。
ベンチャーやフリーランスになってからは、アプリ・Webのエンジニアとして小規模開発（3人〜10人未満）でお仕事をさせていただいております。
エンジニアというお仕事
エンジニアの具体的な業務内容と求められるスキルについて紹介します。
エンジニアといっても様々な立場と役割があります。
| エンジニア | 役割 | 備考 |
|---|---|---|
| プロジェクトマネージャー（PjM) | そのプロダクトのソフトウェア開発において舵を切る人。責任を担い、プログラマーやデザイナーの作業のとりまとめをする。顧客との折衝をする。顧客とお金を話をするのはここ。ディレクションとも呼ばれる。 | 素晴らしいソフトウェアを作る上で重大な役割！ソフトウェア開発の最高責任者！ |
| プログラマー（PG） | プログラムを実装する人。現場によっては設計も行う。 | プロダクトに命を注ぐ人！ |
| デザイナー（D） | プロダクトのデザインをする人。現場によってはコーディングも行う。デザイナー兼コーダーとも呼ばれる。 | ユーザーに最も近いところを作れる！ |
簡単に3つに分けました。現場によっては役割が少し異なりますが。
他にも営業寄りのエンジニア（営業SEとも言われる）であったり、全体設計・システム設計を担うCTO的な役割を持つ方であったり様々な役割がありますが、ここでは分かりやすく３つにまとめました。
※注意
現場や開発規模によってはリソースの事情でこんなきれいに役割が別れないこともあります。1人でPjMもPGもやっている場合もあります。あくまでもリソースに余裕がある現場を想定しての説明ですのでそこを考慮した上で読んでいただければ幸いです。
ソフトウェアの開発プロセス
開発プロセスは次のとおりです
- 要件定義
- UI/UXデザイン
- 全体設計
- 内部設計・実装（レビュー・テストも含む）
- 顧客テスト・フィードバック対応
- 納品
細かい部分は端折っていますが、基本的な流れはこのような感じです。
それぞれのプロセスで登場するエンジニアと作業内容についてまとめました。
| プロセス | 主な登場人物（略称） | 作業内容 |
|---|---|---|
| 要件定義 | PjM | 顧客からヒアリングした要望をプロダクト仕様に落とし込む作業。必要な機能の洗い出しをする。 |
| UI/UXデザイン | D | プロダクトデザインを考え、ツールを使ってモックアップを作成する。 |
| 全体設計 | PjM PG |
技術選定や利用するサードパーティーのサービスなどを決め、全体の利害関係を決める。プロダクト仕様からシステム仕様に落とし込む作業。 |
| 内部設計・実装（レビュー・テストも含む） | PG PjM（結合テストのみ） |
選定した技術で具体的にどのような方針で実装するか決める。採用するアーキテクチャやフレームワークを決める。決めた方針に従い実装する。単体・結合テストも行う。結合テストはPjMに参加してもらう。 |
| 顧客テスト・フィードバック対応 | PjM PG D |
プロダクトのα版（またβ版）を顧客に触ってもらう。そこで出たフィードバックをPGやDが対応する。 |
| 納品 | PjM | 顧客テストをクリア後、完成したソフトウェアを納品する。納品物は開発した成果物、ソースコード、仕様書等を納品する（顧客と調整した上で決まる）。 |
求められるスキル
プロジェクトマネージャー（PjM)
- 技術知見
- コミュニケーション力
- 責任能力、管理能力
技術知見
技術知見とは
「この技術を使えば具体的に何を実現できるかといった知見」
です。
顧客から「こういうの作りたいんですけど可能ですか？可能な場合はどれぐらいの予算で作れますか？」と聞かれた場合に正しく回答できるかが求められます。
コミュニケーション力
コミュニケーション力とは
「難しい技術的な話を技術を知らない人へ分かりやすく伝えれる力」や「相手の理解度を考慮した上で分かりやすく伝えれる力」
です。
顧客への説明時や顧客からのフィードバックを内部のメンバーに共有する際に求められます。
責任能力、管理能力
責任能力とは
「開発プロジェクトの最高責任は自分であり、自分がいなければ正しく開発できないといった心構えをもって従事できる力」
です。
仕事をする上で責任を持つことは当たり前のことですが、PjMは1番責任を意識しなければいけない立場です。問題が起こった場合は直ちに状況を把握し、対応をしなければいけません。手段が複数ある場合はその状況においてのメリットを考え、判断しなければいけません。また、顧客への説明責任を果たさなければいけませんので、良いニュースや悪いニュース全て説明できるようにしなければいけません。
管理能力とは、開発タスクの管理や開発メンバーの管理です。納品までの具体的な開発スケジュールと細かいマイルストーンを決め、タスクをメンバーへ割り当てます。スケジュール通りの進捗があれば問題ありませんが、遅れている場合はリカバリープランを提案しなければいけません。
PjMは顧客と内部のメンバーからサンドウィッチされている立場なのでかなり大変ですが、求められるスキルにあるように重要な役割を持ち貴重な人材です。
プログラマー（PG)
- 設計力、実装力
- 新しい技術をキャッチアップする力
- 改善思考力
設計力、実装力
設計力とは
「具体的な実装方針を決めること」
です。
実装に迷いをもたせないよう採用したアーキテクチャやフレームワークで実装の方向性を示します。また、仕様の変更や機能の追加など既に実装したプログラムを触らなければいけない場合、低コストで修正でき且つデグレード（動いていたプログラムが変更によって動かなくなる事）のリスク抑えれるようしっかり設計する力が求められます。
設計については後述します。
実装力は
「プログラミング言語を使って実現したいものを作り上げる力」
です。
利用するプログラミング言語の使い方や特徴の理解やプログラミングで作ったものを動かすプラットフォームの仕様（特にライフサイクル）理解が求められます。
新しい技術をキャッチアップする力
新しい技術をキャッチアップする力は
「常に技術の勉強をすること」
です。
技術は常にアップデートされているため、アップデートに追従して内容を勉強していくことが求められます。例えば過去に使っていた技術が非推奨や廃止になり、新しい技術が登場してこちらを使ってくださいといったことがあり、そのように状況でもしっかり対応できるかが求められます。
改善思考力
改善思考力とは
「現状に甘んじず常に改善できないか考える力」
です。
例えば設計であれば「もっと実装しやすく仕様変更や機能追加に強い設計はないか」と考えたり、実装であれば「もっとパフォーマンスを上げれるアルゴリズム、書き方はないか」と考えたり、また仕事の進め方においては「手動で作業していることをスクリプトを使って自動化できないか」といった改善案を考えることが求められます。
改善することで実装コストの削減やヒューマンエラーの削減などに貢献できるため、改善案を提案して実際に導入できる人材はかなり重宝されます。
改善思考力はPG以外の方も持たなければいけないスキルです。
デザイナー（D)
- プロダクトコンセプトに合うデザインを決める力
- デザインツールの知見
- HTML/CSS/JSの知見
プロダクトコンセプトに合うデザインを決める力
とても重要なスキルです。似たような他のプロダクトのデザインを参考にしてコンセプトに合うデザインを決めるスキルが求められます。個人的にはデザインはフォント種別、サイズ、カラーテーマで決まると思っています
またユーザーの使いやすさも考慮しなければいけないため、UXを考慮したデザインも求められます。
デザインツールの知見
考えたデザインを成果物としてアウトプットするためにはAdobe XDやFigmaなどのデザインツールを使って作成します。
HTML/CSS/JSの知見
現場によってはマークアップ言語を使って実際にコーディングする場合もあります。デザイナー兼コーダーの人材は業界で重宝されます。
エンジニアとして知ってほしい事
ここからは未経験の方へ伝えたい自分の思いを書きたいと思います。プログラマー（PG）寄りの内容ですがご了承ください。
1番大切なのは設計力
お金に関わる内容なので、開発会社を経営している方にも読んでいただきたいです。
知って欲しいのはプログラミングできることが大切ではなく、1番大切なのは
コードを書く方針を立てる設計力
です。プログラミングできることは大前提です。
なぜ設計が必要なのか説明すると、開発コストを抑えるためです。
設計を怠ると起きる現実
まず根底には開発費用（人件費）があります。
開発費用とは開発にかかるお金、つまりエンジニア達の稼働する人件費です。稼働時間が多くなるとその分の人件費も高くなります。設計をしっかりすることでここにかかるコストがかなり変わります。
設計を全くせずに実装を進めると具体的にどうなるのか次のとおりです。
- どこに実装すれば良いのか分からないので、処理の責務が統一されないコードができあがる
- 似たような同じコードが至る所に書かれてしまう
- 1.と2.により、仕様変更や追加実装で安易に触ることができない、デグレードのリスクが高くなる
プロジェクトが進むことで問題も顕在化し、現場の混乱も生じてコミュニケーションコストも増え、人件費がさらに高くなってしまいます。なんとかローンチしたとしてもさまざまな問題を抱えているため、納品された顧客はまさに負の遺産をもってしまう形になります。この負の遺産の機能追加や不具合改修のお仕事がいろんな人に渡されてたらい回しされているのが現状です。
そうならないためにも設計の勉強をしてください
プロダクトに適したソフトウェア設計をしっかりすることで先ほど述べた問題点を解決することができ、開発費用も抑えることができます。
では具体的に何を勉強すれば良いのか次のとおりです。
- システム設計のアーキテクチャについて勉強（デザインパターンなど）
- 変更や機能追加に強い実装方法を考える（保守性の高い設計）
- しっかり設計された実装コードを読む
デザインパターンについては本がたくさん並んでいるのでぜひ手にとって読んでください。オブザーバ、シングルトン、ファクトリー、リポジトリなどそれぞれのデザインパターンの理解と用途について勉強してみてください。MVC、MVVM、Clean Architectureなども合わせて勉強していただければ。
また、自分で考えて実装することも大事です。1つの機能を実装した際に、例えば「今後似たような機能がもし増えた場合を考えて再利用できそうなロジックは共通モジュールとして切り分ける」といった考えで実装していくと自ずと力はついていきます。
そして、個人的に1番勉強になるのはしっかり設計されている実装コードを読んで触ることです。もし設計に詳しい方が周りにいらっしゃればぜひ話をしてみてください。門前払いされるかもしれませんが、ちゃんと自分の思いを伝えれば相談に乗ってくれると思います。
物づくりの面白さを感じてほしい
エンジニアは魔法使いのようなものです。コンピュータという魔法を利用して世の中を便利にして生活を豊にできるプロダクトを作れるのがエンジニアです。
利用者からの感謝の気持ちを伝えてもらえた時の「作ってよかった」と感じれる瞬間は1番やりがいを感じれるシーンではないでしょうか。
ぜひご自身のモチベーションの根底に「物づくりの面白さ」を入れていただきたいです。
そんな壮大なこと分からないという方は、一緒に開発する仲間から感謝された時の喜びとやりがいをモチベーションにしていただきたいです。
コミュニケーション力は必須です
プログラマーはコミュ障でも大丈夫っていう話を数年前に聞いた覚えがあるのですが、そんなことありません。
プログラマーという技術に詳しい人ほど技術を知らない人へ分かりやすくスマートに伝えれる力が必要なのです。
伝えるシーンは、現場によって異なります。大規模であれば営業、マーケ、品質評価、生産、経理、社長など、技術的な話をより分かりやすく伝える必要があります。営業の方に複数のスレッド間でデッドロックしてしまいとか言っても分かりませんよね。
伝える方法として、紙とペンを使って状況を図をかける力もほしいです。言葉で伝えるより絵に書いた方が複雑な状況を分かりやすく表現することができるからです。
言葉で伝える力を身に付けるためには、周りの方へ教えることや勉強会などのイベントに参加してプレゼンテーションするなど自分の言葉でアウトプットしてください。聴衆の反応から伝わった伝わっていないを考察し、もっと分かりやすい表現はないかなど考えて場数を踏んでください。
一緒にお仕事したいエンジニア
最後に、自分がどのような人と一緒にお仕事がしたいか書きます。
- 責任感がある
- 自走力がある
- 伝えたいことをちゃんとまとめて話すことができる
当たり前ですが、仕事に責任感を持てない人とは仕事したくありません。責任感があるから問題を起こさないよう設計をしっかりして実装できるのです。責任感は仕事の進め方にも表れます。
自走力とは知らない技術でも調べて情報を取って触ってみて感触をつかめることや、問題に直面してもしっかり原因を分析して解決できる力です（問題解決力とも言われるが自走力で統一）。自分で調べて解決していくので別名「ググる力」とも呼んでいます。
伝えたいことをちゃんとまとめて話すことができる方と一緒にお仕事がしたいです。様々な技術を扱う業界なので、情報を正しくスマートに伝えれるスキルを持った方は重宝されます。
最後に
いかがでしたでしょうか。長々と書いてしまいすみません。
もし質問がありましたらお気楽に私のTwitterへDMもしくはQiitaのコメントに投稿してください。
https://twitter.com/hobbydevelop
できる限り回答したいと思います。
質問に対する回答はこの記事に掲載しようと思います。
みなさんからの質問
Q. クラウドを含むインフラ部分のアーキテクチャ設計の役割について
SaaSなどを活用した、クラウドを含むインフラ部分のアーキテクチャ設計も、PGの役割になることが多いのでしょうか？
回答
AWSやGCPなどのクラウド選定やその中のサービス（バックエンドサーバー、ファイルサーバー、DBなど）選定と設計（どれぐらいのスペックで動かすかを設定したyamlファイルやDockerの構築など）はインフラエンジニア又はバックエンドエンジニアが行います。バックエンドの内部設計やDB設計はバックエンドエンジニアが行っているのが多いと思います。選んだサービスや設計はPjMに共有され、最終決定はPjMも交えて決めると思います。
本記事で紹介しているPGという表現が抽象的な表現なので厳密に言うとフロントエンド担当、バックエンド担当、インフラ担当と分けれますのでその中の後者になります。
なお、現場によってはPjMがDB設計を行っているプロジェクトもありました。
そのチーム構成はWeb開発の新規案件（規模は小さいもの）で、PjM1人とPG1人でデザインは別の会社が担当していました。PjMの責務としてはディレクションとDB設計、PGの責務は設計と実装（フロントとバックエンド共に）を担当していました。
また質問に対する回答ではないかもですが、ディレクションもPGも両方作業されている方もいました。私がいた現場ですが、不具合改修や文言変更などの小さな仕様変更や画像の差し替えの対応にあたっていました。
こちらも開発規模によってチーム構成はガラッと変わるので参考程度でお願いします。
Q. PjMとPGの作業量について
PjMは責任が重いものの、作業量自体はPGの方が多いように思うのですが、実際のところどうなんでしょうか？
回答
比較的、作業量が多いのは実装担当のPGかと思います。
ただ現場によってはPjMはプロジェクトを掛け持ちで複数回しているのでPjMの方が忙しい場合もあります。
また、PjMはプロジェクトを掛け持ちしている分、利害関係も多くなるので割り込み作業が多いです。
Q. 「しっかり設計されている実装コードを読んで触ること」を具体的に教えて欲しい
設計力を上げる方法として「しっかり設計されている実装コードを読んで触ること」とありますが、読んで触るのにオススメのコード(GitHubリポジトリ？)を教えてほしいです！
あと、「しっかり設計されているコード」の探し方も併せて教えていただけると大変助かります！
色んなOSSを手当り次第探していくしかないんですかね…？と思うなどしております。
回答
しっかり設計されている実装コードを読むチャンスは次のとおりです。
- もしエンジニアとして働いているのであれば、優秀と思う社内のエンジニアのコードを見る。そして何故そのような実装にしているのか考える又は聞く
- ご自身が仕事や個人開発で使っているライブラリがOSSであれば、Githubに書かれているコードを読んで分析する
- 技術に長けているTwitterアカウントをフォローしてその方のGithubを見たり技術ツイートが実装について言及しているものがあれば深掘りする
1は、職場によってはできない場合があるので、もし優秀な方がいらっしゃれば是非その人のコードを読んで分析してみてください。
2は、ご自身が使っているライブラリのGithubの中身を見にいきます。私の経験でお話すると、過去にFlamingoと言うライブラリを作りました。その設計のモデルとなったライブラリがBallcapというライブラリです。このライブラリのソースコードを分析して設計を理解して自分のライブラリに取り入れました。しっかり設計されているかどう判断しているかというと「様々なユースケースでテストをしてもしっかり動いていること」と「コードの変更や追加があっても低コストで対応できる」といった観点で判断しています。
3は、ご自身が使っている技術をキャッチアップしている方をフォローしてその方のツイートをウォッチングします。新しいライブラリや実装方法についてツイートしていると思うので、それを取り入れて試して合うかどうか考察することです。
今でも私は1, 2, 3の全て行い、設計について学んでいます。
Q. 見積りの作り方を知りたい
〇〇だからこのくらい費用がかかります。でも先方があまりいい表情をされない時に、利益を確保しつつ、お互いに良い条件を出す方法とか知りたいです。
回答
先方に納得してもらう必要があります。納得させるためには「なぜこのくらい費用がかかるのか？」といったことを具体的に説明する必要があります。
例えば1つの機能を対応するにあたって3人日の見積もりをしたとして、なぜ3人日かかるのか具体的に説明します。
- 分析・設計に0.5人日
- 実装に1.5人日
- テストに1人日（テストコード実装込み）
といった具合にこの機能を対応するにあたり、設計からテストコード実装まで品質をしっかり確保しなければいけないため費用はかかる事を伝えなければいけません。
ただ、顧客は他の会社さんからいただいた見積もり内容と比較しているかと思いますので、その点も考慮した上でこちらで開発するメリットを伝えなければいけないと思います。その場合、自信をもって弊社は品質はしっかり確保した開発できることを伝えるべきだと思います。
また、少ない工数で開発した場合（十分に品質を確保できていない）のデメリットも伝える必要もあります。
それでも顧客が納得がいかないようでしたら撤退することを考えた方が良いです。
Q. 自社、受託、SES、社内システム開発の違いを知りたい
自社、受託、SES、社内システム開発の違いとそれぞれのメリットデメリットについて知りたい。
また、選択するべきキャリアプラン（自己分析の仕方）でアドバイスがあればお願いします。
回答
私は今まで自社、受託、社内システム開発の経験をしました。SESとして派遣された経験はありませんが、SESとして派遣されたエンジニアと一緒にお仕事をしたことがあるのでその観点で回答します。
これはあくまでも私が経験した現場で感じたことなので、全てがそうとは限りません。そこを考慮した上で読んでください。
| 業務 | メリット | デメリット |
|---|---|---|
| 自社開発 | 主にプロダクトをより良くするための開発（グロース）と、業務効率向上のための改善作業を行う（CIやテスト導入や手動でやっていたことの自動化など）。また営業やマーケなど開発以外の部署とも関わりがとれるため、開発以外の知見（データ分析やUI/UX改善案など）を得れる。 | 先人の方が作り上げたプロダクトに関わるため、新規開発（01開発）の経験があまりできない。受託開発とは違い発注元となる会社がいないので顧客と折衝する経験があまりできない。また保守がメインになると既存の不具合修正の仕事ばかりさせられることも多い。 |
| 受託開発 | 発注元の会社さんがいてお仕事ができるため、顧客との折衝ができる（見積もりや顧客レビューなど）。新規開発ができるため、全体設計や技術選定から参加でき自分の作りたいようにプロダクトを作れる。一通り経験できると、独立して自分で受託開発を請け負うことも可能。 | プロダクトをローンチしてからのグロース作業に参加することがあまりない。発注元の事業計画にも関わるので、グロース提案が通りにくい（そもそもそこまでの責務をもてない事が多い）。 |
| SES | 様々な現場での開発経験ができる。大企業へSESとして派遣されることも珍しくないのでその企業の内部の実情であったり仕事の進め方を知る事ができる。また大手で働いていることをアピールできる？（過去にあったのが某大企業と言ってた人が実はSESで派遣されているだけだったとか）。 | 派遣先の会社の裁量によるため、現場によっては激務。また派遣先の会社の事業戦略によって急な依頼が金曜日の夜にふってくることも珍しくない。そのため休日出勤も比較的多い。 |
| 社内システム開発 | 発注元は社内（他部署が多い）なので、受託開発に比べてリラックスして仕事ができるかも？Visual Studioを使った社内システム開発が多いのでその知見を得たい方は向いているかも。C#やJava、VBなど。 | 他部署の窓口の方が技術に詳しくない場合は、何回も説明を求められる事が多い。社内なので様々な要望が五月雨で飛んでくることも多々あるので折衝が大変かも。 |
キャリアプランのアドバイスとしては、自分がどうなりたいのかしっかり決めることです。何がやりたいのか分からない場合はとりあえずやってみるしかないです。やってみて自分に合いそうなら続ける、合わなければ違うことをとりあえずやってみるべきかと思います。
ご参考まで。
Q. もし自分が業務未経験でエンジニアになるとすればどうしますか？
回答
次のような手順で転職します。
- 具体的にどういうものを作りたいのか決める。例えばiOSアプリ。
- iOSアプリの本を買って勉強する。
- 並行して実務経験のあるエンジニアさんに実務で必要なスキルを聞く
- 3.で聞いたことをひたすら勉強する。
- 転職活動の準備をする、アピールできるようGithubは毎日コミット、自身のポートフォリオ開発する
- ポートフォリオ開発と並行して新しい技術や設計はどんどん試してメリットデメリットを考える
- 転職活動をする
- 転職してからもより楽に実装できるようになるため新しい技術や設計については勉強をする
ご参考まで。
Q. shoheiさんの経歴でなぜそのキャリアプランを選んだのか知りたい
回答
学生時代は遊んでいたので1社目に入社する理由はあまり考えていませんでした。確か高専の先輩がそこで働いていたので色々話を聞いて面白そうと感じて入りました（面接はしっかり対策していきましたが）。
入社してから3年間は新しいことを学び、物づくりをする楽しさを感じていたのですが、4年目のディレクションを経験してから自分の中でやり切ってしまった感じがありました。そのため、この会社で何を目指せればいいのか分からなくなりました、簡単に言うと仕事に飽きてしまったのです。
なので他に何かしたいなと思い、スマフォがiPhoneだったのでアプリを作ろうとなって勉強したら面白くこれを仕事にしたく転職をしました。
2社目は半年でやめてしまいました。自分のやりたい事ができないと判断したためです。
そして独立しました。
独立後は自分のやりたいお仕事を優先しています。