初めての方へ

システム開発の要件定義

  1. HOME
  2. 初めての方へ
  3. システム開発の要件定義

システム開発の要件定義とは

お客様の業務を図や文章で表現する

お客様の業務を図や文章で表現する

システム開発が失敗する理由」にも説明がある通り、システム開発で一番難しいところは、我々開発者が、お客様のことを知る、というところです。そして、「要件定義」とは、この「お客様のことを知る」という作業になります。

従いまして、「要件定義」について、正しいやり方、というのは、あるようで無い、と、思います。一言で言えば、「お客様にとって当たり前の業務を、図や文章で表現する」ということになります。

お客様の業務をシステムの機能で表現する

お客様の業務をシステムの機能で表現する

お客様のことを知る、のではなく、お客様の業務をシステムの機能で表現する、というアプローチです。要件定義というよりも「フィット・アンド・ギャップ」という言葉で表現した方が良いかも知れません。

出来合いのシステムを導入する場合に、事前に、そのシステムで業務が出来るかどうかを、確認することを指しますが、広い意味で要件定義と呼んで良いと思います。例えば、売上伝票入力をするときに、システムの機能と現場で使っている伝票の書式と比べて、全てを網羅出来ているか、伝票の修正はどう出来るか、承認処理はどのようなフローになるか、など、実際にシステムを導入して、日々の業務をこなせるかどうか、確認をします。

システム開発の要件定義で決めること

要件定義は上述の通り、お客様の「業務」について明らかにしていくプロセスです。
その作業に有効な資料作りが、要件定義での「成果物」になっていきます。一般的なものとして、以下のようなものがあります。

概要システム開発を行いたい理由を述べます。現状の課題、実現したいこと、を、文章で表現し、お客様と開発チームが同じゴールを共有するための基本的な情報になります。
組織構成図社内や部門内の組織図です。権限管理や承認フロー、ステークホルダの明確化、物理的なオフィスや作業場所の違い、といったことを理解するのに役に立ちます。
業務フロー図(現状)業務毎に、現状、どのような流れで仕事が進むのか、図で表します。
部署、その中での登場人物別に、何に対してどのようなアクションを取るのか、ということを、図にしていきます。

これによって、業務がどれだけの人に関わるのかと、どういう順序で行われるのか、が明確になります。
業務フローには、社外の登場人物も明記される必要があります。例えば、銀行、運送業者、外注業者、仕入先、顧客、など、日々の業務で接する社外の方々も、明示する必要があります。
業務フロー図
(あるべき姿)
システム導入後に、どのような姿になっているべきかを、業務フローで表します。
現状のフローに、吹き出しなどであるべき姿を表現することも多いかもしれません。
業務タイムテーブル
(日、週、月、など)
業務フローは、業務の流れを表しますが、時間の概念を表現するのが難しいです。

1日、1週、1ヶ月、といった単位や、1取引、という単位で、どのような時間の流れで業務が進むのかが、重要なケースがあります。業務フロー図に吹き出しで表現することは出来ますが、時間の流れを明確にすることで、隠れた要件を見つけることが出来ることがあります。
機能要件改善された業務フローに必要な、システムとしての「機能」を一覧化します。
非機能要件改善された業務フロー上で、期待される効果や、実現されなければいけない制約を一覧化します。

例えば、〇〇機能は5秒以内に処理が終らないといけない、システムは8:00から20:00まではノンストップで稼働しなければいけない、月末処理は〇日までに終らないといけない、といったことになります。
セキュリティ要件非機能要件に含まれるものではありますが、セキュリティ要件は重要な要件になりますので、別に扱うことも多いです。
・個人情報や機密情報を扱う機能
・インターネットを利用する機能
・社外の人やシステムと繋がる機能
・システム外の、機械と繋がる機能
などは、要件定義の段階で明確になっている必要があります。

システム開発の要件定義の進め方

システム開発を行いたい理由を共有する

何故システムを開発したいのか、を、まず、共有させて頂きます。この理由は、要件定義が完了する時に、最終的な目標になります。ですが、要件定義の中で、変わっていくこともあるかもしれません。重要なことは、最終的にはお客様、開発チーム、の双方で、同じ目標を共有していることです。

現状の業務フローと、あるべき業務フローを、作成する

成果物として作成する業務フローを作ります。この取り組みの中で、組織図も自ずと作成されます。
現状の業務フローを作り、その後、あるべき業務フローを作成します。

機能要件を作成する

あるべき業務フローまで作成できると、必要な機能の洗い出しが出来るようになります。
それが機能要件になります。

非機能要件、セキュリティ要件を作成する

機能要件は業務フローを眺めていれば作成出来るのですが、非機能要件とセキュリティ要件は、業務フローでは見えません。お客様と開発チームで、ディスカッションが必要になります。この2つについては、お客様だけではなく、開発チームの方が詳しいことも考えられます。
特にセキュリティに関しては、お客様の希望する機能が、実現出来ないこともあり得ます。(例:クレジットカードナンバーを、登録しておいて、リピータのお客様の利便性を測りたい、といったことは、簡単に実装してしまうと、とんでもないセキュリティ事故につながりますから、開発チームとしては受け入れられない要件であることも考えられます。)

システム開発の要件定義が失敗するポイント

お客様と開発チームの会話不足が招く誤った要件定義

お客様と開発チームの会話不足が招く誤った要件定義

要件定義とは、お客様と開発チームが、歩み寄る場ですから、時間がかかります。1回、2回で終わるものでもありません。お客様の中のステークホルダ全員が関わる必要があります(経営層、部課長、現場の担当者、全ての方々に関わって頂く必要が出てきます)。

従って、きちんと時間をとって、きちんと話合うことが出来なければ、失敗してしまいます。
そして、往々にして、この時間を取ることが出来ずに、「失敗」してしまいます。

 

また、どんなに時間をかけても、間違った要件定義になってしまえば、同じく「失敗」です。要件定義が正しいかどうかを、お客様自身が、確認する必要も出てきます。この作業は、とても大変な作業になりますが、お客様の責任で実施する必要があります。ですので、正直に言いますと、要件定義という作業は、とても難しい作業になります。

システム開発の要件定義を成功させるためには

プロジェクトリーダーの決裁権とチームの連携

POINT 01

プロジェクトリーダーの決裁権とチームの連携

必要があれば経営層にも関わって頂く必要がある要件定義ですので、開発チームだけでは推進が困難です。お客様の方でもプロジェクトリーダーを立てていただき、プロジェクトリーダーが部署横断的に、調整に協力をして頂くことが、重要になります。また、作成される要件定義の成果物をプロジェクトリーダーの方が確認して、承認することが出来ないと、進まなくなってしまいます。

 

社内の方でプロジェクトリーダーを立てるのが難しい場合、開発チームから、お客様の立場で振舞うリーダーを用意することもあります。この場合、いきなり現場に入ってくる他社の人間に対して、現場の方が受け身にならないよう、経営層またはプロジェクト推進ご担当者の方から、全社アナウンスして頂く必要が出てきます。

 

要件定義では、お互いの意見が対立することも、考えられます。そうした際に、妥協したり、決断したりする必要があります。開発チームだけでなく、お客様の方でも、プロジェクトリーダーにある程度の決裁権があることが、求められます。

トライ&エラーを繰り返しながら進めるアジャイル開発

POINT 02

トライ&エラーを繰り返しながら進めるアジャイル開発

このように、要件定義というフェーズは、非常に責任も重く、難しいフェーズになってしまいます。多くの方が、その責任を負うことに不安を感じるはずですし、逆に強硬になりすぎて、開発側の意見を否定するだけになってしまうと、出来もしないプロジェクト計画になり、不幸な結果を招きやすくなります。

 

ですので、小さなものを出来るだけ早く作って、お客様と一緒に確認しながら進める、というアジャイル開発が、そうした重責を軽減出来ることもあります。トライ&エラーで進めることが大前提になるので、仕様変更があっても、出来る限りのことを試して、失敗するならまたやり直す、ということも、比較的やりやすくなります。

 

要件定義を進めるのが難しい、という場合、フィジビリティスタディも兼ねて、アジャイル開発を進めてみて、システム化すべき内容が明確になったら、改めて要件定義からやり直す、ということも、お勧めです。

初めての方へ

システム開発の工程

システム開発の流れについてはこちらから。

システム開発にかかる費用

システム開発のケースに応じた参考費用についてはこちらから。

システム開発が失敗する理由

お客様との共同作業となる要件定義の進め方はこちらから。

システム開発の要件定義

システム開発・導入に関してよくある疑問にお答えします。

システム開発・導入に関してよくある疑問にお答えします。