悩めるシステム発注者に知っておいてほしい5つのこと


ここのところ、システム開発の「発注側」の方から、私の専門分野の一つでもある要件定義プロセスについて、相談を受けることが多くあります。

要件定義プロセスは、システム開発の成否を大きく左右するもっとも重要なプロセスです。このプロセスの品質が、プロジェクトとシステムの品質を決めると言っても言い過ぎではありません。なぜなら、プロジェクトのすべてのプロセスは、この要件定義プロセスで作られた「要件」をもとに行うからです。

プロセスとは、あるインプットを加工してアウトプットを生み出す一連の取り組みです。インプットの質が悪ければ、いくらそのプロセスの手順が優れていても、アウトプットの品質を保証することはできません。そのいちばん最初のインプットが「要件」なのです。

しかし、システム発注者は、要求をどう伝えればいいのかがわかりません。また、開発者がつくった要件定義書をもらったとしても、その品質を判断する基準を持ち合わせていません。開発者や開発会社の言うことを信じるしかないのが実状です。しかし、いくつかのポイントを知っておくことで、要件定義プロセスの質を高め、その後のプロセスをスムーズに進めることができます。

それらのポイントの中でも、とくに重要なものについて5つ挙げておきます。これだけですべてがうまくいくわけではありませんが、わずか5つのポイントでも、押さえておけば効果は必ずでます。

1.要件定義プロセスの「目的」を理解する

要件定義プロセスの品質を高め、意味あるものにするには、まずプロセスの目的を知る必要があります。「要求を伝える」「仕様を決める」などが考えられますが、これだとまだいあいまいです。目的を明確に理解しなければ、プロセスにおける行動があいまいになってしまい、どうなればプロセスが完了したと言えるのかが判断できません。

要件定義プロセスの目的は、大きく2つあります。すなわち、

 1.設計可能な仕様を得ること
 2.要件管理の基準を得ること

の2つです。

ただ単に、発注者側から要求を伝えて、開発側「わかりました」というだけでは、使える仕様にはなりません。「使える仕様」とは、つぎの設計プロセスで、設計が可能なレベルになっているということです。設計が可能ということは、そこに「あいまいさ」がなく、「一意に解釈でき」、異常系の振る舞いや、制約条件などが網羅されているということを指します。つぎの設計プロセスで「この場合はどうするんですか?」という質問が、開発側から出ないレベルになっていなければならないということです。

また、仕様はかならず「ベースライン」を設定しなければなりません。ベースラインとは、「これで設計を開始する」という基準のことです。つまり、要件としてバージョン1.0であるということを合意し、その後の仕様変更や追加は、差分を管理しなければなりません。その差分管理の基となるのがベースラインです。

ベースラインを明確に決めなければ、無秩序な仕様変更や追加を呼び込むことになります。場当たり的な仕様変更は、そのたびに設計やコードに変更が入ることで、品質の低下、手戻りの発生、スケジュールの遅延を招きます。必ず関係者が「この日に合意した」という証拠を残して、「これ以降は変更として扱いますよ」と合意しなければなりません。

要件定義プロセスの目的は、この「設計可能な仕様を得ること」と「要件管理の基準を得ること」の2つです。この2つが満たせていなければ、要件定義プロセスは終わっていないと考えてください。

しかし、いくらベースラインを合意したとしても、要件の品質が悪ければ、変更は頻発します。そのためにも次からのポイントを押さえておいてください。

2.仕様書フォーマットを規定する

要件定義プロセスの成果物は、「要求仕様書」とは「要件定義書」などと呼ばれます。しかし、この成果物のフォーマットが決まっていないことが、少なくありません。

開発側は「わかれば何でもいいです」というかも知れません。しかし、どのような要素が含まれていなければならないかは教えてくれません。それは、何を検討しなければいけないかを、開発側がわかっていないからです。

何を検討すればいいかがわかっていないということは、いつも設計段階で詳細を考えているということにほかなりません。設計プロセスに入ってから「これはどうなんですか?」というやりとりが多発します。発注側も忙しいのですぐに返事ができないでいると「仕様がなかなか決まらない」という開発者の言い訳を助長することになります。

要件定義のフォーマットは必ず決めてください。フォーマットが決まっていないということは、検討すべきことがはっきりしていないということですから、見積もりもできないはずなのです。

3.仕様書には「理由」を明記する

要件を定義のむずかしさは、「モレ」と「ズレ」にあります。「モレ」とは、考慮漏れのことです。「そこは考えていませんでした」ということがあとで必ず起こります。また「ズレ」は解釈の違いです。「そう書いてあります」「そんなつもりじゃなかった」というやりとりを経験した人は多いはずです。要件は「一意に解釈できる」ことが必要ですが、はじめからそのレベルにまで要件を落とし込むことは、簡単ではありません。

多くの場合、発注者側が出す「要求仕様」は、「要求」の記述と、「仕様」の記述が混じったものです。つまり「~がしたい」というあいまいさを含んだものです。これは当然のことです。しかし、「要求」では設計ができません。設計できるようにするには、「仕様」にしなければなりません。そのときに便利なのが、要求の「理由」です。「なぜ、そのようにしたいのか」を伝えることで、仕様化の大きな助けになります。

要件定義のフォーマットには、「要求」と「理由」を明記し、それに続けてその要求を満たす「仕様」を書くようにします。

4.先にテスト仕様書をつくってもらう

先に、要件定義プロセスの目的の一つは、「設計可能な仕様を得ること」だと言いました。では、設計可能であるかどうかは、どのように判断すればいいのか。

設計が可能であるということは、すなわち「テストができる」ということです。これを「検証可能性」とも言います。ということは、テスト項目を先に作ってもらえば、その要件が設計可能なレベルになっているかがわかります。

テスト仕様書は、必ず作ります。作るのであれば、コーディングのあと、テストの直前に作るのではなく、要件定義プロセスの直後に作ってもらえばいいのです。テスト仕様書をつくること自体が、要件の品質を確かめるプロセスを兼ねることができます。また、先にテスト仕様書をつくることで、設計プロセスでは、そのテストを通る設計になっているかどうかも確認することができるようになります。

5.中間成果物は必ず提出してもらう

発注側が要求を伝えたあと、成果物を確認するのは、実際にシステムが出来上がったときだけということも少なくありません。確かに忙しい中で、すべての中間成果物を見ることは難しいかもしれませんし、見てもわからないというのが実状でしょう。

しかし、進捗は確認するはずですので、各プロセスが完了したらなら、それまでの中間成果物は、必ず提出をしてもらうようにしましょう。そのためには、プロジェクト計画時点で、成果物のリストを定義しておく必要があります。

発注者側が中間成果物を確認しなければ、それはプロセスを省く誘惑につながります。スケジュールが圧迫してくると、まずドキュメントの作成が省かれます。ドキュメントを省いたまま進めれば、発注者も開発者も検証のすべを失うことになります。

中間成果物は、後から提出を求めるのではなく、プロセス完了後すぐに出してもらいましょう。「まだ変更が入るので」というかもしれませんが、「現時点のものでかまいません」と言えばいいのです。中間成果物を見れば、そのプロセスがどの程度の品質が行われたのかがわかります。そうすれば、「この先何が起こりそうか」もわかり、是正処置を早めに打つことができます。

コメントを残す

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

CAPTCHA


次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>