結果的にスクラムになってる!なのがいいと思う!

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

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

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

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

 
 

Outline/structure of the Session

最初に全部説明してしまって、その後に、じゃあ実際それってどういうことなのかってのを具体例で説明して、次に、僕はこういうときにはこうやったよとか話をして、最後に、いくつかのチームで共通して見られたこととその対応、みたいな話ができたらいいかな。

Learning Outcome

どこから始めたら良いか分からないって人には、一歩踏み出すための糸口が見えるような、既に一歩踏み出してる人には、自信を持って前に進むことができるような、そんな気持ちが湧いてくるように頑張りたいと思います。

Target Audience

スクラムを導入したいけどどこから始めたら良いか分かんないって方や、まだまだ自分はスクラムをやっているとは到底言えないと思っている方

Requirements

スクラムの基本的な知識はある方が聞きやすいと思います。

schedule Submitted 5 months ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Minoru Yokomichi
    keyboard_arrow_down

    プロダクトチームが必要とするパーソナリティ。そしてそれをデザインするということ。

    Minoru Yokomichi
    Minoru Yokomichi
    schedule 5 months ago
    Sold Out!
    20 mins
    Talk
    Intermediate

    社内ベンチャーで新規プロダクトを開発するためのチームを立ち上げるにあたって、成功の確率をあげるためにどのようにチームを構築したか、またミッション設定とその役割に対する名前付けの重要性などを、実体験を交えながらお話します。

    • 技術的なスキルセットの網羅性
    • プロダクトチームで必要とされるパーソナリティ
    • 各自が持つパーソナリティの把握と補完関係づくり
    • 各メンバーへの境界付け(ミッション)の設定の重要性と、そこへの名前付け
    • そしてそれをオーバーラップさせるということ
  • Liked Yasuo Hosotani
    keyboard_arrow_down

    アジャイル開発におけるドキュメンテーションの考え方

    Yasuo Hosotani
    Yasuo Hosotani
    schedule 5 months ago
    Sold Out!
    45 mins
    Talk
    Beginner

    前は、アジャイル開発宣言において「包括的なドキュメントよりも動くソフトウェアを」と言われていることもあり「アジャイル開発ではドキュメントは書かない」という誤解がありました。現在では、「必要なドキュメンテーションは行う」というのが定説になっていますが、「何が必要なのか?」はコンテキストに依存することもあり明確ではありません。 本セッションでは、自分達にとって必要なドキュメントは何なのか?をそれぞれの現場で考えるときの考え方を説明します。

  • Liked KOGA Masanori
    keyboard_arrow_down

    エンジニアの技術力評価は難しい? - 5年間運用してきた相互評価制度の改善の歴史 -

    KOGA Masanori
    KOGA Masanori
    schedule 5 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

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

    そこで、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が語ります。

     

  • Liked Mitsunori Seki
    keyboard_arrow_down

    Agile Product Management for Product Owner - 27 tips to manage your product and work with scrum teams

    Mitsunori Seki
    Mitsunori Seki
    schedule 5 months ago
    Sold Out!
    20 mins
    Tutorial
    Beginner

    Product owner, in order to determine the services or products that the customer is really necessary, and not the experience or intuition, ability to think logically is required. In, the services and products the customer is really necessary, to think logically, what do I?

    In this session, we will introduce 27 tips to manage your product and work with scrum teams.

     

    ----

    プロダクトオーナーは、顧客が本当に必要としているサービスやプロダクトを見極めるために、経験や勘ではなく、論理的に考える力が求められています。では、顧客が本当に必要としているサービスやプロダクトを、論理的に考えるには、どうすればいいのでしょうか。

    このセッションでは、アジャイルなプロダクトマネジメントにおいて、プロダクトオーナーがスクラムチームと一緒にプロダクトをマネジメントするにあたっての27のtipsをご紹介します。

  • Liked Iwao Harada
    keyboard_arrow_down

    お悩み解決!持ってて損しない道具箱

    Iwao Harada
    Iwao Harada
    schedule 5 months ago
    Sold Out!
    20 mins
    Talk
    Beginner

    「なんでこんなの作る必要だあるんだよ!?」

    いろんな現場で大小の声を聞きます。
    ロールは余り関係なく、プログラマーだけでなくデザイナー、プロダクトオーナー…誰からも。

    インタビューしても、実際にソフトウェアを使う場面を見ても、結局、何なのか?

    そんな時の思考ツールとして「モデリング」をおすすめします。
    「モデリング」を通して分かることは沢山あります。

    • 自分が考えていたけど言語化できていないこと
    • 誰も気付いていない共通点や性質
    • QWAN(Quality Without A Name)
    • etc...

    オブジェクトの広場に掲載されていた「モデリングカフェ」を開催します。
    身近なものをモデルとして表す時の観点や考え方、そんなものを20分で浴びます!

    皆さんに書いてもらうものの発表とかしません。
    予習も可能なのでHP見て予習すると不安なく参加できますので、気軽にどうぞ。

    https://www.ogis-ri.co.jp/otc/hiroba/others/ModelingCafe/

  • Liked Takahiro Kaihara
    keyboard_arrow_down

    『ぼっちはいねぇが!』 Save the Bocchi 2017

    Takahiro Kaihara
    Takahiro Kaihara
    Tatsuya Sato
    Tatsuya Sato
    schedule 5 months ago
    Sold Out!
    20 mins
    Workshop
    Beginner

    『ぼっちはいねぇがァァァァァァ!!!!!!!!!1』 

    Scrum Gatheringでぼっち…ギャザリングなのにギャザれない…それ、とても悲しいこと。

    廊下の片隅でスマホいじってるあんたも本当はギャザりたいんダロ?

    SNSで一方的に顔を知っているあの人とお友達になりたいッ…でも、おっかねぇ!!

     

    そんな優しくもおせっかいな気持ちから、このプロポーザルは生まれました。

    ギャザリング初参加の方、ぼっち属性が強めな方々に参加いただき、ワークショップ/アイスブレイク系のアクティビティをしたいと思っていますが、

    具体的に何をやるかは、今から2カ月かけてゆっくり考えます。

     

    ギャザリングをもっと楽しく!賛同いただける方とポイント余ってる人はVoteよろしくお願いいたします!

     

    * 現在、ぼっち界の大御所に出演交渉中です。大御所にJOINいただけました!ぼっち問題に関心ある方の参加もお待ちしております

    * なまはげ役の方を、2名ほど募集しておりますので、我こそはという方はご連絡いただけましたらと思います。

    * PPAP方面でも1名募集しております。

    * おひるごはん枠でも可

  • Liked Yotaro Takahashi
    keyboard_arrow_down

    コミュニケーションはルール化すれば上手くいく 〜Core Protocolsによるコミュニケーション改善〜

    Yotaro Takahashi
    Yotaro Takahashi
    schedule 5 months ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    コミュニケーションは難しい

    同じプロダクト開発に関わっているとしても、開発チーム内には多かれ少なかれコミュニケーションの問題があります。

    • なぜあんな事言うんだろう??
    • 意味のない指示にうんざり
    • 否定されてばっかりでモチベーションが上がらない
    • 全然メンバーが助けてくれない
    • 一緒に仕事していると、チームメンバーと仕事に求めてるものが違う気がする
    • なんかアイツの言い方が腹が立つ

    感じる問題は様々な形で現れますが、これらの問題の一因には、人と人(あるいはチーム)とのコミュニケーションの難しさがあります。コミュニケーションは難しいんです。話している内容以外に知らなければならないことが多すぎます。

     

    ルール化してコンテクストの共有

    他者とコミュニケーションするときに、相手が話した内容だけでなく、相手のバックグラウンド、コンテクストなど様々な情報が共有されていないと、コミュニケーションロスや、意図しない誤解を生みかねません。

    そこで、「コミュニケーションにルールを作る」ことでコミュニケーションロス、誤解を減らすことができるのでは? という考えから、コミュニケーションに「プロトコル」を持たせる、という工夫があります。

    Core Protocols

    コミュニケーションのルール化のため、チームで自力でルールを策定することも可能ですが、何もないところからルール化するのにはそもそも大量のコミュニケーションが必要になり、現実的ではありません。(ルール化できるくらいコミュニケーションわかってれば苦労はないのだ)

    そのような問題に対応するため、コミュニケーションをルール化したものが公開されているものもあります。私は、GNU-PLで提供されている Core Protocols(コアプロトコル) http://www.mccarthyshow.com/online/ というルールを利用していました。

    このセッション

    本セッションでは、Core Protocolsの内容を紹介した後、私が経験した多国籍チーム(シンガポール人、マレーシア人、日本人の混成チーム)でそれをどのように利用してきたか、それによってどのようなメリットがあったかをご紹介します。その上で、Core Protocolsの有効性、使いどころ、ハマった時の解決法をシェアします。

    Core Protocolsが、あなたのチームのコミュニケーションの問題を改善に役立ちそう!(あるいは役立たなそう!)と判断ができるような体験をシェアできるセッションにしたいと考えています。

  • Tomonari Nakamura ( ikikko )
    Tomonari Nakamura ( ikikko )
    schedule 5 months ago
    Sold Out!
    20 mins
    Talk
    Intermediate

    BacklogというWebサービスを題材に、少数精鋭・個人プレイである程度の成功を収めていたサービスにおいて、組織改正の際にリーダーを任されてからの試行錯誤や取り組みについてお話します。

    従来までは、チームメンバーも4〜6名程度で、数年間ほとんどメンバーの入れ替わりもなく、阿吽の呼吸でサービス開発を進めることができていました。ですが、リーダーを任されるのと時を前後して、メンバーも10名・20名と着々と増えていき、チームの大多数がスキルは十分なものの文化的な背景を共有できていない状況でした。そのような状況下で、従来型の個人プレイでは行き詰まりを感じており、チームで物事に当たってより大きな成果を出すプロセスへの変換を迫られていました。

    本発表では、リーダー改め駆け出しのスクラムマスター・アジャイルコーチが、チームプレイを根付かせるために行ってきた取り組みについて、紹介します。

  • Masanori Kado
    Masanori Kado
    Junya Ishihara
    Junya Ishihara
    schedule 5 months ago
    Sold Out!
    45 mins
    Workshop
    Beginner

    2014年3月、達人デイヴ・トーマスが「アジャイルは死んだ」と宣言してから、プログラミングのできない「認定ほげほげ」や「ふがふがコーチ」は殲滅した。それを遡ること数年前、Scratchの開発者であるミッチェル・レズニック教授がTEDトークで 「子供達にプログラミングを教えよう」と感動的なプレゼンを行い、日本には阿部和広先生の著書『小学生からはじめるわくわくプログラミング』(日経BP社)という良書が登場した。アジャイルが死んだ一方で、プログラミングそのものは裾野を広げているのである。すでにゾンビとなった方々もこれを機に童心に戻り、Scratchでプログラミングを学び直してみてはどうだろうか。本セッションでは、アジャイルプラクティスのひとつ「ペアプログラミング」によって、それを体験する。

  • KazuhideInano
    KazuhideInano
    Atsushi Harada
    Atsushi Harada
    schedule 5 months ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    突然ですが、「アジャイルひよこクラブ」ってコミュニテイ、ご存知ですか?

    「アジャイルひよこクラブ」とは、アジャイル(特にスクラム)の実践による開発現場の改善を志す人(ひよこ)が集い、有識者(にわとり)に悩みを相談しつつ、いつの日かにわとりになることを目指すコミュニティです。

    ひよこは現場へ旅立ち、経験を積んで立派なにわとりになって空に大きく羽ばたいて飛んでいきたいと夢見ています。しかし、 そもそもにわとりは飛べない 理解してくれないor誤解したまま理解してるつもりな上司に振り回されたり孤独を愛し過ぎて心を閉ざしてしまったメンバに夜回り先生したり会社のルールでがんじがらめに拘束されたりと、いろいろな壁に当たってチキンハートになってしまったりおいしいチキンにされそうになったりという厳しい現実が多々あります。

    あぁ、何ということでしょう!それでもひよこは今日も頑張ります。諦めずにこつこつと、あれやこれや奮闘しています。
    RPGでも大切ですよね、レベル上げ。にわとりへの道も スライム倒し 一歩の努力から。

    今回はみなさんに役立つ かもしれない であろうひよこ達の冒険の軌跡を事例として共有したいと思います。
    あるあるな悩みもあればその現場ならではの悩みもあったりと様々です。
    さぁ、外の世界にちょっと触れてみませんか?一狩り行こうぜ(違う)

  • Liked Rie Chonan
    keyboard_arrow_down

    多様な働き方をするチームでスクラムを実践してみた

    Rie Chonan
    Rie Chonan
    schedule 5 months ago
    Sold Out!
    20 mins
    Talk
    Beginner

    出張で不在の多い営業、月末月初が忙しい経営管理部、子どものお迎えを控えつつ差し込み業務に追われる総務
    ...と働き方の異なるメンバーで構成された非開発チームが、
    スクラムを実践した経験を失敗談、工夫点、今後も活かせる良かった事をもとにご紹介します。

  • Liked Tsuyoshi Ushio
    keyboard_arrow_down

    Scrum / DevOps の導入を加速させるグローバルマインドセット

    Tsuyoshi Ushio
    Tsuyoshi Ushio
    Rochelle Kopp
    Rochelle Kopp
    schedule 5 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

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

  • Taku Fujii
    Taku Fujii
    schedule 5 months ago
    Sold Out!
    45 mins
    Talk
    Executive

    エンタープライズアジャイル勉強会の実行委員会で考えた日本におけるエンタープライズアジャイルの3つの可能性をまず説明し、アジャイル開発の実践を試みる際に陥りがちなアンチパターンを説明します。さらに、そのアンチパターンを克服するための実行委員の方々の提言を動機、戦略、戦術という観点で整理して紹介します。

  • Liked Masahiro Taguchi
    keyboard_arrow_down

    ゲーム開発を盛り上げる技術とチームを支え続ける原動力

    Masahiro Taguchi
    Masahiro Taguchi
    schedule 5 months ago
    Sold Out!
    20 mins
    Talk
    Beginner

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

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

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

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

  • Liked Yuichiro Yamamoto
    keyboard_arrow_down

    スクラム道関西 第79回定例会 + アジャイルラジオ公開録音

    45 mins
    Panel
    Beginner

    スクラム道関西は、2012年に設立されたアジャイル・スクラムの実践情報を交換するScrum Alliance公認コミュニティです。

    今回で定例会は通算で79回目を迎えることになりまず。Scrum実践における小さな悩みや新しい気づきなどを持ち寄り、古株・新参によらずスクラムバディとしてざっくばらんに意見交換をしてきました。今回この定例会を、RSGTに集まった全国各地の参加者と一緒に、肩を張らない等身大の意見を交換しあえる場として、いつものユルくて楽しい雰囲気を共有できないかと考えています。

     

    また、スクラム道関西ではストリーミング放送「アジャイルラジオ」を運営しています。スクラム道関西のRSGT参加が叶えば、これを記念して、その場でRSGTの雰囲気を伝えるために公開収録をさせたもらえたら嬉しいです。

    セッション本編で採用されなくても、収録のために会場の片隅にスペースをいただけると有り難いです。

  • 武市 大志
    武市 大志
    schedule 5 months ago
    Sold Out!
    60 mins
    Keynote
    Intermediate

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

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

  • Liked Yasunobu Kawaguchi
    keyboard_arrow_down

    パネル: DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ

    45 mins
    Panel
    Intermediate

    DevOps(継続的デリバリー)によって、プロダクト開発は、より短いピッチで仮説検証することが可能になりました。仮説を効率的に実装につなげ、素早くデリバリーして、部分リリースでメトリクスをとって検証する。リーンスタートアップが、大企業でも積極的に採用されるようになった、ともいえます。こうした時代に、プロダクトマネージャーに求められるスピード感や役割そのものが変化しています。おそらく正解もないので、パネルディスカッションを用意することにしました。ぜひ皆さんで議論しましょう。

     

  • Tsutomu Yasui
    Tsutomu Yasui
    Takeshi Arai
    Takeshi Arai
    schedule 5 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    「『価値を生み出すためのアジャイル』は近視眼的ではないのか?アジャイルとは『環境が変化しやすい中で価値を守り続ける』ためのものではないのか?」

    「『アジャイル』の名のもとに、やたらと新しいことをやりたがるのは、間違いではないか?」

    「『変えること』と『守ること』はどちらが大切なのか?」

    本セッションでは、上記の問いを立てたうえで、現場からの現実解を発表します。発表内容は、複数の会社・組織からそれぞれのエクスペリエンスレポートです。

    発表(予定):

    • 翔泳社
    • ヴァル研究所

    アジャイルやスクラムと言うと「新しいことをする」「新たな価値を創造する」というイメージになりがちです。しかしアジャイルとはそれだけではない、むしろ今あるものを続けていくという向きにゆくためのものだったのではないか。変化しやすい環境の中で、本質的に同じプロダクトを変わらず提供し続けている会社にこそアジリティがあるのではないか。そうした話を、現実のビジネスからのエクスペリエンスレポートとしてお届けします。

     

  • Makoto Takaesu
    Makoto Takaesu
    schedule 5 months ago
    Sold Out!
    45 mins
    Tutorial
    Advanced

    僕が考えている「TG(てーげー)」というアジャイル開発プロセスを紹介します。

    ただ1つ「チャンプルー」という必須のプラクティスがあるだけの、非常に導入しやすいものになってます。

    何度か発表してるのでリンクも参考にしてください。

    まだどこでも使われてないと思われるので、我こそはという方は事例発表第1号になりませんか?

    合わせて、聞いたことありそうで聞いたことのない、ちょっと聞いたことあるかもな、使えそうなプラクティスも紹介します。

    ネタではなくガチですが、まぁてーげーということで、そんな感じで。

  • Liked Makoto Takaesu
    keyboard_arrow_down

    「なんたらアジャイル」その前に 〜 アジャイル開発「守破離」の「守」

    Makoto Takaesu
    Makoto Takaesu
    schedule 5 months ago
    Sold Out!
    20 mins
    Talk
    Beginner

    「アジャイル」や「スクラム」という言葉をよく聞くようになったものの、アジャイルコーチとして、よくわからないままやっている、あるいはやらされている人たちと会う機会が増えてきました。

    では、何を「守」ればアジャイル開発を行っているといえるのでしょうか?

    「アジャイル」とはどういうものであり、どういうものではないか、についてお話したいと思います。