Scrum Alliance Regional Gathering Tokyo 2013 2日目の基調講演の裏で行われたセッション Scrum the Next Generation に参加してきました。メモを共有します。
目次
- 前座 なんでここに来たの？ 吉羽龍太郎氏
- いつまで開発のやり方ばっかり語ってるの？ 吉羽龍太郎氏
- スクラムはフレームワークか？ 原田騎郎氏
- ON MY WAY TO THE TIMELESS WAY OF PROGRAMMING 角谷信太郎氏
- スクラムを壊すな エマーソン・ミルズ氏
- アジャイルサムライは当たり前になるか？ 西村直人氏
- 感想
前座 なんでここに来たの？ 吉羽龍太郎氏
京王線と銀座線が遅れていたため、前座で15分くらい @ryuzee さんによる会場を巻き込んだセッションがありました。テーマは「会場間違えてない？なんでここに来たの？この講演に期待することは何？」でした。自分のところにもマイクが回ってきました。
はて、私はなぜここに来たのだろう。アジャイルの現場やカンファレンスで活躍され、アジャイルを学ぶ人は一度は耳にしているであろう、５名の講演者。彼らは基調講演の裏で何をするのか、確かめたくてこちらに参加しました。
おそらく、あの会場にいた人たちの考えはみんな同じだったのではないでしょうか。それに応えるように、実行委員長 @miholovesq さんの熱い思いも聞くことができました。これから始まる講演の期待が高まる前座でした。
いつまで開発のやり方ばっかり語ってるの？ 吉羽龍太郎氏
いつまで開発のやり方ばっかり語ってるの？ #sgt2013 | Ryuzee.com
アジャイルの目指すもの
- アジャイル開発ではツールや開発のやり方に目が行きがちだが、開発のやり方はそんなに重要じゃない。他にもっと大事なことがある
- ビジネスの目的はお金をかせぐこと。開発の方法論ばかり語ってもお金につながらない
- ビジネス価値をいかに早く実現するか、がアジャイルの目的
- ビジネス活動は競争にさらされているので、変化が早い。何が当たるかなんて、やってみないと分からないことが多い
- できるものは早く作る。できないなら早く諦める
- 失敗は小さく早期から。失敗から学ぶ
- 歩みが遅い会社はゆっくり死んでいく
アジャイルが失敗する理由
- スクラムが上手くいくかどうかは、組織の文化による所が大きい
- アジャイルでやろうとすると、会社の文化の問題にぶつかる
- 組織の問題は自分たちでなんとかするしかない
- スクラムを適用したら問題は見つかるかもしれないが、スクラムで組織の問題が解決するわけではない。今のやり方がうまくいかないからといってアジャイルをやっても問題が解決するわけではない
- アジャイルの標準化も意味がない。コンテキストが違えばやり方も違う
- 衆愚的意思決定（○○さんが決めたからそれで決まり）はクソへの第一歩
- アジャイルコーチを雇っても、スクラムはうまくいかない。コーチは基本的に押し付けをしない。コーチの使い方は自由。
- アジャイルコーチが同じ現場に長くいるのはよくない。コーチをできるだけ早くクビにするべき。コーチは喜んでそれを受け入れる
スクラムはフレームワークか？ 原田騎郎氏
フレームワークとは
- フレームワークとは枠組みのこと
- フレームワークとアプリケーションは分けることができる
- 全体の寿命を延ばすためにインターフェースが切られる
- ソフトウェアはすごい勢いで変化し、フレームワークとアプリケーションのどちらの寿命が長いか分からなくなってきた
- アプリケーションの中は依存性だらけになっていることが多い
- ソフトウェアでは依存解決のためDependency Injectionという考え方が生まれた
- 組織もアプリケーションと同じく、依存地獄になっていることが多い
スクラムはフレームワークか？
- 教科書にはフレームワークと書かれているが、そう言い切っていいだろうか？（あくまで問題提起であり、スクラムの教えを否定するつもりはない）
- スクラムは組織を継続的に成長させる仕掛けでありたいと考えている
- 成長し続けるほうが長く生きられる
- 成長させるためには外から評価を貰う必要がある
- 長く生きるためには新陳代謝が必要
- 死なない細胞は人間では癌と呼ばれ、自らを滅ぼす
会社組織はよいソフトウェアを作れるか？
- お金を目的にした会社組織から生まれたよいソフトウェアもたくさんある。しかし、よいソフトウェアはコミュニティから生まれることが多い
- 会社組織よりコミュニティの方が平均寿命が長い
- コミュニティには組織の長生きの秘訣がありそう
ON MY WAY TO THE TIMELESS WAY OF PROGRAMMING 角谷信太郎氏
自分が本当に良いと思っていることを相手に伝える
- 自分が良いと思っていることを他の人にどう伝えるか、いろんな所で試してみてほしい
- 良いと思うことの強さが、コミュニティの強さにつながっていく
- 誰もが反対することでも、自分はここが良いと説明できれば、正解が見えてくるかもしれない
- スクラムはフレームワーク。フレームワークは共通する悩み事を考えなくてよくしてくれるもの
- フレームワークを使ったアプリケーションをややこしくしているのは開発者
- スクラムも同じで、ややこしくしているのは中の人たち
- 一人ひとりがどうやって上手くやるかを考えて、つなげていくのが大事
ギャザリングしよう
- ギャザリングとは集まること
- 勉強会などで偉い人と話すのは最初は怖い。参加者の人とも何を話していいかわからない。角谷さんもはじめはそうだった
- このような場所で登壇している人は、少し先を歩いていて、いろんなトラブルにぶつかっている。それをシェアしに来ている
- 一番よいのは、自分が作ったものを興味がありそうな人に見てもらうこと
- そのようなものがない場合は、本を持参してサインをねだるとよい。話のきっかけができる。１回ねだっただけではなかなか覚えてもらえないので、別の勉強会で何度もサインをねだろう。
- ここはスクラムを学ぶ人が集まる場所。目的も境遇も似ているから仲良くなれる。みんなで学び合おう
スクラムを壊すな エマーソン・ミルズ氏
スクラムを壊すな。理解しないで改造するな
- スクラムは管理責任を分離している
- POの管理責任：何をつくるか
- チームの管理責任：どうやって、どのくらい、いつまでに
- スクラムの問題は、技術的な問題がほとんどない。人の問題がほとんど
- 社風、その組織のやりかたに依存する
- スクラムは10年経っても変わっていない。素晴らしいか、腐っているかのどちらか
- スクラムを変える前に、チームで正しいやりかたを検証して考えろ！
スクラムの改造ワースト５
１．管理者は必要だから、プロジェクト管理者を配置する
- プロジェクト管理者は、計画表を整理していいように見せる作業に追われることがほとんど
- 管理者を置いたらスクラムはどう壊れる？
- チームが責任を負わなくなり、チームが進捗管理をしなくなる
２．この会社は分散チームを使わざるを得ない
- スクラムはどこが壊れる？
- チームが壊れる
- お互いの状況把握ができない
- 時差があると起きていられない
- ふりかえりができないので、適用・検証のループが回らない
３．専門性を最大限にするため、単能専門チームを作る
- 設計チーム、フロントエンドチーム、バックエンドチーム、テストチーム
- 各チームがどんなに高性能でもウォーターフォール化する
- 設計している間、テストチームは何をするの
- ウォーターフォールはつまらない
- スクラムは楽しい
- スクラムをやりはじめたきっかけは楽しいから
４．ふりかえりをやめる
- スクラムはどこが壊れる？
- スクラムの適用と検証のループが壊れる
- デイリースクラムでは、昨日やったこと、今日やること、ジャマしているものを話し合う
- デイリースクラムの目的は、チームで作るための意思疎通
５．大事な案件だから日報と○○会議が必要
- 包括的なドキュメントより動くソフトウェア
- 進捗管理をするのはチーム
- 無理をしてよい品質のコードを書けるか？よい発想のできる時間はどのくらいか？
- チームが自分たちを管理しなくなった瞬間、スクラムではなくなる
オープンソースは楽しい
- オープンソースは楽しい
- 分散開発なのになぜかうまくいっている
- モチベーションなど、何か秘密がある
- お金のために開発するといいものは作れない
- オープンソースは、自分が皆に提供したいから作っている
アジャイルサムライは当たり前になるか？ 西村直人氏
アジャイルサムライは当たり前になるか？
- 当たり前とは？
- 自分たちがやっている、隣でもやっている、よその会社でもやっている
- 当たり前にするには
- 現場に導入されること、成果を出すこと、互いに学び合って上達すること
アジャイルサムライを当たり前にするには
- 現場に導入するのは難しいか？一人でもやりはじめればいい
- 毎週価値のある成果を届ければいい。成果が出ると、上司に話を聞いてもらえる、続けさせれもらえる
- 簡単に言うな。では何がそんなに怖い？怖ければ学び続けて上達するしかない
アジャイルサムライを読んだその後、どうするか
- やってみる、考える、悩む、次を試す。これらを「学ぶ」という
- アジャイル開発とは、学ぶ仕組み。知識を自分のものにする
- 最初から上手くできた人にはあったことがない。時間が必要。西村さんたちも６人で５年かかっている
もし、このやりかたを気に入っているのであれば
- 成果にこだわり、成果を実感し、周りの人に喜ばれる、失敗したらくやし涙を流せるやりかた
- 一人でできないなら、みんなで学び合いたい
- 上達しようという意識を高く
- アジャイルは教えたくなるもの
- 一緒にアジャイルを当たり前にしよう
感想
クソの定義ってなんだろう
「クソプロダクトを良い方法論で作ってもやっぱりクソはクソ」@ryuzee さんがクソクソおっしゃってましたが、クソの定義ってなんだろうとセッションを聞きながら考えていました。セッションの中でも名言していなかったはず。終わった後も仲間とどう思うか話しました。
- お金にならないプロダクトはクソか？いやそれは言い過ぎ
- 最初からクソなプロダクトなんてあるわけがない。ビジネス価値があるから発注がある
- 「衆愚的意思決定はクソへの第一歩」といっていたように、プロダクトがまずい方向に向かったときに、それを止められない組織がプロダクトをクソにしていく
- クソなのは我々？
- 我々がクソなまま良い方法論で作ろうとしてもいいものはできない（@haradakiro さんの講演で紹介のあったコンウェイの法則）
- 思い当たる節は多々
一度「クソの定義」について考えてみると新しい発見があるかもしれません。
ミルズさんのプレゼンは分かりやすかった
- 個人的には一番よかった、@emersonmills さんのプレゼン
- スクラムのプロセスを壊したら、何が壊れるか、図解と共に説明されていてすごく分かりやすかったです
- スクラムがかなり壊れている自分のチームはどこが壊れているか、もう一度考えようと思いました
- プレゼン資料、早く上がらないかなあ
持ち帰ったもの
- アジャイルは学ぶ仕組み。組織を長生きさせる仕組み
- みんなで学び合い、良いと思ったことを伝えたい
- アジャイルの問題は組織の問題がほとんどであることを知る。組織の問題の解決方法は自分たちで考えるしかない
- 楽しいことはモチベーションにつながる。講演者の皆様は全員楽しそうで、エネルギーに満ちあふれていました
私のチームのアジャイルがうまくいかない理由は、まだまだ顧客との距離が遠いことが原因のひとつではないかと思いました。どうやって顧客との距離を縮めていくか、課題が見えてきました。難しいですが、アジャイルな開発を自分が良いと思っているなら、他人のせいにせず、もう少し顧客側に踏み込むべきなのかと思いました。アジャイル開発への気持ちは折れかけていましたが、もう少し踏ん張れそうです。参加してよかった。