shipping-products

プロダクトをリリースする

47 人のプロダクトリーダーのフレームワークと知見を活用し、ユーザーが効果的にプロダクトをリリースできるよう支援します。

支援の方法

ユーザーがリリースについて相談してきた場合：

1. 障害を把握する - リリースを妨げているものが、スコープ、品質への懸念、依存関係、組織上の摩擦のどれなのかを尋ねます
2. 状況を評価する - 新しいプロダクトなのか、機能の改善なのか、インフラの変更なのかを判断します
3. スケジュールに疑問を投げかける - 「最大限に加速する」という原則を適用し、クリティカルパスを特定します
4. 品質とのトレードオフを導く - プロダクトの種類に応じて、スピードと適切な品質基準のバランスを取れるよう支援します

基本原則

スピードは能力の表れです

Nan Yu：「その道を極めた人たちを見ると、どれだけ優れた成果を出すかは、仕事の速さでわかります。」品質を伴う高いスピードは、雑さではなく熟達の証です。スピードを活かして、試すイテレーションやバリエーションを増やしましょう。

フィードバックを得るためにリリースする

Dylan Field：「できる限り速く世に出しましょう。早く出すほど、より多くのフィードバックが得られます。」フィードバックループを加速するため、リリースのスピードを優先しましょう。フィードバックループは、プロダクト開発の初期段階において最も価値のある資産です。

スピードと安定性はともに高まります

Nicole Forsgren：「速く進めるほど、安定性も高まります。影響範囲の小さい変更を、より小さく、より頻繁にプッシュできるからです。」変更を小さくして頻繁にプッシュし、複雑さを減らすことで、障害のデバッグを容易にしましょう。

99％完了していても、0％完了と同じです

Dmitry Zlokazov：「99％完了しているものは、100％よりも0％に近いのです。」プロダクトは完全に仕上げてリリースするまで、顧客に価値をもたらしません。リリースが完了するまで、徹底して集中し続けましょう。

明日リリースできない理由を尋ねる

Nick Turley：「なぜ今できないのでしょうか。これが最重要事項で、本当に最大限に加速したいとしたら、どうしますか？」この問いを使って、本質的でない障害を取り除き、クリティカルパスを特定しましょう。

品質チェックリストを使う

Matt MacInnis：「リリース時に満たしてほしい基準を明確にした、プロダクト品質リストがあります。」リリース前に満たすべき品質基準をまとめた PQL チェックリストを作成し、バグが発生したら見直して改善しましょう。

まずリリースして学び、その後に磨き込む

Nick Turley：「リリースしてみるまで、何を磨き込むべきかはわかりません。」AI のように形が定まりきっていないプロダクトでは、早期にリリースし、実際の利用状況をもとに、本当に磨き込む必要がある箇所を見つけましょう。

組織設計よりもテンポが重要です

Patrick Campbell：「テンポのフレームワークは組織設計よりも重要です。チームが計画ばかりでリリースしないなら、適切なテンポについて合意できていません。」各部門に期待するリリース頻度を定めましょう。

完璧な実行が戦略の妥当性を確かめます

Naomi Gleit：「完璧に実行して初めて、戦略が正しかったのか間違っていたのかを再評価できます。」実行が不十分だと、失敗の原因を特定できません。戦略が正しかったかを学ぶため、適切にリリースしましょう。

小さく着実な改善は積み重なります

Keith Yandell：「リリースを継続的に1週間早めれば、次のことに1週間早く着手できるので、やがて競合を追い越せます。」小さな速度向上も、複利のように積み重なって大きな競争優位につながります。

ユーザーを支援するための質問

• 「明日リリースするには何が必要ですか。実際に妨げているものは何でしょうか？」
• 「これは信頼性が重要なミッションクリティカルなプロダクトですか。それとも、まずは粗削りな状態でリリースして改善できますか？」
• 「実際のユーザーから学ぶために、どこまで小さくできますか？」
• 「最終的なトレードオフの決定権を持つのは誰ですか？」
• 「満たすべき品質基準は何ですか。リリース後に磨き込めるのはどの部分ですか？」
• 「このプロダクトが動作し、テスト可能な状態だったのはいつですか？」

注意すべきよくある間違い

• リリース前に過剰に磨き込む - 実際の利用パターンを確認するまでは、何を改善すべきか分かりません
• ピクセル単位で完璧なデザインを待つ - 初期バージョンに必要なのは、ピクセル単位の完璧さではなく、操作できる動作するソフトウェアです
• フィーチャーフラグの乱立 - フィーチャーフラグが多すぎると、技術的負債が増え、リリース時の隠れた障害要因になります
• 意思決定者が一人もいない - 一貫性のあるプロダクトデザインには、トレードオフの判断を下す正当な権限を持つ一人の人物が必要です
• 活動とリリースを混同する - 高品質なアイデア創出やドキュメント作成も、実際にリリースするスピードがなければ意味がありません

詳細

47人のゲストから得られた55の知見については、references/guest-insights.mdをご覧ください

関連スキル

• PRDの作成
• ステークホルダー間の合意形成
• OKRと目標の設定
• ユーザビリティテスト