UP TO DATE・バックナンバー>>
UP TO DATE 共通フレーム
システム構築の標準化と開発力強化

本ページの内容をPDFファイルでダウンロードできます >> PDFダウンロード


情報システムは、高速に・大規模に・複雑に、しかも日々ネットワークによる広がりを増しています。それにつれてシステムに関わる企業や人は加速度的に増えていきます。そうした中で同じ用語が企業や人によって異なる意味で使われたり、同じ作業の適用範囲が異なったりすることは情報システムに重大なリスクを生じかねません。
そこで注目されているのが、情報システムのライフサイクル全般において、関係者全員が共通して利用できる用語や作業内容を標準化する「共通フレーム」。最新版「共通フレーム2007」を中心に、多くの企業でその活用が進められようとしている共通フレームとは何なのか、特長や構造、利用・活用方法を紹介します。

ページのトップへ▲

共通フレームが生まれた背景

はじめに共通フレームの生い立ちを説明しておきましょう。

なぜ共通フレームか

かつてホストコンピュータが中心の時代は、社内または特定のベンダー間でシステムを開発していました。やがてマルチベンダーが一般的となり、企業は従来とは異なるベンダーあるいは複数のベンダーと開発を進めるようになります。システム規模も大きくなり、幅広い部門からさまざまな職務の人たちが開発に携わるようになると、コミュニケーション上でさまざまな問題が生じるようになってきました。

  • 課題1 <作業現場の混乱>
    複数の企業や部門が関与するようになると、1つの用語について企業や部門などそれぞれの立場で意味やその用語の指し示す範囲が異なる場合があり、コミュニケーションの弊害となります。また、作業内容や進め方の違いが現場の混乱を招き、開発効率を著しく低下させてしまいます。
  • 課題2 <見積りを比較できない>
    同じRFP(提案依頼書)を提示しても、ベンダーごとに用語や作業項目の名称、その内容や範囲の解釈が異なる可能性があります。一言で「保守」と言ってもベンダーごとに対応範囲が異なる可能性は高く、そうなると見積り自体が比較できません。
  • 課題3 <狙い通りのシステムが構築できない>
    用語の意味・解釈の相違を放置したまま開発を進めると、納期や品質に重大な影響を与えます。開発の進行につれて関係者間で意図の食い違いが大きくなり、当初の狙いとズレが生じて修正に時間を要したり、極端な場合には使えないシステムとなり、訴訟問題にさえ発展しかねません。

以上のような課題を解決するために用意されたのが共通フレームです。システム発注側と受注側の間で誤解や混乱がないように、共通して利用できるように用語や作業内容の標準化を実現する「ガイドライン」なのです。

共通フレーム2007への道すじ

情報処理振興事業協会(現、情報処理推進機構:IPA)の下に設置された産官学から構成される「システム開発取引の共通フレーム検討委員会」が、1992年に検討を開始しています。その後1994年に、国際標準化組織ISO/IEC JTC1/SC7委員会で審議中だったソフトウェアライフサイクルプロセスの委員会原案(後のソフトウェア開発プロセスのモデル規格ISO/IEC 12207)をベースにして作成されたのが「ソフトウェアを中心としたシステムの取引に関する共通フレーム」(「共通フレーム94」)です。
翌1995年には基になったISO/IEC 12207が正式発行となり、これに合わせて共通フレームも改訂されています。それが「ソフトウェアを中心としたシステム開発および取引のための共通フレーム 1998年版」(「共通フレーム98」)です。
そして、10年近い歳月を経た2007年9月に、現時点(2009年2月現在)の最新版「共通フレーム2007」が公表されました。ISO/IEC 12207の追補発行やITを取り巻く環境変化に対応した改訂が行われています。

ページのトップへ▲

「共通フレーム2007」のアウトライン

最新版「共通フレーム2007」では、契約変更の管理や企画、要件定義など、それまでの共通フレームになかったプロセスが加えられるなど、より実務的な改訂が行われています。

「共通フレーム2007」の構造

「共通フレーム2007」は、ソフトウェアライフサイクルに関する国際規格ISO/IEC12207(JIS X 0160)をベースとしており、構想段階から開発を経て廃棄にいたるまでのソフトウェアの全ライフサイクルに沿って整理されています。
次の図は「共通フレーム2007」の構造で、「主ライフサイクルプロセス」、「組織に関するライフサイクルプロセス」「支援ライフサイクルプロセス」「システム監査プロセス」という基本プロセスで構成されています。

各プロセスの構造

作業を「プロセス」「アクティビティ」「タスク」「リスト」の4階層で表現しています。
基本プロセスは、さらに複数のプロセスで構成されます。それぞれのプロセスは、いくつかのアクティビティで構成され、アクティビティはさらにいくつかのタスクで構成されます。タスクもいくつかのリストで構成されるというように細分化されています。
これらは書籍の目次のように大項目(プロセス)、中項目(アクティビティ)、小項目(タスク)、例示(リスト)という階層構造になっています。

改訂のポイントと特長

「共通フレーム2007」では、それまでの共通フレームになかったプロセスが加えられるなど、より実務的な改訂のほかに、重要な改訂点があります。
それは、設計など従来の上流フェーズを拡張し、超上流という考え方を導入している点です。超上流とは、ソフトウェア開発における最初の作業である要件定義の前段階作業のこと。経営的視点から全社のシステム化の方向性を整理するフェーズやそれを受けてのシステム化計画の立案フェーズなどがそれにあたります。経営的な視点からのシステム開発に対応しているのです。

ページのトップへ▲

共通フレームの利活用

共通フレームとは、システムのライフサイクルにおいて標準的な作業の範囲とその内容・項目を記したものです。企業独自の開発方法・プロセスを、共通フレームの体系に対応させることは、関係者間に正確かつ効率的なコミュニケーションを生み出し、システムの企画・開発〜運用・廃棄までを円滑に行うことを可能にします。

修整して利用する

共通フレームは規定されている内容をマニュアルのようにそのまま適用するものではありません。組織やプロジェクトの特徴に合わせてガイドラインを修整(テーラリング)して使います。
修整は、利用状況に合わせてアクティビティやタスクを取捨選択したり、複数のタスクをまとめたりする作業です。
次の図のように、第1レベルで共通フレームの規定を修整して企業の特徴に合わせて標準化し、第2レベルの修整ではシステムの特性や開発技法に合わせるというように、修整レベルを決め、レベルごとに利用者の実情に即した内容に修整して利用します。

発注の際の要件定義モデルとして使う

共通フレーム策定における本来の目的の1つです。RFPの作成時など、ベンダーの作業を定義するためのモデルとして活用できます。作業を発注する側と受ける側の誤解をなくし、円滑に業務を進めることができるようになります。
発注者側は「用語については共通フレーム2007に準拠しているので、提案書や見積り等も同じように準拠して作成するように」と伝えることで、受発注者双方の作業範囲や役割分担などを明確にすることができます。

作業項日のチェックリストとして使う

本来共通フレームは社内だけでの活用も可能です。
共通フレームでは、図2で示したようにプロセスごとに「アクティビティ」−「タスク」−「リスト」という階層で記述されており、個々の具体的な作業であるタスクを遂行するための作業項目がリストとして例示されています。これらを社内業務のチェックリストとして使用することができます。
プロセスごとに構造化され、整理されており、プロジェクトの計画から日々の運用に至るまでタスクや作業項目に漏れがないかなどを確認することができます。

プロセスの改善・見直しに使う

チェックリストとしての使い方をさらに進めたものです。自社内ですでに構築されている、または進行中のプロセスを共通フレームと比較・照合を行ってプロセスの網羅性や粒度(処理の細分化の単位)の適否を確認します。
必要に応じてプロセスの追加・分割・統合など再構築を進めることで、プロセスの網羅性を向上させ、プロセスの品質向上、構築後の追加作業の抑制、開発業務の効率化、共通フレームに準拠することで、社内のプロセスを統一することで、開発業務のさらなる効率化と品質向上を期待できます。

大手建設会社A社の事例

基幹システム再構築などの全社に関わるシステム改変は、共通フレーム導入に最適のタイミングとなるでしょう。全社的なシステム改変となれば、社内外の多くの部門・部署が関与しますので、共通フレームにより、社内でしか通じなかった用語や作業を国際的な規格に則って標準化することができます。
大手建設会社A社では、ホストコンピュータのダウンサイジングをきっかけにEA(Enterprise Architecture)の導入を決定しました。その目的の1つに要件定義の標準化と役割分担の明確化があり、そこで注目したのが共通フレーム2007でした。超上流(要件定義)の標準化に言及しており、同社の要件定義の標準化に即していたからです。さらに、内部統制への対応も含めて、工程の見直しを実施し、目標通りの標準化を実現しました。

ページのトップへ▲

共通フレームの可能性

作業を発注する側と受ける側の誤解をなくすために策定が進められてきた共通フレームですが、これまで紹介したように活用範囲が拡大しています。
作業を標準化することで、さらに効率化と高品質化が期待でき、結果的にはコスト削減にもつながります。共通フレームは、ソフトウェアライフサイクルに沿って必要な作業が網羅されている、ベストプラクティスとして活用できるのです。関係者全員の共通認識として業務を推進できる「日本版標準」が共通フレームなのです。
めまぐるしく変化するビジネス環境に迅速に対応するためには、質の高いITシステムを効率よくかつ低コストに構築しなくてはなりません。共通フレームは、そうしたITシステム構築を強力に支援する仕組みです。自社ITシステムのさらなる高品質化とライフサイクル全般の標準化を実現する、共通フレームにチャレンジしてみてはいかがでしょうか。

ページのトップへ▲

All Rights Reserved, Copyright(C) FUJITSUファミリ会