仕様書に書いていない機能が、
現場では動いていた。

32人日。4社をまたぐ商流の中で、要件定義と開発を並走させた。SQL応答が2.69秒に到達した時点でSLAの2.5秒を超えていた。インデックスの見直し、クエリ分割、キャッシュ設計の再構成。「動く」から「使える」への最後の0.19秒が、このプロジェクトの本質だった。

「クロス集計は要らない、今期はこれだけ届ければいい」——スコープを一度絞った。その判断が、チームの優先順位を常に明確にした。

参画した初日、コードレビューで分かった——商用スケールの設計ではなかった。前の開発会社がプロジェクト途中で抜けた。引き継ぎではなく、再構築だった。

4ヶ月。3つのユーザー像（ホール経営者・データクリエイター・ファン）それぞれに必要な機能を別々に設計した。移行過程で200件超のバグが顕在化した。1件ずつ潰した。「この段階での手抜きが3年後の保守コストになる」——その判断だった。

要件定義が進む中、奇妙な事実が判明した——正式な仕様書には一行も書いていないFAX確認フローが、現場では毎日動いていた。長年Salesforceを使い続ける中で誰も文書化しなかった運用が、現場の仕事を支えていた。

新システムはその「見えていた機能」も走らせなければならない。React.js + Nest.jsでフルスクラッチ再構築。5年分の患者データを移行しながら、FAX送受信・CSV自動連携・帳票出力の4機能を自社実装した。

BizOn!はフェイスブックと同等の機能を持つSNSプラットフォーム——フィード・DM・マッチング・イベント・プッシュ通知——をFlutterで構築。1つのDartコードベースから3プラットフォームを同時提供し、リリース後30日で14,284名の経営者がアクティブに利用する日本最大級の経営者ネットワークに。

広告収益レイヤーの追加は3つの制約を同時に引き起こした。Apple Steering規制（DartバンドルにコンパイルされたデータがiOSバイナリになる）・GMOのリダイレクト型3DS認証・特定商取引法対応。本番稼働中のアプリで、iOS App Store・Google Play・Webを単一ウィンドウで同時リリース。