悩めるManagerたちがお互いの皿回しっぷりを共有してスッキリする会

現場でScrum MasterやProduct Ownerとしてバリバリやってて、昇進してManagerとか課長とかに(望む望まないにかかわらず)なったという方、多いんじゃないでしょうか。私もそのクチなんですが、Managerになってからというもの、何もうまくいった覚えがなくて、苦しいです。いろいろ本を読んだり実践したりもしてみてますが・・・毎日悩んでいます。

そんな折、「エンジニアのためのマネジメントキャリアパス ――テックリードからCTOまでマネジメントスキル向上ガイド」が発刊されました。

https://www.oreilly.co.jp/books/9784873118482/

貪るように読みました。

特にこの一節に非常な共感を覚えました。

部長レベル以上の管理職が味わっている感覚を表現するとしたら、「皿回し」が最適です。回転速度が一定レベル以下に落ちた皿は棒から落ちてしまうため、どの皿にも注意を払っていなければなりません。こうした皿回しの「皿」が、技術部長であるあなたにとっては監督対象である部下たちでありプロジェクトであって、どのタイミングでどの部下なりプロジェウトなりにどの程度注意を払うかを見定めるのがあなたの務めです。

なんという言い得て妙感!!なんだ、みんなそうなんだ!!と思いました。
社内で「この本を語る会とかやりたいね」とかって話をしていたりしたので、どうせならRSGTにProposal出しちゃってもいいかなーと思い、筆をとっております。

悩めるManagerたちと悩みを共有し、一緒にうまいビールを飲みたいです。

 
 

Outline/Structure of the Workshop

以下のような進め方をしようと思ってます。ワールドカフェ形式っぽい感じです。

http://world-cafe.net/about/

  • なんでこのセッションをやりたいと思ったかの共有・進め方の説明(10分)
  • テーブルごとにディスカッション(15分×3回)
  • Show and tell(残り時間)

ワールドカフェで全体共有を前提にするのって良くないって言われるかもしれないんですが、きっとRSGTに来てる人たちはこのへんの空気感は分かってくれるはず!!せっかくのディスカッション結果なので、みんなで共有したいなと。

「こういう進め方の方がよくない?」ってのがあれば是非教えてほしいです。

Learning Outcome

  • Managerとして、似た悩みを持った仲間を作れる
  • Managerとして、悩みの解決のヒントを見つけられる
  • メンバーとして、Managerってこんな事で悩むんだーってのを知ることができ、自分がManagerになった時に備えることが出来る

Target Audience

部下を持ってて管理職っぽい事をやってる方/Manager・Senior Manager・General Managerなど、肩書関係なし/Managerや管理職に対して言いたい事がある方

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 Yusuke Amano
    keyboard_arrow_down

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

    45 Mins
    Thought & Practice
    Intermediate

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

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

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

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

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

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

  • 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 SATORU KAWABUCHI
    keyboard_arrow_down

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

    20 Mins
    1st Step Case Study
    Beginner

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

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

  • 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 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 Takahiro Futagawa
    keyboard_arrow_down

    Takahiro Futagawa - スクラムチームを辞めて20人でカンバン運用してきた半年間の軌跡

    20 Mins
    Advanced Case Study
    Intermediate

    Pairsを運用する株式会社エウレカでは2018年4月から、それまでの目的別スクラムチーム組織を変更し事業部全体でリアルカンバンを用いたプロダクトバックログの優先順位を忠実に消化できるチーム体制へ変更しました。

    このセッションでは4月から今までのリアルカンバン運用の軌跡についてお話しながら、つらみやうまく行ったこと、今後の展望などをご紹介したいと思います。

  • 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 Mitsuyuki Shiiba
    keyboard_arrow_down

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

    20 Mins
    Advanced Case Study
    Intermediate

    こんにちは。椎葉です。

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

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

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

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

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

  • Liked Yuichiro Yamamoto
    keyboard_arrow_down

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

    20 Mins
    Advanced Case Study
    Intermediate

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

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

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

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

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

  • Liked Atsuko Tsujioka
    keyboard_arrow_down

    Atsuko Tsujioka - リーダーシップを一度捨ててチームの輪の中に置いた話

    Atsuko Tsujioka
    Atsuko Tsujioka
    Engineer
    SMS Career,inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    株式会社エス・エム・エスキャリアの辻岡です。

    弊社は人材紹介事業を主に、医療介護通じて働く人と日本を元気にする会社です。

    私は社内の人材紹介エージェント(キャリアパートナー)が利用する業務システムの開発を主に担当しています。2年半前に弊社に転職しました。

    入社当初配属された部署には以下の課題がありました。

    • 現状の課題をあきらめがち
    • 全員目の前の火消しや依頼に対応するのが精一杯
    • 正社員が誰も実装してない。一切ソースコード見てない
    • 開発計画の正否の考え方が短期目線なものばかり
    • 社員数 << 他の会社から来てくれる人数。→人の管理者状態。
    • リリースしてもトラブルがあっても殆どキャリアパートナーに連絡しない

    etc…

    YAMAZUMI(山積み)

    ある日1つのチームを持つことになりました。

    彼らにアジャイル手法を伝え続けてチームの輪が出来始めた頃。

    私は一人で抱えたチームのリーダーシップを一度捨てました。

    そしてそれをチームの輪の中に置きました。

    リーダーシップを一度捨てることで全員がオーナーシップを持って課題を乗り越えていくチームができた事例を紹介したいと思います。

    発表スライドはこちら

    https://www.slideshare.net/AtsukoTsujioka/rsgt2019-127663850

  • Liked Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / Haruna Iizuka / Masahiko Morita / Megumi Tsuchihashi / Ryota Nagatomo / Saki Ota / Saki Tanaka / Takuya Uchida / Tsubasa Kanemura / Yuki Misumi - 学習する/Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー

    45 Mins
    Thought & Practice
    Intermediate

    チームがうまくなるために、「学習」と向き合うことはとても大切です。
    私がこれまで関わってきたチームでも、アジャイル開発を通してチームがうまくなることに取り組み続けてきました。

    ところが、最近新卒向けの研修に携わった際に衝撃を受けました。

    ビジネス採用として入社したためプログラミング未経験だった新卒の彼らは、当初は黒い画面(ターミナル)すら怖がっていましたが、数カ月後にはメンター陣からのインプットを頼りに、

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

    などをまわしながら、3週間でプロダクトを作れるようになっていました。
    その道のプロフェッショナル達がエクストリームだと思うこと/どうはじめたらいいのか悩んでいることを平気で突破してしまったのです。

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

    私達は、

    • 学習し続けていく中で固定観念に囚われてしまうことがあること
    • 学習をしていないことが圧倒的成長スピードを生むことがあること

    という事実に向き合う必要があります。

    学習を積み重ねていくことで成長スピードが落ちてしまうのではなく、学習を積み重ねていっても成長スピードを落とさないチームをどうつくるか。そのためにはUnlearn(学びをリセット)がキーになります。

    このセッションでは、そろそろ言い訳するのはやめてもっとうまくなるためにはどうすればいいのかを真剣に考えます。もっとうまくなるための学習する/Unlearnするチームについて一緒に考える時間にしましょう。