$30 off During Our Annual Pro Sale. View Details »

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

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

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

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

Atsushi Nagata

October 31, 2023
Tweet

More Decks by Atsushi Nagata

Other Decks in Technology

Transcript

  1. サイボウズにおけるアジャイル開発とドキュメント
    サイボウズ株式会社
    アジャイルクオリティ
    永田 敦

    View Slide

  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研究会 研究コース4 「アジャイルと品質」 主査
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 2

    View Slide

  3. 2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 3
    コードを書き、使い、保守することについて大半のエンジニアが持つ不平のうち、
    並ぶものなく際立ってよくある不満点は
    品質の高いドキュメンテーションの欠如である
    Googleのソフトウェアエンジニアリング

    View Slide

  4. SECIモデル 4つの知識変換モード
    表出化
    Externalization
    連結化
    Combination
    内面化
    Internalization
    共同化
    Socialization
    形式知
    形式知
    形式知
    暗黙知
    暗黙知
    暗黙知
    形式知
    暗黙知
    暗黙知と形式知が相互作用するときこそ、
    イノベーションが生まれるのである
    知識創造企業、野中郁次郎、竹内弘高

    View Slide

  5. SECIモデル 表出化
    表出化
    連結化
    内面化
    共同化
    形式知
    形式知
    形式知
    形式知
    暗黙知
    暗黙知
    暗黙知
    暗黙知
    ドキュメンテーション

    View Slide

  6. SECIモデル 内面化
    表出化
    連結化
    内面化
    共同化
    形式知
    形式知
    形式知
    形式知
    暗黙知
    暗黙知
    暗黙知
    暗黙知
    形式知を暗黙知に内面化するためには
    書類、マニュアル、ストーリなどに
    言語化・図式化されなければならない

    View Slide

  7. SECIモデル 共同化
    表出化
    連結化
    内面化
    共同化
    形式知
    形式知
    形式知
    形式知
    暗黙知
    暗黙知
    暗黙知
    暗黙知

    View Slide

  8. SECIモデル 連結化
    表出化
    連結化
    内面化
    共同化
    形式知
    形式知
    形式知
    形式知
    暗黙知
    暗黙知
    暗黙知
    暗黙知

    View Slide

  9. ウォータフォールモデル
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 9
    要求 分析 設計 実装
    システム
    テスト
    出荷判定
    要求
    仕様書
    機能
    仕様書
    設計書 コード
    レビュー レビュー レビュー レビュー
    • プロセスで品質を作りこむ
    • 開発作業は、明確に目的を定義されたプロセスで区切られている。
    • その成果物をドキュメントによって形式化している
    • ドキュメントをレビューを行うことで、プロセスを評価し、品質を確認する⇒品質ゲート
    • ドキュメントでプロセスをつなぎ、開発情報が集約されている。
    • 製品全体をまとめてバッチ処理で進む
    • 要求からテスト(動かして確かめる)までの時間的隔たりが大きい⇒仮説検証に時間がかかる

    View Slide

  10. ウォータフォールからAgileへ
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 10
    分析
    設計
    実装
    テスト
    時間 時間
    要求(スコープ) 要求(スコープ)
    Waterfall Agile
    Beck 2000
    Royce 1970
    ソフトウェア工学の分岐点における、アジャイルの役割、平鍋 健児、SS2010

    View Slide

  11. 暗黙知
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 11
    暗黙知

    View Slide

  12. 表出化
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 12
    暗黙知

    View Slide

  13. 暗黙知から暗黙知へ:共同化
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 13
    暗黙知

    View Slide

  14. なぜ、アジャイル開発ではドキュメントが
    少なくなるのか
    2023/10/27
    ASDoQ大会 2023 copyright © Atsushi Nagata 14

    View Slide

  15. スクラム・フレームワーク
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 15
    グルーミング/0
    リファインメント
    プランニング
    仮説検証と改善
    タスク遂行
    モニタと改善
    プロダクトバックログ
    スプリント計画
    スプリントバックログ
    振り返り
    スプリントレビュー
    スプリント
    実施
    デイリー
    スクラム
    出荷判断可能な
    プロダクト
    インクリメント

    View Slide

  16. ウォータフォールとSCRUM
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 16
    要求 分析 設計 実装
    システム
    テスト
    リファインメント
    (グルーミング)
    スプリント
    計画
    タスク実行 レビュー 振り返り
    ウォータフォール
    SCRUM

    View Slide

  17. スプリント
    タイムボックス
    一定の期間
    目標をかえない 完成の定義に
    合意する

    View Slide

  18. プロダクトバックログ
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 18
    プロダクトバックログ
    プロダクトバックログアイテム
    サイズ
    無定形文
    フューチャー
    欠陥
    技術的な改善
    知識の獲得
    ユースケース
    ユーザーストーリー
    ユースケース
    アイテム
    要求

    View Slide

  19. プロダクトバックログ
    ▌ユーザーストーリ
    ⚫ ユーザーの要求
    ⚫ シナリオ;ふるまい
    ⚫ 要求の理由
    ▌受け入れ条件 (acceptance Criteria)
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 19
    SCRUMにおける要求ドキュメント

    View Slide

  20. プロダクトバックログ:要求
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 20
    • より早く価値を確かめたいもの
    • エッセンシャルな機能
    MVP(Minimum Valuable Product)
    実用最小限の製品を目指す
    すぐにスプリントで開
    発に取り掛かれる状態
    サイズが小さい
    要求が詳細に
    詰めてある

    View Slide

  21. プロダクトバックログ・グルーミング
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 21
    バックログ
    リファインメント
    オリジナルの
    大きなバックログ
    バックログの
    優先順位付変更
    バックログの割り込み
    プロダクトバックログの見積もり
    サイズ
    プロダクトバックログアイテム
    バックログ削除
    Product Owner(PO)が
    バックログの
    毛づくろいをして
    MVPや優先順位を
    最適なものにし続ける

    View Slide

  22. バックログ・リファインメント
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 22
    ストーリポイントで見積る
    優先順位の低いものは
    ざっくりした表現でもよい
    • POがバックログをチームに説明する
    • 要求
    • ユーザーストーリ
    • 受け入れ条件
    • チームでの話し合い
    • POへの質問
    • 開発者どうしでの質問・議論
    • ここで、すでにどのように疾走
    するかのイメージを考えている
    • チームによる見積もり
    バックログ(要求)を次のような状態にする
    • ビジネス上の価値よりが明確に正しく表現され
    • 十分に小さい大きさに分割され
    • 見積もりがされ
    • スプリントですぐに開発にかかれる

    View Slide

  23. バックログ・リファインメント
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 23
    要求プロセス:
    バックログの品質をあげ、開発ができる状態にする
    目的、理由、背景
    ユーザーストーリ
    受け入れ条件
    バックログの
    説明 質問 見積もり
    PBI
    レディ
    スプリント
    スプリント スプリント
    品質を埋め込む
    QA PG
    PO
    PO
    PG
    バックログの
    改善
    アーキテクチャ
    リスク
    制約
    PO
    Doing in parallel with
    Sprint
    リファインメント

    View Slide

  24. リファインメント
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 24
    このユーザー
    ストーリ
    は・・・
    さてどう実装
    するか?
    プロダクトオーナ(PO) 開発者

    View Slide

  25. リファインメント
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 25
    ここの作りは
    どうでしたでしょうか
    開発者 開発者
    こんな感じ
    だったと思い
    ます

    View Slide

  26. リファインメント
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 26
    そこは決まって
    いませんでした
    どのように
    使うだろうか
    プロダクトオーナ(PO) QA
    このように使っ
    た場合はどう振
    舞いますか

    View Slide

  27. 暗黙知の形成
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 27
    暗黙知

    View Slide

  28. リファインメント
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 28
    見積もりは
    ”8”です
    プロダクトオーナ(PO) 開発者
    割と複雑だなあ
    -
    見積もりは
    いくつですか
    少し大きいようですね
    分割していきましょ

    View Slide

  29. 氷山 不確定要素が隠れている
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 29
    バックログもタスクも
    大きいと
    不確定要素が多い

    View Slide

  30. 暗黙知による開発
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 30
    開発チーム
    暗黙知

    View Slide

  31. 暗黙知のコミュニケーション
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 31
    暗黙知

    View Slide

  32. 暗黙知の問題
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 32
    暗黙知
    時間的、空間的な距離が離れるほど、暗黙知は乖離する

    View Slide

  33. サイボウズにおけるアジャイル開発の事例
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 33

    View Slide

  34. スプリントのプロセス例
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 34
    スプリント
    Sprint
    Planning 2
    リスク認識
    タスク
    計画
    受入テスト
    設計
    仕様書変更
    プロダクトバックログアイテム
    設計・実装・テスト
    Sprint
    Review
    Sprint
    Panning 1
    PO
    バックログ
    説明
    割り当て
    タスク実行
    モブ・アクティビティ
    この場合複数のチームで開発している LeSS(Large Scale Scrum)を採用

    View Slide

  35. スプリントプランニング2
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 35
    バックログ
    タスク設計
    テスト実装
    タスク実行








    QA
    設計















    PM
    UIデザイン
    リスクリスト 仕様書
    受入テスト
    設計書
    システム
    テスト実行
    品質の共有
    内面化・共同化
    品質の
    確認
    表出化
    コード

    View Slide

  36. ▌色々なプロセスに活用される情報が整理されドキュメントになっている
    ⚫ リスクリスト⇒仕様書、タスク設計、テスト設計書
    ⚫ 仕様書⇒タスク設計、受入テスト設計書、タスク実行
    ⚫ 受入テスト試験設計書⇒タスク実行(自動テスト)、テスト実装
    ⚫ 開発とQAがモブで一緒に行う。モブによるレビュー効果がある。
    36
    活用されるドキュメント
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata

    View Slide

  37. モブによるレビュー効果
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 37
    次のステップ
    対象
    次のステップ
    ドライバ
    つぶ
    やき
    自信
    質問 相槌
    改善
    学び
    提案
    議論
    返答
    ナビゲータ ナビゲータ
    説明
    促進ループ
    改善ループ
    https://speakerdeck.com/nagworld/kokogasugoi-mobupuroguramingu

    View Slide

  38. アップデートされるドキュメント
    ▌仕様書
    ⚫ 仕様書は、すべてのチームがオーナーで、共通で一つの仕様書を、ラン
    ニングごとにアップデートしている。
    ⚫ バックログのスコープで、システムの振舞いで追加されたこと、変更され
    たことを加筆修正していく。
    ⚫ 開発は、コード実装する前に、仕様を明確に理解し、この振舞をター
    ゲットに開発に集中することができる。
    ⚫ QAは、確実に性格なテストベースが得られる
    ⚫ 小さいスコープなので、修正コストは多くない
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 38

    View Slide

  39. 保守される仕様書のメリット
    ▌仕様書を書くことで、理解が深まったり、理解していないことが分かる
    ▌現在のシステムの挙動が正しいのかを確かめるリファレンス(基準)
    ▌前に開発したものと似たものを開発する場合がある。前に何をやったのかを参考にすることがで
    きる。
    ▌仕様には、開発チームが行う方針が書かれている。その方向にあっているかを確認できる。
    ▌同じスプリントばかりでなく、時間が離れていても参照する機会や、対象者は多く、有用な情
    報であることが分かる。
    ▌POがリビューして、実装する前に理解齟齬が検出できる。
    ▌市場からの問い合わせ(クレーム)が仕様であるものか、想定外のふるまいか(バグ)が判
    断できる
    ▌頻繁に仕様書を修正することで、表現が正確に洗練されていく。(訓練)
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 39

    View Slide

  40. まとめ
    ▌アジャイル開発の場合、要求を分割し、ドキュメントだけでなく、多様な手段で
    情報を伝達、共有し、活用している。
    ▌SECIモデルで示されるような、暗黙知と形式知の変換が盛んにおこなわれて
    いる
    ▌それらの要因で、ドキュメントの量自体は少なくなっている。
    ▌一方、サイボウズの例ように、ドキュメントという形式知を使い、特に仕様書をプ
    ランニングでアップデートしていることで、品質を先に組み込み、ドキュメントを後
    のプロセスで生かしたアジャイル開発が実現できることを示した。
    ▌これにより、サステナブルなビジネスモデルに耐えて、次の課題に挑戦しています
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata 40

    View Slide

  41. 41
    参照文献
    2023/10/27 ASDoQ大会 2023 copyright © Atsushi Nagata
    ▌ Googleのソフトウェアエンジニアリング、 Titus Winters 他、オライリージャパン、2021
    ▌ 知識創造企業、野中郁次郎、竹内弘高、東欧経済新聞社、1996
    ▌ エッセンシャル スクラム、Kenneth Rubin、 翔泳社、2014

    View Slide

  42. 以上です
    ありがとうございました
    2023/10/27
    ASDoQ大会 2023 copyright © Atsushi Nagata 42
    サイボウズ株式会社
    永田 敦
    [email protected]

    View Slide