SoundLogは、マンション・アパートの騒音に悩む人が dB・日時・音声をワンタップで記録し、 管理会社に提出できるPDF報告書の生成からメール送信、その後の経過管理までをアプリ内で完結できるiPhoneアプリです。 市場分析・要件定義から実装・品質管理・課金設計・CI/CD・App Store公開まで、全工程を一人で担当しました。
手書きDartコード（自動生成を除く）。画面13・サービス15クラスを1人で実装
UI・PDF・メール文面まで日英中韓対応。翻訳の整合性チェックは自作ツールで自動化
リリースまでに18回のスキーマ変更。データを失わない3段階フォールバック付き
出荷前監査でデータ消失・課金・iOSパス切れなどの重大リスクを設計修正
騒音トラブルの当事者が本当に困るのは「測ること」ではなく「伝えること」。 管理会社に相談しても「いつ・どんな音が・どのくらい」を口頭で説明しきれず、対応が進まない—— その構造的な課題を、記録から報告・経過管理までの一気通貫で解決します。
dBを測るだけのアプリは無数にある一方、「記録を蓄積し、管理会社向けの報告書に整理し、送信し、経過を追う」 までを日本語でカバーするアプリは調査時点で見当たりませんでした（海外のThe Noise App等は日本未参入）。 機能の競争ではなく、「報告」という業務フローの空白を獲りにいくプロダクトです。
スマホのマイクによる簡易計測である以上、法的証拠としての効力は保証できません。 そこで「証拠を作るアプリ」ではなく「管理会社とのコミュニケーションを支える参考記録ツール」と定義し、 オンボーディング・PDF・ストア記載の各層で限界を明示。期待値を正しくコントロールする設計にしました。
ユーザーが置かれる4つの場面を起点に、機能ではなく体験の流れとして設計しています。
設計原則は「騒音が鳴っている瞬間に、3秒以内に記録完了できること」。 アプリを開けばリアルタイムdBメーターが動いており、赤いボタンをタップするだけで録音・dB値・日時が保存されます。 種類（足音・音楽・声など）や発生源の方向、深刻度、写真は、落ち着いてから後追いで追記できます。
ボタンを押せない場面のために、設定したdB閾値を連続3回超えると自動で30秒録音するモードを用意。 録音後はクールダウンを挟んで連続録音を防ぎ、Android展開ではフォアグラウンドサービスでOSによる強制終了を回避、 iOSではバックグラウンドオーディオで監視を継続します。静かな時間帯の環境音ベースラインも自動学習します。
記録は騒音日記とカレンダーに自動整理され、統計画面では曜日×時間帯のヒートマップ、 週次トレンド、平均・最大dB、環境基準の超過状況を確認できます。 感覚的な訴えが、第三者に伝わる客観的なパターンに変わる瞬間です。
3ステップの報告ウィザードで、状況に合うメール文面（初回の相談から緊急報告まで、トーン別の4テンプレート）を選び、 13セクション構成のPDF報告書と音声ファイルの添付を確認して送信。 送信後は相談履歴としてステータス（経過観察中／改善済み／未解決）を管理し、 14日経過でフォローアップをリマインドします。報告して終わり、にしません。
5タブ・13画面。すべての機能が「管理会社への報告」というゴールに向かって接続されています。
リアルタイムdBメーター・波形表示・録音を1画面に集約。記録の瞬間に迷わせないUI。
record / noise_meter / カスタム円形ゲージdB閾値を連続超過すると自動録音。プロセス保護やクールダウンなどOS事情を吸収。
flutter_foreground_task / UIBackgroundModes時系列とカレンダーの2ビュー。インライン再生、スワイプ削除、写真・メモの追記に対応。
table_calendar / just_audio曜日×時間帯ヒートマップ、週次トレンド、環境基準比較で発生パターンを可視化。
fl_chart / SQLite集計被害サマリー・発生源分析・記録一覧・添付音声対応表など13セクションをA4に自動整形。
pdf / NotoSansJP埋め込み / 4言語出力テンプレート選択→文面確認→添付確認のウィザード。送信はOS標準シートでユーザー自身が実行。
share_plus / MFMailComposeViewController送信済み報告をステータス管理し、経過メモを記録。14日経過でフォローアップを促す。
report_history / flutter_local_notificationsUI・PDF・メール文面まで日英中韓に対応。メールは言語ごとに文化的に自然な文面へ。
ARB 530キー / ReportL10nCSV+音声+写真のZIPエクスポート。Pro月額と消耗型チケットの2系統課金を実装。
archive / RevenueCat (Subscription + Consumable)騒音記録は「ご近所トラブル」という機微情報。録音・写真・記録はすべて端末内に保存し、 外部送信はユーザー自身のメール操作のみという設計です。結果として固定費は開発者登録料程度（月1,000円強）に収まり、 個人開発でも持続可能な運用になっています。
記録／日記／統計／レポート／履歴の5タブと、言語選択・規約同意・マイク較正などの初回フロー。ダーク／ライト両対応。
課金状態・クレジット残数・設定・言語を中央集権で管理。DB書き込み→状態更新→通知を1箇所に集約し、不整合を防止。
録音・dB計測・自動監視・PDF生成・メールテンプレート・課金・通知・ストレージ管理・エクスポート等を独立クラス化し、画面から分離。
記録・報告履歴・経過メモ・設定の4テーブル。録音（M4A）・写真・PDFは相対パスで参照し、500MB上限の自動クリーンアップ付き。
サブスク＋消耗型課金の購入検証・履歴管理。唯一の外部SaaS
PDFと音声の送信はユーザー操作で実行。アプリは勝手に送らない
gitタグ（ios-v*）起点でビルド→署名→TestFlight自動配信
Point: Firebase等のBaaSをあえて使わず、認証もサーバーも持たない。「個人情報を預からない」ことを プライバシー説明・ストア審査・運用コストの三方良しに効かせています。
Flutter本体だけでなく、録音・計測・帳票・課金・CI/CDまで、モバイルプロダクトの出荷に必要な周辺領域を一通り扱っています。
iOS版を先行してApp Store公開し、その後のAndroid展開も見据えて単一コードベースのクロスプラットフォームを選択。 一方でマイク監視のプロセス保護（Android FGS）やiCloudバックアップ除外（iOS）など、 OS固有の挙動はMethodChannelやプラットフォーム分岐で個別に対応しています。
Codemagic上で ios-v* タグをトリガーに、依存解決→コード生成→署名→ビルド番号の自動採番→TestFlight配信までを自動化。 リリースワークフローでは開発用フラグ（ENABLE_DEV_PRO）の混入をスクリプトで検知して失敗させる安全弁も実装しました。
「何を作ったか」よりも「なぜそう作ったか」。トレードオフと向き合った判断を、理由とセットで紹介します。
録音データや記録は一切クラウドに送らず、端末内で完結。共有はユーザー自身のメール操作に限定しました。
消耗型チケットの残数をローカルDBに直接持たせず、RevenueCatの購入履歴（トランザクションID）と 累計消費数から毎回算出する方式にしました。
18回のスキーマ変更に対し、「正規実行 → カラム単位のリトライ → 設定テーブルのみ再作成」の 3段階フォールバックを用意しました。
録音・写真・PDFのファイル参照を絶対パスから相対パスへ全面移行（schema v18でデータも一括変換）しました。
機種ごとのマイク感度差はキャリブレーション（5秒間計測→上下10%の外れ値除去→±20dBで補正）で吸収。 同時に、簡易計測の限界を製品の前提として明示しました。
UI（ARB）・PDF/メール（BuildContext非依存のReportL10n）・DB保存値（英字コード化）の3層で多言語を構造化。 4言語ARBファイルの整合性は自作チェックツールで機械検証します。
25年のSIer経験で身についた「監査・トラッキング・記録」の規律を個人開発に持ち込み、 自動テスト・実機確認・リリース前監査を組み合わせて重大リスクを出荷前に潰しました。
マイグレーション失敗時に全テーブル再作成される危険を監査で発見。3段階フォールバックへ設計修正し、蓄積記録の保全を最優先。
クレジット計算・購入ID照合・記録上限など、お金と利用制限に関わるロジックを重点的に自動テスト化。
iPhone実機でマイク権限、録音中のdB表示、PDF生成、報告フローを確認。審査で問われる導線も動画・画面で検証。
ARB4ファイルのキー欠落・プレースホルダ不一致を検出する自作ツールで、多言語の劣化を防止。
孤立ファイルの自動削除と容量上限管理（超過時は古い録音から80%まで削減・ユーザー通知付き）。
開発用Pro解放フラグの混入をリリース検証で検知。flutter test/analyzeも通し、出荷判断を機械チェックに寄せました。
App Store公開ビルドのスクリーンショットです。ダークテーマを基調に、dB数値は等幅フォントで視認性を確保しています。
エンジニアリングだけでなく、市場分析・価格設計・収益予測・審査対応までをプロダクトマネジメントとして実施しました。
着手前に市場を定量化し、「小さいが競合不在」のニッチであることを確認してから開発を開始しました。
騒音問題は解決したら用済み＝LTVが短い。月額一本ではなく、単発ニーズを拾う消耗型チケットを軸に据えました。
初版の収益予測は「個人開発・広告費ゼロ」の実績相場と乖離していたため、6日後に自ら全面下方修正。 DL数・課金転換率・サブスク継続期間（平均1.5ヶ月と想定）・ストア手数料を織り込み、 「初年度は年30〜50万円が現実的」と再評価した上でリリース判断をしました。
プライバシーポリシー・利用規約・サポートページの整備、マイク権限の用途明示、 簡易計測の多層免責、App Store審査向けの課金フロー実演動画の準備まで、 リジェクトリスクを潰してから提出。マーケティングサイトも自作・公開済みです。
要件定義書・監査記録・実装ステータスを常に最新へ保ち、AIコーディングエージェントを活用しながら、 要件・優先度・検証は自分で握るスタイルで個人開発の生産性と品質を両立させました。
TAM/SAM/SOM試算、競合調査、課金モデル設計。ビジネス分析ドキュメントを作成。
記録・日記・統計・レポート・履歴の5タブと録音/dB計測基盤。要件定義書v3.0として文書化。
監査で37件検出→全件改修。UI/UX改善20件、課金率改善7施策も並行実施。
tx-ID駆動クレジット管理、4言語整合性ツール、相対パス正規化（v18）。要件定義書をv5.0へ更新。
Codemagic CI/CD整備、TestFlight配信、マーケティングサイト公開、App Store公開。
Android展開の技術検証、AdMob・年額プランの検討、ASOチューニング。
SoundLogは「アプリが作れる」ことの証明ではなく、「プロダクトを発見し、設計し、品質を担保し、出荷する」 一連の意思決定を一人で回せることの証明として開発しました。
市場分析・価格設計から実装・CI/CD・App Store公開・マーケサイトまで、全レイヤーの意思決定を経験。
要件定義書・監査記録・ステータス管理を最新に保つ、25年のSIer経験に裏打ちされた進め方。
AIエージェントの出力を監査・機械検証・実機確認で受け入れる、再現性のあるプロセス設計。
楽観に流れない収益予測の自己修正、法務・審査リスクの先回り対応。
