要求開発超入門 / Vol.11 AsIsとToBeとは | リコーITソリューションズ株式会社
要求開発において、AsIsとは現状の業務やシステムのことを示します。またToBeとは、次期の業務やシステムのことを示しています。 さて、ビジネスを"見える化"するには、どのような観点が必要なのでしょうか？ まず、現状の業務・システムはどのようになっているのか捉えなければならないでしょうね。そして、将来のあるべき姿としての業務・システム像も必要です。さらに、予算・コスト・期間を踏まえた、現実的な次期の業務・システムの姿も"見える化"しなければなりません。 このことを図で表すと図1のようになります。このように業務・システムの姿を、現状、理想（あるべき姿）、次期という3つの形式にまとめるのは、基礎知識として知っておく必要があるでしょう。 しかしながら、この3つの"見える化"を行うのは実践的ではありません。あるべき姿と次期という2つを捉えるのはコスト的にも大変で、しかも、両者の違いが非常に曖昧にな
RFP/要件定義/要求仕様---違いは明確？
「RFP（提案依頼書）」「要件定義書」「要求仕様書」──。この三つの言葉を見て、その違いを明確に説明できるだろうか。筆者は、日経SYSTEMSという雑誌を担当して日々システム開発現場における開発手法や実務情報を記事としてまとめているが、この三つの用語には、定義に曖昧な部分があったり、違いが分かりにくい面があったりすると感じている。 三つの用語が示すドキュメントはいずれも、ユーザーがどんなシステムを開発したいのかを記述したものだ。実は、筆者がこれまで普通に使っていた用語は、三つのうちRFPと要件定義書の二つ。これらについては、それなりに違いを理解しているつもりである。対して、要求仕様書という用語はあまり使っていなかった。 ざっくりいえば、RFPはシステム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出すためのもの。一方の要件定義書は
「要件定義」を理解しよう （要求・要件の３レベルのまとめ） - 主に言語とシステム開発に関して
システム開発の要件定義には，さまざまな手法がある。 たとえば，「要件」という言葉と「要求」という言葉が混同され紛らわしい。 が，どの手法も基礎は同じ。 ビジネス 業務 システム という３階層さえ把握すれば， 要件定義や要求定義について書かれたどんな文章も読みこなしてゆける。 要件定義の「３階層」を理解するための一覧表 要件の３段階 段階 1 2 3 名称 ビジネス要件 業務要件 システム要件 主役・焦点 ビジネス， 企業経営者 業務，ユーザ， 各部門担当者 システム 要件発信者 発注者（顧客） 受注者（ベンダ） 内容の違い 要件の内容 企業としての，市場に対する目標や経営上・事業上の問題点。 業務担当者としての，部門の業務を果たす上での課題・目標。 システムとして，業務要件を満たすために業務モデル内で果たす役割。 曖昧さを排除するために ROIを用いて数値化して記述する。 KPIを用いて数
要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要アクション
要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要アクション：明日から使えるシステム開発プロジェクトの進め方 再入門（2） 本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。今回は、要件定義の準備作業について解説する。要件定義をスムーズにこなすためには作業に着手する前に綿密な計画を立てる必要がある。 連載目次 要件定義へ拙速に突入してはいけない システム開発プロジェクトの進め方をあらためて解説する本連載。前回の「若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実」では、今のSIerが直面している問題点を提示し、本連載の意義や概要などを紹介した。今回からプロジェクトの進め方についてから具体的なノウハ
要件定義をうまくこなすためのポイント――要件定義の完了条件と要求の引き出し方
要件定義をうまくこなすためのポイント――要件定義の完了条件と要求の引き出し方：明日から使えるシステム開発プロジェクトの進め方 再入門（3） 本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。今回は、要件定義をうまくこなすためのポイントについて解説する。手間を惜しまず丁寧に対応しよう。 連載目次 皆、悩んでいる――そもそも、要件定義とは システム開発プロジェクトの進め方をあらためて解説する本連載。連載第1回の「若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実」では、今のSIerが直面している問題点を提示し、本連載の意義や概要などを紹介した。前回の「要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要
要件定義に必要なスキルと技法|中堅企業・中小企業における パッケージ導入の手引き
企業における情報システムの役割と比重がますます高まっています。情報システムへの経営者、管理者、利用者からの要求も多様になり、しかも要求もお互いに関連しあっており、複雑性を増しています。また、要求実現の検討を行う際にルール改善・仕組み見直しなどの問題を解決すべき事柄も含まれています。 要求の実現を達成するために、パッケージ導入（システム再構築・クラウド）のＦＩＴ＆ＧＡＰを含む要件定義作業の進め方と成果物のまとめ方が重要なウエイトを占めています。この要件定義作業を滞りなく進め、実のある成果物を創りだすためには、それに必要なスキル・技法・知識が必要不可欠です。これらを保有しているプロジェクトメンバーによってのみ、要件定義の価値ある成果物が可能になります。 ● 要件定義作業の要領と特性及び限界を知ることは大切なことです。次のダウンロード資料 に目を通すことを薦めます。 【参考】 ダウンロード資料＜
要件定義のIT化支援ラボ株式会社
IT導入はするな！ 要件定義無し（RFPのみ）のシステム発注は危険！ システムの導入やWebサイトの構築を検討中の担当者・責任者の方々には、事前に知っておいて頂きたい事があります。 満足できるシステムを導入できる確率はどの程度かご存知でしょうか？ 調査の結果、明確な数値が出ています。調査によると、 満足いくものが作られる確率の方が低いのです（具体的な数字は次ページ）。 まさかとお思いかもしれませんが、決して大げさに言っている事ではありませんし他人事でもありません。 もしシステム化で失敗するとどうなるのでしょうか？ 企業として打撃を受けてしまうのは当然ですし、担当者や責任者個人の立場も危うくなることさえあります。 しかし、どんなにリスクがあったとしてもシステム化が必要なケースは存在します。 そんな時にシステム化の担当者はどうすれば良いのでしょうか？ 使いやすいシステムを構築・導入するのは本当
要件定義のIT化支援ラボ株式会社
要件定義をできる人材とは？ 要件定義書や、要件定義を含むRFPを作成するにはどのような知識や経験を持つ人が必要なのでしょうか？ 残念ながら、システムに詳しければ誰でもできるというわけにはいきません。 どのような要件定義でも共通して必須となる条件は、 「実際の要件定義の場面に少なくともアシスタントとして立ち会った経験が有る事」 「要件定義書をもとにシステム設計をした経験がある事」 の二つです。 前者は当然の条件です。 要件定義は発注者の業務的・人間的な要求を引き出しつつ、開発側にとっても役立つ情報に定義・分類していく複雑な作業です。 要件定義を行う工程をパターン化することは難しいため、書籍での学習やセミナーを受けただけのレベルでは決して習得できるものではありません。 ましてや発注者の要求が漠然としている場合や組織内で要件が纏まっていない場合、更にシステム化に逆行する企業文化を持つ場合など、た
要件定義ツールを使った既存システムの分析
前回はUMLを使ってシステムの地図をかく方法を説明しました。今回はUMLを使わずにより簡単に分析する方法を説明します。システムの入出力とデータをつなぐ分析手法は、要件定義でも使われる手法なので同じ要領で既存システムを分析することができます。今回ご紹介するのは要件定義ツールを使う方法です。柔軟性には欠けますが、要件定義が初めての方でも簡単に短時間でまとめることができます。 短期間に分析する 今回ご紹介する方法は画面数が100程度の中小規模なシステムを対象としています。システム関係者へのヒアリングが行える環境があり、材料（入出力情報とデータ）が揃っている場合は、手法とツールを使うことで、短時間でシステムの地図を作成できます。 今回は要件定義ツール「要件のツボ」を使った方式を説明します。今回もプログラムそのものを調査するのではなく、システムの入出力を調べ、その使われ方を調べる方法です。「要件のツ
要件定義 - IT Systemの作り方
要件定義とは、システムの開発や改修に先立ち適用される領域の業務を明確にしシステム側に要件を明確にする、ソフトウェア開発の一プロセスである。 かつてのシステムは、非常にシンプルなものであった。企業・社会の中でのシステムの位置付けは、人が手作業で行っていた単純な計算作業を代わりに行う電卓の延長のようなものである。しかし、ハードウェア・ソフトウェア・ネットワーク技術の発達と共にシステムが行える事が幅広くなり、社会・企業のあらゆる領域に進出した。今や、企業の中核で重要な経営判断をサポートするまでに広がっている。それに伴い、代替する業務の内容は複雑化し、技術者はシステムを開発する能力のみでその責務を果たす事は難しく、システムをとりまく業務を含めてデザインする能力が求められるようになった。技術面でも、複雑化に対応するため、オペレーティングシステム・ミドルウェア・フレームワーク等、多くの実現方法を生み出
やってはいけないシステム要件定義の禁じ手とは - ITマネジメントのノウハウ
システム要件定義は、業務の要件をシステムの作り手に伝える重要な情報である。曖昧な要件定義に代表される、やってしまうと後から面倒なことになる「やってはいけないこと」と、そのデメリットをご紹介する。 □ 大ざっぱな要件提示でも問題ない場合 情報システムのユーザー企業の担当者が、ITベンダーのエンジニアに口頭で要件を伝え、後日、エンジニアがまとめた仕様を確認した上で発注し、プログラム開発に着手する。継続的な取引関係にある場合によく見られる光景である。このような場合、エンジニアはユーザー企業の業務やシステムの仕様を熟知しているため、ことは上手く運ぶ。しかし、全く新しい業務であったり、これまで該当業務で取引がないITベンダーが相手であったりした場合は事情が大きく異なるので注意が必要だ。 □ 曖昧なシステム要件定義のケース 例えば、販売管理システムの再構築のために、RFP（提案依頼書）を作成して、提案
プロジェクト管理と要求定義の肝
要求定義の肝 発注者のためのプロジェクト管理 日経コンピュータ（日経BP）の2009年7月8日号に寄稿した「発注者のプロジェクト管理」の元原稿です。 アーキテクトの仕事～立ち上げ・要件定義 システム開発ジャーナル（毎日コミュニケーションズ）の創刊号に寄稿した「アーキテクトの仕事～立ち上げ・要件定義」の元原稿です。 著書 なぜ今、「発注側のプロジェクト管理」なのか 工事進行基準の適用が始まった。システム開発における数々のグレーゾーンを排除するために、ベンダにはこれまで以上に高いプロジェクト管理能力が求められることになる。この影響は当然、発注側にも及ぶ。役割分担や要件のグレーゾーンの扱い、仕様変更の扱いなど、これまで発注側の「ごり押し」で通ってきた要求が、（良いか悪いかは別として）簡単には通らなくなってくる可能性が高い。発注側としても、この状況に対応するために、問題定義や要件の明確化およびステ
今さら聞けない RFPによる調達&提案ガイド(11) 機能要件の実現に必要な機能を定義する要件
RFPに記載すべき最も重要な要素であるシステム要件は機能要件と非機能要件から構成されています。前号と重複するところもありますが、非機能要件を作成する方法を解説するにあたって、機能要件と非機能要件についておさらいしておきましょう。 前号では機能要件について、「システムを利用して何をやりたいか」を説明したもので、「業務上の付加価値に直接的に関係するもの」だと述べました。例えば、「前日の商品別売上実績を翌日の9時までに見られるようにしてほしい」「従業員の残業時間を翌月の第1営業日までに集計してほしい」などが、機能要件に当たります。 対する今号のテーマである非機能要件とは「その機能をどのような品質で利用したいか」を説明したものであり、「想定される環境下でその機能を問題なく利用し続ける」ための要件となります。 各種標準化団体が非機能要件について定義しているので、以下に紹介しましょう。 非機能要件とは
要件定義 プロジェクト管理者の道具箱
■開始条件 ユーザ側で要求事項が整理されている事。 システム開発案件を受注し、契約が締結されている事。 ■要件定義の目的 業務をシステム化するときにユーザの要求をまとめる作業を要求定義という。その成果物を要求定義書という。 要求を実現するために、システム化の要件をまとめる作業を要件定義という。その成果物を要件定義書という。 要件定義は、システム化の範囲を明確にし、システム開発にかかる工数や費用を見積もる為にも行う。 ■要件定義の担当 要求定義、および要件定義はユーザ中心で行うべきである。 ユーザ側で関係部門の担当者を集めて、システム化の委員会を発足させ、要求事項の導出やとりまとめ、要件定義を行う。 開発者は情報システムに関する専門知識を提供し、ユーザの要件定義作業を支援する。 ■要件定義の方法 ユーザはシステム化したい事を明確に定義し、開発者に漏れなく伝えなければならない。 ユーザは自らの
システム開発 - 要件定義 -
要件定義の目的 要件定義とは、以下の点を整理し、矛盾がない事を確認し、利用者とシステム開発者が同じ認識を持つ事です。 ①．システム化の目的 ②．対象業務 ③．人、物、時間、場所を明記した業務の流れ ④．機能毎の要件 ⑤．業務が分岐する場合の条件 ⑥．利用制限 ⑦．外部設計のインプットとなるだけの項目の定義 ⑧．シナリオテスト作成のインプット (2011.07.16追記) (2011.03.06) 要件定義書の有効期間 要件定義書の有効期間について、様々な考え方があると思いますが、私はシステムが存在している期間は有効であるべきと考えます。 それは、要件定義書のコンテンツが要件定義書にしかないからです。外部設計書、内部設計書を作成してしまえば、システムが完成してしまえば 必要ないものではありません。外部設計書を作成中に機能数が変更になる場合でも、システムが稼働してからでも、要件定義書のコンテン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【リカイゼン】見積依頼・発注先探しのビジネスマッチングサイト
要件定義工程の進め方
もしも要件定義の無いシステム開発の担当になったら
システム要件定義の「システム的部分」のまとめ方の知恵 - ITマネジメントのノウハウ
IT企画/RFP作成/PMO支援コンサルティング | オージス総研