アジャイルが早すぎた時代は去り、ビジネス、開発、運用や、プロダクト、サービス、受託などのいくつもの世界が惑星直列がごとく重なり合い、アジャイルは不可欠なものとなりました。このセッションでは、エバンジェリストとしてアジャイルとコミュニティ、開発現場と歩んできた10年間をふりかえりながら、次の10年に繋げていきたいと思います。

日経電子版は2015年に日経電子版アプリを全面リニューアルし、その後の継続的な改善リリースによってアクティブユーザー数を1年で2倍に押し上げ、AppStoreのおすすめベストニュースAppにも選ばれました。

これらを実現したのはレガシーな開発体制からの脱却、社員がメインエンジニアとしてプログラムを書く内製開発、そして部局の壁を越えて理想を実現するためのチーム力でした。アジャイル開発を進める上で遭遇した課題・解決策、そしてこれからの展望をお話しします。

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

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

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

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

Kaizen is a Japanese word that means continuous improvements.

However, people usually find that make one improvement is easy but having improvements continuously is not that easy and rarely could keep them continue.

In this session, we present Kaizen patterns where teams can use to help themselves to achieve continuous improvements.

日本へのScrum / DevOps の導入を米国と同じような深度、スピードで実施するのは 大変難しいと言われています。解決策は、Scrumが生まれた国、米国の文化、マインドセットを学ぶことです。本セッションはマルチカルチャーの専門家のRochelle Kopp さんと共に研究している Agile / DevOps のための文化インストールメソッドのうち、Scrumの背景に存在する米国の文化をインストールするグローバルマインドセットをご紹介いたします。これによって、Scrum の背景をより深く理解し、Scrumや新しい技術の導入をより効果的、高速に実施できるようになります。是非ご参加ください！

In this workshop you will learn how to energize people with a simple card game called “Moving Motivators”, developed by Jurgen Appelo, the founder of Management 3.0.
Management 3.0 is a movement of innovation and leadership with management as a group responsibility. Its goal is to help you grow and transform organizations into becoming great places to work.

The Moving Motivators Game is not only a tool for learning about each others intrinsic motivation, it is also an effective communication exercise and it is always great fun for all participants.

エンジニアの技術力を評価するのって難しいですよね。 評価する側がエンジニアではない場合は特に難しいと思います。

そこで、VOYAGE GROUPでは2011年7月から技術力評価会というエンジニアの相互評価制度を導入しました。 5年やってみて、わりと良い感じだと思っています。

この5年間で会社の状況に多くの変化がありました。

• エンジニアの人数が約2.5倍になった
  • 40人強 -> 100人弱
• 会社が上場した
  • 2014年 マザーズ上場、2015年 東証一部に市場変更
• 長期に運営しているメディアが増えた
  • ECナビ 12年、リサーチパネル 10年、PeX 9年、kotobank 8年
• アドプラットフォーム事業を始め、日本最大級の規模になった
  • fluct、Zucks Ad Network、Zucks Affiliate
• 多くの新規事業に挑戦した
  • アドプラットフォーム事業、採用支援事業、EC事業、ゲームパブリッシャー事業、ソーシャルゲーム事業、ソーシャルマーケティング事業、キュレーションメディア事業、etc

このセッションでは、多種多様な事業を支えるエンジニアの相互評価制度の改善の歴史について、制度設計から全エンジニアの最終評価までやってきたCTOが語ります。

Testing isn't mentioned directly in any Agile method but it's super important to support the built-in quality. Then how to get it done in the right way? This talk delivers one of the common approach with the case study, following Agile testing manifesto. 

This talk comes from the problem, methodology to solution, applied in a complicated system for years.

あるチームがScrum、XPなどアジャイル手法を用いての開発、またアジャイルな姿勢、ふるまいができるようになってきたとします。
その次のステップの1つとしてアジャイルなカルチャーを他のチームや組織に広げていくことがあります。
それにより、学び続け、変化に対応できる組織となり、不確実な状況を生き残ることができます。

しかしここに至るにはいくつもの壁や難しさがあります。
ギルドワークスの現場コーチでは、様々なクライアントの現場にいる開発チームの改善から始まり、その後、プロダクト、サービスの事業、そして組織の改善まで行っています。

このセッションではそのぶつかってきた壁、壁のアプローチ、その失敗談、また乗り越えることができたお話をします。

ScrumをScrum Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。私達は2015年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透明性、検査、適応の3本柱を強化してきました。

私達はいまやスクラムに別れを告げつつあります。スプリントは1日以下で、ロール(PO, SM, Member)はスプリント毎にクジで決定し、スプリントレビューはPO以外が全員個別にデモします。テストやメトリクスも更に洗練され、いまや私達は自分達のタスクを最小6分単位でスケジュール、追跡し、改善に役立てています。

このチームが取り組んでいること、そしてどうしてこのようなことをやっているのかをみなさんにご紹介します。

As an agile coach, I've been finding and watching lots of failure or mistake or misunderstanding related to Scrum. This session will introduce common pitfalls that many team encounter and will provide the way how to avoid those pitfalls.

アジャイルコーチとしてスクラムに関する多くの失敗や間違い、誤解を見てきました。本セッションではよくある落とし穴や問題、間違いと、それをどう避けるかについて解説します。

〜スクラムマスターが求められているのは、ソフトウェアの世界に限ったことじゃないを実践したみた結果を共有します〜

自然派オリジナル缶詰の制作、販売を行う会社とお店を立ち上げたばかりの元エンジニアの社長さん。

やりたいことが沢山ある中、お店をオープンしました。
まずは店舗運営の初期メンバーを３人雇ったけれど、その人達の日々の仕事を考えること（指示出し）で手一杯になって、本当にやりたかったことになかなか手を付けられない日々。

ストレスがたまる中、そういえばエンジニア時代にも同じことがあったような。

あのときは、スクラムを取り入れることに挑戦したな。

ただ、どうすればスクラムを缶詰屋さんに適応することができるのか。

手探りで缶詰屋さんにスクラムを適応した、社長さんとスクラムマスターのお話をします。

Continuous Integration is crucial in modern software development. Therefore, a lot of teams involve Mr. Jenkins and hope for a better quality software. But do they know that they are killing Mr. Jenkins? My talk will answer this question and introduce 3 levels of good practices to maintain a healthy, strong and long living Mr. Jenkins.

スクラムに取り組むと、とても解決が難しい問題を掘り当ててしまうことがあります。
 
ロジカルには解決できないような問題　---　例えば、

マネジメント層に不信感をもっていたり

何かが原因で孤立してしまった人、

原因を誰のせいにもできない問題でつまづいてしまった人…

組織で働いていると、矛盾、葛藤、理不尽な問題はたくさんあります。
 
そのような体験をしたり発見した方は多いのではないでしょうか？
 
私もスクラムチームを支援する立場として、そのようなつらく難しい問題に直面し悩みました。
 
そんな時にふとしたきっかけで、私はコーチングのプロのコーチに

『つらい問題に出会ったときの向き合い方』が存在することを教えてもらいました。

それは、ある「対話」のやり方でした。
 
そこで得た知識と経験を、Regional Scrum Gathering Tokyo 2017 に参加される皆さんにも共有したいと思います。

自分たちの組織をどうやって改善するのか

特にエンジニアは組織の話となると嫌厭しがちです。
わかります、自分もそうでした。

でも、身近な改善を続けると必ず組織の問題にぶつかります（ました）。
昨今話題のDevOpsやMicroserviceの話をとりあげてみても、組織とは切っても切り離せません。

そんな時にもちろん今とは違ういい組織を探すことも一つの選択肢です。
しかし、そんな都合がいい組織は果たしてあるのでしょうか。
仮にあったとして自分がそこに都合よく入れるのでしょうか。

そんなことを考えた1エンジニアが、組織を変えることを考えて「未来会議」というものをやってみた話をします。

自分たちのどうやって組織と向き合えばいいのか、どういう組織を目指すべきなのか一緒に考えませんか？

頑張ったのに成果として認められないから脱却し、「最短で成果を上げる」ためのノウハウをご紹介します。
私は、2011年にスクラムと出会ってから、ほぼ毎期で社内賞または社外賞を14件受賞することができるように成長できました。
（補足：スクラム実践前は、ウォーターフォール開発のエンジニアでしたが、社内賞・社外賞からは無縁でした。。）
最短で成果を上げるためには、「強いスクラムチームを作る」ことが大切だと実感しております。

なぜ、スクラムチームをつくる必要があるのか？、どのようにしたら、強いスクラムチームを作ることができるのか？を成功・失敗事例を交えながらご紹介いたします。
また、現場では、スクラムによるアジャイルな開発を導入していない方にも、明日からすぐ実践できる秘訣をご紹介いたします。

「最高の開発チームをビルドしたい、開発現場をよりよくしたい！」

日々そう考えている皆さんと同じく、Gunosyの開発チームでも様々な課題を解決しながら組織をスケールアップし、現在はLeSSの導入実践を試みています。このセッションではフラットで10名規模の開発メンバーから50名規模のクロスファンクショナルなLeSS開発組織へスケールアップを行うときにでてきた課題と、それを乗り越える際に重視したポイントをリアルにお伝えしたいと思います。

私達の経験のご紹介と、厳しくも楽しみながらいかに開発をよりよくしていけばよいのか、皆様の開発現場での改善の一助になるようなセッションになれば幸いです。

みなさんの開発現場は盛り上がっていますか？ 開発現場では、チームが協力しあって取りかかることは重要だと思いますが、その場の空気が盛り上がっていないと、チームが協働的に取り組むことが難しくなってきます。

また近年のゲーム開発では、開発規模がますます巨大化していく上に、市場やお客様のニーズも日々変化してきているため、開発の複雑さも増してきており、そうした中でライバルよりも良いプロダクトをお客様に早く届けることがビジネスとして重要であり、そのために開発プロセスや考え方もそれに合わせて変化させていくことが重要になっています。

本セッションでは、ゲーム業界でのソフトウェア開発の特徴をお話した上で、私が開発現場をもっと良くしていくためにどのような取り組みを行ったのか、またどのような想いを持ってチームを支え続けてきたのかをお話したいと思います。

関西人なので面白おかしく話すことを保証します！