JEITA ソフトウェアエンジニアリング技術分科会
2009/3/17 S.Otuki

システム品質向上へ向けた作業標準化への取り組み

第3章

ソフトウェア品質保証への取り組み.........................................................................................2

3.2

システム品質向上へ向けた作業標準化への取り組み................................................................2

3.2.1

はじめに...............................................................................................................................2

3.2.2

作業の体系化 .......................................................................................................................2

3.2.3

システム基盤作業の手順化.................................................................................................5

3.2.4

運用保守作業の手順化 ........................................................................................................6-1-第3章 ソフトウェア品質保証への取り組み
3.2 システム品質向上へ向けた作業標準化への取り組み
3.2.1 はじめに
情報システムの構築から運用保守作業は、複雑・多岐にわたる作業と多くのノウハウを必要としており、かつ、高品質を求められている。JEITA Workshop2008「ソフトウェア品質保証への取り組み」のヒアリングの一環として、株式会社富士通エフサスの成瀬泰生氏（インフラテクノロジーセンター
エグゼクティブ IT アーキテクト兼共通技術センター長）にお話をうかがった。
システム基盤の現場では、作業の標準化や知識の体系化は、あまり系統的に推進されていない。現場での課題は以下のように集約される。
•そもそもシステム基盤作業で何をしたらよいかわからない。

•

同様のトラブルが繰返し起きている。

•

全体としての品質が上がらない。

顧客と SE の間で作業内容の認識に相違があり、作業の漏れ抜けによる作業の手戻りも頻発している。
そこで、まず対応すべき施策は、関与者間で共有できる作業範囲・役割分担、作業順序、成果物、システム品質についての「標準化」が必要である。

3.2.2 作業の体系化
富士通では、従来より SDEM（企画、開発、運用・保守の標準プロセス）という社内標準化活動を推進してきている。顧客を含めたすべての関係者の共通認識を形成するためのシステム、ソフトウェアに関する作業の「地図」の役割を果たすことを目的としている（図 3.2.2-1）。

図 3.2.2-1 システム・ソフトウェアに関わる作業-2-SDEM は 1976 年にソフトウェア開発規準として整備され、以降、システム開発標準、共通フレー
ム対応、ソリューション指向の標準プロセス体系を経て、現行のものは、企画、開発、運用・保守、品質保証活動の基本的な考え方を示した標準プロセス体系に発展している。SDEM は、顧客およびSE といったプロジェクトの関係者が共通認識を築くための包括的な作業体系であり、豊富な IT サー
ビス・ソリューションの実績より引き出された、より詳細・具体的な、カテゴリーグループ毎の作業の手順化や製品技術情報テンプレート・導入サービスを含めたノウハウの集大成となっている。具体的な作業手順として、SDEM 実践標準としての業務アプリ開発編（ITBASP）、システム基盤編（ITIMAP）、および、運用・保守編（ITSMOP）等がある（図 3.2.2-2）。

図 3.2.2-2 SDEM 全体構成
SDEM の作業体系は、作業分類と工程の２つの軸で、作業を V 字モデルに従って体系化しており、次の４つの観点から構成されている（図 3.2.2-3）。
①カテゴリ（作業分類）
カテゴリとは、作業の関連性、作業で必要な知識•技術をもとに、作業を分類したものである。
これは、大きく４つ（実世界、インターフェース、システム、マネジメント。これらを概念カテゴリと呼ぶ）から構成され、役割の視点（経営者、利用者、共同作業、情報システム部門、プロジェクト管理者）をあわせもつ。この概念カテゴリを共通の軸として、各プロセス（企画プロセス、要件定義／開発／運用テスト・移行プロセス、運用・保守プロセス）では、個々の細分化されたカテゴリが設定される。例えば、要件定義／開発／運用テスト・移行プロセスでは、経営、業務、システム要件、アプリケーション、アプリケーション基盤、システム基盤、保守・運用、移行・展開、開発支援、プロジェクトマネジメントの各カテゴリが設定されている。
-3-

カテゴリは、プロジェクトでの開発体制（チーム編成）や役割分担に活用できる。例えば、顧客側の体制（顧客側プロジェクトマネージャ、業務チーム、運用・保守チーム、移行・展開チーム）とベンダー側の体制（ベンダー側プロジェクトマネージャ、アプリチーム、アプリ基盤チーム、システム基盤チーム、移行・展開チーム、開発支援チーム）との協働関係が各カテゴリの詳細項目によって示されることになる。
②工程（時間の流れ）工程とは、システム構築のための一連の活動を検証するための区切りである。例えば、要件定義、設計、製造（構築）、テスティング、運用テスト・移行の各工程の区切りでは、工程の完了規準が設定される。
③WBS（作業項目）
WBS とは、作業項目を段階的に階層化し、作業区分として構造化したものである。第１レベ
ル（体系化）では、プロジェクトを最も包括的に管理する場合の作業項目が設定され、カテゴリ・工程のマトリクスにより全ての作業項目を網羅している。第２レベル（詳細化）では、開発資源（期間、工数、技法、ツール、用品）の投入単位が設定され、ここでプロジェクト要因の役割単位が規定される。第３レベル（具体化）ではさらなる具体化が進められ、出力ドキュメントが対応している。
④品質保証（V 字モデル）
開発対象を設計により徐々にシステム構成要素に分解し、テストにより統合していく。V 字モ
デルでは、プログラム構造設計とプログラムテスト、システム構造設計と結合テスト、ユーザインタフェース設計とシステムテスト、システム要件定義と運用テスト・移行、情報化構想立案／システム化計画と運用・保守とが、それぞれ対応している。

図 3.2.2-3 SDEM の４つの観点-4-

3.2.3 システム基盤作業の手順化作業の体系を、現場・現物・現実の三現主義にもとづいて詳細化・具体化し、さらに作業の手順として確立したものがシステム基盤編（ITIMAP: IT Infrastructure architectural Method AndProcess）である。ITIMAP は非機能要件という論理の世界に基づき、システム基盤という物理の世界を実装する。論理の世界とは、性能・拡張性、信頼性、セキュリティ、運用・保守、移行・展開に関する要件であり、物理の世界は、システム構成・環境（データベース、ネットワーク、施設）を示している（図 3.2.3-1）。システム基盤技術者のさまざまな活動を明確に定義しており、計画の立案段階では PERT 図やファイル体系図により何をすべきかを定義し、作業の実施段階では基盤 WBS 一覧、ファイル一覧、基盤タスクカードによりどのように作業を実施すべきかを定義し、さらに、成果物に対して基盤レビューシートにより品質を確保するようにしている。

図 3.2.3-1 システム基盤（物理の世界）の位置づけ
ITIMAP は SDEM の体系に基づいてシステム基盤作業を実践化したもので、以下の４つの観点から構成される。
①作業の体系化（プロセス）
PERT 図（WBS1 体系）によって、作業の実施順序や前後関係などの関連性を関係者と明確にする。これはシステム基盤作業において実施すべき作業項目（WBS1 レベル）全体の関連性を体系化しており、これにをカテゴリごと、工程ごとに実施すべき作業項目、作業範囲、役割分担について明確にする場合に活用することができる。
基盤 WBS 一覧は、作業項目や成果物にもとづいて役割分担を関係者と明確化する。これはシステム基盤作業において実施すべき作業項目（WBS1~3 レベル）と成果物の関係を体系化した一覧である。これをカテゴリごと、工程ごとに実施すべき作業項目、作業範囲、役割分担に-5-ついて明確にする場合に活用することができ、また、作業項目と作成すべき成果物の関連性についても関係者と明確化する場合に活用することができる。
②成果物の体系化（アウトプット）
ファイル体系図によって、作成すべき成果物の全体像を関係者と明確化する。これはシステム基盤作業において作業項目ごとに作成すべき成果物を体系化したものである。これをカテゴリごと、工程ごとに作成すべき成果物の作成範囲、役割分担について関係者と明確にする際に活用することができる。
ファイル一覧によって、作成すべき成果物の構成要素を関係者と明確化する。これはシステム基盤作業において作業項目ごとに作成すべき成果物を体系化したものであり、さらに、成果物の構成要素（章立て）についても体系化している。これを、カテゴリごと、工程ごとに作成すべき成果物の作成範囲、役割分担、さらには、作成すべき成果物の構成要素（章立て）についても関係者と明確にする際に活用することができる。
③作業の手順化（ノウハウ）
基盤タスクカードによって、具体的な作業内容や実施上の留意点を確認できる。これは、作業項目、作業手順、および、作業のポイントなどの知識、技術を SE のノウハウとして WBS3 レベルごとにまとめたものである。これを、カテゴリごと、工程ごとに作業計画の立案~作業の実施~成果物の作成の各段階においてシステム基盤技術者のリファレンスとして利用でき、さらに、専門家育成などの人材育成にも活用できる。
④品質保証（評価項目）
基盤レビューシートによって、品質保証活動のためのチェック観点を確認できる。これは、作業品質の評価項目を作業項目、成果物、基盤タスクカードにもとづいた作業ポイントごとにまとめたものである。これによって、カテゴリごと、工程ごとに実施すべき作業品質の評価をプ
ロジェクト特性に応じて簡単、確実に漏れなく実施することができる。

こういった標準化活動を進めることによって、従来、現場で長年行われてきた「個人の経験による感覚での作業」からの脱却を図ることができる。SDEM による作業の体系化、ITIMAP による作業の手順化、そして、継続的な改善活動を通じ、顧客ビジネスへの貢献を果たし、さらには、業界への貢献をしていくことを目的としている。現在、業界貢献という観点では、非機能要求グレード検討会や、SEC での各種活動での展開を図っている。

3.2.4 運用保守作業の手順化
従来の発想では、「開発は一瞬、運用は永遠」と言われるものの、運用を開発のオマケと考え、軽視する風潮がある。運用は開発の後ろという「作りを重視」した発想が蔓延しており、運用段階に入るとドキュメンテーション不在でローテーションができなず属人的運用になってしまったり、計画や目標がなく漫然と目の前の仕事をこなしている状況が続いている。
-6-

図 3.2.4-1 ITSMOP のプロセス関連図
運用起点の考えに転換するために、ITIL（IT Infrastructure Library）を導入し、ITSMOP（ITService management &. Maintenance & Operation Process）の整備を進めている。ITSMOP のカ
テゴリ構成は、ITIL と対応した構成になっているが、プロセス全体を関連付けることにより、より実践的な体系としている(図 3.2.4-1)。また、経営、経営、業務、サービスサポート、サービスデリバリ、システム運用、システム保守、プロジェクトマネジメント、点検を PDCA サイクルで改善することに特徴がある。

図 3.2.4-2 ITSMOP の概要-7-

プロセス関連図によって、各構成要素の詳細化されたプロセス間の関連を明確にする。さらに担当者間の連携についてもプロセス（オペレーション）フローによって詳細化される。ここでは、例えば、経営者層、業務担当者、利用者、運用担当者（オペレータ）、運用管理社、運用保守責任者、保守管理者、保守担当者、専門部隊間のフローが定義される。ITSMOP の各プロセスにおける計画作業は、開発プロセスの中で実施され、保守・運用担当者に対しては IT サービスマネジメント操作手順も含めて育成していくことによって、IT サービス全体の PDCA サイクルを構成している。
また、現在運用中のプロジェクトにおいては、IT サービスマネジメントプロセスごとの成熟度を評価するため、ITSMOP「現状把握ヒアリングシート」を用い、レーダチャートから強み、弱みを見いだし、改善策を検討する方法が用いられている。

図 3.2.4-3 プロセス関連
ITIL は 2007 年 5 月再改訂され Version 3 が発表され、今後、これで強化された継続的サービス改善、サービスストラテジを参照し、運用起点のライフサイクルマネジメントを達成していく方向である（図 3.2.4-3）。
■-8-