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

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

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

Outline/structure of the Session

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

Learning Outcome

  • 成功するプロダクトチームの作り方が学べるよう、尽力いたします。

Target Audience

プロダクトをチームで開発することに喜びを感じている人 / 感じたい人

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked 武市 大志
    keyboard_arrow_down

    武市 大志 - 日経電子版 穴のあいたバケツ開発

    60 Mins
    Keynote
    Intermediate

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

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

  • Liked KOGA Masanori
    keyboard_arrow_down

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

    KOGA Masanori
    KOGA Masanori
    CTO
    VOYAGE GROUP, Inc.
    schedule 1 year 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 Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling / Tetsuro Oniki - How to Energize People - Agile Leadership

    45 Mins
    Workshop
    Intermediate

    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.

  • Liked Mitsuyuki Shiiba
    keyboard_arrow_down

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

    20 Mins
    Experience Report
    Intermediate

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

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

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

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

  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - アジャイルカルチャーが 組織に根付くまでの挑戦

    45 Mins
    Experience Report
    Intermediate

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

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

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

  • Liked Daisuke Watanabe
    keyboard_arrow_down

    Daisuke Watanabe - スケールアップする組織におけるLeSS実践と継続的改善手法

    20 Mins
    Talk
    Beginner

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

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

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

  • Liked Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling - Scale an Organization the Agile Way | 会社組織のスケールアップ

    45 Mins
    Workshop
    Intermediate

    In this workshop you will learn how to grow business in an agile way, with a simple card game called „Meddlers“, developed by Jurgen Appelo, the founder of Management 3.0.
    Management 3.0 is a pioneering approach to help creative organizations survive and thrive in the twenty-first century.

    The exercise allows players to visualize and discuss organizational structure, in a way that matches the concept of value networks.

  • Liked Kenji Morita
    keyboard_arrow_down

    Kenji Morita - LeSSにおけるチーム連携のパターン

    Kenji Morita
    Kenji Morita
    Senior Engineer
    Canon Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Advanced

    最近は日本でも、Scrumの実践者は増えてきており、1チームでの開発で成功をおさめ、2チーム、3チームと規模を拡大している事例も増えてきていると思います。Scrumのスケール手法としては、SAFeがメジャーですが、フレームワークとして非常に大きく、数チームのためのフレームワークとしては、取り組みにくいのが現実です。

    そこで、昨年は「Nexus と LeSS 概要と説明」と題して、それらの概要や共通点を紹介しました。どちらの手法も、元になっているスクラムと同じで、必要最低限の必須のフレームワークのみを定義しており、少しずつ開発規模を拡大していくチームが、必要最小限のプラクテスを実践し、不足部分に関しては、開発チームが改善していくスタートラインとするのに、適した手法になっています。

    Nexusでは、依存関係が最小になるように、LeSSでは、フィーチャーチームによるチーム分割を基本とし、ドメイン知識や実装する機能について、チーム内で完結し、できる限りチーム内でのコミュニケーションで、開発が進められるように考えられています。

    しかしその場合、異なるチームが同じコンポーネントの変更をする必要があり、専門性の高い技術を全てのチームが持たなければならないことを意味します。
    このような問題を解決するため、LeSSには以下のようなチーム間連携の仕組みがあります。
    * マルチチーム・バックログリファインメント
    * No Branch
    * コミュニティー
    * オープンスペース
    * トラベラー
    * コンポーネントメンター
    * スカウト

    本セッションでは、Scrumのスケールアップの時に、チーム間連携を改善するこれらのプラクティスについて、紹介します。

    LeSS Study コニュミュニティーで学び、日本での第一回の「認定LeSS実践者コース」の受講からの学びを少しでもお伝えできればと考えて居ります。

  • Liked Tsuyoshi Yasunishi
    keyboard_arrow_down

    Tsuyoshi Yasunishi - 組織が急成長するベンチャーを、スクラムでチームにする方法

    20 Mins
    Talk
    Intermediate

    6人で開発していたベンチャーが、半年でエンジニアが30人あまりに急増し、チームやマネジメントという概念が存在しない中、スクラムをベースにチームとマネジメントの基礎を作っていった苦労話をいたします。

    人数が急激に増えるということは、初めましての人たちとの関係性構築(対立も含めて)、組織の文化の再構築、複雑性の増大に対する対処など、一見問題が起こっていないように見えても、問題が見えてくるときには対処が難しいような状態になることが多くありました。

    その際にスクラムをベースに様々な改革を行ってみたところ、上手く言った所、上手く行かなかった所、継続的に課題として対処したところなど、色々なことが起こりました。その生々しい事象や、失敗、ポイントになった考え方やプロセス、今後の戦略などから、アプローチの選択肢を共有させていただきます。

  • Liked すてぃお
    keyboard_arrow_down

    すてぃお - 1年間、チームで広告システムを開発した学び

    すてぃお
    すてぃお
    スクラムマスター
    Speee
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    1年間、広告システムをチームで開発してきました。

     

    開発当初はチームの事など一切考えていませんでしたが、

    自分が変わることによって、チームが変わっていくのが面白くなってきました。

    チームがどのような問題にぶつかって、どのように解決していったか、時系列で話していきたいと思います。

     

    最初は混濁してたチームもちゃんとしたプロセスを踏めば学習しながら成果を出し続けられるチームになるということを

    お話しします。

  • Liked Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui / Takeshi Arai - 継続性とアジャイル / Sustainability and Agile

    45 Mins
    Talk
    Intermediate

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

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

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

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

    発表(予定):

    • 翔泳社
    • ヴァル研究所

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

     

  • Liked Yotaro Takahashi
    keyboard_arrow_down

    Yotaro Takahashi / Hayashi Hiroyuki / Kento Haneda / Kouhei Takamatsu / Midori Hirose / Naoto Nishimura / Naoya Muto - レガシーな組織に @nawoto を入れてみた〜とあるチームの半年間の軌跡〜

    45 Mins
    Experience Report
    Intermediate

     分社して早数年、依然レガシーを極めるリクルートジョブズ。

    その中に突如転職してきたアジャイルサムライこと @nawoto 。

    初めてのメンバー、初めての言語、初めてのチーム開発。

    そして突然はじまったリモートワーク。

    人と、組織の思惑が絡み合う中、いかにしてこのチームはリリースまでこぎつけたのか。目まぐるしい展開の中で @nawoto が下した決断は!?

    混迷の半年間が、各メンバーの口から語られる。

    衝撃のラストを見逃すな!!

     

  • Fumitaka Inayama
    Fumitaka Inayama
    PMP
     
    schedule 1 year ago
    Sold Out!
    45 Mins
    Experience Report
    Intermediate

    エンジニアと組織。
    組織がおかしいと思ったら、自分で組織を変えよう。

    チームを育て、組織も育てる。
    属人的な専門家の集団から、学習する組織に変える。

    組織を変えるリ・デザインのコンセプト。
    エンジニアを育てるチーミング。

    組織をリ・デザインし、エンジニアの成長を促す組織に変えるためのプラクティスを共有します。