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

期限厳守のスクラム？開発（１Sprint：２週間）の経験（４年）総括
１スクラムチームの中での
・失敗（長期的に悪手と思いながらもやり続けたこと）
・コミュニケーション面での小さな改善・工夫
・個々のスキル不足解消のためにやりきれなかった施策の過程
と、今振り返っての気付きについて
(番外) 教訓：理性＞＞＞感情で行動し続けると自己肯定感が底を付きました（感情は捨てちゃダメ絶対）

Transcript

1. 期限厳守のスクラム的開発現場での経験談 ~葛藤の中で目指そうとした姿 と 離脱後の気付き~ 前職:SIerのお話 (後半4年の総括) 【フル版】
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. 主にコミュニケーション面の課題への改善・工夫 ◦ チーム内コードレビューが「大きなボール」の投げ合いに ▪ 指摘件数が多い、再レビューでもまだ多い • ※小さい手戻りも積み重なる 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減 /連携強化 ◦ 実装中のコードを上げてもらう ➡ 先回りフィードバック ▪ どの時点で上げるかは最初に決めたり、担当者に委ねたり ▪ レビュー依頼時には細かい部分のチェックで済ませられる 14 課題 タスクがずるずる長引く(完了の見通しがみえづらい) 手段 Ｄｒａｆｔ ＭＲ、Ｄｒａｆｔ ＰＲ を活用し始める
15. 主にコミュニケーション面の課題への改善・工夫 • (完全ではないが) 手戻り感の軽減 • メンバー間で連携が必要になる事項にも気付きやすい ➡ ＭＲ/ＰＲ に直接書き込んで連携できる • 完了見通しを握りやすい 15 手段 Ｄｒａｆｔ ＭＲ、Ｄｒａｆｔ ＰＲ を活用し始める ◦ 実装中のコードを上げてもらう ➡ 先回りフィードバック 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減 /連携強化 課題 タスクがずるずる長引く(完了の見通しがみえづらい)
16. 主にコミュニケーション面の課題への改善・工夫 1. 個々の「状況」を見える化 ➡ 互いにフォローし合える 2. 道筋と現在地を明快化 ➡ 互いに迷いなく進める 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減 /連携強化 「お互いが背を支え合い全員で前進する」状態に近づけた 16 取り組み：
17. (からこその成果 ） • 根拠：自分自身 過去のキャリア(主にデスマーチ)を経て「自主性」喪失 　➡ スクラムにある程度適応 　➡ 自主性を一定身に着けた • 慢性的なチームの課題： ◦ 個々の技術スキル不足、チームの戦闘力不足 ▪ 不安定なベロシティ（未完了タスク持ち越し常態化） 　　　　　　　　　　　　に立ち向かっていけそうな状態に 主にコミュニケーション面の課題への改善・工夫 「自主性」を育むための環境・仕組みが必要 17 根本解決のためには…
18. 実現したかったが、道半ばで実現できなかったこと ◦ 業務で役立ちそうなツールやOSSを共有 ➡ 環境の制約上困難 ◦ 読書会などを行い、学び/気付きを共有 ➡ 多忙により賛同得られず ◦ ※主導開催していた勉強会中止（一方通行で効果０と苦渋の決断） 小さなアウトプット/フィードバックサイクル形成が成功の鍵 気付き(うまくいく共通点) • 自分達の環境は特殊 ➡ 外に目を向けず、内に目を向けた ◦ サイクル形成の題材を内側(自分達の環境)で探した 「自主性/主体性」を育むための環境・仕組み を作るために… 18 他社の事例を参考にしようとするも適用できず
19. 実現したかったが、道半ばで実現できなかったこと ◦ ネタには困らない（ほぼ無限に溢れてくる） ◦ 無理なくフィードバック可能（初動は自分が主導可） ◦ チーム内での知識共有 ◦ メンバーの(内部)設計力向上 ◦ 自チームの弱点傾向分析 ➡ レビュー指摘を手で集めるのに超手間がかかる 　 → 改善策を打ったものの上手くいかず 　 → ボールを握られ自然消滅 　 → (一定やり切り限界を迎え)転職活動へ… (→ 1年半後の今) Time up メリット 19 見つけた題材：コードレビュー指摘
20. 今だから言える事（伝えたい大事なこと）1/3 理想像を捉えつつも自分達に合う形を模索していく 20 ➡ 今は着手困難な課題でも未来では取り組み可能に • 人は変えない →「仕組み」で「人の行動」を変える 支えになった考え方： • １つ１つ積み重ねていく(時間がかかってもいい) ※結果に繋がらずとも考え続ける限り「停滞」ではない ◦ 見えていなかった課題が浮き彫りになっていく ◦ １つ１つが (思わぬ形でも) 繋がっていく ◦ (レトロスペクティブの場は大事)
21. 今だから言える事（伝えたい大事なこと）2/3 • 継続は力なり • 見えている「問題」だけを上げるのはもったいない ◦ 失敗、違和感 (何かやりづらい/上手くできない) など 「問題提起」に達せずとも上げれる雰囲気を作る 21 失敗や違和感などの裏側には「仕組み」の問題が潜んでいる ➡ Ｔｒｙを考え（取捨選択して）試す ➡ 皆で深掘り＆推測して、どこに問題点があるか考える レトロスペクティブの機会は大事
22. 今だから言える事（伝えたい大事なこと） 3/3 22 Ｑ. (忙殺される中で) なぜ改善をやり続けられたのか？ 個々が持つ「得意なこと(才能)」を個々が捉え活かすも大事 • スクラムでの「得意や強みを活かす」→ 得意や強み≒スキル/経験 (改善実行にあたり)元から「スキル/経験」があったか？ No • 本能的な衝動に従って勝手にやり続けたというだけ ※当時は認識すらできていなかったが本能的にやっていた ➡ (スキル/経験なかったが) 気付いたら「成果」が出た Ａ. 自分の「得意なこと(才能)」が「舞台整備」だから
23. ～おまけ～ ４年間で開発サイド全体のやり方が どう変わったか 23
24. 開発サイド全体でのやり方の変遷 • 最初にある程度計画立てるが、後はやってみないと分からない 　➡ やり始めるも途中で追加で必要な物が見つかる 　　　➡ リリース直前にツケが周って全体が疲弊 • 最初にしっかり計画立て（スクラム×ウォーターフォール？） ◦ 最初の１～２Sprint は 計画のための調査・準備 ◦ ※主にチームリーダーが担当、メンバーは明確なタスクから着手 ▪ 各タスクで、何をやるかの具体とリスクを洗い出す ▪ 各タスクは 2, 3 point にまで分解（大きくても 5 point) ▪ 線表を作成 24
25. 作成していた線表のイメージ　※１リリース分作成 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 本レビュー 〇 〇 〇 【バッファ】 〇 ※各項目に予定/実績の行を用意 → 予実を記録して後の振り返りに利用 25
26. 離脱後の気付き （ スコープの調整余地なし ＝ 残業or休出で補う一択 ＝ 地獄 ） • 中～短期スパン(数ヶ月等)で区切る ＝「Sprint」と「中短期スパン」の２段式(改善)サイクル ◦ 現スパンのスコープを決めて計画立てて取り組み ◦ 途中で追加が必要な物が見えたら、現スパンのスコープを調整 ◦ １スパンが完了したら、その先の解像度も上がる 「スクラムのデメリット：全体スケジュールが把握しづらい」の緩和策 26 ➡ 全体感を定期更新して共有、理解を得ながら進められる？ • ３ヶ月位のスパンで区切る ＝ 良いことでは？
27. • 理想像を捉えつつも、自分達に合う形を模索していく ◦ 「人」は変えない→「仕組み」で「人の行動」を変える ◦ 積み重ねが繋がりを生み、困難な課題にも取り組み可能になる ◦ 失敗や違和感など「問題提起」に達せずとも上げる→深掘り/試行 • スクラムでの「得意や強みを活かす」 ◦ (既に持っているスキルや経験を活かすだけに留まらず) 各個人が持つ「得意なこと(才能)」を個々が捉え活かすのも大事 • デメリットへの緩和案：中短期スパン(数ヶ月等) で区切りを置く ◦ ≒ スクラム×ウォーターフォール ▪ 「Sprint」と「中短期スパン」による２段式(改善)サイクル まとめ 27