ユーザーが資料をくれないのは、ベンダーの責任です
連載目次 ユーザーが義務を果たすためにはベンダーの支援が必要？ 本連載は主としてITベンダー向けに書いており、取り上げる紛争事例もどちらかといえばベンダーに厳しい結果が出たものが多い。そのせいか読者の皆さまから寄せられる意見の中には「裁判所はユーザーの責任をどのように考えているのか、開発側に負担が寄り過ぎてはないか」といったものも散見される。 しかしもちろん、判決の中にはユーザーの協力義務を厳しく問うものも多く、必要な時期までに要件定義を行わないユーザーや、仕様の確定に必要な情報をタイムリーに提供しないユーザーにこそプロジェクト失敗の責任があるとするものも少なくない。裁判所が、特にユーザー寄りというわけではないというのが、数多くの判例を調査しての私の実感だ。 ただし、ここで考慮に入れなければならないのはユーザー企業のスキルと経験である。システム導入におけるユーザーが負うべき責任についての裁
要件定義書ってどんなふうに書くのですか？(´・ω・｀) - プログラムを書く上で、要件定義が大事だ！といわれるのですが、ではど... - Yahoo!知恵袋
要件定義書ってどんなふうに書くのですか？(´・ω・｀) プログラムを書く上で、要件定義が大事だ！といわれるのですが、ではどんな風に書けば具体的な要件定義となるかがわかりません(T_T) 検索で１つは見つけたのですが、 http://docs.google.com/viewer?a=v&q=cache:TIju4YTpeZUJ:sourceforge.jp/projects/witchpaper/docs/plan2/ja/1/plan2.ppt+%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9%E6%9B%B8+.txt&hl=ja&gl=jp&pid=bl&srcid=ADGEESiV-930FQ-ygI03AUjGryT1D0DMikWw3RKnVxPf-f2nKjVpcPj2lGBsotKGctuCX8SZ8OORpomFe_mvlk--Q__-jEtpu_Q
開発までの道のり | データウェアハウス自由帳
要件定義について 要件定義書は、どのようなシステムを構築するかを記したドキュメントです。 システムをどういうアーキテクチャにするか一つ一つ判断し決定するため、とても大事で難しいフェーズです。 クライアントと話し合いを重ねて、システムの全体を把握しなければなりません。 プロジェクトで要件定義が適切に行われていなかったために、数千万・数億円の赤字のプロジェクトになるなんてことも珍しくありませんので気をつけましょう。特にデータウェアハウスは大規模な案件が多く、技術屋さんのコストも高いので間違ったことをするとすぐ赤字になります。 以下に要件定義の中でも特に大事なプロセルについて紹介します。 ビジネス要件 ビジネス要件は、実際にユーザーがどういう形でどのような物が欲しいかという要求をまとめたものです。 ここを確定させておかないと、どのソースのどのデータを持ってくるかという判断ができなくなります。 ア
第1回 要件定義工程のITアーキテクト
ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は要件定義工程を対象にします。要件定義工程では、主に次の5つの成果物を作成します。 （1）Vision Document （2）利害関係者マップ （3）概念機能モデル図・概念データモデル図 （4）非機能要件定義書／品質特性シナリオ （5）グランドデザイン ポイントは「ビジネス視点」と「システム視点」の両方を持つこと。技術者は総じて「How（どのようにつくるか）」への思考（＝システム視点）が先行しがちです。これでは「間違ったものを正しくつくる」ことになってしまいます。それを避けるには、「Why（なぜつくるのか）」と「What（なにをつくるのか）」を明らかにすること、つまり、ビジネス視点を持つことです。 ITアーキテクトは、アーキテクチャー設計に対する「説明責任」が伴います。
非機能要件定義するときに参考にするとよい資料
0.前置き 非機能要件定義って難しいなって思う今日この頃です。定義をする順番、業務要件定義との兼ね合い、参考にする資料の乱立などなど。 将来に備えて、今まで学んだことを少しまとめておこうと思います。今回は「参考にするとよい資料」です。後半では非機能要件定義をするうえで押さえておくべき各領域の知識を補える書籍を紹介します。 もともと2012年に書いたブログですが。2018年1月13日に見直しと大幅な加筆をしました。 1.「参考にすると良い資料」の紹介 非機能要件全般を押さえるために適している資料をまずは紹介します。特に1つめの非機能要求グレードは必ず押さえておくべき良い資料です。 非機能要求グレード 情報処理推進機構（IPA）にて公開されている資料です。URLは以下を参照してください。 非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開 顧客と一緒に、非機能要件をにぎりま
プロジェクト運営の難所はこうして乗り越える
関連キーワード RFP | IFRS | ERP | Excel | PMO（プロジェクトマネジメントオフィス） 第3回「経営と業務部門の協力を引き出すプロジェクト運営術」では、経営がガバナンスを効かせるための「ステアリングコミッティ」、ならびにIT部門、業務部門の連携を円滑に進めるための「協同プロジェクト体制」について紹介した。今回は、IT部門・業務部門の連携タスク（要件定義、ベンダ選定、受け入れテスト、システム・業務移行など）を乗り切るためのプロジェクト運営術について考察する。 本稿では、要件定義、ベンダ選定を例として、まず始めに推進上の難所を整理した上で、それらをうまく乗り切るための運営術を具体的に述べていく。 連載インデックス 【第1回】実は知られていない「PMO」の基本的な役割 【第2回】事例で見る、プロジェクト別PMO使いこなし 【第3回】経営と業務部門の協力を引き出すプロジェ
価値ある要件定義の成果物|中堅企業・中小企業における パッケージ導入の手引き
【ページ構成】 ■ 要件定義書の失敗事例と原因 ■ 目的達成へと導く「要件定義書」 ■ 価値ある成果物を創るための条件 ■ 要件定義作業でのベンダ力量のチェックと判断 情報システムの検討を意味するパッケージ導入（クラウド導入）プロジェクトの失敗の多くは、要件定義書（FIT&GAP/要求定義含む）の成果物に起因しています。その原因は「対象範囲のカバー漏れ、具体性の欠如、曖昧表現、スキル不足、ストーリの無いまとめ方」など多岐に渡っています。また、ユーザとベンダ共に企業環境の変化に対応すべき情報システムの活用方法を提示できない成果物の内容にもあります。システム要件が経営方針、取引条件、業務効率、管理内容及び情報技術などが関連しあって決まるという中堅・中小企業の経営ニーズへの基本的な理解不足です。 失敗した要件定義書の成果物事例を通して、どこに問題点と原因があるかを明らかにします。つぎに、あるべき
非機能要件を見極める【前編】：ヒアリングでは不十分
「要件定義を難しくする」とクローズアップされてきたのが“非機能要件”の存在である。非機能要件とは，性能や信頼性，拡張性，セキュリティなど，機能要件以外のもの全般を指す。これらはユーザーへのヒアリングからだけでは洗い出しにくい。漏れがあると，稼働後のトラブルの種になる。こうした事態を未然に防ぐ，非機能要件の見極め方を探る。 旅行代理店のアールアンドシーツアーズは，今年10月末に予定しているホテル予約システムの稼働に向けて，今，開発の真っ最中だ。このシステムは，仕入れた航空券の在庫や宿泊の空室情報を管理するホストに，2次代理店からインターネット経由で送信されてくる予約データを受け渡すもの。 開発を主導する大平雅義システム部長は，「機能要件はほぼ固まったが，性能に関する非機能要件が懸案として残っていて悩ましい」と語る。 予約データはインターネットを介してやり取りされる。そこに含まれる顧客情報は暗
要件定義書の作成
Webサイト制作における要件定義書は、クライアントの要望をもとに制作するWebサイトの仕様をまとめたものです。具体的には、各画面遷移や管理画面イメージ、サーバー情報、プログラム開発内容、データベース、セキュリティなどのシステムに関する内容が含まれています。通常、企画提案書で方向性が固まった段階で、要件定義書の作成に取り掛かります。より正確な見積書を作成するためにも必要なものです。 ただし、プログラムやデータベースなどのシステム要素が複雑でない簡単なWebサイトの場合は、企画提案書をブラッシュアップさせて要件定義書の代わりにすることも多いのが実情です。 要件定義書の具体的な作成方法 ヒアリングした内容と企画提案書に盛り込んだ内容をさらに具体的なものにするために整理していきます。企画提案書の段階では制作者側の案も含まれているので、要件定義書にはクライアントが実施したいという確認が取れた部分だけ
第1回 要件定義作業を容易にするシステム化企画書の意義 | IT Leaders
「ユーザー企業が必要としているシステムはどのようなものか」を定義する要求仕様書。実際に作成する上では、まずはきちんとしたシステム化企画書をまとめることが肝要となる。システムに求める機能はUML（統一モデリング言語）で定めるユースケース図を用いると分かりやすい。 要求仕様を取り巻く議論が活発だ。書店には要求仕様を冠とする書籍が立ち並ぶ。どれを手に取ってもなるほどという内容だが、これらの本に1つだけ欠けているものがある。それは、要求仕様を書く側の技術力について言及されていないことだ。 それだから本を読めば要求仕様書が書けると勘違いしてしまう。要求仕様書を書くには深い業務知識と経験が必要である。さらにITについても造詣が求められる。ことはそう簡単ではない。 しかしながら要求を仕様化する方法や手段は「要求仕様技術」として少しずつ確立されつつある。技術であれば習得することができる。 この連載では、シ
要件定義書って何書くの？(補足) – エフエス企画室
「要件定義書」とは、要件定義での決定事項をまとめ上げたシステム仕様書です。パソコンソフトに添付されているマニュアル本と同じような位置づけで、システムハウスが持ち込んだ書式に沿って記述・構成されます。 作成はシステムハウスが行ない、納品物件として検収の対象となります。検収が済めば、システムはユーザーに引き渡され、以降、自分達の責務で運用することになります。 いつまでも開発メンバーが近くにいて、サポートを継続してくれるとは限りません。システムの構成が誰でも理解できるよう、（仮にサポート契約を結んだとしても）引継ぎ資料としての役割も与えなければなりません。使える要件定義書として、最低限必要と思える情報を記しておきます。参考まで。 要件定義書の最小構成 概要 システム導入の目的 時間の経過とともに本来の目的がぼやけ、習慣化されたオペレーションだけが後世に残されていくなんて寂しいですよね？要件定義書
RFP/要件定義/要求仕様---違いは明確？
「RFP（提案依頼書）」「要件定義書」「要求仕様書」──。この三つの言葉を見て、その違いを明確に説明できるだろうか。筆者は、日経SYSTEMSという雑誌を担当して日々システム開発現場における開発手法や実務情報を記事としてまとめているが、この三つの用語には、定義に曖昧な部分があったり、違いが分かりにくい面があったりすると感じている。 三つの用語が示すドキュメントはいずれも、ユーザーがどんなシステムを開発したいのかを記述したものだ。実は、筆者がこれまで普通に使っていた用語は、三つのうちRFPと要件定義書の二つ。これらについては、それなりに違いを理解しているつもりである。対して、要求仕様書という用語はあまり使っていなかった。 ざっくりいえば、RFPはシステム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出すためのもの。一方の要件定義書は
要件定義 プロジェクト管理者の道具箱
■開始条件 ユーザ側で要求事項が整理されている事。 システム開発案件を受注し、契約が締結されている事。 ■要件定義の目的 業務をシステム化するときにユーザの要求をまとめる作業を要求定義という。その成果物を要求定義書という。 要求を実現するために、システム化の要件をまとめる作業を要件定義という。その成果物を要件定義書という。 要件定義は、システム化の範囲を明確にし、システム開発にかかる工数や費用を見積もる為にも行う。 ■要件定義の担当 要求定義、および要件定義はユーザ中心で行うべきである。 ユーザ側で関係部門の担当者を集めて、システム化の委員会を発足させ、要求事項の導出やとりまとめ、要件定義を行う。 開発者は情報システムに関する専門知識を提供し、ユーザの要件定義作業を支援する。 ■要件定義の方法 ユーザはシステム化したい事を明確に定義し、開発者に漏れなく伝えなければならない。 ユーザは自らの
要件定義書（要求仕様書）の書き方・例 書式・様式・フォーマット 雛形（ひな形）・見本・サンプル テンプレート（無料ダウンロード）01（プログラム設計書などの前提）（ワード Word）
要件定義書（要求仕様書）の書き方・例 書式・様式・フォーマット 雛形（ひな形）・見本・サンプル テンプレート（無料ダウンロード）01（プログラム設計書などの前提）（ワード Word） 要件定義書（要求仕様書）のテンプレート 本テンプレートは、エクセルで作成した要件定義書（要求仕様書）のフォーマットです。 システム開発（ここではソフトウェアの開発の意味です）に必須の仕様書には基本設計書、詳細設計書、プログラム設計書などというものがあります。 現在は、外部設計書、内部設計書という言葉の方がよく用いられているようです。これは要件定義書の作成を顧客ではなくシステム開発側が行うようになってきたことと関係があるのかもしれません。 しかし、これらの仕様書の前提として欠かせないのが顧客の業務内容、ニーズ、要求・要望をきちんと把握することです。 といっても、ただ顧客の言うとおりのシステムを開発してもダメです
要件定義書の一般的な項目 - 技術情報Wiki
→要件定義・基本設計 →ドキュメント作成 ※ここに載っている項目をすべて網羅した要件定義書というのはあまり見たことがない。客の要望に応じて機能要件のみ文書化したりすることもある。
要件定義の勘どころ
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
「要件定義書のアウトライン作成」完全マニュアル
他の文書と同様、要件定義書はまず文書全体のアウトライン（骨格、構成）をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し＝中見出し＝小見出し（章＝節＝項）の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回（第3回「分かりやすい提案書はアウトラインが美しい」）紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要／システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ
鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ポイント５秒
＠IT自分戦略研究所