【主にCA向け】未経験エンジニア転職支援のためのIT業界見取り図
発端
弊社CAの方にわたしのキャリアやIT業界知識についてお話しする機会がございました。
お話ししていくなかで「これ地味に需要あるのでは……？」という仮説が生じたので、「とりあえず実際に書いてみるか！」と行動に移したわけです。
注意
筆者について
全くのIT未経験状態から中途でSES企業に入社し、エンジニアになった人物です。現在は株式会社ROXXで働いています。
領域的にはサーバー・フロント・インフラくらいの順で多く触る、なんでも屋さんです。ファシリテーションやリサーチも行います。
本項は、上記のような人間が、あくまで自分の知識範囲と実感とを提出する内容となります。したがって、内容に一般論との乖離が存在するかもしれません。その点、ご承知のうえお読みくだされば幸いです。
ちなみに過去わたしにITエンジニアへの未経験転職を相談してくる友人・知人が数名存在しましたが、概ねこのようなことを伝えています。
ご購入に際して
以下の点について、予めご了承ください。
本稿はあくまで一エンジニア個人の知識を提示する記事です。所属会社の見解を代表するものでもなく、あくまで一個人として展開しているコンテンツとなります。弊社が関連したのは、「執筆のきっかけ」のみであり、品質面の責任も筆者のみに属します。
そうした執筆経緯もあり、また入念な内容チェックも行いましたので、NDA抵触事項等、コンプライアンスに反する内容は含まれていません（ご安心ください）。
無料公開を予定していますしました。本稿はある種の自己資産でもあり、しばらくしたら「公開された発信」として扱いたいのです。
目的
大目的は以下のような構造となっています。
キャリアドバイザーがITエンジニア界隈に対する解像度を上げるために読む最初の資料とする
「ITエンジニアになりたい」という求職者にCAが提供できる情報量を増やす
求職者のwillを引き出したり、問い直したりするためのツールを提供する
内容的に、未経験の人のやる気に水を差しかねないことが書かれている気もしますが、それを認識してなお「ITやりたい！」「プログラミングを仕事にしてみたい！」という人に支援が届けばいいなという気持ちをもって本稿を執筆しています。
対象読者像
未経験ITエンジニア転職の支援を行っている／行う予定のキャリアアドバイザー
ITエンジニアに転職したい未経験者
上記に該当する方は、この拙稿を読んで一定の価値を感じてくださるのではないかと思っております。
特に、求職者から「ITエンジニアになりたい」という言葉を引き出したときに、次の打ち手が上手く出てこない状況の方にはおすすめできます。
IT一本に絞るにせよ、別業界を併願するにせよ、いずれにせよIT業界やエンジニアについての知識がないと、判断しにくいものと思います。
逆を言えば、既に業界について熟知していらっしゃるCA様には向かない可能性が高いです。業界知識のないCAに向けた資料として想定されているためです。
ここでいう「エンジニア」とは
とりあえずITエンジニア、特にシステム系・Web系のそれに限定します。組み込みエンジニアなどもプログラミングを行いますが、筆者の見識の範疇を超えます。
また、「機械エンジニア」などの求人も多く存在すると思いますが、これらも外します。筆者の専門外であるのと、業務範疇やキャリア形成が結構異なってくるためです。
ターゲット企業の分類
厳密な定義はさておき、「だいたいこういう業務感で、だいたいこういう分類が成立しているよ」くらいの内容を説明します。
SES企業
業態としては客先常駐・派遣なんですが、業界ではSESと呼称することが多いのでそれに習います。
大掴みで言えば、客先に開発・運用・保守の人員を派遣する企業となります。業務委託契約・準委任契約などを締結することが多いのかなと思っています。
当然ではあるのですが、客先常駐の手前に営業フェイズが存在します。案件獲得から商談（成約前に営業とエンジニアとがクライアントと"商談"を行うという業界慣行があります）が行われるんですね。
SESは人員の増加が収益の増加に直結する事業形態です。
研修制度を設置している企業が多く、比較的に未経験採用も活発なので、未経験で応募する場合は大抵SES企業になるかなと思います。
エンジニア視点でのメリット
比較的受かりやすい
人員増加へのインセンティヴが企業側に常に存在するため、未経験市場まで踏み込んだ採用が行われている
業務内容も営業次第で選択可能で、本人がスキル不足でも何かしらのアサイン先を見繕いやすい
ひとつの現場で（仕事や人間関係が）上手く行かなくても、転職をせずに他の現場に移ることができる
様々な工程レイヤーや技術に、短い間隔で触ることができたりもする
長期的な関係構築よりも、技術にフォーカスして仕事がしやすい
様々な現場をみることで、個々の現場の風習を相対化して見る能力が高まる
研修制度が充実していることが多い
受託や自社は最初からOJTになる場合が多いが、SESは研修のみに没頭する時間を設ける場合が多い
より高い単価で営業するためであり、これもまた企業側にインセンティヴが存在する
エンジニア視点でのデメリット
炎上案件へのアサインが多い
クライアント企業が急いで人手を必要する状況である場合が多いことを考えると、ある種自然なことではあります
火消し能力を身に着けてプロジェクト型業務で大活躍する人材も稀に？ 頻繁に？ 発生します
自社と客先とで板挟みになるケースがある
アサイン方針や評価について、現場と自社とで認識の齟齬が起こったりすることがあります
現場評価はよくアップセルも実はできているのに、本人への給与反映がないというケースも存在します
企業によっては全然開発案件に入れないことがある
簡単な手作業オペレーションや、仕様書が既に存在するテストをやりスクショを取り続ける現場にアサインされる場合もあります
企業毎の営業方針実態を吟味しつつ、求職者のwillと調整するのが良いかと思います
ただ、これはある種メリットでもあります。業界に参入しつつ、追加で学習時間が得られるという見方もできるからです
受託開発企業
クライアント企業から依頼を受けて、業務委託・準委任・請負などの契約を締結し、クライアントへ設計書・仕様書・ソースコード等の成果物を納品する開発形態となります。ただし、これは元請けの場合です。
下請けの場合、より上流の会社から作業の一部ないし全部を移譲される形となります。この業界構造を「多重下請け構造」と呼びます（開発の鈍化・中間搾取の温床となりますから、筆者は基本的に悪しき風習だと思っています。ただ、超大規模な開発（たとえば、メガバンクの基幹システムとそのサブシステムの開発）になってくると一定仕方ない面も出てきます）
SIerという言葉について
「システム開発や運用などを請け負う事業・企業」という点で受託開発と対象領域は一致する言葉ですが、特に「一次請けとなる、比較的大きな企業」を指して言う場面が多いかと思います。
SEとPGという職種分割について
基本的に、上流（要件定義・設計）をSE（システムエンジニア）、下流（アプリケーション実装・運用・保守・テスト）をPG（プログラマー）がやるという職務分掌が、ウォーターフォール型の開発工程を有する企業では多く採用されています。
ただし、この分割線は例えば弊社の場合だと特に存在しなかったりします。設計・実装のいずれもこなすエンジニアが多数です。アジャイルプロセスにそぐわない、そもそもそんなに自明な境界線ではない、というのが要因かと思います。
また、SE, PGに上下関係を見出すような思潮も存在していた／いるのですが、些か短絡的な理解と言わざるを得ません。SEが実装の都合を全然理解しないまま雑な仕事をしており、その分をPGが巻き取ってどうにかしているような現場も存在します。この場合、価値が高いプレイヤーはPGの方でしょう。
ただ、一般的にSEの方が給与レンジは高いところに設定されている、ということはあるかと思います。ところによっては激務なので、必ずしも高待遇と呼べるかはわかりませんが……
エンジニア視点でのメリット
自社開発企業よりは受かりやすい
SESよりは選考基準が高めだが、いわゆるWeb系自社開発よりは受かりやすい
元請けであれば、要求開発・要件定義などの上流工程からプロジェクトに参画できる可能性が高くなる
上流工程経験は、市場価値として比較的大きな要素になるかと思います
企業によっては新規開発案件も多く、ゼロイチフェーズに携われる場合がある
自社開発の場合、既にメインプロダクトがPMFを得ていて、その拡張的な開発や保守を行う場合が比較的多いです
新規にアサインされる可能性は受託と比較して少ないだけであり、存在はします
エンジニア視点でのデメリット
SESに比べると少々受かりにくい（メリットの言い換えですね）
いわゆるWeb系自社開発よりは受かりやすいが、SESよりは選考基準が高め
商流の都合上、炎上案件がそこそこ多い
技術スタックや文化は固定的である
SESのような形での大胆な異動はできなくなる
ただ、これもメリットとして認識できて、あまり浮気せずに専門性の向上を行う方向で考える場合もあります
下請けだと状況のコントローラビリティが低くなる
上流の言いなり、はわりかし存在するかなと
会社の成長性の見込みが小さい
中小規模の受託開発会社を想定すると特に顕著。スケールアップではなくスケールアウトで横展開するしか成長ラインを作れないのが要因として大きい（要は案件受注数を高めて、その分開発人員を増やすという、労働集約的な利潤追求モデルであるため）
大手SIerの場合は、「既に大きいため」成長の余地がなかったりする
自社開発企業
自社のプロダクトを、自社内のBizSideメンバーと協力的に開発・運用してゆくことが主となる企業・開発体制です。
エンジニア視点でのメリット
エンドユーザーやビジネスサイドとの距離が近い
受託の場合は、「ビジネスサイドはお客様」だったりするので、ラディカルな提案は比較的しにくいですね
自分自身がプロダクトに対しての広い意味でのステークホルダーとなる
受託の場合、納品して案件クローズ、他社で保守するなどのパターンがあり、その後のビジネスに介在できなかったりします
企業風土やプロダクトの内容の指向性が強い
自分にあっていれば、かなり居心地のよい空間になると思います
給与・待遇が良い傾向にある
資金調達などの大型原資を背景とした雇用戦略が浸透している、というのがあります。スタートアップに顕著。メガベンチャーの場合は既に出ている巨額の利益が原資
特定ドメインに対して集中的にキャッチアップする方針で、ビジネス知識をつけていくことができる
逆にこのあたり幅広くの方がいいなら受託がオススメです
エンジニア視点でのデメリット
未経験で受かるのは至難
経験者採用しかそもそもしていない企業が多く、即戦力が求められている
逆にいえば、即戦力レベルであることを示したり、「数ヶ月の育成をする価値がある人材だ」という認知を得る動きができれば受かる可能性はあります
シード期とかから入る場合でない限り、メインプロダクトのゼロイチはなかなか経験できない
企業風土やプロダクトの内容の指向性が強い
ただし、これも当然メリットとして裏返しに認識可能な項目です
ソフトウェア開発工程について理解する
V字モデル
V字モデルについては、以下の記事がわかりやすいので自分で書くよりもお読み頂く方が良いのかなと思います。
https://webrage.jp/techblog/v_shaped_mode/
元未経験エンジニア採用担当としての所感
筆者は前職で採用担当も行っておりました。書類選考から一次面接までが担当範囲で、その次は最終CEO面接でした。わたしが通す場合かなり強めに推してCEOにトスアップしていて、だいたい入社決定していた気がします。要は厳しめの担当だったのではないかなと。
現職でもエンジニア面接はやっています（ミドル・シニアが主に面接対象ですね）。自分が推した人が入社したりとかもしていましたが、そもそもが数件なので前職に比べればこのあたりのコミットは薄めです。
以下は、そのような人が書いた資料という認識でお願いします。
どういう観点を重視して選考を行うか
「エンジニアにとりあえず必要な資質」として読んで頂ければ幸いです。
学習意欲があること
ITエンジニアには（というかある程度知的労働を含む全ての職種が本当はそうだと個人的には思うのですが）、絶えず学習していくことが求められます。
コアとなる部分の知識（コンピューターの動作原理、プログラミング言語とは何か・アプリケーションに要求される品質とは何か・ネットワーク特にインターネットはどのようなプロトコルを前提として構築されているか等々）があれば新しい技術にも柔軟に対応し、すぐにキャッチアップすることができるようになるかもしれません。しかし、その土台知識自体が広い範囲におよぶものであり、学習に年月を要します。
誰と競争することになるのか
そして、中長期を考えると、人材市場価値における競合相手は
中高、下手したら小学生の頃からパソコンを触りまくっている
大学で計算機科学等関連領域を専攻しており、知識が既にある
新卒で大手に就職して長期研修で学習している
とかになってきます。一番最後のはNTTデータ・NEC・日立・富士通・日本IBMなどに多く存在し、だいたい高学歴で地頭が良いですね。で、そういう人が新たなチャレンジや待遇変化のためにベンチャー転職とかもしている世界観です。
さて、「努力は夢中に敵わない」は流石に言い過ぎだと思いますが、「夢中」で特に苦を感じずに勝手に身に着けている人間や既に膨大なバックグラウンドを有した状態で就職している人間が多く存在することを認識しておくことは重要です。
ここを認知しないまま就職すると、想定とのギャップが大きくなり、あまり良くない方向の挫折に繋がる場合があります。
上記を総じて考慮すると、学習意欲の比重は高くなります。
手を動かしているか
では、「学習意欲」をアピールするにはどうすればいいかを話します。
学習意欲をみる際に、採用側が手っ取り早く確認できる要素が「手を動かしているか」「見せられる成果物が少しでもあるか」があります。
後述する通り、無料・格安で取り組めるインターネット教材は市場に大量に存在しているので、まずそれをやってみているかというポイントが存在します。適正を見る上でも、一回触ってみることを求職者さんにおすすめするのがいいですね。
また、「ポートフォリオとなるようなソースコード・サービスを自前で作り上げているか」というのも問われる場合があります。特に企業側から直接要求されていなくても、求職者側から提示できたら大きな加点となります。年々、ポートフォリオの平均レベルは上がっていますが、多少拙くてもないよりは遥かに良いです。
それより少しハードルを下げて、プログラミング中に調べた知識をブログ記事等で発信すること、もアリな路線です。
注意点ですが、インフラエンジニア領域は（特にハードウェアを主に触るインフラエンジニアの場合、）ポートフォリオ等の成果物が作りにくいです。実際の環境を組み上げるには、ある程度高額な機材が必要になりますし、それを「持っていって面接で見せる」というような行動は考えにくいからです。代わりに、コンピューター・ネットワーク・OSの学習を行ったり、取得容易な資格の学習を促す形で、手を動かしている状況を作るのが良いかと思います。自分のPCで仮想環境を作成し、そのOSのセットアップを行い、システム管理業務に相当する作業をしてみるなどの学習方針も考えられます。
なお、稀に手を動かす方向よりも、「知識量で勝負する」「異能とセットで売り込む」等の方向で長じているエンジニアも存在します（わたしとか割とそっち寄りです）が、未経験層では基本的にこれってナシですよね。
「結局は仕事であり、そして専門性が要求される」という認識を持っているかどうか
未経験エンジニアによくある業界認識と実態とのギャップをまた綴ります。こうした見解を目にし耳にした後に求職者さんが「夢がないなぁ」となるか、「のし上がったら結構いいじゃん」になるかはまあ、人それぞれかなと。
待遇への期待について
未経験でITエンジニアを目指そうとしている方には、待遇が良いイメージ（「カフェでMac開いて云々でオシャレ」「フルリモートワーク」「高収入」）をお持ちの方が多いかと思います。正直、自分もそういう要素に憧れた面がないわけではなかったように回顧されます。
さて、しかし、この認識は上澄みの出来事……とまでは言わないまでも、まず最初から手に入るものではないです。
単に「足りない（売り手市場である）」というだけではそうした待遇形成にまでは至りません。スキルあってこその出来事です。
逆に言えば、スキルさえあれば転職をはさみつつどんどん待遇を上げていける市場感ではあります。
実際、わたしも「同世代に比べると高めの収入」「やろうと思えばフルリモートで仕事ができる状態」「さらなるスキルアップのために自己投資できる環境」を得ていますね。
これは弊社が作り上げてきた地盤によるところも大きいので、強く感謝しております。
成果責任について
そして、未経験とはいえ仕事である以上、「エンジニアとして一定以上のアウトプットを求められる」という認識は、当然ながら必要になります。未経験でもちゃんとしたものを実装できなければ仕事にならないのです。そのためには自分から粘り強く調べる姿勢がほしいものです。また、業務に必要なコミュニケーションも、当事者意識をもって積極的に行わなければなりません。
まとめ
未経験でなんとなく「ITエンジニアやりたい」と思っている人には、このあたりを認識できていない人が多く散見されます。
もちろん、業務解像度が低いこと自体は何も悪くないのですが、こうしたギャップをその後本人がどう受けとめるかによって、転職やその後のキャリアの成否は変わってくることでしょう。
自分の理解を十分に言語化して伝達するスキルがあるか
コミュニケーション力等のソフトスキル面も当然見ています。
たとえば言語化能力が低いと、以下のような負を生み出してしまうことがあります。
コードレビューにおける提案の曖昧化
仕様に関する調整の難儀
対話の場における、本当は生じなかったはずのディスコミュニケーション
エンジニアであろうと、一定のコミュニケーション能力は求められるわけですね。
また、性格面でキツかったりすると如何に有能でも全体のスループットを下げてしまいかねないのもあり、そこも大丈夫かどうかを探ったりします。
結論
上記全体をさらに抽象化して、「能動性が認められるか」とも言えるかと思います。受動姿勢が強いと、上記にあげた資質の形成に難がある場合が多いです。技術的な面で受動性が出る場合、ほかの面（コミュニケーション等）ではなおさらのことかと思います。
未経験状態から学習するためのリソースに何が存在するか
学校の類
職業訓練校
たとえば厚生労働省 - ハロートレーニングなどのような行政サービスが存在します。
受講時の状況によっては、給付金等の支援も受けられます。
施設・各自治体の募集要項等を読んだ上で応募するのが良いかと思います。
人材紹介の場合、この方法を紹介するかどうかもちょっと難しいところがありますよね。
プログラミングスクール
色々ありますが、現役のエンジニアからすると、大同小異感が否めません。
メリット
メンターを得ることができる
学校のカリキュラムをこなしているだけでもそれなりの知識は付く
デメリット
支払っている金額に対してリターンが少なすぎる
大抵の場合、転職できるとも限らない程度のスキル感で卒業することになる
オンラインコーディングシステムの類
Progate
こちらもWebエンジニアの基礎学習に特化したオンラインコーディングサービスです。
動画を見ながら実際にブラウザ上でコードを試すことができます。自分の環境を構築する必要もないので、手軽です。
運営企業によるクオリティコントロールがあるため、安心です。
Paiza
こちらもWebエンジニアの基礎学習に特化した動画解説・オンラインコーディングサービスです。物を作る場合もあれば、操作説明や純粋なコンセプト説明の動画も含まれています。
動画を見ながら実際にブラウザ上でコードを試すことができます。自分の環境を構築する必要もないので、手軽です。
運営企業によるクオリティコントロールがあるため、それなりに安心です。
動画教材
Udemy
総合的な動画講座サービスですが、Web関連の教材も多く掲載されています。特に英語ができる場合、かなり高品質な動画で学ぶことができるのでオススメです。とはいえ、日本語教材も十分な品質のものが多く存在します。
現役エンジニアが副業で作成している教材もあります。
ドットインストール
Webエンジニアの基礎学習に特化した動画解説サービスです。物を作る場合もあれば、操作説明や純粋なコンセプト説明の動画も含まれています。筆者は未経験の頃、結構お世話になりました。
運営企業によるクオリティコントロールがあるため、それなりに安心です。
Webページ
Techpit
ハンズオン形式で実際に物を作る方向の教材が掲載されているサービスです。
Udemy同様、現役エンジニアが（軽い）副業として取り組んでいたりします。
転職活動にあたっての責務分割、CAと求職者との役割分担
CA業務未経験の自分が書くのも烏滸がましいのですが、ITエンジニアとしての視点から、どういう風に切り分けられるかを考えてみたいと思います。
本人がやらなければいけないことは何か
学習
ポートフォリオの作成
なお、インフラエンジニアの場合、ここは難しくなってくるので、学習に寄せた方がいいかもしれません
あるいは、候補求人の直近の業務では扱わなくとも、AWSでネットワークを組んでみて、実際に動くサーバーを作ってみるのもいいかもしれません
これは、クラウドで構築する際に使用する知識の一部は、オンプレミスでハードウェアを自分で触る場合にも活きるからです
CAに与えられた課題・宿題へのアプローチ
ITエンジニア一本で行くと決めている場合は、特に上記に割く時間を最大化する動きが必要になるかと思います。採用確度を少しでも高めるためには、やはり本人の技術的なキャッチアップが要素としては大きいです。
その上で、CAは何をするか
通常のCA的支援
面談、およびそのなかでのアドバイス
書類作成
面接対策・企業情報を考慮した戦略の提供
一般論レベルの大枠の知識提供を行うこと
自力で調べて、業界や業務を理解するという行動を喚起するための、前段として
全くのゼロから個人で業界感を掴みに行くのは流石に難しいので
ここはCAから高解像度で話せると良い気がしています
グリップを作る上でも効果的なのではないかと
成果物説明の壁打ち役になること
それが書類選考者・面接官に響くかどうかを吟味して、改善点を伝えるのは、「就職活動の協力者」でないとできないです
学習・作業で手一杯になる可能性が高いので、認知的な部分は他者がサポートしたほうがいいと思っています
本人のメタ認知が難しい部分なので、一人の受け手として、気づきを与えるのが重要だと思います
上記は、知識提供・行動喚起・モチベーション管理に集約できると思います。PDCAを回すための助力を行うという点では他業界への支援と同様だと見れますね。
本人が「時間的には逼迫していながらも、楽しんでいる」という状況が作れているかという観点を以って対話してみると、テコ入れポイント・支援内容スイッチの方針が見つかるかもしれません。
思うように進まない場合
適正欠如の場合もあれば、単にプロセスの問題である場合もあることでしょう。そのいずれなのかを見極めつつ、「他業界・他職種の推薦も考えてみる」「本人との目線合わせを再度行い、これからのロードマップを引き直す」などの打ち手が考えられます。
たとえばITやるぞと言った面談のその次の面談までに何も行動・成果物がなかった場合、時間捻出ができていないのか、本人に実はモチベーションがあまりないのか、ほかに想定外の要因が存在するのか……等々の分岐が出てくるはずです。そこを引き出す問いがあれば良さそうな気がします。
勝ち筋を作る
ここもCA業務未経験の自分が書くのも烏滸がましいのですが、書いてみますね。
未経験エンジニア転職をしたことがあり、現役であるという視点を組み込めるとは思います。
短期で決めたい場合
現状も多くの決定がここだと思いますが、SES企業への応募意思決定を取るのが良いかなと思っています。
研修の存在を強くアピールする
「未経験状態で入社後急に実務をするとなったらどう？」という問いについて、求職者が意外と考えていない可能性があります。これは他業界についてもありがちな点ですね。SES企業の場合、研修をしつつ営業先を探していくというプロセスになるのが大半なので、そのあたりの心配がない状態になります。
入社タイミングで実務レベルまで手元技術を向上させられる求職者は稀なはずです。大抵の人は、研修に魅力を感じてくれるのではないでしょうか。
そのうえで、個々の会社の研修内容実態の差異を説明できたりすると、信頼度の上昇が期待できると思います。
ただし、「入社時の不安」が二度訪れることにはなるかもしれません。つまりSES企業への入社と現場への配属というタイミングで不安ポイントが二回あるのです。ここも予めケアできるようにしておくと更に説得力が増すかもしれません。
3年-5年後に向けた投資として、SESキャリアを説明する
3年から5年程度のレンジで成長を考えると、年収500-700万円くらいの人材になれる可能性が出てきます。
また、給与以外の待遇面もかなり本人の当初期待に近いところを狙えることでしょう。
わたし（執筆時現在20代後半）の周囲のエンジニア（前職・前前職の同期たち）も、それかそれ以上に貰っています。
以上を踏まえると、初手SESで数年下積みという思考にシフトしてキャリアを考え、当座の転職活動を速やかに進めるという路線にも、本人に十分なインセンティヴが生じると思います。
SES前提の面接対策をする
SESはポテンシャル採用の面が強い（会社が多い）です。
技術的な質問についても「質問集」（本稿終盤に掲載しているコンテンツです）に掲載されている程度の内容がほとんどだと思います。
そうした面を考慮すると、どちらかというとヒューマンスキルに寄せて、「現場で上長から継続をもらえそうなパーソナリティ」をアピールしつつ、技術質問対策も軽くやっていくという発想で、決定がある程度期待できるのです（自分の最初の会社がSESで、まさにそうした形での決定でした）。
特にインフラエンジニアは成果物提出よりも学習状況の方が重視されるのではないかと思います（そもそも、成果物提出自体が難しいため）。
あとは通常の面接対策同様に進めれば結構行けるんじゃないかなと個人的には思っています。
ただ、わたしの就職当時よりは若干難化しているはずなので、Webエンジニア（サーバー・フロント）を志望する場合、成果物を引っ提げて行くことが望ましくはあります。
長期支援を見込む場合
単月での数字にコミットしにくくなるのがデメリットですが、ITエンジニアに対しての強いwillが形成できている求職者には長期想定で支援継続を考えたほうが決定確度は上がると思います。下記のような打ち手が追加できるからです。
資格取得等、一定のLTがどうしても生じてしまう活動も行える
入社容易なSES企業だけではなく、より幅広い選択肢を視野に入れられる
デメリット
ただ、上記の路線だと「一定自力で勝負できる市場価値を得るところまで到達する」こともあるので、CA経由決定で送れるか、という点には問題が出てくる可能性もあります。グリップにかけるコストも大きいはずです。
メイン技術をどこに置くか
フロントエンド（クライアントサイド）
主にWebブラウザに表示される部分を実装するエンジニアです。
iOSアプリ・Androidアプリ・PCアプリ等々もクライアントとなり得ます。それらと明確に区別したい文脈ではWebフロントエンドなどと呼称する場合が多いかもしれません。
どういう人に向いているか
動くものを作ることが楽しい人は、特にフロントエンドに向いているかと思います。実際に表示されて触れる部分を担当するので、そうした歓びを感じやすいポジションとなります。
また、デザイン・デザイナー的な思考が身についている人も向いていますね。実際にデザイナーと協業する場面も多く、その意図をよりスムーズに把握できる方が、効率的に画面を作っていくことができるからです。
要素技術
HTML
ブラウザに配信される文書ファイル、またはその仕様・構造を指してHTMLと言います。みなさんがいまこうしてご覧になっている画面の表示文言や画像などのソース（元素材、くらいに捉えて良いです）となるのがこのHTMLです。見てもらえれば分かりやすいと思いますので、ごく簡単なものを持ってきました。
<!DOCTYPE html>
<html lang="en-US">
<head>
<meta charset="utf-8">
<title>My test page</title>
</head>
<body>
<p>This is my page</p>
</body>
</html>（上記はMDNが提供している初等的な解説から引用しました）
CSS
HTMLに装飾効果を付与するための記述言語（マークアップランゲージ）です。HTMLはあくまでただの文書構造を示すファイルなので、そのままブラウザに表示させるだけでは、見た目が端的に言って「しょぼい」感じになります。
HTMLに対してCSSを適用すると、色や効果を付与することができます。
だいたいこんな感じのファイルです。「これをHTMLと繋げて、それら全体をブラウザが解釈することで、いまみなさんがご覧のようなWebページが表示される」みたいにイメージしてもらえればだいたい合ってます。
h1 {
color: red;
font-size: 5em;
}
p {
color: black;
}（上記はMDNが提供している初等的な解説から引用しました）
JavaScript
実はユーザーに配信されるファイルはHTML, CSSだけではありません。そのほかに配信されるものとしては画像コンテンツ等々も含まれますが、エンジニアが扱うものの中で重要度が高いのはJavaScriptです。
JavaScriptはブラウザに読まれることを前提として開発・発展してきたスクリプト言語であり、プログラミング言語に必要な要件（は流石にこの記事の範疇を超えるので省略します。そういうのがあるとだけ思って頂ければ幸いです）を満たすため、（HTML, CSSなどとは異なり）プログラミング言語と言えます。
JavaScriptはざっくり言って
CSSだけでは実現しにくいUIを作る
そのWebアプリケーションに特有の通信を行う
そのWebアプリケーションに必要な計算を行う
といったような使途を有しており、Webページを単なるページではなく「アプリケーション」足らしめるためには、このJavaScriptの働きが大きく寄与しています。
TypeScript
JavaScriptを楽に安全に扱うために開発されたプログラミング言語として認識すればだいたい合ってます。
「楽に安全に」とはいっても、ある程度の知識・技術を持っている人にとっての「楽さ・安全さ」の実現を志向した技術です。
初心者がいきなり勉強しようとするとわけがわからなくなる可能性があります。適正が高い人は「ほぉん」くらいで済む可能性もあります。
TypeScript / JavaScriptがユーザーに届くまでのストーリー
どういうストーリーがあるかというと、ざっくりこんな感じです
①サーバー側でTypeScriptで書かれたコードをJavaScriptに変換しておく
②変換されたコードをHTMLと紐つける
③ユーザーが引き起こす様々なイベント（ページが開かれる・ボタンが押される・フォームに入力が行われる等々）に応じて、JavaScriptが適宜実行され、インタラクティブな動作が生じる
React / Vue.js
流行っているのもありもしかしたら耳にするかもなと思ったので載せましたが、これについては「そういうもんがある」くらいの理解でも問題ないと思います。
JavaScriptの世界観のなかで「現代の複雑なWebアプリケーションを開発しやすくする」ためのツールだと認識しておけば大丈夫です。
サーバーサイド（バックエンド）
サーバーサイドエンジニアはその名の通り、ブラウザの通信相手となるサーバーのプログラムを書いたりするエンジニアです。
ユーザーからみたときは「通信相手」ですが、提供側からみたときは「自分たちのサーバー」です。ちなみに「インフラ」の項目を読むときにこの認識があると少し分かりやすいかもしれません。
また、サーバーも実のところ、コンピューターとその内部で動いているプログラムのことなんですよね。みなさんがお使いのMacは人間がグラフィックの豊富な画面やキーボードを用いて操作するものですが、そういうサーバーとしては特に要らない機能は省いているコンピューター（例外もあるんですが、例外なのでここでは無視します）だと思えば、なんとなくイメージつくかもしれません。
サーバーサイドの場合、（フロントエンド開発は最終的にHTML, CSS, JavaScriptを形成するのに対して）プログラミング言語はわりかしなんでもいいという特徴があります（それでも頻用される言語は幾らか挙げられますので、後ほど記します）。
さて、サーバーサイドのアプリケーションは例えば以下のような機能を発揮することが出来ます。
データベースにユーザー情報や取引情報を登録する
ユーザーにメールを（自動）送信する
関連するサービスと連携する
ただし、原理上コンピュータで出来ることなら何でもサーバーサイドで開発し得るため、もっと多くの機能・複雑な機能を想定することもできます。
が、典型的には上記の延長線上に収まる開発内容になるということですね。
どういう人に向いているか
ロジシャンの方が向いていると思います。かなり技術技術したタイプのエンジニアが多いです。
ただし、ドメイン知識（事業領域の知識、弊社の場合、就職・転職・人材紹介のスキームの知識）はサーバーの方が要求されます。
「どういう規範のもとにデータ操作の制御を行うか」は事業領域を含めたソフトウェア仕様の理解がないと、誤った実装をしてしまうかもしれません。そうした部分を担当する以上、プロダクト・事業に要求される規範を認識していないといけないでしょう。
そのため、世の中の仕事に対する知識欲を有している人は、より向いていると言えます。
要素技術
インフラと重なる部分もあるんですよね。たとえばOS関連の技術はインフラエンジニアになる場合も当然レベルで必要になります。
プログラミング言語
JavaとかPHPとかRubyとか色々聞きますよね。「なにがちゃうねんこいつら」となることかと思います。
これなんですが、実は「できることにあまり差異はなく、得意／苦手なことに差異がある」と見たほうが良いのです。
我々はそれぞれの細かい特徴を見つつ言語の採用判断を行うわけですが、未経験を支援するCAの場合、世の中でどれだけ使われているかにフォーカスして見ていくのが良いかと思います。
その点で行くと、PHP / LaravelやRuby on Railsなどの「スタートアップの初期から開発速度を高めることを重視した」技術や、大規模システム構築で頻用されるJavaなどの大枠での特徴（ただし、ここで書かれている認識は割と大雑把なものです）を把握しておけば良いかと思います。これらはいずれも現役のサービス・システムが多いので、まず直近で仕事がなくなることはありません。
それぞれの言語の特徴については需要があったら追記します。
DB / SQL
SQLはデータベースからデータを抽出したり加工したりする際に使う言語です。
ちなみに、SQLは実のところエンジニア以外も身につけると得するかもな技術だと思います。
データ分析に役立ちます。ある程度知っていると、すぐに自分がほしいデータを取り出せるのが利点かと思います。
コンテナ型仮想化技術（docker等）
現代的なサーバーサイドコーディング環境を作るには、dockerを主としたコンテナ型仮想化技術が事実上必須となっています。
どういう技術かを簡単に説明します。手元のPCとサーバーとでは、環境が異なるために動作の違いが生じてしまうことがあります。そういった環境間の差異を吸収し、自分の手元と本番サーバーとの差分を最小化するというのが、仮想化技術の大きな利点です。
ほかにもサーバーを動かす上で色々利点があるのですが、高度に技術的な話題になるので省略します。
Operating System（Linuxの各種ディストリビューション等）
いわゆるOSですね。サーバーサイドのアプリケーションもOS上で動きます。そのOSについての知識も、サーバーサイドエンジニアにはある程度求められます。
インフラ
おそらく未経験エンジニアでの支援において、最近の応募先としては一番多い気もしますが、上記を踏まえてからの方が話しやすいので後に回しました。
どういう人に向いているか
物事の原理を追求する志向性がある人がまず一番向いています。システムの比較的深いレイヤーや標準的なプロトコルを正確に把握することが必要だからです。
システムの安定に強くコミットメントするポジションでありかつセキュリティにも強く関わる部分であるため、慎重さ・冷静さが強く求められます。
高度なインフラエンジニアはシステムの全体構成を理解している必要があります。その点で、理解のための粘り強い整理ができるかどうかや、強力な知識欲がコンピテンシーに挙げられるはずです。
インフラエンジニアの業務範囲
CAの皆様が一番関心のある分野がインフラかと思います。未経験領域での採用・求人数が多いためです。
本項ではまず、一般的なインフラエンジニア観から確認し、未経験求人の業務内容にフォーカスしたまとめを述べます。
オンプレミスのサーバー構築や社内のローカルネットワーク構築
「自分の会社の一室をサーバールームとして、そこにサーバー（としての用途の性格が強いコンピューター）を並べ、それらの間でネットワークを形成したり、インターネットに接続するために配線を行う」のようなイメージをもってもらえれば、仕事の内容が分かるのではないかと思います。
会社によってはこの領域を情報システム部門が行っていたりします（情シスはインフラエンジニアとしての側面を有することもある、とも言えます）。
AWSの提供側、つまりAmazonは（一般的なオンプレミスのサーバー構築よりは高度に自動化された形ですが）自前のデータセンターにAWS用の膨大なサーバー群を構築していることになります。クラウドインフラの実体は、高度なオンプレミス環境であり、要は「代わりにやってくれている」ということなんですね。
クラウドインフラの構築
AWS、GCP、Azureなどは聞いたことがあるでしょうか。
これらはいずれもクラウドインフラをユーザーに提供するサービスです。IaaS(Infrastructure as a Service)という言葉でも指示されます。
自社でWebサービスを展開していてクラウドインフラとしてAWSを選んでいる企業は、「AWSのユーザー企業」と認識できます。
さて、最近では、多くのサービスがこのクラウドインフラによって構築された環境で動作しています。
インフラエンジニアは必ずしもこのクラウドインフラを触るとは限りませんが、「クラウドインフラの構成を管理し、よりセキュアにより安定してよりスケール容易にする仕事」は比率としてどんどん高くなってきています。
「オンプレミスよりも容易に行うことができ、費用的にも優位性がある場合が多く、また増台するなどの拡張も遥かに簡便であるため、採用する企業が爆増した」というのがこうした採用状況の背景ですね。スタートアップのインフラとかもうだいたいクラウドインフラです。
オンプレミスと比較した際のデメリットも存在しないわけではないのですが、大抵の場合はメリットのほうが大きいため、本稿ではそのあたりの記述は省略しておきます。
さて、簡単とは言っても、それはオンプレミスに比べての話です。OS・ネットワーク・ミドルウェア等々の知識は依然として必要ですし、またそれに加えてクラウドインフラ各種サービス固有の知識も要求されます。そのあたりへの習熟が、エンジニアとしての力量に直結することでしょう。
スキルアップ路線について
クラウドインフラを主軸としたインフラエンジニアを目指す場合、基本的には「最初はAWSにフォーカスする」のが良いと思います。理由はシンプルで、「現状、採用案件数が最も多く、ノウハウも業界にある程度浸透している」からです。
インフラの運用・保守
管理しているサーバーとそのネットワークに異常が起きていないかを確認し、異常が見つかればその解決を行う業務があります。これを、監視業務と呼びます。運用・保守段階で生じる業務の多くがこの監視業務に属します。
さて、異常とはこの場合、
監視対象のサーバーがダウンしている
ダウンまではいかずとも、著しくパフォーマンスが低下している
監視対象のタスク（通常、ソフトウェアが自動的に実行するもの）が実行されていない
監視対象のネットワークにおいて、特定のノード間の通信がうまく行われていない
などの事象です。
こうした異常を検知した場合、インフラエンジニアは原因調査を行い、必要に応じてハードウェアの再セットアップやOS・ソフトウェアの再起動などの修復オペレーションを行います。
監視業務において頻出する事象への対処はある程度マニュアル化されており、その指示通りに修正するといった仕事が大半を占めます。ただ、その域を漏れる事象を確認した場合、より高位のエンジニアにリポート、協力して解決にあたります。
キッティング
PCやスマートフォンなどのデバイスに各種設定やソフトウェアのインストールなどを行う業務です。
内容からお分かりの通り、ほとんどの業務がマニュアル化されており、もっとも簡単な部類です。
運び込みを伴う場合もあるので、腰痛に注意が必要です。
未経験のインフラエンジニア求人が想定している業務内容について
未経験のエンジニアが最初に携わることになる仕事は、上記の中でも「運用・保守」「キッティング」などとなるはずです。時にはサーバー・ネットワーク構築にアサインされる場合もありますが、任されるのはある程度定型化されていてマニュアルも存在する業務が大半でしょう。
よって、実のところ未経験でも「基本的な用語理解はある」「落ち着いて対処することができる」といった資質さえあれば、十分に就業・継続可能な領域となります。
どんな資格があるか
長期支援になる場合には選択肢に入る資格取得。短期でも簡単に取得できるものを試しに受験するなどの方向性はあり得ます。そのため、主要な資格について、その概要と現場からの所感をお伝えしようかなと思います。難度表記は独断と偏見に塗れています。鵜呑み注意。
※未経験領域でチャレンジするには厳しいものは、除外してあります。
※筆者はいずれも持っていません（が、取ろうと思えば取れる気はしています）。
ITパスポート
対象：誰でも
難度：たぶん未経験でも勘が良ければ1,2週間で取れる気がしている
温度感：学習意欲をみる程度にはなるが、ないよりはもちろんいい
基本情報技術者
対象：エンジニアを目指すならどの領域でも
難度：3ヶ月から半年程度の学習期間は見込みたい
温度感：SESや未経験採用する受託なら、よほどBADがない限り採用ラインに乗せたい
備考：上位資格（応用情報技術者）があるので、それに繋げられるとよい
Oracle認定Java Bronze
対象：サーバーサイドエンジニアを目指す人
難度：未経験でも勘が良ければ1,2週間で取れる気がしている
温度感：学習意欲をみる程度にはなるが、ないよりはもちろんいい
備考：上位資格があるので、それに繋げられるとよい
AWS認定クラウドプラクティショナー
対象：クラウドでのインフラ構築・運用に携わろうと考えている求職者
難度：上手く行けば一ヶ月程度の学習でも受かる
温度感：SESや未経験採用する受託なら、よほどBADがない限り採用ラインに乗せたい
備考：上位資格があるので、それに繋げられるとよい
CCNA
ネットワーク機器最大手Ciscoが認定している、ネットワーク技術者系の資格です。
対象：物理的なインフラ（特にネットワーク）の構築・運用に携わろうと考えている求職者
難度：上手く行けば短期間の学習でも受かる
温度感：SESや未経験採用する受託なら、よほどBADがない限り採用ラインに乗せたい
備考：上位資格があるので、それに繋げられるとよい
LPIC
Linuxの理解を問う資格です。
対象：エンジニア（特にインフラ、サーバーサイド）を目指している求職者
難度：上手く行けば短期間の学習でも受かる
温度感：SESや未経験採用する受託なら、よほどBADがない限り採用ラインに乗せたい
備考：上位資格があるので、それに繋げられるとよい
その後のキャリア展開
エンジニアのキャリアアップを考えたときに主に想定される路線についても簡単に説明していきます。
技術特化プレイヤー
圧倒的な技術力を背景に、長期的に開発レイヤーでの業務を主軸として働くエンジニアとなります。
未経験からここに到達するのは至難だと思いますが、生涯の半分を技術に捧げるくらいの気持ちなら十分に可能な路線だと思います。
エンジニアリングマネージャー
EMと略記することが多いです。
エンジニアのヒューマンマネジメント
評価
マネジメント範囲における技術的判断・助言
後進育成
技術組織全体の底上げ
などに働きかけるマネージャーだと理解すると良いかもしれません。
単に技術ができるだけでなく、事業のプロセスやエンジニアキャリア、対話やコーチングなどの技能も含めた幅広い知識を活用していくことになります。
エンジニアリングマネージャーのしごとは同名書籍の翻訳者による概説といった趣のスライド資料です。EMについて、現状もっとも早く楽に理解できる資料かなという気がしています。
プロジェクトマネージャー・開発ディレクター
主に受託開発などの業態で、プロジェクト型業務の進行管理を行う職種です。エンジニアからのキャリアアップ以外でもなることはできますが、ソフトウェア開発の場合、技術理解のある方が明らかにスムーズに事を運べるので有利です。
基本的に、プログラミングを行うことはありません。
V字モデルで言うと、「要件定義」等の上流工程において主体となる役割を果たします。また、以後の各工程の進行の健全化に責任を負い、プロジェクト進行の妨げとなっている問題を解決し、ステークホルダーの利害調整も担います。
工期見積もりと実態とのギャップが生じやすいソフトウェア開発プロジェクトを成功させるためにもっとも重要なポジションとして認識できるはずです。
プロダクトマネージャー
PM, PdMなどと略記されることが多いです。
製品開発の路線を、事業・技術の両面から作り出していくマネージャーです。
市場へのリサーチ、顧客課題の発見、発見した課題に対する解決方法を構想、プロダクトの成長管理、Biz - Devの橋渡し……等々多岐にわたる仕事を行います。
上記から分かる通り、単に技術的な知見を有するだけではなく、市場全体やサービス価値に対する明晰な理解が求められるポジションです。
ビジネス知識も持ちつつ、（自分で実装するわけではないものの）技術的解決の手札を多く持っている必要がある点で、知識水準的にもかなり難しい役割と言えるでしょう。
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法は、プロダクトマネージャーとエンジニアとの関係について、今日的な課題感を説明する良い資料です。このスライドを通じてPMの仕事を理解することもできそうな気がしているので、貼っておきます。
スクラムマスター
スクラムという開発手法に卓越した見識を持つ人がなります。
開発サイクルの改善を積み重ねるため、非定型的な様々な業務を行うポジションです。サーバントリーダーとしての資質が求められるほか、ファシリテーターやコーチとしての振る舞いも時に求められます。
状況によっては技術者としての動きも求められますが、開発チームの健全化に対しての寄与が最重要ミッションです。
結論
生涯プログラミングだけをやる人は、どちらかというと少数なんじゃないかということが把握されたかと思います。
かつて存在したエンジニア35歳定年説こそは破れていますが、とはいえ、純粋な技術者としてのキャリア以外にも路線は幅広く存在しているということです。
上記の職種に限らず、たとえば（エンジニアとしての知識を活かして）営業・マネージャー・人事などに転向する人も散見されます。
これらの職種の給与感も確認しつつ、「十年先、どのようなレイヤーで、何をしたいか」を求職者と対話できると、より良いエンジニア転職支援が行えると思います。これは、未経験層に限らず。
読んでおくと良さそうな資料
CAサイド
業界理解
ITの仕事に就いたら「最低限」知っておきたい最新の常識
※この本だけ自分で中身を確認していません
業界理解を別口でやっていたので本を読むということがなかったんですよね。
この本は、目次を見て網羅的だったので載せました。類書の中では良さそうです。
キャリア理解
エンジニアから管理職になるにあたっての躓きポイントや、開発者組織にありがちな課題とその対処について書かれた書籍です。マネジメントキャリアパスを考えているエンジニアが読む本ですが、当該キャリアに対する解像度を上げるために役立つことには違いないので、人材紹介の文脈でも役立ち得ると考えています。
エンジニアリングマネージャーの業務範囲や、それをどのように上手く実行するかについてのmind setやhowが書かれた本です。非エンジニアリングマネージャーでも、ヒューマンマネジメントに関心のある方でしたら一読の価値はあるかと思います。
人材紹介の文脈では、エンジニア領域でのハイキャリア支援のため・若手エンジニアに対するキャリアアドバイジングを行うための知識を獲得するために読むというのも活用方法として考えられます。
技術概要理解
図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書
AWS概説本です。が、「オンプレって何？」というところも書かれています。
エンジニア以外でも理解可能な範疇かなと思うので記載しました。
図解即戦力 サーバーのしくみと技術がこれ1 冊でしっかりわかる本
少々難しい部分も含むかもしれませんが、サーバー技術の大枠がつかめる本です。
求職者サイド
Web
MDN Web Docs
Web（特にフロントエンド）の実装に用いられる諸技術の信頼できるドキュメントです。
実務でもよく参照するので、サイト自体に慣れておくと良いでしょう。
IPA - 安全なウェブサイトの作り方
Webサイト実装に現れる典型的な脆弱性を防ぐ方法が簡潔に書かれている資料です。
このくらいは防げていて当然ラインになってきますので、初心者でも理解している必要があります。
XSSやSQLインジェクションなどの有名脆弱性は面接でも問われる場合があるので、対策となります。
SQL 第2版 ゼロからはじめるデータベース操作
DB, SQLはミック本読んどけみたいなところがあります。
図解即戦力 サーバーのしくみと技術がこれ1 冊でしっかりわかる本
CAの方にも記載しましたが、求職者にも役立つと思います。特にサーバーサイドエンジニアが、その周辺領域としてのインフラを理解する上で、入門的に使える本です。
インフラ
サーバ／インフラエンジニアの基本がこれ1冊でしっかり身につく本
インフラエンジニア向けの初学者本としてはかなり良い内容かと思います。
イラスト図解でよくわかる ITインフラの基礎知識
こちらも同様。
マスタリングTCP/IP
TCP/IPプロトコルスタックの理解を行う上でよく推薦される図書です。
とはいえ、通しで読むのはおすすめしません。分厚いので。
辞書的に使ったり、興味のある部分だけ読むようにするといい書籍です。
求職者向けの初歩的な質問集
さて、いざITエンジニアを前提として支援をするなかで、スキル感・学習感を判断したい場面があるかと思います。そうしたときに使える質問を用意してみました。解答・解説も用意しますので、本人がわからなかった場合に、解答を示してみると支援の説得力も出るかもしれません。が、実際に触ったことがないと難しいかもしれません。エンジニアが「基礎理解を把握するための問題集」として作問したものである、というネタバラシをしてしまう方向もアリだと思います。
また、これに回答できるようになること自体、自然と面接対策にもなるかと思います。未経験であっても技術的な質問も想定され得ますし、そもそも対策しないと喋れない、という自覚を促すのにも効果的だと個人的には思っています。
ちなみにSESとして就職したとき、自分は全部「わかりません！」だった気がします（これは冗談でもなんでもなく、すべて研修期間中に覚えました）
ちなみに、「知らない」という回答も許容する形で訊くといいです。「知らないことを認めること」もエンジニアとして重要な資質となります。そのうえで、「このあとすぐに調べる」「次は回答できるようにする」といった前向きな動きができると良いのです。
Q. HTTPメソッドのGETとPOSTの違いを説明してください
回答例
GETは主に「データを取得する」などの場面で使われるメソッドです。例えば「タイムラインを取得する」といったような操作はGETで行われます。リクエストに際しての付加的なパラメーターはbodyではなく、クエリパラメーターとしてURLに含めて渡すことが推奨されます。「取得」などで使われることから分かる通り、同一のリクエストを何度実行しても（別の処理によってデータが改変されなければ）結果が変わらないメソッドと言えます。この性質を「冪等性」と呼び、GETは冪等性のあるメソッドです。
対して、POSTは主に「データを作成する」ための通信で用いられるメソッドです。例えば「ツイートを書き込む」といったような操作はPOSTで行われます。パラメーターは、GETとは違ってURL部分でなくHTTPのbodyに含めて送信することになります。「作成」が行われることを期待するメソッドである以上、何度も実行すると、（サーバーがそれを防ぐ制御をあえてしていないと想定した場合）実行した回数分だけ新しいデータができてしまいます。そのため、冪等性のないメソッドと言えます。
解説
正確性を多少犠牲にした文章でこそありますが、この回答全文を答えられる人はおそらくいますぐエンジニアとして就職できます。
理解・説明の段階として、以下のようなレイヤーに分けられます。
そもそも何であるかが分かっている：言葉としてHTTP, GET, POSTを知っている
HTTPメソッドの用途の区別が説明できている：取得・作成などの文脈が盛り込まれている
. パラメーターをどこに含めてリクエストすることが推奨されるかについての認識がある：URLのクエリパラメータか、HTTP bodyか
冪等性の概念とそのHTTPにおける文脈を認識している：GETは冪等とされ、POSTは非冪等とされる
3までを説明できると強いですね。サーバーサイド・フロントエンドのいずれも3くらいまでは基礎知識となります。4の部分も基礎的な認識とはなりますが、言葉でちゃんと説明できる必要はそこまでありません。
HTTPとは、ブラウザとサーバーとで行われる通信の、アプリケーションレベルのプロトコルです。通信のリクエスト・レスポンスの標準化された形式です。リクエスト時にはこのHTTPの形式で「サービスに対して何をしてほしいかを表現する」こととなります。HTTPメソッドは、「何をしてほしいか」の大まかな種別を表示するためのパーツだと思ってください。
Q. Webにおけるバックエンドとフロントエンドの違いを説明してみてください
回答例
エンジニアの実装範囲をベースに説明します。
フロントエンドエンジニアはざっくり言って画面側を実装する人です。HTML, CSSでコンテンツとUIデザインを表現し、ブラウザ上で動作するアプリケーションをJavaScriptで書きます。
バックエンドエンジニアは、ざっくり言ってサーバーの内部で動作するアプリケーションを実装する人です。PHP / LaravelやRuby on Rails、Javaなどのプログラミング言語・フレームワークを使って開発することが多いです。また、データベースも触るので、SQLも扱える必要があります。
解説
このくらいで全然いいです。もちろん、これ以上詳細化してもいいのですが、そこまでやった場合は未経験転職なら加点要素かなと思います。
逆にこの質問に答えられない場合、自分で調べてすらいない可能性があるので、結構ダメダメです。むしろそうした調査意欲を確認するときくらいにしか訊かないかもしれません。
内容面は、エンジニア以外でもざっくり把握できていると思うので、解説を省略します。
Q. SQLってなんですか？
回答例
SQLはデータベースにデータの取得・作成・更新・削除を依頼するための言語です。SELECT, CREATE, UPDATE, DELETEは先程の操作（取得・作成・更新・削除）と対応する構文で、まとめて四大構文などとも呼ばれます。SQLの主機能と言えるでしょう。
データの分析を行う場面や直截的にデータの変更を行いたい場面ではSQLをそのまま人間が書きます。これを俗に生SQLなどと呼びます。また、アプリケーションからSQLを用いる場合、実装者はORマッパーやクエリビルダーなどのライブラリを用いてプログラムを記述し、そのプログラムがSQLを生成すると言った手順を踏むことが多いです。
SQLは「データをどうやって操作するか」ではなく「どのようなデータに対して、何をしたいか」という宣言を行う形で記述する言語です。よって宣言的なパラダイムに属する言語としても認識できます。
SQLのシンタックスは、集合論や述語論理を背景として設計されています。
解説
サーバーサイドを目指すなら、SQLについても分かっているか確認して良さそうなので質問集に加えました。
未経験なら四大構文まで触れられていたらOKだと思います。アプリケーションからSQLを扱う際の方法まで言及できたらベスト。
後半は豆知識に近く、実務上はさほど意識しなくても問題ありません。
Q. gitとGitHubについて教えてください
回答例
gitはソフトウェアのソースコードなど、テキスト形式で扱われるファイルを便利にバージョン管理するためのツールです。こうしたバージョン管理用のソフトウェアをVCS（Version Controll System）と総称します。gitはVCSに属するソフトウェアである、ということになります。
GitHubはそのgitを用いて管理しているソースコードの類をオンライン上で共有するためのサービスです。現在はMicrosoft傘下で開発・運用されています。
GitHubを始めとするremote repositoryを用いると、ソースコードが自分の手元のPCだけではなく、GitHubにも保存されることとなります。したがって、GitHubはバックアップとしての機能も有するわけです。
複数人で開発する場合の共有も容易となり、開発中のコミュニケーションもGitHub上で行われます。
自分のソフトウェアをGitHubにpublic repositoryとして公開していれば、理論上、世界中の人が開発に参加することができるようになります。公開方法はGitHubに限られませんが、このような開発形態を採るソフトウェアをOSSと呼びます。逆に、GitHubを使っていてもソースコードを公開しない方法も採用できます。そのような開発形態を採るソフトウェアはプロプライエタリ・ソフトウェアと呼ばれます。
解説
完備な説明をするともっと長くなるのですが、概ね以上のようなことが言えたらgitやGitHubへの理解は問題ないかと思います（実際の操作が巧みにできるかは別ですが）。
エンジニアリング領域的な面からみると、サーバー・フロントは頻用するツールです。インフラの場合はまちまちですが、今日日、少なくとも無関係ということはないはずです。
Q. OSI参照モデルについて説明してください
回答例
OSI参照モデルは、コンピューターネットワークで利用されている多数のプロトコルについてのモデルです。多くのプロトコルを7つのレイヤーに分類、そして全体的に統合しつつ、各々の役割を説明する抽象的なモデルであると言えます。
L7： アプリケーション層がよりソフトウェアに近く、L1：物理層がよりハードウェアに近いレイヤと見ることができます。
解説
主にインフラ向けの質問となります。サーバーサイドエンジニアの場合も分かっていると良いです。
各レイヤ全てを完璧に説明できる必要まではないです。大枠でどういうことのために作られたモデルがあるかが分かっていて、層の方向が理解できていれば大丈夫だと思います。
Q. IPアドレスとは何かを簡単に説明してください
回答例
インターネット・プロトコル（L3）において、通信の相手を識別するための番号です。
人間が読み書きするコンテキストでは10進数をドットで繋げる表記法などを主に用いますが、コンピューターが利用するデータとしての実体はビット列となります。
インターネットに接続する際に用いるアドレスは、public IPアドレスと呼ばれ、全世界で一意に特定可能なものとする必要があります。そうした都合上、public IPアドレスはICANNやその下部組織といったオーソリティによって割り当てが管理されています。
それとは別に、ローカルなネットワークで用いられるprivate IPアドレスというものがあります。こちらについては、全世界でなく、ネットワーク内で一意であれば問題ありません。アドレスの割り当ては当該ネットワークの管理者がある程度自由に行うことが出来ます。
また、IPv4のアドレスが枯渇してきた現在、より大量のノードを扱えるようにするために、IPv6という仕組みが整えられてきています。
解説
インフラ基本問題その2です（基本なんですが、そのまま「説明してください」で訊くと派生的に語らなければいけない事柄が沢山出てくるので、結構難しいです）。
とりあえず、「どのプロトコルに属する概念であるか」「何に用いるか」「どういう表記がされるのか」について幾らかの説明があれば問題ないはずです。つまり、回答例の最初の2行分までが言えれば十分ということになります。
謝辞
弊社（株式会社ROXX）のメンバー、特にCAのみなさん
素敵な絵をヘッダ利用可能な状態にしてくださっていたmacurocuoさん
ありがとうございます！
この記事が気に入ったらサポートをしてみませんか？