(発表ver) 期限厳守のスクラム的開発現場での経験談～葛藤の中で目指した姿と離脱後の気づき～

2024/6/28 Raccoon Tech Connect #5 スクラム開発の工夫
での発表スライド

※8分に収めるため多少削る前のフル版スライド：
https://speakerdeck.com/symthy/huruver-qi-xian-yan-shou-nosukuramude-kai-fa-xian-chang-denojing-yan-tan-ge-teng-nozhong-demu-zhi-sitazi-toli-tuo-hou-noqi-duki

Transcript

1. 期限厳守のスクラム的開発現場での経験談 ~ 葛藤の中で目指そうとした姿 と 離脱後の気付き ~ 前職:SIerのお話 (後半4年の総括) Raccoon Tech Connect #5 【発表版】
2. 前職(最後4年間)の環境：組織構造 　ビジネスサイド ＰМ、ＰО、ﾃｯｸﾘｰﾄﾞ、先行検討Ｔ etc. 開発 チーム A 何をやるか決まった状態 で上から降ってくる 開発 チーム B 開発 チーム C 開発 チーム D 自分の役割(４年変遷)： ↓１年：メンバー ↓２年：サブリーダー ↓１年：半分リーダー兼任 サブリーダ以降の業務： ・スプリント計画 ・タスク管理/進捗管理 ・完了レビュー ・レトロスペクティブ進行 ・コードレビュー ・メンバーのサポート 　etc. ２次請け ２次請け プロダクト開発 2
3. 前職(最後4年間)の環境：プロダクトの性質 ユーザの環境 ユーザの 業務 システム リソース 我々 製品 イン スト ーラ • 自分達の環境で運用ではない • ユーザの環境にインストール 我々 の 製品 3 データセンター ユーザ ・品質妥協NG ・随時リリースNG 監視
4. 約３ヶ月に１回を繰り返す（１Sprint:２週間） 開発項目 担当 線 AAA チームＡ BBB チームＢ CCC チームＣ DDD チームＤ EEE チームＢ FFF チームＤ ： ： XX.XX.01-00 XX.XX.02-00 XX.XX.02-01 XX.XX.03-00 前職(最後4年間)の環境：リリース頻度 (元の計画が破綻しない限り) 品質担保した上で 期限までに終わらせる 影響大の不良 あれば延長戦 4
5. Contents • 1開発チームに閉じた話（メイン） ◦ 長期的には悪手と思いながらもやり続けたこと （アンチパターン） ◦ 主にコミュニケーション面の課題への小さな改善・工夫 ※時間の都合により、３／４つを紹介　 ◦ 実現したかったが、できなかったこと ※時間の都合により、概要のみ紹介　 ◦ 今だから言える事 ※時間の都合により、１／３つを紹介 • 開発サイド全体の話 （おまけ） ◦ ４年間でやり方がどう変わったか ◦ 離脱後の気付き 5
6. 長期的には悪手と思いながらもやり続けたこと • 慢性的なチームの課題： ◦ 個々の技術スキル不足、チームとしての総合力不足 ▪ 不安定なベロシティ（未完了タスク持ち越し常態化） 自分一辺倒なチーム 少なからず成長/挑戦機会を 奪っていた側面はあったはず… 6 • メンバーの過剰フォロー • あえて自らに一極集中化（チーム内の問題解消をほぼ一手に担う） ➡ 何かあれば入り込み、片っ端から解決、時には部分的に巻き取り ➥ 毎回凌ぎ切るために奔走 =必然 (理性＞＞＞感情) 期限を守る事だけを考えると最善手… 品質と期限両⽴の圧
7. 本来の目指したかった姿 1. 個々の「状況」を見える化 ➡ 互いにフォローし合える 2. 道筋と現在地を明快化 ➡ 互いに迷いなく進める 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減/連携強化 「自分一辺倒」な状態は望んでいなかった… 理想のスクラムチームのイメージ(主観)： • 自律/協働/透明性 → 互いの強みを活かしてシナジーを生む 目指そうとして作った仕組み 7 「全員が互いをフォローし合える、全員で前進していく」 状態に本当はしたかった
8. 1. 個々の「状況」を見える化 ➡ 互いにフォローし合える 主にコミュニケーション面の課題への改善・工夫 ➡ 夕会を増やす/別途相談の会議も行うが、それでも足りず チーム初期状態：日中静かなチャット(コロナ禍突入、初フルリモート) ・何をやろうとしているか ・何を考えているか ・何を悩んでいるか ・やったこと/結果　など 分報とは を独り言のように書き込む ➡ 個々の状況を見える化 ※1タスク＝1スレッドで実施 8 課題 デイリースクラム (朝会) で進捗がない状態が頻発 手段 「分報」の真似事を始める（in Microsoft Teams）
9. 1. 個々の「状況」を見える化 ➡ 互いにフォローし合える 主にコミュニケーション面の課題への改善・工夫 9 チーム初期状態：日中静かなチャット(コロナ禍突入、初フルリモート) 課題 デイリースクラム (朝会) で進捗がない状態が頻発 手段 「分報」の真似事を始める（in Microsoft Teams） • 後々形成できた文化： ◦ 宣言してから行動 → 結果をアウトプット ➡ 問題の検知がしやすいから互いにフォローもしやすい (副産物)しばらく結果が出てこない＝問題を抱えている可能性を疑える
10. 主にコミュニケーション面の課題への改善・工夫 「分報」で個々の詳細な状況が見える化できたら、別の課題が浮き彫り ◦ ＴＤＤ（テスト駆動開発）をヒントに組み込み ▪ ＴＤＤ ≒ 小さく分解して１つずつ順番に取り組む ※小さなＴｏｄｏ＝「やることリスト」 をスレッドのトップに記載 10 2. 道筋と現在地を明確化 ➡ 互いに迷いなく進める ◦ 故に、タスク進行の途中でやることが見つかる(予定も伸びる） 課題 タスクの全体像や進捗度合いが把握しづらい 手段 各タスクに対して小さなＴоＤоを最初に書き出す
11. 主にコミュニケーション面の課題への改善・工夫 • タスクの全体像と進捗度の確認が容易に ◦ 「やること」に漏れやズレがないか確認できる • (副産物) メンバー間のやり取りがスムーズに ◦ １つの「やること」ベースで確認/会話ができる 11 2. 道筋と現在地を明確化 ➡ 互いに迷いなく進める 課題 タスクの全体像や進捗度合いが把握しづらい 手段 各タスクに対して小さなＴоＤоを最初に書き出す 「分報」で個々の詳細な状況が見える化できたら、別の課題が浮き彫り
12. 主にコミュニケーション面の課題への改善・工夫 ◦ 誰かに聞いて教えてもらわないと分からない（属人化） • 最初は Teams Wiki (使いづらく移行先探しに数か月要すが) Microsoft OneNote へ移行 （フリーフォーマットが想像以上に刺る） • 仕様、手順、ルール、Tips 等を逐次書き残していった 12 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 課題 チーム内で情報共有ができていない 手段 自分達が自由に書ける場 (自チーム内wiki) を用意 ※開発サイド全体のwikiはあったが何でもは書けず残せていなかった
13. 主にコミュニケーション面の課題への改善・工夫 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 ◦ 仕様、手順、ルール、Tips 等を逐次書き残していった 13 課題 チーム内で情報共有ができていない 手段 自分達が自由に書ける場 (OneNote) を用意 • 他の人を挑戦させやすい、互いのフォローがよりやりやすい ◦ 分報と相性〇： wiki のページリンクを渡すだけでフォロー可能 • (副産物) 分報での課題「過去の内容を追いにくい」の解消 ◦ (自由に書ける故に)タスクでの調査/検討/試行結果なども残す
14. 主にコミュニケーション面の課題への改善・工夫 1. 個々の「状況」を見える化 ➡ 互いにフォローし合える ◦ 「分報」の真似事（宣言して行動、結果をアウトプット） 2. 道筋と現在地を明快化 ➡ 互いに迷いなく進める ◦ 最初に「やることリスト」を書く 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 ◦ 自分達が自由に書ける場所を用意 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減/連携強化 ◦ (Gitlab/Githubの) Draft MR/PR を活用→先回りフィードバック、連携 「全員が互いをフォローし合える、全員で前進していく」状態に近づけた 14
15. 実現したかったが、できなかったこと（概要のみ） • 「慢性的なチームの課題」に着手ができる状態になった ◦ 課題：「個々の技術スキル不足、チームとしての総合力不足」 • サイクル構築のための題材：コードレビュー指摘 ◦ 始めるも課題が見つかり頓挫… ➡ 一定やり切った＆限界を迎え転職 15 • 「自主性」を育むための環境・仕組みが必要 (仮説) ◦ 根拠：自分＝過去のキャリアで一度喪失したが身に着け成果を出した 他社事例を参考にするも適用できず… • 小さなアウトプット/フィードバックサイクル形成 が成功の鍵 • 自分達の環境が特殊 → 内側（自分達の環境内）に目を向けた 内側で題材を探し、見つける 根本解決のためには…
16. 今だから言える事（伝えたいこと） 理想像を捉えつつも自分達に合う形を模索していく 16 ➡ 今は着手困難な課題でも未来では取り組み可能に • 人は変えない →「仕組み」で「人の行動」を変える 支えになった考え方： • １つ１つ積み重ねていく(時間がかかってもいい) ※結果に繋がらずとも考え続ける限り「停滞」ではない ◦ 見えていなかった課題が浮き彫りになっていく ◦ １つ１つが (思わぬ形でも) 繋がっていく ◦ (レトロスペクティブの場は大事)
17. ～おまけ～ ４年間で開発サイド全体のやり方が どう変わったか 17
18. 開発サイド全体でのやり方の変遷 • 最初にある程度計画立てる、後はやってみないと分からない 　➡ やり始めるも、途中で追加で必要な物が見つかる 　　　➡ リリース直前にツケが周って全体が疲弊 • 最初にしっかり計画立て（スクラム×ウォーターフォール？） ◦ 最初の１～２ Sprint ＝ 計画立てがメイン ▪ 各タスクで、何をやるかの具体とリスクを洗い出す ▪ 各タスクは、可能な限り小さく分解 ▪ 線表を作成 18
19. 作成していた線表のイメージ　※これを１リリース分作成 7/1 7/2 7/3 7/4 7/5 7/6 7/7 7/8 7/9 7/10 7/11 7/12 TASK-1234：〇〇処理の追加 1 検討 〇 2 コーディング 〇 〇 〇 3 テスト実装 〇 〇 〇 4 動確 〇 〇 5 内部レビュー 〇 〇 6 本レビュー 〇 〇 〇 【バッファ】 〇 ※各項目に予定/実績の行を用意 → 予実を記録して後の振り返りに利用 19
20. 離脱後の気付き （ スコープの調整余地なし ＝ 残業or休出で補う一択 ＝ 地獄 ） • 中～短期スパン(数ヶ月等)で区切る ＝「Sprint」と「中短期スパン」の２段式(改善)サイクル ◦ 現スパンのスコープを決めて計画立てて取り組み ◦ 途中で追加が必要な物が見えたら、現スパンのスコープを調整 ◦ １スパンが完了したら、その先の解像度も上がる 「スクラムのデメリット：全体スケジュールが把握しづらい」の緩和策 20 ➡ 全体感を定期更新して共有、理解を得ながら進められる？ • ３ヶ月位のスパンで区切る ＝ 良いことでは？
21. • 理想像を捉えつつも、自分達に合う形を模索していく ◦ １つ１つの積み重ねが繋がり、シナジーを生む ▪ 今は着手困難な課題でも、未来では取り組み可能になる ◦ 「人」は変えない→「仕組み」で「人の行動」を変える • デメリットへの緩和案：中短期スパン(数ヶ月等)で区切りを置く ◦ 「Sprint」と「中短期スパン」による２段式(改善)サイクル ◦ 全体感を定期更新して共有、理解を得ながら進められる かも ◦ (スクラム×ウォーターフォール) まとめ 21