フロントエンドとバックエンドの違いは...答えがあるかどうか！

アプリ開発やプログラミングしていて気づいた発見を今日は書いてみます。個人制作でもチーム開発でも共通する大事な点や苦労する点など。

●フロントエンドとバックエンドの違いとは？
●外装＝答えがない、仕組み＝答えがある
●山を登り切ってから相談するなよ！

フロントエンドとバックエンドの違いとは？

プログラミングといっても幅広いのですが、大きく分けて

●フロントエンド
●バックエンド

に分けられると思います。

フロントエンドは、その名の通り目に見える部分で、「外見」みたいなものです。家でいえば、塗装や装飾などデザインにあたります。

※代表的な言語には「HTML」や「CSS」、「JavaScript」などがあります。

バックエンドは、目には見えないですが裏で動きを制御してくれているもの。家でいえば、ガス設定や排水管などの「仕組み」が近いでしょうか。

※代表的な言語には「Java」や「Ruby」、「PHP」「C#」「Python」などがあります。

どちらかといえば、フロントエンドの方が目に見えて楽しい！いかにもものづくりやん！みたいなこと思っていたのですが、最近知人と話していて気づいたのは、意外と「外装」よりも「仕組み」が好きな方も多いということ。

なぜなら「外装」には答えがないからです。「仕組み」はエラーかエラーじゃないかの2択なので、答えはすぐに分かります。というか、パソコンが勝手に教えてくれます。なのでそっちのが楽という意見です。

お粗末な仕分け方かもしれませんが、文系と理系くらいの趣向の違いがあるのかなと思いました。単純にデザインが好きか好きじゃないかってレイヤーの区別も可能ですが、もっと奥まで考えると「答えがすぐに分かる」という意味では、同じエンジニアでも全然好き好きが違うんだろうなぁと。

Webエンジニアって最近すごい人気らしいんですが、そういう意味でも文系（という表現はあまり好きではないがｗ）寄りの方が志望しているのかもしれません。SEO対策もフロントエンドに入っちゃうらしいので、もうなにをもってエンジニアなのか分からなくなってきますねｗ

結論、クライアントサイドもサーバーサイドもアプリ開発するならどちらも大事になるので、どちらもできたことに越したことはないのですが、自分もどちらかといえば「外装」の方が楽しい派でした。

外装＝答えがない、仕組み＝答えがある

しかし、「答えが無限にあって時間が膨大にかかる」という意味では、確かにバックエンドの方がいいなとも思ってきたのです笑

自分はもともとWordPressというCMSは3年前くらいから触っていたのですが、あれはゴリゴリのフロントだけですし、もっといえばプラグインやテーマでなんとでもなるので、プログラミング知識ゼロで実装できちゃいます。（自分でカスタマイズしたいと思わなければ）

しかし、バックエンドまで知ると、こういう動きが設定してあったのか～とか、rubyとphpって兄弟みたいなものなんだな～とかも分かってきます。データベースの設計や構築、API連携など、WordPressの時にはまったく分からなかった裏の部分が分かってきます。分かってくると、そこもいじれるようになるので、仕組みをつくれる側になれます。

バックエンドは、特に設計が一番大変な気がします。

設計は、家で例えるなら、何階建てで、どこで柱を立てて、どこに電気通れるようにしようとか、事前に考える設計士さんにみたいなものです。しかし、これ、話を聞いていると大半が設計段階のものがそのまま実現するわけではないこともわかります。

というのも、個人製作の場合は実装しているフェーズになって

「あ、やっぱこんな仕様の方が良いな」
「ここはないほうがいいや」

などど気持ちが変わって当初の遷移図から大幅変更になることも。
自分もそうでした。どれだけ事前に詰めたぞと思ってもやっぱり途中で意思が（ポジでもネガでも）変わったりするんですよ。ほとんどの方も経験あるはず！

個人ではなく、顧客であっても途中で要求が変わることがあるので、

「やっぱりこの機能も追加しておいて～」
「頑張ってくれたみたいだけど、ここなくていいよ」

などと現場では指示が変わるものです。

勿論、フロントエンドも影響は出てきますが、バックエンドの方が対応大変だと思います。なるべく要件定義で固めておいて、途中の変更なし一本で進めたいものですが、これが現実なかなか難しいですよね。

山を登り切ってから相談するなよ！

これはなにもエンジニアだけの世界ではなく、デザイナーやコピーライターにも言えることです。あがってきた絵が想定と違った、送られてきたコピーがどれもしっくりこない、などなど。もはや上司に指示された資料作りにおいても同じことがあるかもしれません笑

さすがに実物の家で同じことは起きませんが、エンジニア世界では「仕様変更」は可能なものなので、顧客も要望追加したり変更したりしちゃうわけですね。

要件定義や設計は、どこの仕事でも大事ですよね。
自分も新人の時に

山を登り切ってから相談するなよ

とよく言われました。
資料作りでも顧客訪問でもなんでも、ふもとの段階でよく相談すること。

そうしなければ、山頂から降りてまた次の山を登らないといけないので、エネルギーと時間の消耗が激しいです汗

ただ、この「要件定義」前に「提案」のフェーズもあります。ここはガッツリ営業の仕事だと思いますが、提案の時にそもそも顧客のニーズを引き出せていないと要件定義すらひっくり返ってしまうかもしれません。大元をたどると、営業の方でしっかり顧客の目的や潜在ニーズもヒアリングしておくことが大事だということにもなります。

HP制作をチームで関わったことがあるのですが、特にHPの設計やデザインになると皆で「これがいい！」「こうでしょ！」と言い合っている間に時間があっという間に過ぎてしまいます。皆で満場一致で決まったことも、翌週になってとある意見からがらりと変わることもあります。そんな連続なので、こういうフェーズはおそらく職人気質の方には合わないだろうなとも思いました笑

ということで、フロントエンドとバックエンドについてふと思ったことでした。それではまた！