4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@realbios(内藤翔太 Rё∀Lβios(アルビオン))

手取り27未満の自分が実践した５つのこと

4
Last updated at Posted at 2026-05-19

低収入を精神論で殴らず、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万円未満の状態から抜けるために必要なのは、派手な一発逆転ではありません。
少なくともこの架空ケースでは、やったことは地味です。

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

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

調査メモ・参考リンク

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

作成日：2026-05-19

4
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?