方針の見え具合で工数の確度が変わる

プロダクト制作やプログラミングの流れって以下を抽象度別に繰り返しているだけ

要件を列挙する

これは事前にできる

方針を列挙する

方針を決定する

形にする

こういったループを、

顧客の求める要件、という最も高い抽象度のものから、

sortできる関数を作る、という抽象度の低めのものまで

に対して、概念を分節しながら、繰り返し適用しているだけ

レベル感がある

要件は見えていて、方針も何となく決まっている

方針を考える時間、取捨選択する時間を考慮しておく必要がある

そもそも要件が見えていない

そもそも要件が見えていない、作らないと気付けない、ということがある

状態遷移の例外ケースを全部特定していないといけない

例えば、「文字数が多いときにどう表示するか」といったものは忘れられがち

文字数を短く強制する、最後を端折る、スペースを広げる、とかの対応が必要になる

タブのラベル部分の場合は、タブを横にスクロールする機能が追加で必要になる

知らない分野、知らないツールを導入するときは、

これが最初から全て予測できているなら、全てのプロダクトは、初回リリース時に完璧なものになっているはず

工数の話もそうだし、どうやって見えるようにするかという話もある

PDCAとかリーンとかよくあるパターンもだいたいこの話をしている