アジャイル開発のドキュメント管理

Scrum Inc.認定スクラムマスターの局です。

アジャイル開発についてのよくある誤解の一つに「アジャイル開発はドキュメント管理が不要」というものがあります。

「うちの会社はドキュメント作成が必須だからアジャイル開発はできない」と考えてアジャイル開発の採用を諦めてしまったり、「アジャイル開発はドキュメント作成をしない手法だから楽だ」と考えてドキュメントを残さなかった結果、あとで仕様に関して言った・言わないの議論が生じてしまったり、この誤解による影響はさまざまなところで発生します。

アジャイル開発にドキュメント作成は不要なのか？
Face to faceの環境がないアジャイル開発が増加
アジャイル開発でも用意すべきドキュメント
アジャイル開発のご相談はNCDCヘ

アジャイル開発にドキュメント作成は不要なのか？

ウォーターフォールと比べてアジャイルではドキュメントを重視しないのは事実ですが、私の経験から考えると、アジャイル開発でもある程度のドキュメント管理は必要です。
特にお客様からの業務委託で行っているアジャイル開発プロジェクトでは、経緯の振り返りができるようなドキュメントは作成しておかないと、ステークホルダーとの話をまとめることが難しいと感じています。

そもそもアジャイル開発の憲章である「アジャイルソフトウェア開発宣言」を見てみると、決してドキュメント作成を否定しているわけではありません。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。

すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

この部分を見れば「包括的なドキュメントよりも動くソフトウェアに価値を置いている」だけであり、ドキュメント作成の価値も認めていることがわかります。

また、アジャイルソフトウェア開発宣言で「包括的なドキュメントよりも動くソフトウェア」に価値を置いている背景として、アジャイル開発はプロジェクトルームが用意されており、共通のホワイトボードと、常にプロジェクトメンバーが対話できる環境で行うべきであるとの考えあります。
つまり、過去の仕様確認や今後の設計の相談をする際には、ドキュメントに依存せず、近くにいるメンバーに相談すれば判断できるという状況が想定されているのです。

「アジャイル宣言の背後にある原則」にはこのような記述もあります。

アジャイル宣言の背後にある原則（抜粋）

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

Face to faceの環境がないアジャイル開発が増加

ビジネス要求に柔軟に対応し、スピーディに動くものを作り上げるというアジャイル開発の目的を達成するためには、日々一緒に働きフェイス・トゥ・フェイスで話せる環境があるのは理想的です。
しかし昨今、リモートワークやマルチワークという働き方が増えたことや、発注者（プロダクトオーナー）と受託者（開発チーム）が異なる企業に属していて物理的に離れているケースも増えていることなど、さまざまな理由でFace to faceの環境がないアジャイル開発が増加しています。

また、技術の進化が加速しており、開発メンバーの得意な技術や経験が不揃いなチームも多いため、同じ言葉でも人により捉え方が異なるという問題も起きがちです。

このような昨今の状況を考慮すると、コミュニケーションの溝を埋めるためのドキュメントはあって然るべきだといえます。
ウォーターフォールのように、次の工程に進んだら変更はしないという前提で詳細まですべて確定にするドキュメントは作らなくても良いのですが、あとで経緯を振り返るためのドキュメントや、備忘録は必要となります。

アジャイル開発でも用意すべきドキュメント

では、アジャイル開発において、用意すべきドキュメントは何でしょうか？プロジェクトにより違いはありますが、私が担当するプロジェクトでよく作成するドキュメントをご紹介します。

ワイヤーフレーム、UIデザイン（プロトタイプ）

まずは関係者の認識を揃えるため、ワイヤーフレームとUIデザインを作成します。できればUIデザインはプロトタイプができていて画面遷移が確認できるものがお勧めです。NCDCではよくFigmaを用いてこれらのドキュメントを作成しています。
また、お客様からの業務委託の開発プロジェクトの場合、お客様もFigmaに招待し直接コメントを記入して頂くようにして認識のズレがないようにしています。

画面仕様書

画面仕様書は、主にプロダクトオーナー（PO）の要望をデザイナーに伝えたり、UIに紐づく処理内容が適切かどうかをPOに判断してもらったりするために作成しています。
こちらもNCDCではよくFigma上に画面項目とアクションを定義したコメントを残して作成します。
また、プロジェクトによっては画面仕様書を成果物として残すことを求められることもあるので、手間はかかりますが最終的にはFigmaからパワーポイントの資料にまとめ直す、PDF化して残すなどの作業をすることもあります。

API仕様書

フロントエンドとバックエンドを分けて開発をする場合はAPI仕様書が必要になります。
API仕様書では、CRUD（Create（生成）、Read（読み取り）、Update（更新）、Delete（削除））の処理がどの画面でどの項目に対して走るかの認識合わせをします。
機能追加のアップデートが続くようなアプリケーションであれば、このドキュメントを管理して、取得できている項目や追加が必要な項目を定義し、更新していきます。

ER図

ER図の作成は重きを置いているものではありません。DB構成は一度作成してしまったらあまり変更は入らないものですが、それ故に後々振り返るときに当初の担当者が既にプロジェクトから離れていて、誰も設計時のこと覚えていないという問題が起きがちです。長く続くプロジェクトが想定される場合ははじめから作成しておくのがお勧めです。