5/24（金）に開催された
Agile Japan 2013に参加してきました。このエントリーでは参加できなかった人向けにキーノート1つ目 James Grenningさんの"
Demand Technical Excellence（邦題：アジャイルにおける品質と技術の重要性）"について講演の概要と私の感想を残しておきます。
最初に所感を述べておきます
Agile Japanの帰り道、もやもやとキーノートの内容について考えていました。最初にアジャイル言い始めたおっちゃん達の一人であるJamesさんのメッセージは何だったのか？
今回のJamesさんの講演のメッセージはアジャイルマニフェストで言っていることと同じだと思います。こうじゃないでしょうか？
「未熟な個人をプロセスやら何やらでがんじがらみにするという考え方はやめよう。個人が自立したプロフェッショナルとなり、顧客も自分も満足できるような仕事を自分の力でやろう。そのために必要な学習はやろう。自分が自分の組織を変える旗手になろう。」
安っぽい自己啓発みたいですんません。
がんじがらめにされるのは楽なんですよ、何も考えなくていいから。自分で考えて、自分で行動するのは怖いですよね。失敗するかもしれないし、おかしなこと言っていると他人に笑われたるするかもしれないし。でも、自立していない状況で仕事しても楽しくないし、成果もついてこないですよね。何でもいいから、1つコレだといのを見つけて、実践して、他人と協調して何かをやりとげていく。そういうことを継続したいなと思う次第でした。
そして、Jamesさんの「dogma follower（宗教信者）になるな」という言葉はちょっとドキッとしました、手段が目的化しやすい自分への戒めとして手帳に書いておきました。周りが見えてへん状態にならないよう、自分を客観視したり、人の意見は素直に聞ける謙虚さ、冷静さも持っていたいです。
スピーカーのJames Grenningさんについて
プログラムに書かれているとおり、最初にアジャイルを推進した人の一人であり、現在も世界中の組み込みソフトウェア開発の現場でコーチングやトレーニングを行なっている方です。
James Grenningさんの発表について
大きく分けて3つあったのかなと思います。
- アジャイルマニフェストが書かれた背景
- アジャイルマニフェスト10周年で挙がった課題
- 今、現場が取り組むべきこと（開発者、スクラムマスター、マネジャー）
なぜアジャイルマニフェストが書かれたのか？
アジャイルマニフェストが出される前に主流だったのは「プロセスさえちゃんとしていればいい。モジュールも開発者さえも交換可能な存在だ。」というもの考え方だったそうです。理論的土台となっているのがWatts S. Humphrey氏の「
Managing the Software Process」。CMMIの元ネタだそうです。
JamesさんはWatts S. Humphrey氏自身がそう言ったわけではないけどと断りを入れながら、産業界のメッセージは「プロセスがすべてで、人は取り替え可能」だったといっていました。それに対して、そうじゃないよね、人が一番重要だよねと言ったのがアジャイルマニフェスト著者達で、彼らの考え方がまとめられたのがアジャイルマニフェストのようです。
これは以前公開した
James Grenningさんのインタビューで同じことを語っている事に気づきました。
驚いたことの一つが、彼らの考え方はその当時主流だった考え方と違っていたことです。90年代に一般的だったのは「正しい開発プロセスがあれば、開発者はもっと上手くやるだろう」というものでした。しかし、アジャイルソフトウェア開発宣言を共に検討したメンバーの意見は「スキルのある優れた開発者がいれば、彼ら自身が学習して開発プロセスを決めれば良い」です。
それとは対象的に、多くの会社ではソフトウェア開発の管理や開発プロセスの改善の話をするとき、会社がやって欲しい通りに仕事をさせようとします。IT産業のやっていることは「うちには取り替え可能なプログラミングユニットの開発者がいる。彼らが開発プロセスに従えば、ソフトウェアの問題はなくなるだろう。」というもの。しかし、アジャイルソフトウェア開発宣言で我々が語っているのは人の重要性です。これは驚くべきものでした。
日本の多くの現場ではどうでしょうか？人の協調を重要視することが日本の製造業の強みだったように思えますが、今の現場で同じことができているでしょうか？ただ、アジャイルコミュニティの活動の成果か、今変化の途上にある気がしますね。
アジャイルマニフェスト10周年で挙がった課題
アジャイルマニフェストが書かれたのが2001年。2011年は10周年ということで、アジャイルマニフェストの著者が
10周年を祝うパーティーが開かれたそうです。そこで、今アジャイルコミュニティが抱えている問題について話し合ったのだそうです。
そこで挙がった今後アジャイルコミュニティがやるべきことは以下の2つだそうです。
InfoQを見ると実際には4つありますが、この講演で強調したかったのはこの2つのようです。
- Demand Technical Excellence（卓越した技術を求める）
- Promote Individual Change and Lead Organizational Change（個人の変化を促し、組織の変化を導く）
なぜ卓越した技術を求めるのか？
ここでScrumの父Jeff Sutherlandの言葉を引用しています。「The biggest problem worldwide for Scrum teams is getting shippable code at the end of every sprint. 」多くのスクラムチームで各スプリントの最後にリリース可能なコードを実装することに大きな問題があるようです。
Jamesさんによると、これは未だに1970年代の開発手法を続けている開発者が多くいるからだということです。それはdebug later programming。実装した後にprint文やデバッガのステップ実行でバグつぶしをやる方法です。この開発手法は、「後でバグを見つけて取り除く」手法であり、バグの混入は許容してしまっているわけです。さらに開発規模の増大に伴い、テストの規模が増大すれば、テストできない範囲にバグが混入され、一番最悪なタイミングにこそバグが見つかって、プロジェクトは大炎上してしまうのです。
debug later programmingの問題に対してJamesさんが提案しているのは「ScrumとXPの結婚」。XPで定義されていた進化的設計に必要な技術プラクティスを見つめなおすことです。
XPの技術プラクティスの中でもJamesさんが一番取り組んでいるがTDDです。開発とテストを連続させ、バグを未然に防止する方法ですね。Jamesさんによるとコンピュータサイエンス分野で有名なエドガー・ダイクストラの言葉「デバッグに時間を浪費するのではなく、バグの混入を最初から防ぐ」を実現する取り組みだと話していました。
今、現場が取り組むべきこと（開発者、スクラムマスター、マネジャー）
現場に対してJamesさんが推奨しているのが「2. Promote Individual Change and Lead Organizational Change（個人の変化を促し、組織の変化を導く）」だったと思います。個人が自立したプロフェッショナルとして成長し、自分が起点となって自分の組織を成長させていこうというアドバイスです。Twitter界隈でもここの言葉に同意している人は多くいたように思えます。
開発者がやるべきこと
- ものづくりのエキスパートになれ
- （TDDをやる時間がないって本当？バグを追いかけている時間があるんならテストを書いてデバッグ時間を減らしたらいいんじゃないの？）
- 新しいことを学習し、挑戰しよう
- （今21世紀だよ？未だに70年代のdebug later programmingやってるってどういうこと？良い本がいっぱい出てるからまず読め！）
- 信頼を築き、自分の仕事を包み隠さずチームに見せよう
- （自分の弱みを見せることを恐れるな、他人に失敗を知られることを恐れるな、包み隠さず明らかにしないと人は成長しない）
- 自分の組織のアドバイザーになれ
- （ボスがTDDをやらせてくれないって？じゃ、君がTDDのプロになって上司に教えればいいだろ？）
スクラムマスターがやるべきこと
- 同僚が問題解決者になるよう勇気づけよう
- 宗教信者になるな、君はスクラム”マスター（主人）”であって、スクラム”スレーブ（奴隷）”じゃない
- Scrum研修で教えられていることを絶対視するな、手段を目的化するな
マネジャーがやるべきこと
- 優れたチームを育てよう
- チームのモチベーションを上げようとするな
- 人のモチベーションを上げることは難しい、無理にやろうとしないこと
- 無茶苦茶な納期を指示したり、生産性の低い作業をやらせなければ、本来プログラミングは楽しいはず！
- モチベーションを下げるのをやめよう
- モチベーションを上げるのは難しいのに、下げるのは簡単。余計なことをしないでいい。
最後に小ネタ
何か難しい交渉になるのかと想定していましたが、運営委員の平鍋さんも「いいですね！Jamesさんは前から呼びたかったですよ！」といきなり快諾。まじですか！！実際の来日の交渉はAgile Japan運営委員の皆様が担当され、私は蛸島さんとTDDのワークショップの通訳および補助として準備をやらせていただくことになりました。
ワークショップについて別途エントリを書きますが、なかなか楽しいものでした。Jamesさんを日本に招聘する活動に携われ、日本の開発者が奮い立つようなキーノートを聞けて、大満足でした。コミュニティの可能性を感じる日々でした。関係者の皆様、ありがとうございました。また、よろしくお願いします！
」はGoogle、Apple、Facebookといったシリコンバレーの有名IT企業によるAI（人工知能」の研究成果、および製品開発の動向を一般向けに解説した書籍です。
」は、英語学習者の間では有名な「
」（1988年出版）の続編です。著者マーク・ピーターセン氏は明治大学の教授で、専門分野の講義の他、英語の講義も担当されているようです。この日本人の英語シリーズは、著者が日本人学生の英作文を添削する過程で気づいた日本人が間違いやすい英語のパターンが分かりやすく整理されています。
」が出版され、対談まであると知り、日本人なら聞いておくべきだろ！と思い立って参加に至りました。
」で、同様に全機能を持って自律的に動く組織を作ることを推奨しています（資料p.61）。その組織が生み出した「時間あたりの付加価値」が分かるようなインセンティブ手法を確立し、製品開発に必要な社内の調達も市場取引と同じようにやっているそうです。これにより、市場が変わるとその変化が社内取引にダイレクトに反映されて、各組織が自律的に「時間あたりの付加価値」を最大化するように動き始めるそうです。