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

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

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

約３ヶ月に１回を繰り返す（１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

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

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

本来の目指したかった姿 1. 個々の「状況」を見える化 ➡ 互いにフォローし合える 2. 道筋と現在地を明快化 ➡ 互いに迷いなく進める 3. 必要情報へアクセス容易化 ➡ 属人化/機会不均等の軽減 4. メンバーに委譲から状況によって併走へ ➡ 手戻り軽減 「自分一辺倒」な状態など望んでいなかった… 「お互いが支え合い全員で前進していく」状態にしたい 勝手に抱いていたスクラムに対するイメージ ● 互いの強み/得意を活かし協力しあうことでシナジーを生む 目指そうとして作った仕組み 7

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

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

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

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

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

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

主にコミュニケーション面の課題への改善・工夫 ○ チーム内コードレビューが「大きなボール」の投げ合いに ■ 指摘件数が多い、再レビューでもまだ多い ● ※小さい手戻りも積み重なる 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減 /連携強化 ○ 実装中のコードを上げてもらう ➡ 先回りフィードバック ■ どの時点で上げるかは最初に決めたり、担当者に委ねたり ■ レビュー依頼時には細かい部分のチェックで済ませられる 14 課題 タスクがずるずる長引く(完了の見通しがみえづらい) 手段 Ｄｒａｆｔ ＭＲ、Ｄｒａｆｔ ＰＲ を活用し始める

主にコミュニケーション面の課題への改善・工夫 ● (完全ではないが) 手戻り感の軽減 ● メンバー間で連携が必要になる事項にも気付きやすい ➡ ＭＲ/ＰＲ に直接書き込んで連携できる ● 完了見通しを握りやすい 15 手段 Ｄｒａｆｔ ＭＲ、Ｄｒａｆｔ ＰＲ を活用し始める ○ 実装中のコードを上げてもらう ➡ 先回りフィードバック 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減 /連携強化 課題 タスクがずるずる長引く(完了の見通しがみえづらい)

主にコミュニケーション面の課題への改善・工夫 1. 個々の「状況」を見える化 ➡ 互いにフォローし合える 2. 道筋と現在地を明快化 ➡ 互いに迷いなく進める 3. 情報のオープン化 ➡ 属人化/機会不均等の軽減 4. 実装時も委譲から併走・協働へ ➡ 手戻り軽減 /連携強化 「お互いが背を支え合い全員で前進する」状態に近づけた 16 取り組み：

(からこその成果 ） ● 根拠：自分自身 過去のキャリア(主にデスマーチ)を経て「自主性」喪失 　➡ スクラムにある程度適応 　➡ 自主性を一定身に着けた ● 慢性的なチームの課題： ○ 個々の技術スキル不足、チームの戦闘力不足 ■ 不安定なベロシティ（未完了タスク持ち越し常態化） 　　　　　　　　　　　　に立ち向かっていけそうな状態に 主にコミュニケーション面の課題への改善・工夫 「自主性」を育むための環境・仕組みが必要 17 根本解決のためには…

実現したかったが、道半ばで実現できなかったこと ○ 業務で役立ちそうなツールやOSSを共有 ➡ 環境の制約上困難 ○ 読書会などを行い、学び/気付きを共有 ➡ 多忙により賛同得られず ○ ※主導開催していた勉強会中止（一方通行で効果０と苦渋の決断） 小さなアウトプット/フィードバックサイクル形成が成功の鍵 気付き(うまくいく共通点) ● 自分達の環境は特殊 ➡ 外に目を向けず、内に目を向けた ○ サイクル形成の題材を内側(自分達の環境)で探した 「自主性/主体性」を育むための環境・仕組み を作るために… 18 他社の事例を参考にしようとするも適用できず

実現したかったが、道半ばで実現できなかったこと ○ ネタには困らない（ほぼ無限に溢れてくる） ○ 無理なくフィードバック可能（初動は自分が主導可） ○ チーム内での知識共有 ○ メンバーの(内部)設計力向上 ○ 自チームの弱点傾向分析 ➡ レビュー指摘を手で集めるのに超手間がかかる 　 → 改善策を打ったものの上手くいかず 　 → ボールを握られ自然消滅 　 → (一定やり切り限界を迎え)転職活動へ… (→ 1年半後の今) Time up メリット 19 見つけた題材：コードレビュー指摘

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

今だから言える事（伝えたい大事なこと）2/3 ● 継続は力なり ● 見えている「問題」だけを上げるのはもったいない ○ 失敗、違和感 (何かやりづらい/上手くできない) など 「問題提起」に達せずとも上げれる雰囲気を作る 21 失敗や違和感などの裏側には「仕組み」の問題が潜んでいる ➡ Ｔｒｙを考え（取捨選択して）試す ➡ 皆で深掘り＆推測して、どこに問題点があるか考える レトロスペクティブの機会は大事

今だから言える事（伝えたい大事なこと） 3/3 22 Ｑ. (忙殺される中で) なぜ改善をやり続けられたのか？ 個々が持つ「得意なこと(才能)」を個々が捉え活かすも大事 ● スクラムでの「得意や強みを活かす」→ 得意や強み≒スキル/経験 (改善実行にあたり)元から「スキル/経験」があったか？ No ● 本能的な衝動に従って勝手にやり続けたというだけ ※当時は認識すらできていなかったが本能的にやっていた ➡ (スキル/経験なかったが) 気付いたら「成果」が出た Ａ. 自分の「得意なこと(才能)」が「舞台整備」だから

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

開発サイド全体でのやり方の変遷 ● 最初にある程度計画立てるが、後はやってみないと分からない 　➡ やり始めるも途中で追加で必要な物が見つかる 　　　➡ リリース直前にツケが周って全体が疲弊 ● 最初にしっかり計画立て（スクラム×ウォーターフォール？） ○ 最初の１～２Sprint は 計画のための調査・準備 ○ ※主にチームリーダーが担当、メンバーは明確なタスクから着手 ■ 各タスクで、何をやるかの具体とリスクを洗い出す ■ 各タスクは 2, 3 point にまで分解（大きくても 5 point) ■ 線表を作成 24

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

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

● 理想像を捉えつつも、自分達に合う形を模索していく ○ 「人」は変えない→「仕組み」で「人の行動」を変える ○ 積み重ねが繋がりを生み、困難な課題にも取り組み可能になる ○ 失敗や違和感など「問題提起」に達せずとも上げる→深掘り/試行 ● スクラムでの「得意や強みを活かす」 ○ (既に持っているスキルや経験を活かすだけに留まらず) 各個人が持つ「得意なこと(才能)」を個々が捉え活かすのも大事 ● デメリットへの緩和案：中短期スパン(数ヶ月等) で区切りを置く ○ ≒ スクラム×ウォーターフォール ■ 「Sprint」と「中短期スパン」による２段式(改善)サイクル まとめ 27