開発ドキュメントはどのように書くべきなのか？

2月の特集「楽々デブドックを書こう！」では、システム開発の現場で用いられている各種開発ドキュメントについて、さまざまな視点から考察している。この特集を読んでいる読者の方々なら「開発ドキュメントを書く」ことの必要性については、改めて語るまでもなく知識的・体験的に理解しているだろう。

しかし、いざ実際の現場において開発ドキュメントをどのように書くのか、という部分についてはいかがだろうか。実際にシステム開発や運用に携わっている方々に話を聞くと、「何を書けばよいかわからない」「現場では、書いている暇がない」「たとえ書いたとしても活用されることが少なく、その存在意義がわからない」など、問題点も感じているようだ。

特に問題の1つとして取り上げられるのは、「開発ドキュメントを書いたのはよいのだが、そこに含まれる情報が開発メンバーの間で正しく共有できていないように感じる」という状況だ。これにはいくつかの問題があると考えられるが、その中でも大きなものは、開発ドキュメントにかかれた仕様がわかり難く、それ故に「開発ドキュメント」という紙はともかく、必要な情報そのものは共有されない傾向にある、ということだ。

開発ドキュメントには、顧客の要求を知る、要件を定義する、仕様を決定する、といったさまざまなフェーズがあり、その各フェーズにおいて「どのようなドキュメントの作成が必要か」といった方法論が研究されている。

例えば「システム作りのもやっと感を解消する『MOYA』」で紹介しているMOYAは、顧客の要求を正しく吸い上げるための方法論の1つである。

発注者ビュー検討会とはなにか

開発の現場において、大きなリスクとなり得るのは「開発の手戻り」である。特に、顧客の要求を正しく理解できず「相互理解が取れない＝顧客の求めるものとは違うもの」をいかに開発したとしても、それは顧客にとって満足のいくシステムとはならず、開発のやり直しを余儀なくされてしまう。

また、もしやり直しが発生しなかったとしても、顧客は不満を抱えたままでそのシステムを使い続けるか、開発後にさらなる機能追加や機能変更が起こるといった状況が発生する。これは顧客にとっても開発者にとっても、決して喜ばしいことではないはずだ。

そこで表1にあげたIT業界の主要各社が設立したのが「発注者ビュー検討会」である。発注者ビュー検討会では、システム開発をはじめるにあたって策定する「仕様」について、顧客に対してわかりやすく提示し、相互理解できるドキュメント作りを目的としている。この発注者ビュー検討会の発足についてはITニュースなどでも紹介されており、システム開発に携わるSIerの方々ならば、特に注目していることだろう。

しかしそこで行われてる活動内容とその成果物は、実際の開発現場に携わる人々にとって「本当に使える」ものなのだろうか。本連載「ほんとに使う？ガイドライン」では、システム開発の現場で働くプログラマ、そしてプロジェクトマネージャの方々に忌憚のない意見をいただき、その内情に迫っていく。 次のページ