通常よりロードが長引いています。 もう少しお待ちください。
データを取得することが出来ませんでした。ページを再読み込みしてください。
通常よりロードが長引いています。 もう少しお待ちください。
データを取得することが出来ませんでした。ページを再読み込みしてください。
5年続けたデザイナー職を辞めエンジニアに転職し、10ヶ月が経過しました。デザイナーからエンジニアへの転職はあまりないパターンかもしれないので、同じような転職を考えてる人に向けて自分が大変だったことなど共有してみようと思いました。デザイナーと言っても、前職は3Dゼネラリストに近い業務でしたのでグラフィックデザイナーとは少し違うかもしれません。絵作りが主な業務内容でしたのでデザイナーという括りにしています。
エンジニア「設計書厳守!設計に無いことを勝手にやるな!」
デザイナー「良い絵を作れ!どうしたら良くなるか考えろ!」
少し極端かもしれませんが概ねあっていると思います。見た目から考えていくデザイナーと、機能から考えていくエンジニアは重要としていることが違い、突っ込まれるポイントも違います。デザイナー時代にサーバーから正常なデータが送られてこないパターンが十種類以上あることなんて気にしてはいませんでしたから。。デザイナー職で良かったのは主観が使える事でした。自分が良いと思ったアイデアを盛り込めるのは楽しいです。
エンジニアへの転職を思い切ったのは、画像生成AIの登場がきっかけでした。誰でも簡単に見た目のいいものが作れてしまう時代がくる。だったら、デザインもエンジニアリングも両方できるようになろう!と考えエンジニア職を探し始めました。
エンジニア職を始めて一番最初に苦しんだのは徹底的に認識の曖昧さをなくしていく事でした。デザイナー職の時は、指示の曖昧さはクリエイティブに考える機会として捉えていましたが、エンジニア職で設計書にないことをやると、仕様にないことを勝手にやった=バグ扱いになります。曖昧さはまず上司やお客さんと認識を合わせて、設計と異なる事を実装するのであれば設計書から変更した上で実装を進める必要があります。
ただしお客さん側もわからない場合は指示ももらえない中で実装を進めないといけない事もあり、その時は設計書や調整した内容を汲み取り最悪ツッコまれても何故そうしたのか説明できるように実装をしていかないといけない。ここが自分の場合はチーム開発の知識、経験がなかったが為にデザイナー時代の感覚で自分の主観で良いと思うことを実装していった結果、バグを出しまくってしまいました。
もちろん当てはまらない現場もあると思いますが、曖昧さを徹底的に回避していくというのはエンジニアにとって重要だと感じます。確かに車の製造に例えるなら、天井の設計に指示がなかったからって作業員が勝手に車にプロペラつけだしたら空を飛べたとしてもなんだこれはってなりますよね。
デザイナーのように絵作りを重要視する場合、最終的な見た目がOKならコードやファイルの綺麗さはさほど重要視されない。納期ギリギリになり作業ファイルが多少まとまってなくても最終的に上司とクライアントが絵を見てハッピーならセーフ!でした。
しかしエンジニア職ではそうは行きません。画像や動画のように1回納品されれば終わりではなく、アプリとして運用していく必要がある為、整理されていないとアプリを運用する方々、一緒に開発をするメンバーに迷惑をかけます。いかにデザイナーから渡されたデザインを崩さず、運用しやすいコードで、無駄のない処理にするかが肝になります。
エンジニアの方は設計書通りに作ることを厳守するため、デザイン面での細かいケアは必須ではありません。ここでデザイナー的視点を持っていると見た目をいい感じに仕上げる事ができます。ただしそのケアが受け入れられるかどうかは、上司やお客さんとのさじ加減だと思いました。
これはエンジニアになるまで実感が沸かなかったのですが、エンジニアはめちゃくちゃコミュニケーションを取ります。デザイナー時代もコミュニケーションはもちろん必要はありましたが、絵を作るにおいてはかなり自分の主観で考え作業ができたので、エンジニアのように細かく認識を合わせる必要はありませんでした。認識のズレを最小限に抑える為に、みんなが使っている文言と同じ文言を使う。自分の知識で言葉を言い換えない。きちんと書類を読み、意味を理解する。この辺はデザイナー時代とは比べ物にならないくらい徹底するので良いトレーニングになっています。
あとはデザイン会社にいた時は自分の見えないところでプロデューサーがお客さんとの認識合わせを沢山してくれていたのだと思います。エンジニアの場合はコードの内容も確認してもらわないといけないので、お客さん側のコードが読める人と話す機会が必然的に増えます。
これはデザイナー時代から思っていたことですが、熟練のエンジニアの方はコンピューター上で起こったあらゆる問題に対しての勘が鋭いです。自分で作ったアプリでなくても、なんとなく内部ではこう動いてる気がするからこうしたら回避できる、みたいな事をすぐに思いつきます。コンピューターを使って仕事をしていくにはこの勘は役立つと思いました。
デザインもエンジニアリングも両方やる、ゼネラリスト的な方向を目指す限りスペシャリストには敵わないです。なのでスペシャリストになることは諦めました。その代わりに全体的なことを理解できるようになる。これを自分の武器とし、磨いていく事にしました。それでも自分の得意分野は持っておきたいと思っています。
エンジニアへの転職は特にものづくりが好きで手を動かしていたいタイプの人なら向いているはずで悪くないアイデアだと思います。エンジニアリングは仕組みを作る作業なので、デザイナーだけでなく、別の目線を持った上でエンジニアリングの目線が加わるのはキャリア可能性が広がり面白いと思います。エンジニア以外の目線を持っている人しか思いつかない事があると思うので、違った目線を持っていることはキャリアの上で大きな強みとなると思います。
どんな言語でもよいので最低限のプログラミングの知識は持っていたほうが良いと思います。プログラミング言語が1つわかればほかの言語はさほど難しくありません。自分の場合は、デザイナー時代にもウェブサイトや社内で使用するVRのアプリを作らせてもらったりしていたのでエンジニアになる前に少なくとも基礎的なプログラミングは理解していました。
デザイナー時代にも会社のウェブサイトの運用で使っていましたが多くても二人でGitを使う程度でした。これが何十人という規模になってくると、考え方が変わってきます。自分のコードでみんなの使うコードを更新する(コミット、ブランチのマージ等)最初はこの更新がめっちゃ怖いです。自動で生成されたファイルも含め1つ1つが何をしているのかわかっていないと余計な変更がみんなの使うコードに入ります。おかしな変更が入るとバグります。そのせいで他の人が動作確認できなくなり、Slack、電話等が賑わいます。そうなった時は結構精神的にしんどいです。そうならない為にも出来ることなら友達同士でもよいのでチーム開発経験があると違うと思います。
これは自分も勉強中ですが、変更に強く読みやすくバグりにくいコード設計が出来た方が良いです。アプリが大きくなればなるほど重要になると思いました。SOLID原則というものがありますのでよかったら読んでみてください。 https://qiita.com/baby-degu/items/d058a62f145235a0f007
これはどんな職業でもそうかもしれませんが、あなたが真面目で優しい人なら尚更、面倒事と責任を押し付けられます。なんだかんだ理由をつけてこっちのせいにされない様に、自分なりの心を守る術を持っておくと良いかもしれません。デザイナー時代では自分がやったというクレジットが欲しいと思いましたが、エンジニアとしては自分がやったというと何かと後々近い実装範囲でで問題がおこった時に責任を押し付けられることが多いので必要がない場合は自分がやったことは黙っていることが賢いと思いました。笑
これからAIが色んなことを簡単にしてくれるなら、より幅広いことを出来るようになる人は絶対に増えるはずです。その時のために準備として私はエンジニアへ転職をしました。
需要があるかはわかりませんが、同じような考えの方が考えるきっかけになれれば幸いです。
お仕事のご依頼はお問い合わせから受け付けております。