アジャイル開発の中心的教義のひとつに「シンプルさ」の価値がある。ソフトウェア設計やテストのやり方に関しては特にそうだ。Gordon Pask Award受賞者のNaresh Jain氏は2006年以来、世界規模の「オープンスペース」型カンファレンス Simple Design & Testing Conference を開催してきた。このカンファレンスは実践者たちが一同に介し、これが実際にどう見えるのか、何を意味するのかについて、その限界を押し上げるものだ。
次回のカンファレンスは6月26日と27日にインドのムンバイで開かれる予定だ。InfoQはNaresh氏に少し時間をとってもらい、この小規模ながらよく知られたカンファレンスの背景に何があるのか、なぜこれほどまでに彼がこのトピックに情熱を注ぐのか、話を聞いた。
InfoQ: 「Simple Design & Testing」というのは、あなたにとって何を意味するのですか？ なぜみんなが気をつけるべきものなのでしょうか？
Naresh Jain氏:
何年ものあいだ、「シンプルな設計とは何か？」「私の言っているシンプルは、あなたの言っているシンプルと同じものなのか？」「複雑な問題に対してシンプルな解は必ず見つかるのか？」といった質問の答えを探してきました。すべての答えがわかったとは思っていませんが、進歩するのに邪魔にならない設計がシンプルな設計である、と自分なりに結論付けています。もっとシンプルにできるかって？おそらくできるでしょう。それは必要なのかって？邪魔になっていないなら不要でしょう。
テスティングというのは非常に興味深いプラクティスです。間違いなく、設計と同じくらい深くて多様性のあるものです。設計と同様、テスティングにも両極端があります。一方はテストするのに熱狂的な人たちで、コードを一行書くたびにテストしたがります。その正反対にいるのは、テストするのは第三世界の国のやつらにやらせるのが一番だと考えている開発者です。適切なバランスをもった人を見つけるのは非常に困難です。このトピックに関する本物の知識だけでなく、実際の実地訓練が何年も必要になるためです。私に言わせれば、集団として適切なバランスを見つけることが重要です。さもないとチャンスを逃すことになるでしょう。
それでは、個人的にまた他の人にとって、そうしたバランスを見つけることが、SDTカンファレンスの裏にある一番の動機ということですか？ このカンファレンスには他にどんな意図があるのですか？
ええ、これらの答えを見つけるための参加型で限界を押し上げる環境こそ、常に私がSDTConfに求めてきたものです。それに、大きなアジャイルカンファレンスに行っても、プロセス話に圧倒されてしまうでしょう。技術的なディスカッションがあったとしてもどれも非常に基本的なもので、参加者（懐疑的な人たち）に対して、進化的設計、TDD、自動テスト、簡易プロトタイプ、継続的インテグレーション、ペアプログラミング、継続的デプロイメントなどをやる価値を納得させるのに時間が費やされます。
こうしたトピックについて、限界を押し上げるための時間はいつどこで得られるのか？ どうすれば基本を超えられるのか？ プラクティスを試すと、何かにはまってしまうかもしれません。あるいは、何かしら判断をしたけれども、真の実践者からフィードバックを求めたくなるかもしれません。さあ、あなたはどこへ行きますか？
このカンファレンスで私が目標にしているのは、実践者たちが直接顔を合わせて、限界を超えるような学習ができる安全な環境を作ることです。
これを実際に始めるにあたって、何がきっかけになったのですか？ どうして完全な「オープンスペース」型にしたのですか？
最初の Continuous Integration and Testing Conference に参加するまで、私は技術的な話にはオープンスペース型のカンファレンスは似つかわしくないとずっと思い込んでいました。実際に参加してみて、そのカンファレンスで得られた学習クオリティにびっくりしました。当時、私は大規模な企業アプリケーションの仕事をしており、テストしやすいシンプルな設計を思いつくのにとても苦労していました。2006年にやっていたそのプロジェクトには、2つの大きな問題がありました。
そこで私は自分に言いきかせたのです。この2つのトピックに関するカンファレンスを開くべきだ、しかもCITConと同じオープンスペース型で。私はAgile Phillyユーザグループの仲間たちに相談しました。みんなこのアイデアを気に入ってくれました。David Bogus氏が私をWest Chester大学に紹介してくれて、最初のカンファレンスが開かれました。あれから年々成長しています。自分でもちょっとびっくりしています、本当に。
次回のイベントでちょうど5周年を迎えるそうですね、おめでとうございます。SDTカンファレンスをリードし続けていますが、何があなたをそうさせるのですか？ あなたにとって、そこから得られた一番の学習成果は何でしょうか？
毎年のカンファレンスで、私は自分のプログラミングスタイルを変化/改善してくれるものについて学んでいます。
例えば最初のカンファレンスでは、"There is no Spoon"（スプーンなんかない）（Corey Haines氏がリード）に関する非常に興味深いディスカッションがありました。のちにCorey氏とペアを組んで、このアプローチを使ってコードをテストしました。スケッチモードで、どんなオブジェクトが必要になるかわからないとき、これはテスト駆動にとってすばらしいテクニックになります。
翌年、私は「Avatars of TDD」というセッションをやりました。そこでは、いろいろな人たちがいろいろなスタイルでどうやってテスト駆動開発しているのか、ディスカッションしました。私はたくさんの人とペアを組む機会を得て、TDDのスタイル (avatar) を左右するさまざまな特性について、これまでの考えをすっかり変えることができました。これと同じ年に、もうひとつ非常に興味深いディスカッションがありました。自分のテストが自分の設計について教えてくれることです。何年もかけて、私はこのカテゴリにたくさんのパターンを追加していきました。これは、テストが悪いのではなく、もう少し設計する必要があるのを人に説明するのに実に役立ちます（テストのせいにしてはいけません）。
去年は、どれが一番のコードの臭い（一番臭うやつ）か、どれを根絶すればコード全体の設計問題の80%を解決できるのか、という非常に興味深いディスカッションがありました。私の見解は、プリミティブへの執着（Primitive Obsession）（適正レベルの抽象の欠如）が重複と条件の複雑さといった問題の大部分を引き起こすというものでした。
いくつか頭に浮んだことを挙げていきましたが、Wikiを見てもらえば、非常に興味深いトピックがたくさんあるのがわかります（多くがそこにドキュメント化されています）。このようなディスカッションと学習こそが、私にこのカンファレンスを続けさせる理由です。
SDTConfがさらに続いていって、どんなことが起こってほしいと思っていますか？
そうですね、みんなカンファレンスの名前を「STD Conference（性病カンファレンス）」と混同しないことを期待してます。もちろん全然意味が違います。いつもこれで少し笑いがとれるので、決してわるいことではないんですけどね。
ちょうど今回のカンファレンスでは、緊急の設計とテスティングについて、実に真剣なディスカッションがあります。参加型のセッションもいくつかあります。でも、それほど好みではありません。私はディスカッションよりも、もっとデモを望んでいます。プログラミングについては、話すよりもやってみる方がずっとよいからです。話すと安っぽくなってしまいます。
この2年間、私たちは設計問題のあるコードの一部を事前に共有できるようにしました。その問題に詳しい人がコードをリファクタリング/書き直しできるようにすることで、別の人が解決策を紹介するるプラットフォームとしてカンファレンスを利用することができます。
これだけのクオリティのカンファレンスに参加することは、誰にとっても極めて重要なことだと個人的に思っています。したがって、これを世界各地に広げるのは重要なことです。もっとたくさんの人がカンファレンスの発想をもって、自分の地域で開催するようになることを望んでいます（Agile Coach Campで起こっているのと同じように）。
最後に何かコミュニティに伝えたいことはありますか？
世界中のあちこちで、ずっと小さな、参加型の、実践者中心の、ピアツーピア学習や探索にフォーカスしたカンファレンスが開かれてきています。これは非常にエキサイティングなことです。本当の学習は、こうした小さなカンファレンスから始まると信じているためです。実践者は自分のスキルと大局観を高めるために経験に基づいた手法を見つけ、そこから他人とともに学ぶことが必要です。何かを始めるのに他の誰かを待ってはいけません。もしそのトピックに情熱があるなら、もう始める準備はできているのです。
Naresh氏、どうもありがとう。