プロダクト開発の成功は『言語化』にかかっている
アマゾンのすごい「逆算資料」。新サービス説明資料は「プレスリリース形式」で
プレスリリース駆動
「言語化」とは?
-
-
フローではなく「ストック」で残すこと(後からいつでも閲覧できる)
-
どこに情報があるか分かりやすい状態のこと(分散していない)
組織におけるタブー
-
内容を把握しているのがプロダクトマネージャーだけ、という状況はよくある
暗黙の了解
-
聞いたら分かるではなく、だれでも見ればわかる状態にしないといけない
仕様のブラックボックス化
リリースされて10年以上経過しているプロダクトだと「誰も仕様が分かっていない」状況は珍しくない。完全にシステムがブラックボックス化し、いつ不具合で爆発するかわからない。
面倒でも、言語化していくことでこの状況は回避できる。
ドキュメントと実態が異なる場合もあるが、それはそれで余計なキャッチアップが必要になるため良くない。
-
要求定義
-
要件定義
これらは解釈幅がとても大きく、ドキュメントにしないと必ず認識がずれる
あると良いドキュメント
-
プロダクト戦略(コンセプトと方向性)
-
重要な機能のPRD(検討経緯と結論)
-
技術スタックと設計概要
-
過去の失敗施策とその考察
ドキュメント化の実例
-
プロジェクトごとにワークスペースを作成
-
定例の議論内容は必ず議事録にする
-
検討経緯もドキュメントにする
-
発生タスクを一覧化