アジャイル開発で作成すべきドキュメント

数年前まではただの技術用語としてしか知らなかった『アジャイル開発』ですが、近頃では参画する案件がアジャイル開発であることも珍しくなくなってきています。

それだけ従来のウォーターフォール型に嫌気が差していたり、そのデメリットを認識している人が増えてきたというコトでもありますが、アジャイル開発をモノベースの開発手法と短絡的に捉えるのは危険です。

本記事では、本来ドキュメントを作成しない想定のアジャイル開発において、作成すべきドキュメントの種類とその理由を書いていこうと思います。

アジャイル開発とは

概要は外部リンクで丸投げします。

感覚的に言うと、従来型の様に仕様をガッチリ決めてそれを設計書に起こして～といったプロセスを踏まず、作りたいモノをぼんやりと思い浮かべた状態でコーディングに着手し、実装しながら動かしてみて仕様の詳細を詰めてまたコーディングといったプロセスで進んでいく開発手法です。

コーディングの時点で仕様が完全に決まっているわけではないので、一般的にドキュメントの作成はしません。

詳細仕様を詰めていく段階で修正が入ることが想定されているために、その都度手直しが必要となってしまうドキュメントは工数を食うだけの無駄な時間と考えます。

なので、実装段階で基本設計書から修正が必要になる、みたいなものすごーく面倒な手間が省けます。

アジャイル開発で作成すべきドキュメント

アジャイル開発ではドキュメントを作成しない代わりに、各メンバーがコードを読めることが求められます。

ただし、システム開発は複数人のプロジェクトで遂行されるのがほとんどであり、他人が実装したコードを読む必要が出てくる場合もあります。

コーディング規約が整備・徹底されていればある程度のコードは読めてしまうのですが、仕様を満たすためにどうしても複雑にならざるを得ないこともしばしば。

そんな時に役立つのが、やはりドキュメントなんですね。

作成すべきドキュメント①

一つ目はマトリクス型で表せるドキュメントです。

実装ベースで言うと、条件分岐が発生する箇所の仕様です。

２×２ぐらいのマトリクスであれば恐らく頭の中だけでも描けるのですが、それ以上になってくるとメンバーの共通認識とするには難易度が高くなってしまいます。

特に、基本法則は存在するが例外となる条件がある場合などは要注意です。

作成すべきドキュメント②

二つ目は図にできるドキュメントです。

ER図はもちろんのこと、コーディング仕様を図で示す粒度はどれぐらいが最適かというのは案件によりまちまちになってしまいますが、シーケンス図レベルのドキュメントは作成すべきです。

フローチャートレベルは大人しくコードから読み取りましょう。

アジャイル型の場合、メンバーのスコープがコーディングだけになりがちなので、実際に動かしてみたら一部で宜しくない動きになるというコトもしばしば。

そんな時に処理の流れを俯瞰できる図があると、どの処理が良くないかを判別しやすくなります。

ドキュメントが生きる場面

ここまでコーディングベースで作成すべきドキュメントを挙げたので、「それ本当に必要か？」と思われる方もいらっしゃるかもしれません。

ですが、テストベースで考えてみたらいかがでしょうか？

細かい条件分岐がある場合、そのテストを行うにあたってコードベースでテストケースを作成してしまうと、どうしてもテストケースの漏れや誤ったテストケースが発生する可能性が出てきてしまいます。

シーケンス図に至っても同様です。

最後に

『アジャイル開発』と聞くとどうしても「ドキュメント不要！やったー！」という感覚に陥ってしまいますが、アジャイルでも作成すべきドキュメントというモノは存在します。

一旦プロジェクトが終了しチームが解散した後に、再度同じシステムのプロジェクトが発足した時、コードからすべてを読み取るというのは少々乱暴かなと。

外国ではどのように進めているのか分かりませんが、アジャイル開発の最終段階で仕様書を作成するのが日本のやり方には合っているのかなと思っています。

以上です。

スポンサーリンク