2013年11月4日
弊社はベトナムを拠点としたオフショア開発を行っていますが、その中で様々な仕様書を元にアプリを開発して参りました。今回はこれまで見てきた仕様書の中で、品質のよいアプリの開発が行える仕様書とは一体どのような仕様書なのかを紹介していきたいと思います。
1) 文章ではなく表やフローチャートで
アプリの動きを文章で記述した場合、一見きれいに書かれていたとしても、そこにアプリ開発に必要な事項が網羅されているかというと、必ずしもそうとは言い切れません。例えば次のような記述があったとします。
ユーザー情報を登録する場合、氏名、住所年齢および連絡先を登録する事。
この記述だけではアプリ開発のために必要な情報が十分書かれているとは言えません。どの項目が必須なのか、何文字入力できるのか、、、
そこで、例えば表を使って記述すれば各項目がどのような視点で書かれているかが一目瞭然に分かります。
2) 何度も読む必要のある説明を中心に書く
例えば、あるチャットシステムを開発するための仕様書がある場合、
本システムは社内のコミュニケーションを促進するために、、、
といったような、システムの目的や背景について説明した記述が多く、具体的なアプリの動作仕様に関する記述が十分でない仕様書を見かける事があります。システムの目的や背景など、一度説明すれば良い内容は、仕様書に書くより、直接口答で説明した方が効果的です。
本来の仕様書の役割に即して考えた場合に記述として重要なのは、例えば画面コンポーネント一覧やエラーリスト一覧など、何度も確認が必要な内容です。
このようなアプリの動作に係る記述は、設計、開発、テスト、そしてユーザー検収など、様々なフェーズで何度も確認されるべき内容です。
3) 主語はだれか
例えば、ユーザーがある機能について権限の付与をシステム管理者に依頼する場合の処理フローを考えます。
1. ユーザーが権限付与の申請をシステム管理者に対して行う
2. システム管理者がユーザーに対して権限を付与する
3. 該当機能を実行し、権限が付与された事を確認する
このような場合、3. で権限付与の結果を確認するのは誰でしょうか。文脈から判断すればユーザーかもしれません。しかし、今回のシステムではシステム管理者かもしれません。そこには仕様が曖昧になるリスクが潜んでいるわけです。主語を必ずつけていくことでこのようなリスクを減らすことができます。
4) 動きを明記する
静的な画面表示の説明ばかりで、画面間の移動や各ボタンの動きに説明が十分でない仕様書を見かける事があります。
「依頼した内容と違った！」というクレームが、オフショア開発で最も多いクライアントのクレームです。
経験上、そのクレームの大半は、画面遷移や動きに関する問題です。
「取り消し」、「キャンセル」、「確定」など、「ボタンの文言で何をやっているかわかるだろう」と仕様書を書く人が思いがちで、説明が足りないことが多いです。
例えば、何かの登録フォームの「キャンセル」ボタンを押した後に、編集内容を廃棄するまでは良いが、キャンセルした後に、画面に何が表示され、その後にどこの画面に移動できるかは、日本人の感覚と海外エンジニアの感覚が違うことが多いです。
5. 仕様漏れを起こさないための工夫
仕様書の内容で一番気をつけたいのが仕様漏れです。例えば、ログインで何文字必要か、という内容が記述されていなかった場合、開発者はその点について質問してきます。しかし、記述の観点として全く書かれていない場合、開発者はその点について質問することはないでしょう。
仕様書には画面項目に限らず、状態遷移や性能、権限など開発に必要なあらゆる観点で表にまとめるなどの記述が必要です。最初にメモとして観点を書き出してから内容を詳細に記述すると仕様漏れ防止に役立ちます。