2023/07/01 開催 スクラムフェス大阪 | Scrum Fest Osaka 2023 での発表資料です。
形式スクラムの功罪 Motoki Hirao
View Slide
twitter: @__yumechi misskey: @[email protected] 発表者について ● Motoki Hirao ● twitter: @__yumechi misskey: @[email protected] ● ４月から転職して開発者になりました（それまではスクラムマスターを１年ほど） ● なぜかスクラムとかアジャイルを入れるぜ！ってタイミングで会社や組織に所属しています ● 趣味はゲームやカンファレンス（主に関東）に参加すること
twitter: @__yumechi misskey: @[email protected] 初めての大阪、どきどきわくわくしてます ● 通過駅や乗り換えのタイミングでご飯食べに降りたことはありますが、それ以外では来たことがない ● 日曜日は観光して帰る予定なので、おすすめスポット有ればおしえてください！ ● 特になければ大阪城行くつもりです
twitter: @__yumechi misskey: @[email protected] この発表に関しての注意事項 ● 私個人の経験による主観のため、N=1の内容でしかありません ● 記憶ベースで書いているので事実が若干歪んでいる可能性もあります ● 特定の所属組織の話ではなく、多くの場所でアジャイル・スクラムを実践するんだ！となって現実的に私・私たちが見てきた課題点を取り上げています
twitter: @__yumechi misskey: @[email protected] 本発表の概要 ● ウォーターフォールライクな開発チームにスクラムを導入する難しさ ● 形式的なスクラムで解決できた問題 ● 形式スクラムの問題 ● 今後うまくやれそうな導入を考えてみる
ライクって なんやねん！ https://soco-st.com/1722 より
twitter: @__yumechi misskey: @[email protected] なぜウォーターフォール「ライク」なのか ● 厳密にウォーターフォールを実行するのは難しいし、体感100%そのプロジェクトやプロダクトルールの何かが運用されている ○ 参考： だったら WF でやればいいぢゃない! ○ https://www.docswell.com/s/tommy109/K2XRMZ-2023-01-12-231349 ● おそらく社会の共通認識的にこれくらいの概念のなにかだけが残っている（と、発表者は考えている） ○ 要求分析、設計、実装、テスト、総合・受入テスト、リリース
twitter: @__yumechi misskey: @[email protected] そんな中でスクラム・アジャイルを学習する壁 ● 人はパターン認識的に学習しようとするので、ウォーターフォールライクな手法と対比して学習しようとする ○ https://ja.wikipedia.org/wiki/パターン認識 ○ アジャイルソフトウェア開発宣言は対話・協調を大事にし、変化し続けるソフトウェア開発という点でイメージがしやすい（表面的には…）
twitter: @__yumechi misskey: @[email protected] マッピングできないスクラムの概念 ● スクラムイベントがそもそもマッピング不可能 ○ 朝会、夕会 → デイリースクラム ○ プロトタイピングなもの？ 基本設計？ → スプリントレビュー ○ 計画や要件定義？？ → スプリントプランニング ○ 振り返り？（そもそもウォーターフォールライクにはない） → スプリントレトロスペクティブ ● 役割についてもマネージャー → スクラムマスター？？ ● プロダクトオーナーとマネージャーの違いは？？
知識が共通認識 になっていない場合は 更に色々出てくる…
はい、理解できません 終了です
はい、理解できません 終了です https://www.irasutoya.com/2014/03/blog-post_2687.html より
うまく行った ワークを紹介
twitter: @__yumechi misskey: @[email protected] 頑張ってみんなで学びましょう ● 実際やってみて良かったこと ○ スクラムガイドをみんなで読んで理解を深める（定期的に） ○ スクラムガイドをみんなで音読する ○ このプロダクト・このプロジェクトでの役割やスクラムイベントで何をやるかの詳細をつめて可視化する ■ ドキュメントの準備が大事、体制図は大事 ● 実際やってみてうまく行かなかったこと ○ 各々でスクラムガイドを読んでもらう
twitter: @__yumechi misskey: @[email protected] 頑張ってみんなで学びましょう ● 実際やってみて良かったこと ○ スクラムガイドをみんなで読んで理解を深める（定期的に） ○ スクラムガイドをみんなで音読する ○ このプロダクト・このプロジェクトでの役割やスクラムイベントで何をやるかの詳細をつめて可視化する ■ ドキュメントの準備が大事、体制図は大事 ● 実際やってみてうまく行かなかったこと ○ 各々でスクラムガイドを読んでもらう みんなでアンラーンだ！
自分もよくわからない！ というのを相手に伝えながら 同期的にワークするのも 時には大事
心理的にも自分一人だけが わからないという 状態を防げる（副次的な効果）
みんなで行け 的なやつ https://loosedrawing.com/illust/1129/ より
twitter: @__yumechi misskey: @[email protected] ● 関係者に我々はスクラムをやります！ということを伝える ○ コミュニケーションが増えて手戻りが減るとかのメリット ○ MTGが多少増えて、リーダー・マネージャーを介さないコミュニケーション増えるデメリット ● スプリントやイベントをいつ行うのか調整する ○ 体感、なぜか２週間スプリントで始めるものの１週間にすることが多い ○ （スプリントの経験数が増えるとその分うまくスプリントが回るようになるため） ○ スクラムイベントの時間が長すぎても良くないので調整する スクラムのメリットや進め方を浸透させる
形式スクラムの定義… スクラムイベントと 各種役割は決めて 動いていることとします
twitter: @__yumechi misskey: @[email protected]
まとめると、 納得感かなぁ https://loosedrawing.com/illust/1378/ より
twitter: @__yumechi misskey: @[email protected] ウォーターフォールライクで起きがちな問題 ● これまでのコミュニケーション ○ リーダー・マネージャーが決めてくる ○ その決定に対して、開発者視点での問題は上がりづらい ● これまでのスプリント・イテレーション ○ 機能ごと・プロジェクトごとになるのでスパンが長い、リズムがない ○ 毎回ふりかえることはない、というか忘れる
twitter: @__yumechi misskey: @[email protected] スクラムの持つ性質によるメリット ● コミュニケーション ○ スクラムイベントで必然的に増える ○ いろいろな人の発言を通して、知見や考え方が共有される ○ ふりかえりから課題や問題を共有し、より良いアイディアで解決できる ● スプリント・イテレーション ○ タイムボックスが明確に区切られているので、次までに何をするかが明確 ○ どこまで進められるのかの合意形成もできる ○ イベントを通してプロセスの改善もできる
ただし、これは どちらかといえばこれまでの コミュニケーション に問題があり、それが顕在化 しただけに過ぎないのだ…
開発者も言われたものを 作るのではなく、 より便利になるものを 作りたい（はず）
twitter: @__yumechi misskey: @[email protected] 専門性を生かした仕事をする ● コミュニケーションが改善されて専門性を生かし、色々任せながら進められるようになる ○ コミュニケーション量が増え、タスクの取りこぼしが減り役割分担が明確に ○ POはプロダクトのことを考えながら優先順位を考える ○ SMは開発者を支援しつつ、プロダクト開発がうまく進むようにいろいろ動き回る ○ 開発者は開発視点で意見しながらプロダクトに貢献する
コミュニケーションを 密にすることで 私たちはプロダクトの 方向性を理解し、 ユーザーの行動変容をどう 起こしたいのかを理解する
プロダクトが向かう 方向やユーザーから 考えたときの 納得感がある！ https://loosedrawing.com/illust/987/より
言われたものを作る を超え始めた！
ただし、 デリバリ速度の改善 まではわからないなぁ という感想…（これまでの計測が甘い問題も含む）
＝スクラムは開発速度を 改善する銀の弾丸ではない
ただ納得感があることは もっと良いステップに つながるはず （うまく言葉にできない…） https://loosedrawing.com/illust/1434/ より
よし、順調にイベントが回っているな！
ただなんかうまくいってない気がするぞ？
アジャイルソフトウェア 宣言に立ち返ると
「プロセスやツールよりも個人と対話を」 と一番上に書いてある https://agilemanifesto.org/iso/ja/manifesto.html
アジャイル宣言の背後にある原則 に立ち返ると
「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」 https://agilemanifesto.org/iso/ja/principles.html より
「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。」 https://agilemanifesto.org/iso/ja/principles.html より
おやおや？？？
形式スクラム最大の 弱点、それは…
顧客への価値提供より プロセスに従う 選択をしてしまうこと 🙀
プロダクトを良くする という本質から 離れてしまうこと 😇
twitter: @__yumechi misskey: @[email protected] イベントが定義されていることによるデメリメ ● スクラムイベントが明確に定義されていることが良い面も悪い面も包含している ○ 良い面： 開発を一定のリズムで行う、コミュニケーションを取れる、スプリントゴールを設定して明確な形で進められる ○ 悪い面: スクラムイベントをやっていればスクラムという誤った認識や誤解を持ってしまう、スクラムイベントに参加することが仕事になってしまう（コミュニケーションを取ることはしなくてもよい）
twitter: @__yumechi misskey: @[email protected] ウォーターフォールライク概念の亡霊 ● ウォーターフォールライクな開発プロセスにマッピングされたアジャイル・スクラムから外れた概念のまま進行してしまう危険性 ○ リリースなのか、デプロイなのか、納品なのか ○ ストーリーポイントなのか、工数なのか ○ 設計？実装？テスト？ ● これまでの開発プロセス・関係性に引き戻される危険 ○ 今までのやり方でもなんとかうまくやれていたから戻そう ○ 開発者はMTGに出ずに開発に集中したい etc…
twitter: @__yumechi misskey: @[email protected] これが進行していくとどうなるのか？ ● 必要なメンバーが揃わないままスクラムイベントスタート ○ 他の会議をしょっちゅう優先してしまう、絶対イベントに来ないチームメンバー ○ あとから議事録を眺めて個別の追加のMTGなどが色々組まれる ● ファシリテーターだけが方向性を定める形になってしまう ○ 気がついたらファシリテーターが１時間話して終わってしまった！ ○ ファシリテーターが毎回固定… ● etc…etc…
twitter: @__yumechi misskey: @[email protected] これが進行していくとどうなるのか？ ● 必要なメンバーが揃わないままスクラムイベントスタート ○ 他の会議をしょっちゅう優先してしまう、絶対イベントに来ないチームメンバー ○ あとから議事録を眺めて個別の追加のMTGなどが色々組まれる ● ファシリテーターだけが方向性を定める形になってしまう ○ 気がついたらファシリテーターが１時間話して終わってしまった！ ○ ファシリテーターが毎回固定… ● etc…etc… もう疲れちゃって…
twitter: @__yumechi misskey: @[email protected] 疲れてくると負のループに陥る ● これまで問題になってたことが戻ってくる ○ リーダーだけMTGに出ましょう→コミュニケーション不足 ○ ふりかえりはしません！→ プロセスが改善されない ○ スケジュールを決めたのでこの通りやりましょう→開発の課題が上がりにくくなり、大変になる ● 単純な疲れから生産性のダウン、モチベーション低下、チーム離脱… ○ 疲れて労働時間が長くなる、全くあまりいいことはない ■ 軽く調べても「我が国における労働生産性をめぐる現状と課題」など出てくる ■ https://www.sangiin.go.jp/japanese/annai/chousa/rippou_chousa/backnumber/2018pdf/20180601041.pdf
twitter: @__yumechi misskey: @[email protected] 疲れてくると負のループに陥る ● これまで問題になってたことが戻ってくる ○ リーダーだけMTGに出ましょう→コミュニケーション不足 ○ ふりかえりはしません！→ プロセスが改善されない ○ スケジュールを決めたのでこの通りやりましょう→開発の課題が上がりにくくなり、大変になる ● 単純な疲れから生産性のダウン、モチベーション低下、チーム離脱… ○ 疲れて労働時間が長くなる、全くあまりいいことはない ■ 軽く調べても「我が国における労働生産性をめぐる現状と課題」など出てくる ■ https://www.sangiin.go.jp/japanese/annai/chousa/rippou_chousa/backnumber/2018pdf/20180601041.pdf スクラムマスター出番です！
twitter: @__yumechi misskey: @[email protected] 正しいスクラムに向き直りをするために ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビスクラムサバイバルガイドを読んで実践する ○ https://www.maruzen-publishing.co.jp/item/b304740.html ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し ○ 概念をもう一度捉え直す ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い意味で外れているのかを考える ● ファシリテーターを毎回変えてみる
twitter: @__yumechi misskey: @[email protected] 正しいスクラムに向き直りをするために ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビスクラムサバイバルガイドを読んで実践する ○ https://www.maruzen-publishing.co.jp/item/b304740.html ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し ○ 概念をもう一度捉え直す ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れているのかを考える ● ファシリテーターを毎回変えてみる あんまりうまくいかなかった
twitter: @__yumechi misskey: @[email protected] それぞれに対してうまく行かなかったポイント ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビスクラムサバイバルガイドを読んで実践する ○ https://www.maruzen-publishing.co.jp/item/b304740.html ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し ○ 概念をもう一度捉え直す ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れているのかを考える ● ファシリテーターを毎回変えてみる 自分一人で理解してもついてこないなんとなく反応薄め…個人のファシリテーション能力に強依存、イベントの再現性がなくなってしまう
twitter: @__yumechi misskey: @[email protected] 今ふりかえるとこうしたい ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビスクラムサバイバルガイドを読んで実践する ○ https://www.maruzen-publishing.co.jp/item/b304740.html ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し ○ 概念をもう一度捉え直す ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れているのかを考える ● ファシリテーターを毎回変えてみる みんなでスクラムに問題があることを理解し、改善に向けて活動する外部者やアジャイルコーチに入ってもらう何度か様子を見る、まずはデイリースクラムから。デイリースクラムは回数をこなしやすいので最適。
チームメンバー自身が 各々アジャイルって 何だ？を理解する 必要がある
結局最後は マインドセットの定着で本質的に考えられるチームに なるのを待つしかない
着目すべきは ソフトウェアの提供価値。 プロセスを見てるのは 危険信号。
確 集 公 尊 勇 約 中 開 敬 気
twitter: @__yumechi misskey: @[email protected] チームの局所最適化は起きていた ● 開発手法が同じプロダクト内でバラバラしていた ● システム間で開発手法を分断すると…？ ○ POと話している量が違うので、エンジニア間でも視座の違いが生まれやすくなる ○ プランナー・ディレクター間でもエンジニアの理解度が変わってしまう ■ ただ開発を委託する人から、一緒にプロダクトを盛り上げていく人に代わっている人に代わっている ■ 人によって扱いが…
twitter: @__yumechi misskey: @[email protected] 開発手法は違ってもいいけれど ● アジャイル・スクラムを採用していないチームにも文化的に浸透が必要かもしれない ● ステークホルダーに対してアジャイル・スクラムは手法が変わるだけではなく、文化形成が変わり関係性も変わること、と認識を変えてもらう必要があったのかも ● いろいろな手法がある状態が無視できないレベルになったら、組織自体が変わっていく決断も必要かもしれない（私に権限はないですがｗ）
昨日のKeynote聞いた 感想では、このあたりの 突破力は身につけないと あかんなとなりました😇😇
これはもう、 スクラムという言葉も 概念も一回持ち込まない
twitter: @__yumechi misskey: @[email protected] スクラムを導入する前にアジャイルマインドをやる ● 過去の経験からアジャイルの代表例としてスクラムを導入しようと試みてきたが、スクラムイベントというプロセスに飲み込まれた ○ スクラムのプロセスに頭を固定するのは絶対に避けたい ● なのでいきなりスクラムに変えよう、はなんとしても避けたい ○ アジャイルソフトウェア開発宣言や、アジャイル宣言の背後にある原則を読む ○ 現状の自分たちの開発においてコミュニケーション不足なところから変える
twitter: @__yumechi misskey: @[email protected] レトロスペクティブ（ふりかえり）から入れたい ● 自分たちを知らないと手の打ちようがない、まずは自分たちを知ろう ● 経験上、その結果やプロセスについてのふりかえりは十分でないことも多い ○ うまくいかなかったプロジェクトとかでものど元過ぎれば… みたいな実感はある ○ とりあえず今の方法でやれているのでやっている、とかは十分にある ● コミュニケーションが少なめでもうまく行くのであれば問題ないので無理にやらない ○ 場合によってはアジャイル・スクラムを導入しないのも選択肢に入れて良い
twitter: @__yumechi misskey: @[email protected] どうふりかえるか ● ふりかえりカタログを見ながら選定する ○ ふりかえりカタログ / Retrospective Catalog - Speaker Deck ○ https://speakerdeck.com/viva_tweet_x/retrospective-catalog-59bd3a29-314c-45dd-911b-f8e5f1308333 ● テーマによってふりかえり手法を変えたり… ○ 普段の開発プロセスのふりかえりはKPTA ○ 前向きになりたいときは Fun, Done, Learnなど ● ふりかえりの手法選定は自分もまだまだ経験不足なので試行錯誤中
twitter: @__yumechi misskey: @[email protected] 次はデイリースクラムをやりたい ● 普段から顔合わせしてコミュニケーションは増やしておきたい ○ コミュニケーションしたことがない相手を減らしておくのは大事だと思う ● 毎日話すことによって日々の動向を知りつつ、課題となっている点を共有し、問題解決や優先順位を相談したい ● 可能ならモニタリングとかも一緒に見ながら話せるといいなーとか
twitter: @__yumechi misskey: @[email protected] 以降のスクラムイベントは必要に応じて ● 本質的にやりたいのは気持ちよく働いて、良いプロダクトを顧客・ユーザーに届けることであるので、スクラムを導入することではない ○ スクラムを導入するという方法の目的化は避けなければいけない ● 他のスクラムイベントはチームの様子を見ながら ○ デイリーのところでコミュニケーションがいっぱいいっぱいな感じであれば、一旦デイリーに慣れてもらうまで待つ ○ チームが成熟していないのにコミュニケーション頻度が高いスクラムを行うのは難しいので…
対話しながら そのチームにとって 必要で成長できる 方法を提案したい https://loosedrawing.com/illust/1411/ より
twitter: @__yumechi misskey: @[email protected] 自分はスクラムマスターが適切だったのか？ ● 技術に触れる時間が減ったことに違和感があった ○ 元々、開発のリードとしてテックリード寄りの考え方だった ■ 開発したいものを渡すことにやや抵抗があった ○ アジャイルスクラムについて教えながら、技術的なインプットもアウトプットも行っていた ● スクラムマスターになった経験自体はとてもよかった、一方で今の自分が貢献できることは開発のほうが大きいという感覚 ○ 開発者視点でアジャイルを支えられることもたくさんある、自動化など
自分のキャリアの壁打ちを誰か… 懇親会で…
twitter: @__yumechi misskey: @[email protected] まとめ ● 導入時にはみんなでアジャイル・スクラムを学習しよう ● アジャイル・スクラムはコミュニケーションが増えるため、コミュニケーションフローの改善に繋がり、プロダクトの方向性に納得感が生まれる ● スクラムのイベントをこなす流れになると、定期的にあるイベントをこなすだけになりプロダクトへの指向性が薄れ、本質から遠ざかってしまう ● スクラム導入を目的とせず、アジャイルなマインドを身につける。発表者も試行錯誤中！まずはチームとの対話を行う「ふりかえり」が鍵
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/
yumechi
prtimes
ascend
upsider_official
suzakiyoshito
more_t
nstock
recruitasken
hacobu
gongongon
nextbeat
fabrica_com
maltzj
colly
notwaldorf
zenorocha
jponch
robhawkes
addyosmani
tammyeverts
jennybc
nonsquared
jnunemaker
eileencodes