| « 2006年10月12日 | 2006年10月14日の投稿 |
2006年10月15日 » |
開発者にアジャイルを強制するのは、危険信号だ（Imposing Agile Is A Very Red Flag）とマーチンファウラーが書いた。
http://martinfowler.com/bliki/AgileImposition.html
要約すると、
アジャイルを管理者が押し付けてはならない、それは、 「プロセスとツールよりも、個人と対話に価値を置く 」という価値にも反するし、その背後にある原則である、 「動機付けされた人たちを中心にプロジェクトを構成する。彼らに環境と支援を与え、彼らが仕事を成し遂げることを信じる」、そして、「最高のアーキテクチャ、要求、そして設計は、自己組織化されたチームから創発する」 にも反する。
というのだ。
チームは自発的にウォーターフォール型の方法を選ぶことだってできる。その場合、アジャイルではなくなるだろが、アジャイルはもともと万能ではないのだ。私は、強制的にアジャイルを押し付けられたチームよりも、自分自身でウォーターフォールを選らんだチームがよいと思う。
うんうん、そうだそうだ。
ところがこの意見に、Kent Beck/Cynthia Andres が反論（ではないが）して、MLでちょっとした議論になっている。
http://tech.groups.yahoo.com/group/extremeprogramming/message/123271
Kentは、
管理者が「アジャイルをやろう」と言い出したっていいじゃないか。「個人と対話」というアジャイルの価値は、チームが管理者やCEOともよい関係を構築すべきことを示唆している。管理者からアジャイルを言い出してもいい。そこから対話が始まるはずだ。ソーシャルチェンジは、企業のどこからだって起こるはずだ。
というのだ。これも正しく、「どこから始まるか」は問題ではなく、その「対話の過程」が重要なんだ、かならずしも「ボトムアップで」やらないとうまく行かない、というものでもないはずだ。
ぼくも、アジャイルやプロジェクトファシリテーション、見える化をあちこちで話たりコンサルティングしているが、「やらされ感」をどうやってなくすか、が一つのテーマとなっている。ぼくは、いつでも、
- 最初に導入の目的をはっきりさせること。（上位目的レベルで「にぎる」こと。同意できなければ、さらに同意できる上位目的方向に登る。）
- チームの問題認識プロセスから参加型で始めること。
- その過程で、アジャイルやプロジェクトファシリテーションの手法を１つの解決策（オプション）と考えること。
を導入の肝としている。これによって、押し付けではなく、「対話」が最初に起こるように、また、納得感、の中で進められるように注意をしているつもりだ。
さて、現実うまく行っているかどうか、はフィードバックによるしかない。
常に「衝突」と「対話」が起こるのが現場だ。衝突を恐れては前に進めない。しかし、上位目的で合意していれば、安心して対話に持ち込めるのではないか。You vs. Me でなく、Problem vs. Us、「問題対私たちの構図」どうやってするかだ。意見がぶつかったら、「そもそも、こういう目的だよね」ということ、その目的がWin-Winである(Win-Loseでない)ことをお互いで確認し、再度衝突しよう。何か「私たち」にとっての解が見つかるはずだ。
| « 2006年10月12日 | 2006年10月14日の投稿 |
2006年10月15日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命