開発/設計職って実際は何してんの?現役の技術職がリアルな仕事内容を10個紹介

開発/設計職って実際は何してんの?現役の技術職がリアルな仕事内容を10個紹介
みるみ

日常で「なんの仕事してんの?」と聞かれるシーンは多いです。

僕はいつもあんまり良い答えが思い浮かばなくて「技術職です」とか「メーカーでエンジニアやってます」とか色々答えてみるんだけど、そうすると100%「それ実際は何やってんの?」ってなるんですわ。

というわけで、多くの方がイメージが湧かないであろう

技術職、その中でも「開発職/設計職」と言われる人たちは日々どういうことをしているのか

について、現役で技術職をやっている僕がなるべくリアルに、細かく、具体例を交えながら説明してみたいと思います。

これはおそらく転職を考えている人にとってもかなりお役に立てる内容なんじゃないかと思ってます。「就きたい仕事の実は何してるのかのイメージが全然湧いてない」なんてお話にならないですからね。

僕は技術職という仕事がとても好きですし、誇りを持っています。なのでポジトークではないですがちょっと良いところにフォーカスした内容にはなっているかもしれません。でもだからこそ楽しんでいただけたら嬉しいなと思います!

今回で言う「技術職」とは強いて言うなら「ハードウェアエンジニア」に近いです。プログラミングなどIT領域では「エンジニア」とは言うけど「技術職」と呼ぶ風潮はあまり感じません(組み込みソフトウェアはそうでもないけど)。

総合的な事前知識も含めて、この辺の話は技術職についてのまとめ記事を先に読んでいただくのがいいかもしれません。

なので少なからず「何かしらのモノづくりに関わる人」みたいなイメージで読んでいただければ幸いです。

開発職と設計職って違うもの?

まずはじめに。

今回の話のタネになる

  • 開発職
  • 設計職

ですが、これらは同じものだと思ってOKです。

具体的な定義なんてもんは一切なく、会社が勝手に部署名をネーミングしているくらいのレベルです。僕の会社だって同じ部署(業務変わらず)なのに「◯◯開発部」になったり「◯◯設計部」になったりコロコロ変わります。笑

厳密に意味を捉えようとするなら

  • 開発職:どちらかというと技術開発寄りで、要素技術の研究などアウトプットが無形物である傾向
  • 設計職:動かすのは頭より手、実際のプロダクト(有形物)を生み出すのに近い傾向

などのイメージはあるっちゃあります。でも線引きなんて絶対にないはずです。

開発職と設計職は基本的に同じもの

「開発と設計は別のものである」などと根拠もない解説をわざわざしているサイトも散見されますが、たぶん実際の現場なんて何も知らない人間が書いているのだろうと思います。上述したように違いを見い出そうとすることはできますが、それをわざわざ一般論に落とし込んで定義化するのは到底無理なはず、というのが僕の考えです。

みるみ
みるみ

もちろん会社によって独自のルールを敷いているパターンは多いです、命名規則みたいな感じで。文脈によってイメージを汲み取りましょう!

というわけで、以降この記事では「開発/設計職」という表記で同じものとして扱います。

開発/設計職の主な業務を詳しく紹介

では本題です。

「一般的に開発/設計職が行っている業務」というものを挙げて、それらについて詳しく説明します。枠組みは一般論だけど、それを分かりやすく噛み砕いて紹介できればいいなという感じです。

数は 10個 。これでも絞った方ですが、少なすぎても意味を成さないのでキリの良い数字で!

1.詳細設計:図面を引いたり描いたり…

engineering-drawing

「設計」と名がつくくらいだし、開発/設計職の花形とも言える仕事じゃないでしょうか。色んな意味でも「メイン」の業務だし、実際にこれを中心に開発フェーズが組まれるのが普通でしょう。

図面とは設計図のこと。どこに何を置くのか、サイズはどうなのか、何と繋がっているのかなどなど…を基本規則に則ったフォーマットで描き上げていきます。

例えば電気系なら

circuit-pattern

このように「どの部品とどの部品がどう繋がっているのか、電圧はいくつなのか」などを示す「回路図」や、

cr-5000-circuit-board-design

このように「どこに部品が置いてあり、どういう経路(「パターン」という)で接続するか」などを示す「基板図」「実装図」などと呼ばれるものを作ります。

機構系、機械系なら

3d-cad-example

このように製品の外観寸法や組み立て仕様を示すCADデータがメイン。機構屋さんはよく「モデル」とか「3Dモデル」って呼んでます。3D CADのイメージがまさにこれですよね。

他にも

3d-Cad-Drawing-example

図面の例。3D CADから出力できる場合がほとんどです。

このように各部品を静的に示すような「組み立て図/三面図/平面図」というものも一緒に作製するのが普通です。こっちの方が図面っぽい感じしますね~。

また、これら以外にも光学系として

lambda_research_corp_oslo-example

光路設計やレンズ設計した結果を図面に起こすこともあります。

みるみ
みるみ

光学部品って実は色んなものに使われているんですよ~。

勘違いされやすいですが、これは作図することが目的の作業ではありません。

メインは製品の設計自体であり、図は単なる結果に過ぎません。

例えば

circuit-pattern

回路図だって、こういう回路設計に至る長~い検討の結果があってこうなっています。色んな実験や測定、検証を経て「これだ!」と決めながら図に起こしていくんです(実際には同時にやったり後で作図だけまとめたりと形態は色々あります)

図面自体を描ける技術(お絵描きスキル)はたしかに立派な能力であり磨けば個性にもなりえますが、設計内容を他人からもえらないと仕事ができないようじゃ話になりません。

しかし順番として「よく分かんないけどとりあえずひたすら図面を描く」というのはスキルアップとしてはかなり上達が速いのでおすすめ。僕も最初は死ぬほど基板のパターン図を書かされたおかげで、電気的なノウハウも後からどんどん付いてきました。

なのでハード屋として技術職に就いたらまずは図面を描く仕事をもらえるようにすると、モチベーション的にもおすすめです!

3D CADに関しては電気系CAD(2D CAD)より単品でのスキル度合いが強いです。「3D CADが超使える」というだけでたぶん転職にも相当強いくらいのアドバンテージが出せるレベルでしょう。でも中身を磨くのも忘れずにね、というお話でした

2.部品選定:実は技術職でも外の人とよく会います

module-choice

言われないと存在にすら気付かないような仕事内容だと思うんですが、「ここに使う部品をどれにするか?」という部品選定の作業は、実はハードウェア系技術者の仕事の中でもかなり大きな割合を占めています。

これはミクロとマクロどちらでも言えるのが面白いところで、例えば

  • 車メーカーがトランスミッションをどこのメーカーのものにするか選ぶ
  • 回路の中の超小さいチップ部品(1ミリ四方以下)をどこのメーカーのものにするか選ぶ

のどちらも部品選定と言えますよね。「技術職の仕事って包含関係で成り立っているな」と僕はよく思うんですが、これはその良い例です。

しかし、一般に「部品選定」と言ったら後者を指すのがほとんど。

技術職での部品選定とは

ちなみに左側は「コンペ」と言って、逆に「自分たちの製品(エンジン)を(車メーカーに)選んでもらう!」という構図になる場合がほとんど。車業界だと特に「ML(メーカーレイアウト)」と呼んだりします。

部品1つを選ぶのも簡単ではなく、以下のような要素を総合的に勘案して決めていくことになります。

  • そもそも今回欲しいケースに見合った部品か
  • 仕様値のバラつき度合い
  • 温度特性
  • 信頼性(耐久度のようなもの)
  • ノイズ特性
  • コスト
  • リードタイム(納期)
  • 納入形態

など。ご覧の通りお金や日程も関わってくるので、これら全てを1人で決定できるようになるためには相当の経験とポジションを要します。もちろん細かいものはある程度「えいや」で決めます。

クソどうでもいいですが、「えいや」って業界用語らしいというのをこの間知って超驚きました。たしかに「そういう表現をする人が多いなあ」とは思っていたけど、初耳でも意味は分かったし、へぇ、なるほど…。など。

また、実際に選ぶときの進め方もサクサク行くものではないです。少し変わったものが欲しいなら、色んなメーカーさんを呼んで直接話を聞いたりサンプル品を見せてもらったり、もしくはそれを実験&評価したり…。

実は技術職、しかも開発/設計職といえども、会社の外に出て色んな人に会うことは多いんです(こういう場合はこっちが「買い手」なのでだいたい他社さんが自社へ来てくれることがほとんどだけど)。

「エンジニアやりたいけど、人と話すのも好きだし、営業的なこともやってみたかったんだよなあ」

と思っていた人には朗報ですね。喋れる奴はすぐ駆り出されます。笑

逆に

「いやいや、人と接したくなくて技術職目指してるんだよ。そんなんごめんだわ」

って人にも朗報です。そういう奴は絶対他社メーカー打ち合わせとかには呼ばれません。笑

みるみ
みるみ

少なくとも僕が上司なら余程その人しか知らないことがあるとかじゃない限り人様の前には出さないです…。

「部品選定」という大きなかたまりのなかに色んな仕事内容が見え隠れしましたね。次からそれらも登場しますよ~

3.不具合解析:作るばかりではなくて、戻る作業も大切

Failure-analysis

不具合解析。僕はあんまり良い思い出がないんですが、人によっては望んでかそうじゃないのか(?)ここのスペシャリストになってしまう人もよく見かけました。いつ見ても同じことやっているようにしか見えないw

試作品や検討中の手作りのプロトタイプはもちろん、量産品でさえ完全にノーミスで作れる保証はいつだってゼロではありません。どんなに工夫を凝らしても予期しない不具合は出てしまうものなんです。

そしたら当然その原因を知る必要があります。それが不具合解析です、そのまんまだけど。

  • その製品の故障モードを理解しており、どのパターンが関係しているか見抜ける
  • 不具合を再現させられるようになるまでひたすら実験して多くのパターンを試す
  • 色んな測定器や設計資料などを使って原因を絞り込んでいく
  • どうやったら見つかった原因を他へ影響を与えずに改善できるか検討する

などなど、全てやろうとすると求められるスキルはかなりハイレベルなものになります。

実際はこの中でそれぞれの仕事が各人員に振られるイメージが正しいと思います。良い例が出たのでもう少し説明を続けてみましょう。

数人~十数人程度の一般的な開発チームがあるとしたら、たぶん

  • その製品の故障モードを理解しており、どのパターンが関係しているか見抜ける
     →チームのメインクラス
  • 不具合を再現させられるようになるまでひたすら実験して多くのパターンを試す
     →新人~若手
  • 色んな測定器や設計資料などを使って原因を絞り込んでいく
     →新人~若手
  • どうやったら見つかった原因を他へ影響を与えずに改善できるか検討する
     →ベテランクラス、それも1人ではなくて数人がかりのことも

みたいな仕事配分が一般的になるかと思います。技術職、特にハードウェアエンジニアは年齢や経験の差がスキルに如実に現れるので、仕事の割り振りはだいぶ明確になりやすいです。

IT系職種とはだいぶ性質が違う点でもあり面白いところでもあるので、興味がある方は下記記事もぜひ読んでみてください。

上記の仕事配分を見て、「つまんないものがやっぱり若手に回ってきているんだな」と思った方はおそらく技術職に向いていないと思います。そういう泥臭い作業がエンジニアの醍醐味だと僕は思っていますし、やっぱり理屈より手を動かす仕事は楽しいって思いません?

みるみ
みるみ

たぶん僕だけじゃなくてベテランのおじさんクラスに聞いてもみんな実験とか測定とかやりたいって言うと思う。笑

不具合解析はわりと電気系エンジニア寄りな仕事内容かもしれません。僕は機構担当じゃないのであまり詳しくないんですが、「不具合解析」ということをやっているイメージはほとんどないんだよな…。電気的な故障と違って目で見りゃ分かるからかな?

4.測定・評価:技術職の基本はデータ取りから

measurement-develoment-engineer

技術職に「基本のキ」なるものがあるとしたら、僕はここだと思います。

何かを語るには必ず数字が必要です。ありとあらゆるデータを測って、それをもとに今回他に9個挙げているような仕事内容へ活かしていきます。

ここで得られる知見やノウハウはめちゃめちゃ多くて、やっぱり技術者はちゃんとした測定をできるかどうかでその後のスキルアップの伸びしろが超変わるんじゃないかと思っています。ベテランおじさんはやっぱり測定/評価に対する考え方や姿勢が僕らとは段違いですもん。

技術職にとって測定や評価は本当に大事なもの

これら「測定」や「評価」と言われる作業は、一般的には単純作業だし若手に回ってきがちのつまらない作業と思われやすいですが、僕は違うと思っています。

ちゃんとした測定をするためにはそれはもう色んな環境セッティングが大切だし、やったことのない測定なら理論の把握も必要。測定器の類だって使いこなせないといけません。

実際に手を動かしながら出てきた数値を確かめて、「ああ、やっぱりこの考え方で合っていた…!」みたいなときの感動はひとしおです。

ちなみにこのツイートをしたときは光学的な測定をしていました。僕ら(僕ともう一人)は勉強中とはいえもともと光学分野は門外漢なので、

  1. まずは基礎理論や資料をもとに仮説を立てて…
  2. 使用する測定器の仕様や仕組みをまず知るために実験的な測定をして…
  3. 実際に測って値を出してみて…
  4. 手計算によって出てきてた理論値と比較して整合性を見る!ドンピシャ…!

みたいなことをやってました。楽しい。

また、「測定をより効率化させるために何かを作る」という作業も多いです。

多くは

  • 測定器を自動制御できるスクリプトを作る
  • 出力されたデータを自動的に溜め込んでいけるプログラムを書く
  • 測定精度を上げるため物理的な用意をする(治具の作製、後述)

などが付随し、これらがまずは仕事になることが多かったです。少なくとも僕は。

この「1つの目的に向かうルートを考え出し、そこに向けて色んな準備をして進めていく」というプロセスが技術職の楽しいところなんだよなあ!

5.新規技術開発:実現したいことに対して課題を解決していく

Research-and-Development

ちょっと粒度を大きくして、ここはざっくりめにまとめてみます。

実際のメーカーという会社の中の事情としては、「今月はこれをリリース、来月からはこの製品を作る!」という感じではなく「なんとなくのコンセプトだけ決まっているけど、その要になる技術がまだ未成熟」みたいなことは非常に多いです。

technology-develoment-engineers

こんなとき、

  • そもそもその技術は成立性があるのか?
  • どんなハードルがあるか?
  • どうやったら解決できるか?

を考えていくのが「技術開発」などと呼ばれるものです。

他にも

  • 先行技術
  • 要素技術
  • 研究開発

などの言葉もこの辺に分類される傾向が強いですね(研究開発だけはわりと明確な区分があることが多い)。前述した「開発職と設計職の違いを無理やり言うなら」の話にも近いですね。

開発/設計職の中にもそれなりにグループ分けはあって、だいたい大きい会社ほど

  • 商品開発系:実際の製品づくりがメイン、とにかくアウトプットを出す
  • 技術開発系:今回の5番の項目「新規技術開発」にあたるような、それぞれの製品の核となる技術自体の開発をする部隊
  • 研究開発系:ビジネスの概念からは最も遠い新規の技術開発など。どちらかというと世間での技術発展を目指すみたいな感じ

という3つが分かりやすい分類かと思います。

開発/設計職はなんとなく3つに分類される

冒頭で紹介したものがほぼベースですが、研究開発も入れて3分類にしてみました。

僕はずっと2つめのポジションにいて、アウトプットを急かされにくく技術の開発自体もじっくり楽しめるという一番良いところに居れていると思っています。

また、新規技術開発というものは今までに挙げてきたような仕事内容をかなり含んでいますが、ゴールが見えない分、面白いと感じる人とつまらないと感じる人が分かれやすいと経験上思います。

ガシガシ設計をやりたい人(図面描いたりとかが好きな人)にはちょっと合わない仕事かな?
僕はさっきも言ったように好きです。「頭で考えてから→実際に手を動かして検証」みたいな流れが仕事に関わらず何でも好きなので!

6.治具の作製:開発/設計職の仕事自体のために必要なものを作る

jig-example

「治具」、見慣れない言葉ですよね。

「じぐ」と読みます。「部品加工などの際に位置などを明確にさせるもの」という意味のjig(英語)から来た当て字です。

そもそも業界によって使われ方もだいぶ違うらしく、「治具ってなに?」という質問にズバッと答えるのは至難の業だと思われますが、技術職まわりで治具と言ったら「製品本体以外で技術検討に使う何らかの物体すべて」という感じになるはず。

いくら説明しても伝わる気がしないので、僕らが「治具」と呼ぶものを写真で列挙してみます。

jig-example-3

拾い物の写真なのでこれが何の治具かは分かりませんが、おそらく何かの位置決め用かセッティング用。このように「ある特定の目的のために作ったもの」を治具と呼ぶ傾向がありますね。

Manufacturing-jig

このような量産の生産ラインで使うような装置全体を「治具」と呼んだりすることもあるし、その辺にあるちょっとした道具もなんでも「治具」って呼びます。

SIGMA-KOKI-CHUO-SEIKI-stage-gonio

位置決めや角度の微妙な調整などに使ったりする道具。「ステージ」や「ゴニオ」などの名前がありますが、まとめてしょっちゅう「治具」と言います。

print-circuit-example-jig

果てには基板そのものを「治具」と呼ぶこともあります。組み込んで使用するモジュールのような製品を開発している場合、組み込まずに単体でも動かせるように「デバッグモード」のような役割を持つのが治具基板です。「電源治具」などとも。

「とにかくなんでも治具って呼べばいいって思ってるだろ」と思いました?そうなんです()

前置きが長くなりました。

で、これら自体を作るのも大きな仕事内容となるわけなんです。

例えば、一番治具っぽいWikipediaにもあるようなこういうもの。

 jig-example-2

金属加工や金型成形のときに使うのが語源だけあって、こういう雰囲気のものは生産現場へ行くと大量にあります。「生産技術」と呼ばれる人はこういった生産用の治具設計の専門部署でもありますね。

より業務を

  • 安全に
  • 確実に
  • 効率的に

進めるためにまず治具も設計しよう!みたいな流れということです。もちろんこれらも図面を描いてメーカーさんに発注したりして製作しているんですよ。イメージ湧きました??

7.DR(デザインレビュー):誰かが設計したものをみんなでチェックする

design-review-visual

少し視点を変えて、個人作業ばっかりではなくチームで仕事をする例も見てみましょう。

DR、Design Reviewの略で「でぃーあーる」とそのまま読みます。デザインとは日本語での「外観・見た目」ではなく「設計」という意味なのでお間違えのなきよう。

内容は「誰かのあらゆる設計結果をみんなで確認し、修正すべき場所がないか指摘し合う」というもの。

DR(デザインレビュー)はみんなで設計ルールなどの確認をし指摘し合う場

単なる打ち合わせに見えそうですが、ここには多くの体系化された手法とそれに関するノウハウがあります。

ひとり個人で設計した内容をまさかそのまま製品化まで持っていくことはないというのは想像がつくと思いますが、それを複数人で特にルールも設けずに見直しただけでは精度はそこまで上がりません。

みるみ
みるみ

むしろめんどくせぇ奴がいるとくだらない説教だけで終わったりするから決してルールなしで自由に喋らせてはいけないのだ…(戒め)

大事なのは、「指摘すべき項目について見落としがないようなちゃんとした進め方ができるか」ということなんですね。

例えばこのDRの発展で、「DRBFM」という手法が存在しています。もとはトヨタが始めたものですが、今はどこの業界でも通用する言葉です。

DRBFMとは?

「変化点」に着目するのがポイントで、つまり「前回の設計内容と変わった点が他にどういう影響を及ぼすのかを徹底的に洗い出す」というもの。前回までに問題がないなら、今回変わった分だけ完璧に考慮できたら不具合は出ない、という考え方ですね(実際はそんな上手くいかない笑)。

スキルに関係なく誰が設計したとしてもまわりにレビューしてもらうのが基本なので、

  • 設計した側:どこをどういう思想で、なぜそういう設計にしたのかちゃんと説明できるようにする
  • レビュアー側:指摘しまくる(雑)

みたいにどちらの立場でもしっかり役目を果たす必要があります。レビューしてもらう側は色々言われまくるのでしんどいこともありますが、成長のチャンスと捉えられるといいですね!

8.出図:GOが出た図面を他社や他部門へ渡す

release-of-drawing

ここから最後3つは大きめの括りで「開発ステップ」みたいな感じにしてみました。

出図とは設計した図面の類を製作先メーカーや他部門へ提出する作業のことを言います。

図面など設計結果に対してGOを出す工程自体を出図に含めるというのもあると思います。つまり前述のDRなどのイメージですね(特に「検図」などと呼ばれることもあります)。

基板の実装図や3D CADモデルがありましたが、あれらはそのデータを基板メーカーや金型メーカーなどに渡すイメージなんです。

そうすると「その図面データをもとに実際にモノを作る装置を動かせるようになる」というわけなんです。このシステムを「CAM」と呼んだりもしますね。

そうすると基板や製品筐体などの成果物が納品されてくる、という感じです。

CADとCAMが連携して図面からモノが作られる

「出図自体の作業は提出するだけでしょ?」

と思われるかもしれませんが、前述のように検査工程が含まれたり、社内の色んな申請フェーズを通したり、使用する部品を会社のシステムに登録したり(うちは特に大変)など、実はやることは結構多いんです。

往々にしてこういうシステムの類は使いづらいので意味不明なトラブルに見舞われたりなどなど…。こういうところはササッと終わらせたいですね!

技術的には大きな意味はない仕事内容ですが、実際の工数はけっこう取られがちなものなので今回取り上げてみました。

9.試作:量産に向けた一定のステップが存在する

prototype-Trial-production

技術業界で「試作」と言ったときは、主に「検討用などに小ロット生産する」という意味合いが強いです。

一般に持たれる「試作」という言葉のイメージは「いかにもハンドメイドで手作りしてとりあえず1個作ってみましたー!」みたいな感じだと思いますが、実際には試作といいつつも簡易的な量産はするという方が近いんです。

試作をする目的は、

  • 現状での動作確認、実機確認
  • 自分らが技術の検討に使う用の実機を手に入れるため
  • 量産自体の課題を確認するため

などですね。

量産の前に試作をする目的とは?

で、この試作を繰り返して実際の量産に向けて色んな仕事が積まれていくというのが一番大きな仕事の枠組みになると思います。

この「試作と量産の関係」についてもう少し説明してみましょう。

試作工程と量産設計の工程

※クリック/タップで拡大

モノづくりには大きな開発のフェーズというものがあって、それが上図のような感じになっています。

  • 大きく「試作段階」と「量産設計」に分けられる
  • 量産(実際のお客さんに渡る製品の生産のこと)がゴール
  • 試作段階までは完全に開発/設計職が主管
  • 量産設計開始以降は社内の色んな部門へと主管が変わっていく

などが大事な点でしょうか。

今回の記事は「開発/設計職に人ってなにやってんの?」なので、基本的には「試作段階と量産設計の半分くらいまで」みたいな感じになる気がします。相変わらず具体的な線引きはありません。

実は僕らの手元に来る完成品より以前にも、たくさん似たような生産をしていたんですね!

10.量産設計:どうやってたくさん作れるようにするか?を考える

math-productions-engineering

最後は量産設計。

さっきの図で言う

test-prototype-production-and-math-production

ちなみに「ES」はエンジニアリングサンプルの略。僕ら「開発/設計職用」みたいな感じですね。

この範囲にあたります。

なぜこんなに何度も同じような生産の練習をするかというと、もし本番の大量生産で何か失敗があったら絶大な損失になってしまうからに他なりません。

  • まずは実際の仕様を実現できるか手動で生産ラインを作ってみて…
  • 今度はそれをほぼ自動化して上手くいくか見て…
  • 実際の金型(治具など)がちゃんと使えるか確認して…

などのように段階を追ってチェックしていく必要があるんですね。まどろっこしいですが、これはほぼもう定式化された流れだと思います(業界によってはこんなに段階数は多くないかも)。

それと、さっきもちょろっと言ったように後半は主管部門が僕たち開発/設計職ではなくなっていきます。

量産設計の工程ごとに主管部門が変わっていく

各フェーズで色んな部門からの視点が入るようにすることも、段階を分けている大きな理由です。最後は神頼みみたいになってますねw

しかし最近のモノづくりの流行りは「設計だけやって実際の量産は外に丸投げ」にシフトしてきてはいます。自社工場での生産というのはコストも上がってしまうため、中国や台湾のメーカーに量産だけやってもらうということですね。

勘違いしてほしくないこと

ここで言う「中国や台湾のメーカー」とは、一般に言われる「品質が悪いメーカーの代名詞」としてのものではありません。量産自体をプロとして請け負っている素晴らしい会社はあっちにたくさんあります。彼らの技術力は凄まじいものがありますよ。

無事にここが滞りなく進むと、いよいよ完成品が世に流通することになります。技術職やモノづくりの一番の幸せで楽しい瞬間です!!

これが何よりのモチベーションとなるのは間違いないと僕も強く思います。

技術職は魅力たっぷりな仕事ですよ!

ざっと10個の区分けで、開発/設計職が主にやっている仕事内容を説明してみました。

おそらく他の普遍的なサイトよりはずっと具体的なイメージが湧いたんじゃないかと思います!これでもまだ具体例を挙げていない方なのですが、身バレしない範囲で具体化していくのはとても難しくて…。嘘を書くのはもってのほかですし…。

「技術職」という言葉はよく聞くわりにとてもふわふわしていて抽象的だし、いざ考えてみると定義も本当に曖昧で僕もいっつも困ります。

そんなとき、「実際の開発や設計の人たちはこういう仕事をしているんだよ」という説明をするならどうするかな?と思ってこの記事にまとめてみました。本当はもっと書きたいですが長すぎるとうざいでしょうしこのくらいにしておきます…。

技術職はとても魅力のある仕事です。このブログでは良いところやメリットをリアルな視点でたくさん書いてありますので、転職先を検討している方はぜひどうぞ!

とりあえず リクナビNEXT みたいにマジで登録が1分で終わるような転職サイトに登録しておくと何かのきっかけが訪れるかもしれません。無料だし、特に損はないのでやっときましょ。

リクナビNEXTに無料登録して求人案件を見てみる

無料!めんどい手続きなし!

今回はこれで終わりです。また!

みるみ
みるみ

ブロガー、ソフトウェアエンジニア。

この「みるめも」というブログの筆者です。

この記事へのコメント
コメントはまだひとつもありません :)

新しいコメントを書く

  • 必須項目はコメント本文のみですが、お名前はぜひご記入いただけると嬉しいです。
    ※メールアドレスを書いた場合も公開されることはないのでご安心ください。
  • 特定のコメントに返信したい場合は各コメントにある「返信する」ボタンからどうぞ。
  • コメントはこちらで承認の作業を行うまでは表示されません。ご了承ください。
    ※ここ数年スパムが激化しており、誤って削除されてしまうケースが増えてきました。スパムボックスも毎日自分の目で確認するようにはしているのですが、どうしても限界があります。確実に僕に連絡を取りたい方は メールTwitter からお願いします。