当方は実務未経験で、エンジニア就職を目指している人間です。
実務を経験してからわかることが99%だと思いながらも、先日友人のためにLPを作る中で、今での職歴等から持っている仕事に関する考え方と目指したいエンジニアの方向性が繋がってきて、ああやっぱフルスタックエンジニアっていいなあと思ったので整理のために文章を書くものです。

※技術的な内容は殆ど出てきません。
※簡単にフルスタックとか言うなとか言わないでください。僕もそう思います。でも目指したいと思っちゃったんだもん。

ちなみになぜフルスタックを目指したいと思ったかというと、ビジネス的な価値をより高くうみ出すため、これにつきます。

1.略歴

エンジニア転職を志す前に、約7年社会人をやっていました。
キャリアとしては銀行営業5年→ITベンチャー財務経理2年という流れでして、一貫してお金の面から経営をみてきたキャリアになります。
このキャリアを経る中で「ビジネスやそれを生み出すプロダクトに直接携わりたい」と思うに至り現在エンジニアを志望しています。
また、エンジニアだと1人でも稼ぎたい！的な人も多いと思うのですが、経営分析的な仕事をしていたため「組織って面白いな」という思いが強く、組織のメンバーとして働きたいなあと思っているタイプの人間でもあります。

過去の職歴から学んだことは色々あるのですが、それぞれ１個ずつ挙げると以下の学びがありました。

銀行営業で学んだこととしては「ビジネス上の価値とは、相手が気付けていないニーズをこちらで発掘し、満たすこと」

ベンチャーで学んだことは「ビジネスは一気通貫なので、浅く全領域への理解を持ちつつ自分の専門分野への強みを持つことがベスト」ということでした。

2.今回のきっかけ

この様なLPサイトを作ったのがきっかけでした。

友人がドキュメンタリーを30本撮って、毎週Youtubeに挙げていくという企画を初めまして。
それを横からみていて、「コンテンツが溜まってきた時にどれをみてみようかな？と選べるサイトがないと見る側は不便なのでは？」と利用者目線で思ったので彼に声をかけ、制作したというのが流れでした。
（言ってしまえば提案営業して受託開発した、みたいな感じですね）

これは本当に簡単なLPサイトなので、かなり簡単につくれました。Contentful(ヘッドレスCMS)＋S3＋CloudFrontで公開しています。実際別で作っているポートフォリオ(CRUD機能いれた基本的なやつ）より相当簡単でした。

ただ、「実際に他人が使い、他人が訪れるサービス」を作ったことで、かなり勉強になったなあというのが感想です。

具体的には就活用のポートフォリオに比べ、常に以下のことを考えて作業してたんですよね。

①友人にとってどういう運用が良いのか

僕自身が扱いをわかっているだけでは不十分なわけで。
ノンプログラマーの友人のためのLPと言うところで、「簡単に投稿・編集ができる」・「ランニングコストが安い」という条件を満たすべきだなというのが念頭にありました。
僕自身があまり経験のない中で、前もって彼に予算感や投稿方法の共有を簡単にできる必要もあるわけで、そうした発想の基に考えて行った結果、Contentfulを利用するという結論に至ったわけです。
(今回は単発の企画ものなので、コンテンツが増え続けることも想定されないな、という前提で考えれたというのもContentfulにした理由の一つにあります。無料版はコンテンツ数の制限があるので。）

②見る人にとってどうあるべきなのか

これは当然まだまだ勉強中ですが、知らないユーザーの人目に触れるわけで、当たり前なんですがどういうデザインであるべきか？をひたすら考える作業になりました。
例えばYoutubeやnoteに遷移するためにあまりに多くの工程を挟むのは見る側からしてよくないよなと思い、アイコンは各コンテンツトップにも、コンテンツ詳細を開いた場合にも配置しています。
「文字情報だけに頼らないように情報を伝える」ということも意識したことですね。当たり前なんですが実際に人がみた時どう思うだろう？と考える姿勢自体がかなり勉強になりました。

表面を作っただけなので制作自体は簡単なものですが、これらのことを考えながら作業したというそれ自体がとても勉強になったというのが今回の感想です。

3.フルスタックいいなあと思った理由

こうした経験があった時に、今までの職歴での考えと色々リンクしまして、「技術の話を知らない人とあくまでビジネスの目線で会話をする必要がある」という風に感じたんですよね。

銀行時代の経験から相手の潜在的なニーズを発掘するのが価値創造だなあと思っているのですが、この職種でそれをやるには
今やろうとしてるビジネスが「何のために」・「何を目指しているのか」・「どう変化していきたいのか」を理解した上で、「技術的にどうアプローチするべきなのか」を提案していく必要があるんだな、という風に思ったわけです。

まあ簡単に言ってますけどめっちゃむずいのはわかってます。でもそれが楽しいところだよなとも思うわけです。

で、ビジネスのためにできる提案の幅を増やすために全ての工程にかかわっておきたいなと思うわけです。

フロントエンドはわかりやすく「どうすればみやすいのか？」等エンドユーザーへの遡及に必要ですし

サーバーサイドは利用者が「どういうデータ抽出をビジネス上必要なのか？」ということを考えた上で提案できなきゃだと思いますし

アーキテクチャは利用者のコストシナリオに寄り添って考えていく必要があると思うんですよね。

これ全部、ビジネス目線で考えるなら自分の感覚・考えをもっとく必要があるなあと（全てに一線級じゃなくていいと思いますが、感覚値はもっておく必要があるなあと）

要はビジネスに対する有用なアプローチをしていくためには全領域触れとかないといけない気がした、というのがここまで冗長に書いてきたことの結論になります。

ちなみに組織がめちゃくちゃうまく機能してるなら1人で担う必要はないですよね、それぞれの領域のプロが集まればいいわけで。
でもみんな人間なので、他領域に対する敬意を持つことも踏まえ触れておいた方がいいよなあとも組織論的な見方からも思うわけです。

元々ビジネスって事業って面白いなあという風に思ってキャリアを経てきましたが、ビジネスの面白さって「他者のニーズを満たす」という突き詰めると貢献性の部分の楽しさに繋がっていると思っていて。
プログラミングのいいところは、プログラミングそれ自体がやっていて個人的に楽しいという「自分の欲求を満たす」という根源的な楽しさもかなえてくれるところであって。
自己承認と他者承認の両方を仕事で満たしうる、という所がめっちゃいいなと思っているわけです。

最近足元の地道な勉強が続いていて自己承認にバランスが寄りかかってきたな、と思ってる中で他者承認について思い出すきっかけになったのでとりまとめたものです。
さあまた勉強しよ。