GraphQLの経験は転職でどう評価されるか｜設計と運用

GraphQLに関わった経験がある転職希望者が職務経歴書を書くと、クエリやミューテーションを実装したという事実をそのまま並べがちです。しかし設計を重視する求人の採用担当者が見ているのは、実装した機能の数ではなく、スキーマをどう設計し、運用で起きた問題にどう向き合ったかという判断の中身です。

中心になるのは、スキーマの設計と、運用で起きる問題にどう向き合ったかという視点です。ライブラリの使い方や年収の相場は、検証済みデータがないため扱いません。

Relasic（株式会社LASSIC運営）｜リモートワーク対応の転職支援

1. GraphQLの経験は、スキーマを決めた過程で評価されます

GraphQLの経験は、実装した機能の数ではなく、スキーマをどう設計したかという判断で評価されます。テレワークを導入している企業は47.3%です＊1。市場の状況を踏まえたうえで、取得範囲や権限をどう区切ったかを、職務経歴書の言葉に置き換えることができます。

GraphQLに関わったことがある転職希望者の職務経歴書は、担当した機能やクエリの実装をそのまま列挙する形になりやすいものです。機能の一覧は、触れた経験があることは伝えますが、何を考えて設計したかは伝えません。設計を重視する求人の採用担当者が知りたいのは後者です。

GraphQLは、クライアント側が必要な項目を指定して取得できる仕組みです。この柔軟さは裏を返せば、スキーマの設計者が、どこまでを公開し、どこで区切るかを決める役割を負うことを意味します。この判断を、担当した機能の説明から切り離して書き出すところから始められます。

この置き換えは、担当してきたプロダクトの規模やチームの体制が何であっても進められます。実装の細かい手順は現場によって変わりますが、何を優先して区切ったかという判断の組み立て方は、現場をまたいでも共通しています。

求人によって、募集要項に書かれているGraphQLの経験の範囲は一様ではありません。実装のみを求める求人もあれば、スキーマ設計から任せる求人もあります。募集要項の記載を読み分けることも、この判断の一部です。

2. 導入の段階によって、任される範囲が違います

GraphQLは導入からの期間によって、任される範囲が変わります。自分が今どの段階にいるかを確認してください。

導入したばかりの時期は、スキーマの土台を一から設計する場面が多く、型の分け方や公開範囲の方針など、後々まで影響する判断を任されます。この時期の経験は、設計の基本方針を決めた実績として書けます。

運用を続けた時期になると、実際の問い合わせの傾向を踏まえて、取得範囲や型の見直しを求められる場面が増えます。想定していなかった使われ方に対応した経験があれば、この時期の実績として書けます。

複数チームで共用する時期には、チームごとに必要な範囲が異なるため、権限の切り分けを設計に組み込む判断が必要になります。この段階の経験は、単独チームの利用を前提とした設計とは異なる判断を含みます。

どの段階の経験も、それぞれ異なる種類の判断を含んでいます。担当してきた時期がどの段階にあたるかを先に確認しておくと、職務経歴書に書く際に、どの判断を中心に据えるかを選びやすくなります。

実際には、これらの段階がきれいに分かれるとは限りません。複数のプロダクトを掛け持ちしている場合、それぞれ異なる段階に同時に関わっていることもあります。

3. 同じGraphQL経験でも、書き方で伝わる範囲に差が出ます

GraphQLに関わった経験を職務経歴書でどう書くかによって、読み手に伝わる情報の範囲は変わります。

書き方による伝わる範囲の違い

職務経歴書の書き方	読み手が受け取る情報	足すと伝わること
「GraphQL APIの設計・実装を担当」とだけ書く	触れた経験があるという事実	スキーマのどの部分を、なぜその形にしたか
「型定義とクエリの実装を行った」と書く	作業を分担して進めた範囲	型をどう分割し、変更の影響をどう抑えたか
「過剰な取得への対応を行った」と書く	問題が起きたことがある事実	どの単位で取得範囲を区切り、誰の判断で決めたか

表の左列は、担当した作業をそのまま書いた例です。右列に足すと、同じ経験が判断として読めるようになります。中央の列は、足す前の書き方で読み手が受け取る範囲です。

3行はいずれも、GraphQLに関わっていれば経験している場面を選んで並べたものです。担当してきた作業のすべてがこの3行に当てはまるとは限りません。自分の経験の中から、判断を伴った場面を思い出しながら、当てはまる行を選ぶ使い方ができます。

職務経歴書に書く際は、右列の言葉をそのまま貼り付けるのではなく、実際に関わったスキーマの規模や制約に合わせて言い換えます。同じ判断でも、利用者の数によって重みが変わるためです。

職務経歴書の分量には限りがあるため、3行すべてを詳しく書く余裕がない場合もあります。その場合は、応募する求人の募集要項で重視されている観点に近い行を優先して書く、という選び方もできます。

あわせて読みたい ｜ システム設計面接とは何を見る面接か｜答え方の順番

4. 運用で起きた問題への対処が、実務の証明になります

GraphQLは、クライアントが必要な項目だけを指定して取得できる仕組みです。この柔軟さは裏を返せば、1件のクエリが想定より多くのデータを引き出してしまう場面を生みます。運用の現場では、この取得範囲をどこで区切るかという判断が、日常的に発生します。

区切り方の正解は一つではありません。取得できる項目の範囲を絞れば、クライアント側の自由度は下がりますが、サーバー側の負荷や意図しない取得は抑えられます。逆に範囲を広く保てば、クライアント側の実装は楽になりますが、想定外の取得を許すことになります。どちらを優先したかという判断が、職務経歴書に書ける実績です。

権限の制御も、同じように判断が伴う領域です。スキーマは複数の画面や複数の利用者から共有して使われることが多く、ある利用者には見せてよい項目が、別の利用者には見せられない場合があります。この線引きを、スキーマの設計段階でどう組み込んだかが問われます。

過剰な取得と権限の制御は、どちらも一度決めて終わりではありません。利用が広がるにつれて、想定していなかった取得のされ方や、新しく生まれた利用者の種類に対応する場面が出てきます。そのたびに判断をやり直した経験があれば、それも実務の証明として書けます。

面談では、なぜその区切り方を選んだかを尋ねられる場面があります。選ばなかった選択肢と、その理由を合わせて説明できると、判断の過程がより具体的に伝わります。

あわせて読みたい ｜ データベースエンジニアの転職｜運用の経験を設計に接ぐ

5. 導入の判断と、実装の担当のあいだ

GraphQLに携わった経験は、「実装が中心」から「導入の判断まで担う」までの間のどこかに位置します。自分の経験がどのあたりにあるかを確かめます。

「実装が中心」側にあるのは、決められたスキーマや設計方針に沿って、型定義やリゾルバを実装する経験です。「導入の判断まで担う」側にあるのは、GraphQLを導入するかどうかの判断や、取得範囲・権限の切り分け方を決める経験です。

多くの担当者は、この2つの間のどこかに位置します。実装だけを担当してきた場合でも、その中で取得範囲の判断を求められた場面があれば、位置は右側に寄ります。

自分の立ち位置を確かめる目安は、スキーマの設計方針そのものに関わったことがあるかどうかです。決められた型定義を実装していたのか、型の分け方や公開範囲を決める側にいたのかで、立ち位置は変わります。

面談では、この立ち位置を自分の言葉で説明できることが役立ちます。「導入の判断まで担っていました」と言い切れなくても、「取得範囲を区切る基準の相談に加わっていました」のように、関わった範囲を具体的に言えれば十分です。

立ち位置は、担当するプロダクトが変わるたびに動くことがあります。新しいプロダクトでは実装から始め、慣れてきた段階で導入の判断に関わる場合もあります。

6. 職務経歴書に足せる3つの要素

GraphQLの経験を職務経歴書に書くとき、足せる要素を3つに整理します。

3つはいずれも、担当した作業を並べるだけでは出てこない要素です。その裏にあった判断を思い出す作業が必要になります。

3つを毎回すべて書く必要はありません。特に大きな判断を伴った場面を選び、そこに絞って書くほうが、読み手には伝わりやすくなります。

書き終えたら、3つがそれぞれ別の場面を指しているかを確認します。同じ画面や同じ機能の話に偏ると、経験の幅が狭く見えることがあります。

3つの要素を書く順番も、応募先に合わせて変えられます。設計の理由を重視する求人であれば最初に置き、権限まわりの経験を重視する求人であれば、その要素を前に出す、という調整ができます。

あわせて読みたい ｜ ハイブリッド勤務の求人｜「リモート可」では分からない出社頻度

7. よくある質問（Q&A）

Q1. GraphQLの実装経験が浅くても、スキーマ設計の話は書けますか。

A. 実装の経験年数と、設計に関わった経験は別に考えられます。型定義の見直しや取得範囲の調整に関わったことがあれば、実装経験が浅くても、その判断を職務経歴書に書くことができます。募集要項に必須の経験年数が明記されている場合は、その基準と照らし合わせて確認してください。面談では、その判断に至った理由まで説明できると、実装経験の浅さを補う材料になります。

Q2. 過剰な取得への対応は、どの程度書けば伝わりますか。

A. 起きた問題の説明よりも、どこで取得範囲を区切ったか、その基準を書くほうが伝わりやすくなります。1つの判断につき、状況・選択肢・結果を短くまとめる書き方が使えます。

Q3. 権限の設計に直接関わっていない場合でも、この経験は書けますか。

A. 権限の設計そのものを担当していなくても、権限の切り分けについて相談を受けた経験や、既存の設計を運用しながら気づいた点があれば、その範囲で書くことができます。関わった範囲を正直に書くことが大切です。面談で聞かれた際に備えて、関わった範囲を具体的に整理しておくと説明がしやすくなります。

Q4. 導入の判断まで担った経験がまだない場合、選考で不利になりますか。

A. 求人によって重視される経験の範囲は異なります。導入の判断を必須としない求人もあれば、必須とする求人もあります。募集要項に書かれた業務内容と、自分が説明できる経験の範囲を照らし合わせてから応募先を選ぶと、選考の過程でずれが少なくなります。

8. まとめ：GraphQLは、決めた過程まで書くと伝わります

GraphQLが使えることではなく、スキーマをどう決め、運用の問題にどう向き合ったかを書くことが、経験を実績に変える一歩になります。

※公開中の求人数は時期によって変わります。記事中の求人の傾向は執筆時点のものです。

出典・参考情報

＊1 総務省「通信利用動向調査」（令和6年）