データ分析チームにスクラム型開発フローを取り入れてみた

スクラムは主にサービス開発に用いられるフレームワークですが、私たちGlobisのデータチームではデータ分析系のタスクにおいてもスクラムを取り入れられないかと試行錯誤してきました。

試行錯誤を続け約半年経過した今、開発系タスクとの違いや工夫してきたポイント、現在どのように開発を進めているのかということをお話しさせて頂きます。

 
 

Outline/Structure of the 1st Step Case Study

- スクラムをやる前

- 開発向けのスクラムをやってみた時

- データ分析向けにどんどん変えていった時

- データ分析にスクラムを取り入れる利点、ハマりどころ

- エンジニアチームの場合との対比

Learning Outcome

- データ分析にスクラムを適用した事例を知ることができる

- 進めていく上でのハマりどころについても知ることができる

Target Audience

データ分析系の業務へスクラム型の開発を活用してみたい方、エンジニアチームでデータ分析のタスクも持っている方

schedule Submitted 1 year ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano / Toshiyuki Ohtomo - チームワークの会社で最高のプロダクトを目指すチームができるまで -強くてスケールするチームの作り方-

    45 Mins
    Thought & Practice
    Intermediate

    私(@ama_ch)が所属するサイボウズでは、「チームワークあふれる社会を創る」というビジョンを掲げてグループウェアを開発しています。

    自分たち自身のチームワークを高めるために、2016年にスクラムを導入しました。私の所属するkintone開発チームでは、スクラム導入から1年以上が経過し、新たに下記のような問題に直面していました。

    「スクラムを導入したは良いけど、まだ加速しきれていない気がする」
    「チームが壊れないようスケールさせるにはどうすれば?」

    これらの問題を解消し、最高のプロダクトを目指すチームを作るために社外のスクラムマスター(@toshiotm)を巻き込んで、より良いスクラムの実践を探求してきました。

    1年間の実践を通じて、私たちのチームには以下のような特徴が現れました。
    - 複数拠点をまたぐリモートモブ中心の開発
    - 新卒エンジニアが1週間で活躍し始める
    - スプリントごとにチーム構成が変わる
    - 仮説検証マインドにもとづく高速な改善
    - スクラムマスターが不要になる

    この1年の活動をふりかえり、スクラムが本当の意味で機能し始めたチームに起きた質的な変化、スケーリングの取り組み、私自身に起きたスクラムマスターの役割の変化などについて、一緒に推進してきた社外スクラムマスターと一緒に考察したいと思います。

  • Liked SATORU KAWABUCHI
    keyboard_arrow_down

    SATORU KAWABUCHI - NTTみたいなトラディショナルな企業でアジャイルな取り組みを実現するたった一つの必要なもの!

    20 Mins
    1st Step Case Study
    Beginner

    大企業の中でファーストケースとしてのアジャイルを生き延びさせるには?

    起きてくる現場と社内との課題、その時マネージャーにできることは?

  • Liked Takuo Doi
    keyboard_arrow_down

    Takuo Doi - 行動分析学に基づくScrumの導入

    Takuo Doi
    Takuo Doi
    CTO
    Lifematics Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Thought & Practice
    Intermediate

    Scrum / Agileは非常に人間的なアプローチです。

    そして、それが大きな魅力である一方で、これまで、プロセスで縛ることにより開発を実践してきた人にとっては、理解できない、導入できない原因ともなっています。

    アジャイルの実践者に現場の課題を相談した際に、よく返ってくる返事の一つが、「It depends(状況による)」です。

    この言葉はまさしくそうなのですが、アジャイルコーチが入っているような現場ではなく、あまり経験のない人にとっては、自分たちの状況を見てもどうしたらよいか分からなく、手当たり次第に思いつきを実施してみたり、原理主義のようにプラクティスを遵守しようとしたりしてしまう原因となっています。

    本セッションでは、心理学の一分野である行動分析学に基づき、Scrumの課題を見付け、その課題を解決する方法を見つける科学的な方法を提案したいと思います。

    本セッションの内容により、改善を促したいプロジェクト/チームをどのようにScrumがうまく機能する体制にし、文化として根付かせるかの汎用的な手法を知ることができます。

  • Liked Yosuke Ota
    keyboard_arrow_down

    Yosuke Ota - スクラム1年生のチームが全員でRSGT2018に参加してわかったチーム開発、はじめの一歩

    20 Mins
    1st Step Case Study
    Beginner

    どのようにするとより良いチーム開発ができるのでしょうか。

    いま、私たちのチームは自信を持ってチーム開発をしています。1週間スプリント中の1日スプリント、当たり前に行われるペア・モブプログラミング、チームの活動に合わせた工夫のあるタスクかんばん、多くのプラクティスを実践することで安定してチームの成果を出しています。

    しかし、スクラム導入からしばらく、自信を持ってチーム開発をしているとは言えない状態でした。

    メンバーの状態に左右されるベロシティ、レビューで発覚する未完了、再計画されないデイリースクラム、さまざまな課題がそこには存在していました。スクラムのことを良く分かっておらず、言われたことをやっているだけの状態だったため、改善のサイクルをうまく回せないことが続きました。チーム開発に対する不安が大きい時期です。

    このような状態から大きく変わる転換点となってくれたのが、チーム全員で参加したRSGT2018でした。

    本セッションでは私たちのチームがわかったRSGTの素晴らしさと、チーム開発のはじめの一歩を紹介します。

  • Liked Ryosuke Nakamura
    keyboard_arrow_down

    Ryosuke Nakamura - 自律的で協調的なチームの作り方 ~複数拠点、多言語、職能型組織で始めるScrum~

    20 Mins
    1st Step Case Study
    Beginner

    職能型組織からメンバーが集められてプロダクトチームを作るような場合、それぞれの役割の間にあるグレーゾーンのタスクを誰が拾うのか、お互いのロールが何やっているのか見えづらい、などの問題が発生しがちかと思います。
    私たちのチームでも大きく以下の役割ごとの組織から集められたチームでした。

    • プランナー(プロダクトデザイン、企画、グロースを担う役割)
    • デザイナー
    • フロントエンドエンジニア
    • サーバーサイドエンジニア
    • QA(Quality Assurance)


    また、プランナーとデザイナーは東京、エンジニアとQAは福岡と物理的にも離れた中作られているチームです。
    もちろんそれぞれがいいプロダクトを作りたいという思いを持ってやっていたのですが、
    プランナー側には以下のような不満があり、

    • エンジニア側の見積もりが適切かわからない(必要以上にバッファー積んでないだろうか?)
    • エンジニア側が十分に効率よく働けているかわからない(人を余らせているのではないだろうか?)
    • エンジニアの売り上げに対するコミットメントが低いように感じる(締め切り守る気あるのだろうか?, オーバーエンジニアリングしてないだろうか?)
    • 変更を柔軟に取り入れてデッドラインも守るようにしてほしい(差し込み開発入れたいこともあるけど、走ってる大きな機能追加のデッドラインはずらしたくない)

    エンジニア側には以下のような不満がありました。

    • 見積もり前にビジネス側で開発のスコープとデッドラインが決めないでほしい
    • 開発する機能に関して背景や目的があまり納得できない
    • 開発する機能の優先順位がわからない
    • プランナー側が作成する要求や仕様が不正確だったり、不十分だったりするせいで、開発期間が延びていると感じているのに理解されていない気がする


    そんな中、社内アジャイルコーチによるエンジニアチームでの振り返りワークショップをきっかけに、エンジニアが週1の改善 MTG を開始し、不満をためることをやめ、プランナー側へ歩み寄るという行動を始めました。
    仕様が期待するものでないのは、エンジニア側からどんなものが欲しいのか伝えられてないからだということで、要求仕様の書き方の模範例を一緒に作る取り組みを始めたり、リモートランチなど直接的に仕事とは関係ないコミュニケーションの量を増やしたりしてお互いの理解を進めていく一方で、KanbanやScrumの社内研修をプランナーとエンジニアで一緒に受けてAgileな開発に関する共通認識を一緒に作っていきました。そして、Scrumからいいところを学ぼう、チーム改善のヒントを得ようとして開催された社内Scrum研修を受けた後、あれScrum導入してもいいんじゃない?とプランナー側、エンジニア側どちらともなく思ってScrumでの開発が始まりました。
    以下のような制約がある中の導入でしたが、それらを受け入れながら、チームの自律的、協調的な動きはScrum導入後加速したように思います。

    • プランナー組織構造の都合上、1人のPOは選出しにくい
    • QAを担当する独立した組織があり、社内にQAの責任者入るものの、実際の手動テストは外部委託
    • 開発チームに共通の言語がない(チームメンバーは中国人、台湾人、日本人、アフガニスタン人で構成され、日本語を話せない外国人、英語を話せない日本人がいる)

    私達は理想的なScrumを実践できている訳ではないかもしれませんが、継続的な改善とお互いの歩み寄りを積み上げ、またScrumのフレームワークの力を借りることで、確実に、よりアジャイルになっていると感じています。

    この事例紹介を通して、組織間の不和に悩んでいる人、チームメンバーにもっとお互いを助け合って欲しいと思っているリーダーのような人に改善のヒントを共有できるといいと思っています。

  • Liked ohbarye
    keyboard_arrow_down

    ohbarye - プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー / Fact based decision making

    ohbarye
    ohbarye
    Engineering Manager
    Quipper
    schedule 1 year ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    ―――憶測や独断ではなく計測されたデータや事実に基づいて意思決定している者だけが石を投げなさい―――

    多くのWebサービスがそうであるように、Quipper が運営する「スタディサプリ」においても長らく"負債"と呼ばれる機能を抱えてきました。

    関係者曰く「なぜこんな機能を早く消してしまわないのか」…

    しかしA/Bテスト・統計的手法・エンジニアリングを組み合わせ、「その機能がどれだけ売上に貢献しているのか」という価値を定量化した結果、"負債"と呼ぶのは相応しくないと認識を改めることになりました。

    本セッションではその事例をご紹介しつつ以下の内容についてお話できればと思います。

    • Quipper が実践しているA/Bテスト
    • 定量データに基づく意思決定
    • 価値の定量化が開発体験やチームにどのような影響を及ぼしたか
  • Liked Tomonori Sano
    keyboard_arrow_down

    Tomonori Sano - スクラムで学ぶスクラム開発

    Tomonori Sano
    Tomonori Sano
    Manager
    KDDI
    schedule 1 year ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    Jeff Sutherland氏とKen Schwaber氏がスクラムを作る際に参考にした『The New New Product Development Game』には以下のように書かれています。

    "Stop running the relay race and take up rugby"

    2019年という日本でラグビーワールドカップが開催される記念すべき年、スクラム実践者の皆様とラグビーという別の角度からスクラム開発を見つめ直したいと思います。

  • Liked Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - 心理的安全性ゲーム

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 1 year ago
    Sold Out!
    45 Mins
    Thought & Practice
    Beginner

    チームの中で、なにか事件が起きたとき、誰がどういう反応をするかでチームの底力が垣間見えます。「心理的安全性ゲーム」では、マズい状況に対する様々な反応を体験して、チームにおける心理的安全性の意味と作り方の理解を深めます。

    「心理的安全性ゲーム」はカードゲームですが、勝敗はありません。マズい状況を発見して報告してくれた「平和を破壊する役」に対して、各メンバーは手札から「発言」を選んで反応します。10分ていどで遊べる簡単なゲームになります。

    このゲームは文字通り、心理的な効果を体験できます。たとえゲームと分かっていても、「教えてほしい」と頼んでいるのに「舌打ちをして」「自分でやれ」と言われるとちょっと傷つきます。言ったほうも、あとで心苦しくなったりします(あるいは、スカッとするかもしれません)。そうしたやりとりを目の当たりにしたチームと一緒に、よいコミュニケーションについて話をするきっかけを作るゲームです。

    4-5人のグループでゲームをやり、そこでの気づきやよりよいコミュニケーションの在り方について議論をしたり、共有したりします。さらにどんな改善が見られるか、再度ゲームをやって試してみましょう。

  • Liked Yoshihiro Yunomae
    keyboard_arrow_down

    Yoshihiro Yunomae - 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた

    20 Mins
    Advanced Case Study
    Intermediate
    モバイルゲームの運用では、プレイヤーを飽きさせないために、週2~3回のコンテンツのアップデートと、月1回の機能アップデートを実施します。このため、開発チームは継続的に価値を出し続ける工夫が必要となります。

    アカツキのある大規模開発チームにおいて、人数の割に開発の進みが思わしくなく、作業が属人化されていました。結果的にプレイヤーに継続的に価値を届けるのが困難となっていました。これは、以下の2つが根本的な原因でした。

    ・チームの開発スタイルが確立する前にチームが肥大化したことにより、コミュニケーションフローが整備されていなかった
    ・開発業務中に運用業務の差し込みが入り、度々開発が中断していた

    これらの根本課題に対処するため、以下を実施しました。

    1. 開発チームを分割し、コミュニケーションパスを設計
    2. Scrumをベースに、複数のチームが並行バージョン開発出来るように開発フローを設計
    3. 次々バージョン開発チームが運用業務を行うようにし、次バージョン開発チームの業務中断を抑止

    本セッションでは、並行バージョン開発を取り入れた経緯と、取り入れた並行バージョン開発の手法を詳細に紹介します。
  • Liked Takahiro Kaihara
    keyboard_arrow_down

    Takahiro Kaihara / Misa Fukuhara - 「自分を立てなおす対話」をやってみよう! ♥ 智慧の車座ワークショップ

    120 Mins
    Workshop
    Beginner

    みなさん、仕事上で理不尽な思いをしたり、仕事でなんだか不完全燃焼していませんか?

    自分ではなくても前は仕事をバリバリと精力的に活動していたのに、今は元気がないなぁって人がまわりにいませんか?

    社会人生活や人生において、ロジカルには解決できない問題がたくさんあります。

    そのような問題を解決・解消するひとつの方法として、皆さんに「対話」を紹介し、少しでも健やかに日々を過ごしていただきたいというのが、このプロポーザルを出した理由です。

    本セッションでは、プロコーチ、組織コンサルタント加藤 雅則さんの著作『自分を立てなおす対話』で紹介されている『智慧の車座』をやってみたいと思います。

    https://www.amazon.co.jp/dp/453231707X

    智慧の車座は、問題を抱えたテーマオーナー(相談者)と、複数の支援者の対話を通して、「問題をほぐし」「智慧を出し合い」解決方法を模索する対話法です。

    このワークショップ参加後に、以下のような状態になればよいなあと考えています。

    1. 「自分を立てなおす対話」とは何かを知る
    2. 「自分を立て直す対話」を(なんとなく)できるようになる

    人生に迷っているあなた、このワークショップに参加して、暗闇荒野に進むべき道を切り開いてみませんか?

    興味を持たれた方はぜひ、投票をお願いいたします。

    「対話こそ、金より輝かしく光よりいのちあるもの」(ゲーテ)

  • Liked Rie Chonan
    keyboard_arrow_down

    Rie Chonan / Tadataka Ebihara - プロダクトオーナーは突然に 〜メカ屋出身プランナーと奇妙な冒険〜

    20 Mins
    1st Step Case Study
    Beginner

    プロダクトオーナーの育成、支援はスクラムマスターの役割であり、難しさである、という事は巷でよく聞く課題です。

    確かに、私も過去に現場でそのような状況に直面することがあり、プロダクトオーナーの立ち位置やチームとの関わり方、支援の方法について悩むことがありました。

    一方で、私たちClova関連チームのプロダクトオーナーは、POという役割も、スクラム開発も初めてという状態での抜擢。

    未経験による悩みだけでなく、ソフトウェア開発とのギャップを感じていました。

    このような状況で、私たちはプロダクトオーナーが抱える悩みや問題は、開発チームの課題として一緒に解消する事にしました。

    本セッションでは、Clova関連チームのプロダクトオーナーと共に登壇します。

    複数の立場から、開発チームとの関わり方やプロダクトオーナーが躓きやすいポイントを紐解きながら紹介できたら幸いです。

  • Liked Yuichiro Yamamoto
    keyboard_arrow_down

    Yuichiro Yamamoto - スクラムならできる プロダクトバックログの戦略

    20 Mins
    Advanced Case Study
    Intermediate

    アジャイルコーチだった私は、昨年のRSGT2018のすぐあと企業に就職しました。EC/製造販売業を営む企業で、内製システムの開発とECサービス/生産管理および社内IT資産のすべてを運用管理するIT部門の部門長を務めてます。

    外部コーチから転身して圧倒的当事者として直面したのは、巨大なレガシーコードとシステムトラブルの山、洪水のような運用アラート、疲弊したエンジニア、諦め…私がやるべきことは、チームコーチングや仕組みづくりよりも、本当に必要なシステムとサービスを提供することです。

    そんなIT部が、この一年間(応募現在で9ヵ月)でいくつかの功績を産み出すことに成功し、社内での信頼を取り戻しつつあります。その道のりをチームと共に工夫してきたことを、プロダクトバックログを管理するという立場から整理してみたいと思います。

    • 部長、知らないでは済まされませんよ
    • システムアラートが止まらない
    • 事業部長連絡会にプロダクトバックログを持ち込む
    • 小さなAwesome
    • 何かを減らさなければ
    • 半分の時間と倍の効果とプロダクトバックログ
    • マインドやない、マネーの話やで

    コメントいただければ、それを踏まえて構成して行きたいと思います。ぜひコメントください。

  • Liked Kenta  Sasa
    keyboard_arrow_down

    Kenta Sasa / Iwao Harada - 明日現場で使える!とにかく明るいScrum Patterns 活用ワークショップ

    100 Mins
    Workshop
    Beginner

    皆さん、開発をエンジョイしてますか?
    開発を行っていると楽しいこともありますが、様々な問題が発生してツラいこともあると思います…

    そんな問題に直面したとき、皆さんはどう対応していますか?
    Try & Errorを繰り返しながら、困難な問題と闘い続けているのではないでしょうか?

    そんな皆様、お喜びください!

    このセッションは、Scrum Patternsを使った問題解決の紹介するだけでなく、実際にそれを体感できるワークショップを開催させてもらおうと思います!
    多くの現場で有効なパターンを学ぶことで、明日の現場に役立つ方法を持ち帰ることができます。

    パターンとは既に実証済みの解決策

    パターンは建築家アレグザンダーの提唱した『パタン・ランゲージ』で挙げられており、パターンの構造は以下のようになっています。

    ❝ある「文脈」で繰り返し起こる「問題」「解決」する方法。その方法にはいくつかの「制約」が課せられているかもしれない -- 結城浩

    私たちはそのパターンを通して、先人たちの知恵を学ぶことができます。
    パターンは時に知っていると思い込んでいる事に関しても新しい視点を与えてくれたり、改めて解決方法の目的の真意を思い起こさせたりします。

    そんなパターンを中心にみんなで問題を議論し、よりよい解決方法を見出したいと思っています。

    皆さんがお持ちの悩み、既にパターンに書いてあるかも?

    ワークショップに関して

    ワークショップを開催するのは、アジャイルコーチやスクラムマスターを中心とした、パターン大好きメンバーが集まったグループ "Scrum Patterns Tokyo (通称SPaT)" です。
    パターンを知らない人や、アジャイル開発初心者でも楽しめる場を提供したいと思います。

    1組4、5人で4組を想定しており、各チームに1人SPaTメンバーがフォローに入ります。

    みんなでパターンランゲージを楽しみましょう!

    ワークショップ登壇者

    • 天野 祐介
    • 原田 厳
    • 稲野 和秀
    • 木村 卓央
    • 川口 恭伸
    • 小坂 淳貴
    • 笹 健太

    参考サイト

    Scrum Patternsに関してはScrum PLoPのサイトがあります(英語)
    http://www.scrumplop.org

    ※本セッションではSPaTが日本語訳したパターンカード(仮)を使用します。

    英語が苦手な方でも問題ありませんのでご安心下さい。

  • Liked Tatsuya Kinugawa
    keyboard_arrow_down

    Tatsuya Kinugawa / Rochelle Kopp - そのときサーバントリーダーはどう振る舞うか

    45 Mins
    1st Step Case Study
    Beginner

    サーバントリーダーシップを実践するにあたって様々な場面で振る舞いを考えさせられることがあります。

    上司への向き合い方、配下リーダー陣への向き合い方、はたまた彼らのメンバーに向けてもこれまでとは違う振る舞いをすることが多いです。

    本セッションではRochelle Koppさんと一緒に具体的なシチュエーションを題材にしながら旧来のマネジメントとサーバントリーダーシップの振る舞いの違いについて実例を挙げながらお話したいと思います。

    これによりこのマネジメント手法がより身近なものに感じて頂ければ嬉しいです。

  • Liked Arata Fujimura
    keyboard_arrow_down

    Arata Fujimura - 結局DevOpsって何だろう? 〜10年目の定義ぐらい大目に見てよ〜

    Arata Fujimura
    Arata Fujimura
    Manager
    Classmethod, Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner
    2009年にDevOpsという言葉がうまれてからそろそろ10年。
    元はDevとOpsが対立せずに連携して協力していこう開発スタイルに過ぎなかったこの造語が、明確な定義を持たないために様々な意味合いが後付され、DevOps担当者である私を苦しめます。

    そこで私自身、「俺のDevOps」を定義しました。
    これやっとけば、俺がDevOps認定するぜ!ってことを、事例交えてお話します。
  • Liked Mitsunori Seki
    keyboard_arrow_down

    Mitsunori Seki - プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処

    45 Mins
    Thought & Practice
    Intermediate

    エンタープライズアジャイルを実現するにあたり、プロダクトオーナーは、プロダクトマネジメント組織の中心として振る舞うことが求められます。しかし、プロダクトオーナーが抱える悩みは多岐に渡ります。本セッションでは、それらの悩みごとを整理した上で、解決に向けた取り組みについてご紹介いたします。

    • プロダクトオーナーとは
    • プロダクトオーナーが抱える悩み
    • なぜプロダクトオーナーが悩むのか
    • どう対処したらよいか
    • プロダクトオーナーがやるべき3つのこと
    • まとめ
  • Liked Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / Haruna Iizuka / Masahiko Morita / Ryota Nagatomo / Saki Ota / Saki Tanaka / Takuya Uchida / Yuki Misumi - 開発未経験の新卒がとりあえず1 hour Timeboxまわしながらプロダクトつくってみたんだけど、何か質問ある?

    45 Mins
    Thought & Practice
    Beginner

    2018年4月・・・

    鶴の一声で、とあるWeb企業に入社したビジネス採用の新卒は全員プログラミング研修を受けることになりました。

    プログラミング未経験の彼らは、最初は黒い画面(ターミナル)すら怖がっていましたが、数カ月後には研修メンター陣からのインプットを頼りに、

    • 1 day timebox
    • 1 hour timebox
    • モブプログラミング
    • プロトタイピング
    • ユーザーインタビュー

    などをまわしながら、3週間でプロダクトを作れるようになっていました。

    さて皆さん、なにか質問ありますか?
    ※この話はノンフィクションです

    その道のプロフェッショナル達がエクストリームだと思うこと/どうはじめるか困っていることを平気で突破していった彼らから学ばせていただきたいなと思い、今私はプロポーザルを書いています。

    もちろん彼らはプロダクトを本番リリースしたわけではありません。
    もちろん彼らは運用しながらお金を稼いでいるわけではありません。
    でも彼らはプロダクトづくりの経験をもっていませんでした。
    でも彼らはプログラミング経験ももっていませんでした。

    このセッションは、そろそろ言い訳するのはやめてもっとうまくなるためにはどうすればいいのかを真剣に考えます。経験でもないスキルでもない我々に不足しているかもしれない何かを、彼らから学ばせていただきましょう。

    このセッションでは実際に研修を受けた新卒の彼らに、彼らの言葉で話をしてもらいます。

  • Liked Iwao Harada
    keyboard_arrow_down

    Iwao Harada / Masataka Mizuno / Takao Kimura - 大規模なアジャイル開発挑戦へ最初の一歩! ~SAFeとLeSSから学ぶ勘所~

    45 Mins
    Thought & Practice
    Beginner

    というか、普通に複数Scrumチームになっただけで難易度hardですよね…?
    チームがScaleするだけで難しくなる現実は何が問題なのでしょうか?

    大規模なアジャイルの難しさ

    「大規模アジャイルってどうやったらいいの?」

    大規模≒Enterpriseという認識で大規模開発にアジャイル開発を始めても多くの人が失敗しています。もしくは、そのような不安から大規模開発に踏み切れない人の相談を多く聞いています。
    現場のマネージャ、チームのリーダー、その中で働くメンバーたち…悩みは、それぞれです。

    私たちには何が足りなかったのでしょうか。

    大規模アジャイル開発で気を付けること

    「大規模アジャイル開発で、まず何をしたらいい?」

    そんな疑問を大規模アジャイルの開発手法であるSAFeLeSSから良いポイントを抜き出し、考えるべき重要なポイントを紹介したいと思います。

    お話しするのは、実際にSAFeと LeSSの研修を受けてみて気が付いた事です。

    二つの手法が大規模なアジャイル開発で“大切にしている”ことを中心に、単なる手法の比較ではなく、それぞれの良いポイントを挙げたいと思います。

    それは皆さんが「大規模なアジャイル開発」に関わる時、失敗しないように考えなければならないポイントに他ならないです!

    大規模は難しいと敬遠されていた方や、これから挑戦しようとしているが不安を感じている方、実際に自己流で大規模開発しているが上手くいっていない方に参考になるはずです。

    参考

    SAFe 日本語サイト
    http://jp4.scaledagileframework.com/

    LeSS 日本語サイト
    https://less.works/jp/

    大規模アジャイル開発手法の全体像

    ■SAFe4.5(英語版のみ。日本語サイトは4.0)
    ■LeSS
  • Liked Arnab Gupta
    keyboard_arrow_down

    Arnab Gupta - 文化を超えたアジャイル:日本とフィリピンの事例 / Agile across Cultures: The Cases of Japan and the Philippines

    20 Mins
    Thought & Practice
    Beginner

    アジャイルはなぜ特定の文化の中で急速に普及しているのでしょうか?
    スクラムのようなツールを実装しやすくするための社会文化およびビジネス上の規範とは何でしょうか?ここ数年、私は日本とフィリピンを行き来して仕事をしており、両国のアジャイル・コミュニティーにも没頭し、様々なアジャイルの形を見てきました。

    この講演では、ホフステード(Hofstede)の文化次元論やエリン・メイヤー(Erin Meyer)のカルチャーマップといったよく知られた文化モデルを用い、2国間の比較の観点とそこから得た考察をいくつかお伝えいたします。

    最終的に私たちは皆、お互いの成功と失敗から学び、探究します。
    文化的な特徴にはどのような長所と短所があるのかを知ることは、今後、海外でのビジネス展開や多国間で仕事をする上で非常に重要となります。
    日本のみならず、関連企業や顧客への提案として、将来アジャイルの導入を検討されている方へも新しい視点やヒントが見つかるでしょう。

    Why is Agile spreading so fast in certain cultures and not in others? What are the sociocultural and business norms that make the tools, like Scrum, easier to implement?
    I spent the last couple of years simultaneously immersed in the Agile communities of two countries: Japan and the Philippines.

    In this talk, I share some of the insights I derived from this comparative view and applying well-known cultural models, such as Hofstede's cultural dimension theory and Erin Meyer's Culture Map. Ultimately we all search to learn from each other's success and failures. It's helpful to know what advantages and disadvantages our cultural baggage bring with them.

  • Liked Daisuke Kasuya
    keyboard_arrow_down

    Daisuke Kasuya - 魂の1on1 100連発

    20 Mins
    1st Step Case Study
    Beginner

    チームをマネジメントしていくにあたって、メンバーとのコミュニケーションは欠かせません。マネージャとして、メンバーと親密になりたい、しかし、このご時世では飲みニケーションなんて言ってられない。

    そこでぼくは今年、これまで以上に1on1に力を入れる取り組みにチャレンジしてみました。

    1on1とは、会議とは違った業務を離れた気軽な対話の場です。30分ほどのマンツーマンの対話を繰り返し行うことで、お互いのことをよく知り、業務の内外のさまざまなことについて気軽に相談できる場の構築を目指します。メンバーから、仕事についてぼくにさまざまな相談をしてほしい。ぼくは、メンバーがリラックスして仕事をするにはどうすればいいか、彼らがどう成長したいかを知りたい。そういったことをお互いで探っていく場です。

    魂を込めて挑む1on1チャレンジ。

    どんなメリットがあって、どんなデメリットがあるか。うまくいく工夫や、うまくいなかったパターンなど、そのすべてをお話します。