チームでふりかえりをする中で「うまくいった場面」の共通点 ~産業カウンセラーの視点から~

私自身はソフトウェア開発に携わっているわけではありませんが、自社サービスのひとつとして「ふりかえりの支援」をしています。

このセッションは、チームで「ふりかえり」や「ミーティング」をする時に

  • 表面的な話しか出ないんだよなぁ...
  • ○○するべき!とか、なんだか他人事な感じなのよね...
  • みんなで話している感じが持てないんだよね...
  • 自分たちのチームの心理的安全性は低いなぁ...

といった、なんだか残念な感じになってしまう場面に対して、なんとかできないか...と試行錯誤をしている方が対象です。

ふりかえりやミーティングの「進め方の」コツではなく、「場のつくり方」といった内容について、私自身の経験から解説します。

 
 

Outline/Structure of the Talk

  • うまくいかない時って、どんな時?
  • チームで話す時「一番最初」に必要なこと
  • 関連情報の紹介(森田療法・NVC・ナラティヴアプローチ)

Learning Outcome

チームで対話の場について

  • 観察するための視点を得られます
  • 表面的な会話になっていたり心理的安全が低い場に対して、どのように関わっていくことができるか?のヒントが得られます

Target Audience

チームで話す場をより良いものにしたいと考えている人

schedule Submitted 3 months ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - チームの再定義 -進化論とアジャイル-

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    チームの再定義 -フラクタルスプリントとフラクタルチーム-

    1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?

    私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。

    異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。

    そしてこれらを支える理論として進化心理学、ダーウィンの進化論などの学術的な視座からアジャイル開発を話します。なぜ人間はチームをつくるのか。

  • Liked Woohyeok Aaron Kim
    keyboard_arrow_down

    Woohyeok Aaron Kim - 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方

    45 Mins
    Talk
    Intermediate

     アジャイルでの大物でありScrumを考案して世界に広げた人物。ジェフ・サザーランド氏は実は、米国陸軍士官学校を卒業した元パイロットです。

    軍隊は一番入れ替わりが激しい組織です。今日入隊する人がいて、その反面退役する人もいます。退役の方が入隊より多く、総員の数がマイナスになることもあります。入れ替わる時の階級もバラバラで、一般兵士が入隊してきても、例えばベテラン士官が退役する場合もあります。

     しかし、こういう状況の中でも、全てのメンバーを即戦力に作る極限のアジリティーを発揮し、最高のパフォーマンスを保つのが軍隊の最大課題であり、存在理由でもあります。私はそこで元陸軍将校として4年間勤め、300名の部下を纏めながら、毎日戦闘力の向上のために資源管理・訓練の計画・実施などに力を入れていました。

     チーム(ないしは会社)そしてアジャイルプロセスは、軍隊と特に違いはありません。入れ替わりは激しく、生産性のために中途はもちろん新卒に対しても即戦力になれる人材を求めています。チームなど組織に対しても、一定のパフォーマンスを出すことが求められています。

    制限された状況の中でも、どうしたら常に最大のパフォーマンスが発揮できるか。

    軍隊ではどういう風にしていて、それをどうやって今のチーム・組織に活かせるか。私の経験を持ってご提案させていただきます。

  • Liked Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling / Yasuyuki Kashima - リーン・チェンジマネジメント - チーム・組織に変化を起こす!オリジナルのチェンジ・フレームワークを構築する方法

    100 Mins
    Workshop
    Intermediate
    • 組織にアジャイルを導入するこに関わっていますか?
    • 変化(変革)をスタートするときに押さえておくべきポイントとは?
    • 変化(変革)に対する「人」と「要因」の適切な対応と考え方
    • 変化(変革)を「見える化」する
    • 全員で同じ方向に向かっていくために必要なこと

    あなたが組織の変化・変革に関わり、チェンジ・プログラムを開発、実行するためのより効果的な方法を探しているのであれば、リーン・チェンジエージェントになりましょう!リーン・チェンジエージェントとして、あなた自身のチェンジ・フレームワークを構築する方法や、変化の影響を受けるステークホルダーからどう支持してもらえるかを様々な視点から考え学びます。

    このセッションでは前半にManagement 3.0の「Change Management(チェンジマネジメント・ゲーム)」を行う予定です。後半はグループでチェンジ・キャンバスを作成します。ディスカッションを通して変化(変革)への戦略を考えていきます。キャンバスから見えてくる変化(変革)への課題とどう向き合い実践していくかを学び、リーン・チェンジマネジメントを体験してください。

  • Liked Takuo Doi
    keyboard_arrow_down

    Takuo Doi - モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education

    Takuo Doi
    Takuo Doi
    CTO
    Lifematics Inc.
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    現在,大学でプログラミング言語の授業を持っています.

    その授業では,文法としてのプログラミングだけでなく,プログラミングの面白さを知ってもらえるもらえるように,モブプログラミングを導入して授業を行なっています.

    ところが,企業でのモブプログラミングの導入とはまた違った課題がありました.そして,その解決策として,行動分析学を元にして,試行錯誤をしています.

    本セッションでは,その試行錯誤の課程を共有したいと思っています.

    ----

    I have a C programing course at university.

    I introduced Mob Programing technique to my class so that my student learn not only the grammar of the programing language but also the fun of programing.

    I have an experience to introduce Mob Programing to the work in our company. However I faced different problems. And Now I am trying to solve the problem using Behavior Analysis.

    I will share this experiences in my session.

  • Liked Matteo Carella
    keyboard_arrow_down

    Matteo Carella - Leadership as capability for Scrum Teams

    Matteo Carella
    Matteo Carella
    Agile Coach
    Agile42
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Nowadays the world of work is very dynamic and volatile. In this scenario Leaders should be able to lead by example, suggest improvements, catalyze change and show courage to improve experimentally: a context in which teams can perform. But in order to achieve this, leadership should be a team capability not only an exclusive trait of the Leaders. Growing that capability of leadership (for example within a Scrum team) requires building it into the organization structure and culture. In this talk we'll explore different leadership behaviours through archetypes and how we can (as Scrum Masters or Team Coaches) shift behavioural patterns from an archetype to another through an evolutionary journey of an high performing team from their early stage of development to maturity.

  • Liked Yusuke Shiokawa
    keyboard_arrow_down

    Yusuke Shiokawa - 我々のゴールは何ですか? ~様々なステークホルダーとどのように共通ゴールを設定するか~

    20 Mins
    Talk
    Beginner

    AgileやScrumを問わず、組織やチームで仕事を進めていく上ためにはゴールの共通認識は重要な要素となります。
    一方で、ビジネスの現場では企画部門や開発部門、営業部門、品質管理部門など様々な立場の人が関わるため共通のゴールを設定することは容易ではありません。
    その結果、Scrumチームが目標を見失ってしまい、本来集中するべき価値に集中できていない場面を見かけることがあります。

    このセッションでは立場の異なるステークホルダーが多数存在するプロジェクトにおいて、共通のゴールを合意するためのSuccessFactorsワークショップをご紹介します。

    さらに、このワークショップの価値を最大限に高めるためのポイントを事例を交えてお伝えします。

  • Liked Yoshihiro Yunomae
    keyboard_arrow_down

    Yoshihiro Yunomae / Ken Takayanagi - 良いチーム構成のための図解思考法お試しワークショップ

    100 Mins
    Workshop
    Intermediate
    良いプロダクトを作るためには、良いチームが必要です。
    良いチームになるためには、組織として適切なチームをデザインできていることがポイントです。
    これは、スクラムをやるためにスクラムチームを作るのではなく、今所属しているメンバーを見て、最良のプロダクトを届けるためのチームをデザインするということです。
    このためには、プロダクトの性質、メンバーのスキル、デプロイ頻度、開発拠点、文化など、様々な観点を考慮しなければいけません。
     
    しかし、これら観点が全てベストな状態であるチームを構成出来ることはまれで、ほとんどの場合、何かしらのトレードオフを受け入れながら構成していかなければなりません。
    例えば開発拠点が2つにまたがっているとき、拠点ごとにチームを作るのは良くあるやり方ですが、機能を実装するのに1つの拠点では完結しない場合はこのやり方がベストとは限りません。例えば、拠点をまたいでチームを作る、という方法もあります。しかし、この場合はコミュニケーションコストが上がるのでそれを下げるような制度や設備があるかどうかを考慮する必要があります。
     
    今回のワークショップでは、実際にこのトレードオフの関係にある項目を洗い出しながら、現在のチーム構成がどうなっているかを可視化していきます。
    さらに、より良いチーム構成の形を検討し、その構成のために今何が足りていないのか、どうすれば実現出来るかを考えていただきます。
  • Liked Iwao Harada
    keyboard_arrow_down

    Iwao Harada / Masataka Mizuno / Takao Kimura - アジャイルコーチから見たScaled Agile Method.. ~SAFe and LeSSから学ぶ勘所~

    45 Mins
    Talk
    Advanced

    1チームがそれなりに成果出すにはかなりの努力が必要です。

    ましてや、普通に複数Scrumチーム難易度hardですよね…?
    チームがScaleするには、どんな現実の「制約」が問題なのでしょうか?

    より上の、より先のチームや開発を目指したい方にSAFeとLeSSから学んだことを伝えます。

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

    「大規模アジャイルってどんなものなの?」

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

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

    smile大規模アジャイルのエッセンスを絞って、「これだけ」分かって欲しいことをお伝えします。

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

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

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

    お話しするのは、実際にSAFeと LeSSを学習したり、実際に体験して気が付いた事です。
    単なる手法の比較ではなく、それぞれの良いポイントを挙げたいと思います。

    smile二つの手法から分かる、大規模なアジャイル開発でおさえておくべき“大切にしている”ことを話します。

    アジャイルコーチから見た大規模アジャイル

    「大規模アジャイルって、実際どうよ?」

    研修や本からは読み取れない大規模アジャイル開発手法に見えた「秘訣」があります。
    例えば、大規模アジャイル手法には、1チームのScrumでも使える良い考え方やプラクティスが実際、あります。

    smile普段のアジャイル開発に役立つ考え方やプラクティスを伝えます。

    参考

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

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

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

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

    Tomonori Sano / Aiki Hirosato - Podスクラムという働き方

    Tomonori Sano
    Tomonori Sano
    Manager
    KDDI
    Aiki Hirosato
    Aiki Hirosato
    -
    -
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    KDDI DIGITAL GATE(KDG)は主にお客さま企業のDX(Digital Transformation)を支援する組織です。

    案件の長さは1週間〜1ヶ月ほどの短期が大半です。解決する課題とその解決策、採用する技術が開発開始の前日に決まるという状況もよくあります。

    このような状況下では、広範囲に渡ってお客さまの要望に迅速に答えられる小さなクロスファンクショナルなチームが必要となります。

    また技術分野においても、クラウドに代表される技術革新の速さに常に追随し続けなければなりません。

    短期でお客さまの課題を解決する事と最新技術に追随する事。

    これを両立するために考えたPodという体制や仕事の進め方をご紹介します。

    RSGT2019がきっかけでKDGにジョインしてくれた相木と一緒にKDGの体制や働き方をお話させていただきます。

  • Liked Takahiro Kaihara
    keyboard_arrow_down

    Takahiro Kaihara / Ken Takayanagi - わかりあえないことから ~「あいつら」とどう向き合うのか ~

    20 Mins
    Talk
    Beginner

    目を閉じて思い浮かべてみてください。

    あなたには、「意見が合わない」「考え方が理解できない」「思い出すだけで腹が立つ!」「できることなら話したくない!」

    そんな「あいつ」はいませんか?

    プライベートであれば、その「あいつ」から、そっと離れればよいですが、取引先の担当や上司、隣の席の人がそうだったりすると簡単に離れる訳にはいかないでしょう。

    そんな時、わたしたちは毎日、息苦しい思いをして仕事を続けないといけないのでしょうか。

    居心地の悪いこの場所を離れる決意をし、転職したほうが良いのでしょうか。


    「あいつ」はいつか、考え方を変えてくれるのでしょうか?



    わたしたちが大事にしているスクラムやアジャイルの「価値観」は、世の中的にはまだ当たり前の「価値観」ではありません。
    (みなさんはそれをもうすでに知っているか経験をしていると思います)

    RSGTはとても居心地のいい場所です。でも一歩、RSGTから離れたらどうでしょうか。
    越境しようとする境界にいる人ほど「価値観」との衝突は避けることができないのではないでしょうか。

    このプロポーザルでは、そんな時に私たちはどういう選択肢があるのかを皆さんとともに考えてみたいと思います。
    (RSGTにとっても皆さんにとっても有意義な時間となるよう努めます)

    発表は、いつもつらい感じの発表をしている開原さんと、そんな人を支援するダイアログファシリテーターの高柳さんでお届けします。

    ■発表の流れ

    1.「社内のあいつら」開原ライトニングトーク(5 min)

    「ルール1:クソ野郎には近づくな」

    昔読んだ、エンジニア向けの本の「ルール1」にはそう書かれていました。
    私は教えを守りクソ野郎とはなるべく距離をとって生きてきたつもりでした。
    そのおかげか、たくさんの良い出会いがあり、人にも恵まれてきたと思います。
    それでも自分にとってしんどい出会いはあります。

    「あいつら」です。

    わたしが「あいつら」とは少し考え方が違うということは、「あいつら」は知っています。
    そして私も、「あいつら」のことを少し知っています。

    できることなら、同じ目標に向かって活動したい。
    でも、私は「あいつら」とわかりえることができるのでしょうか。
    「あいつら」が「わたしたち」にすることができるのでしょうか。

    「クソ野郎に近づくな」は正しいことだったのでしょうか。

    この数年間、考えてきたことをお話ししたいと思います。


    2.「社外のあいつら」高柳ライトニングトーク(5 min)

     企業内の研修依頼の多くは、何かしらのスキルが不足していて、もしくは課題になっていて、それを補う、解決するための研修になります。その場合の受講者は「自分にそれがないから受けてこいということか?」とか「今までのやり方は間違っているから、新しいやり方に変えろということか?」という自身を否定されたような状態で参加しているので、研修を「学びの場」として受け取るのではなく「研修内容を批判する場」として挑んで…というか、お手並み拝見とばかりにわかり合おうとしない状況が発生します。

    そんな分かり合えないことから始まる研修で、私がどのような向き合い方、選択をしてきたかをお話させてもらいます。


    3.「あいつらとの選択肢」について対話 By 高柳のファシリテート(10min)

    ホワイトボードではなく、iPadを使ってリアルタイムに書き取り、それをプロジェクターに投影しながら、2人の対話を、つなげたり、解いたり、遠ざかったりしながらお互いのライトニングトークから得た情報・状況で語り合います。

  • Liked Akiko Iwakiri
    keyboard_arrow_down

    Akiko Iwakiri / Toshihiro Ichitani / Tomoyasu Ishii - 経営者に聞く!-アジャイルと経営ー開発の現場は変わりつつある。事業サイド、経営陣はどうか?

    45 Mins
    Panel
    Beginner

    そもそもの思い

    RSGTの参加者が年々増えていることからわかるように、この間、スクラムに舵を切る開発現場が急増しています。

    波に乗って私も、スクラム的プロダクト開発手法を学ぼうと、2019年3月に、認定プロダクトマネージャー研修を受講しましたが、POの役割が広すぎて、定義していないのと同じだと感じました。また、プロダクトオーナー向けのドキュメントが具体的ではなく、事業サイドの方が、赤いピルを飲むために、手がかりがほとんどないように感じました。

    このギャップの前に、経営者はどんな手をとっているのか?というのが、このセッションを考えるきっかけでした。

    日本の経営方針は「ヒト」「モノ」「カネ」、アジャイルは「文化」が第1義。

    ナイスな開発チーム、プロダクトオーナーが自然と出てくる会社の文化をどう作っていったら良いのか、スクラムチームやアジャイル開発チームを抱える会社の経営方針は、どうきめるのかなど、本や研修には出てこない話を、デベロッパーから経営者になった方々に、この場でお話しいただき、彼らがヒリヒリした日常から何を気づき判断していったのか、お話を引き出せたらと思ってます。

    45分1本勝負。ぜひ、チャンスをいただけるとうれしいです。

    また、この場で聴いてみたいことなどあれば、コメントいただけるとうれしいです!

    登壇者

    市谷 聡啓

    ギルドワークス株式会社 代表取締役/株式会社エナジャイル 代表取締役/DevLOVEコミュニティ ファウンダー

    サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、ギルドワークスを立ち上げる。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。訳書に『リーン開発の現場』(共訳、オーム社)、著書に「カイゼン・ジャーニー」「正しいものを正しくつくる」がある。

    石井 智康

    石井食品株式会社 代表取締役社長執行役員

    ソフトウェアエンジニアとして、コンサルティング会社にて大企業の基幹システムの構築やデジタルマーケティング支援に従事。2014 年よりフリーランスとして、アジャイル型受託開発を実践し、ベンチャー企業を中心に新規事業のソフトウェア開発及びチームづくりを行う。2017 年から祖父の創立した石井食品株式会社に参画。地域と旬をテーマに農家と連携した食品づくりを進めている。現在のライフスタイルに合った「豊かな食」のあり方を模索中。認定スクラムプロフェッショナル。アジャイルひよこクラブ幹事。

    もう1名調整中

    進行役:岩切 晃子

    株式会社翔泳社取締役 / コンピュータ出版販売研究機構会長

  • Liked 船戸 康弘
    keyboard_arrow_down

    船戸 康弘 / Kenta Sasa - 良いアプリを作る為にスクラムを初めたら、巨大な組織(自動車会社)の風土が変わってきた話

    45 Mins
    Talk
    Beginner

    日本の典型的な製造業で、スクラムで社内向けアプリ開発を始めて約1年。
    ソフトウェア開発をしたことのない部門が、失敗を繰り返しながら動くをソフトを作り、ユーザーに価値を提供出来るようになってきました。

    スクラムによって生まれたのは品質の高いアプリだけではありません。セクショナリズムが強い大企業の中で、部門を越えた関係者が一つのチームとして動くことによって仲間が増え、コラボレーションが生まれ、想定していなかった所でも新たな価値が生まれつつあります。

    組織風土の変化の話に加えて、開発チームの具体的改善事例やインフラ構築の取り組み、メトリクスの推移なども共有します。

    参考に7月にDASAで発表した際の資料をシェアします:

    https://speakerdeck.com/yasuhiro_funato/minnagashou-huo-wode-rareru-aziyairukai-fa

  • Liked showwin
    keyboard_arrow_down

    showwin - ホラクラシーとスクラムは共存できるのか

    showwin
    showwin
    CTO
    LAPRAS株式会社
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    LAPRAS株式会社では全社的にHolacracy(ホラクラシー)というティール組織の1つである組織体系を導入しています。一方でホラクラシー導入前から開発チームではスクラムで開発を進めており、ホラクラシー導入の2018年4月から2つのフレームワークの共存にチャレンジしてきました。

    ホラクラシーの思想は個々人が役割(ロール)を持って責任範囲を明確にし、各人が自身で優先順位を決めて主体的に動いていくものである一方、スクラムは属人化を排除してだれでもどの役割を担えるようになる状態を理想としており、開発の優先順位決定もプロダクトオーナーが役割を持っています。根本的に異なる思想を持っているように見える2つのフレームワークが同居できるのか、実際に運用してみてわかったことをお伝えします。

  • Liked Junki Kosaka
    keyboard_arrow_down

    Junki Kosaka - なぜ私たちはホワイトボードを書くのか

    20 Mins
    Talk
    Beginner

    手書きという行為が本当に嫌いでした。
    スクラムを実践するまで、ペンを持つ機会を全力で避けて生きてきました。

    そんな私が●千円もする携帯用ホワイトボードを日頃から持ち歩き、ファミレスでも客先打ち合わせでも積極的に活用するようになったことで、気づけば周囲から「ホワイトボードを書く人」としてチーム外の会議に呼ばれるようになっていました。

    スクラムチーム内外での実践から得た書き手のメリットを中心に、好きが高じて非エンジニアな業界などからも学んできたお話を織り交ぜながらご紹介します。

    RSGTに参加される方々は、日頃からホワイトボードを活用しながらより良い場を作られている事かと思います。
    そんなみなさんの気づきや助けになるような機会になればと思い、プロポーザルを出させていただきました。

    濃厚な20分間を共有しながら矢印の書き方ペンの持ち方などのちょっとしたコツを覚えることで、あなたのホワイトボード生活がグッと楽しくなること間違いなし、です!

  • Liked Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi - スクラムマスターがファシリテーションを意識した時に受けるワークショップ

    100 Mins
    Workshop
    Intermediate

    スクラムでプロジェクトを進めて行く時に「ファシリテーション」という言葉は割と普通に出てくると思います。そしてスクラムで実際に「ファシリテーションをする」時になると、スクラムマスターとして見ている視点とファシリテーターとして見ている視点は少し違うのかもしれないと思うことがあります。ファシリテーターとしての役割と、スクラムマスターの役割と「帽子を被り直す」という感じで使い分けるということを考えていらっしゃる方もいると思います。

    今回のワークショップでは、スクラムイベントでのファシリテーションというポイントもありますが、その前にそもそもファシリテーションがスクラムの文脈では何をすることなのか、ファシリテーターとしての視点、捉え方が何を指すのか、改めて自分自身の引き出しに「ファシリテーション」のラベルのついた棚を明示的に増やしてみませんか?

  • Liked Takao Kimura
    keyboard_arrow_down

    Takao Kimura / Yasunobu Kawaguchi - 「ハイキュー!!」でわかるチームそして心理的安全性

    45 Mins
    Talk
    Beginner

    小さな巨人に憧れてバレーボールを始めた主人公が、高校生になり古豪烏野高校に入学し、チームの中で成長していく漫画「ハイキュー!!」
    この漫画は、チームそしてチームビルディングなどスクラムにも適用できるメッセージが要所要所にちりばめられています。

    このセッションでは、ハイキュー!!を通じて、心理的安全性とは何か?
    チームとは何か?
    現場でそれを行うためには、どうしたら良いのかをお伝えします。

  • Liked Kentaro Masuda
    keyboard_arrow_down

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

    Kentaro Masuda
    Kentaro Masuda
    Software Engineer
    Rise UP Inc.
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

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

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

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

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

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

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


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

  • Liked Kanako Muroyama
    keyboard_arrow_down

    Kanako Muroyama - トラブルだらけの現場から 仕事が「楽しい」現場に変わった、6か月間の話のその後

    20 Mins
    Talk
    Advanced

    2019年4月にDevLove関西で発表した「トラブルだらけの現場から 仕事が「楽しい」現場に変わった、6か月間の話」(https://www.slideshare.net/cowappa/ss-141300729)のその後の話です。

    業務改革を行ったチームがその後どうなったのか報告します!

  • Liked Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi / Mori Yuya / Manabu Shibahashi / Yumiko Yoshida - スクラムのためのチームビルド:対話型組織診断ワークショップ

    100 Mins
    Workshop
    Beginner
    Bernard DUPONTBernard DUPONT https://www.flickr.com/photos/berniedup/32052417864/in/photostream/

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

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

    そんな体験はないでしょうか?

    自分の考えをきちんと伝える。相手の主張としっかり向き合う。チーム内での会話の仕方は、チームの空気感や会社の文化に影響されます。

    「ケンカできる」とは、いがみあった対立ではなく、「互いに遠慮せずに主張し合える健全なコミュニケーション」の状態です。このワークでは、参加していただいたみなさんに組織や文化の理論をご紹介しながら、学びと体験をお届けします。対話で組織を観ることで、組織の風土が変わっていく、その第一歩を踏み出しましょう。


    【ワークショップ概要】

    『ケンカできるチームをつくるワークショップ』は一人一人は能力があるのにチームの結束がいまいちで悩んでいるリーダーに向けた実体験型ワークショップです。チームが結束する対話を実体験します。この実体験ではリーダーシップ理論やチームビルディング理論だけを学ぶ座学とは異なり、チーム内の対話の仕方を体験します。この体験によって鏡を見るように自分達の現状が分かります。前提として、チームで参加ください。

  • Liked Yuichiro Yamamoto
    keyboard_arrow_down

    Yuichiro Yamamoto - プロダクトバックログのシステム要件

    Yuichiro Yamamoto
    Yuichiro Yamamoto
    ICT部 部長
    株式会社AmidA
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    プロダクトバックログを維持するのに、いい感じに使えるツールがない。

    自社事業のIT部でプロダクトオーナーを担いながらプロダクトバックログをいじり倒してます。いまのところ良いツールが見つからず、スプレッドシートで残念な感じの手動組み合わせでやりくりしてます。

    課題管理システムやタスク管理システムは馴染みませんでした。カードに書いたりタスクボードの左端に並べて飾ったりしてますが、もう少し高度な「仕組み」が欲しいと願ってます。

    そんな私なりの「あったらいいな」を、私の組織におけるプロダクトバックログのライフサイクルや、内外の共有の方法、さらにはプロダクトマネジメントを装う方法など交えながら、整理してみたいと思います。

    誰か作ってください。