システム設計の登竜門！要件定義入門#2

システム設計の登竜門！要件定義入門#1での内容、要件定義の基本や概念をより深く理解、習得するためページです。もし#1をご覧になっていない場合にはシステム設計の登竜門！要件定義入門#1を先に参照ください。

要件定義を始める際の第一歩、

まずは要件定義の中で、設計に必要な枠組みを明確にすることを目指します。「枠組みを明確にする」というのは、つまりシステム、インフラ、アプリケーション、データに関するアーキテクチャの方向性を明確にし、その中で必要なデータとプロセスを明確化することを指します。例えば、アプリケーションは現行踏襲を基本とするのか、インフラはオンプレミスで構築するのか、クラウドに移行するのか、プログラミング言語も現行踏襲か、データモデルを流用するのか等を明確にしていくことになります。

「枠組み」は開発手法やプロジェクトにより異なります。いずれにしても、その枠組みを想定した場合に、どの程度の開発規模が必要になるか、求められる精度の見積りが可能でなければなりません。このことは、要件定義の段階で「どこまでを求めるか」により、後続の各工程で定義すべき内容が変わっていくことを意味します。ですので、読者の皆さんが関与する開発プロジェクトにおいて、工程に対する考え方がきちんと確定した時点で、内容をカスタマイズする形で、「要件定義」にて行うべき作業を定義していってください。

情報システムにおける「要求」と「要件」

情報システムにおける「要求」と「要件」ここでいったん、情報システムにおける「要求」と「要件」の考え方を整理しておきましょう。「要求」とは、「ユーザーが情報システムで実現したい事」を指します。「要件」とは、「要求」を基に、「制約」を踏まえて、「情報システムに盛り込むべきもの」を指します。この2つの定義を、どこまでも念頭に置いておいてください。

「要求」と「要件」の違い

＃1 でも前述しましたが、再度「要求」と「要件」の違いを整理してみましょう。「要求」= 本当に欲しいもの「要件」= 本当に要るもの要求と要件の違いを簡潔に言い表すとしたら、このようになります。要求にはまず、大きな「ビジネス要求」があります。それを実現すべく「ピジネス要件」を整理していきます。さらに部門レベルの「業務要求」があります。その実現手段は「業務要件」として整理していきます。システム要件は、ビジネス要件と業務要件をブレイクダウンする形で整理していきます。また、「ビジネス要求」「業務要求」から「システム要求」が明かになり「システム要件」として整理される場合もあります。例えば次のような具合です。

ビジネス要求:定性·顧客の拡大と顧客満足度の向上。定量·それに伴う売上の向上。

業務要求:担当部門における顧客の利便性向上によるクレーム減少。円滑なフローによる受付事務負担の軽減。部門売上の向上、会員数増加、サイトアクセス増加。

システム要求:新ECサイト構築。新決済手段導入によるサイトユーザビリティの向上。アクセスログ取得。リコメンド導入。基幹系とのデータ連動実施。顧客マスターの再構築。さらに、最初から「システム要求」が明らかであり、それを実現するための「システム要件」を整理していく場合もあります。

さらに最初から「システム要求が明らかなケース」には、以下があります。

①RFP(提案依頼書)の中にシステム要求が明示されている一この場合においても、「ビジネス要求」「業務要求」との整合性は精査する必要があります。

② システムの保守フェーズにおいて発生した要求一現場の声に押されて明らかになった場合でも、「ビジネス要求」との泥離が生じていないか精査する必要があります。

③誰の目から見ても「システム要件」とすべき要求(操作性に問題のある UIを改善するなど)一緊急性があるため、すぐに手をつけなければならないのはやむを得ませんが、それでも結果的にどう「ビジネス要件」「業務要件」に反映されるのかは、きちんと精査できるようにしておきましょう。

④外部要因により「ビジネス要求」が「システム要求」になったもの。

上記④の例には、税制·法律·制度の改正、グローバル対応、BCP(事業継続計画)、セキュリティ対策、データ駆動経営(内外データを活用する地盤作り)等があります。ほとんどの場合こういった要求は、現場の業務要求を通り越してシステム要求となります。必然的に優先度を上げて対応を迫られることになります。

さて今度は、システムに対する要求と要件を、簡潔に定義してみましょう。

「要求」= ユーザーが情報システムで実現したいこと

「要件」= 要求に基づきつつ、制約を踏まえて、情報システムに盛り込むべきもの

然るべき制約の中で実現可能な要求だけが、要件としてまとめられていきます。いくら高い理想を掲げたくても、現状を含む制約を無視しては、要件たりえません。また、要求と要件の違い以前に、そもそもの問題として、多くのユーザーが「システムで解決すべき要求と、別の手段で解決すべき要求」、つまりビジネス要求とシステム要求をきちんと判別できていないことがあります。要求を整理する段階、例えばRFPの作成時に、「要求のあるべき姿」にまで突っ込んで社内コンセンサスがとれていればよいのですが、たいていの場合はそうなっていません。このことは、業務改革を伴うプロジェクトや、新規ビジネスの立ち上げを伴うプロジェクトではいっそう顕著です。

どこまでがビジネス要求で、どこからがシステム要求かわからない、換言すれば、課題のどこまでをシステムで解決すべきか、ユーザーすらわかっていないケースが多々あります。そんな状態であるにもかかわらず、開発者はユーザーの言うことを何でも丸呑みして、全てシステム要件として整理し、システムに取り込もうとしてしまい、挙句に工数ばかり超過して、要求を満たすシステムを構築できなかったという例は珍しくありません。

そうした事態に陥らないために、本書では要求を階層化して、整理していく方法を説明します。要求をステークホルダーのレベルに応じてきちんと整理し、かつ、「要件となりうるか」を明確にしていくのです。要求が全て要件となる訳ではないことを常に頭の片隅に置いておきましょう。

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

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

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