議事録ドリブンな会議とテスト駆動開発
議事録ドリブンな会議は、議事録を書くことを中心に据えることで、議論の無制限な発散やあいまいな終結を避ける会議のやりかただ。プロジェクターにPCを繋げてリアルタイムに議事録を取り、合意事項をどんどんその場でレビューしながら書く。あいまいさはないし速い。
ところで、会議の目的が議事録を取ることだ、と言ったらおかしいよね。そんなはずない。会議の目的はアイデアの創出と合意形成で、さらに言えばそれを通じて最終的には組織のミッションの達成するのが本当の目的だ。お客さまの満足、とかね。じゃあ、お客さま第一主義で行こう会議、と言えばもっとエクストリームにいい会議になるかというと、それはちょっともう違う。価値や目的が重要とはいえ、あんまり直球勝負でそれをいっちゃうと逆によくわからなくなるなんてことがあるようだ。
じゃあこんどは、たとえば席順重要会議とか二時間に一度は休憩を取ろう会議と、議事録ドリブン会議はなにが違うの？って考えると、これは、着眼点はいくつかあるとしても、どのくらいダイレクトにゴールに向かっているかが違うのじゃないでしょうか。議事録ドリブンの場合は、議事録という、会議の直接のアウトプットに着目しているところがいいんでしょうね。議事録担当が困惑してるような進行の場合には、これはうまくいっていないということがよくわかる。最近よく言われる見える化みたいなことと結び付くようにも思います。ここで言う見えるっていうのは、うまくいっているのかヤバいのかがぱっと目に飛びこんで来て、うまくないならなんとかするための行動がすぐできること、ですね。
さて本命のテスト駆動開発のこと。議事録ドリブンな会議の目的が議事録ではないように、テスト駆動開発においてもテストが目的じゃない。ソフトウェア開発の真の目的はいろいろ意見があるとは思うけれど、ともかくそこへ向かっていく過程でいまどこまで来ているのかどんな感じなのかきっちり見えるようにして、ドライブ可能にして進めていこう、ってのがテスト駆動開発だと理解しています。テストで駆動することは目的ではなくて手段。テスト、すなわちあるべき振舞いを明確にして、それに沿っているかどうかに着目することで見えてくるいろいろなことに気づきを糧にドライブしようということ、でしょうか。具体的にはさまざまなテスト駆動の形があると思います。
ところで、テスト駆動開発はテスト技法ではなくて設計技法ですってよく言います。まあ僕も確かにテストというよりは設計かなという気もしないではないけれど、やっぱりゴメンなんかすこし違うと思う。メタファとして言っているんだったらまぬけな異論でごめんね。でも、設計か試験かって工程フェーズのどこなのって話みたいに聞こえてしまうんだ。そうじゃなくて、それはフィードバック重視とか重複駄目とかの、えーっとこれって価値とか原則に近いことじゃないかと。原則は、設計にだって試験にだって適用されると思うし、テスト駆動のテストが見える化するものから引き出されて、設計だって試験だってうまくものにしていきたいってことだよね。
