比較的大規模なプロジェクトの設計段階で思ったことなど。会議など頻繁に開かれると思いますが、聞いているだけだったり、各人が色々なことを喋って内容がまとまっていなかったり・・結局何をやりたいかわからなくなることがあるので大事なことについてメモ。
Contents
会議前について
会議を有意義なものにするために、ある程度以下の内容について、会議前に準備できているといいかと思います。
必要な前提知識
テーマに対する理解度が個人でバラバラだと会議にいっても聞いてるだけになってしまいます。
会議を聞くために最低限必要な情報などをアップデートしておくようにしましょう。前提知識があやしくないかのテストできればベスト
テーマ
話し合いたい内容。資料があるとやはり進みやすいです。
明確なゴール
次に述べますが、どこを目的とすべきかのゴールです。
できればデータパターンやYesNoなどで各人の認識の差異を吸収できればベストです。
タイムスケジュール
このテーマはこの時間までに話し合いたいなどしないとダラダラ長くなりがち・・・なのでゴールをもうけてできるだけオーバーしないように。
明確なゴールを決める
会議や打ち合わせのたびにポツポツと問題点が出てきてしまい、設計などがひっくり返る、なかなか決まらないことが多い場合、ユースケースから満たすべきテストケースを割り出し、そのテストケースを満たすことをゴールと考えると良いのではないかと思います。理想論かもしれないが・・・・
プログラムを造らない段階でもデータイメージは想定することが可能なため、テストケースの想定は可能なはず・・。
理想論を追求しすぎるといつまでたっても決まらないことが多いため、ある程度現実的な案を考えましょう。
どうしたら「ゴールになるのか」という点を明確に設けるように。
議事メモ
大きい単位のMTGなどは議事メモがあるかと思いますが、小さい各チームごとのMTGでも議事メモがあるとサマリーのようになってよいかと思います。
各人の認識のずれを抑える意味でも、箇条書き＋インデント方式で議事メモなどを取るように。
あまり発言してない人などが中心にとるといいかもしれないです。
アクションプランを考える
会議終わった後に、各人の認識がずれていたり、で、結局次何やるんだっけ？というようなことになりそうなので、終わった後にいつまでに、誰が何をやるかのタスクが明確になっているように。
レビュー時はチェックリストを設ける
レビューのたびにポツポツと問題点が出てくる場合、仕様、ドキュメントの体裁的なことに関して、チェックポイントを決めておくと内容に差異がなくなると思います。
チーム内での情報の情報共有方法を考える
チーム内での仕様の認識に齟齬が出るのは仕方ないかもしれませんが、各人でレビューをしあう、説明をし合うなどして、一人の人間が仕様を握っているということがないようにしておくと良いと思います。
データのテストパターンが一番現実的だと思います。
出来るだけ情報の同期ができる便利なツールを使う
１つの資料の情報の変更が、別の資料にも影響されるような資料を作るのが良いでしょう。
Excelであればなるべく関数やマクロを使い、手作業での修正量を押さえることが必要。(１つの修正で何箇所も修正が発生するような事態をなるべく避ける)
開発時と連携できるような資料がベスト(コードからドキュメントが開発できるなど)
