低収入を精神論で殴らず、SEの技術で「見える化」「自動化」「再現性」に寄せた話。

前提：この記事は完全なフィクションです。 実在の人物・勤務先・収入・転職活動とは関係ありません。投資、転職、副業、節約の成果を保証するものでもありません。

この記事で書くこと

「手取り27万円未満」という状況は、システムエンジニアにとって珍しい話ではありません。
ただ、そこから抜けるために「頑張る」「勉強する」「副業する」だけを言っても、だいたい続きません。
本稿では、架空の若手〜中堅SEが、生活と仕事をひとつのシステムとして扱い、改善した手順をまとめます。

Qiita向けなので、自己啓発だけでは終わらせません。家計、作業ログ、学習、成果物、職務経歴を
ログ、チケット、バッチ、メトリクスとして扱います。

なぜ「技術で生活を直す」のか

低収入状態のつらさは、単に金額が少ないことではありません。判断余力が削られることです。
毎月の固定費、残業、学習時間、転職準備、資格勉強、副業調査が全部頭の中にあると、CPUが常時100%になります。

なので最初にやるべきことは「気合い」ではなく、状態の外部化です。障害対応でログを取らずに原因調査しないのと同じで、
生活も仕事もログがなければ改善できません。

1. 家計を「ログ監視」にした

最初にやったのは、家計簿アプリを眺めることではなく、支出をCSVに落として月次バッチで集計することでした。
目的は節約ではなく、異常値検知です。

やったこと

カード明細と銀行明細をCSVでエクスポート
カテゴリを手で完璧に付けず、まずは固定費・変動費・浪費・投資の4分類だけにする
SQLiteに入れて、月ごとの差分を見る
「減らすもの」ではなく「残す価値があるもの」から判定する

import csv
import sqlite3
from pathlib import Path

db = sqlite3.connect("money_log.sqlite3")
db.execute("""
CREATE TABLE IF NOT EXISTS expenses (
    paid_at TEXT,
    vendor TEXT,
    amount INTEGER,
    category TEXT
)
""")

def normalize_category(vendor: str) -> str:
    rules = {
        "家賃": "fixed",
        "電気": "fixed",
        "ガス": "fixed",
        "通信": "fixed",
        "書籍": "learning",
        "Udemy": "learning",
        "AWS": "learning",
        "コンビニ": "variable",
    }
    return next((cat for key, cat in rules.items() if key.lower() in vendor.lower()), "unknown")

for path in Path("csv").glob("*.csv"):
    with path.open(encoding="utf-8-sig") as f:
        reader = csv.DictReader(f)
        for row in reader:
            vendor = row["利用店名"]
            amount = int(row["金額"])
            db.execute(
                "INSERT INTO expenses VALUES (?, ?, ?, ?)",
                (row["利用日"], vendor, amount, normalize_category(vendor))
            )

db.commit()

集計は雑でいいです。最初から完璧なデータ設計をすると、家計改善ではなくマスタ整備が目的になります。
ここでは「毎月なぜか消える3万円」を発見できれば勝ちです。

SELECT
  substr(paid_at, 1, 7) AS ym,
  category,
  SUM(amount) AS total_amount
FROM expenses
GROUP BY ym, category
ORDER BY ym, total_amount DESC;

ポイント： 節約ではなく、監視。浪費を責めるのではなく、再発防止策を作る。

2. 仕事を「チケット駆動」に寄せた

収入を上げるには、作業時間ではなく説明可能な成果が必要です。
ところが現場では「頑張りました」「色々対応しました」で終わりがちです。
それでは評価面談でも職務経歴書でも弱い。

そこで、仕事をすべて小さなチケットとして扱いました。JiraでもRedmineでもGitHub Issuesでも、最悪Markdownでも構いません。
大事なのは、作業の開始前に「完了条件」を置くことです。

# TASK-2026-0519-001: 夜間バッチの失敗原因調査

## 背景
月初処理で `ORA-01013` が断続的に発生している。

## 完了条件
- 直近3か月の発生時刻、処理対象件数、実行SQLを整理する
- 再現条件の仮説を2つ以上出す
- 暫定回避策と恒久対策を分けて記載する
- 関係者に判断してもらうための1枚サマリを作る

## 成果物
- investigation_ora01013_202605.md
- slow_query_candidates.sql
- meeting_summary.md

これを続けると、職務経歴書がかなり楽になります。
なぜなら「やった作業」がそのまま「再利用可能な成果ログ」になるからです。

3. 生成AIを「作業代行」ではなく「レビュー担当」にした

生成AIは便利ですが、低収入から抜ける目的で使うなら、雑に丸投げするよりレビュー担当にした方が効きます。
なぜなら、SEの価値は「責任ある判断」に残るからです。

使い方は単純です。仕様書、SQL、テスト観点、障害報告をAIに投げて、次の3つだけ見てもらいます。

前提が抜けていないか
反証・例外ケースがあるか
上司や顧客に出したときに誤解される表現があるか

あなたはシステム開発プロジェクトのレビュー担当です。
以下の仕様メモを読み、次の観点で指摘してください。

1. 要件として曖昧な箇所
2. DB・API・画面・バッチのどこに影響が出るか
3. テストケースとして不足している観点
4. 顧客に確認すべき質問
5. 設計書に落とすときの章立て

制約：
- 断定しすぎない
- 不明点は不明点として扱う
- 実装案より先に確認事項を出す

これで「作業が速くなる」というより、「手戻りが減る」効果が出ます。
手戻りが減ると、夜に学習・棚卸し・職務経歴更新をする余力が戻ります。

4. 学習を「求人票コンパイル」に変えた

勉強は大事ですが、収入改善が目的なら、好きな技術を無限に学ぶだけでは足りません。
架空の私は、求人票を30件ほど集めて、出現頻度の高いスキルを雑に数えました。

from collections import Counter
from pathlib import Path
import re

texts = "\n".join(p.read_text(encoding="utf-8") for p in Path("jobs").glob("*.txt"))

keywords = [
    "SQL", "Oracle", "SQL Server", "AWS", "Azure", "Docker", "Kubernetes",
    "CI/CD", "GitHub Actions", "要件定義", "基本設計", "テスト設計",
    "セキュリティ", "生成AI", "データ分析", "API", "運用保守"
]

counter = Counter()
for key in keywords:
    counter[key] = len(re.findall(re.escape(key), texts, flags=re.IGNORECASE))

for skill, count in counter.most_common():
    print(f"{skill}: {count}")

ここで大事なのは「流行っている技術」ではなく、「自分の現場経験と接続できる技術」を選ぶことです。
たとえば業務系SEなら、いきなり機械学習モデルを作るより、SQL改善、バッチ監視、API連携、テスト自動化、クラウド移行、
生成AIを使った設計レビュー補助の方が職務経歴に載せやすい。

5. 職務経歴書を「月次リリース」した

最後にやったのは、職務経歴書を転職直前に書かないことです。
月末に30分だけ、今月の成果を追記しました。

## 2026-05 実績ログ

### 障害対応
- 月次バッチのタイムアウト原因を調査
- 実行計画と処理件数の相関を確認
- 暫定対応として対象期間分割を提案
- 恒久対応としてインデックス見直しとSQL分割を起票

### 設計改善
- 外部IF仕様書の未定義項目を洗い出し
- エラーコード体系を整理
- 受入テスト観点を20件追加

### 数値
- 手戻り問い合わせ：前月比 -30%
- 夜間バッチ再実行：3回 → 1回
- レビュー指摘の一次回答時間：平均2日 → 0.5日

数字は盛る必要はありません。むしろ雑な数字を盛ると面接で死にます。
重要なのは「何を観測し、どう改善したか」を言語化することです。

まとめ

手取り30万円未満の状態から抜けるために必要なのは、派手な一発逆転ではありません。
少なくともこの架空ケースでは、やったことは地味です。

家計をログ化して、異常値を検知する
仕事をチケット化して、完了条件と成果物を残す
生成AIをレビュー担当にして、手戻りを減らす
求人票をコンパイルして、学習テーマを現実に寄せる
職務経歴書を月次リリースして、評価材料を蓄積する

低収入の問題を「自分の根性不足」にすると、だいたい詰みます。
でも、観測できるものに分解すれば、改善対象になります。
SEなら、生活もキャリアもシステムとして扱えます。

調査メモ・参考リンク

Qiita公式ガイドラインが重視する「エンジニアにとって再利用性・汎用性の高い内容」に寄せるため、個人語りだけでなく、コード・SQL・運用テンプレートを入れています。SE業務の工程やクラウド利用の広がり、DX/AI人材需要については公的資料を参照しました。

作成日：2026-05-19