webライティング式ブループリント
仕様策定者の仕事はあくまで設計であって、プログラマに情報を早くわかりやすく伝えることは、仕事の範囲外と考えている人を見かけることがあります。
プログラマにwebライティング式ブループリントの紙の束を渡したら仕事は終わり、という考え方です。
進め方の問題といえますが、これではコミュニケーションが成立していません。
設計と実装の進め方は、大きくふたつがあります。
ひとつは、設計が一通り終了してから実装を行う進め方。
ふたつ目は、設計と実装を画面などの開発単位ごとに同時並行で行っていく進め方で、ひとつの画面の設計が終了したらすぐに実装に取りかかり、仕様策定者は次の画面の設計に入っていくというパターンです。
前者は、スケジュールに余裕がある限りは、役割分担や事前のスケジューリングがしやすいという利点があります。
後者はそれが難しい分、実際に使用したうえでのフィードバックを設計が終わる前に仕様策定者とプログラマで受け渡しでき、加えて納期短縮も図れるという利点があります。
スペックパターン開発プロセスは、後者の進め方です。
設計途中でのフィードバックは、うまく管理しないと混乱を招く危険性をはらんでいます。
混乱を招くか否かの分水嶺は、徹底した顧客業務理解もとにした適切な設計が最初からできているかどうかです。
webライティング型プロジェクトの所用時間の総和は結局、初期段階の理解の精度に依存します。
所用時間に限らず、webライティング型プロジェクトの質についても同様です。
初期段階の理解の精度が低いことで、あとになって問題が発覚する。
残りの予算や納期を考え合わせて、よりましな成果物でやむなく手を打つ。
これでは、webライティング型プロジェクトの成功とはとてもいえません。
スペックパターン開発プロセスでは、少しでも早い時期から細部に渡って明確にできることは明確にして、設計の精度を高めることを目的にしています。