老舗メーカーにみんなでアジャイルを導入してみました ~「俺がやる!」から「みんなでやる!」に至るまで~

既存の組織体系やマインドが色濃く残る老舗メーカーで、健全なソフトウェア開発を実現できるよう全社的にアジャイルや要求開発の導入を推進してきました。

2016年に、ほぼ私一人で始めた活動ですが、今では20名を超えるコーチングチームを組織するに至りました。
一部の活動は私の手を離れ、完全に社内コミュニティを主体に運営されています。
さらに、毎年開催している社内のアジャイルカンファレンスは、17年時点は約450名ほどの参加者だったのが20年には倍の約900名にまで増えました。
さらにさらに、私が支援した社内のサービス開発チームが、SFOにプロポーザルを出すに迄いたりました。

ここに至るまで経緯や具体的な施策、現在直面している困難と課題についてお話しさせて頂きます。

現在の途中経過ではありますが、少しでも皆さんの参考になれば幸いです。

 
 

Outline/Structure of the Talk

  • 企画、販売、開発、運用など、関係者全員でゴールを合わせる方法の全社展開
    • VUCAな時代に適応すべくフィードバックを短くする
    • 老舗メーカーの課題
    • アジャイル型要求開発とは
    • アジャイル型開発における機能要求と非機能要求の扱い
    • テストのあり方
    • どうやって全社に広めたのか
    • コミュニティの形成と人事制スキル認定制度化
  • アジャイル型企画/開発の導入からコーチチームを結成するまで
    • 「アジャイル」の誤解が招く課題
    • やって見せる
    • 社内の他の現場の同志を見つける
    • 「アジャイル」の正しい理解の共通認識化
    • 全社展開に向けたトップダウンとボトムアップのアプローチ
    • 全社横断のコーチングチームを発足
    • チームの強みと弱みを見つけるアセスメント
    • コーチングチーム自身を強くする育成手法
  • で、これからどうするの?

Learning Outcome

Fearless Changeを実践した実事例を知れます

チームへのアジャイル導入は進んでいるがプロダクトチームや組織的な導入には至っていない方に、組織へのアジャイル導入、組織改善の事例が知れます

Target Audience

組織にアジャイルを導入している、または、しようとされている方

Slides

Video


schedule Submitted 1 month ago

Public Feedback

comment Suggest improvements to the Author
  • Toshiharu Akimoto
    By Toshiharu Akimoto  ~  2 weeks ago
    reply Reply

    分散アジャイル勉強会などで発表して反響のあった、あのセッションでしょうか?
    それならスライドもある程度先行して公開しちゃっても良いのではないかと思いました。話の内容の良さが皆さんに伝わるのではないかと思いました。

    • Kei Nakahara
      By Kei Nakahara  ~  1 week ago
      reply Reply

      メッセージに気付くのが遅れました!!
      あれ?
      ほんとだ。
      SlidesってところにSlideshareのURLを貼ってたんですが表示されていないですね。。。
      なぜだろう。

      VIDEOの所にSlideshreのURLを貼ったら表示されました。

      ありがとうございました!

  • Kei Nakamura
    By Kei Nakamura  ~  3 weeks ago
    reply Reply

    TO:Kei.Nakaharaさん 
    広めたい活動です、応援してます!

    • Kei Nakahara
      By Kei Nakahara  ~  3 weeks ago
      reply Reply

      ありがとうございます!!


  • Masayuki Nishida
    keyboard_arrow_down

    Masayuki Nishida / Kei Nakamura - スクラムチームが挑む!未熟プロダクト育成とビジネス成功への道

    45 Mins
    Keynote
    Beginner

    老舗大手製造業生まれの新規SaaSビジネスが1年目で直面した成長の壁、
    モダンアプリ開発会社が加わり組成した新スクラムチームが、ビジネス貢献に取り組み続けて成果を上げ始めています。

    「変化を目指す」老舗事業会社のPOと「変化を加速する」開発会社のScMが、体験や事実、その裏側にあった仲間の支援など、対談形式も交えてお伝えします。

    「スピード優先で事業化にこぎつけスタートしたSaaSプロダクト。その結果プロダクトが、早晩スケーラビリティや持続性を担保できず足踏み状態になる」…そんなビジネスあるある。

    今回題材となるSaaSプロダクトも、スピード優先でビジネスを始めた当初は数十社の顧客と密にやり取りを行い、フィードバックを製品に反映しながら良好な立ち上がりに見えました。
    しかし顧客数が増えるにつれ、事業会社が進めていた日曜大工的開発では開発スピードや品質が市場要求に追いつけなくなっている状態に、事業会社POは悩みます。
    (悩みの一例)
    ・PoCの延長で開発されたプロダクトのテスト、デプロイが人力依存で非効率な状態
    ・インフラやアーキテクチャが大規模顧客を考慮していない中でのエンタープライズシフト企画
    など。
    せっかくビジネスが拡大しそうなのに、さてどうしたものか。。。

    組織的な改善を水面下で続けていた老舗大手企業とモダンエンジニア集団が出会い協力しスクラムに取り組んだ軌跡

    登壇するPO、ScMが本プロジェクトで大切にしてるマインド

    [ PO ]

    対話を通してビジネスが目指していく姿、変化していく市場の生の声、背景を伝え続ける

    [ ScM ]

    POを含めたステークホルダへの状況の見える化と対話の機会を明示的に増やして活用してもらう工夫をしました

     

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - アジャイル環境における品質プロセス - Janet Gregory & Lisa Crispin(動画放映)

    Jumpei Ito
    Jumpei Ito
    QA Engineer
    WingArc1st Inc.
    schedule 4 weeks ago
    Sold Out!
    90 Mins
    Keynote
    Beginner

    テスターを含むチーム全体(Whole-Team)で、プロセスやプロダクトに品質を作り込む(Build quality in)にはどうしたらよいでしょうか。
    Janet Gregory とLisa Crispinによるこの動画では、W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」と、それをアジャイルな職場で実践する方法について詳しく学べます。

     

    W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」で以下の2つの原則はJanetのお気に入りです。

    • quality is everyone's responsibility(品質はすべての人の責任)
    • improve quality you automatically improve productivity(品質を向上させれば、自動的に生産性も向上する)

    また、Janetがオリジナルで提唱する原則が以下の2つです。

    • if you focus on quality the speed will come(品質にフォーカスすればスピードが出る)
    • if you focus on speed the quality gets lost(スピードにフォーカスすれば品質が失われる)

    アジャイル環境において品質を考えると、「プロダクト品質」と「プロセス品質」の関係が重要となります。
    JanetとLisaは以下のような内容で特にプロセス品質についてトークします。


    1.Question Askerであるべき
    2.例やテストを使って開発をガイドする
     ・magic bubble(魔法の泡) コード・テスト・自動化
     ・Acceptance Testのループ(受け入れテスト作成→テストの拡大→自動化担当者とペア→テストメソッドの作成→何をテストするのかを明確化→TDDサイクル→ハッピーパスが通るまでリピート→探索的テスト)
    3.エクササイズ(ユーザーストーリーからテストを考える)
    4.アジャイルテスティングの4象限を使ってテストを把握する
    5.探索的テスト、品質属性のテスト、スライディング・スケール
    6.コアプラクティスを使う
     ・継続的インテグレーション
     ・テスト自動化
     ・機能やストーリーの優先順位付け
     ・ビジネス価値を頻繁にデリバリー(いつでも出荷可能なリリース候補を用意する)
     ・品質をデリバリー(コアプラクティスを用いて、会社やチームのあらゆる部分で品質を構築)

     

  • Fujihara Dai
    keyboard_arrow_down

    Fujihara Dai - アジャイルコーチの10年、スーパーアジャイルコーチの10年、ウルトラアジャイルコーチの10年

    45 Mins
    Keynote
    Advanced

    (あとでちゃんとかくかもしれない)

    2010年にフロリダで開催されたAgile conferenceに参加していらい、「よりアジャイルなチームを作るためには?」を考え続けてきたようにおもいます。僕の関心は常に「アジャイル開発」です。

    当初は企業内のアジャイルチームとして活動し、のちにアジャイルコーチと名乗るようになり、開発現場に立ったり、チームや組織開発を考えたり、「どうやったらもっとアジャイルになるか」を考え続けてきましたが、今もアジャイルコーチとして新しい現場に立つたびに、10年前と変わらず悩み続けています。

    10年の経験を得て、これまでにできてきたこと、まだできていないことをふりかえりながら、次の10年をスーパーアジャイルコーチとして現場を成功させ、その次の10年でウルトラアジャイルコーチとして過ごすために必要なことを考えるセッションです。

  • Hiroshi KURABAYASHI
    keyboard_arrow_down

    Hiroshi KURABAYASHI - ベトナムでやり直すソフトウェア開発

    Hiroshi KURABAYASHI
    Hiroshi KURABAYASHI
    None
    Indigames
    schedule 2 weeks ago
    Sold Out!
    45 Mins
    Keynote
    Beginner

    ベトナムでは COVID-19 が世界的に流行する以前より、日系企業のオフショア開発の縮小・撤退が散見されるようになってきました。ベトナム経済の継続的なえげつない高度成長により(コロナ禍でもGDPプラス成長)、コスト上昇が著しいのは事実です。コスト、品質、そのバランスなど悩みどころはたくさんあります。

    ベトナムの開発では日系企業の場合、基本的には、通訳を通じての日本語もしくは直接英語でやり取りを行いますが、

    言葉が通じることと、話しが通じることは違います。

    要件を正しく伝える・相手の言いたいことを正しく理解する。ごく基本的で大切なことですが、特に国を超える場合、思考の背景にあるコンテキスト(カルチャー)を理解することが重要です。お互いが。

    私は2014年12月からおよそ6年半、

    • ハノイ、ホーチミン
    • 案件を出す側・受ける側
    • 保守運営案件、新規案件、自社開発案件
    • ラボ型開発、受託開発
    • エンジニアがいるクライアント、いないクライアント

    など様々な組み合わせで、PM、エンジニア、人事、経営などの立場でベトナムに関わってきました。

     

    Made in Vietnam のソフトウェア開発を世界品質にすべく活動するなか、試行錯誤してきたこれまでの取り組み、現在の取り組みをシェアしたいと思います。

  • Kazuho Onojima
    keyboard_arrow_down

    Kazuho Onojima - 1500人、110以上のプロジェクトが並走するグローバル企業で品質改善活動に取り組んでいる話

    45 Mins
    Keynote
    Beginner

    スタートアップ企業のソフトウェア・サービス開発や、大手企業の新規事業開発を支援するSun Asteriskの開発拠点はベトナムにあり、約1500名の開発体制では常に110を超えるプロジェクトが同時に動いています。

    私達は最近までプロダクトを高速でデリバリーすること強みとしてきましたが、最近では”品質”を次のテーマとして取り組んでいます。
    品質が企業に与える影響は経営において非常に重要なものであり、その影響は長期的であると考え、
    私達のビジネスモデルの特性をふまえてQA2AQやAgile Testingなどを参考に、以下の観点でSun*のアジャイル品質定義と品質改善活動に取り組んでいます。

        1. 私達が提供するべきプロダクト品質 (技術/製品品質)
        2. 顧客が私達に期待するプロダクト品質 (技術/製品品質)
        3. 顧客がEnd Customer / Userに提供するべきサービス品質 (製品品質)
        4. End Customer / Userがサービスに期待している品質 (特に製品品質)

    今回はそんな私達の取り組みについてご紹介させていただきます。

    #Agile mindset #QA2QA  #AgileTesting  #Scrum #GIST Planning

  • Masatoshi SEKI
    Masatoshi SEKI
    null
    null
    schedule 1 week ago
    Sold Out!
    45 Mins
    Keynote
    Advanced

    「ユニコーン企業のひみつ」。この本はとても読みやすいんだけど、でもそれって…自分と違う星の話を眺めてる気分だからじゃないのかな(仮説)。

    私たちのチームと本で紹介されているチームの様子は、まるで地続きみたいによく似ていてます。本講演では「ユニコーン企業のひみつ」を使って私たちのチームについて説明を試みます。この本を自分のことのように受け止めた人たちの助けになれば良いな、と思います。

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - チームの状況にあったいろいろなタイプのスクラムマスターの見つけ方

    20 Mins
    Talk
    Beginner

    「どういう人がスクラムマスターをやればいいんだろうか?」

    この質問はチームがScrumに取り組もうとした時によく出てくることの1つです
    Scrumにあるプロダクトオーナー、スクラムマスター、開発者の3つの役割のうち、特にスクラムマスターはわかりにくいようで、この冒頭の質問が出てくるようです

    しかし、一方で、ScrumGuideには以下にあるようにスクラムが機能するにはとても重要な役割を果たします

    スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を 持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクス を全員に理解してもらえるよう支援することで、その責任を果たす。

    では、どのような人がスクラムマスターに向いているのでしょうか?
    またプロダクト、チームや組織の状況によってどういうような人がスクラムマスターをするとより良いのでしょうか?

    このセッションでは、「どういう人がスクラムマスターをやればいいんだろうか?」という質問に、ギルドワークスの現場コーチとして70チーム以上(すべてにスクラムマスターがいたわけではありませんが)を支援してきた事例から自分なりの経験や考えをお話できればと思います

    よりよいスクラムマスターと出会える、見つける、なっていくヒントになれば幸いです

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / Takahiro Kaneyama - ふりかえり手法のおもちゃばこ〜最近生まれた新しいふりかえり手法をお届け!〜

    20 Mins
    Talk
    Advanced

    みなさん、ふりかえりは楽しんでいますか?
    うんうん、いいですね!私はすっっごく楽しんでいます!!

    この2-3年、ふりかえりのことを発信する人たちが増えてきました。
    日本で初開催された  ふりかえりカンファレンス では、22名もの人がふりかえりの想いや新しい手法を語っています。
    また、ふりかえりamでも、Podcastの中でゲストが様々な手法を紹介してくれ、新しい手法も生み出されています。

    日々、新しい手法が生み出されているふりかえり。

    このセッションでは、近年生み出された手法を紹介していきます。
    どれも楽しくわくわくする手法ばかりですので、気になる手法を真似してみてくださいね!

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / kyon _mm - Deep Dive Experts - 達人が見ている世界を覗いてみよう -

    45 Mins
    Talk
    Beginner

    達人たちが見ている世界を覗いてみませんか

    「あの人はこの問題に対してなんて答えるんだろう?」
    「あの人はこの答えに辿り着くまでにどういう思考プロセスを経たのだろう?」
    「あの人の頭の中身が見てみたい!!」
    と思ったことはありませんか?

    同じようなプラクティスや手法を用いていても、人/チームによってまったく違う結果になります。
    つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

    このセッションでは達人たちが見ている世界を覗いてみる実験をします。
    ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
    ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - 「モンダイ」が現れた!ゲームでアジャイルを練習しましょう!

    20 Mins
    Talk
    Beginner

    プロダクト開発は難しいですよね。コミュニケーションとスキルがとても必要です。よくストレスいっぱいあります。

    でも、もしプロダクト開発がゲームだったら・・・

    コーチとして、開発チームと仕事を面白くなるためにたくさん実験を作りました。

    そのプレゼンには、アジャイルか開発を楽しくなるコツとゲームを紹介します。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori - アジャイルなチームをつくる『ふりかえり』のガイド++

    45 Mins
    Talk
    Beginner

    ふりかえりが少しずつ認知されてから、様々なところでふりかえりの重要性が叫ばれてきました。ただし、どう始めたらいいのか、どう定着までに至るのか、道のりはあまり述べられてきていません。

    ふりかえりは、チーム全員で定期的に立ち止まり、チームがより良いやり方を見つけるために話し合いをして、チームの行動を少しずつ変えていく活動です。

    COVID-19とリモートワークの加速によって、これまで顔を合わせて働いていたチームも、直接会って仕事をする機会は今後も減っていくでしょう。これから新しくチームを作ることも今まで以上に難しくなっていきます。

    そんな世界の中でも、変化に柔軟対応でき、価値を生み出し続けられる「アジャイルなチーム」。そして、それを作るための一歩目である「ふりかえり」と、その導入をガイドします。

    このセッションは「Developers Summit 2021(デブサミ)」でベストスピーカー賞8位を受賞したセッションの再演です。
    ただし、アジャイル・スクラムの知識を前提として導入部分をバッサリカットし、デブサミではお話のできなかった+αの内容をあわせてお届けしたいと思います。

  • Masamichi Otsuka
    keyboard_arrow_down

    Masamichi Otsuka / Hideo Kobayashi - 経験ゼロからはじめる!10年以上続くプロダクトのアウトカム創出戦略

    45 Mins
    Talk
    Beginner

    アジャイルの浸透によってプロダクトがアウトカムに目を向けることの重要性が認識されるようになりました。では、従来型の開発プロセスで10年以上開発を続けてきたプロダクト開発チームは、どのように取り組めばアウトカムに目を向けたアジャイルな開発に転換できるのでしょうか?

    今から2年前、10年以上の歴史を持つプロダクトが新たなビジネス領域に参入するためにチームを再結成して新機能を開発していくことになりました。正解がないレッドオーシャンのビジネス領域に飛び込んだ我々はまず開発プロセスをアジャイルに転換する必要性を感じてスクラム開発を取り入れようと試行錯誤していました。そんな中、関西でアジャイルコーチとして活動されている中村洋さんと秋元さんが開催していた相談会をたまたま見つけて相談しました。そこでホワイトボードの中央に書かれた言葉が「アウトカム」でした。

    何のためにプロダクト開発をアジャイルにするのか?開発プロセスを変えてアウトプットを増やすだけではなく、ビジネスの成果=アウトカムにつなげなければ我々の課題は解決しないと気付かされました。「アウトカムは何か?」を問いかけ続けてプロダクトを成長させていくことがアジャイルの本質だと気付きました。

    アウトカムを得るためにはプロダクトとその顧客をよく知る人の存在が重要だと考えました。そこで、チームで一番のベテランエンジニアが経験ゼロからプロダクトマネジメントを担当することになりました。そこから1年間、まずは開発チームにスクラムを取り入れて、新体制のアウトプットを安定させる事に取り組みました。その間にプロダクトマネージャーはスクラムのプロダクトオーナーとしての振る舞いを学びました。そして2年目、プロダクトのアウトカム創造をチーム目標に設定して本格的にプロダクトマネジメントに取り組みました。

    2年前の再結成からチームのマネジメントを担当しているエンジニアリングマネージャーと、自身も新たなステージへ飛び込んでチャレンジしているプロダクトマネージャーが、アジャイルを取り入れてプロダクトのアウトカム創造に試行錯誤してきたチームの取り組みについてそれぞれの視点でお話しします。

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - 独立QAチーム1年戦記:スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum

    45 Mins
    Talk
    Intermediate

    English follows:

    「Scrum@Scale(S@S)を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター(QAエンジニア・テストエンジニア ・などなど)もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA(Visionary QA)」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

    開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト(Agile Testing)』(翔泳社)は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

    さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ(テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える)。

    このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

    "In a 100-strong software development organization which runs Scrum@Scale, an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

    Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

    Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

    With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

  • Ryuku Hisasue
    keyboard_arrow_down

    Ryuku Hisasue - 良いチームを形成する方法 〜リーダーのいない組織を大学生が挑戦〜

    45 Mins
    Talk
    Beginner

    このセッションでは,大学のPBL(Project Based Learning)でリーダーのいない組織を形成し,その活動の中でどのようにチームが成長してきたかをお伝えします.

    いま,日本の大学ではPBLという学習方法が広く実施されています.PBLとは,実際にプロジェクトチームを形成してプロダクトを作る経験を得ることによって,チーム開発やチームマネジメントの手法について学ぶことができる学習手法です.私が所属する大学でもPBLのカリキュラムがあり,スクラムを用いてプロダクトを作るという経験を得ました.しかし,私たちのチームはほかのチームとことなりリーダーを決めずに活動してきました.そして,その結果として,とても良いチームを形成できたと感じています.

    リーダーもいなく,開発初心者が集まるプロジェクトで,どのようなことに苦労したか紹介・分析し,どのようにいいチームに進化することができたのかお話ししていきます.

  • Shigeo Konno
    keyboard_arrow_down

    Shigeo Konno - なんちゃってアジャイルコーチが、コーチングを受けて気づいたことを共有します

    Shigeo Konno
    Shigeo Konno
    Agile coach
    NEC
    schedule 3 weeks ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    アジャイルでは、なぜ支援者がトレーナーではなくコーチなのか?
    どっかに引っかかりを感じながら、でも、なんとなく見ないふりをして、アジャイルコーチのマネごとをしてきました。
    アジャイル支援サービスを構築して、販売して、徐々にお客さんからも評価いただくうちに、
    自分がやっていることが本当にアジャイルコーチなのかに自信を持てなくなってきました。

    ある日、流石に見ないふりが苦しくなって、
    コーチを探し始めたら、わざわざ時間をとってたくさんのコミュニティの仲間が相談に乗ってくれて
    スーパーコーチのAkiさんにたどり着きました。

    現時点では導入となる6回のセッションが終わった段階、
    旅の途中ですが、同じもやもやを持っている方に何かの助けになればと思って、自身の体験を共有します

    ※発表内容は個人の主張・主観であり、所属している組織とは関係ないものになります

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - コミュニティ活動で得られた知識と希望~オンライン勉強会200回参加して感じたこと~

    aki matsuno
    aki matsuno
    engineer
    -
    schedule 1 week ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    完全未経験&文系でソフトウェア開発の道に飛び込んで3年半、仕事で少しずつ成果が出せるようになったものの、度重なる挫折と大きな無力感を抱いていた自分は、藁にも縋る想いでオンライン勉強会への参加を始めました。

    そこで出会ったのは、アジャイル開発をはじめとしたソフトウェア開発を豊かにする多種多様な知見と、常に変化を楽しんでお互いに刺激を与え続けているコミュニティの方々でした。

    素敵な出会いに囲まれた自分は、焦燥感から参加していた勉強会が楽しくなるばかりか、これまで嫌いだった"学ぶ"という行為が楽しく感じられるようになりました。
    気が付くと、物事を継続することが苦手だった自分は毎週勉強会に参加して毎日読書するようになり、200回の勉強会参加&100冊弱の読書をしていました。

    そして、コミュニティの方々と一緒に学びを深めるにつれ、知識が身につくのみならず"自分自身と向き合うこと"の重要性を意識するようになりました。

    今回は、自分がアジャイル開発や様々な学問から学んだ知識やもらった希望、そして自分に多数の知識と驚くほど大きなエネルギーをくれたコミュニティの方々の話をしてみようと思います。

  • Shota Suzuki
    keyboard_arrow_down

    Shota Suzuki - 商用車メーカーの内製DXスクラムチーム奮闘記  ~スクラムブルーからの脱却と成長~

    Shota Suzuki
    Shota Suzuki
    DX Dept.
    Hino Motors Ltd.
    schedule 2 weeks ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    トラック・バスといった商用車のメーカーである日野自動車は、コネクティッド技術や車両IoTデータを活用したソリューション開発にチャレンジしています。
    より早く・多くの価値をお客様にお届けするための施策として、あるプロダクトの開発を、内製主体でのスクラム開発で進めることにしました。
    21年7月にver1.0のプロダクトをリリースを目指して、現在も開発を継続中です。

    チームメンバーにアジャイル経験者はゼロ、半数はシステム開発の初心者、おまけに仕事はフルリモート前提・・・
    不安が募る船出でしたが、パートナー会社(NEC)によるコーチング・共同開発などの取り組みを通じて、習熟と改善を繰り返してきました。
    企画から数えて約1年、8回の開発スプリントを通じて、チームとして工夫してきたこと、乗り越えてきたこと、学んだことを共有します。
    スクラムの世界に足を踏み入れたばかりの「よちよちチーム」ですが、私たちなりの創意工夫が皆さんの参考になれば幸いです。

  • Takeshi Kakeda
    keyboard_arrow_down

    Takeshi Kakeda - 「IKIGAI」と「マルチ・ポテンシャライト」で最強アジャイルチームできるかな?

    Takeshi Kakeda
    Takeshi Kakeda
    Owner
    Zensow
    schedule 1 week ago
    Sold Out!
    90 Mins
    Workshop
    Intermediate

    a4310d2b6582d11a5058a7031d619a09.png

    コミュニケーション、コラボレーションについての様々な考え方や手法を用いて、スクラムマスターはチームをよりよい状態に導こうとしているでしょう。

    一方で、本セッションでは少し視点を変えて「個人」の視点でチームを考えてみます。

    2015年頃から「生きがい」という日本語の概念が徐々に世界に広がっていき、いまや世界中にIKIGAIとして知られるようになりました。

    同じく2015年頃から飽きっぽく移り気、器用貧乏、という否定的にとられがちな個性を「マルチ・ポテンシャライト(様々な可能性を持つ人)」と視点を変えポジティブに捉えるムーブメントが生まれました。

    もし、チームメンバーが全員「IKIGAI」を見つけて、「器用貧乏」のようなネガティブイメージを持つ人がもっと前向きになれたら、どう変わるでしょうか?

    本ッションでは、「IKIGAI」と「マルチポテンシャライト」の考え方を用いて、それぞれのメンバーが、個人として「仕事」を超えて「人生」をよりよく生きる、チームとしてよりよく生きるための考え方と個人ワークを学び体験します。

     

     

  • Yuya Kazama
    keyboard_arrow_down

    Yuya Kazama - 開発が加速していくために、テストコードを書き始める前から考えるべきテストの話

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 1 week ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    システム開発において、テストは切っても切り離せない存在です。
    しかし、「カバレッジを満たすために書いている」「テストコードは書いたが、本番でトラブルが多発している」となっていませんか?
    実は、テストコードを書き始める前に既に勝負は決まっています。

    本セッションでは、実際に例題を使って皆さんにも考えてもらいます。そして、作業ではないテストについて“体験”し“実感”してもらいます。

    本セッションの体験を通じて、「開発エンジニア」「テストエンジニア」がともに考えて作り出す、一歩先行くテストの世界をご紹介します。

  • Jean-Baptiste Vasseur
    keyboard_arrow_down

    Jean-Baptiste Vasseur - リーダーとは何か、その答えをずっと探していたがCAL2を受けてやっと理解し始めた話

    45 Mins
    Talk
    Intermediate

    昨年弊社のメンバーが徐々に増えてきて、自分としてよりリーダーらしい立場と振る舞いをとっていきたいと考え始めましたが、そもそもリーダーとは何か、そこからスタートする必要がありました。

    色んな書籍やネット記事を読めば大体のことが理解できますが、相反する考え方もあれば自分としてこういうリーダーになりたいというものがちゃんとフィットするものも見つかりませんでした。

    そこで2020年9月にScrum AllianceのCAL(Certified Agile Leadership)プログラムに出逢いました。

    よし!CAL1とCAL2を取得してヒント探しに行くぞ、と。

    そして2021年4月現在、無事終わりました。確かにヒントは得られました。

    しかし、経験したこと、学んだこと、得られたものは想像を遥かに超えていました。

    皆さんにもぜひアジャイルリーダーの旅に出て欲しいという気持ちを込めて私のアジャイル・リーダー・ジャーニーを語りたいと思います。

help