システム企画の用語
全72語。
業務プロセスを根本から見直して作り直すこと。関連する業務ごとに分類し、優先順位を付けて進める。
システム開発の全体像と共通フレームの企画プロセス
データの発生源・処理・蓄積場所を、データの流れを示す矢印でつないで表す図。
⚠ UMLの説明として出されるひっかけ。「データの流れ」「発生・吸収・蓄積」ならDFD。
要件定義と機能要件・非機能要件
対象をエンティティ（実体）とその属性、エンティティ間の関連で表す、データ中心の図。
⚠ UMLの説明として出されるひっかけ。「エンティティ」「データ中心アプローチ」ならE-R図。
要件定義と機能要件・非機能要件
UMLなど、オブジェクト指向技術の標準を策定している国際的な標準化団体。
要件定義と機能要件・非機能要件
調達の最初に、システム化の目的や業務内容を示して、ベンダに技術や製品の情報を出してもらう依頼書。
⚠ RFP と取り違えやすい。「情報提供」なら RFI、「提案書の提出」なら RFP。
システム調達の流れと RFP・契約
調達対象や調達条件、要件を示して、ベンダに提案書を出してもらう依頼書。
⚠ RFI は情報を集める段階で、RFP はその後に提案を求める段階。
システム調達の流れと RFP・契約
導入から廃棄まで、システムを持つことでかかる費用の総額（イニシャル＋ランニング）。
⚠ 導入費だけを指す言葉ではない。
情報化投資のコストと採算の計算
OMGが標準化した、オブジェクト指向開発で使うモデリング言語で、目的に応じた複数の図法を標準化された記法で描き分ける。
⚠ E-R図（データ中心で、エンティティと関連を描く）、DFD（データの流れを矢印で描く）、IDL（インタフェース記述言語）、SQL（DB操作言語）、XML（マークアップ言語）と区別する。
要件定義と機能要件・非機能要件
システムの企画・開発・導入の時点で一度だけ発生する費用。
⚠ ランニングコストと取り違えやすい。導入が終わればもう払わないなら、イニシャルコスト。
情報化投資のコストと採算の計算
実際に手元に出入りするお金の流れ。投資の回収額は、利益に減価償却費を足した額になる。
⚠ 会計上の利益とは一致しない。
情報化投資のコストと採算の計算
業務モデルや主要なDB・サーバ・ネットワークの構成概要、体制、費用と投資効果、スケジュールを決める作業。
⚠ テスト計画や運用マニュアルの具体化は後の工程なので含まれない。
システム開発の全体像と共通フレームの企画プロセス
経営上のニーズや情報技術の動向を調べて、将来必要になる最上位の業務機能と業務組織（業務の新しい全体像）を描く作業。
⚠ システム化計画の立案と混同しやすい。構想は「目指す全体像」、計画は「体制・費用・投資効果・構成概要」。
システム開発の全体像と共通フレームの企画プロセス
定性的な評価を段階ごとの点数に置き換え、重み付きの合計を満点で割って達成度を出す方法。
⚠ 重み付け総合評価法と計算は似ているが、満点で割って％にする点が違う。
情報システム案の評価方法と重み付け計算
ソフトウェアを企画してから要件定義・開発・運用・保守を経て廃棄するまでの一生。
システム開発の全体像と共通フレームの企画プロセス
実際に働いた時間や使った資材に応じて代金を払う契約。
⚠ 「労務に対する対価」と書いてあれば T&M。「成果物」なら一括請負。
システム調達の流れと RFP・契約
新しい事業やプロジェクトの計画が実行可能かどうかを調べて検証すること。
⚠ ブレーンストーミング（批判せずにアイデアを出す）やロールプレイ（役割を演じる）と区別する。
システム開発の全体像と共通フレームの企画プロセス
個人情報の漏えいや目的外利用を防ぐ機能を、企画・設計の段階からシステムに組み込んでおく考え方。
⚠ プライバシーマーク（個人情報を適切に扱う事業者への認定マーク）と混同しやすい。設計の考え方か、認定制度かで見分ける。
要件定義と機能要件・非機能要件
個人情報を適切に取り扱っている事業者に対して付与される認定マーク。
⚠ プライバシーバイデザインは設計の考え方で、こちらは事業者を認定する制度。
要件定義と機能要件・非機能要件
システムを使い続ける間、継続して発生する費用（保守費・回線費・リース料など）。
⚠ イニシャルコストと取り違えやすい。「保守」「運用」「月額」はこちら。
情報化投資のコストと採算の計算
機器を購入せず、リース会社から長期で借りて月額料金を払う契約。
⚠ 購入（資産になり、イニシャルコスト）とは違い、リース料は毎月のランニングコスト。
情報化投資のコストと採算の計算
購入価格に掛けて月額リース料を出すための率。
⚠ 年率か月率かを確かめる。月額料率2％なら、300万円の機器は月6万円。
情報化投資のコストと採算の計算
案を実行したときに失敗や損失につながるおそれのある要素。
⚠ 効用と対になる評価軸。正しい評価方針は「効用とリスクの両方を見る」。
情報システム案の評価方法と重み付け計算
作業を社外に任せるときに支払う費用。
情報化投資のコストと採算の計算
決めた価格で、期日までに作った成果物に対して代金を払う契約。
⚠ T&M は労務（時間）に払い、実費償還はかかったコストにフィーを上乗せして払う。
システム調達の流れと RFP・契約
システムの起動・終了や監視などを計画的に行い、業務が円滑に回っていることを確かめるプロセス。
⚠ 保守と混同しやすい。日々動かすのが運用、修正依頼を分析して直すのが保守。
システム開発の全体像と共通フレームの企画プロセス
顧客情報や商談の記録を共有し、営業活動を効率化するシステム。
⚠ 顧客との関係全体を管理する CRM と混同しやすい。SFA は営業部門の活動の効率化が中心。
情報化投資のコストと採算の計算
システムが止まらずに使い続けられる度合い。
要件定義と機能要件・非機能要件
システム要件・ソフトウェア要件の定義、方式設計、製造、テスト、移行など、実際にシステムを作り上げるプロセス。
⚠ 「システムの機能・方式・ソフトウェア」が主語なら開発。
システム開発の全体像と共通フレームの企画プロセス
経営・事業の目的を達成するために、システム化の方針と実施計画を決めるプロセス。
⚠ 要件定義プロセスと混同しやすい。「経営上のニーズ・方針・計画」なら企画、「業務手順・入出力・利害関係者の合意」なら要件定義。
システム開発の全体像と共通フレームの企画プロセス
システムが何をするかを表す要件で、機能の実現範囲、機能間のデータの流れ、他システムとのインタフェースなどを指す。
⚠ 非機能要件と対になる。「何をするか」が機能要件、「どれくらいの品質でやるか」が非機能要件。他システムとのインタフェースは機能要件に入る。
要件定義と機能要件・非機能要件
システムが「何をできるか」という要件。
⚠ 非機能要件は、性能や信頼性など「どれくらいの質でできるか」という要件。
システム調達の流れと RFP・契約
提案書やベンダの能力を、事前に決めた評価基準で比べて調達先を決める段階。
⚠ 契約の締結は、選んだ後に役割や責任分担を文書で確認する次の段階。
システム調達の流れと RFP・契約
システム開発の作業と用語を統一し、発注者と受注者が共通の言葉で話せるようにするための日本のガイドライン。
システム開発の全体像と共通フレームの企画プロセス
対象の業務の流れや情報のやり取りを図などで表したもの。企画プロセス（計画の立案）で作る。
⚠ 要件定義で決める詳しい業務手順と区別する。
システム開発の全体像と共通フレームの企画プロセス
新しい業務の在り方、業務手順、入出力情報、組織・責任・権限、業務上の制約などをまとめた要件。
⚠ システム機能の範囲を扱う機能要件や、システム基盤の品質を扱う非機能要件と区別する。
要件定義と機能要件・非機能要件
発注元と調達先が、役割や責任分担などを文書で確認し合う、調達の最後の段階。
システム調達の流れと RFP・契約
成果物が要件や仕様どおりに正しく作られているかを確かめるプロセス。
⚠ 妥当性確認と混同しやすい。仕様に照らすのが検証、利用者の意図に照らすのが妥当性確認。
システム開発の全体像と共通フレームの企画プロセス
設備の購入費を、使用する年数にわたって分割して計上する費用で、実際にはお金が出ていかない。
⚠ 維持費・支払利息・製造原価と違い、回収額を求めるときに利益へ足し戻す項目。
情報化投資のコストと採算の計算
案を実行したときに得られる効果や便益のこと。
⚠ コストとは別物。効用が案ごとに違うなら、コストが最小というだけでは選べない。
情報システム案の評価方法と重み付け計算
当初のリース期間が終わった後、ずっと安い料金で借り続ける契約。
⚠ 料金が切り替わるのは契約の節目なので、グラフは階段状になり、なだらかには減らない。
情報化投資のコストと採算の計算
予定価格以内で、最も安い価格を出した者を落札者にする方式。
⚠ 「最高得点」なら総合評価落札方式、「最低価格」ならこちら。
システム調達の流れと RFP・契約
得られる利益が、かかる費用を上回り、投資が割に合うこと。
⚠ 利益と費用が等しい場合は「採算がとれる」に含まないことが多い（「未満」で問われる）。
情報化投資のコストと採算の計算
技術・予算・体制の面から、その案を本当に実行できるかどうか。
⚠ 投資対効果とは別の観点。どちらも見たうえで、さらに新たな問題点の発生も評価する。
情報システム案の評価方法と重み付け計算
作業にかかったコストを払い戻し、さらに固定フィーやインセンティブを上乗せして払う契約。
⚠ 「償還」という言葉があれば実費償還。一括請負は成果物に定額で払う。
システム調達の流れと RFP・契約
評価項目の重要度を表す倍率。
⚠ 評価点（各案の出来ばえ）とは別の数値。掛け忘れが典型的なミス。
情報システム案の評価方法と重み付け計算
評価項目ごとの点数に重みを掛けて合計し、総合点で案を比べる方法。
⚠ スコアリングモデルは結果を％（達成度）で出すが、こちらは総合点の大小で案を選ぶ。
情報システム案の評価方法と重み付け計算
どの業務を、どんな目的でIT化するかをまとめた計画案。
⚠ 手段（ハードウェア構成など）より先に「何をするか」を決める。
情報システム案の評価方法と重み付け計算
1人が1か月働く作業量を1とする単位で、人数 × 月数で求める。
⚠ 人数そのものと混同しない。4人で3か月なら12人月。
情報化投資のコストと採算の計算
入札をせず、発注者が契約相手を選んで決める契約方法。
⚠ 「入札を経ずに」と書いてあれば随意契約で、総合評価落札方式ではない。
システム調達の流れと RFP・契約
予算・期限・法規制・既存環境など、システムが守らなければならない前提や制限。
要件定義と機能要件・非機能要件
価格と提案内容を点数にして、合計点が最も高い提案を落札者にする調達方式。
⚠ 最低価格落札方式は価格だけで決める。随意契約は入札をしない。
システム調達の流れと RFP・契約
入札で、価格点と技術点を合計した総合点が最も高い業者を落札者にする方式。
⚠ 価格だけで決める最低価格落札方式とは違う。予定価格を超えた入札は対象外。
情報システム案の評価方法と重み付け計算
成果物が利用者の視点から見て、意図した用途に合う正しいものになっているかを確かめるプロセス。
⚠ 検証と区別する。「利用者の視点」「意図された」が出たら妥当性確認。
システム開発の全体像と共通フレームの企画プロセス
発注側の注文書（申込み）に対して、受注側が請書（承諾）を返すと契約が成立する。
⚠ RFI・RFP・提案書は契約前のやり取りに使う書類で、請書を返しても契約は成立しない。
システム調達の流れと RFP・契約
「改善された」「変わらない」のように言葉で表す評価。
⚠ 定量的評価は数値で表す評価。定性的な項目も、点数を付ければ評価に使える（除外しない）。
情報システム案の評価方法と重み付け計算
金額・時間・件数などの数値で表す評価。
⚠ 定性的評価と対になる言葉。
情報システム案の評価方法と重み付け計算
RFP に応えてベンダが出す書類で、実現方法・費用・体制などが書かれている。
⚠ RFP は発注側が出し、提案書はベンダが出す。どちらも契約書類ではない。
システム調達の流れと RFP・契約
投資した金額を、毎年の利益（回収額）で取り戻すまでにかかる年数。
⚠ 必要年間利益は投資額 ÷ 回収期間。投資額の比だけで判断しない。
情報化投資のコストと採算の計算
システムにかける開発・運用・保守の費用に対して得られる効果。システム化計画で明確にする。
システム開発の全体像と共通フレームの企画プロセス
かけた費用に対してどれだけの効果が得られるかの比率。
⚠ 実現可能性（そもそも実行できるか）とは別の観点。
情報システム案の評価方法と重み付け計算
IPAがまとめた非機能要件の整理表で、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境の6分類で要求の水準を決めるもの。
要件定義と機能要件・非機能要件
機能以外の要件で、可用性・性能・拡張性・運用性・保守性・移行性・セキュリティなどの品質要件と、技術要件・運用要件を指す。
⚠ 機能要件（機能範囲・データの流れ・インタフェース）と混同させる選択肢が定番。「〜性」「品質」「技術要件」「開発基準」なら非機能要件。
要件定義と機能要件・非機能要件
性能・信頼性・セキュリティ・運用性など、機能以外の品質に関する要件。
⚠ 機能要件は「何をするか」。RFP には両方を載せる。
システム調達の流れと RFP・契約
各評価項目で何点を付けるかの物差し。
⚠ システムの提案者ではなく、評価する側（発注者）が決める。
情報システム案の評価方法と重み付け計算
提案をどの項目で何点として評価するかのルールで、公正さを保つため提案を受ける前に決めておく。
⚠ 選定の後や、特定のベンダに合わせて決めるのは不公正。
システム調達の流れと RFP・契約
案を比べるときの観点（省力化、期間短縮など）。
情報システム案の評価方法と重み付け計算
修正依頼の内容と影響を分析し、システムを業務や環境に合うように変更・維持するプロセス。
⚠ 運用（日々の稼働と監視）と区別する。
システム開発の全体像と共通フレームの企画プロセス
機器やソフトウェアを正常に保つために、継続して支払う費用。
⚠ 取得費用の一部ではなく、毎年かかるランニングコスト。
情報化投資のコストと採算の計算
全項目が目標どおりだった場合の満点に対する、実績点の割合（％）。
⚠ 満点は「重みの合計×最高点」。4段階評価なら最高点は3。
情報システム案の評価方法と重み付け計算
発注者があらかじめ決めておく落札価格の上限で、これを超えた入札は評価対象から外れる。
システム調達の流れと RFP・契約
発注者があらかじめ決めておく、契約金額の上限の目安。
⚠ これを超えた入札は、技術点が高くても評価されない。
情報システム案の評価方法と重み付け計算
矛盾した要件や実現できない要件などの解決方法を利害関係者に説明し、合意を得る活動。
⚠ 要件の評価との違いは、関係者に説明して承認をもらう段階かどうか。
要件定義と機能要件・非機能要件
利害関係者から要件を漏れなく引き出し、制約条件や運用シナリオを明らかにする活動。
⚠ 要件の評価（矛盾・曖昧さをなくして整理する）と取り違えやすい。「引き出す」なら識別、「整理する」なら評価。
要件定義と機能要件・非機能要件
引き出した要件の矛盾や曖昧な点をなくし、一貫性のある要件の集合に整理する活動。
⚠ 要件の識別（引き出す）や要件の合意（説明して合意を得る）と区別する。
要件定義と機能要件・非機能要件
新しい業務の在り方や手順、入出力情報、ルールなどの業務要件を明確にし、利害関係者間で合意するプロセス。
⚠ 企画（なぜ作るか・方針）や開発のシステム要件定義（システムの機能・方式）と区別する。
システム開発の全体像と共通フレームの企画プロセス
利害関係者のニーズ・要望・制約条件を明らかにし、新しい業務とシステムに必要なことを決めて合意する工程。
⚠ 企画プロセス（システム化の方針・計画を立てる）やシステム開発プロセス（方式設計で実現方法を決める）と混同しやすい。「合意」「関係者」「制約条件」は要件定義、「方針」は企画、「設計」は開発と見分ける。
要件定義と機能要件・非機能要件
利用者・発注者・運用者など、システムに関わり合いを持つ人や組織。
要件定義と機能要件・非機能要件