今回は要件定義が果たすべき目的を説明します。要件定義では、関係者間の合意をとりつつ、確定した要件を基に仕様を確定して、設計工程に速やかに移行できるようにしなければなりません。

表記法について

例えば、表記法に UML (Unified Modeling Language)を使用した場合を考えてみましょう。UMLで表現するメリットには、設計·開発に至るまでの一気通貫が可能になることが挙げられます。デメリットとしては、ユーザーとの意思疎通がやや困難であることでしょう。また、使いこなせる技術者が限られる恐れもあります(昨今ではそんな心配は無用かもしれません)。そもそも要件定義は、本来ユーザーの仕事であるとも言われます。

仕様化と設計

 

仕様化とは、要件に基づいて設計可能な状態とすることを示します。上の図のように、「仕様化」と「設計」は本来、別の工程に位置づけられます。本来であれば、「仕様化」は要件定義、「設計」は設計工程の作業です。当然、分けて考えるべきなのですが、実際には両者を断ち切るのは困難です。実際のところ、仕様を検討し設計していく工程は、シームレス(途切れなく)につながっている方が効率的です。ただ、だからといって、「要求そして要件を、暖味にしたまま設計を行え」というのではありません。どこまでの範囲を要求として整理し、要件として宗義していくか、また、どこまでを設計とみなし、場合によっては実装を併行して行うのか、開発プロジェクトごとに解釈し決めていくのがセオリーです。

要件に要求をあわせる

時には、システム要件に、その他の要件を合わせる必要があります。例えばERP導入(企業の持つ様々な資源を統合的に管理・配分し、業務の効率化や経営の全体最適を目指す手法)の場合などがその典型でしょう。システム要件を不可侵の要件として扱い、業務要件やビジネス要件等で要求を満たす必要が生じます。つまり組織変更、人員配置、業務見直し、取引先との折衝等です。こういった場合、間違っても、システム要件以外で解決すべき課題を、システムでなんとかしようとしてはいけません。要求に合わせて何でもシステム要件に含めるようなことは、決してやってはなりません。そんなことをすれば、アドオン開発の山に埋もれることになります。そして、ERPをバージョンアップする都度、多大な費用を投じて再開発する羽目に陥ります。そもそも何のためにERPを導入したのかさえ、わからなくなってしまいます。ここでもトップの覚悟が問われるのです。

要求の「トレーザビリティ」

「トレーザビリティ(追跡可能性)とは、依存関係や因果関係などを明確に説明する性質や状態のことを指します。」「例えば、情報システム開発で要件変更が起こった際、どの機能がどの要件に基づくものかが明確であれば、変更によって影響を受ける機能が特定しやすくなり、その後の作業が楽になります。これはすなわち、「要求とソリューションのトレーサビリティが確保されている状態」ということになります。同様に、ある要求の変更が別の要求へどのような影響を及ぼすか明らかにしておくために、要求間の関係を整理しておくことも重要になります。特にビジネス要求、ステークホルダー要求、ソリューション要求の関係を明確にしておくことで、最終的なソリューションがビジネス要求を網羅できているかを確認できます。」

トレース可能な工程の考え方

工程が進むにつれて、成果物を概要から詳細へと深堀りしていきます。そうすれば、成果物のトレースや整合性チェックが可能となり、後から変更が入った場合にも、前工程の成果物に遡って修正を加えることができます。そして詳細の変更が概要に影響を与える場合に限り、遡る、つまり「前向きな手戻り」を行うことになります。以上を前提としたとき、要件定義で行うべき事項とは何でしょうか。

そして、要件定義のそもそもの目的は何でしょうか。筆者は、「まずは開発対象システムの目的の明確化。それも業務視点で、必要性をきちんと議論。その上で目標を定めるべき」と考えています。場合によっては、詳細の検討は設計·実装フェーズにて行えばよいのです。要件定義で詳細まで詰めてしまうと、手戻りが生じた時に遡るのが困難になるという現実えもあります。もちろん、詳細まで要件定義で明確になるのが理想であることは間違いありません。開発手法がウォーターフォールであろうと、アジャイル型であろうと、基本的に要件定義で行うべき作業は変わりません。それよりも、開発プロジェクトごとに変わることがあるのです。

要件定義の範囲

要求分析·要件定義は「様々な色合い」のアナログの情報を、01のデジタル情報に落とすための方向性を固め示す工程だと言えます。では、どこまでやることが「要件定義」の範囲なのでしょうか。これに対する回答は、前述したとおり「プロジェクトにより異なる」としか言えません。回答になっていないですね。但し、確実に言えることがあります。「その時点で必要とされる工数の規模感が把握可能であり、見積もり可能なレベルは必要」であるということです。前述のとおり、必要とされる見積の詳細度は、プロジェクトにより違ってきます。逆に、要件定義段階で必要とされる工数の見積りがどのレベルか、その詳細度によって、要件定義にて行うべき作業を決定すると良いでしょう。

氷山の喩え

「氷山の一角」という言葉があります。表に見える部分は、全体のわずか8分の1に過ぎず、残りは水面下に沈んでいます。その氷山の一角だけで、見えるはずのない水面下を含む氷山全体の威厳を保っています。このことを「要求」と「要件」の喉えとしてみます。要件として実現されている8分の1で、残りの8分の7の要求を満たさなければ、氷山の動きの威厳を保てない、ということになります。17の比率は当然プロジェクトごとに異なるとしても、圧倒的な数の要求に対し、絞り込み、練り込んだ要件で、システム、そしてシステムを使用するビジネスを成り立たせなければなりません。要件要求では、水面下に沈んだ8分の7の「要求」をすくい上げて、要件としてまとめ上げるには何が必要でしょうか。

ビジネス視点・業務視点を忘れない

ITを活用することが前提の情報システムであっても、この段階で技答えは、要件定義において、ビジネスや業務からの視点を外さないこと技術用語の連発はNGです。あくまでビジネス、業務の視点からシステムの要件を整理し、設計を含む後工程に繋げていく必要があります。そして、ITシステムの向かうべき方向をビジネス視点·業務視点で定め、今回整理された要件との間で整合がとれているかを明確にする必要があります。

果たすべき目的とは?

要件定義の目的とは何でしょうか。筆者は次の2点に集約されると考えています。「やるべきこと」と「そのために必要なこと」を明確にすること。それは合意可能かを確かめること。要件を「設計へ移行可能な状態」にすること。この2点です。当たり前のことですが、これらが明確にならないうちに「設計」に入るのは危険です。このことはウォーターフォール型開発だろうがアジャイル型開発だろうが、開発手法にかかわらず普遍です。

【広告】Librus Tech Communityのお知らせ

Librus株式会社が運営する、システムエンジニアやプロジェクトマネージャーの方向けに展開するコミュニティにぜひご参加ください。「互いに助け合い、学び合う空間」をコンセプトに、システム開発に関するセミナーや勉強会をはじめ、案件や転職先のご紹介、相談対応も行います。エンジニア初心者の方や起業、現在フリーランスをされている方、フリーランスを目指している方も大歓迎です。

▼Slackコミュニティ入会フォーム
https://forms.gle/1D5duKwVJhm1vFb18