PMRクラブ
先号　　　次号

情報システム導入プロジェクトにおける共通フレーム2013の概要

横河ソリューションサービス(株)　薄井　昭人　[プロフィール]　：10月号
1．はじめに
　今回、2015年9月8日(火)に開催された「第16回 PMRクラブ」において話題提供させていただいた内容から一部を紹介します。
　近年の情報技術 (IT) の発展に伴い、ビジネス領域が拡大しています。製造現場では、従来のプロセス制御システム (PCS) のみならず、製造実行システム (MES) や基幹業務システム (ERP) などの情報システムを導入し、経営管理～操業管理～運転管理を直結して経営効率の向上に努めています。情報システムは企業の業務を支え、そのシステムの信頼性は経営に影響を与えるまでになりました。一方で、システムやその根幹をなすソフトウェアの企画、開発、維持管理においては、言葉の定義やその解釈の問題、要件定義や役割分担の問題、見積り・契約・仕様変更の問題など、多くの課題を抱えているのが現状です。
　このような状況のもと、ソフトウェア取引の透明性の確保、発注者・開発者・運用者が行うべき作業の可視化のための共通規範として「共通フレーム」が策定されました。
　共通フレームとは、ソフトウェアの構想から開発、運用、保守、廃棄に至るまでのライフサイクルを通じて必要な作業項目、役割等を包括的に規定した共通の枠組みです。共通フレームの目的は、ソフトウェア開発者 (受注者) とそれを利用する事業者 (発注者) が、“同じ言葉を話す”ことができるようにすることにあります。なお、現在出版されている最新版は2013年に出版された「共通フレーム2013」ですが、最初の共通フレームはソフトウェアライフサイクルプロセス (SLCP) の国際規格原案を参照文書として1994年に「共通フレーム1994」が出版され、その後、1998年、2007年、2009年に改訂を重ねてきています。

2．共通フレーム2013の必要性
　前章でも触れたように、ソフトウェアの開発とその取引については、多くの問題が指摘されてきています。本章では、共通フレーム2013のような標準化がなぜ必要なのかについて、その根底にあるソフトウェア開発とその取引の問題について説明します。
　共通フレーム2013では、ITを取り巻くプロセスに関連する課題として次のような問題を上げています。
(1) コミュニケーションの複雑さ
(2) 言葉の問題
(3) 要件定義や役割分担の問題
(4) ステークホルダーの合意の問題
(5) 不明確は取引の問題
(6) 見積の問題
(7) 仕様変更の問題
(8) “情報システムの信頼性向上”の問題
(9) 再利用の問題
(10) ユーザビリティの問題
(11) ライフサイクルモデルの問題
(12) 業務全体を対象範囲としてとらえられていない問題
(13) プロジェクト任せという問題
(14) 保守の可視化ができていないという問題
(15) 運用からの視点がおろそかになっているという問題
(16) 使える業務システムになっていないという問題

これらの問題のうち、「(3) 要件定義や役割分担の問題」および「(6) 見積の問題」ついて、少し具体的に紹介します。
① 要件定義や役割分担の問題
　IT化におけるユーザ・ベンダの役割分担の明確化が必要です。
SEC BOOKS「経営者が参画する要求品質の確保」では、ユーザ企業とベンダー企業の役割分担を具体的な提言として、“超上流から攻めるIT化の17カ条”が記載されています。
1) ユーザとベンダーの思いは相反する
2) 取決めは合意と承認によって成り立つ
3) PJTの成否を左右する (業務及びシステム) 要件定義の先送りは厳禁である
4) ステークホルダー間の合意を得ないまま、次工程には入らない
5) 多段階の見積は、双方のリスクを低減する
6) システム化実現の費用はソフトウェア開発だけではない
7) ライフサイクルコストを重視する
8) システム化の方針・狙いの周知徹底が成功の鍵となる
9) 要件定義は発注者の責任である
10) 要件定義書はバイブルであり、事あらばここへ立ち返るもの
11) 優れた要件定義書は、システム開発を精緻に著わしたもの
12) 表現されない要件は、システムとして実現されない
13) 数値化されない要件は、人によって基準が異なる
14) 「今と同じ」という要件定義はありえない
15) 要件定義は「使える」業務システムを定義すること
16) 機能要求は膨張する。コスト、納期が抑制する
17) 要件定義は、説明責任を伴う
② 見積の問題
　曖昧なニーズのまま見積を行い、契約が取り交わされた後で問題となるケースがあとを絶ちません。ユーザは、(業務) 要件定義の前段階におおよそのプロジェクトの方向性を決めただけで予算を見積ることが多く見受けられます。この段階では不確定要素が多く、ベンダーが提出する見積は多くの前提条件が付けられたものになります。プロジェクトが、この前提条件を十分確認せずに金額だけ見て発注した場合、プロジェクトの終盤で膨らんだ数字を見て、トラブルとなることは容易に想像できます。
　SEC BOOKS “経営者が参画する要求品質の確保” で、曖昧さが残る段階の見積を、はっきりした段階で見積り直せるルール作りなどが産業界にとってプロジェクトの成功の鍵となると述べています。下記のような多段階で見積の都度、契約が行えるルールが必要となります。


3.　共通フレーム2013の概要
　次に、共通フレーム2013の目的、対象範囲、適用分野、利用者と利用方法について簡単に紹介します。
① 共通フレーム2013の目的
共通フレームを産業界で「共通の物差し (※1) 」として用いることにより、“システム及びソフトウェア開発とその取引の明確化 (※2) ”が可能となり、増大するシステム及びソフトウェア開発の取引において相互理解を容易にし、市場透明性を高め、取引のさらなる可視化を実現します。
(※ 1) 共通の物差し
取引時の契約者 (取得者と供給者) 双方があるいはシステム開発に係る全ての人々が、取引対象であるソフトウェアを中心としたシステムの企画、要件定義、設計・開発、運用・保守の作業内容を共通に参照できるようにしている。
(※ 2) 取引の明確化
受発注契約の際に、取引内容が取得者・供給者双方で十分に具体化され、契約内容に曖昧さがなく、契約以降に契約時点で見えなかった作業が発生しないこと。また、契約当事者以外の第三者に対しても十分に公明正大で透明性が保たれていること。
② 共通フレーム2013の対象範囲
「業務分析、業務設計、ソフトウェアを中心としたシステムの企画、 要件定義、設計・開発、運用・保守及びそれらに係る諸活動」を対象とします。
③ 共通フレーム2013の適用分野
共通フレームは、取得者と供給者の二者間の契約に基づいて使用されることを想定しており、適用対象が組織の内部か外部を問わず、次の場合に適用します。
1 ) システム、ソフトウェア製品を取得または提供する時
2 ) ソフトウェアサービスを取得または提供する時
ここで、ソフトウェア製品とは、製品として販売されているソフトウェア及び組み込みソフトウェア等を指します。ソフトウェアサービスとは、システムインテグレーションサービスを受けるまたは提供するような場合を指します。また、ソフトウェアサービスを提供する場合は、取引だけではなく供給者の開発標準として用いることも含まれます。
④ 共通フレーム2013の利用者と利用方法
利用者は、ソフトウェアを中心としたシステム開発及び取引に係る全ての組織または人たちであり、具体的には、以下の利用者が想定されます。
1 ) 直接取引に係る組織
取得者と供給者 (企業、企業内の各部門・組織)
2 ) 取引要素を構成する各作業に係る部門
契約関係、企画、業務要件定義、開発、運用、保守、支援の各作業
(企画・業務部門、システム部門、ソフトウェアベンダ、利用または運用部門、品質管理・法務・監査・教育等の部門)
3 ) 政府・監督官庁及び標準化推進団体等
共通フレームはソフトウェアを中心としたシステムの開発および取引を明確化することが目的ですから、システムの企画、要件定義、開発、運用、保守および契約に関する作業について、共通フレームの 各要素がどのような作業であるかを理解できることが重要になります。

4. 共通フレームの設計思想
　共通フレームの特徴として、以下に示す10項目の設計思想で作成されています。
(1) 超上流の重視
SEC BOOKS 「経営者が参画する要求品質の確保」の考え方に基づいて、超上流と言われる企画プロセス、要件定義プロセス、契約の変更管理プロセス等を追加しています。
(2) モジュール性の採用
各プロセスは、必要に応じて組み合わせて実施できるようにモジュール化されています。
(3) 責任の明確化
取得プロセスは「取得者」、企画プロセスは「企画者」のようにプロセスごとに作業の主体者 (役割) を定義し、責任の所在を明らかにしています。
(4) 責任範囲の明確化
企画～要件定義～システム開発～運用テスト～運用・評価までの一連の流れを、設計とテストで対応させてV字で表現し、そこに事業・業務・システム・ソフトウェアの領域を重ね合わせて示すことにより、上流から運用までの流れを、企画して作り込むフェーズとその正しさを確認するフェーズを対応させることで、責任範囲を明確にしています。


(5) 工程、時間からの独立性
共通フレームは、工程や時間には依存しない。各プロセス、アクティビティ、タスクは一般的な順序で配列されているだけで、本質的に時間の依存性を持ちません。つまり、プロセス、アクティビティ、タスクはソフトウェアライフサイクルを構成する「仕事」の順序や時間関係を規定したものではありません。
(6) 開発モデル、技法、ツールからの独立性
共通フレームは特定の技法やツールに依存しません。
(7) ソフトウェアを中心としたシステム関連作業までを包含
共通フレームでは、業務の一部を「システム」に置き換えるための活動を定義します。このとき、「システム」は「人による活動」とともに「業務」の一部として存在することになります。
(8) システムライフサイクルプロセスとの整合性
共通フレームはソフトウェアライフサイクルで使われるプロセスを中心に定義しますが、システムライフサイクルで使われるプロセスと矛盾するものではありません。
(9) 文書の種類、書式を規定しない
共通フレームでは、ドキュメントの種類や書式などの詳細については規定していなません。例えば「システム設計書」と一言いってしまうと、既にその中に使われている項目や言葉によって作業内容が自ずと決まってしまいます。そのため、文書の種類、書式を規定していません。
(10) テーラリング (修整) の採用
共通フレームの適用にあたっては、アクティビティ、タスクを取捨選択したり、繰り返し実行したり、複数のものを一つに括って実行してよいとしています。この部分がとりわけ重要です。共通フレームに書かれているとおりにやるのではなく、プロジェクトの特性も含めて、お互いの契約行為の中でテーラリング (修整) して利用すればよいということになります。

5. おわりに
　今回、「第16回 PMRクラブ」における話題提供として、情報システム導入プロジェクトにおいて構想から開発、運用、保守に至るまでのライフサイクルを通じた包括的な共通規範となる「共通フレーム2013」について、その概要をご紹介しましたが、話題資料をまとめる中で、共通フレームはP2Mに通じる考え方で捉えることができるのではないかと考えました。例えば、一連の流れを設計とテストで対応させたV字モデルのうち、企画・要件定義などの超上流や上流はP2Mで言えばスキームモデル、システム開発から運用テストまではシステムモデル、運用・評価の部分はサービスモデルがそれぞれ適用できます。
　また、当日の参加者どうしの意見交換では、見積の問題のところで示した要件定義段階での不確定要素と見積の難しさ、V字モデルにおける各フェーズでの設計とテストの関係性など、様々なディスカッションも交わされ、話題提供者の私自身にとっても多くの得るところがありました。
　今後もPMRクラブを通して、様々な話題について皆様と意見交換させていただければと存じます。

参考文献
・ SEC BOOKS 「共通フレーム2013　～経営者，業務部門とともに取組む「使える」システムの実現～」，独立行政法人 情報処理推進機構 (IPA) 技術本部 ソフトウェア高信頼化センター (SEC)，2013年12月
・ SEC BOOKS 「経営者が参画する要求品質の確保　～超上流から攻めるIT化の勘どころ～　第2版」，
独立行政法人 情報処理推進機構 (IPA) 技術本部 ソフトウェア高信頼化センター (SEC)，オーム社，2006年5月
・ 「共通フレーム2013の概説」，独立行政法人 情報処理推進機構 (IPA) 技術本部 ソフトウェア高信頼化センター (SEC)，研究員　室谷　隆

以上
ページトップに戻る