$30 off During Our Annual Pro Sale. View Details »

形式スクラムの功罪

 形式スクラムの功罪

2023/07/01 開催
スクラムフェス大阪 | Scrum Fest Osaka 2023 での発表資料です。

yumechi(Motoki Hirao)

July 01, 2023
Tweet

More Decks by yumechi(Motoki Hirao)

Other Decks in Business

Transcript

  1. 形式スクラムの功罪

    Motoki Hirao


    View Slide

  2. twitter: @__yumechi misskey: @[email protected]
    発表者について

    ● Motoki Hirao

    ● twitter: @__yumechi misskey: @[email protected]
    ● 4月から転職して開発者になりました(それまではスクラムマスターを1年
    ほど)

    ● なぜかスクラムとかアジャイルを入れるぜ!ってタイミングで会社や組織に
    所属しています

    ● 趣味はゲームやカンファレンス(主に関東)に参加すること


    View Slide

  3. twitter: @__yumechi misskey: @[email protected]
    初めての大阪、どきどきわくわくしてます

    ● 通過駅や乗り換えのタイミングでご飯食べに降りたことはありますが、それ
    以外では来たことがない

    ● 日曜日は観光して帰る予定なので、おすすめスポット有ればおしえてくださ
    い!

    ● 特になければ大阪城行くつもりです


    View Slide

  4. twitter: @__yumechi misskey: @[email protected]
    この発表に関しての注意事項

    ● 私個人の経験による主観のため、N=1の内容でしかありません

    ● 記憶ベースで書いているので事実が若干歪んでいる可能性もあります

    ● 特定の所属組織の話ではなく、多くの場所でアジャイル・スクラムを実践す
    るんだ!となって現実的に私・私たちが見てきた課題点を取り上げていま
    す


    View Slide

  5. twitter: @__yumechi misskey: @[email protected]
    本発表の概要

    ● ウォーターフォールライクな開発チームにスクラムを導入する難しさ

    ● 形式的なスクラムで解決できた問題

    ● 形式スクラムの問題

    ● 今後うまくやれそうな導入を考えてみる


    View Slide

  6. twitter: @__yumechi misskey: @[email protected]
    本発表の概要

    ● ウォーターフォールライクな開発チームにスクラムを導入する難しさ

    ● 形式的なスクラムで解決できた問題

    ● 形式スクラムの問題

    ● 今後うまくやれそうな導入を考えてみる


    View Slide

  7. twitter: @__yumechi misskey: @[email protected]
    本発表の概要

    ● ウォーターフォールライクな開発チームにスクラムを導入する難しさ

    ● 形式的なスクラムで解決できた問題

    ● 形式スクラムの問題

    ● 今後うまくやれそうな導入を考えてみる


    View Slide

  8. ライクって

    なんやねん!

    https://soco-st.com/1722 より


    View Slide

  9. twitter: @__yumechi misskey: @[email protected]
    なぜウォーターフォール「ライク」なのか

    ● 厳密にウォーターフォールを実行するのは難しいし、体感100%そのプロ
    ジェクトやプロダクトルールの何かが運用されている

    ○ 参考: だったら WF でやればいいぢゃない! 

    ○ https://www.docswell.com/s/tommy109/K2XRMZ-2023-01-12-231349

    ● おそらく社会の共通認識的にこれくらいの概念のなにかだけが残っている
    (と、発表者は考えている)

    ○ 要求分析、設計、実装、テスト、総合・受入テスト、リリース

    View Slide

  10. twitter: @__yumechi misskey: @[email protected]
    そんな中でスクラム・アジャイルを学習する壁

    ● 人はパターン認識的に学習しようとするので、ウォーターフォールライクな
    手法と対比して学習しようとする

    ○ https://ja.wikipedia.org/wiki/パターン認識

    ○ アジャイルソフトウェア開発宣言は対話・協調を大事にし、変化し続けるソフトウェア開発
    という点でイメージがしやすい(表面的には…)


    View Slide

  11. twitter: @__yumechi misskey: @[email protected]
    マッピングできないスクラムの概念

    ● スクラムイベントがそもそもマッピング不可能

    ○ 朝会、夕会 → デイリースクラム

    ○ プロトタイピングなもの? 基本設計? → スプリントレビュー

    ○ 計画や要件定義?? → スプリントプランニング

    ○ 振り返り?(そもそもウォーターフォールライクにはない) → スプリントレトロスペクティブ

    ● 役割についてもマネージャー → スクラムマスター??

    ● プロダクトオーナーとマネージャーの違いは??


    View Slide

  12. 知識が共通認識

    になっていない場合は

    更に色々出てくる…


    View Slide

  13. はい、理解できません

    終了です


    View Slide

  14. はい、理解できません

    終了です

    https://www.irasutoya.com/2014/03/blog-post_2687.html より


    View Slide

  15. うまく行った

    ワークを紹介


    View Slide

  16. twitter: @__yumechi misskey: @[email protected]
    頑張ってみんなで学びましょう

    ● 実際やってみて良かったこと

    ○ スクラムガイドをみんなで読んで理解を深める(定期的に)

    ○ スクラムガイドをみんなで音読する

    ○ このプロダクト・このプロジェクトでの役割やスクラムイベントで何をやるかの詳細をつめて
    可視化する

    ■ ドキュメントの準備が大事、体制図は大事

    ● 実際やってみてうまく行かなかったこと

    ○ 各々でスクラムガイドを読んでもらう

    View Slide

  17. twitter: @__yumechi misskey: @[email protected]
    頑張ってみんなで学びましょう

    ● 実際やってみて良かったこと

    ○ スクラムガイドをみんなで読んで理解を深める(定期的に)

    ○ スクラムガイドをみんなで音読する

    ○ このプロダクト・このプロジェクトでの役割やスクラムイベントで何をやるかの詳細をつめて
    可視化する

    ■ ドキュメントの準備が大事、体制図は大事

    ● 実際やってみてうまく行かなかったこと

    ○ 各々でスクラムガイドを読んでもらう

    View Slide

  18. twitter: @__yumechi misskey: @[email protected]
    頑張ってみんなで学びましょう

    ● 実際やってみて良かったこと

    ○ スクラムガイドをみんなで読んで理解を深める(定期的に)

    ○ スクラムガイドをみんなで音読する

    ○ このプロダクト・このプロジェクトでの役割やスクラムイベントで何をやるかの詳細をつめて
    可視化する

    ■ ドキュメントの準備が大事、体制図は大事

    ● 実際やってみてうまく行かなかったこと

    ○ 各々でスクラムガイドを読んでもらう

    みんなで
    アンラーンだ!

    View Slide

  19. 自分もよくわからない!

    というのを相手に伝えながら

    同期的にワークするのも

    時には大事


    View Slide

  20. 心理的にも自分一人だけが

    わからないという

    状態を防げる(副次的な効
    果)


    View Slide

  21. みんなで行け

    的なやつ

    https://loosedrawing.com/illust/1129/ より


    View Slide

  22. twitter: @__yumechi misskey: @[email protected]
    ● 関係者に我々はスクラムをやります!ということを伝える

    ○ コミュニケーションが増えて手戻りが減るとかのメリット

    ○ MTGが多少増えて、リーダー・マネージャーを介さないコミュニケーション増えるデメリット

    ● スプリントやイベントをいつ行うのか調整する

    ○ 体感、なぜか2週間スプリントで始めるものの1週間にすることが多い

    ○ (スプリントの経験数が増えるとその分うまくスプリントが回るようになるため)

    ○ スクラムイベントの時間が長すぎても良くないので調整する

    スクラムのメリットや進め方を浸透させる


    View Slide

  23. twitter: @__yumechi misskey: @[email protected]
    本発表の概要

    ● ウォーターフォールライクな開発チームにスクラムを導入する難しさ

    ● 形式的なスクラムで解決できた問題

    ● 形式スクラムの問題

    ● 今後うまくやれそうな導入を考えてみる


    View Slide

  24. 形式スクラムの定義…

    スクラムイベントと

    各種役割は決めて

    動いていることとします


    View Slide

  25. twitter: @__yumechi misskey: @[email protected]

    View Slide

  26. まとめると、

    納得感かなぁ

    https://loosedrawing.com/illust/1378/ より


    View Slide

  27. twitter: @__yumechi misskey: @[email protected]
    ウォーターフォールライクで起きがちな問題

    ● これまでのコミュニケーション

    ○ リーダー・マネージャーが決めてくる

    ○ その決定に対して、開発者視点での問題は上がりづらい

    ● これまでのスプリント・イテレーション

    ○ 機能ごと・プロジェクトごとになるので
    スパンが長い、リズムがない

    ○ 毎回ふりかえることはない、というか
    忘れる


    View Slide

  28. twitter: @__yumechi misskey: @[email protected]
    スクラムの持つ性質によるメリット

    ● コミュニケーション

    ○ スクラムイベントで必然的に増える

    ○ いろいろな人の発言を通して、知見や考え方が共有される

    ○ ふりかえりから課題や問題を共有し、より良いアイディアで解決できる

    ● スプリント・イテレーション

    ○ タイムボックスが明確に区切られているので、
    次までに何をするかが明確

    ○ どこまで進められるのかの合意形成もできる

    ○ イベントを通してプロセスの改善もできる


    View Slide

  29. ただし、これは

    どちらかといえばこれまでの

    コミュニケーション

    に問題があり、それが顕在化

    しただけに過ぎないのだ…


    View Slide

  30. 開発者も言われたものを

    作るのではなく、

    より便利になるものを

    作りたい(はず)


    View Slide

  31. twitter: @__yumechi misskey: @[email protected]
    専門性を生かした仕事をする

    ● コミュニケーションが改善されて専門性を生かし、色々任せながら進められ
    るようになる

    ○ コミュニケーション量が増え、タスクの取りこぼしが減り役割分担が明確に

    ○ POはプロダクトのことを考えながら優先順位を考える

    ○ SMは開発者を支援しつつ、プロダクト開発がうまく進むようにいろいろ動き回る

    ○ 開発者は開発視点で意見しながらプロダクトに貢献する

    View Slide

  32. コミュニケーションを

    密にすることで

    私たちはプロダクトの

    方向性を理解し、

    ユーザーの行動変容をどう

    起こしたいのかを理解する


    View Slide

  33. プロダクトが向かう

    方向やユーザーから

    考えたときの

    納得感がある!

    https://loosedrawing.com/illust/987/
    より


    View Slide

  34. 言われたものを作る

    を超え始めた!


    View Slide

  35. ただし、

    デリバリ速度の改善

    まではわからないなぁ

    という感想…(これまでの
    計測が甘い問題も含む)


    View Slide

  36. =スクラムは開発速度を

    改善する銀の弾丸ではな
    い


    View Slide

  37. ただ納得感があることは

    もっと良いステップに

    つながるはず

    (うまく言葉にできない…)

    https://loosedrawing.com/illust/1434/

    より


    View Slide

  38. twitter: @__yumechi misskey: @[email protected]
    本発表の概要

    ● ウォーターフォールライクな開発チームにスクラムを導入する難しさ

    ● 形式的なスクラムで解決できた問題

    ● 形式スクラムの問題

    ● 今後うまくやれそうな導入を考えてみる


    View Slide

  39. よし、順調にイベント
    が回っているな!


    View Slide

  40. ただなんかうまくいっ
    てない気がするぞ?


    View Slide

  41. アジャイルソフトウェア

    宣言に立ち返ると


    View Slide

  42. 「プロセスやツールよ
    りも個人と対話を」

    と一番上に書いてある


    https://agilemanifesto.org/iso/ja
    /manifesto.html


    View Slide

  43. アジャイル宣言の背後
    にある原則

    に立ち返ると


    View Slide

  44. 「顧客満足を最優先
    し、価値のあるソフト
    ウェアを早く継続的に
    提供します。」

    https://agilemanifesto.org/iso/ja/principles.html より


    View Slide

  45. 「チームがもっと効率を高
    めることができるかを定期
    的に振り返り、それに基づ
    いて自分たちのやり方を最
    適に調整します。」

    https://agilemanifesto.org/iso/ja/principles.html より


    View Slide

  46. おやおや???


    View Slide

  47. 形式スクラム最大の

    弱点、それは…


    View Slide

  48. 顧客への価値提供より

    プロセスに従う

    選択をしてしまうこと

    🙀

    View Slide

  49. プロダクトを良くする

    という本質から

    離れてしまうこと

    😇

    View Slide

  50. twitter: @__yumechi misskey: @[email protected]
    イベントが定義されていることによるデメリメ

    ● スクラムイベントが明確に定義されていることが良い面も悪い面も包含して
    いる

    ○ 良い面: 開発を一定のリズムで行う、コミュニケーションを取れる、スプリントゴールを設定
    して明確な形で進められる

    ○ 悪い面: スクラムイベントをやっていればスクラムという誤った認識や誤解を持ってしまう、
    スクラムイベントに参加することが仕事になってしまう(コミュニケーションを取ることはしな
    くてもよい)


    View Slide

  51. twitter: @__yumechi misskey: @[email protected]
    ウォーターフォールライク概念の亡霊

    ● ウォーターフォールライクな開発プロセスにマッピングされたアジャイル・ス
    クラムから外れた概念のまま進行してしまう危険性

    ○ リリースなのか、デプロイなのか、納品なのか

    ○ ストーリーポイントなのか、工数なのか

    ○ 設計?実装?テスト?

    ● これまでの開発プロセス・関係性に引き戻される危険

    ○ 今までのやり方でもなんとかうまくやれていたから戻そう

    ○ 開発者はMTGに出ずに開発に集中したい etc…


    View Slide

  52. twitter: @__yumechi misskey: @[email protected]
    これが進行していくとどうなるのか?

    ● 必要なメンバーが揃わないままスクラムイベントスタート

    ○ 他の会議をしょっちゅう優先してしまう、絶対イベントに来ないチームメンバー

    ○ あとから議事録を眺めて個別の追加の
    MTGなどが色々組まれる

    ● ファシリテーターだけが方向性を定める形になってしまう

    ○ 気がついたらファシリテーターが1時間話して終わってしまった!

    ○ ファシリテーターが毎回固定…

    ● etc…etc…


    View Slide

  53. twitter: @__yumechi misskey: @[email protected]
    これが進行していくとどうなるのか?

    ● 必要なメンバーが揃わないままスクラムイベントスタート

    ○ 他の会議をしょっちゅう優先してしまう、絶対イベントに来ないチームメンバー

    ○ あとから議事録を眺めて個別の追加の
    MTGなどが色々組まれる

    ● ファシリテーターだけが方向性を定める形になってしまう

    ○ 気がついたらファシリテーターが1時間話して終わってしまった!

    ○ ファシリテーターが毎回固定…

    ● etc…etc…


    もう
    疲れちゃって…

    View Slide

  54. twitter: @__yumechi misskey: @[email protected]
    疲れてくると負のループに陥る

    ● これまで問題になってたことが戻ってくる

    ○ リーダーだけMTGに出ましょう→コミュニケーション不足

    ○ ふりかえりはしません!→ プロセスが改善されない

    ○ スケジュールを決めたのでこの通りやりましょう
    →開発の課題が上がりにくくなり、大変に
    なる

    ● 単純な疲れから生産性のダウン、モチベーション低下、チーム離脱…

    ○ 疲れて労働時間が長くなる、全くあまりいいことはない

    ■ 軽く調べても「我が国における労働生産性をめぐる現状と課題」など出てくる 

    ■ https://www.sangiin.go.jp/japanese/annai/chousa/rippou_chousa/backnumber/2018p
    df/20180601041.pdf


    View Slide

  55. twitter: @__yumechi misskey: @[email protected]
    疲れてくると負のループに陥る

    ● これまで問題になってたことが戻ってくる

    ○ リーダーだけMTGに出ましょう→コミュニケーション不足

    ○ ふりかえりはしません!→ プロセスが改善されない

    ○ スケジュールを決めたのでこの通りやりましょう
    →開発の課題が上がりにくくなり、大変に
    なる

    ● 単純な疲れから生産性のダウン、モチベーション低下、チーム離脱…

    ○ 疲れて労働時間が長くなる、全くあまりいいことはない

    ■ 軽く調べても「我が国における労働生産性をめぐる現状と課題」など出てくる 

    ■ https://www.sangiin.go.jp/japanese/annai/chousa/rippou_chousa/backnumber/2018p
    df/20180601041.pdf

    スクラムマスター
    出番です!

    View Slide

  56. twitter: @__yumechi misskey: @[email protected]
    正しいスクラムに向き直りをするために

    ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビス
    クラムサバイバルガイドを読んで実践する

    ○ https://www.maruzen-publishing.co.jp/item/b304740.html

    ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し

    ○ 概念をもう一度捉え直す

    ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い意味で外れてい
    るのかを考える

    ● ファシリテーターを毎回変えてみる


    View Slide

  57. twitter: @__yumechi misskey: @[email protected]
    正しいスクラムに向き直りをするために

    ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビス
    クラムサバイバルガイドを読んで実践する

    ○ https://www.maruzen-publishing.co.jp/item/b304740.html

    ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し

    ○ 概念をもう一度捉え直す

    ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れている
    のかを考える

    ● ファシリテーターを毎回変えてみる


    あんまり
    うまくいかなかった

    View Slide

  58. twitter: @__yumechi misskey: @[email protected]
    それぞれに対してうまく行かなかったポイント

    ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビス
    クラムサバイバルガイドを読んで実践する

    ○ https://www.maruzen-publishing.co.jp/item/b304740.html

    ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し

    ○ 概念をもう一度捉え直す

    ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れている
    のかを考える

    ● ファシリテーターを毎回変えてみる


    自分一人で理解してもついてこない
    なんとなく反応薄め…
    個人のファシリテーション能力に強依存、
    イベントの再現性がなくなってしまう

    View Slide

  59. twitter: @__yumechi misskey: @[email protected]
    今ふりかえるとこうしたい

    ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビス
    クラムサバイバルガイドを読んで実践する

    ○ https://www.maruzen-publishing.co.jp/item/b304740.html

    ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し

    ○ 概念をもう一度捉え直す

    ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れている
    のかを考える

    ● ファシリテーターを毎回変えてみる


    みんなでスクラムに問題があることを理解し、
    改善に向けて活動する
    外部者やアジャイルコーチに入ってもらう
    何度か様子を見る、まずはデイリースクラムから。
    デイリースクラムは回数をこなしやすいので最適。

    View Slide

  60. チームメンバー自身が

    各々アジャイルって

    何だ?を理解する

    必要がある


    View Slide

  61. 結局最後は

    マインドセットの定着
    で本質的に考えられる
    チームに

    なるのを待つしかない


    View Slide

  62. よし、順調にイベント
    が回っているな!


    View Slide

  63. 着目すべきは

    ソフトウェアの提供価値。

    プロセスを見てるのは

    危険信号。


    View Slide

  64. 確 集 公 尊 勇

    約 中 開 敬 気


    View Slide

  65. twitter: @__yumechi misskey: @[email protected]
    チームの局所最適化は起きていた

    ● 開発手法が同じプロダクト内でバラバラしていた

    ● システム間で開発手法を分断すると…?

    ○ POと話している量が違うので、エンジニア間でも視座の違いが生まれやすくなる

    ○ プランナー・ディレクター間でもエンジニアの理解度が変わってしまう

    ■ ただ開発を委託する人から、一緒にプロダクトを盛り上げていく人に代わっている人
    に代わっている

    ■ 人によって扱いが…


    View Slide

  66. twitter: @__yumechi misskey: @[email protected]
    開発手法は違ってもいいけれど

    ● アジャイル・スクラムを採用していないチームにも文化的に浸透が必要かも
    しれない

    ● ステークホルダーに対してアジャイル・スクラムは手法が変わるだけではな
    く、文化形成が変わり関係性も変わること、と認識を変えてもらう必要が
    あったのかも

    ● いろいろな手法がある状態が無視できないレベルになったら、組織自体が
    変わっていく決断も必要かもしれない(私に権限はないですがw) 


    View Slide

  67. 昨日のKeynote聞いた

    感想では、このあたりの

    突破力は身につけないと

    あかんなとなりました😇😇


    View Slide

  68. twitter: @__yumechi misskey: @[email protected]
    本発表の概要

    ● ウォーターフォールライクな開発チームにスクラムを導入する難しさ

    ● 形式的なスクラムで解決できた問題

    ● 形式スクラムの問題

    ● 今後うまくやれそうな導入を考えてみる


    View Slide

  69. これはもう、

    スクラムという言葉も

    概念も一回持ち込まない


    View Slide

  70. twitter: @__yumechi misskey: @[email protected]
    スクラムを導入する前にアジャイルマインドをやる

    ● 過去の経験からアジャイルの代表例としてスクラムを導入しようと試みてき
    たが、スクラムイベントというプロセスに飲み込まれた

    ○ スクラムのプロセスに頭を固定するのは絶対に避けたい

    ● なのでいきなりスクラムに変えよう、はなんとしても避けたい

    ○ アジャイルソフトウェア開発宣言や、アジャイル宣言の背後にある原則を読む

    ○ 現状の自分たちの開発においてコミュニケーション不足なところから変える

    View Slide

  71. twitter: @__yumechi misskey: @[email protected]
    レトロスペクティブ(ふりかえり)から入れたい

    ● 自分たちを知らないと手の打ちようがない、まずは自分たちを知ろう

    ● 経験上、その結果やプロセスについてのふりかえりは十分でないことも多
    い

    ○ うまくいかなかったプロジェクトとかでものど元過ぎれば
    … みたいな実感はある

    ○ とりあえず今の方法でやれているのでやっている、とかは十分にある

    ● コミュニケーションが少なめでもうまく行くのであれば問題ないので無理に
    やらない

    ○ 場合によってはアジャイル・スクラムを導入しないのも選択肢に入れて良い

    View Slide

  72. twitter: @__yumechi misskey: @[email protected]
    どうふりかえるか

    ● ふりかえりカタログを見ながら選定する

    ○ ふりかえりカタログ / Retrospective Catalog - Speaker Deck 

    ○ https://speakerdeck.com/viva_tweet_x/retrospective-catalog-59bd3a29-314c-45d
    d-911b-f8e5f1308333

    ● テーマによってふりかえり手法を変えたり…

    ○ 普段の開発プロセスのふりかえりは
    KPTA

    ○ 前向きになりたいときは Fun, Done, Learnなど

    ● ふりかえりの手法選定は自分もまだまだ経験不足なので試行錯誤中


    View Slide

  73. twitter: @__yumechi misskey: @[email protected]
    次はデイリースクラムをやりたい

    ● 普段から顔合わせしてコミュニケーションは増やしておきたい

    ○ コミュニケーションしたことがない相手を減らしておくのは大事だと思う

    ● 毎日話すことによって日々の動向を知りつつ、課題となっている点を共有
    し、問題解決や優先順位を相談したい

    ● 可能ならモニタリングとかも一緒に見ながら話せるといいなーとか


    View Slide

  74. twitter: @__yumechi misskey: @[email protected]
    以降のスクラムイベントは必要に応じて

    ● 本質的にやりたいのは気持ちよく働いて、良いプロダクトを顧客・ユーザー
    に届けることであるので、スクラムを導入することではない

    ○ スクラムを導入するという方法の目的化は避けなければいけない

    ● 他のスクラムイベントはチームの様子を見ながら

    ○ デイリーのところでコミュニケーションがいっぱいいっぱいな感じであれば、一旦デイリー
    に慣れてもらうまで待つ

    ○ チームが成熟していないのにコミュニケーション頻度が高いスクラムを行うのは難しいの
    で…


    View Slide

  75. 対話しながら

    そのチームにとって

    必要で成長できる

    方法を提案したい

    https://loosedrawing.com/illust/1411/ より


    View Slide

  76. twitter: @__yumechi misskey: @[email protected]
    自分はスクラムマスターが適切だったのか?

    ● 技術に触れる時間が減ったことに違和感があった

    ○ 元々、開発のリードとしてテックリード寄りの考え方だった

    ■ 開発したいものを渡すことにやや抵抗があった

    ○ アジャイルスクラムについて教えながら、技術的なインプットもアウトプットも行っていた

    ● スクラムマスターになった経験自体はとてもよかった、一方で今の自分が
    貢献できることは開発のほうが大きいという感覚

    ○ 開発者視点でアジャイルを支えられることもたくさんある、自動化など

    View Slide

  77. 自分のキャリアの壁打ち
    を誰か… 懇親会で…


    View Slide

  78. twitter: @__yumechi misskey: @[email protected]
    まとめ

    ● 導入時にはみんなでアジャイル・スクラムを学習しよう

    ● アジャイル・スクラムはコミュニケーションが増えるため、コミュニケーションフローの
    改善に繋がり、プロダクトの方向性に納得感が生まれる

    ● スクラムのイベントをこなす流れになると、定期的にあるイベントをこなすだけになり
    プロダクトへの指向性が薄れ、本質から遠ざかってしまう

    ● スクラム導入を目的とせず、アジャイルなマインドを身につける。発表者も試行錯誤
    中!まずはチームとの対話を行う「ふりかえり」が鍵


    View Slide

  79. twitter: @__yumechi misskey: @[email protected]
    利用情報

    ● スライド作成: Google Slide https://www.google.com/slides/about/

    ● フォント: Noto Sans https://fonts.google.com/noto/specimen/Noto+Sans

    ● 利用画像

    ○ フリーイラスト素材集|ちょうどいいイラスト https://tyoudoii-illust.com/

    ○ Loose Drawing | 無料で商用利用可なフリーイラスト https://loosedrawing.com/

    ○ shigureni free illust │ 素朴で可愛い、女の子のイラスト素材サイト https://www.shigureni.com/

    ○ 商用可・フリーイラスト素材|ソコスト https://soco-st.com/

    ○ ドット絵ダウンロードサイト DOTOWN|無料の素材サイト https://dotown.maeda-design-room.net/

    ○ かわいいフリー素材集 いらすとや https://www.irasutoya.com/


    View Slide