比較的大規模なプロジェクトの設計段階で思ったことなど。
明確なゴールを決める
会議や打ち合わせのたびにポツポツと問題点が出てきてしまい、設計などがひっくり返る、なかなか決まらないことが多い場合、ユースケースから満たすべきテストケースを割り出し、そのテストケースを満たすことをゴールと考えると良いのではないかと思います。理想論かもしれないが・・・・
プログラムを造らない段階でもデータイメージは想定することが可能なため、テストケースの想定は可能なはず・・。
理想論を追求しすぎるといつまでたっても決まらないことが多いため、ある程度現実的な案を考えましょう。
どうしたら「ゴールになるのか」という点を明確に設けるように。
レビュー時はチェックリストを設ける
レビューのたびにポツポツと問題点が出てくる場合、仕様、ドキュメントの体裁的なことに関して、チェックポイントを決めておくと内容に差異がなくなると思います。
チーム内での情報の情報共有方法を考える
チーム内での仕様の認識に齟齬が出るのは仕方ないかもしれませんが、各人でレビューをしあう、説明をし合うなどして、一人の人間が仕様を握っているということがないようにしておくと良いと思います。
データのテストパターンが一番現実的だと思います。
出来るだけ情報の同期ができる便利なツールを使う
１つの資料の情報の変更が、別の資料にも影響されるような資料を作るのが良いでしょう。
Excelであればなるべく関数やマクロを使い、手作業での修正量を押さえることが必要。(１つの修正で何箇所も修正が発生するような事態をなるべく避ける)
開発時と連携できるような資料がベスト(コードからドキュメントが開発できるなど)
