Set-Based vs. Point-Based

最近、チームのロードマップを敷く仕事をした。
具体的にはアプリの安定性を上げるためにこの四半期何をするか上層へのプレゼンをした。ただ、上手くまとめられた気がしなかった。
実行予定のアクションを羅列しただけで、スッキリ要点を伝えられた感触がなかった。
マネージャーに相談すると、Set-Based DesignとPoint-Based Designの違いを意識するといいというフィードバックをもらった。

よく使われるのはPoint-Basedで、物事を決め打ちで計画していく方法だ。
多少の不確実性があっても、何をすればいいかほぼ明確であるなら期限を設定してタイムラインを引くだけ。 しかしプロジェクトの途中で計画を変更するときには他のオプションを立ち止まって再考しなければいけないので、コストがかかってしまうのが欠点だ。

比べてSet-Based Designはあらかじめ様々なオプションを用意して、具体的な計画を練り切らずにプロジェクトを始めてしまう。プロジェクトの途中で得た学習を元に臨機応変に次の予定を調整していくことを前提にしているので仮説検証のループが回しやすい。まさにアジャイルの手法といえる。

今回私の場合は、いくつかあったアイディア全てを実行したとしても必ず「安定性」と言うゴールを達成できると言いきることができなかった。なぜなら「安定性」はあまりにも広義で、私が提示したアクションは可用性や保守性といった安定性が包括する一部分に対するアクションに過ぎず、安定性に大きく影響を与えると言い切れなかった。
もしSet-Based Designを意識していたら、プレゼンでは実際のアクションにフォーカスせず、何を目標にするか（可用性を上げるなど）を要点として伝えられた。
特に上層レイヤーにとっては実行する計画の中身よりもどのような観点でプロジェクトを進めていくか、どのようなオプションがあるか分かるだけで十分であるからだ。

次からはキッチリ計画を立てなくとも、オプションを用意しながら進んでみてもいいのかもしれない。