「アジャイル開発においてはドキュメントは不要」という意見を聞いたことはないだろうか。
確かに開発プロジェクトにおいては、ドキュメントを作ること自体は目的ではない。ドキュメントはあくまでも最終的なシステムを作るための補助的な材料であることは事実だ。そのため、ドキュメントを作る時間がもったいないからドキュメント自体不要であるという考えが一部広まってしまっているのかもしれない。
しかし、アジャイル開発においてドキュメントが不要というのは間違っている。単純にドキュメント作成自体が目的ではないというだけの話だ。
そのため、この記事ではアジャイル開発において必要になるドキュメントについて説明する。具体的には以下の３つのポイントを説明する。
それでは見ていこう。
アジャイル開発でドキュメントが必要かを判断する基準
アジャイル開発においてもドキュメントの作成は必要だ。そこで、ドキュメント作成においてそれが必要か否かを判定する基準が必要になる。
その基準は以下のように整理できる。
それぞれ詳しく見ていこう。
「何を作るか」のを記載するものか
アジャイル開発でも「何を作るか」の認識を合わせるためのドキュメントは必要だ。
そもそも開発プロジェクトにおけるドキュメントには二つの種類がある。それはドキュメントの内容が以下のどちらを記しているのかによって分類できる。
前者はビジネス担当と開発チームの認識を合わせる要件定義などのための書類であり、後者は開発内部で使用する設計書のことだ。
そして、前者の意図でドキュメントを作るのは重要だということだ。これが開発チームと発注者やビジネスの担当者の両者の認識を統一するための唯一の方法だからだ。
途中でプロジェクトに参加する人のキャッチアップを楽にするか
先ほどの章では、開発側とビジネス側の認識を合わせるための手段としてドキュメントが必要だという説明をした。
開発チーム内部での認識を合わせる手段としてもドキュメントは必要だ。その際の主要な判断基準の一つとして、プロジェクトに途中から参加する人が容易にキャッチアップできるようになるかがある。
例えばシステム全体のアーキテクチャや、データ構造がわかるER図などがあれば、それだけでミドル以上のエンジニアであればシステムに対する理解を一定程度自ら把握することができる。特にER図があれば、そのサービスの核となるデータが何かが分かるので、優先度をつけてキャッチアップをしやすい。
以下のようなER図があったとしよう。
このER図を見ると、「注文」と「顧客」から多くの線が出ているのがわかる。つまり、この二つが色々な関連を持っているのがわかる。そのためこのサービスの核となるのは「注文」と「顧客」であり、キャッチアップするときに優先的に見た方が良いのはここら辺だという推測ができる。
それがあることで開発が楽になるか
開発チーム内部での認識を合わせる手段としてのドキュメントにおいて、「それがあることで開発が楽になるか」というのも重要な観点だ。
楽になるという言葉には以下の２つのポイントがある。
・その機能の開発担当者の認識を整理する役に立つか
・開発方針のレビューをしてもらいやすくなるか
この点に関しては以下の記事で詳しく解説したので、ぜひ読んでほしい。
アジャイル開発に必要な２つの設計書と２つの例外
アジャイル開発で不要なドキュメント
開発チーム内の認識を揃えるためのドキュメントは必ず必要というわけではない。とくに、そのドキュメントがあることで開発が楽になるわけではないのであれば作る必要がない。
このパターンに当てはまる具体例としては以下のような場合が存在する。
例えば詳細設計書が挙げられる。詳細設計の中にはクラスの一覧やロジックの詳細を書くことがあると思う。例えば以下のような内容だ。
これはソースコードを読めばわかる内容であり、記載の粒度も細かいため頻繁に変更が入る可能性があるのでメンテナンスコストが極端に高くなる可能性が高いのでドキュメント化しない方が良い。
アジャイル開発で必要になるドキュメント
この章では、アジャイル開発で必要になるドキュメントについて紹介する。具体的には以下の３種類だ。
・ユーザーストーリー
・要件定義書
・システムの設計書
それぞれ見ていこう。
ユーザーストーリー
「何を作るか」を記したものだ。このストーリーのリストを見れば、このサービスが何を実現したいのかがざっくりとわかるはずである。
例えば、以下のようなものがユーザーストーリーだ。これは八百屋のサイトのユーザーストーリーである。これを見れば、プロジェクトチームが認識している「このシステムではこれが実現できるべき」という内容がわかる。
要件定義書
要件定義書も必要だ。
ユーザーストーリーの内容を実際にシステムに落とし込むためにはより詳細な内容を詰める必要がある。その内容を詰めるために使うのが要件定義書だ。
これには特に決まったフォーマットはないし、何を書くべきかも決まっていない。そのため、必要に応じた詳細さで記載する必要がある。
例えば、以下の画像はプロフィール作成サービスを開発していた時の要件定義書の一例だ。ここでは、案件の背景、課題、その対応方法案についてまとめて、対応方法をクライアントと意思決定するために活用した。
システムの設計書
システムの設計書についてはこちらの記事で解説している。ぜひこちらも参照して欲しい。
まとめ
アジャイル開発のドキュメントについて解説してきた。
アジャイル開発でも、ウォーターフォールと一緒でドキュメントが必要であることは変わらない。ただし、そのドキュメントの目的が変わる。
つまり、ウォーターフォールではドキュメントも納品物であるために作成自体が目的にもなるが、アジャイルにおいては開発プロジェクトを進める上で必要があればドキュメント作成をするという方針になる。
開発プロジェクトのそれぞれのゴールに応じて、ドキュメント作成をするかしないか適宜考えて進めていけるような開発チームが増えてくれたら幸いだ。
