MinsTalkIntermediateアジャイルの文脈において、メトリクスの取得・活用は、もはや一般的なこととなりつつあります。メトリクスには、仮説検証に基づく経験主義的な行動を促し、結果として自律的成長や協働につながるという側面があります。一方でプロダクト開発の現場からは、「メトリクスの取り方がよく分からない」・「どう活用すれば良いのか分からない」といった意見も耳にします。当セッションでは、プロダクト開発の現場の「メトリクス難民」を救うため、メトリクスの学術的裏付け、具体的な取得・活用方法および事例を、Agile2016・SQiP2016の最新の知見を踏まえながらご紹介させていただきます。ReportIntermediate〜スクラムマスターが求められているのは、ソフトウェアの世界に限ったことじゃないを実践したみた結果を共有します〜自然派オリジナル缶詰の制作、販売を行う会社とお店を立ち上げたばかりの元エンジニアの社長さん。やりたいことが沢山ある中、お店をオープンしました。店舗運営の初期メンバーを3人雇ったけれど、その人達の日々の仕事を考えること(指示出し)で手一杯になって、本当にやりたかったことになかなか手を付けられない日々。ストレスがたまる中、そういえばエンジニア時代にも同じことがあったような。あのときは、スクラムを取り入れることに挑戦したな。すればスクラムを缶詰屋さんに適応することができるのか。手探りで缶詰屋さんにスクラムを適応した、社長さんとスクラムマスターのお話をします。ReportIntermediateこの5年間くらい、いくつかのチームをスクラムな開発チームにしてきたんだけど。「スクラムをやろう!」ってしてると、あんまりうまくいかないなぁって感じある。すんの?って「結果的にスクラムになってる!」ってのが良さそうだなって思う。今、僕のサポートしているチームは全員がペアで仕事をしていて、スプリントの期間は1週間。開発チームと運用チームがあって、そのメンバーが2スプリント毎に入れ替わって知識を共有していってるから、全員がお互いにカバーできる状況になってるの。ペア作業をやるなんて余裕があっていいなって言われたりするんだけど全然そんなことなくて、めちゃめちゃ忙しいチームだからこそ、こういう形にしてしまったんだよね。スクラムをやろうとしてやってたら、できなかっただろうなーって思う。ほんと、結果的にスクラムになったって感じ。僕の所属してる楽天の大阪支社の開発部は、ほとんど全部のチームがスクラムを取り入れた開発スタイルなんだけど、そのそれぞれが自分たちの担当しているサービスの特性や、ビジネスメンバーの考え方、開発チームの成熟度や、メンバーのスキルなどに合わせて、色んな形のスクラムになってるのも、そういうことなのかなって。スクラムをやろうとするとどういうところが良くないのか、結果的にスクラムになってるっていうのは具体的にどういうことなのか、で結局どうやって進めていくと良さそうなのかを、僕のこれまでの体験を交えながらお話ししたいなって思います。Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。3本柱を強化してきました。私達はいまやスクラムに別れを告げつつあります。Member)はスプリント毎にクジで決定し、スプリントレビューはPO以外が全員個別にデモします。テストやメトリクスも更に洗練され、いまや私達は自分達のタスクを最小6分単位でスケジュール、追跡し、改善に役立てています。このチームが取り組んでいること、そしてどうしてこのようなことをやっているのかをみなさんにご紹介します。オフショア開発でどうやってアジャイルできるのかわからない開発者、マネージャーとして約十年の経験の中で、異なる国の、異なる文化を持ち、スキルも考え方も違う人たちと働いてきた方法をお話しします。オフショアで陥りがちな落とし穴を避け、問題を解決するコツが見つかるかもしれません。国をまたいだスクラムチームの立ち上げ方についてもお話しします。コストを押さえつつ、今のやり方でプロジェクトを成功させる方法を知りたければ、是非聞きに来てください。※追伸:(ベトナム人)日本語で発表します。MinsTalkIntermediateRSGT2015では日本側の立ち位置でチャレンジしたアジャイルオフショア開発導入事例についてお話しさせて頂きました。RSGT2016ではフィリピンに滞在し、現地の多国籍チームの中に入って実践したアジャイル開発導入事例についてお話しさせて頂きました。現地でチャレンジしたからこそ得られたこれらの経験をお伝えできればと思います。日本側、ベトナム側それぞれの立ち位置で3年以上取り組んできたアジャイルオフショア開発の目指すべき方向性についてもお話しする予定です。ReportBeginnerコミュニケーションは難しい同じプロダクト開発に関わっているとしても、開発チーム内には多かれ少なかれコミュニケーションの問題があります。あんな事言うんだろう??意味のない指示にうんざり否定されてばっかりでモチベーションが上がらない全然メンバーが助けてくれない一緒に仕事していると、チームメンバーと仕事に求めてるものが違う気がするなんかアイツの言い方が腹が立つ感じる問題は様々な形で現れますが、これらの問題の一因には、人と人(あるいはチーム)とのコミュニケーションの難しさがあります。コミュニケーションは難しいんです。話している内容以外に知らなければならないことが多すぎます。他者とコミュニケーションするときに、相手が話した内容だけでなく、相手のバックグラウンド、コンテクストなど様々な情報が共有されていないと、コミュニケーションロスや、意図しない誤解を生みかねません。いう考えから、コミュニケーションに「プロトコル」を持たせる、という工夫があります。Protocolsコミュニケーションのルール化のため、チームで自力でルールを策定することも可能ですが、何もないところからルール化するのにはそもそも大量のコミュニケーションが必要になり、現実的ではありません。(ルール化できるくらいコミュニケーションわかってれば苦労はないのだ)そのような問題に対応するため、コミュニケーションをルール化したものが公開されているものもあります。いうルールを利用していました。Protocolsの内容を紹介した後、私が経験した多国籍チーム(シンガポール人、マレーシア人、日本人の混成チーム)でそれをどのように利用してきたか、それによってどのようなメリットがあったかをご紹介します。Protocolsの有効性、使いどころ、ハマった時の解決法をシェアします。Protocolsが、あなたのチームのコミュニケーションの問題を改善に役立ちそう!(あるいは役立たなそう!)と判断ができるような体験をシェアできるセッションにしたいと考えています。ReportIntermediate分社して早数年、依然レガシーを極めるリクルートジョブズ。メンバー、初めての言語、初めてのチーム開発。はじまったリモートワーク。人と、組織の思惑が絡み合う中、いかにしてこのチームはリリースまでこぎつけたのか。下した決断は!?混迷の半年間が、各メンバーの口から語られる。MinsTalkBeginner今回、卒業制作を始めて受け持つにあたり、スクラムを導入しました。大学の卒業研究やゼミ活動は1週間単位で成果を図る場合がほとんどで、1週間スプリントのスクラムは適応しやすいと思います。就活もあり、教科書的通りにはスクラムを導入しにくかったりもします。今回は、実際に導入した過程を踏まえ、ゼミにおけるスクラム導入の一助ができればと思います。ConfEngine。