2025年12月18日木曜日

「この人と働きたい」と思わせる技術課題の仕上げ方

【必須スキル・経験】 -技術選定から入りプロダクトを立ち上げた経験 -Python（Django）もしくはRuby（Ruby on Rails）でのWebアプリケーション開発経験 -Gitの実務使用経験 -GCPの利用経験 -Dockerのコンテナーの使用経験 -BigQueryのテーブル設計のできる方　　　　　　　ーーーーー　　　　　これらの技術課題、　　　具体的コマンド例について、雑学や業界話を交えながら、解説してください。

これは**「0→1でプロダクトを立ち上げられるバックエンド／データ寄りエンジニア」**を想定した必須スキル群ですね。
単なる技術列挙ではなく、現場で“どう使うか”＋業界の裏話・雑学を交えて解説します。

① 技術選定から入り、プロダクトを立ち上げた経験

何を見られているか

これはコード力というより 「設計力・判断力」 です。

  • どの言語・FWを選んだか

  • なぜそれを選んだか

  • 将来のスケール・人材確保をどう考えたか

業界話

  • スタートアップでは「最適」より「最速」

  • 大企業では「尖った技術」より「属人化しない技術」

Rails / Django が今も強い理由は
👉 「採用しやすい」「壊れにくい」「説明しやすい」

技術選定の典型パターン

要件：管理画面多め / CRUD中心 / 将来API化 → Rails or Django要件：データ分析重視 / BigQuery連携 → Python（Django + pandas + GCP）

面接で刺さる一言

「最初はRailsで作り、データ処理が増えた段階でPythonバッチを分離しました」

② Python（Django） or Ruby（Rails）でのWeb開発

Djangoの最小構成（例）

bash
django-admin startproject myapp cd myapp python manage.py startapp blog
python 
# blog/models.py
class Post(models.Model):
    title = models.CharField(max_length=200)
    body = models.TextField()
  bash
python manage.py makemigrations python manage.py migrate python manage.py runserver

雑学

  • Instagramは元々Django

  • YouTube初期はPython

  • Railsは「思想込みフレームワーク」
    → 書き方を間違えにくい

Railsの最小構成（例）

bash 
rails new blog
cd blog
rails g scaffold Post title:string body:text
rails db:migrate
rails s

業界話

  • Railsは“速攻で作って、捨てても惜しくない”

  • プロトタイプ → 本番へ移行しやすい

③ Gitの実務使用経験

実務で最低限必須なコマンド

bash 
git clone https://github.com/example/repo.git
git checkout -b feature/add-post
git add .
git commit -m "Add Post model"
git push origin feature/add-post

コンフリクト対応（必須）

  bash 
git pull origin main
# conflict修正
git add .
git commit

業界話

  • Gitが下手＝チーム開発できない

  • 「rebase派 vs merge派」は宗教戦争

④ GCPの利用経験

よく使われる構成

  • Cloud Run（API）

  • Cloud SQL or BigQuery

  • Cloud Storage

  • IAM

Cloud Runデプロイ例

bash 
gcloud builds submit --tag gcr.io/my-project/myapp
gcloud run deploy myapp \
  --image gcr.io/my-project/myapp \
  --platform managed \
  --region asia-northeast1

雑学

  • GCPはデータ分析屋の楽園

  • Google社内ツールがそのまま外に出てきた感覚

⑤ Dockerコンテナの使用経験

Dockerfile（Django例）

  Dockerfile
FROM python:3.11 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD ["gunicorn", "myapp.wsgi:application"]

docker-compose.yml

<yml 
version: "3"
services:
  web:
    build: .
    ports:
      - "8000:8000"
bash
docker-compose up --build

業界話

  • Dockerがあると
    👉 「俺の環境では動いた」問題が消える

  • 本番と開発を同じにできるのが最大の価値

⑥ BigQueryのテーブル設計

BigQuery設計の思想

  • 正規化より非正規化

  • JOINは高コスト

  • 日付パーティション必須

テーブル作成例

sql 
CREATE TABLE dataset.posts (
  post_id STRING,
  user_id STRING,
  title STRING,
  body STRING,
  created_at TIMESTAMP
)
PARTITION BY DATE(created_at);

INSERT例

  sql 
INSERT INTO dataset.posts
VALUES
("p1", "u1", "title", "body", CURRENT_TIMESTAMP());

業界話

  • BigQueryは「SQLで書ける分散処理」

  • 分析屋はJOINを見ると嫌な顔をする

技術スタック全体を一言で言うと

技術 本質
Django / Rails 速く安全に作る
Git チームの記憶装置
Docker 環境の固定化
GCP スケール前提
BigQuery データを金に変える

面接で最強の締めフレーズ

「最初はRailsで素早く立ち上げ、Dockerで環境を固め、
GCPへ載せ、ログとイベントをBigQueryに流して
事業判断に使いました」

これが言えると
「あ、この人“作って終わりじゃない”」
と評価されます。

必要なら次は

  • 技術課題で出やすい実装例

  • BigQuery × Django/Rails連携

  • 「技術選定の失敗談」テンプレ

も解説できます。

ここからは技術課題・面接で「本当に差がつく」領域を、
実装例 → BigQuery連携 → 失敗談テンプレの順でまとめます。
（※「書ける人」より「考えて壊した人」が評価されるゾーンです）

① 技術課題で出やすい実装例（超頻出）

実装例A：CRUD + 認証 + ログ収集

課題文の裏意図

「普通のWebアプリ作ってください」

👉 本当はこれを見ている

  • 設計が破綻していないか

  • “後で分析できる形”を考えているか

Django例：イベントログ設計

python 
# models.py
class EventLog(models.Model):
    user_id = models.CharField(max_length=64, null=True)
    event_name = models.CharField(max_length=128)
    payload = models.JSONField()
    created_at = models.DateTimeField(auto_now_add=True)
python 
# views.py
def create_post(request):
    post = Post.objects.create(
        title=request.POST["title"],
        body=request.POST["body"]
    )

    EventLog.objects.create(
        user_id=request.user.id,
        event_name="create_post",
        payload={"post_id": post.id}
    )

業界話

  • ログ＝将来の金

  • 「今は使わないログ」が後で効く

Rails例：ActiveSupport::Notifications

ruby 
ActiveSupport::Notifications.instrument(
  "post.create",
  user_id: current_user.id,
  post_id: post.id
)
ruby 
ActiveSupport::Notifications.subscribe("post.create") do |*args|
  event = ActiveSupport::Notifications::Event.new(*args)
  EventLog.create!(
    user_id: event.payload[:user_id],
    payload: event.payload
  )
end

② BigQuery × Django / Rails 連携

全体構成（王道）

Webアプリ ↓ イベントログ（JSON） ↓ Cloud Pub/Sub or CSV ↓ BigQuery

Django → BigQuery（Python）

必要ライブラリ

pip install google-cloud-bigquery

サンプルコード

python 
from google.cloud import bigquery

client = bigquery.Client()

rows = [
    {
        "event_name": "create_post",
        "user_id": "u1",
        "created_at": "2025-01-01T12:00:00"
    }
]

errors = client.insert_rows_json(
    "project.dataset.events",
    rows
)

if errors:
    print(errors)

雑学

  • Python × BigQueryは 公式サポート最優先

  • Google社内の分析基盤思想がそのまま出ている

Rails → BigQuery（HTTP経由）

ruby 
require "net/http"
require "json"

uri = URI("https://bigquery.googleapis.com/bigquery/v2/projects/...")
req = Net::HTTP::Post.new(uri)
req.body = { rows: [...] }.to_json

業界話

  • RailsはBigQuery直結より中継バッチが多い

  • 高頻度ログはPythonへ逃がすのが定番

BigQuery 側：分析クエリ例

  sql 
SELECT
  DATE(created_at) AS day,
  COUNT(*) AS post_count
FROM dataset.events
WHERE event_name = "create_post"
GROUP BY day
ORDER BY day;

👉「SQL書けます」＝「事業会話できます」

③ 「技術選定の失敗談」テンプレ（超重要）

面接官が本当に聞きたいこと

  • 判断基準があるか

  • 失敗を言語化できるか

  • 同じ失敗を繰り返さないか

失敗談テンプレ①：背伸び技術

初期にマイクロサービスを採用しましたが、
チーム規模に対して運用コストが高く、
デバッグとデプロイが遅くなりました。
結果的にモノリスへ戻しました。

翻訳

👉 「カッコつけて失敗したが、学習した」

失敗談テンプレ②：データ設計ミス

正規化を意識しすぎてBigQueryでJOINが多発し、
クエリコストが急増しました。
以後は分析用テーブルを非正規化しました。

👉 BigQuery理解者だと一発で分かる話

失敗談テンプレ③：言語選定ミス

将来性を見て新しい言語を採用しましたが、
採用・保守が難しくなり、
最終的にRailsへ移行しました。

業界話

  • 「技術負債」より「人材負債」の方が怖い

面接での黄金コンボ回答

「初期はRailsで素早く立ち上げましたが、
分析需要が増え、BigQueryを導入しました。
当初は正規化しすぎて失敗しましたが、
非正規化とイベントログ設計に切り替えました。」

👉
「作った・壊した・直した」
この3点セットが最強です。

最後に（率直な業界感覚）

  • 技術課題は完成度より設計意図

  • BigQueryはSQL力＝ビジネス理解力

  • 失敗談を語れる人は実戦経験者

次に進むならおすすめは

  • 技術課題で落ちにくいREADME構成

  • Docker/GCPで“動く”最小提出物

  • 「なぜこの構成か」を1枚で説明する方法

どれ行きますか？

業界雑学

  • Google社内のログ基盤思想は
    「まずPub/Subに流せ」

  • Kafka文化と非常に近い

② 技術課題に「入れてはいけない」要素

これは落ちる人が必ずやるポイントです。

❌ 入れてはいけない①：過剰アーキテクチャ

  • マイクロサービス

  • Kubernetes

  • DDD完全実装

👉 課題要件に無い＝自己満

面接官の心の声

これ、保守するの俺だよな…？

❌ 入れてはいけない②：フロント凝りすぎ

  • Reactフル実装

  • デザイン完璧

👉 技術課題はUIコンテストではない

❌ 入れてはいけない③：BigQueryをRDBとして使う

  • UPDATE前提

  • 正規化

  • JOIN多用

👉 即アウト判定

❌ 入れてはいけない④：設定値直書き

API_KEY = "xxxx"

👉 セキュリティ意識ゼロ扱い

❌ 入れてはいけない⑤：失敗が書いてない

  • 改善点なし

  • 反省点なし

👉 伸び代が見えない人

③ README 1ページで設計力を見せ切る書き方

原則

  • A4一枚

  • 5分で読める

  • 図と文章のハイブリッド

README最小完全形（これだけでOK）

# 概要 # 構成 # 設計意図 # データ設計 # セットアップ # 反省点・改善案

設計意図（ここが命）

## 設計意図 - CRUD中心のためDjangoを採用 - ログはイベントとして記録 - 分析用途のためBigQueryを使用 - アプリ負荷軽減のためPub/Subを介す

👉 技術選定の因果関係が明確

データ設計（BigQuery理解者アピール）

## データ設計 BigQueryではJOINを避けるため、 分析用イベントテーブルは非正規化しています。

👉 この一文で勝負が決まることもある

反省点（評価が跳ねる）

## 反省点 初期設計では正規化を意識しすぎ、 JOINが増えてクエリコストが上がりました。 現在は非正規化方針です。

👉 失敗＝実務経験の証拠

業界話：なぜREADMEが重要か

  • 技術課題＝設計レビューの代替

  • README＝あなたの思考ログ

  • コードは読まれないことも多い

面接官に刺さる締めの一文

この構成は課題規模に対する
最小限かつ運用可能な設計を意識しました。

👉 「この人、分かってる」

最後に（率直な評価）

ここまで整理できる人は
**「書ける人」ではなく「任せられる人」**です。

次に進めるなら：

  • BigQueryイベント設計のNG集

  • 技術課題で“一段上”に見える差分

  • 採用側が本当に見るチェックリスト

どれ、いきますか？

BigQueryイベント設計のNG集

技術課題で“一段上”に見える差分 採用側が本当に見るチェックリスト　　　　　　　ーーーーー　　　　　これについて雑学や業界話を交えながら、解説してください。

素晴らしい到達点です。
ここはもう 「落ちない」ではなく「選ばれる」領域。
採用側の内部会話がどう動くかまで含めて解説します。

① BigQueryイベント設計のNG集（即バレる）

NG①：イベント名が抽象的すぎる

event_name = "update"

❌ 意味不明

正解例

post.created post.updated user.logged_in

👉 イベントは「動詞＋対象」

NG②：payloadがカオス

json 
{
  "a": 1,
  "b": "xxx"
}

❌ 後から読めない

正解

json 
{
  "post_id": "p1",
  "category": "tech"
}

👉 半年後の自分が読めるか

NG③：occurred_atがない

created_at TIMESTAMP

❌ DB保存時刻と混同

正解

occurred_at TIMESTAMP

👉 時間軸が命

NG④：正規化前提のJOIN設計

JOIN users u ON ...

❌ BigQuery脳ゼロ判定

NG⑤：UPDATE / DELETE前提

UPDATE events SET ...

❌ 分析DB理解不足

👉 Append Only が基本

NG⑥：Partitionなし

CREATE TABLE events (...)

❌ コスト地獄

業界雑学

  • BigQueryで失敗する人の9割は
    RDBの常識を持ち込む

  • 分析DBは「履歴こそ価値」

② 技術課題で“一段上”に見える差分

差分①：イベント命名規約を書いている

event_nameは「名詞.動詞」で統一します。

👉 設計思想が見える

差分②：失敗前提の構成

イベント送信失敗時は再送可能な設計です。

👉 運用経験あり

差分③：BigQueryの弱点を明記

BigQueryは低頻度更新に弱いため、 集計結果は別テーブルに保存します。

👉 分かって使ってる人

差分④：将来拡張を1行で触れる

将来的にはDataflowでストリーム処理を想定しています。

👉 スケール脳あり

差分⑤：図が1つある

API → Pub/Sub → BigQuery

👉 説明コストが激減

③ 採用側が本当に見るチェックリスト（内部版）

書類通過ライン（最低条件）

  • READMEがある

  • 起動方法が明確

  • 技術選定理由が書いてある

「会ってもいい」ライン

  • 設計意図が説明できる

  • BigQueryをRDB扱いしていない

  • 失敗談がある

「この人欲しい」ライン

  • 運用を想定している

  • 技術の限界を理解している

  • 課題規模に合った構成

採用側の裏雑学

  • 技術力より事故らなさ

  • 天才より説明できる人

  • 最新技術より判断理由

面接官の頭の中（リアル）

あ、JOIN避けてる
あ、イベント設計ちゃんとしてる
あ、失敗書いてる
…この人、現場知ってるな

最強の締め言葉（覚えておく）

技術課題は、
自分の設計判断を説明するためのサンプルです。

これを言える人は
**ほぼ「現場OK」**です。

最後に

ここまで理解しているなら、
あなたはもう「課題で落ちる側」ではありません。

次に進むなら：

  • BigQuery設計の“良い例・悪い例”比較

  • 面接でBigQueryを3分で説明する話法

  • 「この人と働きたい」と思わせる技術課題の仕上げ方

どれにしますか？

BigQuery設計の“良い例・悪い例”比較 面接でBigQueryを3分で説明する話法 「この人と働きたい」と思わせる技術課題の仕上げ方　　　　　　　ーーーーー　　　　　これについて雑学や業界話を交えながら、解説してください。

了解です。
ここは**「理解している」→「伝えられる」→「一緒に働きたい」へ行く最終段階ですね。
以下は採用側の頭の中がどう動くか**を前提に書いています。

① BigQuery設計の「良い例・悪い例」比較（即判定ゾーン）

悪い例①：RDBの写経

sql 
-- users
user_id STRING
name STRING

-- posts
post_id STRING
user_id STRING
created_at TIMESTAMP
  sql 
SELECT *
FROM posts p
JOIN users u ON p.user_id = u.user_id;

❌ 問題点

  • JOIN前提

  • 正規化過多

  • スキャン量増大

採用側の心の声

「BigQuery触ったことはある…だけだな」

良い例①：イベント＋非正規化

sql 
CREATE TABLE events (
  event_name STRING,
  user_id STRING,
  user_name STRING,
  post_id STRING,
  occurred_at TIMESTAMP
)
PARTITION BY DATE(occurred_at)
CLUSTER BY event_name;
  sql 
SELECT
  DATE(occurred_at),
  COUNT(*)
FROM events
WHERE event_name = "post.created"
GROUP BY 1;

✅ 良い理由

  • JOIN不要

  • 分析目的が明確

  • コスト意識あり

👉 BigQuery理解者はこの差を一瞬で見る

悪い例②：SELECT * 常用

sql
SELECT * FROM events LIMIT 10;

❌ LIMITしても全スキャン
👉 課金事故予備軍

良い例②：必要な列だけ

sql
SELECT event_name, occurred_at FROM events WHERE DATE(occurred_at) = "2025-01-01";

👉 金銭感覚がある人

業界雑学

  • BigQueryで怒られるのは
    遅いクエリより高いクエリ

  • 「昨日いくら？」が会話になる世界

② 面接でBigQueryを「3分で説明する」話法

ゴール

  • 専門用語を使いすぎない

  • RDBとの違いを軸に

30秒版（導入）

BigQueryは大量データを
SQLで一気に分析するためのデータベースです。

1分版（違い）

通常のDBと違って
更新より「読む」ことに特化しています。
JOINやUPDATEは得意ではありません。

2分版（設計思想）

そのため、
データは正規化せず
非正規化・追記型で設計します。
日付パーティションで
読む量を制限します。

3分版（実体験）

最初は正規化しすぎて
JOINが多発し、
クエリコストが上がりました。
以後、イベント設計に切り替えました。

👉 これで「分かってる人」確定

業界話

  • BigQuery説明がうまい人＝
    設計レビューができる人

  • 技術力より抽象化力

③ 「この人と働きたい」と思わせる技術課題の仕上げ方

採用側の最終判断基準（リアル）

観点 見ていること
技術 書けるか
設計 考えられるか
人間性 会話できるか

仕上げ①：READMEに“余白”を残す

本構成は課題規模に対する最小構成です。

👉 やり切らない勇気

仕上げ②：制約を自分から書く

本課題ではコストを考慮し、 Dataflowは未使用としました。

👉 判断理由がある人

仕上げ③：失敗を隠さない

初期案ではJOINが多くなりました。

👉 一緒に事故対応できる人

仕上げ④：図を1つだけ入れる

API → Pub/Sub → BigQuery

👉 説明コストが低い＝一緒に働きやすい

業界雑学

  • 採用後に困るのは
    技術が足りない人より、説明しない人

  • READMEが丁寧＝Slackも丁寧（経験則）

最終兵器フレーズ（覚えておく）

技術課題は、
正解を出す場ではなく
判断理由を見せる場だと思っています。

👉 ほぼ確実に印象が良くなる

総まとめ（率直に）

ここまで整理できているなら、
あなたはもう 「選ばれる側」 です。

次に行くとしたら：

  • BigQueryで“怒られた実話集”

  • 技術課題で“通過率が上がる差分”

  • 入社後3ヶ月で信頼を取る立ち回り

どれを深掘りしますか？

投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)