営業さんのやる気を奪うだけで生産性の低い「困った会議」には次の5つのタイプがあるそうだ。
- 報告会
- 独演会
- 尋問会
- 恫喝会
- 慰め会
プレジデント3月号の記事（Webからも参照できる）による。
ソフトウェアレビューの会議でも共通する部分が多い。レビューの場合、もっとバリエーションが多く、「参加してほしい者が出てこない」「何も決まっていない」「会議内容の取りこぼしがある」「効果が出ない」等、その理由はもっと幅広い。
ソフトウェアレビューでも、上述の「困った会議」と同様に目的の設定が曖昧か、設定があっても目的とズレていることが多い。目的を明確にし、効果の出るレビューにするためには、それなりの役割分担、ガイドライン、技法が必要になる。
テストとレビューの最も大きな違いは、教科書的にはプログラムが動く前でも実施できるのがレビュー、プログラムを動かしながら実施するのがテスト、ということになるだろう（私が担当する講義ではそう教える）。
テストにはテスト計画、テスト実施報告書等、実際にテストをやらなければ得られないエビデンスを提出することが求められ、その過程でも手順や技法を検討することになるが、レビューには現時点ではテストほどのものが求められていないというのが現状ではないだろうか。検討が十分でなければ結果や効果がばらつきにつながることが多い。
ソフトウェアレビューにおいて、安定した結果や効果がでない原因やそれらを防ぐための方法を紹介し、広めていくことの必要性を@ITに感じていただいた。私の研究グループでのこれまでの実証的な調査結果やよく起こっていることを連載で紹介していく。初回は非常に基礎的な内容だが、意外と陥りやすい記録に焦点をあてている。初回タイトルは「"確実な記録"こそが、品質・コストに貢献する」
今回のものは、普段、ここを読まれている方には少し物足りない可能性があるが、何かの気づきにつながれば幸いだ。回を重ねるにつれ、高度な問題点を取り上げていく予定だ。
Special
- PR -
ストレス社会との付き合い方
「思いやり経営」のススメ
テレワークが労働者のマインドを変える
求む、クックパッド男子
37歳の常識――我々は一生学び続ける