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

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

Outline/Structure of the Talk

・1Sprint:席替え?すればいいじゃん。まずは無邪気に場を作ってみた

・2Sprint:フィードバックを経て細かい作業が得意なSM召喚

・3Sprint

・まとめ

Learning Outcome

・集団の合意形成を導く上でぶつかった課題・失敗・喜び・そこで得た学びを知見として得ることができる。

Target Audience

・集団での意思決定に悪戦苦闘して頑張っている方 ・ScrumMasterとしてチームの支援を頑張っている方

schedule Submitted 1 year ago

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

  • Yota Imai
    keyboard_arrow_down

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

    Yota Imai
    Yota Imai
    Manager
    BizReach Inc,
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    yamoryってなに?

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

    https://yamory.io/

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

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

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

    セッションの概要

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

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

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

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

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

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

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

  • 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サイトなど)は、プロダクトの製造や出荷が必要で、ソフトウェアを提供するより長いリードタイムや事前準備が必要です。

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

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


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

  • yumi kanehira
    keyboard_arrow_down

    yumi kanehira / Kazunori Yamasaki - 全社スクラム!ScrumMasterがみた事業費100億円ロボットベンチャーの挑戦!

    45 Mins
    Talk
    Intermediate

    私達GROOVE X(https://groove-x.com/)は4年の歳月をかけ、

    不確実で複雑な "♥" をもった家族型ロボットを発売しました!

    前例がないプロダクトを、180人20チームの規模で発売までこぎつけた弊社は
    【イノベーションを起こし続けられる組織づくり】を目的に、
    組織コンセプトとしてスクラムを選択しています。

    その適応範囲は、Softwareを作るチームだけでなく、
    Hardwareやコーポレート、ビジネスレイヤーまで、全社に及びます。

    スクラム導入・運用にあたっては、

    現場のメンバーや上司を説得する事に注力されている方もいるかと思われますが、

    いざ導入した「その先」に待っているのはバラ色の世界でしょうか…?

    全くもってそんなわけが無い「その先」でぶつかった

    課題・失敗・喜び・学びの事例をお話させていただきます。

  • Yoshitaka Hirano
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

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

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

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