1. SI案件でアジャイル開発を進めるときの勘所 2020/12/18 株式会社アトラクタ 取締役CTO/アジャイルコーチ 吉羽 龍太郎
2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定チームコーチ(CTC) / 認定スクラムプロ フェショナル(CSP) / 認定スクラムマスター(CSM) / 認定スクラムプロ ダクトオーナー(CSPO)。青山学院大学非常勤講師 2
3. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリングなどが専門領域 3
4. 登壇 各種イベントでの登壇 オンサイト トレーニング コーチング アジャイル開発やDevOps に関するオンサイトコーチ ング アジャイル開発や組織づくり に関するオンサイト トレーニング 認定研修 認定スクラムマスター研修 Suitable for all categories 等の主催 business and personal 執筆・翻訳 技術書やドキュメントの 執筆や翻訳 などなど
5. 本日のお話 ✤ SI案件でアジャイル開発をする際に気をつける必要がある以下の3つのテーマを取り 上げて解説します ✤ 顧客をはじめとしたステークホルダーマネジメント ✤ エンタープライズレベルの品質の作り込み ✤ チーム作り 5
7. SIのコンテキストにおけるステークホルダー ✤ ステークホルダーはさまざま ✤ 顧客（発注者） ✤ 顧客（ユーザー） ✤ 自社内のマネージャー ✤ 自社内の各部門（運用部門、セキュリティ部門、監査部門……） ✤ それぞれに対してステークホルダーマネジメントしていく必要 ✤ 提案〜案件終了までライフサイクル全体でさまざまな取り組みが必要 7
8. 顧客のアジャイルに対する理解はさまざま ✤ ✤ 顧客のアジャイルに対する理解は千差万別 ✤ 「最近アジャイルなるものが、多く使われるのでそれでやりたい」 ✤ 「ウォーターフォールよりアジャイルの方が速いらしい」 ✤ 「仕様変更が自由にできるので、走りながら考えればいい」 ✤ 「時間がないからアジャイルしかない」 ✤ 「速い・安い・うまい」 ✤ 「アジャイルだと失敗しない」 過度な期待を持っていることが多いので、期待値をすり合わせる 8
9. アジャイル導入の理由 プロダクトの出荷を速くしたい 優先順位変更に対応したい 51% 47% 42% 39% 37% 36% 31% 26% 23% 21% 18% 生産性をあげたい ビジネスとITのアラインメントを強化したい 品質をあげたい 出荷の予測性をあげたい プロジェクトリスクを減らしたい プロジェクトの可視性を向上したい チームの士気を高めたい プロジェクト費用を減らしたい エンジニアリングの規律を向上したい 分散チームをうまく管理したい ソフトウェアの保守性を上げたい 0 20 40 14th Annual State of Agile Survey, https://stateofagile.com/ 63% 60 71% 80 9
10. アジャイル導入の理由 プロダクトの出荷を速くしたい 優先順位変更に対応したい 51% ビジネスとITのアラインメントを強化したい 47% 品質をあげたい 42% 出荷の予測性をあげたい 39% プロジェクトリスクを減らしたい 37% 何に期待しているかを開始前に確認する プロジェクトの可視性を向上したい 36% チームの士気を高めたい 31% プロジェクト費用を減らしたい 26% エンジニアリングの規律を向上したい 23% 分散チームをうまく管理したい 21% ソフトウェアの保守性を上げたい 18% 63% 71% 生産性をあげたい 0 20 40 14th Annual State of Agile Survey, https://stateofagile.com/ 60 80 10
11. アジャイルとはフィードバックサイクルの集合体 1〜4週間 1〜4週間 1〜4週間 1〜4週間 1〜4週間 ✤ 大事だと思う要求から順番に実現していく(ときには不要なものを削除する) ✤ 作る(Build)、測定する(Measure)、学習する(Learn)の繰り返し ✤ 何が今やるべき大事なことなのかビジネス側は優先順位判断をし続ける(ビジネス側の継続的関与) ✤ 要求の中身も優先順位もすべて変化する可能性があり、それに対応する 11
12. 顧客に正しい知識を身に着けてもらう ✤ 営業活動の一環でも構わないので、アジャイルとは何か、アジャイルとは何でないの かを知ってもらう必要 ✤ 重要なポイント ✤ スコープは変わる ✤ 順番をつける ✤ 継続的な関与が必要 ✤ なんでも後回しにできるわけではない ✤ 顧客自身に大きな責任がある 12
13. アジャイルは複雑な問題の解決を目指す アジャイル ウォーターフォール 問題を把握するために試行錯誤（探 索）を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予測 しやすい領域。状況を専門家が分析して 理解し、取り得る手を検討して進めてい く。うまくやる方法は複数あるためそれを グッドプラクティスとして活用していく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 13
14. アジャイルは複雑な問題の解決を目指す アジャイル ウォーターフォール 問題を把握するために試行錯誤（探 索）を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予測 しやすい領域。状況を専門家が分析して 理解し、取り得る手を検討して進めてい く。うまくやる方法は複数あるためそれを グッドプラクティスとして活用していく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 「同じ物」を速く作る方法ではない 14
15. 契約をどうするか ✤ ✤ 従来のウォーターフォールだと以下が一般的 ✤ 要件定義フェーズは準委任 ✤ 開発〜テストフェーズは請負契約 アジャイル開発の場合どういう契約をするとよいか？ 15
16. 固定金額・固定スコープ (≒請負契約) => 危険 利益 売上 120 総額が固定される。 すなわち作業量が増えると利益が減る 96 金 72 額 48 変化を受け入れつつ範囲を固定する ことは非常に難しいので大量のバッファを積む 24 ことになってしまう(が足りるか分からない)… 0 1 2 労力 3 4 16
17. 上限付きタイムアンドマテリアル (≒準委任) 利益 売上 120 ここに達したら作業終了 96 金 72 額 48 24 0 1 2 労力 3 4 17
18. フェーズ分割契約 (≒準委任) 利益 120 売上 一定の間隔(複数スプリントの束)に区切って繰り返す。双方が解約権を持つ 96 金 72 額 48 24 0 1 2 3 労力 4 5 18
19. 現状でのアジャイル開発契約に対する解 ✤ ✤ 一括での請負契約は極めてハイリスク ✤ 紛争事例もある ✤ 発注者側の力関係が強いと、「定額、変更し放題、期間無制限」のような酷いことに なるケースも 準委任型の契約が望ましい ✤ IPAによるアジャイル開発モデル契約書でも準委任を前提としている ✤ 受注側から見た場合に、レバレッジが効きにくく、利益率に影響がでる可能性も ✤ 能力の高いチームを作り、チームを高い単価で売ることを考える 19
21. プロダクトオーナーを誰がやるべきか ✤ SIのコンテキストであれば、プロダクトオーナーはSI側から選任するのがベター ✤ ✤ ✤ 顧客側がPOを出した方がいいという見解を見ることもあるが…… 理由はさまざま ✤ プロジェクトに継続的に時間を確保しなければいけない ✤ 複数のステークホルダーの利害を調整しなければいけない ✤ 状況の変化にあわせて、スクラムチームが進むべき道を調整しなければいけない ✤ これらができる顧客はかなり少ない ✤ プロダクトオーナーが機能しないと、かなりの確率でプロジェクトは失敗する 顧客はステークホルダーとして扱う 21
22. 顧客とスクラムチーム全体との接点はスプリントレビュー 22
23. プロダクトオーナーの責務 ✤ SIにおけるプロダクトオーナーの最大の責務はステークホルダーマネジメント ✤ 機能の詳細化、優先順位付けを行い、ステークホルダーと合意を形成する ✤ ときにステークホルダー間の対立をなんとかしなければいけないことも ✤ 全体の進ちょくや見通しなどを明らかにする ✤ スプリントレビューにステークホルダーを招待して確実に参加させる ✤ ✤ スプリントレビューはあくまでプロダクトへのフィードバックの場 ✤ 承認を行う場ではない（裏でプロダクトオーナーが行えばよい） これらはほかのメンバーと協力して行っても良いが、意思決定は1人で行う ✤ 合議制は責任の所在の曖昧化と、速度の低下をもたらす 23
24. 社内ステークホルダーの扱い ✤ 自社内のマネージャーや各部門（運用部門、セキュリティ部門、監査部門……）も重要 なステークホルダー ✤ スプリントレビューに招待したり、プロダクトオーナーが個別に連携していく ✤ 最初から巻き込むのが鉄則 ✤ セキュリティや品質を最後に扱うのは無意味。これらをどう担保していくのか、計画 段階から継続的に関与させる 24
25. リスク低減のために初期に検討すべきポイント ✤ ✤ プロダクトに対する観点 ✤ 技術や品質に対する観点 ✤ ビジョン ✤ 技術的な解決策の概要 ✤ ゴール ✤ 品質・スコープ・期限等の優先順位 ✤ 成功の基準 ✤ スコープ外にするもの 人に対する観点 ✤ ステークホルダー概観 ✤ プロジェクトチーム ✤ 計画やマネジメントの観点 ✤ プロジェクトリスク ✤ 期間 ✤ 費用 25
27. 品質とは何か？ ✤ 「〜性」要求 = 非機能要件 ✤ 安全性、信頼性、効率性、有効性、拡張性、機密性、安定性、保守性など ✤ 「〜ができる」という要求 = 機能要求 ✤ 非機能要求と機能要求を満たしている度合い = 品質 ✤ どこをベースラインにするのかはトレードオフ ✤ ✤ 対象のプロダクトによって明確に違う ビジネスサイドにとっての品質 = バグの有無よりもそのプロダクトを利用してビジ ネス上の成果があげられるかどうか 27
28. ウォーターフォールのV字モデル 要求分析 受け入れテスト 要求定義 システムテスト 基本設計 結合テスト 詳細設計 単体テスト 実装 28
29. ウォーターフォールのリスク 変更のコストと リスク 要求 分析・設計 開発 時間 テスト デプロイ 29
30. 品質は検査では上がらない Quality comes not from inspection, but from improvement of the production process.. Edwards Deming ✤ 「全品検査への依存を止める。品質は統計的手 法で向上させる（完成後に欠陥を見つけるので はなく、欠陥を防止せよ）。」 ✤ => 品質は作り込むもの 30
31. スクラム概要 単体テスト、結合テスト、受け入れテストがプロダクトバックログ項目(≒要求)単位 で行われる。それが完了していることで初めてリリース判断可能とする 31
32. アジャイルのアプローチ（プロダクトバックログ項目ごと） ※PBI=プロダクト バックログ アイテム 変更のコストと リスク PBI#1 PBI#2 PBI#3 PBI#4 要求 要求 要求 要求 分析・設計 分析・設計 分析・設計 分析・設計 開発 開発 開発 開発 テスト(単体・結合…) テスト(単体・結合…) テスト(単体・結合…) テスト(単体・結合…) (デプロイ) (デプロイ) (デプロイ) (デプロイ) 時間 32
33. 完成の定義 (≒非機能要求) ✤ プロダクトとして定めた「リリース判断可能なプロダクト」を作成するために実施しな ければいけないことの一覧 ✤ 例えば、ユニットテストする、統合テストをする、静的解析する、リリースノートを書く、レ ビューするといった活動を明確化する ✤ 定義を満たしてはじめて「完成」となる。満たしていない場合はプロダクトオーナーの 受け入れ確認もしてはいけない ✤ プロダクトバックログ項目単位での完成の定義、スプリント単位での完成の定義、リ リース単位での完成の定義といった形で定義をすると分かりやすい 33
34. (参考) 受け入れ基準 (≒機能要求) ✤ 受け入れ基準とは「プロダクトバックログ項目」で満たしていないといけない機能性を 定義したもの ✤ したがってプロダクトバックログ項目単位で受け入れ基準は異なる ✤ 一方で、完成の定義は非機能要求の定義なので、（ほぼ）全プロダクトバックログ項目 に適用される 34
35. 品質の基準(完成の定義)、テスト範囲や内容の決め方 ✤ 範囲や内容は「目的」「ROI」「リスク」に依存する ✤ なぜ？なにを？だれのために？を明確にし、シンプルな実現方法を考える ✤ スクラムの場合、プロダクトオーナーと開発チームが中心となって考える ✤ ✤ プロダクトオーナーはもちろんステークホルダーと協働する ✤ ステークホルダーには社内の品質管理部門などが含まれることが多い 実際の開発を始める前に決めなければいけない ✤ 工数や必要なスキルセットへの影響が大きい 35
36. 品質 品質 出荷品質が 分からず進める 出荷前に品質 差分が埋まらない 出荷 可能品質 出荷 可能品質 高リスク #1 #2 #3 …………………… #Ship 品質 高リスク 時間 #1 #2 #3 …………………… #Ship 品質 出荷前に品質 差分を埋める 時間 最初から出荷 可能品質を維持 出荷 可能品質 出荷 可能品質 中リスク #1 #2 #3 …………………… #Ship 低リスク 時間 #1 #2 #3 …………………… #Ship 時間
37. 品質担保活動全体の流れ 工程・タイミング 主な実施内容 プロジェクト開始前 プロジェクトのビジネスを理解する、品質の定義 プロジェクト計画・リリース計画づくり 品質の定義、テスト計画の作成 繰り返しによる開発 レビュー、ユニットテスト、受け入れテスト、リグレッションテスト、探索的 テスト エンドゲーム（システムテスト） 負荷テスト、セキュリティテスト、全体のリグレッションテスト、ユーザー受 け入れテスト 本番リリース 本番リリース作業、スモークテスト 37
38. 社内の品質管理部門との関わり ✤ 品質管理部門はプロジェクトの後半ではなく、プロジェクト初期の計画作り、品質管理 の計画、テスト範囲の決定、テスト方法の決定についてチームを支援する方がよい 社内 品質基準 プロジェクト 品質基準 ビジネスの要求に あわせて調整 ＝完成の定義 品質管理部門 とチーム 38
39. スプリントにおける活動 ✤ スクラムではコーディング作業とテスト作業は密接につながっている ✤ つまりコーディングとテストとプロダクトオーナーの受け入れが終わって、はじめてそ の機能が完成したことになる ✤ テスト未完了(非機能要求が未対応)のもの、プロダクトオーナーが受け入れない(機 能要求が実現されていない)ものは、スプリントでの成果と見なされない ✤ スプリント内でどのようなテストを行えば完成となるのか、どのようなトラッキングが 必要なのかは、スプリント1を開始するまで(=準備フェーズ)に整理して合意しておく 39
40. 不具合の修正も極力スプリントで行う 問題が見つかったフェーズ 修正までの時間 要求や設計 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1日 問題は早期に発見するほど、解決の速度が速く影響範囲も少ないので原則としてすぐ直す。 スプリント内で開発したものをスプリント内で修正するのであればトラッキングの必要もない。 大きな不具合が発覚した場合は、プロダクトバックログに追加するなどして追跡することも。 つまりエンドゲームでのバグ密度には明確な差がでてくるので従来のモノサシで判断しないこと 40
41. バグが混入する時期 Capers Jones, Applied Software Measurement: Global Analysis of Productivity and Quality 41
42. バグを発見する時期 Capers Jones, Applied Software Measurement: Global Analysis of Productivity and Quality 42
43. バグを修正するのにいくらかかるか Capers Jones, Applied Software Measurement: Global Analysis of Productivity and Quality 43
44. バグ発見の時期をシフトレフトする Capers Jones, Applied Software Measurement: Global Analysis of Productivity and Quality 44
45. テスト自動化の必要性 機能数 コード行数 ✤ 小規模リリースのたびに手動で テストするとコードベースが大 きくなるにつれてテストコスト が膨らむ(特に回帰テスト) ✤ スクラムではフレームワークの 定義のみで、テスト自動化につ いては触れられていないが、 実際はテスト自動化は必須 テスト件数 1200 900 600 300 0 Sprint#1 #2 #3 #4 #5 #6 #7 #8 45
46. テスト自動化の必要性 ✤ 手作業で確認するのは時間がかかりすぎる（何度もやれば余計に） ✤ 手作業で確認すると、手順を間違えたり、結果の判断を間違える ✤ チームにもっと価値の高いところに集中してもらう ✤ 「生きたドキュメント」になる。テストが仕様を表す ✤ 何度でも実行できるし、実行に時間もかからないので、テストの障壁が下がる 46
48. ※テスト工程ではなく、テスト種別の観点で整理している アジャイルテストの4象限 【自動と手動】 機能テスト 例示 ストーリーテスト プロトタイプ シミュレーション 第2象限 【手動】 第3象限 探索的テスト シナリオテスト ユーザビリティテスト ユーザー受け入れテスト アルファ版、ベータ版 【自動化】 第1象限 単体テスト コンポーネントテスト 【ツール】 第4象限 パフォーマンステスト 負荷テスト セキュリティテスト 技術面でのテスト プロダクトを批評 チームを支援 ビジネス面でのテスト 48
49. ここまでの話を踏まえて検討する ✤ ここまでの話を踏まえて、このプロジェクト(プロダクト)において ✤ 品質とは何かを定義し ✤ その品質をいつ、どのように、誰が担保するのかを設計する ✤ その設計を関係者間で共有して、プロジェクトを進める 49
51. アジャイル開発での成果を決める要素 問題設定力 開発力 チーム力 ✤ 適切な問題設定 ✤ ドメイン知識 ✤ 開発プロセス習熟 ✤ 明確なビジョン ✤ アーキテクチャ設計力 ✤ 心理的安全性 ✤ マーケットの理解 ✤ 開発言語 ✤ 透明性 ✤ 取捨選択 ✤ 性能 ✤ 検査と適応 ✤ 良いプロダクトバックログ ✤ セキュリティ ✤ ムダをなくす ✤ 優先順位付け ✤ インフラストラクチャー ✤ 学習 ✤ ステークホルダー管理 ✤ 自動化 ✤ リーダーシップ ✤ リスク・コスト管理 ✤ 品質・テスト ✤ オーナーシップ ✤ … ✤ … ✤ … 51
52. チームは進化する タックマンモデル 形成期 混乱期 統一期 機能期 解散期 人が集まるがまだ独立して 意見を言うようになるが、 一緒に活動し、異なる意見 よく機能するチームとなる。 目的を果たし、チームが解 おりコミュニケーションが 一方で自分と違う意見に抵 を受け入れる。目的や期待 チームには一体感がある。 散する時期 少ない 抗を示すようになる 値などが一致する 自立性が高い 52
53. チームの成長に必要なもの => 心理的安全性 (……と成長に使える時間的余裕)
54. プロジェクトアリストテレス ✤ Googleが2012年に開始した労働生産性向上計画プロジェクト ✤ 生産性の高いチームの共通点の洗い出しと成功要因の分析を実施 ✤ 結果や知見をre:Workで公開（https://rework.withgoogle.com/） ✤ NewYork Timesなどでも記事が 54
56. うまくいっているチームに共通する要素の仮説 ✤ 仕事以外のプライベートでも親しい ✤ 頻繁に飲食をともにしている ✤ 内向的な人同士や外向的な人同士など似た特性の人でチームを構成している ✤ 興味や関心が似ている ✤ 圧倒的なリーダーシップやカリスマ性がある ✤ ボーナスや報酬によるモチベーション ✤ 共通の趣味 ✤ 共通の学歴 56
57. うまくいっているチームに共通する要素の仮説 ✤ 仕事以外のプライベートでも親しい ✤ 頻繁に飲食をともにしている ✤ 内向的な人同士や外向的な人同士など似た特性の人でチームを構成している ✤ 興味や関心が似ている ✤ 圧倒的なリーダーシップやカリスマ性がある ✤ ボーナスや報酬によるモチベーション ✤ 共通の趣味 ✤ 共通の学歴 どれも関係なかった 57
58. チームのルールやふるまいに注目 ✤ ✤ 個人の能力の合計とチームの能力はイコールではなかった ✤ 優秀な人が多いチームでも失敗している ✤ 成果を出したチームにほかのことをやらせても成功するが、失敗するチームは何を やっても失敗する現象 よい集団規範の有無が及ぼす影響が大きい ✤ ✤ 不文律・習慣・行動基準（明文化の有無は関係ない） 均等な発言機会と共感力・他者理解力があると成功しやすかった ✤ 心理的安全性 58
59. Effective DevOps ―4本柱による持続可能な組織文化の育て方 59
60. 機能しないチームでは話にならない ⑤結果への 無関心 ④説明責任の 回避 ③責任感の不足 ②衝突への恐怖 ①信頼の欠如 60
62. 意見を言えて、改善や実験（と失敗）を繰り返せる安全性が ハイパフォーマンスにつながる 62
63. 機能するチームづくりのコツ ✤ ✤ 稼働率を気にして人を交換可能な「リソース」とみなすと、チームの成果達成が遅れる ✤ プロジェクトの兼任(例: 0.5人月アサイン)を避ける ✤ 遅れが伝搬する、兼任側が燃えると延焼する 過度なチーム構成の変更を避けて、チームを維持する ✤ ✤ ✤ チームは生き物。それぞれのチームで違った進化をする パートナー比率を高くしすぎない ✤ パートナー比率が高すぎるとエンゲージメントの不足とノウハウの流出に直結 ✤ プロジェクトの成功に対するコミットメントを期待しにくい 良いチームを作って高く売る 63
64. 複数プロジェクト兼任によるムダ プロジェクト数 1プロジェクトあたりの稼働可能時間 コンテキストスイッチによるロス 1 100% 0% 2 40% 20% 3 20% 40% 4 10% 60% 5 5% 75% Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284. 64
65. まとめ ✤ SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可 能性があるので、案件開始前に教育すべし ✤ ステークホルダーマネジメントは重要。これはウォーターフォールでもアジャイルでも変 わらない。SI案件の場合、プロダクトオーナーの重要な仕事はこれ ✤ 要求される品質を開始前に明らかにする。そのために社内品質管理部門と連携したり顧 客と調整したりする必要がある ✤ 品質を最後に上げることはできないので、最初から最後まで確保し続けられるようにする ✤ 成果を出したければ良いチームを作ること ✤ 複数プロジェクトの兼任はムダでしかない 65
