XP祭り関西2016～アジャイル15周年ふりかえりの感想 #xpjugkansai

「XP祭り関西2016～アジャイル15周年ふりかえり」が無事に終わりました。
約60人もの参加者、木下さんの基調講演、山根さんと土屋さんのアジャイルラジオコンビ、スクラム道関西の4人、藤井さんのDtoD、パネルディスカッションと盛り上がりました。
参加者、講演者、スタッフの方、お疲れ様でした。

以下は、僕個人のラフな感想。

【参考】
XP祭りin関西2016 - XPJUG関西wiki

XP祭り in 関西 2016 ?アジャイル15周年ふりかえり? - 日本XPユーザーグループ関西 | Doorkeeper

XP祭り関西2016～アジャイル15周年ふりかえり(2016/2/27) #xpjugkansai - Togetterまとめ

fkino diary(2016-02-27) "XP祭りin関西2016 に参加しました"

【1】今日の基調講演は、木下さんの「5分で分かるアジャイルムーブメントの歴史 拡大版」。
日本のアジャイル15年の歴史を凝縮した内容で、とても素晴らしいと思います。
僕は、XPJUG関西に10年以上関わってきたので、とても感慨深くて、色んな思いがありすぎて。

5分で分かるアジャイルムーブメントの歴史 拡大版 from Fumihiko Kinoshita

日本のアジャイル本の歴史を辿ると、3回のうねりがある。
1回目はXPブーム、2回目はScrumブーム、そして今3回目。

2000年代前半のXPブームでは、開発者がXPに熱くなっていた。
東京のXP祭りに参加して、あの雰囲気を関西でもやりたいと思って、XPJUG関西で企画したのがXP祭り関西2006。
それから10年も続いている。

2008年頃からのScrumブームでは、プロジェクトリーダーがScrumをチーム運営へ導入して熱くなっていた。
田口さんが、僕はScrumを導入して今まで失敗したことがない、と発言されていたのも思い出す。
未知の領域、新しい技術を取り入れた開発でScrumは大きな威力を発揮する、という趣旨を言いたかったのだろうと推測する。

そんな中、永和システムマネジメントとチェンジビジョンしかXPをやっていないのではないか、という疑惑から、平鍋さんが「アジャイル止める宣言」。
そこからAgileJapanが発足し、マネージャ層、経営層向けにターゲットを絞り込む。
また、IPAも「非ウォーターフォール型開発」という名前でアジャイルの研究会と資料を公開し、最初はIPAでもアジャイルと言えなかったのが、アジャイルという言葉が解禁になった。

そして今、ITがビジネスの中心になっているWebサービスやベンチャー企業では、アジャイル開発が当たり前の環境。
アジャイルでない従来型のSIもあるけれど、ネット上にもプラクティスやアンチパターン、事例が溢れていて、少なくとも知識の上ではもう差別もない。
そんな気がしている。

【2】山根さん＆土屋さんのアジャイルラジオコンビのお話。
山根さんがJavaの開発で使ったツールやフレームワークの変遷の話は、僕もすごく同感して、感情移入してしまって。

僕も山根さんと同じく、ファウラーの「リファクタリング」本から入った。
僕は2002年頃、「リファクタリング」本を夢中で読んでいた。その頃はJavaプログラムを書ける初心者レベルだったから、こんな風に使うんだ、という知的刺激が楽しくて。
Eclipse上で、リファクタリングやデバッグ、しかもリモートデバッグまでできるのも楽しくて。

Antも随分使っていた。
WindowsでもUnixでも、同じビルドスクリプトが動くので、単体テストでもテスト環境でも本番環境でも同じようにビルドスクリプトを流用できる。
Strutsに初めて触れた時も、これだ！と思っていた。
今はもう、レガシーなフレームワークだけれど。

JUnit、DBUnitなどのテスティングフレームワークも書いていて楽しかった。
Javaでリフレクションはこういうふうに使うのか、モックはこういうものなのか、という気付きが楽しかった。

でも、あの山根さんも最近の技術のトレンドに少しずつ遅れてきていると感じている。
だから、コミュニティに顔を出して、新しいトレンドを取り入れようとしている、と。

【3】田口さんのKPTのプラクティスの事例も興味深かった。
普段はプラクティスの話はしないんだけど、と話しながら。

KPTは良くできたフレームワーク。
長所だけでなく、問題も洗い出して、対策まで考えさせる。

でもKPTを毎回やると飽きる時がある。
だから、他の色々なファシリテーションのツールを使う。
良かったこと・悪かったことをアイコンの周囲に付箋で書き出す。
モスバーガーの店前の掲示板を真似て、朝会の前に、いじりキャラの若手に小さなホワイトボードにその日の気分を書かせて、朝会の雰囲気をほぐしたり。

XP祭りin関西2016 明後日からはじめるアジャイル [ Here comes tao of scrum kansai ] from Takahiro Kaihara

【4】パネルディスカッションのテーマは「アジャイルの達人に聞く～ソフトウェア開発の質問コーナー」。
僕がモデレータと言いながら、自分が一番聞きたい内容を質問形式にして、パネラーと議論できればと思っていた。
質問は、典型的なWF型開発しか知らない、というSIの立場であえて書いてみた。
5つの質問を用意していたが、最初の質問1個だけで1時間以上も費やしてしまった笑。

XP祭り関西2016～アジャイル15周年ふりかえり「アジャイルの達人に聞く～ソフトウェア開発の質問コーナー」 #xpjugkansai from akipii Oga

【5-1】「要件定義で注意しているポイント」を質問として投げかけた所、藤井さんから、その問題はアジャイルでは既に解決している。
アジャイルでは要件のように機能詳細は定義せずに、ユーザストーリーでまとめる。
1～3ヶ月おきにリリースすることで、ユーザーストーリーを検証・評価して、顧客に価値あるシステムを提供していく。

でも、要件定義が必要なのは、見積りの元ネタになるから。
見積りが契約内容と見なされてしまう。

【5-2】土屋さんいわく。
見積りは2種類は出すようにしている。オプションは2種類作り、双方にメリット・デメリットがあるように説明すれば、お客さんも納得してくれる。
松竹梅、という3種類の見積りあるよね、と。

【5-3】木下さんいわく。
うちは、インセプションデッキが作れるまで開発を始めない。
ユーザとは準委任契約を結んでいるので、要件定義で固定スコープの一括委託契約はしない、と。
顧客はうちの開発力を信用しくれているし、うちも顧客の信頼を崩さないようにと思って、信頼関係を大事にしている、と。
この点は、委任契約にある善管注意義務の発想と全く同じ。

他に、価値創造契約のように、準委任契約ではなく、システムの開発と運用を一体化した契約スタイルもある。

また、ユーザ側の担当者がアジャイルを受け入れてくれる人か否か、を判断している。
ユーザ企業の担当者が上司にお伺いを立てるような人ではダメで、俺がすべての要件を決める、と言う、プロダクトオーナーの役割を自覚する担当者でないと上手くいかない。

【5-4】田口さんいわく。
うちはゲーム会社なので、受託開発案件はそうない。
ゲームでは、ユーザが楽しいと思うものを作る、というふわっとした要件が多いので、要件定義という発想がゲーム業界自体にあまりない。
やってみないと分からないから。
そういう未知のソフトウェア開発では、Scrumがすごくマッチする。
Scrumを導入して今まで失敗したことがない。

でも、たとえば、ゲームのキャラクターを作るという作業の場合、キャラクターの図面を作る、キャラクターのエフェクトを付ける、などの作業を複数人のデザイナーが担当して作業する場合がある。
その場合は、Scrumではなく、タスクかんばんでワークフローとして作業を流す。
その方が回りやすい、と。

【5-5】参加者からの質問も多くて、その内容もすごく共感できて。

準委任契約と言っても、実際は要件定義は実施済みで、どんなモノを作るのか、という仕様が決まっているから、一括請負契約と変わらない場合がある。
そんな場合でもアジャイル開発はできるのか？と。

パネラーからは、顧客と信頼関係を築いていれば、準委任契約でも、スコープを固定せずとも開発は可能。
ある一定期間で、これだけの予算の範囲で作る、という条件があるので、その範囲内でベストなソフトウェアを作る。
その条件の範囲内で、顧客の要望に基づき、フィーチャを取捨選択して、オプションのように取り扱う、と。

でも、質問者の方は何となく納得できていないような雰囲気を感じた。
そして僕自身も、質問者と同じく違和感を感じていて、質問者とパネラーの間で、準委任契約の意味やその背後にある現実にズレがあるように感じた。

僕が知っている準委任契約は、実費請求の準委任契約であり、作業報告書がなければ開発費用を請求できない。
顧客の依頼に基づいて作業した、という契約。
その契約内容は、事実上、一括請負契約とあまり変わらない。

一方、パネラーの場合、顧客との信頼関係があり、顧客はチームの開発力を信用しているし、チームも顧客の要望がスコープに入るかどうか十分に吟味して回答し、その範囲内できちんと結果を出す。
その差は、要件定義がアバウトであっても、顧客がチームを信頼していて、チームも必ずアウトプットを出す、という信頼関係があるか否か。
その差は大きい。

や16ぁさんはTwitterを使っています: "挙げている例が当てはまりすぎててそのままワイに突き刺さる #xpjugkansai"

kawanotronさんはTwitterを使っています: "でも@akipiiさんの悩みよくわかる。 #xpjugkansai"

【5-7】他に、アジャイル開発ではドキュメントを作らないのか？という参加者からの質問もあった。

木下さんいわく。
ドキュメントはうちもほとんど作っていない。
でも、ユーザ側の担当者が変わると、そんな話は俺は聞いていない、と言い出す人がいて、大変になったこともある、と。

【6】アジャイル開発が当たり前の知識になったとしても、実際の現場でアジャイル開発が使えていなかったり、契約や要件定義でアジャイル開発を生かすノウハウがなかったりする。
今日のような場で、その辺りの本音の議論が少しでもできて、参加者の心に残ってくれたらいいなと思う。