がちがちウォーターフォールのCOBOLer集団が、アジャイル/スクラム開発に挑戦してみた!

アジャイル開発という言葉は既に一般的になって久しいとはいえ、実際にはまだまだ取り組みが始まったばかり、あるいはこれから始めようと考えている方も多くいらっしゃるのではないでしょうか。
ここでは、ウォーターフォール&COBOLという、これまでアジャイルとは無縁な世界で生きてきたチームメンバーがどういった経緯でアジャイル/スクラム開発に挑戦することとなり、学び、実践する中でぶつかった壁をいかに乗り越えてチームとして成長を遂げてきたかをご紹介します。
アジャイル/スクラム開発を始めることのワクワクを共有し、同じような状況の方々の一歩を踏み出すきっかけになればと思います。

 
 

Outline/Structure of the Talk

 ・経緯
  - がちがちウォーターフォール&COBOLの文化とは
  - デジタルの流れが地銀にも。我々もアジャイル/スクラム開発に対応すべく、3か月チャレンジ
  - 社内にもアジャイル開発などのデジタル生産技術推進組織はあるが、社外の風を入れるためにRedHat社 OPEN INNOVATION LABSを採用

 ・そもそもアジャイル/スクラム開発とは
  - アジャイルソフトウェア開発宣言と12の原則
  - スクラム開発の役割とイベント

 ・実際の過程と大変だったところ
  - 各工程の様子とエピソード
  - どのような壁にぶつかったか(チーム/個人)
  - どのように進化していったか(チーム/個人)

 ・アジャイルとウォーターフォールの違いとは
 ・実案件をアジャイル開発で進めるメリットと課題
 ・今後の展望

Learning Outcome

 ・アジャイル/スクラム開発がどのような考え方、活動なのかイメージできる
 ・アジャイル/スクラム開発とウォーターフォール開発の違いを理解できる
 ・アジャイル/スクラム開発初心者がどのようなところにつまずくか、一例がわかる
 ・アジャイル/スクラム開発のワクワクを共有できる

Target Audience

・アジャイル開発という言葉は聞いたことはあるが、具体的な考え方や活動をイメージしたい方/・アジャイルチームを初めて立ち上げようとしている方、それをサポートする方/・昔経験した初めてのアジャイルのワクワクを思い出したい方

schedule Submitted 1 year ago

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?

    20 Mins
    Talk
    Intermediate

    現場コーチとしてScrumでサービス開発しているチームの支援をしていると、よくディスカッションする話題の1つが「プロダクトバックログアイテム(PBI)の価値や成果をどう考えて、どのように扱うか?」というものです。

    このような話題の時、OutputとOutcomeの話をします。

    • Outputとは、リリースした機能の数や質のことをここではいいます。
    • Outcomeとは、利用者がどう変わったのか?利用者の課題が解決したのか?と利用者視点での効果のようなことをいいます。
      • ※Outcomeはビジネス視点からのOutcomeと、利用者視点からのOutcomeの2つに分類されます。上記は利用者視点からのOutcomeのことを書いています。

    たくさんのPBIをつくって頻繁にリリースしてOutputが増えたとしても、自分達にとっての価値、もしくは利用者にとっての価値(利便さや嬉しさ)といったOutcomeが増えていないとそのプロダクトやサービスを続けていくことはできません。

    1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
    また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか?の参考にしています。


    プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。(ScrumGuide2017より)



    このセッションでは、"プロダクトバックログアイテムにおける価値の取り扱いのやり方”のいくつかの現場の事例を紹介しつつ、Outcomeについて考えをお話します。
    みなさんのPBIのOutcomeがよりわかりやすく、より高くなるヒントになればと思います。

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - アジャイルコーチ活用術

    20 Mins
    Talk
    Beginner

    世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。
    アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。
    アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。

    一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。
    これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります(アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです)。

    本セッションでは、アジャイルコーチとは何なのか、実際にアジャイルコーチをどう活用すれば良いのかを、日本で唯一のScrum Alliance Certified Team Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。

  • Kazutaka Matsusaki
    keyboard_arrow_down

    Kazutaka Matsusaki / 河野 彰範 - アジャイルな組織を創っていくには?地銀で取り組むアジャイルな組織創り

    45 Mins
    Talk
    Beginner

    ふくおかフィナンシャルグループ(FFG)では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
    昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。

    2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。

    古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
    そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
    実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。

    このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。
    取り組んできたこと、失敗したこと、成功したこと、たくさんあります。
    地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。

    • アジャイル組織の変遷
    • 現行ルールのしがらみとの闘い
    • アジャイル開発を少しずつ組織に浸透させていく方法
    • 組織を拡大していくための対内・対外的な取り組み
    • 拡大していく組織で発生した問題
    • 成果を出し続けていくための組織やチームの意識改革
  • Hiroyuki Ito/伊藤 宏幸
    keyboard_arrow_down

    Hiroyuki Ito/伊藤 宏幸 / 高橋 勲 - 特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術 -

    45 Mins
    Talk
    Intermediate

    我々LINEのSETチームは、テスト自動化の実現・推進だけではなく、プロダクト開発チームのプロセス改善・DevOpsの推進・技術戦略の策定・実施といった活動を、全社的に行っています。

     
    一連の活動に際して我々は、様々な技術・ツールとアジャイルプラクティス・マインドセットとを組み合わせ、日々実験を繰り返しながら、ビジネス的成果へとつなげています。
     
    当セッションでは、特定の開発チームから組織横断活動までに活用できる、技術とアジャイルの組み合わせ方を、LINEでの実例をもとに、参加者の皆様が現場に持ち帰って試せる形でご紹介します。
    また当セッションは、SETチームをこれから作ろうとされている会社・担当者の皆さま向けの具体的なアプローチ集とすることも想定しています。

  • 45 Mins
    Panel
    Advanced

    大企業で新規事業を始めるために必要なものはなんだと思いますか?予算ですか?社内政治ですか?そう!違う!そう!

    プロダクトオーナーやリーンスタートアップの本を読んでも、なかなか教えてもらえないのが「日本企業におけるカネと政治」。エンジニア出身の方も、マーケティング出身の方も、プロダクトデザインやUXの方も、等しく苦労するポイントであろうと思います。

    プロダクト開発はうまくできても、それ以外のところで泥沼にハマってしまいがちな大企業の皆様に、うまくサヴァイヴして人生をときめくためのヒントをお伝えできればと考えております。そのために、実際に大企業で新規ビジネス開発の仕組みづくりに携わるみなさんから、戦略やヒントやマサカリをいただきます。もしかしたらちょっと心に棘が刺さるかもしれませんので、しっかりと心のご準備をお願いいたします。

    発表者は、絹川達也さん(楽天)、太田敦士さん(NTT西日本)、そして楽天技術研究所や楽天テクノロジーカンファレンスを設立から育ててこられた森正弥さん。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。

  • Harada Kiro
    Harada Kiro
    CEO and Agile Coach
    Attractor Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    ScrumPLoPとして2010年から活動してきたスクラムをパターンランゲージとして記述する活動も、2019/8/5現在、最終校正が完了し印刷待ちです無事9/3発売されました。RSGT 2020 には、出版された本を持っていける予定ですいきます。

    540ページの大部になってしまったので、ちょっと気軽に手に取るには大きな本になってしまいました。

    このセッションでは、A Scrum Book の読み始める方法を、ちょっとした出版までのエピソードなどを含めてお話しできればと思っています。

    著者のJim Coplienを発表者に追加しました。

  • Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - ワークショップ用ゲームの作り方 やっとむ流

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 1 year ago
    Sold Out!
    100 Mins
    Workshop
    Intermediate

    カンバンゲーム、宝探しアジャイルゲーム、心理的安全性ゲームなどを作ってきたやっとむから、ゲームの作り方を解説します。

    私が作っているゲームは、一般的な商業ゲームとは違い、伝えたい明確な内容、ゲームの体験から受け取ってほしいメッセージが入っています。そうしたゲームを作るために、以下のような順番で考えます。

    1. 伝えたいものはなんなのか自分の中で整理する
    2. それを伝えられるゲームの枠組みを選ぶ
    3. ゲームバランスを取る

    1.の項目では、アジャイル開発であるとか、心理的安全であるとか、カンバンボードといった対象を自分なりに分析し、モデリングしたりシミュレーションモデルを作ります。ここでは、ゲームでは表現しない要素、切り捨てる要素を探します。

    それをもとに、プレイヤーに体験しほしいエクスペリエンスを考えます。たとえばカンバンゲームでは、以下のような体験を想定しました。

    • 全体が見えているとハイレベルな判断ができるようになる
    • 個人でなく全体を最適化したくなる
    • タスクが見積もり以上にかかる
    • タスクが片付くと嬉しい、盛り上がる
    • 人が抱えてる問題を知ると解決できる
    • 自分の解決法を見せると誰かが利用する
    • みんなでやると早く終わる
    • 早く終わると問題が起きにくい
    • 仕掛で残してると問題が増える
    • 終わりそうだと思ったら問題だらけになる
    • 話し合うと思わぬ解決法が見つかる
    • 仕事を割り振るリーダーはいらない
    • タスクに価値があると優先順位を判断できる

    つぎに2.の段階では、そうした体験をゲームとしてどう表現するか考えます。世の中にはたくさんゲームがあるので、そこからアイデアを借りるのがよいでしょう(商業ゲームならパクりは問題ですが、自分のワークショップで使う分にはいーんじゃないかなと思っています)。逆に言うと、ゲームを作るコツはよいゲームをたくさん知っていることです。

    カンバンゲームはカンバンボードを扱うものなので、カンバンボードをそのままシミュレーションします。タスクの内容、見積もり、ToDo/Doing/Doneはリアルそのものです。こうしたリアルを写し取った要素が多いと、ゲームから仕事に役立つ学びを直接得やすくなります。

    もちろん、すべて再現してしまったらそれは仕事そのものなので、デフォルメ、ゲームらしさも必要です。仕事の進み具合をサイコロで表現する、問題と解決をそれぞれカードで表現するというのはゲームとしての工夫になります。解決が有効か話し合うというところは、『キャット&チョコレート』などのゲームから借りたアイデアとなります。

    世の中のゲームを知っているから自分のゲームのアイデアも浮かぶというのと同時に、道具立てもけっこう重要です。どんな道具が使えるか(いま持っていないものも含む)、それをうまく利用できないか。カンバンゲームでは、ゲーム用の金の延べ棒を使います。これを見るだけでプレイヤーはテンションが上がりますし、カンバンがDoneになったら儲かるんだということが直感的に伝わります。このインスピレーションは、仕事におけるタスクの見方にまで影響します。カンバンゲームでは次のような道具を使っています。

    • サイコロ → 仕事の進捗は予測できない
    • 仕事残量をチップで見せる → 仕事の大きさが目で見える
    • 問題カード → カンバンで問題が起きていることの見える化
    • 解決カード → 手札に持った解決方法を適用できる
    • 金塊 → 仕事には価値があることの実感

    最後が、3.のバランス調整です。時間的にはここが一番かかります。ゲームの枠組みがあっても、求めている体験が本当に得られるか、違った感触のものになってしまわないか、予想外の抜け道がないかなどを考えます。バランス調整では、いろいろな人に実際に遊んでもらう必要があります。

    カンバンゲームではこのバランス調整の中で、以下のような発見や出来事がありました。

    • 無理筋な解決法を押し通そうとする人がいる
    • 「もっとがんばる」で解決できると主張を崩さない人がいる
    • ピッタリ合う解決法しか使いたくない人がいる
    • EVENTカードを先読みして期待する
    • 無理だと思ったらサイコロが爆走して完了する
    • 自然と1人1タスクにしてしまう(習慣の力は強い)

    私のゲームはプレイヤー同士の会話を重要なファクターにしていることが多く、そのためゲームとして破綻することは少ない(ルールを悪用して一人勝ちする、など)ものの、よい会話が生じるかは気をつかうところでもあります。

    バランス調整はある意味永遠に続き、ゲームをやっては微調整をしたり、たまに大幅バージョンアップが起きたりもします。

    当日はこのような話をします。参加者の方と一緒にゲームを作る時間があるかは、採択の結果に寄ります。

  • Tadahiro Yasuda
    keyboard_arrow_down

    Tadahiro Yasuda - 日本にJoy,Incを創る!ぼくらのジョイインクジャーニー3年間の軌跡

    Tadahiro Yasuda
    Tadahiro Yasuda
    CEO
    Creationline,Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    Joy,Inc.に出会う前のぼくらは、チームとして機能していませんでした。2013年ごろ、色々な問題が噴出し、会社としてどん底の状態でした。
    そこから、色々な取り組みを行い、少しづつ会社の状態がよくなっていきました。その過程のなかで2017年8月「Joy,Inc.」に出会いました。
    「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
    この本に共感しぼくらもこんな会社に成りたい!と決意。それを実行してきました。
    会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

  • Yuichi Tsunematsu
    keyboard_arrow_down

    Yuichi Tsunematsu - 「1プロダクトをみんなで作る」会社での大規模スクラム(LeSS)導入

    Yuichi Tsunematsu
    Yuichi Tsunematsu
    Manager
    Retty Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    Retty株式会社は「信頼出来る友人や好みの合う人から自分にぴったりなお店を探す」グルメサービスRettyの開発・運営を行なっております。内部システムはレストランを見つけるtoC向けのWeb、スマートフォンアプリ、レストラン側が利用するtoB向け管理システムに大別できますが、会社としてたった1つの多くのユーザに利用されるサービスを手がけています。

    サービスと会社が大きくなった結果、全社でスピード感とアジリティを追求していくには開発プロセスの見直し、そして組織構造の見直しが必要だと考えるようになりました。

    本講演では1チームから始まったスクラム開発をどう広げ、LeSS(Large Scale Scrum)を採用した大規模スクラム体制に移行できたのか、具体的な課題とその対処を交えて紹介します。

  • Makoto Takaesu
    keyboard_arrow_down

    Makoto Takaesu / Etsuo Yamada - ちゃんとしてるScrumってどんなのだ? 〜“ざんねんスクラム”で学べるチームビルディング術〜

    45 Mins
    Talk
    Beginner

    アジャイル開発やスクラムに関する誤解や誤用(ScrumBut)をまとめて“ざんねんスクラム”と総称してます。
    “ざんねん”なスクラムの状況を通じて、何がイケてないのかを深く理解し、どう改善すればよいのか?をSpeakerが話すだけではなく、参加者みんなで考えていこうというコンセプトのセッションです。

    • 「それってうちのことですか?」
    • 「どこかで見たこと聞いたことあるような。。。」
    • 「なるほど、そう考えるとたしかによくなさげ」
    • 「アジャイルが認知されてきたからこそ起きている、最近の状況」
    • 本当にあった怖いスクラムの話

    といった感じで複数の小さなテーマごとに話をしたいと思います。
    (途中参加、途中退出はお気軽にどうぞ)

    以前からの定番あるあるネタ、最近のアジャイル界隈などのテーマを織り交ぜて、参加者の方に1つでも生きた情報を現場に持ち帰ってもらえればと考えています。

  • Miho Nagase
    keyboard_arrow_down

    Miho Nagase - とにかく明るいセッション ✌️(^o^)

    Miho Nagase
    Miho Nagase
    Agile Coach
    Attractor Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    え、え、え、ちょっと待ってちょっと待って?

    このセッション、明るくなーい!???

  • Miho Nagase
    keyboard_arrow_down

    Miho Nagase - グローバルスクラムドヤリングへの招待

    Miho Nagase
    Miho Nagase
    Agile Coach
    Attractor Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    例年Regional Scrum Gathering Tokyo(以下RSGT)には多くのプロポーザルが集まります。一方で、RSGTを知る人ほど、講演に対する期待値のハードルを自ら上げてしまうという話も聞かれます。

    またここ数年、海外のカンファレンスに参加する日本人も増えてきました。しかし講演者として参加する人はまだまだ多くありません。

    カンファレンスでの登壇は、そこまで難しいものでないといけないのでしょうか? アジャイルの世界において、新しいことに挑戦し、情報をオープンにしてフィードバックをもらうことの喜びや学びの価値は、皆さんがよく知っているのではないでしょうか。カンファレンスで聞く話よりももっと濃くてすごい会話(他の登壇者の方々、失礼!)を、実はビアバーで、居酒屋で、職場で、ミートアップで、すでにしているのではないでしょうか?

    先駆者に遅れること数年、わたしが2012年に初めて海外のアジャイル系のカンファレンスに参加して、しかも当時馴染みのなかったOSTセッションを1枠提案させられるはめになってして以来、東南アジアを中心に海外カンファレンスに参加し見聞きしてきた経験から、もっと気軽に、もっと自信を持って、そしてもっと楽しく登壇するための挑戦にお誘いします。

  • Koki Shimizu
    Koki Shimizu
    Scrum Master
    N/A
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    みなさん、スプリント期間ってどうやって決めてるんですか?なんとなく決めてませんか?

    なんとなくでも、きっと開発チームの頭のなかにある”これまでの経験”によってひねり出された期間がスプリント期間になっているんじゃないですか?

    スプリントが終わったら”潜在的に出荷可能なもの”ができるんですよね?すぐリリースしてください!

    え?リリースできない?あくまで”潜在的に”って言ったじゃない。あとこれとそれとこれとそれをやらなくちゃいけない、あと1ヶ月かかるんだって。

    うちの会社はしがらみが多いから・・・とか。

    プロダクトオーナーと開発チームがDefinition of Doneを共有していないとこんなことになります。

    Definition of Doneは、単なる、「タスクを終わらせるときのチーム内の合意事項」ではありません。

    プロダクトを「リリースして、顧客に届く」までのバリューストリームを示し、そこまでに必要な作業と基準をすべてを洗い出します。

    作業と基準をすべて洗い出して、はじめて、

    • 「潜在的に出荷可能なインクリメント」がどのくらいの期間で作れるのか
    • このプロダクトにスクラムは適用可能なのか
    • スプリント期間が終わってから顧客に届くまでに何をやらなくてはいけないのか、どれくらいの期間がかかるのか

    が明確になりますし、スクラムをはじめる前に明確にしておく必要があります。もちろんその後も継続的にリファインメントされる必要があります。

    これがDefinition of Doneです。

    このセッションでは、忘れられがち(と勝手に私が思い込んでるだけかも知れませんが)なDefinition of Doneの重要性と作り方、維持管理の方法を

    みなさんと考えていきたいと思います。

    とくに規制(FDA、ISO*****等)があるプロダクトや昔ながらのルールのある企業において、スクラムを適用する際には、Definition of Doneを決めることが非常に効果的だと確信しています。

  • KazuhideInano
    keyboard_arrow_down

    KazuhideInano - チームや組織が変革するためのポイント 〜アジャイルコーチの視点から〜

    KazuhideInano
    KazuhideInano
    Agile Coach
    JEI LLC
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    最近のDXという風潮も追い風となり大企業でもベンチャーでも規模を問わずアジャイル、スクラムに取り組む現場が本当に多くなってきました。

    私は流しのアジャイルコーチをしているのでこういった現場の支援を行うことが主な仕事となりますが、実際のところチームにせよ組織にせよ一筋縄では行かないことがよくあります。時として、今まで培ってきた組織の文化や慣習などのような「今までのやり方」が障壁となってしまうことがしばしばあるからです。

    そこでこのセッションでは、コーチの視点で「うまくいくためのポイント」や「気をつけるべきポイント」などを事例を踏まえつつお話しし、チェンジエージェントを担うみなさんにヒントを持ち帰ってもらえる場としたいと思います。

    ※ここで挙げる事例は一部実例も含みますがあくまで架空のものとなります

  • showwin
    keyboard_arrow_down

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

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

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

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

  • Takao Kimura
    keyboard_arrow_down

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

    45 Mins
    Talk
    Beginner

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

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

  • Harada Kiro
    keyboard_arrow_down

    Harada Kiro - Kaizen in Practice

    Harada Kiro
    Harada Kiro
    CEO and Agile Coach
    Attractor Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Kaizen has become a buzzword we hear everywhere.
    Unfortunately, there are many ineffective Kaizen implementations, just like ScrumButs.

    Kaizen is an everyday activity to make it better that leads to “continuous improvements.”
    But how can we start Kaizen, and how can we continuously perform Kaizen?

    This session will guide you with how you and your team can make your Kaizen effective and continuous. The talk also includes several practical Kaizen actions you can try with your team.

    And try to answer the question: “What is Kaizen for?

    This presentation has been delivered as a keynote at Regional Scrum Gathering Beijing 2019.

  • 徳冨 優一
    keyboard_arrow_down

    徳冨 優一 - スクラム開発を阻害する "白い巨塔"

    徳冨 優一
    徳冨 優一
    代表取締役
    Degino Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    スクラム開発に必要なことはスクラムのノウハウだけではないようです。 ケント・ベックのエクストリームプログラミングが日本に紹介されてから二十年が経ちます。その当時から長年 XP を実践してきたエンジニアが見た大手 SIer の状況は、まるで二十年前にタイムスリップしたかのようでした。

    そんな大手 SIer におけるシステム開発の問題点、およびカイゼンと備えについて共有したいと思います。