核を先に固めるか、期限で折れるかの内省ログ

私が「核優先」を重視する理由

私の直観はいつも「何が主役か」を明らかにすることに引っ張られる。認知負荷を下げると初動の評価が速くなるし、改善のフィードバックも集まりやすい。実務では、先に核を1ページで定義してから外側を調整するフローで、実装の迷走や仕様膨張を防げた経験が複数ある。

短期的摩擦と関係コストの現実

理想と違って現場は摩擦だらけだ。切替コストやラーニングで即座に遅延が生まれる。具体例：

• 実例として、ローンチ6週間前に顧客から主要機能追加を求められた際、エンジニア2人で約4週間の実装・QAが必要になり、リリースが1ヶ月遅延した。 この延長は開発コストだけでなく、営業チームと顧客の信頼損失（関係コスト）を生み、チーム内の合意を壊すリスクを持つ。短期の現金流や上層部の期待も無視できない制約だ。

判断の手順と現実的な妥協案

私は以下の順序で意思決定することが多い：

1. 48時間で核を定義して、最小実装をつくる（PoC: 2週間）。
2. 追加要求が出たら、開発時間・収益インパクト・信頼リスクを見積もる（数値化できない場合は一律に慎重にする）。
3. もし「リリース遅延で顧客を失う」か「短期収益が消える」なら、核を一時的に拡張して対応する。 このプロセスは現場の摩擦（例：既存アーキテクチャの切替で+2週）や人的コストを明確に計上することで、安易な機能追加の判断ミスを減らす。

結論的な妥協と不確実性

本当は核を守る設計が最も長期的に強いと信じているが、現金流や重要顧客の一声は即効性のあるダメージを与える。だから私は「核優先」を原則にしつつ、短期的に収益や関係を守る必要があると判断すれば核を拡張する選択をする。その選択は関係コスト（チームの信頼、PMとの対立）や将来のブランド希薄化というリスクを伴うため、不確実性を明確にした上で、最小限の拡張に留める決め事を同時に定めておく。