要件定義書。 「要件定義書」の意味と使い方とは?

システム要件定義の進め方とは?【完全初心者ガイド】社内SE必見

要件定義書

ある日突然上司から、「例の案件の要件定義を、至急作成してくれ」と頼まれたらどうしますか? まずすべきことは、お客さんの要望を把握する「要求分析」とそれをベースにシステムの全体像を決定する「要件定義」の2つのステップがあることを把握した上で、そのプロセスを上司と共有し、顧客ニーズに関する資料を集めるべきです。 そして顧客(エンドユーザー)は何をしてほしいのか、そのためにどのような機能を実装し、どのように進めていくのかをヒアリングし、決定することです。 それを文書に落としたものが、要件定義書です。 IT分野で発生するトラブルの実に40%は、要件定義の不十分さに起因すると言われています。 要件定義は、文章を作成する時の「5W1Hの法則-Who(誰が)、When(いつ)、Where(どこで)、What(なにを)、Why(なぜ)、How(どのように)」に似ています。 本記事では初心者の方向けに、要件定義の大事な視点、要件定義に入れるべき項目、失敗しがちなパターンまで、できるだけわかりやすく解説します。 【目次】 1. 要件定義とは 1. 要件定義に求められる経営視点とシステム開発視点 1. まず最初は現状把握から 1. 要件定義書はシステム開発の台帳になる 1. 要件定義に求められるスキル 2.要件定義書の書き方 2. 基本的な要件定義書の型とは 2. 要件定義書に入れる項目 2. いわば要件定義は、システム開発のルール作りであり、シナリオになるものです。 要件定義には、経営視点とシステム開発視点の2つの視点が必要です。 詳細は後述しますが、構築したシステムが機能し、経営貢献し、依頼主である顧客の顧客満足を実現することが重要です。 要件定義は、クライアントの課題をいかに解決する内容にできるかが重要 1-1. 要件定義に求められる経営視点とシステム開発視点 要件定義には、経営視点とシステム開発視点の大きく2つの視点が必要です。 まず経営視点とは、顧客企業のサービス競争力強化という本質的視点とシステム構築にかかるコストに対するリターンの最大化という2つの視点があります。 この部分は、営業が担当します。 システム開発における顧客企業のサービス競争力強化とは、システム構築投資が今は重要な経営テーマということです。 ユーザーにとって魅力的なサービスを実現する上でシステムは重要な役割を果たしており、システムの機能や使い易さは企業の成長に直結するからです。 コストに対するリターンの最大化とは、プロジェクトのコストパフォーマンスです。 顧客としてはできるだけ安く、早く、高機能でできる方がありがたいのは当然です。 次にシステム開発視点とは、顧客の要求にある機能動作やそれによって引き起こされるユーザーの誤動作までをプロの見地でシミュレーションし、正確なプログラム動作でイメージすることです。 この部分は、システム開発者(SE)が担当します。 要件定義には、経営視点とシステム開発視点の2つの視点が重要 1-2. まず最初は現状把握から システム開発案件は、通常営業担当が受注し、依頼主の担当窓口にヒアリングをすることから始まります。 下記の「システム開発工程の全体像」を見て頂くとわかると思いますが、リリースまでには長い道のりがあります。 担当窓口の方が認識されていない経営課題が見つかるかもしれない営業企画書や社内資料などを集めていきます。 そうすることで要件定義ミーティングで提案という形で先手を打って、機能設計の漏れや事後修正トラブルを回避できます。 要件定義書はシステム開発の台帳になる 要件定義書は、システム開発者(SE)によって作成された「概要」です。 本格的にシステム構築作業に入る前に、顧客(エンドユーザー)に提出される最終書類になります。 その目的は、システムに詳しくない顧客が見ても、システムがどのように開発されていくのか、どんな機能が付くのか、わかりやすく理解してもらえることです。 システム構築中の修正や納品後のトラブルを防止するためにも、要件定義書では顧客の要望だけでなく、開発を担当する企業の知見やノウハウ、業界の最新トレンドなどが反映したものが理想です。 1-4. 要件定義に求められるスキル 質の高い要件定義は、トラブルを防ぎ、顧客満足を向上させる布石になります。 それほど、最上流工程である要件定義は重要です。 ここでは、質の高い要件定義を実現するためのスキルについて解説します。 使い易さは機能や正確性と同じぐらい、システムの生命線です。 要件定義書の書き方 要件定義書には、「業務要件」と「システム要件」の2つの情報群が記載されます。 ただ下記の「要件定義書に入れる項目」一覧にあるように、混乱や誤解を回避するために細かく記載するケースが結構あります。 2-1. 基本的な要件定義書の型とは 要件定義書は、システム初心者の方にとっては、難易度の高いものです。 ここでは、官公庁などで使用された信頼性の高い要件定義書の実例やサンプルをご紹介します。 ・ ・ ・ ・ 2-2. 要件定義書に入れる項目 要件定義書に入れる項目の典型的な例を、以下に記します。 参考にして下さい。 良い要件定義書の条件 良い要件定義書とは、顧客と開発会社双方が誤解なく、の全情報を共有できる文書です。 特に装備すべき機能項目は漏れなく網羅することが重要です。 ポイントを、以下に記します。 要件定義のありがちな失敗パターン 要件定義は一番最初の仕切りフェーズであり、その後の工程にも大きな影響を及ぼします。 要件定義におけるよくあるトラブルパターンを事前に把握しておくことで、事前に手を打って回避できたり、ダメージを最小限に抑えることができるというメリットがあります。 例えば「スマホ画像投稿機能」という言葉があったとしても、その画面イメージや操作イメージが共有されていないと、その後に出てくる技術用語がイメージできないことがよくあります。 要件定義作業および要件定義書とは別に、その開発案件のビジネススキームやインターフェースの画面遷移といった補足資料を用意することで、プロジェクトに関わる全員が同じ認識を持てるようになり、スムーズにプロジェクトを進行させることができるようになります。 ただ納期優先で要件定義を疎かにすると、その後の工程で混乱が生じる可能性が高まります。 通常、要件定義にかけるべき時間は全体工程の3分の1と言われています。 1年のプロジェクトであれば、理想は4ヶ月かけるべきなのです。 そうはいっても現実には緊急性の高い案件も数多くあり、そういった場合、要件定義はしっかり実施し、その後の開発を多方面に展開する工夫をすることで納期を間に合わせるパターンもあります。 システム開発における要件定義段階で、ドキュメント資料だけでなく、似たシステムの開発プロセスや他社先行事例のコスト事例を提示するのは効果的です。 ちなみに、システム業界での有名なトラブル事例を以下記します。 システム開発に関係する用語には、普段聞き慣れないものも多数あります。 そうした時、開発企業にとっては慣れ親しんだ用語でも、顧客企業(エンドユーザー)にとってはほとんど理解されていないという事態にもなりかねません。 どんな機能を装備するか、どのプログラミング言語を活用してバグらないソースコードをどう書くかは、その先の話です。 極論言えば、初期フェーズは技術用語は顧客企業には見せなくてもいいかも知れません。 それよりもビジネススキーム図やインタフェースの画面遷移デザインの方が、顧客企業とGOALをコミットする上で有用なケースが多々あります。 ・具体的な要件定義のプロセスを教えて下さい 要件定義を行うにあたって、具体的な実務のポイントはどういったものでしょうか。 その文書が、要件定義書です。 その作業に入る前に、発注する顧客側から要望や必要条件をまとめたRFPが出されることもあります。 要件定義の作業として、以下が重要なポイントになります。 ・構築する業務 ・システム仕様 ・システム化の範囲と機能の明確化 ・実現すべき要件 ・要件定義の費用について システムを開発する前段階の要件定義には、費用がかかるのでしょうか?費用がかかるとすれば、相場はどれぐらいでしょうか。 コミュニケーションに時間がかかると、要件定義のコストが上がるリスクを感じています。 要件定義ではリソースも確定させるので、開発会社にとっては精緻な金額見積もり作業的な側面もあります。 システム開発に関する売上は、普通人/月(にんげつ)で計算されます。 こういった人的リソースのシミュレーションも、要件定義の重要な要素です。 ここで問題になるのが、その人的リソースのクオリティです。 この場合ですと、月80万支払う価値のあるスキルを保有しているエンジニアかどうかを、顧客企業側が事前に面接したりして確認することが結構あります。 特に顧客(エンドユーザー)がしてほしいことを、可視化も含めてブレなく共有できているかどうかが、その後の工程の生産性を大きく左右します。 そのためには、競合企業情報、社内ニーズ、今までの経験値などあらゆる知見を駆使し、顧客にとって価値の高いシステムを実現するための地図になる必要があります。 このシステム開発の上流工程である要件定義こそが、開発プロセスの心臓部分なのです。

次の

要件定義書って何?書き方と目的、要求仕様書、RFPとの違いまとめ

要件定義書

「要件定義書」とは? 「要件定義書」とはSEによって書かれる最終書類 「要件定義書」とはシステム開発に関して顧客からの要求を受けた後、システムを実際に作る前に提出される最終的な書類で、「開発されるシステム内容」について書かれています。 そのため「要件定義書」は、システム開発をするシステム開発者(SE)によって書かれるのが主流です。 「要件定義書」の目的は「顧客に対する説明」 「要件定義書」の目的は、SE側が顧客のニーズを受けたシステム開発のプランをまとめて、それを専門的な知識のない顧客に対してもわかりやすく説明することです。 「要件定義書」の内容 「要件定義書」の内容は、顧客からのシステム開発に関する要望に即してSEが顧客と相談して、最終的に合意した内容になります。 顧客が専門的な知識を持ち合わせていない場合には、機能などをSEによって付け加えられることもあります。 要件定義書の内容をまとめるときに大切なことは、どの項目でも顧客と細かく協議することです。 それにより、システム開発が終わってから「イメージとは違う」とか「私の思っていたことはもっと別のことだった」といった顧客からの批判や不満が出ることを防ぐことができます。 そのため「要件定義書」の内容は、顧客からの要望だけでなく、SEによる専門的な知識や経験も活かされた踏み込んだ内容になります。 そもそも「要件定義」とは? 「要件定義」とは「開発プランの機能や性能の定義」 「要件定義書」が書かれるまでの間、SEは顧客側から出された要望に対して、専門知識を使いながら開発されるシステムの内容を確認して、そのシステムの持つ機能や性能を定義していきます。 その最終的に定義された機能や性能のこと、またはそれらを定義することを「要件定義」と言います。 「要求定義」は顧客からのニーズをまとめる 「要件定義」に対して、顧客がシステム開発のニーズについてまとめたものを「要求定義」と言います。 そしてそれを文書化したものが「要求定義書」です。 「要件定義書」の書き方とポイント 「要件定義書」の必須項目 開発されるシステムによって項目内容は多少変わってきますが、どの要件定義書でも主に次のようなことが書かれます。 システムの概要:どんなシステムなのかの説明• システム導入の目的:システムを導入することで、何ができるようになるのかを説明• システム導入後の業務フロー:開発されたシステムを導入すると、今後の業務の流れがどうなるのかを示した業務の流れを示したプラン• 機能要件:システムはなにをできることの説明• 非機能要件:機能以外の付随内容の説明 「機能要件」と「非機能要件」 「要件定義書」の項目の中には「機能要件」と「非機能要件」という項目があります。 「機能要件」では「開発されたシステムによって何ができるのか」が書かれます。 具体的には、データの種類や構造、処理できる内容などです。 一方「非機能要件」とは機能以外のことで、開発されるシステムの拡張性や性能、効率性やセキュリティなどのことです。 「要件定義書」の書き方のポイント 「要件定義書」を書き始める前には、必ず顧客との話し合いが大切です。 システム開発で問題となるのが、開発途中で顧客からオプションとして仕様の追加などの変更が加えられて開発に支障をきたすことです。 そのようなことがないように、まずは顧客とよく話し合っておくことが大切です。 また読み手である顧客は、専門的な知識を持ち合わていないことが考えられます。 そのため専門用語ばかりにならないように、わかりやすい言葉を使うようにしましょう。 専門用語を使う場合は、平易な言葉で説明して補足としてカッコ書きで専門用語を書き足すようにします。 「要件定義書」のテンプレート ここではあるシステム導入に向けて書かれた要件定義書の目次とシステム導入の目的を例にとってテンプレートを紹介します。 目次には「要件定義書」に書かれた項目タイトルをリストとして明確に書きます。 本文のひとつである「システム導入目的」では、タイトルに続き小見出しをつけて、それぞれに説明を加えていくという構成になります。 目次のテンプレート 1. 2 システム導入の目的 1 システム化の目的 (新しいシステムを導入されたらどのようなことが達成されるのかを説明) 2 現行システムの問題点 (問題点を説明する) 例: ・各部門との連携がうまくいっていない ・連絡伝達に時間がかかりすぎるなど (3)システム化の方針 (システム導入後、達成される内容を具体的に記述) 例: ・システム導入により、業務を妨げる無駄を省き効率化を目指す。 ・データの総合間管理を実現して情報を共有する、など。 「要件定義書」の英語表現 英語で「business requirements document」 「要件定義書」は英語で「business requirements document」と言います。 「要件」は「requirement」で要件が複数あることが普通ですから、複数形の「s」をつけます。 「document」は「書類」の意味です。 「business」をつけなくてもいいのですが、仕事に関するという部分を明確にするために「業務」という意味の「business」を最初に置く使い方がよく見られます。 また「定義」を意味する「definition」を使って「requirements definition document」と訳すこともできます。 顧客からのニーズを受けて、システム開発者であるSE側が専門的な知識も付け加えた内容になります。 システム開発後に顧客からの不満が出ないように、事前の十分な話し合いが大切です。

次の

ミスなくモレなく見やすい「要件定義書」の書き方 (1/3):ユーザーの要件には「ウソ」がある?

要件定義書

システム要件定義書の書き方6つのポイント 要件定義書の書き方としてポイントとなるのはどういったことでしょうか。 要件定義書を仕上げるには、頼む側の企業と作る側の企業の意見が一致しないと良いものは作ることができません。 そういった意味でも、きちんとした意見の摺り合わせをした上で、要件定義書を作成することが一番です。 全体の方針を決める 要件定義書を作成するにあたって、一番大切なことは全体の方針をきちんと決めることです。 何故、そのシステムを作ろうとしているのか。 この部分をきちんと「システム化」の目標として定めないと、どんなプロジェクトも先へは進めません。 まずは、プロジェクトの基本方針だったり背景だったりをきちんと決定し、システム化する範囲を決めることが大事です。 それから外部のインターフェイスや利用するユーザーの範囲などを細かく決定していくことで、全体の方針をしっかりと決めましょう。 業務の要件を決める 要件定義書を作成するにあたって、業務の要件を決めておく必要があります。 業務の要件とは、新しいものを作り上げるときに必要な業務のあり方や運用をまとめることで、業務に必ずなければならないものの条件や環境のことを指します。 通常、要件定義書を作成するにあたって、現存する業務を分析することで、新しいものをシステム化するのに必要な範囲を決めるのです。 機能の要件を決める 要件定義書を作成するにあたって、機能の要件を決めなければなりません。 機能の要件とは、新しく作る業務にてそのシステムやソフトウェアを使って何が出来るのかを整理したものです。 そのシステムにおいて使うデータの種類や構造、画面表示の方法や、操作の方法。 処理内容、帳票などの出力の形式などが、この機能の要件に含まれます。 要件定義書を作成するには、この機能の要件をきちんと作り込んでおくことが大切です。 非機能の要件を決める 要件定義書を作成するには、非機能要件を記載する必要もあります。 非機能の要件とは、先ほど述べた機能要件以外のシステム要件のことを指します。 どのような事か具体的に示すと、運用性、セキュリティ、信頼性、性能、拡張性などを指し、これらに関する要件が内容として含まれることになります。 要件定義書には、このような非機能要件もきちんと記載しなければいけないのです。 絶対にしてはいけないこと 要件定義書の書き方のポイントとして、絶対にしてはいけないことがあります。 それは、お客様の要望を全て聞き入れよう、100%実現しようとしてはいけないということです。 これだけは絶対にしてはいけません。 お客様の要望に全て応えることが顧客満足度に繋がると思われるかもしれませんが、それはシステムエンジニアとしてのプロの仕事とは言いません。 どんな業界でもお客様の方がその業務のプロであることに間違えはありませんが、新しくシステムを構築するという意味では、システムエンジニアの方がその分野のプロという自覚を持ちましょう。 お客様が最終目標としているシステムが、どのような効果を生むのか、また技術的に可能な要件であるのか、お客様の希望の予算内にきちんと収まるのか。 これらを総合的に判断して、一番最適なものを提案することが重要です。 要件定義書を作成していくにあたって、お客様と要件を決めていくときには、たくさんの要望が出て来るものです。 しかし、費用対効果のないものや実現不可能な要件なども出て来ることもあります。 このような時に、はっきりと「できないものはできません」と言えることが大切です。 勿論、出来ないものにはその理由と根拠を丁寧にお客様へ説明することが大切です。 また、このような場合別の提案が出来ると、お客様との間にさらなる信頼関係が生まれるかもしれません。 顧客満足度を上げる書き方 要件定義書の書き方について、顧客満足度を上げるような書き方は相手の言いなりなった形の要件定義書ではありません。 お客様側の要望を全て聞き入れているのだから、顧客満足度は高いのではないかと思われるかもしれませんが、それは違います。 自分の言った通りのものだけが出来たのであれば、それは当たり前のことです。 相手の要望から、不必要なものを省いて必要になりそうな別のものを提案して盛り込みます。 それがうまく機能した時こそ、顧客満足度というのは上がるのです。 だからこそ、要件定義書を書く時は相手の要望を全て聞き入れることをしてはいけないのです。 まとめ いかがでしょうか。 要件定義書の書き方を6つのポイントからご紹介しました。 要はシステムを構築するための、基本的な最初の全体構想を練る部分を決定するためのものです。 しかし、ここできちんとしたものを作成しておかなければならない重要なポイントなのです。 システム要件定義書の書き方6つのポイント• 全体の方針を決める• 業務の要件を決める• 機能の要件を決める• 非機能の要件を決める• 絶対にしてはいけないこと• 顧客満足度をあげる書き方 Filed Under: Tagged With: ,.

次の