Shortlink

議事録を書いていて本当にあった怖い話

議事録担当となって5ヶ月となるが、未だノウハウをまとめるには至らず。思いの外好評なので発注元もなかなか引継ぎを許してくれない。早くノウハウを整理して新人にでも引き継ぎたいのだが。(先輩に引き継いだら見事にクレーム食らった)

議事録の手順と目的

会議へ出席してメモを取るという点では他の出席者と同じ。ただ、会議にはオブザーバとして出席しているので、発言権は一切無い。発言内容をひたすらメモするだけ。ひたすらメモを取って、会議後に所定の形式に整理して提出。その後は内部で回覧して指摘や修正があれば取り込む。そしてお客さんへ送付。

議事録の一番の目的は、「今回の会議で決まったこと」「次回の会議までにやらなければならないこと」を文書化し、証拠として残すこと。商売でやっている以上証拠を残しておくことが肝心で、方針や費用の話になったときに言った言わないの堂々巡りにならないように備えておかなければならない。また、それらがどのような経緯で決まったかを残しておくために、一連の発言を記録しておくことも行っている。

作業としてはこれだけなのだが、議事録を書いているときや回覧しているときにとんでもない質問を受けることが多々ある。あまりにも多いのでよくある質問としてまとめてみた。 Continue reading

Shortlink

内部レビューとバージョン管理

Subversion実践入門:達人プログラマに学ぶバージョン管理の続き。

どうも読んでいて引っかかったことが一点。バグ修正のタイミングについて。

以下、「1.1 バージョン管理の実際」より引用。

問題を絞り込むために、Fredはまずテストを書いた。

本番障害の調査手順だが、ここではまずテストコードを書いている。今までの自分の経験からすると、まずは本番の画面を叩いてログを見て…という流れになりそうだが、何よりも先にテストありきの前提で調査を行なっている。

…、コンパイルして、彼のテストで問題が発生しないことを確認した。そして、簡単な健全性テスト(sanity test)としてテストスイート全体を再実行してから、修正済みのコードを中央のバージョン管理システムにチェックインした。

やはり先に書いたテストコードありきという前提。ソースを修正してテストケースを書いて…という流れではない。どうもアジャイル開発を前提としている模様。 Continue reading