Slide 1

Slide 1 text

期限厳守のスクラム的開発現場での経験談 ~ 葛藤の中で目指そうとした姿 と 離脱後の気付き ~ 前職:SIerのお話 (後半4年の総括) Raccoon Tech Connect #5 【発表版】

Slide 2

Slide 2 text

前職(最後4年間)の環境:組織構造  ビジネスサイド PМ、PО、テックリード、先行検討T etc. 開発 チーム A 何をやるか決まった状態 で上から降ってくる 開発 チーム B 開発 チーム C 開発 チーム D 自分の役割(4年変遷): ↓1年:メンバー ↓2年:サブリーダー ↓1年:半分リーダー兼任 サブリーダ以降の業務: ・スプリント計画 ・タスク管理/進捗管理 ・完了レビュー ・レトロスペクティブ進行 ・コードレビュー ・メンバーのサポート  etc. 2次請け 2次請け プロダクト開発 2

Slide 3

Slide 3 text

前職(最後4年間)の環境:プロダクトの性質 ユーザの環境 ユーザの 業務 システム リソース 我々 製品 イン スト ーラ ● 自分達の環境で運用ではない ● ユーザの環境にインストール 我々 の 製品 3 データセンター ユーザ ・品質妥協NG ・随時リリースNG 監視

Slide 4

Slide 4 text

約3ヶ月に1回を繰り返す(1Sprint:2週間) 開発項目 担当 線 AAA チームA BBB チームB CCC チームC DDD チームD EEE チームB FFF チームD : : XX.XX.01-00 XX.XX.02-00 XX.XX.02-01 XX.XX.03-00 前職(最後4年間)の環境:リリース頻度 (元の計画が破綻しない限り) 品質担保した上で 期限までに終わらせる 影響大の不良 あれば延長戦 4

Slide 5

Slide 5 text

Contents ● 1開発チームに閉じた話(メイン) ○ 長期的には悪手と思いながらもやり続けたこと (アンチパターン) ○ 主にコミュニケーション面の課題への小さな改善・工夫 ※時間の都合により、3/4つを紹介  ○ 実現したかったが、できなかったこと ※時間の都合により、概要のみ紹介  ○ 今だから言える事 ※時間の都合により、1/3つを紹介 ● 開発サイド全体の話 (おまけ) ○ 4年間でやり方がどう変わったか ○ 離脱後の気付き 5

Slide 6

Slide 6 text

長期的には悪手と思いながらもやり続けたこと ● 慢性的なチームの課題: ○ 個々の技術スキル不足、チームとしての総合力不足 ■ 不安定なベロシティ(未完了タスク持ち越し常態化) 自分一辺倒なチーム 少なからず成長/挑戦機会を 奪っていた側面はあったはず… 6 ● メンバーの過剰フォロー ● あえて自らに一極集中化(チーム内の問題解消をほぼ一手に担う) ➡ 何かあれば入り込み、片っ端から解決、時には部分的に巻き取り ➥ 毎回凌ぎ切るために奔走 =必然 (理性>>>感情) 期限を守る事だけを考えると最善手… 品質と期限両⽴の圧

Slide 7

Slide 7 text

本来の目指したかった姿 1. 個々の「状況」を見える化 ➡ 互いにフォローし合える 2. 道筋と現在地を明快化 ➡ 互いに迷いなく進める 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減/連携強化 「自分一辺倒」な状態は望んでいなかった… 理想のスクラムチームのイメージ(主観): ● 自律/協働/透明性 → 互いの強みを活かしてシナジーを生む 目指そうとして作った仕組み 7 「全員が互いをフォローし合える、全員で前進していく」 状態に本当はしたかった

Slide 8

Slide 8 text

1. 個々の「状況」を見える化 ➡ 互いにフォローし合える 主にコミュニケーション面の課題への改善・工夫 ➡ 夕会を増やす/別途相談の会議も行うが、それでも足りず チーム初期状態:日中静かなチャット(コロナ禍突入、初フルリモート) ・何をやろうとしているか ・何を考えているか ・何を悩んでいるか ・やったこと/結果 など 分報とは を独り言のように書き込む ➡ 個々の状況を見える化 ※1タスク=1スレッドで実施 8 課題 デイリースクラム (朝会) で進捗がない状態が頻発 手段 「分報」の真似事を始める(in Microsoft Teams)

Slide 9

Slide 9 text

1. 個々の「状況」を見える化 ➡ 互いにフォローし合える 主にコミュニケーション面の課題への改善・工夫 9 チーム初期状態:日中静かなチャット(コロナ禍突入、初フルリモート) 課題 デイリースクラム (朝会) で進捗がない状態が頻発 手段 「分報」の真似事を始める(in Microsoft Teams) ● 後々形成できた文化: ○ 宣言してから行動 → 結果をアウトプット ➡ 問題の検知がしやすいから互いにフォローもしやすい (副産物)しばらく結果が出てこない=問題を抱えている可能性を疑える

Slide 10

Slide 10 text

主にコミュニケーション面の課題への改善・工夫 「分報」で個々の詳細な状況が見える化できたら、別の課題が浮き彫り ○ TDD(テスト駆動開発)をヒントに組み込み ■ TDD ≒ 小さく分解して1つずつ順番に取り組む ※小さなTodo=「やることリスト」 をスレッドのトップに記載 10 2. 道筋と現在地を明確化 ➡ 互いに迷いなく進める ○ 故に、タスク進行の途中でやることが見つかる(予定も伸びる) 課題 タスクの全体像や進捗度合いが把握しづらい 手段 各タスクに対して小さなTоDоを最初に書き出す

Slide 11

Slide 11 text

主にコミュニケーション面の課題への改善・工夫 ● タスクの全体像と進捗度の確認が容易に ○ 「やること」に漏れやズレがないか確認できる ● (副産物) メンバー間のやり取りがスムーズに ○ 1つの「やること」ベースで確認/会話ができる 11 2. 道筋と現在地を明確化 ➡ 互いに迷いなく進める 課題 タスクの全体像や進捗度合いが把握しづらい 手段 各タスクに対して小さなTоDоを最初に書き出す 「分報」で個々の詳細な状況が見える化できたら、別の課題が浮き彫り

Slide 12

Slide 12 text

主にコミュニケーション面の課題への改善・工夫 ○ 誰かに聞いて教えてもらわないと分からない(属人化) ● 最初は Teams Wiki (使いづらく移行先探しに数か月要すが) Microsoft OneNote へ移行 (フリーフォーマットが想像以上に刺る) ● 仕様、手順、ルール、Tips 等を逐次書き残していった 12 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 課題 チーム内で情報共有ができていない 手段 自分達が自由に書ける場 (自チーム内wiki) を用意 ※開発サイド全体のwikiはあったが何でもは書けず残せていなかった

Slide 13

Slide 13 text

主にコミュニケーション面の課題への改善・工夫 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 ○ 仕様、手順、ルール、Tips 等を逐次書き残していった 13 課題 チーム内で情報共有ができていない 手段 自分達が自由に書ける場 (OneNote) を用意 ● 他の人を挑戦させやすい、互いのフォローがよりやりやすい ○ 分報と相性〇: wiki のページリンクを渡すだけでフォロー可能 ● (副産物) 分報での課題「過去の内容を追いにくい」の解消 ○ (自由に書ける故に)タスクでの調査/検討/試行結果なども残す

Slide 14

Slide 14 text

主にコミュニケーション面の課題への改善・工夫 1. 個々の「状況」を見える化 ➡ 互いにフォローし合える ○ 「分報」の真似事(宣言して行動、結果をアウトプット) 2. 道筋と現在地を明快化 ➡ 互いに迷いなく進める ○ 最初に「やることリスト」を書く 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 ○ 自分達が自由に書ける場所を用意 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減/連携強化 ○ (Gitlab/Githubの) Draft MR/PR を活用→先回りフィードバック、連携 「全員が互いをフォローし合える、全員で前進していく」状態に近づけた 14

Slide 15

Slide 15 text

実現したかったが、できなかったこと(概要のみ) ● 「慢性的なチームの課題」に着手ができる状態になった ○ 課題:「個々の技術スキル不足、チームとしての総合力不足」 ● サイクル構築のための題材:コードレビュー指摘 ○ 始めるも課題が見つかり頓挫… ➡ 一定やり切った&限界を迎え転職 15 ● 「自主性」を育むための環境・仕組みが必要 (仮説) ○ 根拠:自分=過去のキャリアで一度喪失したが身に着け成果を出した 他社事例を参考にするも適用できず… ● 小さなアウトプット/フィードバックサイクル形成 が成功の鍵 ● 自分達の環境が特殊 → 内側(自分達の環境内)に目を向けた 内側で題材を探し、見つける 根本解決のためには…

Slide 16

Slide 16 text

今だから言える事(伝えたいこと) 理想像を捉えつつも自分達に合う形を模索していく 16 ➡ 今は着手困難な課題でも未来では取り組み可能に ● 人は変えない →「仕組み」で「人の行動」を変える 支えになった考え方: ● 1つ1つ積み重ねていく(時間がかかってもいい) ※結果に繋がらずとも考え続ける限り「停滞」ではない ○ 見えていなかった課題が浮き彫りになっていく ○ 1つ1つが (思わぬ形でも) 繋がっていく ○ (レトロスペクティブの場は大事)

Slide 17

Slide 17 text

~おまけ~ 4年間で開発サイド全体のやり方が どう変わったか 17

Slide 18

Slide 18 text

開発サイド全体でのやり方の変遷 ● 最初にある程度計画立てる、後はやってみないと分からない  ➡ やり始めるも、途中で追加で必要な物が見つかる    ➡ リリース直前にツケが周って全体が疲弊 ● 最初にしっかり計画立て(スクラム×ウォーターフォール?) ○ 最初の1~2 Sprint = 計画立てがメイン ■ 各タスクで、何をやるかの具体とリスクを洗い出す ■ 各タスクは、可能な限り小さく分解 ■ 線表を作成 18

Slide 19

Slide 19 text

作成していた線表のイメージ ※これを1リリース分作成 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

Slide 20

Slide 20 text

離脱後の気付き ( スコープの調整余地なし = 残業or休出で補う一択 = 地獄 ) ● 中~短期スパン(数ヶ月等)で区切る =「Sprint」と「中短期スパン」の2段式(改善)サイクル ○ 現スパンのスコープを決めて計画立てて取り組み ○ 途中で追加が必要な物が見えたら、現スパンのスコープを調整 ○ 1スパンが完了したら、その先の解像度も上がる 「スクラムのデメリット:全体スケジュールが把握しづらい」の緩和策 20 ➡ 全体感を定期更新して共有、理解を得ながら進められる? ● 3ヶ月位のスパンで区切る = 良いことでは?

Slide 21

Slide 21 text

● 理想像を捉えつつも、自分達に合う形を模索していく ○ 1つ1つの積み重ねが繋がり、シナジーを生む ■ 今は着手困難な課題でも、未来では取り組み可能になる ○ 「人」は変えない→「仕組み」で「人の行動」を変える ● デメリットへの緩和案:中短期スパン(数ヶ月等)で区切りを置く ○ 「Sprint」と「中短期スパン」による2段式(改善)サイクル ○ 全体感を定期更新して共有、理解を得ながら進められる かも ○ (スクラム×ウォーターフォール) まとめ 21