Agile Japan 2009

Agile Japan 2009に行ってきた。

このイベントの存在自体を知らなかったのだが、平鍋氏の記事にまんまと乗せられて、駆け込みで参加に至った次第。

いやぁ、楽しかったですよ。
プログラムについてはAgile Japan 2009のサイトを見ていただきたい。もっとも、2009へのPermalinkになっていないので、2010開催、なんてことになったら消えるかもしれない。大雑把に説明すると、次のような流れだった。

  1. キーノート
  2. パネルディスカッション
  3. LT
  4. 事例紹介
  5. アイスブレイク
  6. ミニセッション(事例紹介&参加型)
  7. クロージングセッション

キーノート

リーンソフトウエア開発〜アジャイル開発を実践する22の方法〜』などで有名なメアリー・ポッペンディーク氏によるキーノート。ソフトウェア開発というか、「生産」に対するアプローチの変遷の歴史についての話。歴史をたどりながら、最終的にはトヨタ生産方式に行き着く。

すげー勉強しているな、この人、というのが印象。ただ、引用をひっかき集めたような内容なので、もしかするとこの人の本を一冊買って読んでおけば事足りたのかもしれない?しかし、読んでいない俺には*1タメになった。

このセッションで自覚したのは、「製造業における知恵、特に日本のそれってバカにならねーな」という、ある意味当たり前のこと。

たぶん俺だけじゃないと思うのだが、製造業におけるノウハウをソフトウェア開発に取り込むことに拒否感があるのである。なぜなら、モノづくりとソフトウェア開発は多くの面で異なるため、そのままもちこんでもうまく回らないことを理解しているからだ。実際、ウォーターフォールモデルは製造業に起源があるが、「最初に設計を固めて、あとは作るだけ」というこのモデルは開発工程の後々になっても変更要求が出やすいソフトウェア開発とマッチせず、そのギャップが現代の開発者をどれだけ苦しめているかわからない。その苦しみが、嘆きが、憤りが、製造業の世界を遠ざける。

しかし、それは単にサルマネしてもダメですよ、というだけの話。いいところを取ればよいし、悪いところは改善すればよい。頭から拒否してもいいことはない。特に日本のモノづくりは世界に誇れるだけの完成度なのだ、倣うべきところは数多いだろう。得た知識をどう扱うかは自分の問題なのだ、自分で考えなければならない。

海外のエンジニアは日本のモノづくり現場のノウハウをこぞって取り入れて、新しいソフトウェア開発プロセスに昇華させる。我々はそれを輸入して賞賛する。いやいや、これは本来国内のエンジニアがやるべきことなのだ。

このへんは、続く黒岩惠氏のセッションで触れられた内容である。脱線しすぎだったが、面白かったからよし。

パネルディスカッション

先のセッションが時間を食いすぎたので、駆け足な内容に。方針変更して、ディスカッションではなく質疑応答になった。

アジャイルとプロトタイピングはどう違うのか、という質問について、「プロトタイプは作ったものを使い捨てるが、アジャイルは育てていく」「フィードバックを取る」「仕様をテストに閉じ込める」などが語られたのだが、個人的には「アジャイルには"アジャイル宣言"がある」という回答になるのではないか、と思ったり。アジャイルを知らない人には通じないか。

あと、平鍋氏が紹介した「許可を取るな、謝罪せよ」という文句が大いに気に入った。所詮、関係者全員の許可を取り付けるなんてほとんど不可能だし、やれるとしても時間を食いすぎる。

LT

出された昼飯を食いながらLT*2を5本。「大阪のおばちゃんは天性のアジャイラーである」との見解には脱帽せざるを得ない。

あ、一緒に行った先輩が「サンドイッチ少なすぎ!」とdisっていましたよ。

事例紹介

「スピードが全てを駆逐する」というハッタリの効いたタイトルで、株式会社良品計画の開発事例を紹介するセッション。

別にアジャイルを意識したわけではないが、単に開発プロセスを工夫したらそれがアジャイル的だった、ということみたいだ。曰く、「2,3週間で完成度70%のシステムをリリース」「使ってもらってフィードバックを受け付ける」「改良する」というサイクルを繰り返しているという。

驚きは、このシステム、シェルスクリプトといくつかの簡易なコマンドのみで実装されており、データはすべてテキストファイルにしているのだという。すぐさまトランザクション制御どうすんだよ、みたいな疑問がでてくるが、それは当然考えていて、なにかしらの対処をしているらしい。「ユニケージ開発手法」と銘打たれている。

システム全体をシェルスクリプトで、というのは我々一般的なプログラマからするとあまりに極端な発想で、すぐさま納得するのは難しい。しかし、機敏なフィードバックを実現するにあたってスクリプティング言語が有効に働くという強力な事例の一つであることは間違いない。

アイスブレイク

アイスブレイクを兼ねた、次のミニセッション用の会場準備。見知らぬ他人と会話をする、というお題が与えられても即座に盛り上がるのは、さすがにみんなアジャイラーなだけはある。ちなみに、「後ろを向いて話している人までいる」と言われてしまったのは、たぶん我々(汗)。お隣が会社の先輩だったから、後ろを向きでもしないと他の人と話せないわけですよ。

ミニセッション(事例紹介&参加型)

6つあるセッションから、興味のあるところを選んで参加する。俺は「体験アジャイル」にいった。ゲームを通じて、アジャイル開発を体感してもらうというセッションである。俺はアジャイル的手法についてはたくさんの本を読んでそれなりに知識を持っているし、部分的ではあるが仕事にも取り入れている。しかし、なにぶんメンター無しで始めているから、自分たちのやっていることがズレていないか確認したかったのだ。

作業の進捗をサイコロで決める、ということで運任せなのだが、逆にそのおかげで見積もりの不確実性は十分に表れていた。最近実際にあったことだが、本当に他愛のない機能を1日で実装するよう計画したところ、開発担当者の開発マシンでのみなぜかアプリケーションをビルドできなくなるという問題が発生し、環境を復旧してなんとか開発を再開するまでに半日かかった、ということがあった。このような、見積もりを外させる要因なんていくらでもあるものだ。

それゆえに、(ゲーム時間で)週に二回実施されるふりかえりで得られるフィードバックの大切さと、対策を早期に遂行して不確実性に対処できるアジャイルの強みも体感できた。タスクが一つ一つ着実に完了していくことによる達成感もある。これらが一体となって作られるアジャイルのリズムは、メリハリもなく淡々とノルマをこなすだけというありがちなスタイルには無い楽しさを感じさせる。

そして、自分たちがやっていることがおおむねズレていないこともわかったので安心。今の路線を突き進んで、よりチームを強化していきたい。

最後にProblemを三回連続で引いてしまったチームの皆さん、その節はどうも。

クロージングセッション

「この場にいるのはみんなアジャイル好きな人たちだから楽しいけど、仕事の現場ではそうじゃないよね?」と、盛り上がる会場に冷や水をぶっかける発言をして、現実に対処するための話が始まる。アジャイル導入には現場や上司の理解が必要であるが、それを得るためには十分な信頼関係がなければならない。しかし相手は、特に上司は難敵だ、視点も価値観も異なる。果たしてどうやって良い関係を築いていくべきだろうか。…そうですね、同じ考えの人間同士で盛り上がっても仕方がない、違う考えの人を巻き込んでいかねばならないのでした。

自分と上司、開発チームとマネージャ、それぞれ違う価値観を持っていてわかり合えないように思えるが、本当のところそれぞれが持っている成功モデルは共通点が多いのだという。誤解があるのは、十分に話していないからではないか?と説く。現実、話してわかる人ばかりではなかろうが、それを確かめる前にあきらめてはいかんよな。幸い、今の上司は理解がある、少なくとも放っておいてくれるので助かっているが。

続けて、チームビルディングの話。「チームというのは単なる集団ではなく、お互いのスキルを出し合い、同じ目標に向かって共同作業していく約束をしている人々の集まりのこと」*3という考えに納得。単なる寄せ集めと団結したチームではその能力に天と地ほどの開きがある。単なる集団では、むしろ互いに足を引っ張り合って悪い影響を及ぼし合う可能性もある。だからこそチームビルディングは難しく、しかし挑戦しがいのある取り組みだと言える。


…と、長々と書きましたが、楽しませていただきましたし、勉強にもなりました。会場にいたみなさん、ありがとうございました。

*1:すみません、買ってはいるがまだ読めてない…

*2:説明するまでもないと思うが、Lightning Talksのこと

*3:うろおぼえだが、内容は外れてないはず