サイボウズにおけるアジャイル開発とドキュメント

ASDoQ大会2023で発表されたものです。

2001年、アジャイルソフトウェア開発宣言によって、“アジャイル”という言葉が生まれたとき、その宣言の中で、“包括的なドキュメントには価値を置きながら、動くソフトウェアにより価値を置く”という考えを示しました。(1) しかし、具体的にドキュメントに何処まで価値を置くのかは述べていません。つまり、アジャイル開発でのシステム開発文書ドキュメントをどうするべきか、これは今でも論争の種になっています。
今回ご紹介していきたいのは、サイボウズでのあるアジャイル開発チームでの事例です。この事例は、アジャイル開発のドキュメントの代表例ではありません。ドキュメントに対するアプローチは、組織、ドメイン、プロセス、コンプライアンスなどの条件により、違っています。
このチームでは、機能仕様書を核としてドキュメントを作り、それを利用しています。彼らが作っているドキュメントは、イテレーションごとに、逐次的に作られています。核になる機能仕様書は、逐次、修正保守されています。その作業は、“動くソフトウェア”を開発するうえで、必要十分であり、さらに、開発の多くの場面で参照、使用されて無駄とは考えられていません。
この事例から、ソフトウェア開発におけるドキュメントの考え方、何のために、だれのためにドキュメントを作るのかということを議論しています。

Transcript

1. サイボウズにおけるアジャイル開発とドキュメント サイボウズ株式会社 アジャイルクオリティ 永田 敦
2. 永田 敦 サイボウズ株式会社 開発本部 アジャイル・クオリティ JSTQB Advanced Level Test Manager Agile Inspection Maestro 2008年 JaSST Tokyo ベストスピーカ賞受賞（マインドマップとHAYST法） 2011年 JaSST Tokyo ベストスピーカ賞受賞（リスクベーステスト） 2011年 5WCSQ (5th World Congress of Software Quality: 上海) 2016年 6WCSQ(6th World Congress of Software Quality: London) 2021年 JaSST Niigata 2021 基調講演 アジャイル・クオリティの探求 その他発表、ワークショップ多数 SQiP研究会 研究コース４ 「アジャイルと品質」 主査 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 2
3. 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 3 コードを書き、使い、保守することについて大半のエンジニアが持つ不平のうち、 並ぶものなく際立ってよくある不満点は 品質の高いドキュメンテーションの欠如である Googleのソフトウェアエンジニアリング
4. SECIモデル 4つの知識変換モード 表出化 Externalization 連結化 Combination 内面化 Internalization 共同化 Socialization 形式知 形式知 形式知 暗黙知 暗黙知 暗黙知 形式知 暗黙知 暗黙知と形式知が相互作用するときこそ、 イノベーションが生まれるのである 知識創造企業、野中郁次郎、竹内弘高
5. SECIモデル 表出化 表出化 連結化 内面化 共同化 形式知 形式知 形式知 形式知 暗黙知 暗黙知 暗黙知 暗黙知 ドキュメンテーション
6. SECIモデル 内面化 表出化 連結化 内面化 共同化 形式知 形式知 形式知 形式知 暗黙知 暗黙知 暗黙知 暗黙知 形式知を暗黙知に内面化するためには 書類、マニュアル、ストーリなどに 言語化・図式化されなければならない
7. SECIモデル 共同化 表出化 連結化 内面化 共同化 形式知 形式知 形式知 形式知 暗黙知 暗黙知 暗黙知 暗黙知
8. SECIモデル 連結化 表出化 連結化 内面化 共同化 形式知 形式知 形式知 形式知 暗黙知 暗黙知 暗黙知 暗黙知
9. ウォータフォールモデル 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 9 要求 分析 設計 実装 システム テスト 出荷判定 要求 仕様書 機能 仕様書 設計書 コード レビュー レビュー レビュー レビュー • プロセスで品質を作りこむ • 開発作業は、明確に目的を定義されたプロセスで区切られている。 • その成果物をドキュメントによって形式化している • ドキュメントをレビューを行うことで、プロセスを評価し、品質を確認する⇒品質ゲート • ドキュメントでプロセスをつなぎ、開発情報が集約されている。 • 製品全体をまとめてバッチ処理で進む • 要求からテスト（動かして確かめる）までの時間的隔たりが大きい⇒仮説検証に時間がかかる
10. ウォータフォールからAgileへ 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 10 分析 設計 実装 テスト 時間 時間 要求(スコープ) 要求(スコープ) Waterfall Agile Beck 2000 Royce 1970 ソフトウェア工学の分岐点における、アジャイルの役割、平鍋 健児、SS2010
11. 暗黙知 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 11 暗黙知
12. 表出化 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 12 暗黙知
13. 暗黙知から暗黙知へ：共同化 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 13 暗黙知
14. なぜ、アジャイル開発ではドキュメントが 少なくなるのか 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 14
15. スクラム・フレームワーク 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 15 グルーミング/0 リファインメント プランニング 仮説検証と改善 タスク遂行 モニタと改善 プロダクトバックログ スプリント計画 スプリントバックログ 振り返り スプリントレビュー スプリント 実施 デイリー スクラム 出荷判断可能な プロダクト インクリメント
16. ウォータフォールとSCRUM 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 16 要求 分析 設計 実装 システム テスト リファインメント （グルーミング） スプリント 計画 タスク実行 レビュー 振り返り ウォータフォール SCRUM
17. スプリント タイムボックス 一定の期間 目標をかえない 完成の定義に 合意する
18. プロダクトバックログ 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 18 プロダクトバックログ プロダクトバックログアイテム サイズ 無定形文 フューチャー 欠陥 技術的な改善 知識の獲得 ユースケース ユーザーストーリー ユースケース アイテム 要求
19. プロダクトバックログ ▌ユーザーストーリ ⚫ ユーザーの要求 ⚫ シナリオ；ふるまい ⚫ 要求の理由 ▌受け入れ条件 (acceptance Criteria) 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 19 SCRUMにおける要求ドキュメント
20. プロダクトバックログ：要求 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 20 • より早く価値を確かめたいもの • エッセンシャルな機能 MVP（Minimum Valuable Product) 実用最小限の製品を目指す すぐにスプリントで開 発に取り掛かれる状態 サイズが小さい 要求が詳細に 詰めてある
21. プロダクトバックログ・グルーミング 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 21 バックログ リファインメント オリジナルの 大きなバックログ バックログの 優先順位付変更 バックログの割り込み プロダクトバックログの見積もり サイズ プロダクトバックログアイテム バックログ削除 Product Owner（PO)が バックログの 毛づくろいをして MVPや優先順位を 最適なものにし続ける
22. バックログ・リファインメント 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 22 ストーリポイントで見積る 優先順位の低いものは ざっくりした表現でもよい • POがバックログをチームに説明する • 要求 • ユーザーストーリ • 受け入れ条件 • チームでの話し合い • POへの質問 • 開発者どうしでの質問・議論 • ここで、すでにどのように疾走 するかのイメージを考えている • チームによる見積もり バックログ（要求）を次のような状態にする • ビジネス上の価値よりが明確に正しく表現され • 十分に小さい大きさに分割され • 見積もりがされ • スプリントですぐに開発にかかれる
23. バックログ・リファインメント 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 23 要求プロセス： バックログの品質をあげ、開発ができる状態にする 目的、理由、背景 ユーザーストーリ 受け入れ条件 バックログの 説明 質問 見積もり PBI レディ スプリント スプリント スプリント 品質を埋め込む QA PG PO PO PG バックログの 改善 アーキテクチャ リスク 制約 PO Doing in parallel with Sprint リファインメント
24. リファインメント 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 24 このユーザー ストーリ は・・・ さてどう実装 するか？ プロダクトオーナ（PO) 開発者
25. リファインメント 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 25 ここの作りは どうでしたでしょうか 開発者 開発者 こんな感じ だったと思い ます
26. リファインメント 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 26 そこは決まって いませんでした どのように 使うだろうか プロダクトオーナ（PO) QA このように使っ た場合はどう振 舞いますか
27. 暗黙知の形成 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 27 暗黙知
28. リファインメント 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 28 見積もりは ”８”です プロダクトオーナ（PO) 開発者 割と複雑だなあ - 見積もりは いくつですか 少し大きいようですね 分割していきましょ
29. 氷山 不確定要素が隠れている 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 29 バックログもタスクも 大きいと 不確定要素が多い
30. 暗黙知による開発 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 30 開発チーム 暗黙知
31. 暗黙知のコミュニケーション 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 31 暗黙知
32. 暗黙知の問題 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 32 暗黙知 時間的、空間的な距離が離れるほど、暗黙知は乖離する
33. サイボウズにおけるアジャイル開発の事例 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 33
34. スプリントのプロセス例 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 34 スプリント Sprint Planning 2 リスク認識 タスク 計画 受入テスト 設計 仕様書変更 プロダクトバックログアイテム 設計・実装・テスト Sprint Review Sprint Panning 1 PO バックログ 説明 割り当て タスク実行 モブ・アクティビティ この場合複数のチームで開発している LeSS（Large Scale Scrum)を採用
35. スプリントプランニング２ 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 35 バックログ タスク設計 テスト実装 タスク実行 懸 念 点 出 し ・ モ ブ QA 設計 テ ス ト 設 計 ・ モ ブ 仕 様 作 成 ・ モ ブ PM UIデザイン リスクリスト 仕様書 受入テスト 設計書 システム テスト実行 品質の共有 内面化・共同化 品質の 確認 表出化 コード
36. ▌色々なプロセスに活用される情報が整理されドキュメントになっている ⚫ リスクリスト⇒仕様書、タスク設計、テスト設計書 ⚫ 仕様書⇒タスク設計、受入テスト設計書、タスク実行 ⚫ 受入テスト試験設計書⇒タスク実行（自動テスト）、テスト実装 ⚫ 開発とQAがモブで一緒に行う。モブによるレビュー効果がある。 36 活用されるドキュメント 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata
37. モブによるレビュー効果 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 37 次のステップ 対象 次のステップ ドライバ つぶ やき 自信 質問 相槌 改善 学び 提案 議論 返答 ナビゲータ ナビゲータ 説明 促進ループ 改善ループ https://speakerdeck.com/nagworld/kokogasugoi-mobupuroguramingu
38. アップデートされるドキュメント ▌仕様書 ⚫ 仕様書は、すべてのチームがオーナーで、共通で一つの仕様書を、ラン ニングごとにアップデートしている。 ⚫ バックログのスコープで、システムの振舞いで追加されたこと、変更され たことを加筆修正していく。 ⚫ 開発は、コード実装する前に、仕様を明確に理解し、この振舞をター ゲットに開発に集中することができる。 ⚫ QAは、確実に性格なテストベースが得られる ⚫ 小さいスコープなので、修正コストは多くない 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 38
39. 保守される仕様書のメリット ▌仕様書を書くことで、理解が深まったり、理解していないことが分かる ▌現在のシステムの挙動が正しいのかを確かめるリファレンス（基準） ▌前に開発したものと似たものを開発する場合がある。前に何をやったのかを参考にすることがで きる。 ▌仕様には、開発チームが行う方針が書かれている。その方向にあっているかを確認できる。 ▌同じスプリントばかりでなく、時間が離れていても参照する機会や、対象者は多く、有用な情 報であることが分かる。 ▌POがリビューして、実装する前に理解齟齬が検出できる。 ▌市場からの問い合わせ（クレーム）が仕様であるものか、想定外のふるまいか（バグ）が判 断できる ▌頻繁に仕様書を修正することで、表現が正確に洗練されていく。（訓練） 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 39
40. まとめ ▌アジャイル開発の場合、要求を分割し、ドキュメントだけでなく、多様な手段で 情報を伝達、共有し、活用している。 ▌SECIモデルで示されるような、暗黙知と形式知の変換が盛んにおこなわれて いる ▌それらの要因で、ドキュメントの量自体は少なくなっている。 ▌一方、サイボウズの例ように、ドキュメントという形式知を使い、特に仕様書をプ ランニングでアップデートしていることで、品質を先に組み込み、ドキュメントを後 のプロセスで生かしたアジャイル開発が実現できることを示した。 ▌これにより、サステナブルなビジネスモデルに耐えて、次の課題に挑戦しています 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 40
41. 41 参照文献 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata ▌ Googleのソフトウェアエンジニアリング、 Titus Winters 他、オライリージャパン、2021 ▌ 知識創造企業、野中郁次郎、竹内弘高、東欧経済新聞社、1996 ▌ エッセンシャル スクラム、Kenneth Rubin、 翔泳社、2014
42. 以上です ありがとうございました 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 42 サイボウズ株式会社 永田 敦 nagnagworld@gmail.com