Web教材一覧法規・基準

共通フレーム

キーワード

共通フレーム、SLCP-JCF、ISO/IEC 12207、JIS X 0169、プロセス、アクティビティ、タスク、事業、業務、システム、ソフトウェア、合意プロセス、テクニカルプロセス、企画プロセス、要件定義プロセス、システム開発プロセス

関連ページ

本ページは、「共通フレーム2013」に準拠しています。その主要部分である各プロセスの詳細は、 IPA「第3 部 共通フレームとガイダンス」 https://www.ipa.go.jp/files/000062659.pdfを参照してください。
 また、付表などはIPA「SEC BOOKS 共通フレーム」(https://www.ipa.go.jp/sec/publish/tn12-006.html)からダウンロードできます。


共通フレームの位置づけ

共通フレームの目的

共通フレームの目的は、ソフトウェアを中心としたシステムの「ライフサイクル全般」にわたって「共通の枠組み」「共通の物差し」を使うことにより「取引の明確化」を実現することにあります。

共通フレームの策定、推進をしているIPAは、次のように説明しています。
「共通フレーム」は、ソフトウェアや情報処理システムの開発者(受注者)、それらを利用したサービス事業者(発注者)が、言葉の意味(範囲)の解釈の違いによるトラブルを予防する(誤解を招かぬようにする)ため "同じ言葉を話す" ことができるよう共通の枠組みを提供し、ソフトウェアの構想から開発、運用、保守、廃棄にいたるまでのライフサイクルを通して必要な作業内容を包括的に定めたものです。

国際規格との関係

共通フレームは、英語ではSLCP-JCF(Software Life Cycle Process-Japan Common Frame)としています。SLCPはISOでの作業委員会名称であり、その作業による国際規格に適合して、日本版の共通フレームとしたという意味です。
 ISOによる国際規格(ISO/IEC 12207)その完全翻訳であるJIS X 0160は、環境の変化に伴い改訂しています。共通フレームは規格の最新版をベースにして、日本での環境で重視すべき事項を加えています。

共通フレームの性格(誤解されやいこと)


共通フレームでの概念・用語

事業、業務、システム、ソフトウェア

共通フレームでは、対象を事業>業務>システム>ソフトウェアに階層化しています。これは、責任の明確化でもあります。

事業
事業とは、企業経営のことです。経営戦略策定は企業により異なるので、共通フレームでは経営戦略は与件としていますが、事業達成すなわち経営戦略の策定や実現の観点から、開発するシステムへの要件、システムの評価をすることにしています。
この「事業」の部分(一部「業務」も含む)を超上流工程といいます(参照: 「超上流から攻めるIT化の原理原則17ヶ条」
業務
事業は販売業務、生産業務などからなっています。また、販売業務を受注業務、在庫管理業務のように細分化して定義することもできます。
システム
共通フレームでは、「システム」と「ソフトウェア」を明確に区分しています。
業務は、人による活動と、ITを利用した活動にわかれます。後者をシステムといいます。システムはソフトウェア、ハードウェア、ネットワーク、入力・出力する人間などから構成されます。
システム要件定義とは、業務の観点から開発すべき情報システムの機能や機能、信頼性などについて決定することです。応答時間の目標値の決定などもこれに含まれます。これらが適切に実現しているかどうかは、システストで確認されます。
システム方式設計とは、システム要件を実現するために必要なハードウェアやソフトウェア構成を明確にすることです。汎用コンピュータを用いるのかクラウドコンピューティングで実現するのか、独自仕様で開発するのかERPパッケージを用いるのかなどの基本的な方式を決定します。
ソフトウェア
ソフトウェアはシステムを構成する一部ですが、情報システムをコンピュータに実装する工程です。大雑把には「システム」が外部設計、「ソフトウェア」が内部設計だといえます。
ソフトウェア要件定義とは、システム要件をプログラムやデータベースのレベルにブレークダウンしたものであり、それが適切に実現しているかは結合テストで確認されます。
ソフトウェア方式決定とは、具体的なプログラミング言語やデータベースの選定、システム開発技法の選定などです。
ソフトウェア詳細設計とは、プログラミングのアルゴリズム、データベースでのクラス図、画面や帳票のデザイン、プログラム間のデータ受渡しなどを決定することです。この結果に基づいてプログラムのコーディングが行われます。

システム開発のライフサイクル

個々の情報システムの開発が計画されてから、実施にいたるまでの工程をシステム開発のライフサイクルといいます。

伝統的なシステム開発のライフサイクル

1990年代頃までは、システムとソフトウェアを明確に分離せず、
  要件分析→外部設計→内部設計→プログラミング→テスト
  └─ 上流工程 ─┘ └──── 下流工程 ────┘

としていました。

要件定義
まず、IT全体計画からの要求、利用部門からの要求などを分析して、対象とする情報システムの範囲を明確にします。そして、その情報システムがもつべき機能を明確にするプロセスです。このプロセスは、主に発注者の任務です。
 要件定義は、システム開発の最初のプロセスです。これが不適切だと、開発した情報システムも不適切なものになります。また、要件定義が不適切なことが、後のプロセスで発見されると、手戻りが発生して、費用や納期に大きな影響を与えます。
注:「要求定義」と「要件定義」
  要求定義:利用者がシステムに要求する事項の内容を明確にすること
  要件定義:システム構築にあたって、システムにどの機能を取り込むかを明確にすること
 厳密には、要求定義→要求分析→要件定義のプロセスになります(参照:「要求、要件、機能」)。
外部設計(概要設計)
ここでの「外部」とは、コンピュータから見た外部のことです。開発すべき情報システムの仕様を、関係者に業務の表現を用いて記述した設計です。このプロセスでは、発注者と開発者(システムアナリスト)が協力します。
 要件定義で示された要件を、システム開発の観点から分析して(要件分析という)、どのように情報システムに取り込むかを検討し、その結果を発注者と開発者が合意することになります。ここまでの範囲を基本設計あるいは上流工程といいます。
内部設計(詳細設計)
内部設計とは、外部設計の内容をコンピュータに実装するための設計で、主にプログラマ向けに作成されます。システムの分割、プログラムのロジック、データベースの構成などを示します。内部設計、プログラミング、テストの前半は、下流工程といいます。主に開発者(システムエンジニア)の任務になります。
プログラミング
内部設計に基づいて、実際にコンピュータ上に実現するプロセスです。慣習的にプログラミングといいますが、データベースの作成やハードウェアの設置なども含みます。大部分は開発者(プログラマ)の任務ですが、データの整備など利用者が行う業務もあります。
テスト
完成した情報システムが、正確な処理をするか、外部設計で合意した機能を実現しているかをテストします。個々のプログラム単体でのテストは開発者が中心となり、システム全体のテストは両者が協力して行います。最後に検収テスト(運用テスト)を行い、それにパスしたら利用者に引き継がれます。この間に、発注者は利用者への操作方法の説明や訓練をしておく必要があります。

共通フレームでのシステム開発のライフサイクル

共通フレームでは、システム開発の順序を規定するものではありませんが、テクニカルプロセスでは、この体系に沿った記述をしています。

別の角度から共通フレームの体系を時間的推移として図示すると次のようになります。

プロセス、アクティビティ、タスク、注記

共通フレームでは、ISO/IEC 12207(JIS X 0160)に従い、システム開発作業を、
  プロセス>アクティビティ>タスク
の階層で体系化し定義しています。最下位のタスクは5階層になります。

  1 合意プロセス
  2 テクニカルプロセス        ──── プロセス群(大区分)
   2.1 企画プロセス         ──── プロセス群(中区分)
    2.1.1 システム化構想の立案プロセス ─── プロセス
     2.1.1.1 プロセス開始の準備
     2.1.1.2 システム化構想の立案  ───── アクティビティ

      2.1.1.2.1 経営上のニーズ、課題の確認 ─┐
      2.1.1.2.2 事業環境、事業環境の調査分析 │
      2.1.1.2.3 現行業務、システムの調査分析 ├─ タスク
      2.1.1.2.4 情報技術動向の調査分析    │
       :                 ─┘

     2.1.1.3 システム化構想の承認
    2.1.2 システム化計画の立案プロセス
   2.2 要件定義プロセス
   2.3 システム開発プロセス
     :
  3 運用・サービスプロセス
  4 支援プロセス
   :


共通フレームの構成

共通フレームは、次の大区分プロセス群から構成されます。
 ここでは、その概要を示します。詳細は、   IPA「第3 部 共通フレームとガイダンス」 https://www.ipa.go.jp/files/000062659.pdf
を参照してください。

1 合意プロセス

システムの取得者(発注者、利用者)と供給者(受注者)の間の合意(契約)に関するプロセス

1.1 取得プロセス
システムに関するニーズ、供給者の選定、契約、システムの受け入れなど
1.2 供給プロセス
RFP(提案依頼書)の作成、契約、システム要件の決定、開発プロジェクト、納入と支援など
1.3 合意・契約の変更管理プロセス
変更要求の協議と合意、変更管理など

2 テクニカルプロセス

組織及びプロジェクトの担当部門が技術的な決定及び行動を結果生じる利益を最適化し、リスクを軽減できるようにするアクティビティの定義をする。

2.1 企画プロセス
経営・事業の目的、目標を達成するために必要なシステムに関する要件の集合とシステム化の方針、及び、システムを実現するための実施計画を得る
  • 2.1.1 システム化構想の立案プロセス
    経営課題を解決するするための新たな業務とシステムの構想を立案する。
    経営上のニーズ・課題、事業・業務環境、現状分析、情報技術動向などを確認。対象となる業務の明確化と業務の新全体像の策定。システム化構想の承認、システム化推進体制の確立など。
  • 2.1.2 システム化計画の立案プロセス
    システム化構想を具体化するために、対象業務について運用や効果等の実現性を考慮したシステム化計画及びプロジェクト計画を具体化し、利害関係者の合意を得る。
    対象業務のシステム化による新業務モデル策定。その実現可能性と費用対効果の明確化。全体開発スケジュール、システム選定方針(ハード・ソフトの基本要件)の策定。プロジェクト推進体制の決定・目標の設定など。
2.2 要件定義プロセス
新たに構築するシステム化の範囲を明確にし、システムが持つべき要件を列挙・検討して利害関係者間で合意する。
業務要件を実現するために必要なシステムの機能や,システムの開発方式,システムの運用手順,信頼性,安全性,セキュリティなど多様な要件がある。
  • 2.2.1 プロセス開始の準備
    要件の収集方法、文書化、合意及び承認などに関するルールの決定
  • 2.2.2 利害関係者の識別
    システムのライフサイクルの全期間を通して、どの工程でどの関係者が参画するのかを明確にする。一般消費者のように直接のコミュニケーションが困難な場合には、それを代表するものを選定する。
  • 2.2.3 要件の識別
    利害関係者から要件を引き出して、その要件を誤解がないように明確に定義する。漏れがないように抽出することが目的であり、要件の取捨選択をするものではない。
    要件には、機能要件と非機能要件がある。この段階で非機能要件も引き出す必要がある。
    ・業務要件を実現するために必要な機能に関する要件
    ・それ以外の機能に関する要件(非機能要件)-品質特性、技術要件、運用・操作要件など
    がある。(参照:「非機能要求グレード利用ガイド」
    このアクティビティは次のタスクで構成される。
    ・2.2.3.1 要件の抽出
    ・2.2.3.2 制約条件の定義(必ず必要となる条件を明確にする)
    ・2.2.3.3 代表的活動順序の定義
      (システムがどのように動作するかをシナリオ化して、必要となる要件を探す)
    ・2.2.3.4 利用者とシステム間の相互作用の識別
    ・2.2.3.5 システムの使用が周辺に及ぼす影響への対処
  • 2.2.4 要件の評価
    「要件の識別」を確認して、矛盾点や曖昧点をなくし、一貫性のある要件群として整理する。そして、実現可能性や重要度により要件に優先順位をつける。
  • 2.2.5 要件の合意
    評価の結果、システムに組み入れる要件を策定して、利害関係者に示し合意を得る。
  • 2.2.6 要件の記録
    合意した要件を文書化し、ライフサイクルを通して管理できるようにする。
2.3 システム開発プロセス
要件プロセスでの要件を解決するには、人的活動による解決とシステムによる解決がある。このプロセスでは、新たに開発するシステムへの要件にブレークダウンして、それを満足するための作業を決定する。
  • 2.3.1 システム開発プロセス開始の準備プロセス
  • 開発環境の準備、開発プロセスの実施計画、非納入品目(CASEなど開発には用いるが納入はしない品目)の使用の容認など
  • 2.3.2 システム要件定義プロセス
    要件定義プロセスからの要件を、システム設計への要件として再定義する。
  • 2.3.3 システム方式設計プロセス
    システム方式とは、システム要件をハードウェア、ソフトウェア、人手による操作などにより、どのようにして満足させるかのこと。システム方式設計とはシステムの最上位レベルでの方式を確立することで、システム要件定義プロセスの次に行うプロセスである。
    ここで、ハードウェアやソフトウェアの構成を決定する。利用者用文書(暫定版)作成、システム結合のためのテスト要件の定義も含まれる。
  • 2.3.4 実装プロセス
    このプロセスの大部分はソフトウェア実装プロセスとして分離されるが、ソフトウェア以外の要素もあるので項目だけ掲げてある。
  • 2.3.5 システム結合プロセス
    システム結合とは、対象システムと関連する他のシステム(手作業システムもある)との間で情報が矛盾なく交換できるかという意味である(プログラムでの結合テストの意味ではない)。
  • 2.3.6 システム適格性確認テストプロセス
    適格性とは要件を満足していること。システム要件定義プロセスでの要件を満足しているかのテストであり、いわゆるシステムテスト(の一部)に相当する。実際に業務で使うデータや、業務上例外として処理されるデータを使ってテストする。
  • 2.3.7 システム導入プロセス
  • 2.3.8 システム受入れ支援プロセス
    受入れテスト、取得者への教育訓練や支援など
2.4 ソフトウェア実装プロセス
「2.3 システム開発プロセス」のうち、ソフトウェア(プログラムやデータベースなど)に焦点をあてたものである。いわゆる「内部設計」といわれる分野である。下位プロセス構成はシステム開発プロセスと類似している。それに関しては「システム」を「ソフトウェア」と読み替えて理解することができよう。
  • 2.4.1 ソフトウェア開発プロセス開始の準備プロセス
  • 2.4.2 ソフトウェア要件定義プロセス
    データの定義及びデータベースの要件定義、外部インターフェース(ソフトウェア間のインタフェースや画面設計など)の要件確認、他のシステムとのデータソフトウェアレベルでの要件定義と共同レビュー
  • 2.4.3 ソフトウェア方式設計プロセス
    ソフトウェア構造とコンポーネントの方式設計。外部インタフェースの具体的な設計。データベースの最上位レベルの設計など
  • 2.4.4 ソフトウェア詳細設計プロセス
    プログラムの詳細設計、データベースの詳細設計など
  • 2.4.5 ソフトウェア構築プロセス
    ソフトウェア、データバースの作成。単体テスト
  • 2.4.6 ソフトウェア結合プロセス
    結合テストに関する作業
  • 2.4.7 ソフトウェア適格性確認テストプロセス
    ソフトウェア要件定義プロセスでの要件が満足されていることの確認
  • 2.4.8 ソフトウェア導入プロセス
  • 2.4.9 ソフトウェア受入れ支援プロセス
2.5 ハードウェア実装プロセス
共通フレームでは、ソフトウェアを主とするシステムを対象にしているので、詳細のプロセスは掲げていない。
2.6 保守プロセス
「保守・運用」とまとめることが多いが、共通フレームではそれを明確に区分している。
「保守」とはシステムを改善・変更する作業
「運用」は現行のシステムを日々動かしていく作業。システムの変更作業はしない
保守プロセスは、納入されたシステム及びソフトウェア製品に対して費用対効果が高い支援を提供することを目的とする。

  • 2.6.1 プロセスの開始
  • 2.6.2 問題把握及び修正の分析
  • 2.6.3 修正の実施
  • 2.6.4 保守レビュー及び/又は受入れ
  • 2.6.5 運用テスト及び移行の支援

3 運用・サービスプロセス

完成したシステムが意図された環境で安定して稼働するためのプロセスである。ここでの運用者とは、クライドコンピューティングの受注者、利用者企業での運用業務の受注者、社内運用でのIT部門などのこと。

3.1 運用プロセス
運用に関する作業の定義、運用テストの実施、移行への支援、利用者教育と支援、システムや業務の運用の評価など
システムの費用対効果の予測は「企画プロセス→システム化計画の立案プロセス」で行い、その評価はここで行う。
3.2 廃棄プロセス
システムの廃棄計画、新旧システムの引き継ぎなど
3.3 サービスマネジメントプロセス
サービスレベルの設定(SLA)、問題管理、構成管理など、ITサービスマネジメントに準じた作業を示している。(参照:「ITサービスマネジメントとITIL」

4 支援プロセス

文書化や品質管理は、テクニカルプロセスの多様なアクティビティに共通する重要な事項である。その事項を集めて必要な作業を示したのが支援プロセスである。

4.1 文書化プロセス
文書化する場合の規定。規範的なものではなく関係者合意で定めればよいとしている。
4.2 品質保証プロセス
成果物、プロセス(仕事の仕方)、マネジメントシステムの3つの品質を保証する。
4.3 検証プロセス
作業結果が仕様(要求事項)を適切に反映しているかを確認する。
4.4 妥当性確認プロセス
成果物が利用者の視点から意図された正しいものになっているかどうかを確認する。
4.5 共同レビュープロセス
合意目標に対する進捗、及び利害関係者を満足させる製品の開発を確実にするために、利害関係者と共通理解を維持する目的として、効果的なレビューを行う。
4.6 監査プロセス
4.7 問題解決プロセス
発見された問題を識別、分析、管理、制御して解決する

5 プロジェクトプロセス

5.1 プロジェクト計画プロセス
  • 5.1.1 プロジェクトの開始(プロジェクトの要求の確立、プロジェクトの実現可能性の確認、プロジェクトの要求の変更)
  • 5.1.2 プロジェクト計画(プロジェクト実行計画の策定、プロジェクト実行計画の共同レビューの実施)
  • 5.1.3 プロジェクトの始動
5.2 プロジェクトアセスメント及び制御プロセス
  • 5.2.1 プロジェクトの監視
  • 5.2.2 プロジェクトの制御(問題の解決、進捗の報告)
  • 5.2.3 プロジェクトアセスメント(評価活動の保証、結果の評価、評価結果の共同レビューの実施)
  • 5.2.4 プロジェクトの終了
5.3 意思決定管理プロセス
5.4 リスク管理プロセス
  • 5.4.1 リスク管理の計画
  • 5.4.2 リスクプロファイル管理
  • 5.4.3 リスク分析(リスクの識別、リスクの発生確率及び影響の見積り、リスクの評価、リスク対応処置及び代替案の文書化)
  • 5.4.4 リスク処置
  • 5.4.5 リスク監視
  • 5.4.6 リスク管理プロセス評価
5.5 構成管理プロセス
5.6 ソフトウェア構成管理プロセス
5.7 情報管理プロセス
5.8 測定プロセス

6 組織のプロジェクトイネーブリングプロセス

組織のプロジェクト遂行能力を高めるため、プロセスの改善、インフラの整備、適切な資源配分、人材の確保・育成、スキル管理、情報資源管理、再利用、システム監査などを行う。

7 プロセスビュー

ここではユーザビリティに関するレビューを扱っている。

8 テーラリング(修整)プロセス

共通フレームを状況に合わせて修整するときの留意事項と作業を示している。