Upgrade to Pro — share decks privately, control downloads, hide ads and more …

人類よ!これがスクラムマスター・アジャイルコーチだ!アジャイル開発の10年と今後を語ろう / Agile coach and Scrum master for 10 years

人類よ!これがスクラムマスター・アジャイルコーチだ!アジャイル開発の10年と今後を語ろう / Agile coach and Scrum master for 10 years

今回は、ゲストに著名なアジャイル実践者である @TAKAKING22 さまをお招きして、アジャイル開発のこれまでの10年、これからの10年を議論させていただきます。

今や当然になりつつあるアジャイル開発やスクラムですが、その起源をたどると、2001年に公開された「アジャイルマニフェスト」にたどり着きます。

そこから10年後の2011年、アジャイルマニフェストが書かれたソルトレイクシティで開催されたAgile Conferenceでは、多くのマニフェスト署名者が集まる歴史的なイベントになりました。

そしてさらに10年が過ぎ、今年はアジャイルマニフェスト誕生20周年を迎えます。オンラインの誕生イベントも開催され(動画視聴可能)、次の10年が語られ始めました。

発表者の二人は、過去に同じ開発プロジェクトにおいて、アジャイル開発を経験しました。私はスクラムマスターとして参加し、@TAKAKING22はエンジニアとしての参加です。

そのプロジェクトは、1000人を超える開発組織の中で初の「アジャイル開発を導入する」と謳ったプロジェクトでした。もちろん途中、困難はありましたが、無事にプロダクトはリリースされ、プロジェクトが終わり、ふたりは異なる環境でスクラムマスターやアジャイルコーチの経験を積んでいきます。

共に歩んだアジャイルプロジェクトから10年。それぞれの経験をふりかえりながら学びを確認し、今後の10年を考えるセッションです。

なお、このイベントは、日本のアジャイル開発の第一人者である平鍋健児氏によるデブサミ2012のセッション「アジャイル開発の10年と今後を語ろう」へのオマージュでもあります。平鍋氏の書籍『アジャイル開発とスクラム 第2版』も8年の時を経て第2版が今月発売され、@TAKAKING22も著者に名前を連ねています。

イベントページ: https://mabl-japan.connpass.com/event/207649/

Dai Fujihara

April 27, 2021
Tweet

More Decks by Dai Fujihara

Other Decks in Programming

Transcript

  1. About Me 『アジャイル開発とスクラム』 https://www.amazon.co.jp/dp/4798129704/ 、『リーン開発の現場』 https://www.amazon.co.jp/dp/427406932X 藤原 大 / Dai

    Fujihara mabl Inc. Japan Lead • 現在: 独立してスーパーアジャイルコーチ CTOやEMへのコーチング 開発組織の技術顧問(プロセス、 QAなど) mablの日本顧客向け業務全般担当 • メルカリ: エンジニアリングマネージャ( EM) Software Engineer in Test(SET) テスト自動化、QA組織立ち上げ • 楽天: EM、アジャイルコーチ • 某SIer: Javaエンジニア • 活動: ◦ 『アジャイル開発とスクラム』寄稿 ◦ 『リーン開発の現場』翻訳 ◦ Twitter: @daipresents ◦ https://daipresents.com/service/
  2. About Guest 及部 敬雄 • Silver Bullet Club(チーム名)所属 • 株式会社デンソーエンジニア

    • 一般社団法人アジャイルチームを支える会理 事 • AGILE-MONSTER.COM(個人事業主) @TAKAKING22 エンジニアとして、様々なドメインのプロダクト開発・運用・新規事業立ち上げを経験。ア ジャイル開発との出会いをきっかけに、最強のチーム・組織をつくることを目標に日々奮 闘している。そこで得た実践知をアジャイルコミュニティなどで発信し続けている。2019年 にチームFA宣言をし、現職にチーム移籍を果たした。新しいチームのかたちを模索して いる。 また、アジャイルコーチ(個人事業主)として様々なチームや組織の支援もしている。 制御不能なアジャイルモンスター
  3. ざっくりとした年表 • 2001〜2010年 ◦ アジャイルマニフェストができた ◦ 2007年ごろ ▪ SIでアジャイルプラクティス導入(藤原) ◦

    2010年 ▪ アジャイル開発をチームになんとなく導入(藤原) ▪ アジャイルカンファレンス初参加(フロリダ、藤原) • はじめての勉強会発表だったきがする ▪ 新人研修にも導入 • 2011〜2020年 ◦ 2011年 ▪ プロジェクトリーダーとしてアジャイル開発プロジェクトを推進 • このあたりまでが『アジャイル開発とスクラム』で書 いた話 • デブサミで話した話 ▪ 藤原: コーチとして次へ ▪ およ: スクラムマスターとして残る • プロジェクト後の話 ▪ ソルトレイクシティでマニフェスト10周年イベント ◦ 2012年頃 ▪ リーンとかんばんの導入(藤原) • デブサミ大阪で話した話 ◦ 2014年 ▪ 現場へ(市場、藤原) ◦ 2017年 ▪ メルカリへ(品質、自動化) • 打倒アジャイルテスティング ◦ 2019年 ▪ 独立(藤原) • アジャイルコーチとして食べていく(というかいかざ るをえなくなった)
  4. 予定しているテーマや質問 • 過去 ◦ はじまりの10年をふりかえる ◦ 我々の10年をふりかえる • 現在 ◦

    スクラムマスターとはなにか? ◦ アジャイルコーチとはなにか? ◦ 当たり前になったアジャイルについて ◦ 日本にマッチしないんじゃね? ◦ 課題がなかなか改善されない現場をどう するか? ◦ 組織の変化・求められるスキルセット • 未来 ◦ 当たり前になったアジャイルの次とは ◦ スクラムマスターに求められるもの ◦ アジャイルコーチに求められるもの • Q&A
  5. 過去: はじまりの10年(2001年〜2010年) アジャイルソフトウェア開発宣言 https://agilemanifesto.org/iso/ja/manifesto.html • 2001年 アジャイルマニフェスト誕 生 • 2002年

    XP祭りはじまる • 2009年 Agile Japan はじまる ◦ メアリー、黒岩さん • 2010年 Agile Conference参加 ◦ 黒岩さんの発表はすごかった (日本人の発表がまだレア) ◦ エンタープライズAgile
  6. 過去: 我々の10年(2011年〜2020年) アジャイルで目指した坂の上の雲 #DevLOVE HangarFlight – Snow Barrage – で発表しました

    #4tate https://daipresents.com/2011/post-3687/ アジャイルで目指した坂の上の雲 #devlove #devlovex #devlovexE https://takaking22.com/2019/clouds-above-the-hill/ • 2011年 ◦ 共同発表 • 2019年 ◦ 続編
  7. Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む https://lean-trenches.com/scaling-agile-at-spotify-ja/ 組織も変わっていく QA iOS (現在から未来?)アジャイル型組織 チームでプロダクトへ Android

    Frontend Backend BI (従来型)ピラミッド型組織 どこに向かうチーム? QA iOS Android Frontend Backend BI ←職能横断的チーム。 チームごとの成熟度を 高く育てられる。チーム 間のコミュニケーション 問題をギルドや支部制 度で弱めている 職能ごと縦割り組織型 → 管理効率が高いが、プロ ジェクト制度だとチームの成 熟度が高まらない。サイロ 化、組織間コミュニケーショ ンの課題がなかなか解決し ない
  8. 現在: 2021年 アジャイルコーチとは? アジャイル・スクラムチームの成熟度モデル https://speakerdeck.com/daipresents/agile-and-scrum-maturity-mode アジャイル・ DevOps時代のCD成熟モデル l https://speakerdeck.com/daipresents/the-continuous-delivery-maturity-model-in-agile-and-devops 成熟度

    テストのプラクティス Level 3 - 最適化: プロセス 改善に集中 本番でのロールバックがほとんどない。欠 陥が見つかってもすぐに Fixされる Level 2 - 定量的に管理: プロセ スは測定・管理されている 品質メトリクスとトレンドは追跡できている。 非機能要件も定義・測定できている Level 1 - 一貫性: アプリの開発 ライフサイクル全体に自動化が 適用されている 自動化されたUTとUATがありUATはテス ターが作成している。開発プロセスの一部 分がテストされている。 Level 0 - 繰り返し可能: プロセ スがドキュメント化・一部自動化 されている UTは自動化。ストーリーをもとにした開発 において部分的にテスト自動化できてい る。 Level -1 - 後退: プロセスは繰 り返せず管理もまだまだで後手 後手 開発後のマニュアルテスト。 DEV/STG/PROのように環境分離。