エンジニアリングをレストランの厨房に例えて説明してみた
CASTER BIZ recruitingさん主催の採用アドベントカレンダーの12日目を担当します。HRBrain VPoEの川田浩史です。
キャスターさんと私は一緒にHRBrainの採用活動を頑張る仲間という関係性でして、具体的な取り組みや雰囲気はこちらの記事を見ていただくと伝わるかなと思います。一緒に仕事しやすく、非常にオススメです。
さて、今回の記事で何を書こうかなと悩んでいたんですが、キャスターの採用仲間である三市さんから「今回のアドベントカレンダーで川田さんが唯一のエンジニアですよ！」って教えていただきました。
なので今回はエンジニアとして、エンジニア採用を頑張っている非エンジニアの皆様に向けて、
エンジニアリングをレストランの厨房に例えて簡単に理解する
ことを目指した記事を書こうと思います。
背景
弊社では2019年10月頃からエンジニア採用に本腰を入れ始めました。
元々私は7年程度バックエンドのエンジニアとして働いていたこともあり、自分自身でエンジニアを探したり、メッセージを書いたり等々、採用にまつわる様々なことで困ることはそんなにありませんでした。
一方で、日程調整、細かいメッセージのやりとり、履歴書職務経歴書の管理、内定通知書の準備、入社前のPCの用意等々、重要かつ細かい作業が積み重なって、1人の限界はすぐにやってきました。そのため社内外含め様々な人と連携していく必要がありました。
いろんな方と話をしていて気付いたのは、非エンジニアの方は思っていたよりもエンジニアリングを理解していないということでした。
理解しようとしているがよく分からないというケースはまだ良くて、「エンジニアって魔法使いみたいだよね（何やってるか分からないけどすごいね）」と、そもそも理解することを諦めているように思える方もいました。
その気持もすごく良く分かります。分からない単語が多くどこから着手したらいいか分からないし時間もかかるので、とりあえず表面の理解に留めるしかないという状況なのかなと思います。
一方、採用だけに関わらずチームでやることはなんでもそうですが、相互理解を諦めてしまった時点から断裂が生まれはじめて、気付いたときには取り返しが付かなくなります。
ということで、今回の記事では「エンジニアリングのことを理解したい、でもどこから知ればいいのか全く分からない」という方に向けて、分かりやすく解説することを目指します。
ターゲットとゴール
ターゲット: 非エンジニアかつ、エンジニアと一緒に仕事をしているけどエンジニアリングのことがよく分からない方
ゴール: スマホやPC上でどのようにしてアプリケーションが動いているのかの概要を理解でき、またどの領域でどの職種のエンジニアが活躍しているかがなんとなく分かること
それでは早速説明していきます。
登場人物(モノ)
これだけだとよく分からないので、順番に説明していきます。
レストランのよくある風景
まずはエンジニアリングの要素を完全に排除して、レストランの流れだけを説明します。
一点、本来であればテーブルの担当とテーブル-厨房間のやりとりをする人は同じになりますが、今回は諸事情で別の人が担当するということにします。
1. お客さんが、テーブル担当の人に注文を伝える
2. 注文内容が、運び屋を介して料理人に伝わる
3. 注文内容を聞いた料理人が、注文の内容がメニューに存在するかどうか、注文した人にアレルギー等ないか確認する
4. 注文した内容と、アレルギー等の個別の情報を元に冷蔵庫から材料を取り出す
5. 材料を使って調理する
6. 完成したらある程度お皿に盛る
7. 料理が、運び屋を介してテーブルに運ばれる
8. テーブル担当の人がお皿をキレイに並べたり、蓋を開けたり、お箸を置いたり等々準備をする
9. いただきます
上記のステップは、誰でも理解できるかなと思います。実は(お察しの通り)、スマホやPCでWebページを開く際の流れも、上記と全く同じです。一つずつ解説していきます。
エンジニアリングの要素を交えた解説
1. お客さんが、テーブル担当の人に注文を伝える
ユーザーがブラウザを介してHTTPリクエストを投げます。
ブラウザの検索バーで「https://www.google.com」と入力してエンターを押すことや、Webアプリケーションの何かしらのボタンをクリックすることで、ブラウザがHTTPリクエストを投げています。
HTTPというのは送る側と受け取る側でのやりとりのルールで、電話番号でいうところの「0-市外局番-市内局番-加入者番号」というルールと似たようなものです。
2. 注文内容が、運び屋を介して料理人に伝わる
インターネット環境を通じて、どこか遠いところにあるアプリケーションサーバにリクエストを伝えます。
3. 注文内容を聞いた料理人が、注文の内容がメニューに存在するかどうか、注文した人にアレルギー等ないか確認する
アプリケーションサーバが、リクエストの内容に不正がないかチェック(バリデーション)したり、ログインするタイプのアプリケーションであればユーザーが誰かを特定します。
ログインするタイプの場合、その人のユーザー名や権限など、サービスごとに知っておくべき情報をリクエストを受け付けた時点である程度把握しておきます。
4. 注文した内容と、アレルギー等の個別の情報を元に冷蔵庫から材料を取り出す
リクエストの内容と、ユーザー情報を元にDBから情報を取り出します。
アプリケーションからDBに情報を取得するためのコマンドをクエリ(query)と呼び、クエリを叩いて情報を持ってくる、といった表現をします。
5. 材料を使って調理する
DBから取り出した情報はそのままだとユーザーにとって情報量が多かったり、整形されておらず価値が低い状態なので、リクエストやユーザー情報に基づいて表示すべき情報に整形します。
6. 完成したらある程度お皿に盛る
アプリケーションサーバ側でDBから取得した情報を整形し終えたら、最終的にブラウザが解釈できる形に整えます。
7. 料理が、運び屋を介してテーブルに運ばれる
インターネット環境を通じて、ブラウザに必要な情報が返されます。
ここでの情報というのは、HTML、CSS、JavaScript、画像、JSON等です。
特にHTML、CSS、JavaScriptはブラウザに何をどう表示させるべきかという指示書の役割を果たします。
8. テーブル担当の人がお皿をキレイに並べたり、蓋を開けたり、お箸を置いたり等々準備をする
HTMLにはお皿の配置や小皿と大皿の関係性、CSSにはお皿自体のデザインや盛り付けに関わる見た目の美しさに関わること、JavaScriptには「お客さんが箸を落としたら替えを持ってくる」など何かのアクションきっかけで発生するイベントの指示などが書かれています。
これらの指示内容に沿って、テーブル担当スタッフがお皿を並べたり食べるための準備をするように、ブラウザが頑張って表示します。これをレンダリングと呼びます。
9. いただきます
ユーザーに無事に表示され、閲覧します。
各エンジニアの役割
では1~9のうち、フロントエンドエンジニア、バックエンドエンジニア、インフラエンジニア、QAエンジニア等各役割の人たちはどのように関わっているのでしょうか。
■フロントエンドエンジニア
テーブル担当(ブラウザ)への指示書を作る人です。基本的にはHTML、CSS、JavaScriptに関わる何かをやっています。
非エンジニアのみなさまもフロントエンドの世界がここ最近めまぐるしく変化しているのを感じていると思います。できるだけ分かりやすく説明してみます。
1. 料理をワンプレートで提供していた時代
最もシンプルなやり方です。注文を受けて、その都度1つのお皿に様々な料理を乗せて提供します。リクエストの度にHTMLを生成してユーザーに返却するやり方です。
2. ワンプレートの中に一部取替可能な小皿を用意した時代
まずワンプレートを提供するのはそのままなんですが、中に小皿を用意してそれだけ作り直すことが可能になりました。
ワンプレートのみで提供されていた場合は「やっぱり餃子を唐揚げに変えてほしい」という要求があった場合に全ての料理を作り直す必要がありましたが、小皿を用意する技術が生まれたことで、餃子のお皿だけを作り直すことができ無駄なくスピーディに提供することができるようになりました。
今私はAjaxの話をしています。
また同じ頃jQueryというライブラリが誕生し、簡単に料理や小皿を扱えるようになりました。これまではフロントまわりがシンプルだったので同じ役割の人がバックエンドもフロントも担うことがほとんどでしたが、この頃あたりから明確に分かれ始めました。
3. ミールキット戦国時代
技術的に新しいことがいろいろできるようになった結果、フロントエンドの技術がどんどん複雑化しました。関わる人数も多くなり、秩序が必要な時代がやってきます。フロントエンドのフレームワークが誕生し始めました。
パッケージ化されたミールキットを使うことで、関わる人数が増えたり担当が変わってもある程度キャッチアップしやすくなりました。
4. テーブル担当への指示書を分かりやすい言語で書けるようになった
「何かのアクションきっかけで発生するイベントの指示」等をする役割だったJavaScriptですが、実はこの言語はなかなかに貧弱で、そのまま指示書を書こうとすると回りくどい説明をしないといけなかったり、同じ意味を持つ別の言葉で表現できてしまったりと、何かと不便でした。
そこに理解&書きやすい言語が登場し、その言語をJavaScriptに翻訳する仕組みが生まれました。
この理解&書きやすい言語がTypeScriptです。他にも似たような性質を持つ言語は複数ありますが、2020年12月時点だとTypeScript一強です。
5. ミールキットが進化した
お客さんからの要望に細かく対応できるように頑張ってきたところ、当初のミールキットを使うだけでは辛い状況になってきました。
ミールキットを使って麻婆豆腐を提供したあとで「豚ひき肉は宗教上の理由で食べられないので大豆ミートに変えたいです」と言われた場合に、麻婆豆腐の中から豚ひき肉を1粒ずつ排除して、エキスを入れ替えるためにスープを一度全部濾して作り直して、みたいな苦行をやっていました。
そこで新しく仮想DOMという概念が爆誕しました。料理の中の豚ひき肉部分を仮想肉として扱うことができ、理想状態を入れ替えるだけでその差分を埋める作業はフレームワーク側がよしなにやってくれるという素敵な世界がやってきました。
無理矢理感が否めないですが、なんとなく理解していただけたら嬉しいです。
■バックエンドエンジニア
料理人(アプリケーションサーバ)への指示書を作る人です。
注文がメニューに存在するかを確認する方法、注文を受け取った際のお客さんの特定の方法、冷蔵庫の中身の整理の仕方、冷蔵庫からの効率的な取り出し方、的確な調理方法、といったことを担っています。
バックエンドだと言語の違いがよく話に挙がると思います。言語の説明を細かくするとかなり長くなりそうなので、静的型付け言語と動的型付け言語の違いだけ簡単に書きます（この話は言語全てに言えるのでバックエンドに限らずではありますが）。
静的型付け言語
食材に適した計量カップや包丁など道具を固定します。例えば小麦粉を扱うときはグラムを計るのでボウルと計量器を使うし、人参であれば薄刃包丁とまな板を使います。
食材(変数)に対して適切な道具(型)があらかじめ決まっているので、調理を始める前の段階で料理長(コンパイラ)がチェックして、もし間違った道具を使おうとしていたら「不適切な道具を使っている」ということに事前に気付くことができます。
動的型付け言語
一方、動的型付け言語は全ての食材に対して同じ道具を利用します。三徳包丁、ボウル、まな板、そのくらいあればだいたいいい感じに作れるでしょ、といった感じです。
静的型付け言語に比べると細かいことを気にしないので早く料理が作れますが、「小麦粉20g使うはずだったのに間違って20cc用意してしまって、お菓子づくりに失敗した」みたいな現象が容易に発生してしまいます。
簡単な野菜炒めとか関わる人数が少ない料理であれば動的型付け言語が向いているだろうし、高品質な料理や人数が多く関わるものであれば静的型付け言語が向いています。
ちなみにJavaScriptは動的型付け、TypeScriptは静的型付けで、最近TypeScriptが好まれる理由はまさにここです。結局最終的にはJavaScriptに翻訳されるので裏側では同じ扱いになるんですが、人間が触れる部分が静的型付けでより安全に扱えるので好まれています。
■インフラエンジニア
ガス、電気、水道、キッチンの様々な道具、冷蔵庫本体のスペック等々が滞りなく運用できる状態を保つ役割です。
最近はSREという役割が誕生して、インフラエンジニアとよく混同されがちですが、実際には違います。
個人的な解釈も大いに入りますが、SREは包丁をよく切れるように研ぐとか、厨房の動線を見直して料理人が効率よく動けるようにするとか、あらゆる面でレストランの信頼性を上げることに注力する役割を指します。
SREのやるべきことの1つにインフラエンジニアの役割も含めることができますが、同じようにフロントエンドやバックエンドの役割も含むこともできると思います。
SREの領域はここまでにしよう、というのは会社によって線引が変わるので、それがややこしくなっている要因かなと私は考えています。
■QAエンジニア
調理後の料理に虫が混入していないか、注文通りに提供できているのかを確認することはもちろん、虫が混入しづらいレシピってないんだっけ？とか注文を間違えない方法考えようよ、とかそういった上流工程も担っています。
おわりに
ここまで読んでくださってありがとうございました。
私がエンジニアになりたててで学習し始めの頃、1つ分からないことを調べようとしてググると10個の新しい分からないことが出てきて、それを更に調べると次は100個…というようにどんどん分からないことが出てきて非常に苦労しました。最初に何を知りたかったんだっけ？といつも迷子になっていました。
数年エンジニアとして仕事をする中で、エンジニアリングってエンジニアにしか分からないようなことは実はあまり無くて、似たような困難は世の中のいろんなところであるので、例えて分かりやすく説明できるんじゃないかなと思うようになりました。
その一つがレストランだったので、今回このような例え話をしてみました。
この記事を読んで、少しでも理解できた部分があれば嬉しいですし、これをきっかけにより詳しく調べてみたいなと思っていただけたらより嬉しいです。
エンジニア採用はどこもずっと厳しい状況が続いていますが、非エンジニアとエンジニアの壁がなくなってお互い気持ちよくコミュニケーションが取れて、転職しようと思った人たちができるだけ相性の良い会社に行けることを祈っています。
おしまい。