はじめましてKAKKAです

SNS大手企業でサーバーサイドエンジニア¹⁾このときはPerl書いてました、Androidエンジニア、ゲームエンジニア(coronaSDK)、スクラムマスターをやって、ベンチャーに飛び立っていったかとおもいきや、誰にも知られること無くリクルートマーケティングパートナーズで働き出してAndroidエンジニア、スクラムマスター、サーバーサイドエンジニア²⁾今はRuby on Railsをしております。

そして非常に投稿が遅れましたが、私も先月Agile Singapore 2014に参加してきましたので、それを踏まえて記事を書かせていただきます。
全体の雰囲気などはAgile Singapore 2014 に参加してきました！ – Agile Singapore 2014 参加レポート #1を御覧ください。

The power of an Agile mindset

このセッションは会議の一番最初のセッションであり、Linda Risingさんの発表でした。
LindaさんはAgile界ではかなりの有名人ですね。そしてこのタイトルの発表もいろんなところで行われているようです。

Agileの成功の多くはプラシーボ効果がもたらすものであり、地頭の良さがどうであれ学び、成長することで何事もよく出来るというお話がありました。

下記のとある実験のお話も非常に興味深かったです。

学生をFixedグループ、Effortグループに分けました。
Fixedグループは子供の時に「あなたは頭が良い」など人物に対して褒めたり、しかられたりした。
Effortグループは子供の時にとった行動や努力に対して褒められたり怒られたりした。

全員に下記の選択をしてもらいました。

1. more difficult test
2. another easy test

90%のEffortグループの学生は1を選びました。80%のFixedグループの学生は2を選びました。

とてもむずかしい試験を2つのグループに行わせました。
Effortグループの学生はとても楽しんでたっぷり働きました。
Fixedグループの学生はいとも簡単に落胆しました。

そして、下記のどちらかを選択して回答してもらいました。

1. 誰が一番頑張ったか、良かったか
2. 誰が一番足を引っ張ったか

Effortグループは1を選びました。Fixedグループは2を選びました。

また簡単なテストを受けてもらいました。
Effortグループはスコアが上がりました。

他の学生を励まし、スコアを伸ばすためにはどうしたらいいかアドバイスをしてもらいました。

Effortグループはたくさんのアドバイスをと励ましをしました。Fixedグループはアドバイスをせず、40%が自分のスコアに嘘をつきました。

これはアジャイルのマインドセットを持っていると、楽しんで仕事ができるようになる、能力が向上する、協調性が上がるということを示しています。

「Be Agile」とよく耳にしますが、その理由がよくわかるかと思います。Do Agileではなく、Be Agile。
そしてBe AgileなしではDo Scrumも良くなりません。
ただ単にスクラムをやっているからと言って、「我々はアジャイルやってますよ」というのは危険かもしれません（そもそもAgileはやるものではなく、なるもの、目指すべき状態ですし）。
ところでアジャイルのマインドセットってなんでしょう？？
おそらくアジャイルマニフェストに定義されている価値・原則のことですね。
Agileのマインドセットを持ちたくありませんか？

LG電子のアジャイル導入のお話

Wisang Eomさんの発表
特大ウォーターフォール企業にアジャイル導入してますが非常に大変ですというお話です。
この方、歩きながらプログラミングしているらしいです。メディアにも結構取り上げられているとか。

よくあるウォーターフォールのフローで開発が行われていました。
上司は急げというしプランナーは上からの指示だというしUXは今よりアツいデザインができたというしエンジニアは私を殺してくれという。
Agile導入の障壁として、

• working in the trenches
• waterfall assumption
• HR policies
• system and tools
• legacy code

などがあります。³⁾あえて訳していないのですがなんとなく伝わったらいいなと思います。

これらを解決していくわけですが、技術面とかは特にButSyndromeをやめましょうというお話が印象的です。

• ScrumBut
  しっかり理解して全てのルールを守りましょう。
• UnitTestBut
  カバレッジだけ意識しても中身ないとダメ。テストコードもリファクタリングしよう。
• RefactoringBut
  あなた方はできてるつもりでも、我々にとってはできてないよ？みたいなことを避ける。
• CodeReviewBut
  形だけコードレビューしても意味が無い。
• CIBut

あと、エンジニアをモチベートはかなり重要。エンジニアは最先端技術が好きだ！ということもおっしゃってました。
はい、確かに好きです。

Interpreting the unwritten rules

Shane Hastieさんの発表。
明確に定義されていないルールの解釈の話です。

我々は皆、世界を様々なフィルターを通して見ています。

• 文化のフィルタ
• 自分フィルタ
  playful, powerful, peaceful, precise
• 価値観フィルタ
  何が正しいのか、間違っているのか、自分の経験にひもづける
• 感情フィルタ
  耳や目からのインプットから口や表情へのアウトプットまで見えない
• 今フィルタ
  おなかへった、疲れた、興奮している、幸せ
• 防御フィルタ
  防御的なリアクション

皆が皆、違うフィルターを通して見ているので、これを元にルールを作るのは大変ですね。
守るのも破るのもストレスがたまりますし。
ルールにすべきか、ガイドにすべきか、判断しましょう。

ガイドにするためには・・・
mustをcanにする
alwaysをsometimesにする
whenを具体的に絞る（十分に時間があるとき、とか）

他にもあります！

ひとまず3つ紹介させていただきました。
他にも興味深い話はありましたが、一旦ここまでで区切らせていただきます。
訳が間違っているとか内容違うよーといった話があれば申し訳ありませんがご指摘お願い致します。