「アート・オブ・アジャイルデベロップメントへの道」へ行ってきた

木曜の夜、平鍋健児さん、木下史彦さんと岡島幸男さん（id:HappymanOkajima）のトークセッション「アート・オブ・アジャイルデベロップメントへの道」へ行ってきました。

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

アジャイルを仕事で実践する方々のお話を聞けて、とても面白かった。復習がてら、ノートと記憶から抜粋してまとめてみました。参加しなかった知人にいつか読んでもらうことを想定して書いたら、長くなってしまいましたが。

導入

開始前に角谷信太郎さんが登場

• 『アート・オブ・アジャイルデベロップメント』はすごい
  • 角谷さんが5年くらいアジャイルで試行錯誤してきて学んだことのほとんどが、この本の中にある
  • しかも、ジェームズ・ショアはすごい人
  • すなわち、この本はすごい
• 装丁も素晴らしい
  • ビン、水や空間などの周りの環境と協調して、活き活きと伸びる木
  • 木が伸びる方向は、木自身が知っている
  • 周りと調和し、協調しながら成長する方法は、皆さん自身の中にあります

その後、セッション開始。
まず、お三方同士の他己紹介がありました。次に、翻訳の作業について。そして、だんだんアジャイルの話題へ。

ダイヤルを回し切らない最近のアジャイル傾向

昔は、「（アジャイルをするなら）ダイヤルをいっぱいまで振り切れ！」という空気だった。今はそうではない。

サイエンスの対義語としての「アート」

本のタイトルに使われている「アート」という言葉は、芸術という意味ではない。

• サイエンス
  • 再現できるもの
• アート
  • 人が発見し、学び、作る技。絶妙なバランスで成立する何か。勘所。

会場のアジャイル実践率

会場に対して、「仕事でアジャイルをしている方、手を挙げてください」という振りがありました。手を挙げたのは5名くらいだったでしょうか（もっといたかも）。平鍋さんと木下さん曰く、「こんなにいるのは初めて」。

普段、こういう場で同じ質問をしたときに手が挙がる割合は、日本で5%、アメリカで25%だそうです。

アジャイルでの「組織的な成功」のために意識していること

p.5の図（アジャイルの「組織的な成功」、「個人的な成功」と「技術的な成功」の3つをバランスの取れたベン図にしたもの）を見ながら、岡島さん「これを見て、アジャイルが熟した印象を受けた」。

木下さんと平鍋さんは、組織的な成功を得るために、普段どんなことを意識してアジャイル開発に取り組んでいるか。

メンバーの成長とビジョンを意識（木下さん）

• よくあるプロジェクト成功の捉えられ方（＝納期や予算を守ること）を一歩超える。「かかわったメンバーが成長できたかどうか」
• 4年くらいXPをやってきた中で、営業やビジネス的な部分を意識するようになった。
• アジャイルのプラクティス「ビジョン」と同じく、ゴールをどこに置くかをはっきりさせる。
  • そうすれば、顧客からの細かい要望でブレることがない。
  • たとえば、Webサイト作成の案件で、集客をゴールとして顧客と合意する。すると、たとえば、「全体で目指すのはコレだから、アレを諦めましょう」といったことができる。

顧客と開発者の対話からプロダクトを生むには、アジャイルが適している（平鍋さん）

• プロダクトアウトもマーケットインもよくない。なぜなら、イノベーションがないから。
• 開発者の「こんなの作ってみました」という作るナレッジと、顧客の「いいね！ こうするともっといいんじゃない？」という使うナレッジが合わさり、粘着性のあるナレッジ（sticky knowledge）になる。
• そのためには、文章よりも話すことが有効。対話が必要。だから、いまアジャイルを選んでいる。

セカンドアダプタ・シンドロームの乗り越え方

p.58「セカンドアダプタ・シンドローム」とは、社内で最初のアジャイル開発プロジェクトが成功しても、2つ目のプロジェクトはコケやすいという話です。理由として、2つ目のアジャイルプロジェクトでは、最初のアジャイルチームほど環境的な条件が良くないということが、本では挙げられています。最初のアジャイルチームは、本当にアジャイルをやりたい人がチームに集まりやすい、お試し的な案件を与えられやすいなど、なにかと恵まれている。しかし、2つ目のプロジェクトは、そうではなくなる。

木下さんは、XPを継続して実践している。どうすれば継続して成功させられるのか。木下さんも、セカンドアダプタ・シンドロームを経験されたのか？

2回目は"XPごっこ"になってしまった（木下さん）

• 1回目は、XPを上手く回せた
  • 試行プロジェクトの形で、関連会社のシステムを開発した
  • チームメンバーは、アジャイルをやりたかった人たち4人
• 2回目は、顧客を巻き込めず疲弊した
  • チームメンバーは、1回目と同じメンバー＋α
  • 形から入ろうとして、"XPごっこ"になってしまった

セカンドアダプタ・シンドロームは、人のラインで乗り越える（平鍋さん）

• 「XPだから上手くいった」と考えてやろうとすると、失敗するのではないか。
• 人が体験から得たものを無視してはいけない。次のプロジェクトも成功させるには、経験値を持つ人が必要。
• 成功したアジャイルチームのメンバーを次のチームにも2人入れよう。

木下さんと平鍋さんの最初のアジャイル開発の話をもう少し詳しく

• 木下さん
  • 技術に明るい上司も巻き込んだ
  • プロジェクトに専用ルームが割り当てられた。他人の目を気にせず、好きにできた
  • ケント・ベックのXP本を読みながら、ああでもない、こうでもないと試行錯誤した。メンターはいなかったが、多くの発見があった。

• 平鍋さん
  • 本を読んで「やってみたい」と思い、ある案件の前作業として、2週間から1ヶ月くらい実施した
  • 実施してみて初めて分かることが色々あった。たとえば、ストーリーをタスクに分ける段階で、実はクラスの分析くらいまでやっている。タスクに分ける作業が設計になっている。
  • アジャイルについて上司の理解を得るには、「XPを使うことで、組織が抱えている課題をどう解決できるか」さえ説明できれば大丈夫なハズ。

「アジャイルの凋落」をどう思うか

ジェームズ・ショア氏は、アジャイルの今後について悲観的な記事を書いているが……

名前でなくマインドを（岡島さん）

• 今後、潮目が変わって、アジャイルが流行るのではないかと自分は楽観している。
• アジャイルという名前ではなく、マインドを残していけば、アジャイルは生き残れると思う。

楽観はしないが、やっていく（木下さん）

• 楽観はしない。がんばっていかないと。
• アジャイルを普及させるとかではなく、まず自分が仕事でやっていく。

アジャイルという言葉を捨ててもよいのでは（平鍋さん）

• ピュア・アジャイル（狭い意味でのアジャイル）を日本の産業構造に根付かせるのは難しいかもしれない。
• しかし、アジャイルには、達成感、貢献感、成長感、協働感という人の喜びのキーとなるものがある。
• 活き活きとした仕事を作れるのであれば、アジャイルという言葉を捨ててもよいのではないか。

火が噴いていてもメンバーが活き活きしてるアジャイルチーム

木下さんは、火噴きプロジェクトを担当することもある。普通なら、メンバーがへばってしまうような状況のはずのプロジェクトだ。しかし、（たしかに残業は多いが）チームメンバーが活き活きとしているように見える。それはなぜか？（岡島さん）

アジャイルで開発していると会話が多い（木下さん）

• デスマーチでは、一般的に黙々と作業しがち。だが、アジャイル開発だとペア作業もあり、会話が多い。
• ペアプログラミング以外の作業でも、なにか聞かれたら丁寧に教えることを実践している。
• その結果、楽しそうに働いているように見える。燃えている（プロジェクトではなく、メンバーが）。

• アジャイル開発をしていない人が「うちはプロジェクトがアジャイル向きではないのでムリだ」と言うことがあるが、自分もアジャイル向きのプロジェクトばかりを担当しているわけではない。
• アジャイルの全プラクティスを実践するのではなく、原則を実践している。
• アジャイルは、受託開発でもできる。

チームビルディング、プロジェクトファシリテーションのこと

ここで、平鍋さんから岡島さんに質問。

岡島さんは、ウォーターフォール文化の中で仕事をしてきて、なぜチームビルディングに焦点を当てるようになったのか？ チームビルディングの本を書くに至ったのか？

チームの人間関係の問題を解決する手段としてプラクティスを使う（岡島さん）

• リーダーをするようになって、チームの問題は人間関係にあると気づいた。
• 解決方法を探していて、朝会などのアジャイルプラクティスを見つけた。
• ウォーターフォールならではの利点（顧客と別々に開発をする＝顧客の目を気にせずに開発手法を選べる）を生かして、実施した。
• 顧客に説明せずに、開発中に朝会やふりかえりのプラクティスを取り入れても、害を与えることはない。結果として良いものを作れたらOK。

• 好きなプラクティスは、ふりかえり。
• プロジェクトファシリテーションをする上で重要なのは、運用をどんどん見直すこと。
  • 上から押し付けると、アジャイルはうまくいかない。チームの意見を取り入れて、運用を改良していく。

アジャイルは押し付けややらされ感ではうまくいかないという事例（平鍋さん）

上海でのアジャイル開発で、カタかったチームの雰囲気が途中からがらりと変わり、うまく回るようになった話。

• 最初は、チームでふりかえりをしてもカタい雰囲気で、皆マジメなことしか言わなかった
• あるとき、ふりかえりで、メンバーの1人が「この部屋、空気悪くない？」と発言
• 「だよね！」という皆の同調。次の1週間やること（Try）として、2時間に1回の換気を提案しあったりして、盛り上がった。

アジャイルの課題とは

岡島さんから問題提起。

• アジャイルチームが書いたコードを、レガシー（な開発手法を採用している）チームが引き継ぐときに、引き継いだ側のチームにとって「やりにくい」と感じる部分があるのではないか
  • たとえば、「システム全体に共通部分がほとんどない」など

木下さんと平鍋さんの考察

• アジャイルで開発されたコードは、業務系システムをレガシー手法で開発するチームにとって、馴染み深いコードではないかもしれない。
• コードを引継ぐときに「人」を全然引き継がなかったことも問題だった。
  • チームメンバーを完全に入れ替えて、成功させることは難しい。1人でもいいので、アジャイルチームのメンバーが、レガシーチームに入って説明してあげるとよかった。
  • ただでさえ、他人のコードには、それがどんなに優れていてもケチをつけたくなるもの。アジャイルチームでコードを書いたメンバーのうち、1人でもレガシーチームに引きつづき存在すれば、レガシーチームの他のメンバーが受ける感覚も違っていたかも。

質疑応答

• 質問(1)：「アジャイルの成功体験を持つ人を次のプロジェクトにも2人入れよう」について。なぜ2人？
• 回答(1)：
  • 2人と言ったのは、「最低2人は入れよう」という意味。（平鍋さん）
  • XPはしんどい。文化的なコンフリクトが起こり、周囲を説得する必要に迫られることもある。そんなとき心が折れないように、仲間が必要だ。（平鍋さん）

• 質問(2)：自分は社内でただ1人の開発者だが、アジャイル開発をしたい。どうすればよいか。
• 回答(2)：
  • イテレート、タスクボード、ふりかえりがオススメ。まず、自分のやっている仕事を1人で張り出してみる。周囲の注目が集まるので、「やってみない？」と声をかけて、一緒に張り出す。1週間たったら、「どうすればコレをもっと上手く見せられるだろう？」と、やる。→もうイテレーション！ イテレーション作るのが大事。（平鍋さん）
  • イテレーションを作れたら、朝会もできるようになる。情報共有が大事。（木下さん）
  • アジャイルでは、顧客もチームのメンバーである。開発者が1人でも、チームは1人じゃない。顧客と一緒に振り返りをやろう。（木下さん）

• 質問(3)：アジャイルには、技術系とチームビルディング系のプラクティスがある。技術系のプラクティスは、どれをどのような判断基準で導入すればよいか。
• 回答(3)：
  • やりやすいものから。ペアプログラミングをしながらTDDを実践したり、既存のコードを把握したりするのは、やりやすい。自分のプロジェクトではそうしている。（木下さん）
  • 技術系とチーム系の接合点のプラクティスから、と考えてみたが、実はオブジェクト指向の教育からかも。なぜなら、スクラム、XP、オブジェクト指向、リファクタリングなき進め方では、失敗するため。顧客の言葉で書かれた機能をもとにアジャイル開発をすると、レイヤでなくピースで実装していくことになる。ピース同士の依存関係が、時間がたつと生まれてくる。その結果、かならず後から構造を作り変える必要が生まれる。（平鍋さん）

• 質問(4)：アジャイルで開発したときのお客さんの反応は？
• 回答(4)：
  • 顧客がアジャイルを知っている場合は、説明不要なので、いきなり適用できる。
  • 顧客がアジャイルを知らない場合も、そんなに説明しない。顧客に「アジャイルでやります」と宣言したり説明したりすると構えられるので、あえて言わない。まず一緒にやってみる。プロジェクトの1つ1つの粒を一緒にやっていくうちに、最終的にアジャイルになっている。たとえば、「ふりかえり」という言葉を使わずに、「1、2週間たったから打ち合わせしましょう」といって、やってみる。（木下さん）
  • 開発の契約についても、他の開発方法のときと同じ。

• 質問(5)-1：日本でのアジャイル採用率が低いのはなぜか。
• 回答(5)-1：
  • SIerとサブコントラクタからなる産業構造のため。契約をはさんだチームでは、たとえ共通のゴールがあったとしても、契約を見たとたんに仕事の押し付け合いという綱引きが始まってしまう。（平鍋さん）
• 質問(5)-2:アメリカでのアジャイル採用率が高いのはなぜか。
• 回答(5)-2：
  • （アメリカにもSIerはあるが）ユーザ企業がエンジニアを直接雇用している。自社のために良いものをうまく作ろうと思ったら、アジャイルに行き着く。（平鍋さん）
  • 国家的事業に関する案件は、アジャイルにならないという笑い話。

感想

開始直後、岡島さんが「この3人の誰とも面識のない方、います？」と会場に投げかけました。手を挙げた人（私含む）の数が、参加者全体の4分の1以下でびっくり。もしかして、なにか共通の前知識が必要なのかな？と心配に……でも、終わってみると杞憂でした。

『アート・オブ・アジャイルデベロップメント』の本の中身と同じく、具体的、実用的な話が盛りだくさんでした。「こういうときはどうしたらいいの？」という参加者の質問に対して、即座に「こんなふうにやってみたらどう？」「自分はこうやった」と返してくれるのがすごい。平鍋さんのいう「人に蓄積されていく経験、アート」を垣間見た気分でした。もっともトークセッションなので、アートが言葉として発現したのを聞いただけにすぎませんが。達人によるこれらの開発現場での実践＝アートなんでしょうね。

そういえば、平鍋さんが話してくれた上海での事例が面白かったです。部屋の空気を入れ換えようという話をきっかけに、チームの空気が変わったわけですね。うまい！（と、勝手にツボに入っていました(^^;）

セッション中、社内事例の話がいろいろ出ました*1。プログラマ志望の就職活動中の学生さんが今回のトークセッションを聞いたら、お三方の会社のファンになるんじゃないかな。私は、学生でもないくせになりましたよー。「良いと信じるやり方があるならやってごらん。もちろん成果はだしてね」とチャンスを与えるのって、健全な文化だなぁ。

楽しいトークセッションをありがとうございました。行ってよかったです。

さて、セッション終了後、「アジャイル話をもっとしたくて懇親会に飛び入り参加したら、懇親会＝オブラブの春イベントだった件」に続く（かもしれない）。

*1:Webで再現してよいものか迷ったので、上のまとめではかなり省きました