ER図＝実体と実体同士の関係性を表現した図 ER図（実体関連図）とは、「実体＝エンティティ」と「実体同士の関係性」を表現した図である。実体とは、独立した一意（1つしか意味を持たない）の対象物のことを指す。たとえば、顧客や注文などが実体に該当する。リレーショナルデータベース（RDB）の設計では、ER図の作成が必須となる。...

業務流れ図には、データを処理する流れが示される。 要件定義では、業務を処理する組織・ユーザー・手段・手順を明確にすることが求められる。そこでまず使われるのが業務流れ図だ。最も基本的な業務流れ図であるフローチャートには、通常、データを処理する流れが示される。また、アクティビティ図は、スイムレーンによって組織横断的な業務を...

非機能要件とは、必要とする機能以外の要件である システム開発における要件定義では、機能要件と非機能要件を決める必要がある。非機能要件とは、システムの性能や拡張性や可用性、あるいはセキュリティなど、必要とする機能以外の要件である。非機能要件を満たすことで、構築したシステムが、要望通りの処理性能を発揮したり、障害発生時に復...

ITベンダーは「完成責任」と「契約不適合責任」を負う。 プロジェクト開始前に見積り金額を提出する請負契約では、システム開発の責任とリスクを「受託者＝ITベンダー」が負う。システム開発の責任のうち、特に重要とされているのが「完成責任」と「契約不適合責任」である。完成責任とはITベンダーが完成した情報システムを納品する責任...

赤字プロジェクトが発生する原因＝見積りミスと仕様変更 赤字プロジェクトとは、システム開発にかかる費用がITベンダーの見積もりを超えた状態である。赤字プロジェクトが発生する原因は大きく2つ。1つは見積りのミス、もう1つは仕様変更である。見積りのミスの原因は、見積りが難しい状況で無理に見積ることである。すなわち、規模・工数...

FP法＝機能要件などをFPに落とし込んで工数と費用を見積る手法 FP（ファンクションポイント）法とは、機能要件とその他の要件を分類し、それぞれに係数をかけ合わせて、それらを積算することでシステム開発の予算を見積る手法である。FP法では、ユーザーから見たソフトウェアの持つべき機能の数とその処理内容の複雑さなどをファンクシ...

ITベンダーだけでなく、ユーザー企業のスタッフも参加する。 開発プロジェクトの体制には通常、ITベンダーだけでなく、ユーザー企業のスタッフも数名参加する。参加するメンバーは、情報システム部門のスタッフのほか、システムを実際に利用するユーザー部門のスタッフであることが多い。これらのメンバーは実は、RPFの作成、オリエンの...

オリエン＝システムに関する要望を説明して提案を募集する場 オリエン（オリエンテーション）とは、ユーザー企業がシステムに関する要望を説明することで、ITベンダーからの提案を募集する場である。オリエンテーションでは通常、あらかじめ作成しておいた「RFP（Request for proposal）＝提案依頼書」をユーザー企業...

受託開発系の収益源＝開発費、運用管理費、インフラ費用 受託開発系ITベンダーの収益源は、大きく分けて3つある。すなわち、情報システムの開発費、情報システムの運用管理費、ハードウェア・インフラの販売・構築・運用費だ。このうち、情報システムの開発では業務の多くを下請け企業に投げているため、費用に占める外注費の割合が5割近く...

As-IsとTo-Be＝現状と理想を比較し、理想に近づくアプローチ As-IsとTo-Beは、現状と理想を比較し、理想に近づくアプローチを考える方法論である。現行システムを「As-Isモデル」、新規システムを「To-Beモデル」と呼ぶなど、IT業界でよく使われている。As-IsとTo-Beでは、現状の業務プロセス・デー...