クライアントにアジャイル開発を提案しようと思ったら

最近は日本でもアジャイル開発が広がりを見せ、クライアントにアジャイル開発を提案したり、逆にアジャイル開発を求められることも増えてきていることと思います。一方で、アジャイルコーチの仕事をしていると、プロジェクトやプロダクトの条件によっては効果的なアジャイル開発が出来ないという事例にもよく出くわします。

これらは案件提案時の工夫やアセスメントによって避けられるものも実は多いのですが、そういった情報はリーチしづらいことが多く、そのため「教科書通りにやっているのに上手くいかない」という状況を生み出しています。

本セッションでは、アジャイル開発の提案から開始までの進め方について、陥りやすいピットフォールの事例をあげながら説明していきます。

 
 

Outline/Structure of the 1st Step Case Study

事例をひとつずつ挙げながら、原因や対策を論じていきます(予定)。

Learning Outcome

アジャイル開発案件の提案時におけるプロダクト・プロジェクトのアセスメント、体制づくりや契約の方法について学べます。

Target Audience

これからクライアントにアジャイル開発を提案しようとしているチーム・営業職、これからSIerにアジャイル開発を依頼しようとしているユーザー企業のIT部門担当者、これからアジャイル開発に転換しようとしている事業会社の開発部長、など

schedule Submitted 1 year ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - ファシリテーションの難しさと楽しさ

    20 Mins
    Thought & Practice
    Beginner

    ScrumでもXPでもアジャイルなやり方でプロダクト開発をしていく上で”会話”は大事になってきます。

    そのような会話は1対1に限らず、チーム全員、チームとステークホルダーのような複数人である会話することもあります。
    そのような場には様々なコンテキスト、利害関係を持った人々が集まることもあり、何もしないで良い結果を得るのが難しい場合もあります。

    その場の質を高めるスキルの1つがこのセッションのテーマである”ファシリテーション”です。


    ファシリテーションとは、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の1つ。日常での組織コミュニケーション全般において、ファシリテーション技術は活用される。 (Wikipediaより抜粋)


    このセッションでは、スクラムマスターにとって必要なスキルの1つでもあるファシリテーションの難しさや楽しさを、現場コーチとして20以上の現場を支援してきた知見を交えてお話します。

  • Liked Narichika Kajihara
    keyboard_arrow_down

    Narichika Kajihara - エンジニア採用もカンバン使ってみたら、「透明性」によって採用が活動が変わったこと / Agile Recruiting

    Narichika Kajihara
    Narichika Kajihara
    Agile Coach
    Yappli,Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Advanced Case Study
    Advanced

    「スクラム」のフレームワークは、もともとソフトウェア開発に用いられてきました。しかし「スクラム」の経験主義の原則は、短いイテレーションの中で、検査と適用を繰り返すことでプロセスのカイゼンを加速させる事ができます。また透明性の原則によって、ステークホルダーへの説明責任、今何が問題になっているのかを見える化させることができます。

    その「アジャイル」フレームワークを「エンジニア採用活動」に適用してみた内容について、発表させていただきたいと考えています。
    トラディッショナルな採用活動は秘密主義に根ざしており、独自な文化が根強く残っています。その中で透明性をもったプロジェクト運営をすることで、「採用活動の変化」「ステークホルダーの意識の変化」、検査と適用を繰り返すことでプロセスのカイゼン速度が向上した。

    開発部門以外にも適用した事例について、お話させていただきたいと思います。

  • Liked Shigeki Morizane
    keyboard_arrow_down

    Shigeki Morizane - 全部SCRUM!~SIerで大切だったもの、サービサーで大切だったもの~

    Shigeki Morizane
    Shigeki Morizane
    CTO
    Levtech Co., Ltd.
    schedule 1 year ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    2018年、15年勤めた富士通、NRIというSIerを辞め、Leveragesというベンチャーのサービサーに移籍しました。

    これまで、SIerやそのお客様先でSCRUMの導入を支援してきましたが、実際のWeb系のサービサーでのSCRUMはまったく毛色の違ったものでした。

    でも、どちらもSCRUM!全部SCRUM!

    規模や価値観やビジネスモデルによるSCRUMの取り入れ方の差を身体で感じ取った話しをします。

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - 超Scrum入門〜未完成フラクタルと15minSprint〜

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 1 year ago
    Sold Out!
    45 Mins
    Thought & Practice
    Advanced

    https://www.youtube.com/watch?v=7xhxIYYMmTc

    チームがうまくいっていることはスクラムチームの大きな目標です。

    いくつかのスクラムチームに関わってきた立場から、良いチームになるための1つの大きなアプローチを見つけました。私が関わってきたチームでは、最初から1DaySprintをやりつづけています。また、1 Hourのタイムボックスを持つチームもあります。またそれらはたった数日で成されます。

    良いチーム、美しいチームとはスクラムという視点だけにはとどまりません。あるチームでは、15minSprint、1hourSprint、1DaySprint、1WeekSprint、1MonthSprintを構成したフラクタルなスクラムを実践しています。

    数万年に渡る生物の美しさ、クリストファー・アレグザンダーが発見してきた美しさ、といった視点からスクラムやチーム、そして理想像を整理します。

  • Liked Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori - Effective Retrospective / とにかく楽しいふりかえり

    45 Mins
    Thought & Practice
    Beginner

    みなさんは楽しくふりかえりをできていますか?

    スクラムでは「レトロスペクティブ」というイベントとして、チームの活動の一環として定義されている「ふりかえり」。色々なチームの話を聞いていくなかで、ふりかえりがなかなかうまくいかない、というチームが多いという現状が見えてきました。

    マンネリ化してしまったり、ふりかえりがスキップされてしまったり、アイデアがなかなか出てこなかったり。そんな状態から脱却するためには、まずは「場」を作ることが大事だと考えています。

    場とは、心理的・物理的なさまざまな側面からなる流動的に変わっていく生き物のようなものです。この場を参加者全員の力でよい方向に形成することで、チームがより高く成長するためのアイデアが出やすくなります。

    場とは何か。そして、場を作るためにどんなことをすればよいのか。また、ふりかえりを楽しくするためのやり方にもフォーカスを当てて、「ふりかえり」全般についてお話できたらいいな、と考えています。

    以下のことを中心にお話いたします。

    • ふりかえりの3つの目的と3ステップ
    • ふりかえりにおける「場」とは
    • 物理的・心理的に場を作るための方法
    • ふりかえりをより楽しくするための方法
    • ふりかえりのさまざまな手法
  • 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 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 Takahiro Kaihara
    keyboard_arrow_down

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

    120 Mins
    Workshop
    Beginner

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

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

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

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

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

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

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

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

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

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

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

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

  • Liked Masayuki Tanaka
    keyboard_arrow_down

    Masayuki Tanaka / Ryoichi Nagadome / Takayuki Ono - 東名阪をまたいだLeSS Huge(大規模スクラム)においてスクラムマスターとして実践したこと

    20 Mins
    Advanced Case Study
    Advanced
    Yahoo! MAP、Yahoo! カーナビ等を開発する私たちが所属する事業部では大規模スクラム(LeSS Huge)を導入し1年が経ちました。
    10チームを超えるLeSS Hugeにおいて東京、名古屋、大阪それぞれの拠点のスクラムマスターからLeSS Huge立ち上げ期〜現在まで実践してきたことをお話しします。


    「LeSS Hugeの立ち上げはスムーズにいった?」
    「拠点が離れているのにスプリントレビューはどうやっているの?」
    「他拠点とのオーバーオールリファインメントなどのセレモニーは問題なく実施できる?」


    1年の取り組みを振り返りつつ、直面した課題と解決のためにとったアクションをお話ししたいと思います。
  • Liked Mitsuyuki Shiiba
    keyboard_arrow_down

    Mitsuyuki Shiiba - ちゃんとやってるのになんかうまくいかないスクラムからの脱出

    20 Mins
    Advanced Case Study
    Intermediate

    こんにちは。椎葉です。

    僕は楽天でWebアプリケーションエンジニアとして働いています。数年前に「エンジニアとして色んなチームを内側からサポートしたい!」と考えて「改善グループ」というグループを立ち上げました。そして、様々なチームの中に入っていって、一緒にコードを書いたり、テストを書いたりして楽しんでいます。

    そんな風にエンジニアとして動くことを中心にしてはいるのですが、実は毎回最初にやるのはチームの開発プロセスを一緒に改善することなんです。というのも、エンジニアとして動くための土台としての開発プロセスが、とても重要だからです。

    僕の所属しているECインキュベーション開発部では、どのチームもスクラムで開発をしているのですが、この活動の中でよく聞いたのは「スクラムをやってはいるのだけど、何かうまくいかない」ということです。

    このセッションでは「スクラムが何かうまくいかない」と感じているチームに実際にどのような課題があったのか、その原因は何だったのか、そしてそれをどのように改善したのか、を失敗談も交えながらお伝えしたいなと思います。

    同じような課題を感じている方が一歩踏み出すきっかけになるといいなと思います。そして、セッションの後にはみなさんと「うちもこういうことがあるよー・あったよー」みたいな話をできたら嬉しいです!

  • Liked Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi / Manabu Shibahashi / Yumiko Yoshida - 喧嘩できるチームを作るワークショップ

    100 Mins
    Workshop
    Advanced

    「チームのメンバーで喧嘩できてますか?」

    自分が言いたいことが相手の意見と対立しそうで、伝えなかった…。
    言ってもわかってもらえないと思ったので言わなかった…。
    このチームでは余計なことをすると指摘されそうで面倒臭いのでやらなかった…。
    そんな体験はないでしょうか?

    自分の伝えたい考えをきちんと伝える。相手が伝えたい考えときちんと向き合う。
    これはチーム内での会話の仕方でもありますが、チームの空気感というか文化からも影響を受けると考えます。

    「喧嘩できる」というのは対立構造ということではなく「喧嘩ができる」チームの空気感があるというある意味「健全なコミュニケーション」が行える状態についてお伝えしたいと思います。

    その改善として、このワークでは組織や文化の理論もお話ししながら、学びと体験をお届けします。

    2018/10/19
    同ワークショップを企業で実施した時の記事が公開されました。

    http://bit.ly/2OCzYA9

    ワークショップを作る時に描いた図

  • 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 Harada Kiro
    keyboard_arrow_down

    Harada Kiro - Scrum@Scale Guide を読んでみよう

    Harada Kiro
    Harada Kiro
    CEO and Agile Coach
    Attractor Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    Scrum@Scale Guide を読んでみましょう(RSGT2019までには日本語版が出ているはず)。

  • Liked Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling / Ikuo Suyama - Fail fast, learn fast - Celebration Grid:組織を変えるプラクティス [Management 3.0体験ワークショップ]

    45 Mins
    Thought & Practice
    Intermediate

    Celebration Grid

    失敗から学ぶことは、ビジネスにおいて重要なテーマであることは疑いようがありません。

    企業、組織、およびチームは、すばやく失敗し、失敗から学ぶことで、複雑な環境に適応しなければなりません。
    あなたの組織では、失敗を祝福していますか?
    成功したことのみを祝い、多くのことを学べる失敗をないがしろにしてはいませんか?
    それでは、すべての失敗を祝う必要があるのでしょうか?あるいは、両方を祝うのでしょうか?
    "セレブレーション・グリッド" によって、成功や失敗ではなく、 "学習したこと" を祝福しましょう。
    このセッションでは、"セレブレーション・グリッド" を実際に作成していただき、失敗を祝う方法や、学びを得るための実験をマネジメントする方法をお伝えします。

    Management 3.0

    Management 3.0 は、オランダ出身のヨーガン・アペロ(Jurgen Appelo)が作ったアジャイルリーダーシップ概念です。
    「人ではなく、システムをマネージするべき」というアイディアに基づいています。
    Celebration Grid は、Management3.0の中でもAppelo氏が「最も重要なもの」と位置づけるプラクティスです。

    CyberAgent AdTech Studioでの事例紹介

    CyberAgent ではこれまで2度ステファン氏によるManagement3.0社内研修を実施しており、20名以上の参加者が1年以上にわたり Management3.0 の取り組みを続けています。
    今回はその中でも「セレブレーショングリッド」のプラクティスを社内でどのように運用し、どのような成果が得られたのかを、成功と失敗の事例を交えてお話します。
  • Liked KazuhideInano
    keyboard_arrow_down

    KazuhideInano / Yoh Nakamura - 受託開発だったりロケーション離れてたりなど課題たくさんの中で支援している現場の話

    20 Mins
    1st Step Case Study
    Beginner

    「もっとビジネスのスピードを上げたい」という課題意識があり、それの解決方法として「今までのやり方のままでは難しい。だからアジャイル開発手法を導入したい」と考える企業は多いです。

    とはいえ「さあ始めよう」とするにしても、関わる人のマインドや協力会社との関係性、とりまく環境などなど変えて行かなければならないことがたくさんある場合が多く、実際のところそれがなかなか大変だったりします。人も組織もなかなか急には変われないものですよねぇ。

    よく直面しがちな課題の例を挙げてみると...

    • 受託開発でPOが発注側、DevチームとSMが受注側という関係性
    • 復数Devチームだがコンポーネントチーム
    • Devチームが個の集団
    • 複数POが織りなす複雑なビジョン
    • 得られた成果やアジリティが見えない
    • POとDevチーム、SMのロケーションが別
    • コミュニケーションしづらい座席レイアウト

    などなど。

    さて、このセッションではこのような課題を抱えつつもスクラムの実践に取り組み奮闘している現場のひとつをケーススタディとして、実際にどんな課題があり、スクラムチームやコーチがどのように取り組み解決を試みたのかの成功談や失敗談をみなさんの参考になるべく紹介したいと思います。

  • 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 Fumitaka Inayama
    keyboard_arrow_down

    Fumitaka Inayama - いっけなーい✏️✏️『とにかく明るいリーダーシップスタイル簡易診断ワークショップ!』あなたの『リーダーシップ・スタイル』はリーダ?マネジャー?サーバントリーダ ?のどのタイプ❣️

    Fumitaka Inayama
    Fumitaka Inayama
    PMP
     
    schedule 1 year ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    <ようこそ>

    1)『リーダーシップ・スタイル簡易診断』の進め方の説明(5分)

    2)自分が信じているリーダーシップスタイルをチェック(3分)

    3)『リーダーシップ・スタイル簡易診断』もパパッとチェーック!(5分)

    4)信じていたリーダーシップスタイルと簡易診断結果を比較と周りと共有(7分)

    <参加ありがとう>