INSIGHTS
Insights
NEBULABの 設計・運用・意思決定 の記録です。
「何を選び、なぜそうしたか」を残し、次の判断材料にします。
※ 守秘のある内容は抽象化しています。個別案件の固有情報・数値・顧客識別情報は掲載しません。
記事・メモ
順次更新ここに載せるのは“唯一の正解”ではありません。 現場の制約に合わせて選択肢を組み替え、判断の理由を残すためのログです。
PUBLISHEDProcess
バックヤード機能を安全に拡張する：MVC + UseCase + DI + SQL分離
SUMMARY
レガシー基盤でも、責務分離と差し替え点の設計で“壊れにくい拡張”を作る。CSV抽出や除外管理のような運用機能を題材に整理。
CONTEXT
決済・請求などの業務領域では、変更の安全性（壊れない/説明できる/後から伸ばせる）が最優先。Controllerを薄くし、UseCaseに業務フローを集約、DIで差し替え点を明示、SQLテンプレで抽出条件を安定化します。
KEY POINTS
- Controllerは入力とレスポンス（CSV/画面）に専念
- UseCaseに業務フローを集約して拡張ポイントを固定
- DB操作はModelへ寄せ、業務ルールはUseCaseへ
- 抽出条件はSQLテンプレートで差分が追える形に
NEXT
- PDF生成・履歴管理など“後から積む機能”の設計ポイントを追記
- 監査/権限が絡む場合の分岐パターンを整理
PUBLISHEDPlace
NRT-LOFT：混み合わない前提で“集中を守る”運用設計
SUMMARY
場の体験は備品より運用で決まる。導線・案内文・ルールの微調整で、静かさと継続性のバランスを取る。
CONTEXT
拠点運営は“混雑を捌く”より“混雑しない”を設計する方が、体験も運用負荷も安定します。紹介制に近い運用や、期待値調整の文章設計など。
KEY POINTS
- 混雑回避は予約/紹介/案内文が効く
- ルールは“体験を守る”ための最小セットに
- 継続できる運用チェックリストを持つ
NEXT
- 案内ページの改善（期待値調整）
- 運用チェックリストの公開できる範囲を整備
IN PROGRESSProcess
改善を循環させる：ふりかえり→テンプレ化→再利用
SUMMARY
学びを“個人の経験”で終わらせず、テンプレ/チェックリストに落として再利用する。更新の運用まで含めて型化する。
CONTEXT
改善は発見より“再現”が難しい。短い雛形（仕様整理/ふりかえり/改善ログ）を作り、現場で回る更新ルールを決めます。
KEY POINTS
- 雛形は“埋めれば進む”粒度にする
- 更新ルール（いつ/誰が/どう）まで設計する
- 公開できる範囲で“判断の理由”を残す
NEXT
- 雛形を公開可能な形に整える
- 更新ルールを決めて運用に乗せる
設計や運用は、状況によって最適解が変わります。
「いまの制約の中で、どう進めるのが良いか」を一緒に整理したい場合は、気軽に相談してください。