アジャイル開発ではドキュメントは必要ない??

突然ですが一つ質問させてください。

あなたが担当しているプロジェクトにはドキュメントはありますか?

私が今まで参画してきたプロジェクトの中にはドキュメントがなく、あるのはソースコードやタスク管理表といったものだけのプロジェクトがありました。詳しく聞いてみると「コミュニケーションを主体としている」「ドキュメントを作る時間がない」「ソースコードを読みながらわからないことがあったら聞いてほしい」などのことでした。

アジャイルソフトウェア開発宣言では以下ように記載されております。

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

アジャイルソフトウェア開発宣言より抜粋

アジャイル開発ではドキュメントやプロセスではなく個人との対話や動くソフトウェアに重点が置かれており、それもあってかドキュメントを用意しないプロジェクトがちらほら見られます。

ではアジャイル開発ではドキュメントは必要ないのでしょうか?それについて私の考えをシェアしたいと思います。

ドキュメントがないソフトウェア開発の末路

私はドキュメントがなかったために悲惨な末路をたどったプロジェクトを二つ知っています。

1つは歴史があり規模も大きな企業での話。そのソフトウェアは多くの大企業で使われており、ビジネス価値は非常に高く売り上げも上々でした。しかし開発現場では多くの不具合の撲滅に追われ、新機能を開発、更には不具合を修正するたびに新たな不具合が発生するといった状態が日常化していました。開発者は皆自分たちのコードがデグレを起こさないかビクビクし、例えるならまるでジェンガだった。

このような現状を生み出した背景に有効な仕様書がないことが挙げられます。ソフトウェアが最初に開発されたのは今から随分昔で、当時はオフショア開発をしていたそうです。途中から自社開発に切り替えることになったが、当時あった仕様書が中国語で書かれており読むことができず、それ以降仕様書というものを作らなくなったとのこと。
更には当時現場で活躍していたエンジニアたちもほとんど退職してしまい、もはやソフトウェアの仕様を正確に把握している人はほとんどいません。言ってしまえば今もまだ残っている古参のエンジニアたちが「生ける仕様書」だったのです。

もう1つはスクラッチ開発をベンダーに依頼したスタートアップ企業での話。そこではちょっとしたニュースサービスの開発を企画していました。役員たちで打ち合わせを行いやプロダクトの構想やプロトタイプを作成し、それをもとに追加で必要な機能を検討、そして国内ベンダーにスクラッチ開発を依頼しました。
ところが1週間ほど運用すると、記事が自動投稿されていないことに気づきました。本来であれば毎朝午前9時に1000件以上のニュースが投稿されるはずなのだがそれができていなかったのです。
この機能がないと運用するのが実質不可能だったため社長は激怒。急いでベンダーに直接問い合わせることに。すると驚いたことにベンダーからの返答は「そのような話は伺っていない」とのでした。

話を進めていくうちにどうやら社長がCTOに伝えていた要件がベンダーに全く伝わっていないことが発覚。さらに言えば自社のプロダクトにもかかわらずCTOは十分に要件を理解していなかったのです。役員での打ち合わせは全て口頭で行われており、依頼内容をまとめたドキュメントはどこにもありませんでした。また、ベンダーとのやり取りも全て口頭で行われていたようでベンダーも要件定義書を作っていなかったことがわかりました。
こうして膨大な開発費用をかけたにもかかわらず開発したソフトウェアは1週間で使い物にならなくなりました。

あなたはドキュメント作成に賛成?それとも反対?

もう少し一般的な問題について整理していきます。

要求仕様書を例にすると要求仕様書がないことで以下のようなことが起こるでしょう。

  • 時間が経つにつれて多くのビジネス関係者は要求がどんなものだったか思い出せなくなり、認識合わせの時に混乱する
  • リリースが繰り返されるにつれて以前まで実装されていた要求が何だったのかが憶えていられなくなる
  • 要求を憶えていられなくなると、知らぬ間にプロダクトの仕様が変わっていても気づけない
  • 更には担当者の交代が何度も行われ、やがて誰も正確な要求仕様を把握できなくなる
  • 仕様がわからないので何が正しいのかがわからず、品質の担保ができなくなる

仮にソースコードが最新かつ正確なドキュメントだという主張があるとしましょう。しかし少なくとも要求仕様書に対しては通用しません。私が思いつく限り以下のような理由があげられます。

1. プログラムを読めないビジネスマンは仕様を把握することができない

その主張は「プログラマ」に対しては有効かもしれないけれどもソースコードを読まない人からすればただの暗号です。

2. プログラムが必ずしもすべての要件を正確に反映しているとは限らない

プログラマが要件の抜け漏れに気づかずに実装し、さらにはテストも通過してしまったことで本来実装されるべき要件が実装されていないことも十分にあり得ます。どんなに入念にテストを行ったとしてもテストしきれない部分が存在しますし、そもそもテストケースから漏れてしまうこともあります。

一方でドキュメントがあることで発生する問題もあるとは思います。例えば、

  • ドキュメントの作成に時間がとられ、ソフトウェアの開発工数が減ってしまう
  • アジャイル開発では仕様が簡単に変わってしまうことがよくある。さらには管理が煩雑で最新の仕様が反映されていないことだってある。そうすると開発現場は混乱してしまう
  • やがて更新されなくなってドキュメントが意味をなさない

が考えられます。

最適解:Just Enough Documentation(必要十分な文書化)

私はプロジェクトに応じてちょうどいいドキュメントを作るのがベストな方法だと思っています。これをを私は「Just Enough Documentation(必要十分な文書化)」と呼んでいます。必要十分な文書化によって作られたドキュメントは簡潔で従来のドキュメントと比較して管理が容易である特徴があります。

アジャイル型プロジェクトにおけるドキュメンテーションについて、ソフトウェア要求第三版ではこのように記載されています。

アジャイル型プロジェクトにおける顧客と開発者との緊密な協力は、一般的に、要求を従来のプロジェクトほど詳細に記述する必要がないことを意味している。その代わりに、ビジネスアナリストなどの要求に責任を持つ人が、必要に応じて、会話と文書により必要な精度を確保する(IIBA2013)。

アジャイル型プロジェクトチームは、要求を書かないことになっていると思われることがあるが、それは正しくない。アジャイル型の手法では、開発者とテスト担当者を正しく導くのに必要な範囲で最小限の文書化を行うことを奨励している。開発者とテストチームが必要とする(または法規制や標準を満たす必要がある)範囲を超える文書化は、工数の無駄遣いである。

カールウィーガーズ;ジョイビーティ著 ソフトウェア要求 第3版 第20章「アジャイル型プロジェクト」より抜粋.

つまりドキュメントはありすぎてもダメですがなさ過ぎてもダメなのです。もちろんその程度はプロジェクトによって変わってきます。銀行系のシステムや医療系のソフトウェアなら少しの失敗が大惨事を生むことになるのでドキュメントは多いほうがいいでしょう(そもそもアジャイル開発でするべきか検討するべきです)。逆に市場のニーズやフィードバックを反映させることで価値を高めていくようなWebサービスであれば作りこんだドキュメントは逆に大きな足枷となります。

ここで私が必要十分なドキュメントを作成するにあたりお勧めするドキュメント群を紹介します。

1. ユーザーストーリー一覧

ユーザーストーリーはユーザーがどういったことを実現したいのかを簡潔にまとめたものです。ユーザーストーリーは例えば以下のように表現されます。

【経理担当者(ユーザーグループ名)】は
【毎月どの程度収支が変化しているのかをすぐに把握する(目的や理由、それを必要とする根拠)】ために
【収支の推移がグラフ化されたレポート(実現したいこと)】を求めている

ユーザーストーリーによってユーザーがどのようなことを求めているのかが把握できます。ユーザーストーリーだけでは具体的な開発まで落とし込むことができませんが、そこからコミュニケーションを続けていくことでユーザーもより深く自分が何を必要としているのかがわかるようになります。

スクラムやXPの手法を採用する際によく使われます。

2. ユースケース一覧

ユースケースはユーザーがどのように使用するかを想定したものです。例えば会計管理ソフトの場合「収入を新規登録する」「支出を新規登録する」「銀行口座を変更する」「支払い履歴一覧を開く」といったものが考えられます。

ユーザーの行動をベースに考えることができるため実装のイメージもしやすく、抜け漏れている関連した要求も見つけやすくなります。

3. フィーチャーツリー

フィーチャーツリーはソフトウェアに必要な機能をツリーで表現したものです。ソフトウェアの核となる機能やそれに付随する機能を表現することができます。機能一覧のように機能に関して詳細まで記載はされませんが、ソフトウェアの全体像や各機能の関係性が簡潔に記されているので簡単に把握することができます。

継続的な管理ができるドキュメントを目指そう

どんな開発でもドキュメントは重要ですが、従来の方法ではドキュメントのボリュームが大きくなりすぎて管理ができなくなってしまったことが課題だったのではないかと思います。そしてアジャイル開発によってドキュメントよりもコミュニケーションが重要視されるようになったことでドキュメントは必要ないといった勘違いが生まれたのではないでしょうか?

アジャイル開発であれウォータフォール開発であれ大事なのは継続的な管理ができるドキュメンテーションです。今一度あなたが関わっているプロジェクトに関するドキュメントを見直してみましょう。

まずドキュメントはありますか?ある場合はどういったドキュメントがありますか?なければなぜドキュメントがないのか考えてみましょう。

ドキュメントはきちんと更新されていますか?更新されていないとしたらそのドキュメントの情報は必要十分量ですか?

そのドキュメントを見ればどの程度ソフトウェアでやっていることが理解できますか?ほとんどできなければそれは必要十分量ではありません。ユースケースやユーザーシナリオを整理してみましょう。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA