顧客の前に
出せる
ソフトウェア。

段階は意図的に重なります。最初のスライスが見えた時点でデザインが始まります。実装は完璧なファイルを待ちません。最初の版を出す時点でスケールは頭にあります — 初日に作り込みすぎないだけです。

1. 01

   発見

   誰かがエディタを開く前に、やる仕事を書き出します。

   最初の会話はスタックではなくプロダクトです。誰向けか、既にあるもの、壊してはいけないもの、「完了」が実際にどう見えるか。ブリーフが散らかっているのは普通です — 実装できる具体さになるまで聞きます。

   仕事の形が文書で渡ります。範囲内、範囲外、最初のスライス、リスク、進め方。採用しても、しなくても構いません。誰も信じていない実装を始めるくらいなら、ここで止めた方がいい。

   手元に残るもの

   • 短い文書のスコープと成功条件
   • 範囲内、範囲外、後回しにできるもの
   • 出荷して学べる最初のスライス
   • 会話、デモ、意思決定の仕方
   
2. 02

   デザイン

   まだ安く変えられるうちに、プロダクトに異議を唱えられます。

   スコープを、クリックできるものにします。フロー、画面、繰り返す少数のコンポーネント。目的はきれいなファイルではありません。空状態、権限、誰も考えていなかった三回目のタップ — チケットになる前に、ぎこちない箇所を見つけることです。

   静的プロトタイプでは足りなければ、本番スタックでスパイクします。レビューは発注した人だけでなく、使う人と行います。合意したファイルが、そのまま実装対象です。どこかへ消えることはありません。

   手元に残るもの

   • クリックできるフローと中核画面
   • 小さなデザインシステム。200コンポーネントのキットではない
   • コメントに隠さない、名前のついた未決事項
   • 最初のスライスに沿った実装順
   
3. 03

   実装

   毎週動くソフトウェア。見て、試し、こちらが直します。

   キックオフにいた人間がコードを書きます。あなたが管理するリポジトリ、クリックできるものの週次デモ、意思決定の場所は一つ。薄い週があれば、そう言います。動くソフトウェアのないステータスは進捗報告ではありません。

   テスト、ログ、出荷の仕組みは途中で入れます — 最後の掃除ではありません。ずれは小さいうちに拾います。スコープは変わり得ます。トレードオフを書いておくので、請求書がサプライズにはなりません。

   手元に残るもの

   • あなたが所有するリポジトリ、環境、リリース経路
   • 動くソフトウェアの週次デモ
   • 誰も探せないチャット履歴ではなく、書いた決定
   • 後からの別案件ではなく、プロダクトに入った品質と監視
   
4. 04

   スケール

   ローンチは関係の終わりではない。

   本番公開こそ、本当の問いが始まります。本番のバグ、事業の変化、コードを理解する必要があるチームの新人。既に動いているものを固め、重要なものを測り、続けてほしいなら次のスライスを出し続けます。

   プロダクトは内製に戻せなければなりません。アーキテクチャ、テスト、メモは手元に残ります。残ってほしいなら残ります。そうでなくても、閉じ込められた感じにはなりません。

   手元に残るもの

   • 運用できる本番システム
   • エンジニアが追える引き継ぎメモ
   • 続けるなら、スコープ済みの次のスライス
   • チケットの空洞ではなく、返事のあるサポート