序論
僕は現在、自分の会社で使う予定の通知システムを開発しています。その中で GitHub Issues を使ってタスクを管理し、ひとつずつ機能を改善しています。今回取り組んだのは Issue #3「表示用データフォーマッタの作成」です。
この Issue の目的はシンプルでした。「メール通知に含まれる内部キーや制御文字をきれいに整形し、利用者にとって見やすい形式で表示する」ことです。しかし実際にやってみると、Python のモジュール分割、ユニットテスト、インポートの仕組み、そして GitHub フローまで、学ぶことがたくさんありました。この記事では、その開発の流れと学びを整理します。
背景：なぜフォーマッタが必要だったのか
以前のメール通知には以下の問題がありました。
- 内部データのキー（data, details, property）がそのまま表示される
- 制御文字（全角スペース \u3000）が混じって読みにくい
- Excel の C列（物件名）が空欄だと何も表示されず意味が分からない
通知を受け取る利用者にとっては「余計な情報が混ざっている」「空欄の意味がわからない」という状態でした。そこで、内部データを正規化してからメール本文を生成する仕組みが必要になったのです。
ステップ1：フォーマッタの作成
フォーマッタは notifier/utils/display_formatter.py に実装しました。Python にモジュールとして認識させるために init.py も追加しています。
仕様は次の通りです：
- 内部キー（data, details, property）を削除
- 全角スペース \u3000 を半角スペースに変換
- C列が空欄なら「物件名なし」と出力
これだけでも通知メールの可読性が大幅に改善されました。
ステップ2：ユニットテストの導入
フォーマッタが正しく動くか確認するため tests/test_display_formatter.py を作成し、pytest で以下を検証しました。
- 内部キーが削除され、全角スペースが置換される
- C列が空欄なら「物件名なし」になる
- C列に値があればそのまま表示される
初めて pytest を使いましたが、テストが通ると安心感があり「壊していない」と自信を持てました。
ステップ3：インポートとモジュールの理解
開発中に最も苦戦したのは インポートエラー です。
Import "notifier.utils.display_formatter" could not be resolved という警告が VS Code に出ました。
解決方法は以下です：
- ディレクトリに init.py を追加
- VS Code の Python Interpreter を .venv に切り替える
- .vscode/settings.json に python.analysis.extraPaths を設定する
この過程で「Python がどのディレクトリをモジュール検索対象にしているのか」を理解できました。
ステップ4：メール送信処理への組み込み
フォーマッタは send_email 関数の冒頭で利用しました。
def send_email(subject, message_list):
subject = sanitize_for_display(subject)
message_list = [sanitize_for_display(m) for m in message_list]
...
こうすることで、ユーザーに届く直前に一度だけ正規化が走り、通知メールはきれいな形式になります。
ステップ5：property → C への置き換え
フォーマッタで property を削除すると本文生成に必要な値も消えてしまう問題がありました。
そこで本文生成では C を参照するようにリファクタリングしました。空欄なら「物件名なし」と出力され、ロジックもシンプルになりました。
ステップ6：Git/GitHub フローの実践
今回の作業は GitHub Issue #3 に対応するブランチ feat/3-display-formatter-min で進めました。
- テストが通ったらコミット
- 不要ファイルは .gitignore に追加
- PR 作成時に Closes #3 を本文へ記載
- マージ後に Issue が自動でクローズ
この流れを体験することで、実務的な GitHub フローを理解できました。
学びと気づき
- 責務分離の大切さ：フォーマッタをユーティリティ層に置き整理できた
- テストの安心感：pytest で「壊していない」と確認できた
- インポートの理解：init.py と VS Code 設定で解決
- データ構造の整理：property から C へ置き換え、表示と内部を分離
- GitHub フローの実践：Issue → Branch → PR → Merge → Close の一連を経験
まとめ
Issue #3「表示用データフォーマッタの作成」は小さな改善のようで、実際には テスト導入・モジュール理解・GitHubフロー・データ設計 など幅広い学びにつながりました。
小さな Issue を解決する積み重ねが、確実なスキルアップにつながると実感しました。