一つ質問させてください。あなたが担当しているプロジェクトにはドキュメントはありますか?私が今まで参画してきたプロジェクトの中にはドキュメントがなく、あるのはソースコードやタスク管理表といったものだけのプロジェクトがありました。詳しく聞いてみると「コミュニケーションを主体としている」「ドキュメントを作る時間がない」「ソースコードを読みながらわからないことがあったら聞いてほしい」などのことでした。アジャイルソフトウェア開発宣言では以下ように記載されております。私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。アジャイルソフトウェア開発宣言より抜粋アジャイル開発ではドキュメントやプロセスではなく個人との対話や動くソフトウェアに重点が置かれており、それもあってかドキュメントを用意しないプロジェクトがちらほら見られます。アジャイル開発ではドキュメントは必要ないのでしょうか?それについて私の考えをシェアしたいと思います。私はドキュメントがなかったために悲惨な末路をたどったプロジェクトを二つ知っています。1つは歴史があり規模も大きな企業での話。そのソフトウェアは多くの大企業で使われており、ビジネス価値は非常に高く売り上げも上々でした。開発現場では多くの不具合の撲滅に追われ、新機能を開発、更には不具合を修正するたびに新たな不具合が発生するといった状態が日常化していました。開発者は皆自分たちのコードがデグレを起こさないかビクビクし、例えるならまるでジェンガのよう。このような現状を生み出した背景に有効な仕様書がないことが挙げられます。ソフトウェアが最初に開発されたのは今から随分昔で、当時はオフショア開発をしていたそうです。途中から自社開発に切り替えることになったが、当時あった仕様書が中国語で書かれており読むことができず、それ以降仕様書というものを作らなくなったとのこと。当時現場で活躍していたエンジニアたちもほとんど退職してしまい、もはやソフトウェアの仕様を正確に把握している人はほとんどいません。言ってしまえば今もまだ残っている古参のエンジニアたちが「生ける仕様書」だったのです。1つはスクラッチ開発をベンダーに依頼したスタートアップ企業での話。そこではちょっとしたニュースサービスの開発を企画していました。役員たちで打ち合わせを行いやプロダクトの構想やプロトタイプを作成し、それをもとに追加で必要な機能を検討、そして国内ベンダーにスクラッチ開発を依頼しました。ところが1週間ほど運用すると、記事が自動投稿されていないことに気づきました。本来であれば毎朝午前9時に1000件以上のニュースが投稿されるはずなのだがそれができていなかったのです。この機能がないと運用するのが実質不可能だったため社長は激怒。急いでベンダーに直接問い合わせることに。すると驚いたことにベンダーからの返答は「そのような話は伺っていない」とのでした。話を進めていくうちにどうやら社長がCTOに伝えていた要件がベンダーに全く伝わっていないことが発覚。言えば自社のプロダクトにもかかわらずCTOは十分に要件を理解していなかったのです。役員での打ち合わせは全て口頭で行われており、依頼内容をまとめたドキュメントはどこにもありませんでした。ベンダーとのやり取りも全て口頭で行われていたようでベンダーも要件定義書を作っていなかったことがわかりました。して膨大な開発費用をかけたにもかかわらず開発したソフトウェアは1週間で使い物にならなくなりました。ドキュメントつくるべき?なくすべき?もう少し一般的な問題について整理していきます。要求仕様書を例にすると要求仕様書がないことで以下のようなことが起こるでしょう。時間が経つにつれて多くのビジネス関係者は要求がどんなものだったか思い出せなくなり、認識合わせの時に混乱するリリースが繰り返されるにつれて以前まで実装されていた要求が何だったのかが憶えていられなくなる要求を憶えていられなくなると、知らぬ間にプロダクトの仕様が変わっていても気づけない更には担当者の交代が何度も行われ、やがて誰も正確な要求仕様を把握できなくなる仕様がわからないので何が正しいのかがわからず、品質の担保ができなくなる仮にソースコードが最新かつ正確なドキュメントだという主張があるとしましょう。少なくとも要求仕様書に対しては通用しません。私が思いつく限り以下のような理由があげられます。プログラムを読めないビジネスマンは仕様を把握することができないその主張は「プログラマ」に対しては有効かもしれないけれどもソースコードを読まない人からすればただの暗号です。プログラムが必ずしもすべての要件を正確に反映しているとは限らないプログラマが要件の抜け漏れに気づかずに実装し、さらにはテストも通過してしまったことで本来実装されるべき要件が実装されていないことも十分にあり得ます。どんなに入念にテストを行ったとしてもテストしきれない部分が存在しますし、そもそもテストケースから漏れてしまうこともあります。一方でドキュメントがあることで発生する問題もあるとは思います。ドキュメントの作成に時間がとられ、ソフトウェアの開発工数が減ってしまうアジャイル開発では仕様が簡単に変わってしまうことがよくある。管理が煩雑で最新の仕様が反映されていないことだってある。すると開発現場は混乱してしまうやがて更新されなくなってドキュメントが意味をなさないが考えられます。Documentation(必要十分な文書化)私はプロジェクトに応じてちょうどいいドキュメントを作るのがベストな方法だと思っています。Documentation(必要十分な文書化)」と呼んでいます。必要十分な文書化によって作られたドキュメントは簡潔で従来のドキュメントと比較して管理が容易である特徴があります。アジャイル型プロジェクトにおけるドキュメンテーションについて、ソフトウェア要求第三版ではこのように記載されています。アジャイル型プロジェクトにおける顧客と開発者との緊密な協力は、一般的に、要求を従来のプロジェクトほど詳細に記述する必要がないことを意味している。その代わりに、ビジネスアナリストなどの要求に責任を持つ人が、必要に応じて、会話と文書により必要な精度を確保する(IIBA2013)。アジャイル型プロジェクトチームは、要求を書かないことになっていると思われることがあるが、それは正しくない。アジャイル型の手法では、開発者とテスト担当者を正しく導くのに必要な範囲で最小限の文書化を行うことを奨励している。開発者とテストチームが必要とする(または法規制や標準を満たす必要がある)範囲を超える文書化は、工数の無駄遣いである。第20章「アジャイル型プロジェクト」より抜粋.つまりドキュメントはありすぎてもダメですがなさ過ぎてもダメなのです。その程度はプロジェクトによって変わってきます。銀行系のシステムや医療系のソフトウェアなら少しの失敗が大惨事を生むことになるのでドキュメントは多いほうがいいでしょう(そもそもアジャイル開発でするべきか検討するべきです)。逆に市場のニーズやフィードバックを反映させることで価値を高めていくようなWebサービスであれば作りこんだドキュメントは逆に大きな足枷となります。ここで私が必要十分なドキュメントを作成するにあたりお勧めするドキュメント群を紹介します。ユーザーストーリー一覧ユーザーストーリーはユーザーがどういったことを実現したいのかを簡潔にまとめたものです。ユーザーストーリーは例えば以下のように表現されます。【経理担当者(ユーザーグループ名)】は【毎月どの程度収支が変化しているのかをすぐに把握する(目的や理由、それを必要とする根拠)】ために【収支の推移がグラフ化されたレポート(実現したいこと)】を求めているユーザーストーリーによってユーザーがどのようなことを求めているのかが把握できます。ユーザーストーリーだけでは具体的な開発まで落とし込むことができませんが、そこからコミュニケーションを続けていくことでユーザーもより深く自分が何を必要としているのかがわかるようになります。スクラムやXPの手法を採用する際によく使われます。ユースケース一覧ユースケースはユーザーがどのように使用するかを想定したものです。会計管理ソフトの場合「収入を新規登録する」「支出を新規登録する」「銀行口座を変更する」「支払い履歴一覧を開く」といったものが考えられます。ユーザーの行動をベースに考えることができるため実装のイメージもしやすく、抜け漏れている関連した要求も見つけやすくなります。フィーチャーツリーフィーチャーツリーはソフトウェアに必要な機能をツリーで表現したものです。ソフトウェアの核となる機能やそれに付随する機能を表現することができます。機能一覧のように機能に関して詳細まで記載はされませんが、ソフトウェアの全体像や各機能の関係性が簡潔に記されているので簡単に把握することができます。継続的な管理ができるドキュメントを目指そうどんな開発でもドキュメントは重要ですが、従来の方法ではドキュメントのボリュームが大きくなりすぎて管理ができなくなってしまったことが課題だったのではないかと思います。アジャイル開発によってドキュメントよりもコミュニケーションが重要視されるようになったことでドキュメントは必要ないといった勘違いが生まれたのではないでしょうか?アジャイル開発であれウォータフォール開発であれ大事なのは継続的な管理ができるドキュメンテーションです。今一度あなたが関わっているプロジェクトに関するドキュメントを見直してみましょう。ドキュメントはありますか?ある場合はどういったドキュメントがありますか?なければなぜドキュメントがないのか考えてみましょう。ドキュメントはきちんと更新されていますか?更新されていないとしたらそのドキュメントの情報は必要十分量ですか?そのドキュメントを見ればどの程度ソフトウェアでやっていることが理解できますか?ほとんどできなければそれは必要十分量ではありません。ユースケースやユーザーシナリオを整理してみましょう。涼フリーランスのエンジニア兼ITコンサルタント。新卒時代はプログラミング未経験からベンチャー企業にて修行をしつつプロジェクトリーダーとして活躍。その後スタートアップ企業で新サービスの企画からソフトウェア開発に携わる。コメントをキャンセルメールアドレスが公開されることはありません。※サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。上に表示された文字を入力してください。検索:検索ある日突然上流工程を任されたあなたへこのサイトでは実際の筆者の経験や信頼性の高い情報を交えて何故ソフトウェア開発が失敗するのか、どうすれば改善することができるのかを考察しています。中には筆者が実践している方法も取り上げておりますが、それによって如何なる損失が発生したとしても責任は負いませんので予めご了承ください。