BizReach社の新規事業「yamory」におけるスクラム導入とモブプロ、チーム拡大、そしてLeSSへ。。。

yamoryってなに?

株式会社BizReachから8月27日にリリースされたサイバーセキュリティ事業とそのサービスで、開発中のプロジェクトで利用しているOSSの脆弱性検知やその管理を行うことでセキュリティリスクや対応コストを削減できます。

https://yamory.io/

開発フローの中にセキュリティを組み込んでいく、DevSecOpsを実現するための一つの選択肢として、開発中にOSS脆弱性に気づき、イテレーションの中でこれらを解消出来ることによって、

  • 「安心してテクノロジーを活用出来る世界」
  • 「すべてのエンジニアによってセキュリティを当たり前にする」

そんな世界観を目指しているプロダクトです。

セッションの概要

 そんなプロダクトを開発するために、2月頃に結成したスクラムチームについてです。結成は昨年はじめ頃でしたが、人数が増えるにつれて、作りたい機能が複雑化していくにつれて、どう管理していくかが課題でした。

 プロダクトの特性としては

  • 「どのOSSにどんな脆弱性があるのか」というデータベース
  • その脆弱性がどの程度危険なのか判断(トリアージ)するロジック
  • お客様のプロダクトにどのようなOSSが含まれているのか解析するためのコアロジック
  • これらを突合して「あなたのプロダクトにはこんな脆弱性があるよ」と通知するロジック

などなど、技術的に非常に複雑な構造をバックエンドに抱えています。

 新規事業結成直後なので所属するメンバーは各分野のスペシャリストばかりで、癖の強いエンジニアたちをなんとか纏めながら、上記のような複雑な機能を如何に安定して開発するか。事業のトップが選んだ手法がスクラムでした。

 それ以降、不定期に飛び込んでくる上記のような大型案件を上手く処理できずに大きな躓き(Velocityがでない!)を経験したり、短期間での異動・採用の成功によってエンジニアが激増し、規模の拡大によってLeSSを本気で考えざるを得ないほどになりました。

 チーム結成の経緯、フェーズごとにぶつかったいくつもの問題。それらにどう立ち向かったかをお話するとともに、チームがぶち当たっている現状の問題や、それらの解決に向けた取り組み、スクラムマスター見習いとしてチームを観察しながら感じたこと、マネージャーとしてチームメンバーの成長と向き合う中での葛藤など、ざっくばらんにお話します。

 
 

Outline/Structure of the Talk

    • 序章 出会い
      • スクラムとの出会い
      • スクラムマスターになる(資格を得る研修に行っただけ
    • 二章 成長
      • 自律し始めるチーム
      • モブプロの力に目覚める
    • 三章 瓦解
      • 急拡大
      • 増大する負の遺産
      • 燃えるセレモニー
    • 終章 リリース!
      • 変化を許容する組織へ
      • より良い姿を求めて(今後の取組み)

Learning Outcome

  • 尖ったエンジニアばかりで構成された小さな事業・チームがどのようにしてスクラムを導入したか
  • そしてどのような経緯で瓦解に至ったか
  • 今後の(手探り感満載の)取組み

Target Audience

新規事業へのScrum導入に興味のある方

Prerequisites for Attendees

特にありません。

schedule Submitted 1 year ago

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - アジャイルコーチ活用術

    20 Mins
    Talk
    Beginner

    世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。
    アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。
    アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。

    一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。
    これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります(アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです)。

    本セッションでは、アジャイルコーチとは何なのか、実際にアジャイルコーチをどう活用すれば良いのかを、日本で唯一のScrum Alliance Certified Team Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - Team-Based TEAM - 会社を越えるチーム -

    45 Mins
    Talk
    Advanced

    あなたのチームはいつ死にますか?

    スクラムはチームワークのためのフレームワークです。スクラムでは、安定したチームが成功するための前提条件として紹介されることが多いです。実際に「STABLE TEAM(安定したチーム)」はScrum Patternsの1つになっています。

    安定したチームは本当によいチームなのでしょうか?

    私たちのチームは、スクラムやモブプログラミングを通して自己組織的なチームになりました。Unlearnを自分たちの活動に組み込んで、学習するチームになりました。スタートアップしたプロダクトも成長軌道に乗せることが出来ました。そしてそのチームは、プロダクトの終焉を乗り越え、さらには会社をも越えました。

    私たちのチームは、Project-BasedでもProduct-Basedでもなく、Team-Based TEAMだったのです。私たちのチームにとってはプロダクトの終焉も転職もチームの死にはつながりませんでした。私たちの考える「STABLE TEAM(安定したチーム)」はSAME TEAM(同じチーム)ではなく、生物のように変化し続けることができるチームです。私たちは会社を越えた後も、変化と向き合い生物的チームを目指して活動を続けています。

    あなたのチームはいつ死にますか?

    このタフクエスチョンの答えはどの教科書にも載っていません。しかし、チームの死を考えることで、どう生きるかが定まり、どうチーミングすればよいのかが見えてきます。一緒にチームのライフサイクルについて考えてみましょう。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / Jean-Baptiste Vasseur / Kazunori Otani / Kenta Sasa - スクラムの理解を深めるスクラムショーワークショップ

    100 Mins
    Workshop
    Beginner

    スクラムショーワークショップは、スクラムの説明をショー(寸劇)形式で行うワークショップです。
    このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。

    スクラムショーワークショップは、yycr2019(アジャイルコーチとスクラムマスターの宴、通称:よなよなコーチングリトリート)
    生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。
    会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。

    皆さんも、スクラムショーワークショップを実施してみましょう!

    紹介動画はこちらから!

    詳細はこちらの記事をご参照ください。

  • Masaya Mito
    keyboard_arrow_down

    Masaya Mito - 組織変更して部長がいなくなってから起きたこと

    20 Mins
    Talk
    Beginner

    サイボウズの事業がオンプレミスからクラウドに移行する中、開発スタイルはウォーターフォールでの指揮統制・分業型からスクラムでの自己組織化・機能横断型に変わりつつあります。そんな状況の中、チームがユーザーにより価値を届けやすくするために職能別部署は解体されチーム主体の新組織になりました。

    新組織の狙いは以下の4つです。

    • 職能単位での部分最適化ではなく、チーム全体で最適化しやすく
    • 従来の職能の枠にとらわれず、個人の多様なスキル・個性を活かしてプロダクトやチームに貢献できるように
    • チームに必要なことはチームで意思決定できるように、権限と責任をチームに委譲
    • 主体的にキャリアを作れるように異動をカジュアルに

    組織変更の中で部長の役割は分割され再割当てされました。採用・予算などはチームに移り、異動は各メンバーに移り、給与評価はそれを受け持つ組織運営チームが新設されました。

    組織変更をして8ヶ月、様々な変化が起きました。
    どうやって意思決定するか議論するチーム。
    どんな人を採用したいか、そもそも人を増やすべきなのかを議論するチーム。
    上長がいなくなり色んな人と1on1し始めるメンバー。
    活発になる他職能/他チームへのお試し異動。
    チーム内でオープンに議論されるようになった問題。

    このセッションでは部長がいなくなった組織で起こったことを紹介します。

  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - スクラムマスター×複業=アジャイルコーチ? —複業で広げるキャリアの選択肢—

    Yusuke Amano
    Yusuke Amano
    ScrumMaster
    Cybozu
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    突然ですが、スクラムマスターのキャリア設計って難しいと思いませんか?
    アジャイル開発が普及するにつれてスクラムを導入するチームも増えている一方で、まだまだスクラムマスターというロールは一般的ではなく、多くのスクラムマスターは元々の役割と兼務しています。スクラムマスターとして価値を高め、今後キャリアを伸ばしていくためにはどうしたら良いでしょうか。

    現在私は週3日サイボウズで正社員として働きながら、週2日は個人事業主として社外のチームをお手伝いするというちょっと変わった働き方(複業)をしています。
    このセッションでは、エンジニアからスクラムマスターになり、アジャイルコーチとして複数チーム・組織を支援する立場になった事例を紹介したいと思います。スクラムマスターのキャリアの選択肢のひとつとして参考になれば嬉しいです。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / えすさん - ふりかえり実践ワークショップ RSGT出張版

    100 Mins
    Workshop
    Intermediate

    あなたのチームのふりかえり(レトロスペクティブ)はうまく機能していますか?マンネリ化していませんか?

    このワークショップは「ふりかえり実践ワークショップ」のRSGT特別版です。
    以下のような悩みを持つ方に、ふりかえりの楽しさを知ってもらいたいと思い、このワークを実施いたします。

    • チームでふりかえりをやっているが、どこかうまくいかないというモヤモヤを抱いている人
      • ふりかえりのやり方が毎回同じでマンネリ化している
      • ふりかえりで毎週同じ意見しかでない
      • ふりかえりが楽しくない、辛い
      • 反省会みたいな場になってしまっている
    • チームのふりかえりをこれから始めたい人
      • スクラムをこれからやってみよう、と思っている
      • ふりかえり(レトロスペクティブ)をどう始めたらいいか悩んでいる
    • ふりかえりをもっと楽しみたい人
      • 自分たちでふりかえりは楽しくやっているけれど、他のやり方にも手を出してみたい
      • 他の人のファシリテーションを見てみたい

    スクラムにおけるふりかえり(レトロスペクティブ)とはなにか、という基本から、ふりかえりの型や様々なアクティビティの体験を含む、ふりかえりを実践するすべての人に楽しんでいただけるワークショップです。

    みんなで楽しいふりかえりを実践しましょう。

  • Yuya Toida
    keyboard_arrow_down

    Yuya Toida - スクラム開発で力を発揮するデザイナーについて —アジャイルに適応したデザイナーとは—

    Yuya Toida
    Yuya Toida
    UX / UI Designer
    Cybozu
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    3年間スクラム開発を実践するチームでデザイナーをやってきた経験をもとに、デザイナーがスクラム開発の中でどのようにチームに関わって、そして力を発揮するのかについてお話しします。

    エンジニアやプロダクトオーナーと行ったロールと比較して、デザイナーというロールがどのようにスクラム開発に関わって行くべきかについてはあまり多くの知見がありません。
    スクラム開発に関わるデザイナーは少なくない(はず)と思うのですが、各自手探りでやっているのが現状です。
    自分も試行錯誤を続ける日々ですが、自身が学んだ知見を多少なりともオープンにすることで、デザイナーというロールにおいてもスクラム開発に対する知見が高まり、チームにより良い貢献ができるようになると嬉しいです。

  • Takeshi Arai
    keyboard_arrow_down

    Takeshi Arai - Scrum Master 2.0 〜僕が考えるスクラムマスターが目指すその先〜

    20 Mins
    Talk
    Intermediate

    僕が考えるスクラムマスターが目指すその先

    プロジェクトにおいて、プロダクトマネジメントにおいて、スクラムマスターとしての役割を実践してきました。
    この知識やマインドや実践知は、製品づくりだけに留まらせる必要はありません。
    チーム、部署へとスケールさせ、会社組織全体を対象にできるのです。

    また、自社だけに留まらず、複業にて他の会社を支援してきました。
    ソフトウェア開発の現場だけではなく、バックオフィス系、営業系、エグゼクティブチームなど、あらゆるところで活用できるのです。

    スクラムマスターのノウハウを活用して、会社という組織を活性化させることを目指してみませんか?
    僕が考えるスクラムマスター業の一つの解をご提供します。
    もしかしたらスクラムマスターとしての「あり方」や「生き方」なのかもしれません。

  • Kazuhiro Niwaya
    keyboard_arrow_down

    Kazuhiro Niwaya / Yusuke Amano - 残業まみれで属人的だったサイボウズ人事部をスクラムで改善した話  ~抜けたエースの穴をチームで乗り越えるまで~

    20 Mins
    Talk
    Beginner

    サイボウズの人事部採用チームは、
    採用計画の立案から面接の実施、合否連絡、内定者のフォロー、イベントの出展、説明会の実施といった業務を日々行っています。
    採用チームに異動してきて2年目の始めに、リーダーを引き継ぐことになりました。
    これまで経験豊富なリーダー中心に業務を進めてきた状態だったので、経験の浅い自分がリーダーになることに不安を感じていました。
    自分個人がエースの抜けた穴を埋めるのではなく、チームの皆でカバーできるような進め方をしたいと悩んでいたところ、
    開発チームで導入が進んでいたスクラムが目に止まりました。
    スクラムが人事の業務改善にも役立つと感じ、導入を決意し、2年ほどスクラムをベースにした業務改善を進めてきました。
    プランニングやふりかえりで地道な改善を重ねた結果、モブ作業やカンバンを活用が進み、メンバーの残業が減り、チームのベロシティも向上しました。
    現在はチームでタスクがコントロールでき、理想のチームに向かう良い状態が作れています。

    改善の過程で起きた問題やそこから学んだこと、チームに起きた変化を紹介したいと思います。

  • Kentaro Masuda
    keyboard_arrow_down

    Kentaro Masuda - 新規事業プロダクトオーナーの現場!〜そのソフトウェアはリリースできますか?〜

    Kentaro Masuda
    Kentaro Masuda
    Software Engineer
    Freelance
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    みなさんは、新規事業に取り組んだ際、プロダクトに価値があることを感じつつも、そもそもリリースできなかったことはありませんか?

    私は、過去いくつかの新規事業に取り組んできました。無事にリリースできたプロダクトもあれば、世に出ることなくお蔵入りしたプロダクトもあります。
    また、関わった立場は、開発者、スクラムマスター、テクニカルサポートなど様々です。

    新規事業は、プロダクトオーナーが、仮説検証をおこない、価値がありそうなことを感じたとしても、世の中にリリースすることすら難しい場合があると、今までの経験から感じています。

    プロダクトオーナーが考えるべきことは、スクラムガイドに記載されているような「プロダクトがユーザーに価値があること」以外にも数多くあります。
    プロダクトを会社からリリースするには、営業、サポート、製造、出荷、総務など、様々な部門との連携が必要です。
    ユーザーがプロダクトを購入するには、営業部門がプロダクトの価値を理解し、販売網を作り上げる必要があります。また、プロダクト購入時の利用規約は法務部門が内容を精査する必要があります。
    ユーザーがプロダクトを利用する際に困った場合、QA対応ができるサポートセンターを構築する必要があります。
    ユーザーが利用するプロダクトが、ソフトウェアを通して販売される場合(ECサイトなど)は、プロダクトの製造や出荷が必要で、ソフトウェアを提供するより長いリードタイムや事前準備が必要です。

    加えて、製造、販売ルートによっては、社外との関係性も非常に重要です。
    製造が社外の工場の場合、アジリティを高めるために小ロット生産をしたいですが、万単位のロット数を最低発注する必要があったりします。
    既存の販売網を代理店を通して活用する場合は、代理店の営業部門にプロダクトの価値を理解してもらう時間が必要ですし、仕切りといった価格調整が利益を残すために大事な要素になります。

    上記はあくまで例ですが、プロダクトをリリースするためには、ソフトウェアを作り上げる以外にもやるべきことが数多くあります。


    本セッションでは、様々な立場で、様々なプロダクトオーナーのもと新規事業に関わったエンジニアとして、私の過去の成功事例、失敗事例を踏まえながら、新規事業においてプロダクトオーナーが考える必要があることを紹介します。

  • Keita Watanabe
    keyboard_arrow_down

    Keita Watanabe / Kazuki Mori - チームビルディングワークショップ

    100 Mins
    Workshop
    Beginner

    最近チームで笑えていますか?

    プロジェクトが始まってからチームビルディングを全くせずにいきなり開発が始まって、チームのコミュニケーションがうまく取れない。チームに新しいメンバーが入ったものの、誰も相手をせず、悲しい目をしてこちらを見ている。 そんな現場、ありませんか?


    このワークショップでは、忙しい中でもできる、よいチームを作り上げるための様々な手法を体験できます。 こんな人におすすめです

    • いいチームを作りたい人
    • チームのコミュニケーションがうまくとれていないともやもやしている人
    • どうやってチームをよくすればよいかわからない人

    ワークショップの中で、チームビルディングのノウハウを知り、実際の現場に戻ってから使える様々なアクティビティを実践します。

    添付したスライドはXP祭り2019にて開催したものです。

    こちらの拡張版を行います。

  • Yoshitaka Hirano
    keyboard_arrow_down

    Yoshitaka Hirano - 1年半スクラムとモブプログラミングをやってみた話

    20 Mins
    Talk
    Beginner

    モブプログラミングを聞いたことはあるけどやってみたことがないという話や、やってみたけどあまりうまくいかなかったという話はよく聞きますが、少なくとも僕の周りではうまくいっている例があまり聞かれません。

    1年半前にスクラムとモブプロを同時に始めたのですが、実際の開発の現場において、部屋の構成、内容、人数、能力差など、うまくいったパターン、失敗したパターンなど気づいたところを共有できればと思います。

    また、その中で気づいたバックログの切り方などスクラムに関することもお話できればと思います。

  • yusuke kato
    keyboard_arrow_down

    yusuke kato - スタートアップの事業成長とともに、プロダクトチームがスケールしていくために取り組んだ挑戦やその成長痛

    yusuke kato
    yusuke kato
    product engineer
    atama plus
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    atama plusは創業期から「プロダクトファースト」の文化を大切にし、アジャイルにプロダクトづくりをしています。
    プロダクトチームだけではなく、カスタマーサクセスチームやコーポレートチームもアジャイルな考えが浸透しており、全員で良いプロダクトを作ろうという文化が根づいています。

    現在では社員数も50人を超え、当初は1チームだったプロダクトチームも今は3チーム(+α)となりました。

    しかし、決して順風満帆に3チームにスケールしたわけではありませんでした。
    初めてのチーム分割を行った際は、うまく機能せず、再度1チームに戻す決断しました。また、一度チームを戻す決断をした後も、組織の成長の中では、チームを分割していく価値があると考え、再度チーム分割にチャレンジしました。

    本セッションでは、特にプロダクトチームにフォーカスをあて、毎月のように人が増えていくスタートアップの中でプロダクトチームを1チーム→3チーム(+α!)にスケールさせていくために行った取り組みや実際におきた課題や痛みなどを実例を交えてお話できればと思っています。

  • yumi kanehira
    keyboard_arrow_down

    yumi kanehira - 130人の合意形成!アジャイルなプロジェクト遂行までの道のり~席替え編~

    yumi kanehira
    yumi kanehira
    ScrumMaster
    GROOVE X, Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner
    こんにちは!マネージャー不在のフラット組織でSMをやっているぶたが好きな兼平です。
    ScrumMasterとして、集団の合意形成をしていく支援を日々行っておりますが、
    入社してすぐ取り掛かったのが、
    「130人が協働しやすい席替えをメンバーが決められるように支援する事」でした。
    簡単そうにきこえるかもしれませんが、要は【130人の合意形成】
    ScrumMasterはどう導けばよいのでしょうか?
     
    一見シンプルな作業でも、様々な制約の元で130人もの集団になると、
    目先の最適化を望む意見も飛び交います。
    どうやって【恊働性】を高める全体最適な計画をし、
    実際に遂行、完了まで持っていくのか…
    SMの涙あり、笑いありの3週間のお話をしたいと思います。
  • Nakato Arase
    keyboard_arrow_down

    Nakato Arase / YUMA ISHIKAWA - ヤフーとイーブックイニシアティブジャパン初の統合プロダクト開発、Agileで進めた全面リニューアルの裏側

    45 Mins
    Talk
    Intermediate
    Yahoo Japan、ebookjapan初の統合プロジェクト、スケジュールファーストの中、Agile開発導入、実践しながら無事リリースしました。
    その後1年で、150万DL突破の電子書籍サービス「ebookjapan」。Yahoo!検索や、Yahoo!トップページとの連携だけでなく、ソフトバンクとの連携も始まり、電子コミック市場No.1を目指して、日々成長を続けています。
    今回は二つの会社がアジャイル開発を導入、実践を通してプロダクトオーナー、アジャイルコーチが取り組んだ事や学んだ事をお話します。
    組織へのアジャイル開発の理解、現場、マネージャーとの意思疎通、エンジニア、デザイナー、ビジネス、編成一体となった大規模アジャイル開発の実践。期限を守るためのスコープコントロール、ステークホルダーマネージメント、そしてリリース後のさらなる取り組みをプロダクトオーナー、アジャイルコーチがそれぞれの立場でやってきた事をお話しいたします。
    ・編成、エンジニア、デザイナー、ビジネス等、異なるスキル(部署、職種)とのアジャイル開発
    ・ステークホルダーの巻き込み、交渉方法
    ・異なる企業文化を持つ同士の共通認識
    ・アウトソーシングとの協働方法
    ・スケジュールファーストにおいて大事なこと
    ・Agile開発未経験から導入・実践時に工夫したこと


    大規模Agile開発導入・実践、異なる文化を持つ組織同士でのプロジェクトの進め方などにご興味ある方は是非お聞きください。
  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - 世界に飛び出そう!僕が海外カンファレンスから学んだこと

    Yusuke Amano
    Yusuke Amano
    ScrumMaster
    Cybozu
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    スクラムを学び実践するみなさん、特にRSGTに参加して情報交換をしようという学習意欲の高いみなさんは、きっと海外カンファレンスにも興味があると思います。私も日本で学びを続ける過程で、「日本のアジャイル事情は少しずつ分かってきたけど、海外ではどうなんだろう?」という疑問を持ち続けていました。

    一般的に海外カンファレンスに行くには費用・言語・稟議など多くの問題があり、実際に行くには高いハードルがあると思います。そもそも高い費用をかけて行くほどの価値があるのか?という疑問もあるでしょう。

    価値があるかどうか判断するために、まずは飛び込んで情報を増やしましょうということで、私は1年でなるべく沢山の海外カンファレンスに参加するという実験を行ないました。直近約1年では下記のカンファレンスに参加しました。

    • Agile Conference 2019
    • LeSS Conference 2019
    • Global Scrum Gathering Vienna 2019(執筆時予定)
    • Agile Vietnam 2018/2019(執筆時予定)

    このセッションでは、実験の過程で学んだ海外カンファレンスの歩き方から、参加すべき人とその理由などを共有します。