要件定義の目的＝すなわち最もやらなければならないこと、要件の範囲の明確化です。要件の範囲を明確にする！要求を基に要件を明らかにするとともに要求がどのように要件として整理されるに至ったのかを経緯を把握し、全体を俯瞰し、システムの核を確実に把握していきます。「知っておきたい要件定義のやるべきこと」はシリーズ化していきたいと思いますのでよろしくお願いします。
ここからの進め方
まず、本項(要件定義でやるべきこと＃1)において要求の要件化を行い、かつトレース可能な状態を構築します。併せて、新TOBEモデル(到達するモデル)の作成準備を行います。次項(要件定義でやるべきこと＃2)では、要件を基に、システムの全体像と外部制約を明確にするために、システム全体図を作成します。併せて、新TOBEモデルの概要を作成します。#3では、業務フローの明確化、#4では業務プロセスの明確化、#5ではUI(システムから利用者への情報の提示・表示の仕方と、利用者がシステムを操作したり情報を入力したりする手段や方式、機器、使い勝手などの総体を表す)· 機能の明確化を行い、#2~#5で抽出された情報を基に、#6でデータ要件の明確化を行います。その後、業務プロセス、UI·機能へのフィードバックを行います。さらに業務プロセス、機能、データ要件を基にCRUDマトリクスを作成し、その結果を業務プロセス、UI·機能、データの各要件にフィードバックします。ここまでで新しい ToBeのプロセスモデルとデータモデルを確定させます。さらにモデルと各要件との整合性を再度精査し、要件自体の見直しを行います。この一連のサイクルを複数回繰り返すことにより、新ToBeモデルを完成させ、要件定義を確立していきます。
反復とフィードバックの意味
要件定義における業務プロセス、UI·機能、データの明確化について、反復フィードバックを行いつつ、反復を行うことにより、要件定義の品質が高まります。一度だけでなんとかしようとは思わないことです。反復のなかで、開発者もユーザーも(システム屋と業務屋という表現でもいいかもしれません)多くの気づきを得ます。理論に裏付けされた経験の繰り返しに、勝るものはありません。
「現行どおり」の危うさ
要件を固める打ち合わせの席で、ユーザーから「現行通りに作ってくれ」と言われることがあります。「機能を問う州する」という考えです。しかし、これをそのまま「要作」とすべきか否かは、熟考を要します。「現行どおり」と言われても設計書が存在しない場合、現行の仕様がわからずに、一から調査しなければならない場合もあります。現行の仕様が開発者に伝わっていないことによる仕様漏れや設計漏れのリスク、あるいは、現行機能どおりに作った機能が実は業務フロー上の問題点になっていたため修正を余儀なくされる等のリスクも内在しています。
要求(実現したいこと)から要件(要求と制約から開発に盛り込むべきもの)へ
「ビジネスの要求」「業務の要求」「システムの要求」として浮かび上がった諸々の事項は、全てが要件になるわけではありません。各要求のなかで優先順位の高いものを中心に、「システム要件」の形に整理し、開発すべきシステムに反映します。「システム要件の形」とは、開発対象となるシステムの ToBeモデルを指します。具体的には、要求を基に作成された元ToBe モデルへの制約やAslsモデルを考慮して作り上げた新ToBeモデルであり、プロセスモデル、データモデル、機能、UIを想定できる要件です。前述したとおり、無理に要件化するのではなく、あくまでシステムに求めるべきもの、実現可能性を基に要件化していきます。そして制約により要件化できなかった要求は、どのような制約により不可であったかを明確にします。代表的な制約は、リソース(人·モノ金)と時間(スケジュール)、技術的困難、技術的制約、現状との泥離の7点に集約されます。
「人」:
いくら素晴らしい方法論があり、素晴らしいツールが用意されていても、使いこなせる人がいなければ話になりません。また技術力やマネージメントの欠如も、プロジェクト遂行の妨げになります。そもそも新しいビジネスを始めるにあたり適材がいなければ話になりません。
「物」:
ビジネスに必要な設備や実装に向けた環境、インフラ、ツールが用意できなければ話になりません。「人」が使うツールも重要な「物」のひとつです。
「金」:
外注に限らず、自社開発でも人員のコストはかかります。システム開発は金に左右されるといってもよいでしょう。また、インフラにどこまで投資するかは、非機能要件次第とはいえ、最終的には「金」で決まります。投資効果は最後には定量的に「金額」で判断されるので、制約としてはこの「金」のウェイトが一番大きいといえます。
「時間」:
納期がなく、いくらでも時間をかけてよければ、かなりの制約から解放されることでしょう。でも現実にそんなことはありません。「時は金なり」で、「金」も絡んできます。時間を使うには金がかかるのです。
「技術的困難」:
ビジネスには大きなインパクトを持ちうるが、実現するには技術的リスクを伴うものを指します。
「技術的制約」:
例えば「既存システムの一部分を利用する」、「ERPを使用することが決まっている」、「クラウド使用が決まっている」等です。
「現状との乖離」:
元のToBoモデル(到達するモデル)と AsIsモデル(現在のモデル)の乖離が激しい場合、充分な検討が必要です。経営判断として「ビジネス要件」化する固い意志があれば別ですが、現実的に可能かどうかを判断した上で、要件化する必要があります。
新規開発の場合、「ビジネス要件→業務要件→システム要件」という要件化の流れは、稀に遡ることがあっても、基本的には一方向に流れていきます。一方、修正案件では多くの場合、「業務要求→業務要件→システム要件→業務要件→ビジネス要件」、「システム要求→システム要件→業務要件→ビジネス要件」というように、起点が業務要求またはシステム要求となる場合があります。この場合でもビジネス要件との整合性をとる必要があります。
「要求」に基づいて「要件」を固めていくこの過程で、どのような分析·検討が行われ、また、意思決定が下されたかを振り返り、要件を確定するとともに、トレース(追跡)可能にしていきます。そして要件として整理された事項が、トレースによりシステム開発プロジェクト全体の方向性と一致しているか、常に確認可能な状態を作り上げます。前述したリポジトリを活用していれば、この「トレース可能な状態」を作り上げるのは比較的容易です。
ここでは業務の複雑さに向き合う覚悟を求められます。なんでもシステム要件とするのでなく、ビジネス要件と業務要件の検討を行い、システム要件を整理することにより、業務プロセスやデータ構造をシンプルにすることを目指しましょう。
ユーザーから引き出したビジネス要求や業務要求に、様々な制約を加味してビジネス要件や業務要件へと落とし込み、業務要件からさらにシステム要件となりうるかを検討するとともに、ビジネス要求と業務要求からブレイクダウンして整理されたシステム要求に対して、同じく制約を加味して、システム要件になりうるかを検討していきます。
【広告】Librus Tech Communityのお知らせ
Librus株式会社が運営する、システムエンジニアやプロジェクトマネージャーの方向けに展開するコミュニティにぜひご参加ください。「互いに助け合い、学び合う空間」をコンセプトに、システム開発に関するセミナーや勉強会をはじめ、案件や転職先のご紹介、相談対応も行います。エンジニア初心者の方や起業、現在フリーランスをされている方、フリーランスを目指している方も大歓迎です。
▼Slackコミュニティ入会フォーム
https://forms.gle/1D5duKwVJhm1vFb18