PMTalk自分たちの組織をどうやって改善するのか特にエンジニアは組織の話となると嫌厭しがちです。わかります、自分もそうでした。身近な改善を続けると必ず組織の問題にぶつかります(ました)。昨今話題のDevOpsやMicroserviceの話をとりあげてみても、組織とは切っても切り離せません。そんな時にもちろん今とは違ういい組織を探すことも一つの選択肢です。そんな都合がいい組織は果たしてあるのでしょうか。仮にあったとして自分がそこに都合よく入れるのでしょうか。そんなことを考えた1エンジニアが、組織を変えることを考えて「未来会議」というものをやってみた話をします。PMTalkスクラムに取り組むと、とても解決が難しい問題を掘り当ててしまうことがあります。問題はたくさんあります。そのような体験をしたり発見した方は多いのではないでしょうか?私もスクラムチームを支援する立場として、そのようなつらく難しい問題に直面し悩みました。そんな時にふとしたきっかけで、私はコーチングのプロのコーチに『つらい問題に出会ったときの向き合い方』が存在することを教えてもらいました。それは、ある「対話」のやり方でした。参加される皆さんにも共有したいと思います。開発現場では、チームが協力しあって取りかかることは重要だと思いますが、その場の空気が盛り上がっていないと、チームが協働的に取り組むことが難しくなってきます。近年のゲーム開発では、開発規模がますます巨大化していく上に、市場やお客様のニーズも日々変化してきているため、開発の複雑さも増してきており、そうした中でライバルよりも良いプロダクトをお客様に早く届けることがビジネスとして重要であり、そのために開発プロセスや考え方もそれに合わせて変化させていくことが重要になっています。本セッションでは、ゲーム業界でのソフトウェア開発の特徴をお話した上で、私が開発現場をもっと良くしていくためにどのような取り組みを行ったのか、またどのような想いを持ってチームを支え続けてきたのかをお話したいと思います。PMTalkエンジニアの技術力を評価するのって難しいですよね。評価する側がエンジニアではない場合は特に難しいと思います。GROUPでは2011年7月から技術力評価会というエンジニアの相互評価制度を導入しました。5年やってみて、わりと良い感じだと思っています。この5年間で会社の状況に多くの変化がありました。EC事業、ゲームパブリッシャー事業、ソーシャルゲーム事業、ソーシャルマーケティング事業、キュレーションメディア事業、etcこのセッションでは、多種多様な事業を支えるエンジニアの相互評価制度の改善の歴史について、制度設計から全エンジニアの最終評価までやってきたCTOが語ります。PMTalkアジャイルの文脈において、メトリクスの取得・活用は、もはや一般的なこととなりつつあります。メトリクスには、仮説検証に基づく経験主義的な行動を促し、結果として自律的成長や協働につながるという側面があります。一方でプロダクト開発の現場からは、「メトリクスの取り方がよく分からない」・「どう活用すれば良いのか分からない」といった意見も耳にします。当セッションでは、プロダクト開発の現場の「メトリクス難民」を救うため、メトリクスの学術的裏付け、具体的な取得・活用方法および事例を、Agile2016・SQiP2016の最新の知見を踏まえながらご紹介させていただきます。AMKeynoteアジャイルが早すぎた時代は去り、ビジネス、開発、運用や、プロダクト、サービス、受託などのいくつもの世界が惑星直列がごとく重なり合い、アジャイルは不可欠なものとなりました。このセッションでは、エバンジェリストとしてアジャイルとコミュニティ、開発現場と歩んできた10年間をふりかえりながら、次の10年に繋げていきたいと思います。PMKeynote日経電子版は2015年に日経電子版アプリを全面リニューアルし、その後の継続的な改善リリースによってアクティブユーザー数を1年で2倍に押し上げ、AppStoreのおすすめベストニュースAppにも選ばれました。これらを実現したのはレガシーな開発体制からの脱却、社員がメインエンジニアとしてプログラムを書く内製開発、そして部局の壁を越えて理想を実現するためのチーム力でした。アジャイル開発を進める上で遭遇した課題・解決策、そしてこれからの展望をお話しします。難しいと言われています。解決策は、Scrumが生まれた国、米国の文化、マインドセットを学ぶことです。ための文化インストールメソッドのうち、Scrumの背景に存在する米国の文化をインストールするグローバルマインドセットをご紹介いたします。背景をより深く理解し、Scrumや新しい技術の導入をより効果的、高速に実施できるようになります。ReportあるチームがScrum、XPなどアジャイル手法を用いての開発、またアジャイルな姿勢、ふるまいができるようになってきたとします。その次のステップの1つとしてアジャイルなカルチャーを他のチームや組織に広げていくことがあります。それにより、学び続け、変化に対応できる組織となり、不確実な状況を生き残ることができます。ここに至るにはいくつもの壁や難しさがあります。ギルドワークスの現場コーチでは、様々なクライアントの現場にいる開発チームの改善から始まり、その後、プロダクト、サービスの事業、そして組織の改善まで行っています。このセッションではそのぶつかってきた壁、壁のアプローチ、その失敗談、また乗り越えることができたお話をします。PMTalkBacklogというWebサービスを題材に、少数精鋭・個人プレイである程度の成功を収めていたサービスにおいて、組織改正の際にリーダーを任されてからの試行錯誤や取り組みについてお話します。従来までは、チームメンバーも4〜6名程度で、数年間ほとんどメンバーの入れ替わりもなく、阿吽の呼吸でサービス開発を進めることができていました。リーダーを任されるのと時を前後して、メンバーも10名・20名と着々と増えていき、チームの大多数がスキルは十分なものの文化的な背景を共有できていない状況でした。そのような状況下で、従来型の個人プレイでは行き詰まりを感じており、チームで物事に当たってより大きな成果を出すプロセスへの変換を迫られていました。本発表では、リーダー改め駆け出しのスクラムマスター・アジャイルコーチが、チームプレイを根付かせるために行ってきた取り組みについて、紹介します。Report〜スクラムマスターが求められているのは、ソフトウェアの世界に限ったことじゃないを実践したみた結果を共有します〜自然派オリジナル缶詰の制作、販売を行う会社とお店を立ち上げたばかりの元エンジニアの社長さん。やりたいことが沢山ある中、お店をオープンしました。店舗運営の初期メンバーを3人雇ったけれど、その人達の日々の仕事を考えること(指示出し)で手一杯になって、本当にやりたかったことになかなか手を付けられない日々。ストレスがたまる中、そういえばエンジニア時代にも同じことがあったような。あのときは、スクラムを取り入れることに挑戦したな。すればスクラムを缶詰屋さんに適応することができるのか。手探りで缶詰屋さんにスクラムを適応した、社長さんとスクラムマスターのお話をします。日々そう考えている皆さんと同じく、Gunosyの開発チームでも様々な課題を解決しながら組織をスケールアップし、現在はLeSSの導入実践を試みています。このセッションではフラットで10名規模の開発メンバーから50名規模のクロスファンクショナルなLeSS開発組織へスケールアップを行うときにでてきた課題と、それを乗り越える際に重視したポイントをリアルにお伝えしたいと思います。私達の経験のご紹介と、厳しくも楽しみながらいかに開発をよりよくしていけばよいのか、皆様の開発現場での改善の一助になるようなセッションになれば幸いです。Reportこの5年間くらい、いくつかのチームをスクラムな開発チームにしてきたんだけど。「スクラムをやろう!」ってしてると、あんまりうまくいかないなぁって感じある。すんの?って「結果的にスクラムになってる!」ってのが良さそうだなって思う。今、僕のサポートしているチームは全員がペアで仕事をしていて、スプリントの期間は1週間。開発チームと運用チームがあって、そのメンバーが2スプリント毎に入れ替わって知識を共有していってるから、全員がお互いにカバーできる状況になってるの。ペア作業をやるなんて余裕があっていいなって言われたりするんだけど全然そんなことなくて、めちゃめちゃ忙しいチームだからこそ、こういう形にしてしまったんだよね。スクラムをやろうとしてやってたら、できなかっただろうなーって思う。ほんと、結果的にスクラムになったって感じ。僕の所属してる楽天の大阪支社の開発部は、ほとんど全部のチームがスクラムを取り入れた開発スタイルなんだけど、そのそれぞれが自分たちの担当しているサービスの特性や、ビジネスメンバーの考え方、開発チームの成熟度や、メンバーのスキルなどに合わせて、色んな形のスクラムになってるのも、そういうことなのかなって。スクラムをやろうとするとどういうところが良くないのか、結果的にスクラムになってるっていうのは具体的にどういうことなのか、で結局どうやって進めていくと良さそうなのかを、僕のこれまでの体験を交えながらお話ししたいなって思います。Study頑張ったのに成果として認められないから脱却し、「最短で成果を上げる」ためのノウハウをご紹介します。私は、2011年にスクラムと出会ってから、ほぼ毎期で社内賞または社外賞を14件受賞することができるように成長できました。(補足:スクラム実践前は、ウォーターフォール開発のエンジニアでしたが、社内賞・社外賞からは無縁でした。)最短で成果を上げるためには、「強いスクラムチームを作る」ことが大切だと実感しております。スクラムチームをつくる必要があるのか?、どのようにしたら、強いスクラムチームを作ることができるのか?を成功・失敗事例を交えながらご紹介いたします。現場では、スクラムによるアジャイルな開発を導入していない方にも、明日からすぐ実践できる秘訣をご紹介いたします。オフショア開発でどうやってアジャイルできるのかわからない開発者、マネージャーとして約十年の経験の中で、異なる国の、異なる文化を持ち、スキルも考え方も違う人たちと働いてきた方法をお話しします。オフショアで陥りがちな落とし穴を避け、問題を解決するコツが見つかるかもしれません。国をまたいだスクラムチームの立ち上げ方についてもお話しします。コストを押さえつつ、今のやり方でプロジェクトを成功させる方法を知りたければ、是非聞きに来てください。※追伸:(ベトナム人)日本語で発表します。pitfalls.アジャイルコーチとしてスクラムに関する多くの失敗や間違い、誤解を見てきました。本セッションではよくある落とし穴や問題、間違いと、それをどう避けるかについて解説します。Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。3本柱を強化してきました。私達はいまやスクラムに別れを告げつつあります。Member)はスプリント毎にクジで決定し、スプリントレビューはPO以外が全員個別にデモします。テストやメトリクスも更に洗練され、いまや私達は自分達のタスクを最小6分単位でスケジュール、追跡し、改善に役立てています。このチームが取り組んでいること、そしてどうしてこのようなことをやっているのかをみなさんにご紹介します。