「7人のアジャイルサムライ」に参加してきました。 #devlove #agilesamurai

2012-04-25

■[勉強会]「7人のアジャイルサムライ」に参加してきました。 #devlove #agilesamurai

　昨日は、東京：飯田橋のクラスメソッド株式会社で開催されたDevLove主催勉強会「七人のアジャイルサムライ」に参加してきました。

　その名の通り、7人で「アジャイルサムライについて語り尽くす」のがこの勉強会の主旨。少人数の座談会形式で、各々持ち寄ったテーマについて、フランクに参加者が意見を出し合いました。

　この勉強会、参加者が7名というのが非常にハードルが高くて、「そもそもオレみたいな勉強不足野郎が参加していいんだろうか？」と遠巻きにイベント告知を見ていたのですが、直前で2名辞退し、開催自体が危ぶまれる事態に。こんな面白そうなイベントが中止されるのは勿体ない、だったら力不足でもなんでも参加して開催できるようにしちゃえ！　とばかりに、勢い参加してきた次第です。いやぁ、開催されて本当に良かった。

自己紹介

　残念ながら1名は業務多忙で直前辞退。6名での座談会となりました。

@papanda

　言わずと知れたDevLove船長。上野のアジャイルで有名な受託開発の会社に所属。

@garden_tree

　フリーでアジャイルやリーンスタートアップの指導をされている方。アジャイルにかなり詳しい。

@banana_umai

　大手飲食情報サイトの中の人。次回「アジャイルサムライDevLove道場」の裏方スタッフ。

@shitai246_

　広告系Webサービスの中の人。社内のゴタゴタとまっすぐ向き合おうとする勇敢な苦労人。

@TAKAKING22

　海岸沿いのServicerからの刺客。偉大なマスターセンセイに師事する若きラストサムライ。

@takigawa401

　この会唯一のスーツの人。二次請け受託開発出生、ウォーターフォール代表(笑)。

インセプションデッキをお客さんと作った時の失敗談

― メモ ―

何故「インセプションデッキ」をやるかが提示できない

言葉を変えて、今までの言葉でやる→ビジネス層相手

「これ作ってくれ」という要望がいきなり来る→さかのぼって事業部長まで行かないと真意が聞けない

1回は失敗させる←準備不足であることを洗い出す

POとビジョンを作る→3ヶ月開発→PO「コレジャナイ」

doneの定義が無かった

ビジョンしかなかった

インセプションデッキって、どこまで具体化する？

価値観の共有

明文化の弊害

見えないようにした方が良いものも

インセプションを作る前に「今既にあるもの」に対するインセプションデッキが必要？

　初っ端から難しい課題にトライ。「顧客と一緒にインセプションデッキを作ると『上手くできなかった感』が残るが、そういったことは無いか？」「そもそも『なんでインセプションデッキを作らなくちゃいけないのか？』を上手く提示できない。みんなどうやってインセプションデッキを作ることに合意しているか？」という起点から議論が始まりました。

　これには「ビジネスの人と打合せする時には『インセプションデッキ』という存在を隠してやった、中の言葉も今までに聞き覚えのある言葉に差し替えた。全部終わってから『実はインセプションデッキというものがあって…』と説明したところ、二回目からは最初から『インセプションデッキを作りましょう』と言って始められるようになった」という意見が出ました。これは非常に上手いですねぇ。

　また、「インセプションデッキを作っていると、あれも分からない、これも分からない、と結構あやふやな点が出てきて完成できない」という悩みも。これは逆に「インセプションデッキを作ることで不明点の洗い出しに使う。『あれも分からない、これも分からない』となった時に『じゃあこの項目は確認しなくちゃいけませんね」と確認を促し、再度デッキ作成に臨む、という意見が。この辺はオレも同意見でした。

　オレからは「そもそも既存の『プロジェクト定義書』や『要件定義書』を作る目的で集まってもらい、その『洗い出す項目の一覧』としてインセプションデッキを活用する」という現在案件でやっている方法を紹介しました。納品が必要で、向こうが分かる名目で納品しない限り受け取って貰えない都合、どうしてもそうやらなくちゃいけないんですが、この辺はみなさんServicerで働いていらっしゃったので、割と目新しい意見だったのかもしれません。

人日の倒し方

― メモ ―

人月だと「いつリリース日なの？」と聞かれる

リリース日のコミットが絶対

WBSを引かないようにしたい

プロダクトバックログから引っ張ってくるやり方じゃないの？

1人日分作業したら終わり、にはしたくない、ポイント扱いにしてサボらないようにしたい

むしろポイントだけでどうやって期間を見積もるの？

大きく確保する

○ヶ月でどのくらい

発注時には人月で貰っているものの、作り始めると関係ない

　そもそも「なんで人月を倒さなくちゃいけないのか？」を理解するところから議論が始まりました。よくよく話を聞くと「プロデューサー的な立場の人がWBSで管理したがる。実際にプロジェクトではWBSは使わないのに、そのプロデューサーの為だけにWBSを作成して、リリース日を決めている。実際には追加要件も変更要件もあるし、都度リリース日は変更してる。作って見せた後は一切更新しないWBSなので、作るのをやめたい」とのこと。要するに「人月を倒す＝WBSから離れる方法」だということが判明。ではそのプロデューサーはなんでWBSを欲しがるのか、というのを分析してみたんですが、昔からのやり方でやりたいんじゃないか、管理した気になりたいんじゃないか、などなど憶測の範囲を超えない意見がちらほら。「できればポイントでやりたい」「プロダクトバックログからPullしてくる形じゃないの？」という意見が出たところで自分の中で強烈な違和感が。そもそも「WBSを作らなくてプロジェクトが進行できるのか？」が疑問点に。

　議論はさらに「なんでWBSを作らなくちゃいけないのか？」に発展します。結論としては「仕事を外注に出すときにはやっぱりWBS作って貰って人月ベースで見る。その時に工数に違和感が無いかをチェックする。契約結んで開発が始まっちゃった後は、向こうがどのように開発していようが関係ない。」という意見から「どうも契約を結ぶ際の工数妥当性を見る為にWBSを作り、人月を見る傾向があるからだ」ということに落ち着きました。

　オレ自身はWBSありきでしか考えてなかったので、タスクは全てあらかじめ各人に割り振っていましたし、リリース日は確定しているものでしたし、人月が敵にになるとか倒すべき相手だとかいう発想さえ出てこなかったのが、オレのスタート地点でした。でもアジャイルな開発手法だとタスクは手隙の人間が自分で取りに行くもので、リリース日はおおまかに決めるもの(←この辺はまだ違和感がある)で、ユーザーストーリー作った後のプランニングポーカーで出したポイントで難易度や期間が決まってくる、その辺がなんとなく飲み込めました。う～ん、アジャイル難しい。確かに受託開発で完璧なアジャイルは現状無理かもですね。

なぜアジャイルが主流にならないのか

― メモ ―

契約の問題 →どうやって取る

そもそもウォーターフォールを知らない

大変なのはどんな手法でも変わらない、アジャイルにしたらバリバリ画面が出来るわけじゃない

　最近NTTデータが新人教育でスクラムを導入する、という話もあったように、徐々にアジャイルというキーワードが聞かれるようになってきたけれども、アジャイルがメインになっていかないのは何故か、というのがこの問い。「アジャイルは良いものだからもっと流行ってもいいはず！」という思いはよく分かります。一番最初にみんなの口から共通して出たのが「アジャイルは契約が難しい」でした。

　あと、管理する側から見た時に「アジャイルでやろうがウォーターフォールでやろうが、大変さは変わらない。アジャイルにしたからといって要件詰めなくていいわけじゃないし、画面がバリバリ作れるわけじゃない。作られるものに大差が無いように見えるのに、採用するのに抵抗があるんじゃないか。」という意見もありました。

　個人的に面白かったのは「そもそもウォーターフォールを知らない」という人も。Servicerではウォーターフォールでもアジャイルでもない、独自の開発手法で行っている場合が多いようです。システム開発＝ほぼ10割ウォーターフォールというイメージを持っていただけに、これは驚きでした。

アジャイルな働き方ができないメンバーがいる

― メモ ―

バスに乗せない、降りて貰う

　これは現場の開発メンバーの1人に「アジャイルってぇ～、すっごい仕事頑張ってる人がやってそうじゃないですかぁ～。そんなにガツガツやりたくないしぃ～。だからアジャイルもヤかなぁ～って。」って感じの人がいるらしくて(実際にはこんな言い方はしてなかった、オレの脳内補完イメージ)、その人をどうやってアジャイルチームに巻き込むか、という悩みに対する議論でした。

　これに対して「アジャイルにやりたくない人にはやらせない。バスから降りて貰えばよい。」という結構バッサリな意見が。過去に新人と仕事をした時も、新人は別働部隊というか外注的位置づけというか、ともかくコアなチームメンバーとしては扱わず、タスクのコントロールをリーダー的な立ち位置の人間がやる、それ以外の打合せやなんかは、他のメンバーと同様に一緒に参加して貰う、というようなことを行ったそうです。

　ただ、議題を定義した人は「チームで一体感というか、楽しくワイワイやりたい。」と思っており、その人にもできればチームの輪に入って欲しいようです。

　これ聞いてて思い出したのは、こないだ妹から聞いた話でした。会社の同僚数人とカラオケに行ったんだけど、1人がみんなの輪の中に入らない。他人の歌は聞かないし反応もしないし、それどころかイヤフォン付けてゲームを始める。注意をしても「私の事は気にしないで下さい」と取り付くシマもない。でも自分で歌いたい曲は入れるし、順番が来ればゲームを中断して歌うんだそうです。そして歌い終わるとまたゲームに戻る、と。…妹の会社はアニメ制作を行っているので、とりわけ変なのが多いのかもしれませんが、当人はやりたいようにできて大満足、他の人間だけが嫌な気分を味わったんだそうです。で、妹のとった対策はシンプル、「次からは誘わない」でした。まぁオレもそれしか方法が無いかなぁとは思います。

　その人にも輪に加わって欲しいという気持ちは凄く分かるけど、それより大事なのは「残りのメンバーがその人を大事にすることで気分悪くなったりしないか」だと思うので、バッサリ切るのも止むを得ないのかな、と。

　あとは「プロジェクト方針で決まったことだから、(個人の感情に関係なく)やって」と頭ごなしに言うことですかね。でもこれも上手く行かない気がしますねぇ。

　これについてはプロジェクトのメンバー育成方針次第で答えが変わってくるので、一概には言えないのかもしれません。

順調にアジャイル開発している中での気になること

― メモ ―

XPはできているのにスクラムは出来ない、嫌だ

→役割の明文化に対する拒否反応

アジャイル vs ウォーターフォール

自分は今アジャイルなのか？

アジャイルって、何？

人間には学びがある

→1ヶ月後の事は1ヶ月後に考える

より良い方向に向かう事を約束して貰える

継続的改善活動

ウォーターフォールは怖い

アジャイルも大変

→完璧なウォーターフォールをやってみたい

　面白かったのは「XPはできてるのにスクラムを導入したいというと『嫌だ！』と拒絶反応を示す」という話。よくよく聞くと「スクラムどうこうではなくて、POとかSMとかいった役割がつくのに嫌悪感を示す」そうです。でもそれまでなんらかの役割は担っていたはずで、結局のところ「役名が付くのが嫌だ」ということらしいですね。なんというワガママな話だｗ。

　そこから話題は発展して(どう発展したかはイマイチ覚えてない…)、「そもそも『アジャイル』ってなんだ？」という議論に。メモにもあったように「人間には学びがある」「より良い方向に向かう事を約束して貰える」などの意見が出ました。オレからは、デブサミ2012の角谷さんの言葉を借りて「アジャイルは形容詞だから名詞のウォーターフォールとは相対しない。アジャイル＝現場のTipsと捉えていて、導入可能なエッセンスだけ取り入れるようにしている」と意見を述べさせてもらいました。「ウォーターフォールは怖い、失敗するか一番最後まで分からないのはリスクが高すぎる*1」というのはその通りだと思います。ナイアガラの滝を飛び降りて、落ちどころ悪けりゃ即死、ってのは避けたいですもんね、できればその脇にある階段を一段ずつ降りて、道間違えたら戻ってこれるのが安心ですわ。

　最後に飛び出した「一回くらい完璧なウォーターフォールをやってみたくありませんか？*2」の問いには、みんな笑いながらもうなずいてました。確かに、完璧で途中で設計ミスも要件漏れもなくて、最初から最後までなんのリスクもなくまっすぐ進むウォーターフォール開発があるなら、ぜひ参画したい！ちなみに、本当のウォーターフォール開発というのは「2回繰り返す」んだそうです。全然知らんかった。

顧客の巻き込み

― メモ ―

POに完全に顧客になりきって貰うことができなかった

顧客から全てヒアリングした上で、顧客を切り離して作る

→チームを守りたい、楽しく開発したい

業務部門と開発部門が切り離される

同じ社内でユーザーとベンダーが出来てしまっている

企画の人と隣の席で働く、物理的に近い距離で働く

→どうやって近くで働くか

週一ミーティング

朝礼

顧客に来てもらう、逆常駐

こっちから近づく

タバコ部屋

登場人物を間違えた

顧客＝PO

　これはみんな苦労しているみたいでした。

　そもそも顧客と話が気軽にできる環境を作りづらい場合には、「POに相当する人から予め要望を全て聞き出して、自分がその人の代わりとなってプロジェクトを回す」という方法を取っている方がいました。オレもこの方法を選択していますが、その人は「プロジェクトのメンバーを守りたい、チームで楽しく仕事をしたい」という思いからで、オレの場合だと「POが忙し過ぎて話を常時聞ける状態に無い為やむを得ず」、というものです。

　同じ会社内であれば「可能な範囲で席替えをする」「週一でミーティングを持つ」「顧客に一定期間こちらの会社に常駐して貰う」などなど、顧客となる人物と物理的に近くにいれる工夫をしているという意見も。

　反対に、「同じ社内なのに何故かそういう要件にかかわる打合せに呼ばれない」「向こうも『来てよ』といい、こっちも『行くよ』と言っているのにちっとも打合せに呼ばれない、勝手に知らないところで話し合って決めてしまい、決定事項だけが開発サイドに一方的に通知される」と、意志疎通の場が持てず苦労されている方も。この辺はなんなんでしょうね、そういう謎の社風が存在するんでしょうか？

アジャイルは好きか

― メモ ―

好き

むしろウォーターフォールが嫌い

　この問いに一番ウダウダ悩んだのがオレでしたねぇｗ。面白かったのは「むしろウォーターフォールが嫌いです」という意見。そんな毛嫌いせんでもｗ。

総評

　勢いだけで参加した座談会でしたが、非常に実りの多い会になりました。参加してよかったし、開催されてよかったｗ。

　個人的に興味深かったのは、会社間での文化の違いでした。Servicerの会社だとどんな風に開発を進めているのか、受託開発しか経験したことが無い身としては色々と勉強させてもらいました。

　あとは、自分のアジャイルに対する理解度がなんとなく計れたのも良かったです。オレはアジャイルを現場改善のTipsとして受け止めているので、今の現場でどうしようもない部分…WBSだったりチーム編成だったりといったところは、バッサリ切り捨てて覚えている傾向があったようです。プロジェクトバックログの話なんかは、確かに読んだような気もするけど、全然頭に入ってなかったもんなぁ。アジャイル十全でやれる機会があった時に、メンバーに間違った知識を教えてしまう危険があったので、見直すきっかけになったのは不幸中の幸いでした。

　一番感じたのは「勉強してるだけじゃなくて、なんかしらの形で実践してみないと駄目だ」という事。今回は全員が実践度合いの多少は違えど、自分で今出来るアジャイルへの取り組みが行えていただけに、面白い話し合いになったんじゃないかと思っています。次回開かれたらぜひまた参加したいですね。それまでにもうちょっと自分の「アジャイル度」を高めておきたいと思います。