常識と反対
時として常識と反対側に解決策がある場合がある。
常識がじゃまをして真実がみえなくなることは非常に多い。
要求開発アライアンスの合宿中に雑談のなかででてきてハッとした点をいくつか。
その1,名前を使わない解決。
普通は、名前つけをしたり、共通認識としての名前を使うことで解決しようとするわけですが。( Name and conquer )
お客さんに説明するときに「UML」でやりますとか、「〜〜方法論」でやりますとか名前を言ってしまうと、「むずかしそう」とかその方法論を「理解しておかなければならない」という脅迫観念が生まれ、結果としてなにも適用できないということになりかねない。
そういう場合は名前をつかわず、にいきなりやってしまって、説明のテクニックでカバーうことでうまくいく場合が多い。
特にビジネスの構造を確認するときのクラス図は、オブジェクト指向がまったくわからない人にも説明可能だという実績はある。
その2,仕様変更を無制限に受け付ける。
これこそ常識とは正反対である。
仕様変更なのかバグなのかっていう判断は、グレーな場合がおおい。 そういうジャッジメントを一切やらずに言われたことは全部やると宣言してしまうわけである。 この方法で成功した例を聞いて本当に度肝を抜かれた。
このことの利点は、
- ジャッジメントにかかるコストが一切かからない。
- 会議を開いたり、調査したりにかかる工数は意外にバカにならない。 殆どの場合その工数で直してしまえる場合が多いという事実がある。
- 精神的に楽
- 仕様変更かバグかのグレーゾーンについて、戦わなくてすむので、感情レベルの関係が悪くならない。
- 開発側がお客様の必要に答えているという実感が持てる。
このことの欠点は、
- 赤字リスクがある
- 最初からバッファをみてこの範囲で受け付けますという進め方はできるだろう。
要求開発アライアンスの合宿は、刺激になる話題満載で、あまりに盛りだくさんで、ここには書ききれない。 問題意識の共有と可能性の探究はとても大きなエキサイトメントを生み出す。
本題の要求開発2.0の展望はすごいことになっている。 いいかたちで協力していきたい。
2/18 追記
ご本人の記事にトラバ
http://agnozingdays.blogspot.com/2008/02/blog-post_12.html