下記の記事(システムの全体像に関する説明)にて、システムの全体像について説明した。本節では、システムの全体像における、要件定義のスコープ、設計スコープについて説明する。また、2つのスコープを重ね合わせ、両者のスコープ間の関係性についても説明する。
システムにおける要件定義スコープ
システムの全体像における、要件定義のスコープを図示する。下図において、赤色で塗られている箇所が、いわゆる要件定義書として記載される部分となる。要件とは、「システムにできてほしいこと」である。
「なぜこの機能を実現してほしいのか？具体的にできてほしいことは何なのか？」が要件定義書に記載される。となると、要件定義書には、「顧客が認識している問題は何か？解決すべき課題は何か？課題を解決するために、どんな機能があるのか？システムの使い手は誰で、どのように機能を使うのか？」が記載されねばならない。
その中でも、最低限記載されなければならない部分は、「どんな機能があるのか？」「システムの使い手は誰で、どのように機能を使うのか？」である。これだけは最低限定義しないと、システムの実現は不可能である。どんな機能が必要なのか提示しないと、議論は前に進まない。誰がどのようにシステムを使うのかも想定できなければ、必要なユーザーインターフェースも検討できない。「誰が、どのようにシステムを使うのか」がわかるように、要件定義書を書くべきだ。
欲を言えば、「何のために」使うのかも明示されているとよい。「何のために」は、記載されていなくても、システムを作ることは可能だ。しかしながら、「何のために」を理解することで、システムの機能を追加するときや、システムの機能を削除するときに、本当に機能追加してよいのか？削除してよいのか？を判断しやすくなる。よくある事例が、ある担当がシステム開発の担当をしており、後任者があまり内容を理解せずに機能を追加してしまい、仕様バグが発生してしまう事例だ。
機能実現の裏にある背景を理解しておかねば、最適な機能追加や機能削減はできない。要件定義書を書くときは、背景も書いておくと、システムの継続的改善が容易になるため、ぜひとも記載しておきたい。参考として、要件定義書の作り方に関する記事を添付しておく。
注意したいのは、上図において、システムの外側の領域が赤枠で囲まれているからといって、システムのIFすべてを要件定義書で書くわけではないという点だ。要件定義書として、システムの振る舞いに対してある程度の言及はするものの、それらの表現は完全である必要はない。
例えば、リモコンへの要件を定義するとして、「テレビから離れていても、電源ボタンの押下により、テレビの電源をつけたり消したりできること。電源ボタンの位置は、全面の左上とする」が要件の一部として記載されていたとする。この例で言うと、電源ボタンの押下が入力であり、リモコン全面の左上に電源ボタンを配置することを要求されていることがわかる。しかしながら、搭載位置の詳細については言及されていない。リモコンの寸法がどのくらいで、ボタンの大きさや見た目はどのような形で、左上のどのあたりに配置されるのかといった、詳細な要件については言及されていない。
システムを具体化するためには、要件(要求)をさらに具体化する必要があるが、それらのさらなる具体化は、設計フェーズで行うこととなる。なぜならば、要件定義で大事なことは、課題の解決なのだから。
ポイント：課題を解決するために、要件を定義しよう
システムにおける設計スコープ
次に、システムにおける設計スコープを図示する。下図において、青色で塗られている箇所が、いわゆる設計書として記載される部分である。要件がはっきりしていたとしても、それをどのように実現するかに関しては、色々な実現手段がある。その中で最適な実現手段を選択し、明確化していくことが設計作業である。ポイントは、設計で重要な点は、システムのことに関して網羅的に記載をすることである。逆に、システムが関わらない領域のことに関して書く必要はない。設計で大事なことは、システムとして、何を、どう作りこむかを記載すべきであって、なぜシステムを作るのかに関しては、書く必要はない。
リモコンの例で言うと、「テレビから離れていても、電源ボタンの押下により、テレビの電源をつけたり消したりできること。」という要件を満足し、システムとして実現するために必要なことが、設計書として記載される。具体的なリモコンの形状、リモコン上に搭載される電源ボタンの形状、電源ボタン押下時の処理、テレビに送信される信号、などなど、あらゆる設計情報が、設計書として記載される。
このとき、重要なことは、この設計書はどの要件を満足するためのものか？がわかるようにすることだ。設計書に記載すべき情報は「どのようにシステムを実現するか」の情報だが、「何を」の情報が合わせて記載されていないと、何の機能を実現するための設計書なのかわからなくなる。
この情報は、いわゆる「上位文書」として記載される。どの要件を満足するための設計なのか、わかるようにしておこう。そうすることによって、この設計は何のための設計なのかが、資料をたどることでわかるようになる。要件定義書には、「何のために、何を」が記載されている。設計書には、「何を、どのように」が記載されている。設計書側から上位資料としての要件定義書を参照することで、設計者は、「何のために、何を、どのように」を理解することができるようになるのだ。
開発の規模が複雑になればなるほど、要件と設計の関係性を可視化して管理することが大事となってくる。システムというものは、オーダーメイド品であり、この世に一つしかない。一方で、システムを作る人たちは、大勢存在する。何のためにシステムをつくるのか？という、進むべき方向性を共有することが、システムの品質を高めるために大切な行為だ。システムを作る人たちの認識をしっかり合わせこむために、「何のために、何を、どのように」が誰でもわかるようにトレーサビリティを管理することが、大変重要である。
システムにおける要件定義スコープと設計スコープの重なり
要件定義のスコープと設計のスコープを重ねてみよう。そうすると、システムの外側が重なっていることに気づくであろう。この部分は、いわゆる「のりしろ」の部分となり、必ず存在することとなる。このとき、設計側で重なりの部分に関する記載を省きたい誘惑がでてくるかもしれないが、その誘惑に負けてはならない。設計側の責務は、システムに関するすべての振る舞いを定義することであるため、記載の量を減らすことはできない。
のりしろを減らそうとすると、要件定義側で、システムの振る舞いに関する記載量を減らすこととなる。ただし、このようなことを行えば、要件が簡素化されてしまうので、要件定義側と設計側で認識の齟齬が発生してしまう可能性がある。何らかの情報の入力に関して言及しようとする場合、「電源ボタンを押下して、テレビの電源をつける」という要件があったとしよう。設計側でも、「電源ボタンを押下して、テレビの電源をつける」という表現はなされる。ただし、設計側では、もう少し具体的な表現となる。要件を定義する側でも、システムを設計する側でも、「電源ボタンを押下して、テレビの電源をつける」という記載はなされるべきだ。このような記載の重複は「のりしろ」となるが、筆者は必要だと考えている。世間では、記載の重複は忌避される傾向があるが、記載が重複しても認識齟齬を排除できるならば、積極的にのりしろを活用していくべきだ。例え記載が重複したとしても、システムのイメージを具体化させるためには、必要な情報なのだ。
のりしろの記載を積極的に肯定していこうとした場合、必ず実施しなければならないことがある。それが、変化点管理と、トレーサビリティ管理である。のりしろが存在するということは、設計書側から見て、上位である要件定義書のバージョンを指定して、その中に記載されている内容を一部転記することとなる。そのため、要件定義書が改訂される場合は、その改訂内容を必ず確認し、設計書の変更が必要な場合は、設計書の内容を変更しなければならない。また、要件定義書を書く側も、要件定義書を改版する場合は、その要件定義書を参照している設計書担当に、必ず連絡をしなければならない。
これらの活動を適切に行っていくためには、ドキュメント全体のトレーサビリティ管理と、ドキュメントの変化点影響範囲の確認が必要である。システム開発というと、コンピュータを駆使して、プログラムを書いていく作業のように思われがちだが、実際は違う。認識合わせのためのドキュメントを、丁寧に、確実に管理をしていくことなのである。
これらの作業は、地味かもしれないが、必ず実施しなければならない作業だ。このような作業がきちんと行われていない場合は、システム開発は炎上する。「しょうがない」という言葉は、「仕様がない」という言葉だ。「仕様がない、ちゃんと管理されていない」状況を、「しょうがない」と嘆くことにならないよう、「しようがある」状態を保ち続ける努力をしていくべきである。たびたび述べていることであるが、要件定義する側と、設計をする側が、認識をぴったりと合わせることができれば、変なシステムができあがることは少ない。しっかりと、お互いで認識合わせを行っていこう。
ポイント：要件定義書と設計書の記載は重複してよい。ただし、適切に変更を管理していこう
