Ruby & アジャイル開発セミナーに行ってきたよ！

Ruby & アジャイル開発セミナーに行ってきたよ！

2012/8/6 の "Ruby & アジャイル開発セミナー"に参加してきました！

内容的には"そうだよなー"っていうこととか"なるほどなー"っていうことが多くて、本当に参加してよかったなぁという内容でした。

特に心に残ったのは次の言葉達です！

新しい言語を学ぶときに大切なのは周りにその言語を好きな人がいるか

"とにかく粘り勝ち"

さっさと失敗してもらう

"KPT で Problem ばっかり出てつらいときは Keep と Try だけにしてみる"

しまださんの話 - Ruby で学ぶ、Ruby を話す - Program into your language, Not in it.

島田さんが珍しく緊張している・・・！
結果的に Ruby の話はあんまりしないよー
今日伝えたいことは２つ

言語を選択すること

ソフトウェア開発にとって影響の大きい判断

言語を学び続けること

ソフトウェア開発者にとって重要な活動

自己紹介

えにしテックの取締役だよ
さつき公園のとなりの会社
LOCALの理事もやってるよ
Ruby が大好き
一般社団法人日本Rubyの会の理事

Rubyに関連する人たちを支援したい
いろいろ活動してるよ

Ruby 札幌所属

不定期で勉強会を開催
大通りのジュンク堂にコミュニティの棚があるよ

Sapporo RubyKaigi 2012 やるよー

３日間で延べ 1,000 人くらいくるよ（！！）
Matz とかくるよ
チケット売り切れなんだ、ごめん

（緊急気味の電話・・・！！10分くらい飛んだ・・・）

言語を選択すること

問題は変わっていく
問題の主戦場が写っている
言語を変えないことのリスク

リスクの考慮

言語を変える・変えない、パラダイムを変える・変えない

パラダイムの落とし穴

パラダイム効果：パラダイムを通して問題をみることで難しく見えてしまう
パラダイム麻痺：ものの見方を変えない
問題を解くために導入するのに、居続けることは問題がある

死なないために

異なるパラダイムで問題を解く - 異なる言語で問題を解く

問題にあった道具を発見することがある
問題の新しい見方や解き方が手に入ることがある
（オブジェクト指向だと難しいけど、関数型だと楽、とか）

"変化ヲ抱擁セヨ"

"言語を学ぶこと"

が大事！
いろいろな言語を学ぶことが大切
学ぶこと、学び続けること
"Ruby Training Course" あるよw

Ruby をオススメする理由

様々な表現が可能

ある問題があるときに使いたい方法を使うことができる
"異なるパラダイムで問題を解く"ことができる

アジャイルな開発とも相性がよい

研修でやる予定だよー
"たのしい開発 Ruby スタートアップ"オススメ

Ruby Sapporo があるぜ！！

冗談で言っているのではないぜー
ラルフ・ジョンソン

"新しい言語を学ぶときに周りにその言語を好きな人がいるか？"

言語を選択すること

何が問題かを見極めて打つ大きな１手だから

にしむらさんの話 - 失敗しないアジャイルの導入の仕方

自己紹介

アジャイルコーチ

現場や組織をアジャイルにするお手伝い
アジャイルサムライ監訳者
北斗と南斗で言えば南斗の方（どっち・・・？）

すくらむどう

もっと上手にアジャイル開発をしたい
Scrum Boot Camp

明日から少しでも不安なく実践する

スクラム道場

日々実践することからより深く研究する

ワークショップ

人に伝えることから新しいことを学ぶ
西村さんの趣味

スクラムブートキャンプが本になります！

2013年発売

スクラム道で10がつにイベントやるよ

今日のテーマ - アジャイルの導入の話

導入の成否を決めるのは開発チーム
導入のステップ
考え方
アジャイルの導入が失敗する場合

開発チーム

アジャイル開発

東京で３割程度、海外だと４５％
キャズムを超えた
最近は経営層マネージャーが導入するケースが多い

新しいチャレンジ、失敗のリスク

プロジェクトの成否
避けて通れないテーマ
30%のコスト削減したい、みたいな場合のはなし

初めてのアジャイルプロジェクトはおそらく成功しない

プロジェクトがそもそも難しい
学習コストの過小見積りが多い

何を学べば良いか

スクラムならスクラムガイド
やることはほかにもたくさんあるよ！
全部開発者が行う - 開発チームで行う

集まって協力して
関心、自主性、共通認識が不可欠

最初の時点からチームワークは存在しない、教育目的のプロジェクトも殆ど無い

エンジンが動かない
うまく進まない
"プロジェクトを成功させる唯一の方法はチームを成功させることだ"
開発チームに学んでいってもらう

ステップ

ハイハイ

開発チームを動かす
気をつけていること

全員が関心があり、少しずつ取り組めること

関心があること - みんなが困っていること

話を聞く（うんうん、大事！！）
観察する
いろいろ出てくる

作業状況がよくわからない
作業負荷が一部に集中
作業に着手できない
・・・とか

オススメを選ぶ

プラクティスを提案してみる
ふりかえり、デイリースクラム、カンバン

種を蒔く段階

歩く

計画からリリースまで

必要なことを身に着けて行く

やっていること

研修

全員の理解を揃えることに繋がる
基本的なところで躓かない

お手本
さっさと失敗してもらう

マネージャーさんから怒られる
・・・けど待ってもらう。かすり傷だから
失敗は学びの機会、早く小さい失敗をさせることが大事
反復

高度なチームワーク

計画をみんなで考える
アーキテクチャを考える
最初はない - 創りあげていく
気づいてないことや見逃している失敗を伝え、考えてもらう
大失敗しないように気をつける - 予防するには

毎日ケアする
学習用のバッファを用意する
基本的な部分は今まで通り作る - サブ機能で試す
開発者に要件定義をしてもらってから開発する
反復が大事

現場を学べる場にする

土壌づくり

全力疾走

１回目の実践ではたくさんの課題が出てくる

成果もでる
現場で解決できることはいくつかあるよね
経営層マネージャーにプロジェクトの中だけでは解決できないことに取り組んでもらう

成果が出ていれば選んでもらうことができる

課題がなくなれば現場はもっと良くなる

本来の導入目的に近づく
育てることが大事
時間は必要、これまでのギャップに比例して時間はかかる

協働が大事

そのためには３つのステップが必要

開発チーム
現場
組織

失敗とは、現場をアジャイルにしていくことが途絶えてしまうこと

誰もが望んで失敗しているわけではない
種を撒けば必ず大きく育つ

質問コーナー

話を聞く、観察するのに具体的にどうしているのか

ポジション的に楽、あの手この手が使える
使えない人は仲間を見つけることが大事だよ

アジャイルに取り組んで良かったこと、悪かったこと
アジャイル開発を新しくやってみようっていう時には詳しい人がいたほうがいい？

実際に作業する人が学ぶほうがよい？
一週間に30分くらい集まって話すことからでもいいんじゃないかな
アジャイル札幌あるよ！

学習コストがかかるよ、ってところはなれるとコストが下がるよってことでいいんだよね？

そのとおり
ただし現場の人がそれを意識してトライすることが大事

辛くない振り返りの仕方、より活性化させる振り返りの仕方

一番簡単なのは Try だけ話すこと

自分たちの強みはなんだろう
Keep と Try だけ話す
Problem は毎日話すのがいいよ
振り返りのグランドルールを一度確認するといいよー
おかし、おやつは必須
自分のことを棚に上げる練習
振り返りは３人以上で！
第三者に司会してもらうという方法もあるよー

開発チームが流動的で育ちにくい場合、どう育てていけばいいのだろうか

粘り勝ちが必要
やり続けること
パッション大事
プロジェクトを離れたところあとも話ができると続けることができるかも

悪いことを早めに言えるチーム作りにはどうしたらよいのか

まず、自分から
報告を受けた時に嫌な顔をしない状況を見えるようにする

コメント