2013年06月02日

ユーザーに優しい設計書を書く方法

只今、「大規模プロジェクトをまとめる方法」に続くレポート第2弾を作成してます。
今回のテーマは「ユーザーに優しい設計書を書く方法」です。多分タイトルだけではあまりピンとこないと思いますので、ざっと概要をご説明しますと、顧客(エンドユーザー)からシステム開発を依頼されてまず行うのは要件定義ですが、要件的は顧客の要望を聞くのが目的ですので、基本的に顧客⇒開発者の一方通行の資料になります。
そのあとに、外部設計(基本設計とも言う)を行うのですが、外部設計では要件定義をもとに、システム化する際に必要な機能、条件、制限事項等をまとめて顧客に定義して、顧客からそのフィートバックを受けてさらに修正していくという顧客と開発者が双方向でやり取りする資料になります。
今回のレポートのテーマにしている「ユーザーに優しい設計書を書く方法」では、この外部設計に重点を置いて書いています。
自分は、仕事で他人が書いた設計書を数多く見てきていますが、設計書というものはシステム開発をやっているプロが見ても基本的に分かりにくいものです。完全に理解するには2度3度と読み返して、大量の参照資料をあちこち見て回る必要があります。
これを顧客に渡して本当に理解できるのでしょうか?

答えは考えるまでもなく"NO"です。

設計書は分かりにくいものなのだから、顧客に理解してもらえなくてもいいと思っているかもしれませんが、それは間違いです。
ユーザーに優しい設計書を書くことで、より多くのフィードバックを受けることができて、誤解や間違いを減らし、顧客から高い満足度を得ることができます。
また、顧客に仕様を理解してもらうことで、システムの都合上どうしても発生しまう制限事項などもスムーズに了承してもらえるようになります。

自分は、このユーザーに優しい設計書を書くことをあまり意識していなかったために痛い目に合った経験があります。
それは、長い期間をかけて開発をしてきたシステムが、ユーザーテストの段階になって、大量の仕様の不具合を指摘され、結局外部設計からやり直し、顧客に多大な迷惑をかけてしまったということです。
実は、外部設計書は全て顧客とレビューして仕様の確認をしたはずなのですが、顧客に完全には理解してもらえていなくて、外部設計書を作り直して再度確認していくと誤解や間違いだらけででした。

その経験を踏まえ、ユーザーに優しい設計書を書く事の重要性と、どのように設計書を書けばユーザーに誤解なく理解してもらえるかを学びました。
早くレポートを仕上げてまずは自社向けに公開したいのですが、深夜まで残業して、休日出勤もしている中、業務時間外にコツコツと作っているのでそろそろ限界を感じています。
みんには、このレポートを役立てて自分のようなドジを踏まないようにしてほしいと願っています。



あと、最近ご無沙汰している「Master Document」ですが、こちらは一向に進んでいません。
設計から開発まで、一貫して管理できる総合パッケージツールとして現在誠意開発中でありますが、やりたいことが盛りだくさんで、なにから手を付けていいやら...
とりあえず今は、コアとなるドキュメント共有ツールを作成しています。このツールを使って各設計書間や、工程間のドキュメントを統合管理して常に最新のデータを参照できるようにします。
設計書は、仕様変更や、不具合などで、常に変化します。その変更を放置しておくとリカバリに多大な工数が必要になってしまいます。
そこで、このドキュメント共有ツールで常に同期をとって、変更をすぐに取り込めるようにするのが狙いです。
「Master Document」は、このような設計の支援ツールと、設計書のテンプレート、ならびに、プログラムの自動生成機能を掛け合わせた統合パッケージとして開発しています。
完成時期は多分5年後ぐらい...です。



とりあえず、ロゴだけは立派なものが出来ています。わーい(嬉しい顔)
posted by j.shiozaki at 19:08| Comment(0) | TrackBack(0) | マスタードキュメント