見積もりと計画

面接ではこう答える 読み上げ

見積もりは約束ではなく予測で、分からないことが多いほど外れる幅は大きくなります。既存のコードの複雑さ、外部との連携、テストやデータ移行のような実装以外の作業が、外れの典型です。私は「何日ですか」と1つの数字を聞くのではなく、「早くて何日、遅くて何日か、何が分かれば幅が縮むか」を聞き、外れそうなら早めに共有してもらえる関係を作るようにしています。

面接ではこう答える 読み上げ

ストーリーポイントは、作業の大きさを日数ではなく、ほかの作業と比べた相対的な大きさで見積もる方法です。1スプリントで終わったポイントの合計をベロシティと呼び、その実績の幅から残りの作業がいつ頃終わりそうかを見通します。PdM としては、チーム同士で比べたり、ベロシティを目標にしたりしないように気をつけ、スコープを削るかの判断材料として使っています。

面接ではこう答える 読み上げ

スパイクは、外部 API が使えるかや既存データの状態のように、調べないと見積もれないことがあるときに、期間を区切って調べるだけのタスクです。成果物はコードではなく分かったことと見積もりの更新で、試しのコードは捨ててかまいません。PdM としては、何が分かれば判断できるかと期間の上限を一緒に決め、結果を見て進める・やり方を変える・やめるを判断します。

面接ではこう答える 読み上げ

大きな機能は、画面・API・DB の層ごとに横に分けるのではなく、機能ごとに縦に切って、毎回ユーザーが使えるものを出すようにしています。例えば検索なら、キーワード検索だけを先に出し、次に絞り込み、次に並べ替えを足します。こうすると外れても早く気づけて、見積もりの外れも小さくなります。MVP も、何の仮説を確かめるかを先に決めて、そのための最小のものにします。

面接ではこう答える 読み上げ

計画が間に合わないときは、期限・範囲・人と費用の3つのつまみで調整します。期限が動かせない場合は範囲を削るのが基本で、そのために最初から必須とできればを分けておきます。人を足してもすぐには速くならず、途中から入ると説明の手間でかえって遅くなることもあります。テストを省くような品質の削り方は、障害と手戻りで高くつくので避けています。

面接ではこう答える 読み上げ

ロードマップは、何をどの順で取り組むかの見通しです。先の予定ほど不確かなので、すべてに日付を入れると外れたときに約束違反になってしまいます。私は Now・Next・Later のように順番と確度で示し、機能の一覧ではなく解く課題と目標の並びにしています。営業や顧客には確定した日付だけを予定と明記して伝えます。