お客様とSIerではじめたスクラム開発(で得た学び)

Transcript

1. お客様とSIerではじめた スクラム開発（で得た学び） 2025.10.04 SATOSHI KANEYASU
2. 2 氏名：兼安 聡 所属：株式会社サーバーワークス アプリケーションサービス部 在住：広島（フルリモート） 担当：DevOps、技術支援、PM、SM SNS(X)：@satoshi256kbyte • 2025 AWS Community Builders • 2025 Japan AWS Top Engineers (AI/ML Data Engineer) • 2025 Japan AWS All Certifications Engineers • 認定スクラムマスター • PMP Speaker Introduction
3. 3 Table of Contents 1. スクラムの基礎用語 2. お客様がSIerに期待すること 3. プロジェクトを軌道に乗せるまで 4. 今からやり直すとしたら 5. まとめ
4. スクラムの基礎用語
5. ⚫ スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、 チーム、組織 が価値を⽣み出すための軽量級フレームワークである。 引用：スクラムガイド スクラムの定義
6. スクラムのスプリント 1日目 2日目 3日目 4日目 5日目 6日目 7日目 8日目 9日目 10日目 デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム プランニング スプリントレビュー レトロスペクティブ 1日目 2日目 3日目 4日目 5日目 6日目 7日目 8日目 9日目 10日目 デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム プランニング スプリントレビュー レトロスペクティブ Sprint N Sprint N+1
7. スクラムイベント イベント やること 頻度 プランニング • スプリントゴールとやることを決める • 毎スプリントで最低1回 デイリースクラム • 日々の進捗を確認し、進行に障害があればアラートをあげる • 毎日 スプリントレビュー • スプリントゴールに到達したか検査する • 動くものを見せる • 毎スプリントで最低1回 レトロスペクティブ • このスプリントの振り返りを行う • 毎スプリントで最低1回
8. 出来上がる機能(≒ユーザ体験)で縦軸できることが大切
9. もう一度スクラムのスプリント 1日目 2日目 3日目 4日目 5日目 6日目 7日目 8日目 9日目 10日目 デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム プランニング スプリントレビュー デイリースクラム 1日目 2日目 3日目 4日目 5日目 6日目 7日目 8日目 9日目 10日目 デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム デイリー スクラム プランニング スプリントレビュー デイリースクラム Sprint N Sprint N+1
10. スクラムは短期のサイクルを繰り返す スプリントプランニング スプリントレビュー、レトロスペクティブ
11. スクラムチーム 名称 責任 やること 開発者 • スプリントのゴールに責任を持つ • スプリントの計画 • PBI（やること）の消化 プロダクトオーナー • プロダクトの価値を最大化することに責任を持つ • リリースの計画 • 効果的なプロダクトバックログ運営 スクラムマスター • スクラムの働き方に対して責任を持つ • チームにスクラムを浸透させる • チーム内のプロセス改善を実行する • 別進捗を妨げる障害を明確化・解消する
12. お客様がSIerに期待すること
13. ⚫ お客様にシステムの開発を依頼される組織 ⚫ お客様だけではできないことを実現するための組織 私の考えるSIer
14. ⚫ システムやサービスを「次のステップに進めたい」 ⚫ 自分たちだけではできないことを補完して欲しい ⚫ 着実に成果を出して欲しい 私がよく依頼されること お客様の状況 スタイル やりたいことが明確 ウォータフォール やりたいことになんらかの不透明さがある スクラム 自分たちで進められるが、確信が持てない 壁打ち
15. ⚫ 0から1ではなく、3〜6から8〜10にする作業 ⚫ 例えば ⚫ 操作性の向上 ⚫ 保守性の向上 ⚫ パフォーマンスの向上 ⚫ 拡張性の強化 ⚫ セキュリティの強化 ⚫ モニタリング ⚫ 統制 「次のステップに進めたい」とは プロダクトレベルまで引き上げるということ
16. プロジェクトを軌道に乗せるまで
17. 開発手法によるコミュニケーションスタイルの違い 開発者 開発者 開発者 プロジェクト マネージャ お客様 担当者 開発者 開発者 開発者 プロダクト オーナー スクラム マスター [ウォーターフォール] [スクラム] 短期間のサイクルで成果を出し続けるには、 こちらのコミュニケーションスタイルが必要
18. 組織が分かれるとどうしても組織のラインが入る 開発者 開発者 開発者 プロジェクト マネージャ お客様 担当者 開発者 開発者 開発者 プロダクト オーナー スクラム マスター [ウォーターフォール] [スクラム] 組織のライン 注）本当は組織のラインがあるのは、 スクラム的にはよろしくないとは思います
19. ⚫ 窓口役がいるスタイルに慣れているのは、開発者もお客様も同じ ⚫ 短期間のサイクルで成果を出し続けるには、 開発者とプロダクトオーナーが直にやりとりする必要がある ⚫ スクラムマスターは、直のやりとりを全力でフォロー ⚫ 開発者自身に会話してもらう ⚫ 互いの専門用語の通訳を行う ⚫ やるしか答えがないことについてまで、いちいちお伺いを立てない ⚫ 開発者自身にデモしてもらう ダイレクトなコミュニケーションを促す
20. ⚫ お客様との信頼関係がないとプロジェクト＝契約自体が続きません ⚫ 報告に力を尽くすことは、信頼関係の維持に寄与すると考えています ⚫ 現実問題として、地味でデモがしづらく、大変なのに報告しづらいも のは存在する ⚫ 例）セキュリティ、統制など ⚫ 私はスプリントレビューの際に設計書とは別の、 レビュー用に特化した構成図や業務フローを作って 成果物がビジネスのどこに寄与するものなのかできる限り説明するよ うにしています 成果物が地味でデモしづらい場合は新たに資料を作る
21. ITエンジニアのスキルツリーと求められるもの プログラマー デザイン バックエンド データベース フロントエンド サーバー セキュリティ ネットワーク モニタリング 統制 習得：難 習得：難 ⚫ 操作性の向上 ⚫ 保守性の向上 ⚫ パフォーマンスの向上 ⚫ 拡張性の強化 ⚫ セキュリティの強化 ⚫ モニタリング ⚫ 統制 [求められるもの]
22. 苦手タスクが含まれる例：拡張性の強化 習得：難 習得：難 ⚫ 操作性の向上 ⚫ 保守性の向上 ⚫ パフォーマンスの向上 ⚫ 拡張性の強化 ⚫ セキュリティの強化 ⚫ モニタリング ⚫ 統制 [求められるもの] ★ ★ ★ ★ その人にとって習得が難しい部分に あたるとそこで止まりやすい プログラマー デザイン バックエンド データベース フロントエンド サーバー セキュリティ ネットワーク モニタリング 統制
23. ⚫ さすがに自身の本来の得意分野から離れたようなスキルまで高レベル で揃えている人は稀 ⚫ 苦手なタスクは、割り込み作業などが入るとそれを理由に後回しにさ れやすい（最悪止まったままレビューになだれ込んでしまう） ⚫ AIなどを駆使しながら、できるだけ計画を詳細化 スキルが足らないタスクについては、相談・学習まで計画に入れる ⚫ 日々進捗をチェックし、変化がない（＝後回し）タスクはすぐ確認 次のステップに進めるならば必ず苦手タスクがあると心得る
24. 今からやり直すとしたら
25. モノリスの種類とマイクロサービス モジュール データベース C D E DB ①モノリス ②モジュラーモノリス ④マイクローサービス モジュール DB モジュール DB モジュール DB モジュール ③分散モノリス モジュールA モジュールB データベース DB モジュール DB モジュール DB モジュール DB モジュール デプロイ単位 デプロイ単位 デプロイ単位 デプロイ単位 デプロイ単位 参考書籍：マイクローサービスアーキテクチャ
26. モノリスとマイクロサービスについて今一度考える モジュール データベース C D E DB ①モノリス ②モジュラーモノリス ④マイクローサービス モジュール DB モジュール DB モジュール DB モジュール ③分散モノリス モジュールA モジュールB データベース DB モジュール DB モジュール DB モジュール DB モジュール デプロイ単位 デプロイ単位 デプロイ単位 デプロイ単位 デプロイ単位 ⚫ マイクロサービスはメリットはあるが、必要スキルが増える ⚫ やり直すとしたらもう少しモノリス寄りから始めるかもしれない
27. ⚫ マイクロサービスは良くも悪くも小さいが、 必要スキルと考えることが多く、スモールスタートとは微妙に違う ⚫ あえてモノリスから作り、途中から切り出していく方法も検討したい ⚫ ただし、モノリスからの「作り直し」ではなく「切り出し」となるよ う、言語・フレームワークを選定し、時には最初から移行先を見据え ておく必要があるだろう モノリスからマイクロサービスへの切り出しを意識する
28. まとめ
29. ⚫ お客様とSIerではじめるスクラム開発は、「次のステップに進める」 ためのプロジェクトが多い ⚫ 「次のステップに進める」だから、難易度の高いタスクが発生する 難易度の高いタスクは相談の時間まで計画しておく ⚫ コミュニケーションスタイルの違いによる苦労は高確率で起きるので 全力でフォロー ⚫ マイクロサービスとスモールスタートは微妙に違うと思います まとめ
31. ⚫ スクラムガイド ⚫ スクラム開発を体系的に学んだのでアウトプットする 参考資料