(English session)

Japanese culture influenced Scrum. Jeff Sutherland and Ken Schwaber presented Scrum in 1995. It was inspired by “The New New Product Development Game“ (1986) by Hirotaka Takeuchi and Ikujiro Nonaka. It also incorporates many elements of Toyota Production System. Then Scrum was reimported to Japan. It has totally changed our way of software development, and given us many insights ranging from teams to organizations. In addition, it makes us rediscover and think of our culture.

I have been working for Rakuten, Inc. for more than 10 years introducing Scrum to many teams. Rakuten adapted English as a primary language, which was unusual as a Japanese company at that time. As a result of that, now we work in a unique environment where many people from diverse cultures work together respecting each other on top of Japanese cultural basis.

In this session, I would like to rethink Scrum from Japanese cultural perspective. I feel there are some insights we can add to Scrum especially about leadership.

椎葉です。新卒として入社したての初々しい2人が、戸惑いながらも頑張っていたのを、僕がチョコを食べながら遠くから見守っていたのは、去年の春のことです。

それから1年もたたないうちに、2人ともがそれぞれのチームの中心になって活躍しはじめ、組織に新しい変化を与え続けてくれています。

びっくりする！すごい！嬉しい！

このセッションは新卒2年目の2人の伊藤さんが

• 悩みながらスクラムやモブプログラミングを導入し
• 先輩たちを巻き込んで挑戦し、学習し、それを何度も繰り返して
• 組織に新しい変化を与えて続けてくれている

そんな勇気の出るお話です。2人のいい笑顔にはいつも癒やされます。

拡大していく組織の中で取り組んでいる、強い思いを持った強いチームづくり

by しゅんごさん

拡大していくサービス・組織の中で任された難しいプロジェクト。

チームの全員がスクラムやモブプロ未経験。

それでも、この難しい状況を乗り越えてユーザーにプロダクトを届けるたんだという強い思いから

試行錯誤をしながらスクラムやモブプロに取り組んできました。

その中で、どんな問題にぶつかって、何を考え、どんな風にそれを乗り越えてきたのかをお話します。

テックリードの卒業を見送ることができるチームづくり

by たいとさん

テックリードしか対応できない。テックリードしか知らない。テックリードがいなくなったら回らない。

僕らは少し前までそういう状況にいました。

このままでは良くない！属人化をなんとかしたい！と考え、モブプログラミングを導入しました。

その結果、最終的には、ほとんど引き継ぎなしでリーダーの卒業を見送ることができました。

モブプログラミングに取り組む中で、若手として何を悩み、何を学び、そこでどんな風に向き合ってきたかをお話します。

ということで、2人がどんなことを考えて、何に取り組み、どんな風に成長してきたのか、その話をご紹介したいと思います。

ぜひ、2人の成長のストーリーといい笑顔を見に来てください。

スクラムチームにテックリード？

「スクラムのロールには定義されていないけど、こういうのは誰がやるのが良いんだろう？」「そもそも、そんな状況ってことは、まだスクラムをやるための準備が整ってないってことなのかな？」って悩むことありませんか？僕はありました。

スクラムに取り組んだ最初のころは「あれー？ここどうしようかな？とりあえず・・・自分でやっとくかな」と思うことが結構ありました。「これでいいのかなぁ？」と不安に思いながらやってましたが、それも5,6年たった今では「あー、うちの組織だと、こういう役割が必要なんだわ。こそこそやらずに、自分の中でテックリードって名前つけて堂々とやっとく方が良さそうだな」って納得してやってます。

スクラムガイドの中には、テックリードというロールは定義されていません。でも僕は、今の組織の中で、このロールがとても大切な役割を果たしているなぁと感じています。大変だけど、やりがいがあって、とても面白いロールです。

こんにちは。椎葉です。楽天株式会社の大阪支社で自社ECサービスのアプリケーションアーキテクトとして仕事をしています。僕が所属している組織では、多くのチームがスクラムを採用しています。その中で、この数年間、僕は改善エンジニアとして「色々なチームに入っていって現場のみんなと一緒に内側から組織の改善をする」という活動をしてきました。その活動の中で学んだのが、テックリードというロールの大切さです。

僕の中のテックリードは、スクラムチームと組織のあいだに立って、技術的な視点に軸足を置きながら、開発やチームや組織を支える。そういう役割です。何かと何かの間におちてしまいそうなものに手をのばして拾い上げたりします：プロダクトオーナーと開発チームのあいだ、開発チームとスクラムマスターのあいだ、スクラムチームと組織のあいだ、そしてマネージャーとスクラムチームのあいだ。など。　

このセッションで伝えたいこと

「僕の組織では、スクラムからは少し外れるかもしれないけど、こういうことをやる必要があって、僕はテックリードとしてこういうことをやってるよ」ということをお伝えしたいと思います。

それによって、これからスクラムに取り組もうとしていたり、既にスクラムを実践しているけど悩んでたりする方々に対して「あぁ、自分も同じようなことで、もやっとしていたけど、そういう風にやってる人もいるんだな」って何かしら参考になるようなセッションにしたいなと思っています。

また、その中で学んだ「テックリードとして考えておくと良いこと」もお伝えします。

今、テックリードとして悩んでいる方や、これからテックリードとしてチームをリードしていく方々に勇気を伝えられるようなセッションにしたいと思います。

サービス運用をまんなかにおいた開発についてお話します。

僕は2010年から楽天の大阪支社でウェブアプリケーションエンジニアとして仕事をしています。僕のいる部署は中規模から小規模のたくさんのサービスを担当していて、1つのチームまたはグループでサービスの開発と運用の両方を担当しています。

サービスの開発と運用の両方を担当しているため、僕らはサービスの運用のことを常に考えながら開発に取り組んでいます。運用のことを考えずに開発をすると全てが自分たちに跳ね返ってくるからです。

このセッションでは、サービスの運用をまんなかに置いて開発をするときに、どのようなことを考えるか、また、どのように他のチームや組織と向き合うか、について自分の経験を元にお話したいと思います。

資料は英語ですが、セッションは日本語です。

こんにちは。椎葉です。僕は2010年から楽天でWebアプリケーションエンジニアとして働いています。より良いものを届けたいという思いからスクラムの勉強を始め、2011年ごろから社内で導入を進めてきました。その影響もあってか、今は部署内のどのチームもスクラムを取り入れた開発を行っています。

スクラムを導入しようとした当初は「あれ？これ具体的にどうやったらいいんだろう？」と悩むことが沢山ありました。タスクってどれくらい細かくすればいいの？とか、見積もりって具体的にどうやったらいいんだろう？とか。

それに加えて難しいなと思ったのは環境です。組織がスクラムに適した形ではなかったり、メンバーもこれからみんなで成長していこうという状況だったり、開発チームの中の誰かがスクラムマスターをやらなきゃいけなかったり。

そんな中で色々と悩みながら一歩ずつ前進しながら取り組んできたのですが、試行錯誤を繰り返した結果「だいたいこうやると良さそうだなー」というやり方が自分の中でできてきたので、それを紹介したいなと思います。

それによって、同じような悩みを持った方が「そういうやり方もあるのか」と感じて一歩踏み出すチカラになれたらいいなと思います。

こんにちは。椎葉です。

僕は楽天でWebアプリケーションエンジニアとして働いています。数年前に「エンジニアとして色んなチームを内側からサポートしたい！」と考えて「改善グループ」というグループを立ち上げました。そして、様々なチームの中に入っていって、一緒にコードを書いたり、テストを書いたりして楽しんでいます。

そんな風にエンジニアとして動くことを中心にしてはいるのですが、実は毎回最初にやるのはチームの開発プロセスを一緒に改善することなんです。というのも、エンジニアとして動くための土台としての開発プロセスが、とても重要だからです。

僕の所属しているECインキュベーション開発部では、どのチームもスクラムで開発をしているのですが、この活動の中でよく聞いたのは「スクラムをやってはいるのだけど、何かうまくいかない」ということです。

このセッションでは「スクラムが何かうまくいかない」と感じているチームに実際にどのような課題があったのか、その原因は何だったのか、そしてそれをどのように改善したのか、を失敗談も交えながらお伝えしたいなと思います。

同じような課題を感じている方が一歩踏み出すきっかけになるといいなと思います。そして、セッションの後にはみなさんと「うちもこういうことがあるよー・あったよー」みたいな話をできたら嬉しいです！

こんにちは。椎葉です。

僕は楽天でWebアプリケーションエンジニアとして働いています。数年前に「エンジニアとして色んなチームを内側からサポートしたい！」と考えて「改善グループ」というグループを立ち上げました。そして、様々なチームの中に入っていって、一緒にコードを書いたり、テストを書いたりして楽しんでいます。

そんな風にエンジニアとして動くことを中心にしてはいるのですが、実は毎回最初にやるのはチームの開発プロセスを一緒に改善することなんです。というのも、エンジニアとして動くための土台としての開発プロセスが、とても重要だからです。

僕の所属しているECインキュベーション開発部では、どのチームもスクラムで開発をしているのですが、この活動の中でよく聞いたのは「スクラムをやってはいるのだけど、何かうまくいかない」ということです。

このセッションでは「スクラムが何かうまくいかない」と感じているチームに実際にどのような課題があったのか、その原因は何だったのか、そしてそれをどのように改善したのか、を失敗談も交えながらお伝えしたいなと思います。

同じような課題を感じている方が一歩踏み出すきっかけになるといいなと思います。そして、セッションの後にはみなさんと「うちもこういうことがあるよー・あったよー」みたいな話をできたら嬉しいです！

この5年間くらい、いくつかのチームをスクラムな開発チームにしてきたんだけど。「スクラムをやろう！」ってしてると、あんまりうまくいかないなぁって感じある。じゃあどうすんの？って「結果的にスクラムになってる！」ってのが良さそうだなって思う。

今、僕のサポートしているチームは全員がペアで仕事をしていて、スプリントの期間は1週間。開発チームと運用チームがあって、そのメンバーが2スプリント毎に入れ替わって知識を共有していってるから、全員がお互いにカバーできる状況になってるの。ペア作業をやるなんて余裕があっていいなって言われたりするんだけど全然そんなことなくて、めちゃめちゃ忙しいチームだからこそ、こういう形にしてしまったんだよね。スクラムをやろうとしてやってたら、できなかっただろうなーって思う。ほんと、結果的にスクラムになったって感じ。

僕の所属してる楽天の大阪支社の開発部は、ほとんど全部のチームがスクラムを取り入れた開発スタイルなんだけど、そのそれぞれが自分たちの担当しているサービスの特性や、ビジネスメンバーの考え方、開発チームの成熟度や、メンバーのスキルなどに合わせて、色んな形のスクラムになってるのも、そういうことなのかなって。

スクラムをやろうとするとどういうところが良くないのか、結果的にスクラムになってるっていうのは具体的にどういうことなのか、で結局どうやって進めていくと良さそうなのかを、僕のこれまでの体験を交えながらお話ししたいなって思います。