ITガバナンスの策定－ITガバナンス策定のためのガ …jp.fujitsu.com/family/lsken/activity/work-group/02/...「われわれのCOBIT」の策定と「ITガバナンス成熟度セルフチ

LS 研:ＩＴガバナンスの策定

2002 年度研究成果報告書

ＩＴガバナンスの策定

－ＩＴガバナンス策定のためのガイドライン作り－

アブストラクト

１．はじめに

企業革新におけるＩＴの役割の拡大に伴い、企業としてＩＴをいかに統治していくかを明示した「Ｉ

Ｔガバナンス」を策定し、適正に運用すること（ＩＴガバナンスの確立）が、事業目標を達成するため

の重要な要素になってきている。またＩＴガバナンスの確立には、利害関係者（経営層・情報システム

部門・ベンダ・ユーザ）全体の明確な目的意識の共有と組織（経営層・情報システム部門など）による

統率力・実行力が必要であり、それに対応すべく情報システム部門のみならず、企業全体にも変革が迫

られている。

そこで当分科会では、ＩＴガバナンスの全体像を明確にし（共通フレームワーク化）、具体的に各社で

適用可能なＩＴガバナンス策定ガイドラインの雛型として「われわれのＣＯＢＩＴ」を作成した。これ

を基に作成した「ＩＴガバナンス成熟度セルフチェックシート」による自己診断を実施し､さらに自社に

適用するためのカスタマイズ、成熟度向上のための取り組みを実践することが重要であるとの結論に達

した。その結果、達成することのできるＩＴガバナンスの確立によって、必ずや各社の企業経営に資す

ることを期待している。

２．ＩＴガバナンスとは

「ＩＴガバナンスとは何か」という議論の中で「ＩＴガバナンスの全体像」、「ＩＴをどのように捉え

るか」、さらに「ガバナンスをどのように捉えるか」という基本的な検討を十分な時間をかけて実施した。

その後、「ＩＴガバナンスのフレームワーク」作りに着手し、各種のガイドラインについて調査・研究を

行った結果、米国のＩＴガバナンス協会（Information System and Control Foundation）の下部組織Ｉ

ＳＩＣＡ（Information System Audit and Control Association）が策定しているＩＴに関する管理ガ

イドラインであるＣＯＢＩＴⅢ（Control Objectives for Information and Related Technology Ⅲ）

をフレームワークとして採用した。

３．われわれのＣＯＢＩＴ（管理目標・成熟度の明確化）

「ＩＴガバナンスのフレームワ

ーク」として採用したＣＯＢＩＴ

は、システム構築から運用までの

全フェーズをカバーしており網羅

性という点では評価できるが、本

来はアメリカ企業のＩＴ部門にお

ける監査向けという傾向が強く、

日本の商習慣や組織構造、企業形

態の違いによって馴染まない点が

多かったため、「われわれのＣＯＢ

ＩＴ」を作成した。ＣＯＢＩＴ全

体のフレームと構造を活用し、

様々なカスタマイズを加えた結果、

具体的な成果物として独自の「Ｉ

Ｔガバナンス要素定義および成熟

度」を定めた。作成にあたっては、

●●●●

●△

△

△

△

△

●

△

●

　Ｐ０１　戦略的ＩＴ計画の定義　Ｐ０１　戦略的ＩＴ計画の定義

色々な情報技術の利用と色々なＩＴに対するビジネスか

らの要件とコストの三要素のバランスを取り、そのバラ

ンスがより高いものになるような戦略的ＩＴ計画を定義

する。

①企画/計画立案プロセスは、ビジネス要件の優先順位付けの仕組みを規定する

こと。

　さらに可能ならばビジネスの要件を明確化する仕組みを規定していること。

②マネジメント層の理解と情報化部門に対する支援は、情報化戦略、検証された数

値データ、構造化され透明性の高い意思決定プロセスを文書化した方法論で可

能とすること。

③IT戦略計画はリスクポジションを明確に示している、例えば明確に最先端のITを

使用するかそれとも実用テスト済みのITをしようするのか、またイノベータとして先

頭を走るかそれともフォロアーとして2番手以降の走者になるかということなどであ

る、また市場が望む提供タイミングと維持とサービス品質にかかわるコスト間での

バランスをとるか明示していること。

④戦略計画の全ての仮定が、吟味され検証されていること。

⑤成果をだすために必要なプロセス、サービス及び機能部門は定めれており、しか

もそれは透明性の高い変更管理プロセスによって柔軟かつ変更かのうなものに

なっていること。

⑥第3者による戦略の実現性チェックが、客観性を高めるために実施され、さらにそ

れが適切なタイミングで繰り返えされていること。

⑦IT戦略計画には、色々なロードマップや移行戦略が用意されていること。

　重要成功要因（ＣＳＦ）

①ＩＴ能力評価の最新性（最終評価日からの経過月）②IT戦略計画の老朽度（最終作成日から経過月）③IT戦略計画立案プロセスに対する参加者の満足度の割合④IT戦略計画が変更されて運営計画が変更されるまでの間の

タイムラグ⑤関与指標⑥計画における開発作業の適時性、体系的なアプローチの準

拠度、そして計画完遂などの品質指標

　重要業績評価指標（ＫＰＩ）

①ビジネス戦略計画の内、ＩＴ戦略計画が占める割合。　中期、短期計画と整合性がとられ、かつ、各担当責任者の実

行レベルまで落とし込まれている。②最新の、しかも明確で、適切に理解されているIT能力を身に

付けているビジネスユニットの割合③マネージメント調査で、責任、ビジネス、IT戦略が明確にリン

クされていること④IT戦略計画の中でカバーされている戦略テクノロジーを活用

しているビジネスユニットの割合⑤ビジネスオーナーによってい了承されたIT予算の割合⑥未終了ITプロジェクトのうちで、容認できるかつ合理的なも

のの件数

　重要目標達成指標（ＫＧＩ）

P 可用性（effectiveness）

S 効率性（efficiency）

機密性（confidentiality）

完全性（integrity）

可用性（availability）

準拠性（compliance）

信頼性（reliability）

情報基準 (Information Criteria)

(P) primary 　(S) secondary

ＩＴ資源　( ＩＴ Resources)

( ) 適用対象（applicable to）

　要員（people）

　アプリケーション

（applications）　技術（technology）

　設備（facilities）

　データ（data）

△

●

△

△

●△

注）ＣＯＢＩＴ－Ⅲ原本との対比（●：変更なし、△：一部変更、×：適用不可、◎：追加）

注

注

注

●●●●

●△

△

△

△

△

●

△

●

　Ｐ０１　戦略的ＩＴ計画の定義　Ｐ０１　戦略的ＩＴ計画の定義

色々な情報技術の利用と色々なＩＴに対するビジネスか

らの要件とコストの三要素のバランスを取り、そのバラ

ンスがより高いものになるような戦略的ＩＴ計画を定義

する。

①企画/計画立案プロセスは、ビジネス要件の優先順位付けの仕組みを規定する

こと。

　さらに可能ならばビジネスの要件を明確化する仕組みを規定していること。

②マネジメント層の理解と情報化部門に対する支援は、情報化戦略、検証された数

値データ、構造化され透明性の高い意思決定プロセスを文書化した方法論で可

能とすること。

③IT戦略計画はリスクポジションを明確に示している、例えば明確に最先端のITを

使用するかそれとも実用テスト済みのITをしようするのか、またイノベータとして先

頭を走るかそれともフォロアーとして2番手以降の走者になるかということなどであ

る、また市場が望む提供タイミングと維持とサービス品質にかかわるコスト間での

バランスをとるか明示していること。

④戦略計画の全ての仮定が、吟味され検証されていること。

⑤成果をだすために必要なプロセス、サービス及び機能部門は定めれており、しか

もそれは透明性の高い変更管理プロセスによって柔軟かつ変更かのうなものに

なっていること。

⑥第3者による戦略の実現性チェックが、客観性を高めるために実施され、さらにそ

れが適切なタイミングで繰り返えされていること。

⑦IT戦略計画には、色々なロードマップや移行戦略が用意されていること。

　重要成功要因（ＣＳＦ）

①ＩＴ能力評価の最新性（最終評価日からの経過月）②IT戦略計画の老朽度（最終作成日から経過月）③IT戦略計画立案プロセスに対する参加者の満足度の割合④IT戦略計画が変更されて運営計画が変更されるまでの間の

タイムラグ⑤関与指標⑥計画における開発作業の適時性、体系的なアプローチの準

拠度、そして計画完遂などの品質指標

　重要業績評価指標（ＫＰＩ）

①ビジネス戦略計画の内、ＩＴ戦略計画が占める割合。　中期、短期計画と整合性がとられ、かつ、各担当責任者の実

行レベルまで落とし込まれている。②最新の、しかも明確で、適切に理解されているIT能力を身に

付けているビジネスユニットの割合③マネージメント調査で、責任、ビジネス、IT戦略が明確にリン

クされていること④IT戦略計画の中でカバーされている戦略テクノロジーを活用

しているビジネスユニットの割合⑤ビジネスオーナーによってい了承されたIT予算の割合⑥未終了ITプロジェクトのうちで、容認できるかつ合理的なも

のの件数

　重要目標達成指標（ＫＧＩ）

P 可用性（effectiveness）

S 効率性（efficiency）

機密性（confidentiality）

完全性（integrity）

可用性（availability）

準拠性（compliance）

信頼性（reliability）

情報基準 (Information Criteria)

(P) primary 　(S) secondary

ＩＴ資源　( ＩＴ Resources)

( ) 適用対象（applicable to）

　要員（people）

　アプリケーション

（applications）　技術（technology）

　設備（facilities）

　データ（data）

△

●

△

△

●△

注）ＣＯＢＩＴ－Ⅲ原本との対比（●：変更なし、△：一部変更、×：適用不可、◎：追加）

注

注

注

1

LS 研:ＩＴガバナンスの策定


われわれ自身（経営層・情報システム部門・ベンダ・ユーザ）の視点で原文を読解し、日本企業で使用

する際に理解しやすいように、記載された項目の取捨選択、意訳を行い、さらに実際に各企業で活用し

やすいように、一覧性・一貫性を高めることに留意した。

「要素定義」には、4つのフェーズ（PO：計画と組織、AI：購入と実装、DS：デリバリーとサポート、

MO：モニタリング）３４のＩＴプロセスについて、各々の解説と求められる要因（情報基準）、対象とな

るＩＴ資源を定義し、重要成功要因（ＣＳＦ）と重要目標達成指標（ＫＧＩ）、重要業績評価指標（ＫＰ

Ｉ）を記述した。また「成熟度」は、各ＩＴプロセス毎に 0から 5のレベル（0：Non-Existent、1：Initial/Ad

hoc、2：Repeatable but Intuitive、3：Defined Process、4：Managed & Measurable、5：Optimized）

をより具体的に定義することに努めた。

４．ＩＴガバナンス成熟度セルフチェックシート

次にわれわれは「われわれのＣＯＢＩＴ」を基に「ＩＴガバナンス成熟度セルフチェックシート」を

作成したが、作成にあたってはその活用方法と活用に際しての留意点を明確にすることで、各企業でＩ

Ｔガバナンスを効果的に実践するツールとして活用できるものとした。内容としては３４の各ＩＴプロ

セスについて解説と回答対象者を記載し、各成熟度レベルについての現状の自己評価と、１年後、３年

後の目標を設定・記入する形式とした。さらにＩＴガバナンスの実践段階では、成熟度レベルの経過実

績を記入・チェックすることで、進捗状況の確認（把握）と評価を容易に行えるようにした。

セルフチェックシートはＬＳ研会員会社にアンケートという形で試行チェックをお願いし、８社から

コメントをいただいた。

５．ガイドラインとしての活用

「われわれのＣＯＢＩＴ」の策定

と「ＩＴガバナンス成熟度セルフチ

ェックシート」をガイドラインとし

て作成した。そして試行チェックの

評価を行った結果、右表の取り組み

の「実践」と「反復」が、ＩＴガバ

ナンスの実現へと導くことになり、

またその取り組みを明文化すること

で、ＩＴガバナンス確立のためのガ

イドラインとして有効であることを

確信した。さらにその過程において、

各企業がそれぞれのポジションやＩ

Ｔ化の段階、課題の優先順位によっ

てカスタマイズを加え、その実践段

階で基準や評価を共有化することが

肝要であるとの結論に達した。

６．まとめ

当初、当分科会では、ＩＴガバナンスを「ＩＴ戦略の策定から実現に亘る一連の活動をコントロール

する」ための「ＩＴマネージメントプロセス及びＩＴ標準」であり、「ＩＴ体制を構築・運用するための

組織だった活動」と定義した。また確立の目的を「経営に対するＩＴ価値を最大化するためのＩＴ戦略」

として具体化しようとしていた。初期の議論において、その必要性を確認し合意することはできたが、

明確な「定義」を見出すことから策定方法を論じるよりも、実質的な成果物である「ＩＴガバナンスの

ガイドライン」を作成し、より実践的に実施できるプロセスを示すこととした。

最後に、ＬＳ研各社において「わが社のＣＯＢＩＴ」を策定し、実践を積み上げ、評価結果を共有す

ることで「われわれのＣＯＢＩＴ」はさらに有意義なものに成熟することができる。その「実践」「共有」

こそが「ＩＴガバナンス確立」への一助となることを確信している。

2

LS 研: 情報システムにおけるリスクマネジメント


情報システムにおけるリスクマネジメント

－システム安定稼動におけるリスクの可視化－


２００２年春に発生した銀行のシステム障害は、企業の経営層には少なからずショックを与え、情報

システム障害が発生した場合の影響は、経営の悪化に直結していることを改めて認識させられることに

なった。情報システムについては、コストパフォーマンスを優先にとらえていた経営者も、リスクマ

ネジメントの重要性を真剣に考え始めた。情報システムを担当している部門にとっては、ＩＴ基盤を安

定稼動させるためにリスクの内容と影響を明らかにし、それらに対して適切な対応をとるとともに、サ

ービスレベルを維持管理することが非常に重要になってきた。

1. 研究の目的

企業において、経営層はリスクに対する対策の必要性を感じながらも、リスクとして具体的にどのよ

うなものが存在しているのか、また、そのリスクに対して、どの程度の対応を行うことが妥当なのかが

不明確であり、的確な対応をとることができない状態でいる。また、情報システム担当部門では、具体

的な費用対効果が明確にできないため、経営層を納得させるリスク対策の提案を行うことができない。

当分科会では、企業の経営層と情報システム担当部門の双方が漠然と感じている不明確さを明らかに

し、リスク対策の具体的提案を行える仕組みを考えることを研究の目的とした。

2. 研究の範囲

分科会参加メンバー各社の重要課題として、「システム運用時におけるリスクの低減」という意見が多

かった。これは、現場の危機感の現れであるといえる。そこで、当分科会では、『システムの安定稼動』

に向けてのリスク対策を経営層が判断するための材料となるリスク評価方法を検討することにした。

一般的にリスクマネジメントは、マネジメントサイクル（ＰＤＣＡ）に従い実施する必要があるが、

当分科会では、Ｐ（Plan）工程における、リスク分析，リスク管理に研究の焦点をあてることとした。

3. リスク分析／リスク管理の評価基準

一般論として言われているリスク分析／リスク管理手法を、自社において適用しようとした場合、手

法を理解し、適用するためにカスタマイズを行い、手順書等を作成するといった作業が発生する。これ

らの作業をできるだけ軽減し、誰にでも理解できる手法を簡潔にまとめることができた。

当分科会では、システム利用者が容認できる使用制限の項目（システム停止時間，レスポンスタイム

等）とその数値（時間等）を、サービスレベルとサービスレベル許容値という形で定義し、これらを使

用することにより問題の解決を行った。

リスク明確化のポイントは以下の２点である。

① サービスレベル許容値を超える状態をリスクと定義し可視化すること

② 脆弱性は脅威の要素として含めること

この考え方から、リスク値を以下のように計算することとした。

リスク値＝Ｔ×（Ｄ－Ｒ）

（Ｔ：脅威の発生頻度，Ｄ：脅威発生時におきる被害の値，Ｒ：サービスレベルの許容値

※ （Ｄ－Ｒ）は被害の大きさを示す）

この式の意味は、以下のように捉えることができる。

① ‘Ｔ×’は被害が小さい場合でも頻発する脅威はリスクが高いことを意味している。

② ‘Ｄ－Ｒ’は、サービスレベル許容値以内の被害値であれば、

リスクとはしないことを意味している。

3

LS 研: 情報システムにおけるリスクマネジメント


　　　リスク管理　　　リスク管理

現状分析　　　　　「業務要件書、システム仕様書、システム構成図等」現状分析　　　　　「業務要件書、システム仕様書、システム構成図等」

業務・資産対応表業務・資産対応表

脅威一覧脅威一覧

リスク分析表リスク分析表

業務、サービスレベルを抽出し、サービスレベル許容値を設定

業務・サービスレベル対応表

業務・サービスレベル対応表

業務が使用する資産を抽出

資産毎の脅威を抽出

業務毎の脅威に対する停止時間と現状対策を抽出し、記入

業務毎の脅威に対する追加対策とその費用を検討し、記入

追加対策により改善された停止時間と発生頻度を記入

リスク対策前後のリスク値と対策コストを比較し、適切なリスク対策の実施を計画

リスク値の妥当性について適宜見直しを行う

1 2 3 45

*A

*B

*Ａ：「システムの安定稼働に対する脅威表」（当分科会で作成）

*Ｂ：「リスク分析ツール」（当分科会で作成）

*B

0

4. リスク分析／リスク管理の手法

リスクを可視化するために、現状分析からリスク管理に至るプロセスを策定した。リスクを数値化す

るために必要な情報（サービスレベルの決定、業務・資産・脅威の一覧）を整備しリスク分析表を導き

出す。リスク管理を容易に行うためのツールを当分科会で独自に作成した。概要は下図のようになる。

5. 適用事例（架空会社）

リスク分析／リスク管理の手法を実際に架空会社に適用した。業務分析を行い、業務・サービスレベ

ル対応表、業務・資産対応表、脅威一覧を分科会メンバーの実務経験を反映しながら作成した。リスク

評価作業として、この基礎資料をもとに適用する対策とそのコストおよび効果の組合せにより複数のリ

スク分析表を作成した。リスク管理として、リスク分析表の結果から最適なリスク対策を選択した。リ

スク管理にて、選択した対策の効果を表したのが下図である。

近年、情報システムにおけるリスクマネジメントは、企業経営のリスクマネジメントの一要素として

考えられてきている。全社的なリスクマネジメントシステムのポリシーにしたがって、情報システムの

リスクマネジメントも行われていくことになる。方針の策定、対策の選択基準、実施対策のチェック体

制、経営によるレビューなどは、生産や販売に関わるリスクマネジメントとベクトルを合わせて遂行し

ていくことになるであろう。

0 200 400 600 800 1000

リスク区分別リスク値累計

追加対策実施前

追加対策実施後

リスク値の比較

停止許容時間内～1 時間～4 時間

～8 時間～1 日～2 日

～1 週間 1 週間以上

4

LS 研: プロセス改善のためのＣＭＭ導入指針(CMM Level5)


プロセス改善のためのＣＭＭ導入指針－CMM Level5 認証（達成）に向けて－


CMM の成熟度段階はレベル１からレベル５まである。レベル３に達した組織は CMM でいうと「定義さ

れたレベル」と呼ばれ、属人的なプロセスから脱却した組織的な標準プロセスをもつ組織である。ソフ

トウェアプロセスについては、組織の標準が用意され、プロジェクトの品質活動のバックボーンとなる。

ソフトウェアプロセスデータベースも組織的に用意され、過去の経験は組織的な管理のもと、プロジェ

クトプロセスに、また製品品質に有効に活用される。このレベルに到達した組織は、製品品質に大きく

寄与するプロセスを持ち合わせた組織であると言ってよい。

だが正直言って我々の業界の一般的な実情から察すると、レベル３のような組織は寡少な存在である

とも言える。いきおい「ＣＭＭの成熟度はこのレベルまでで十分ではないのか？」という見方がよくで

てくる所以でもある。また同時に、我々の周囲には伺い知れるレベル３以上の達成企業の事例も少ない。

果たしてレベル３達成以後レベル４，５の世界が我々の組織に寄与してくれるものは何であろうか？

１．ＣＭＭの全体構成の把握

本分科会ではＣＭＭの全体像を理解・把握するため、独自のアプローチを用いた。レベル２からレベ

ル５までのＣＭＭの記述に登場する「役者」を「上級管理層(SM)」「ソフトウェアエンジニアリングプロ

セスグループ(SEPG)」「プロジェクトソフトウェアマネージャ（PjSM）」「ソフトウェア品質保証グループ

(SQA)」「ソフトウェアエンジニアリンググループ(SEG)」「トレーニンググループ(TG)」「ソフトウェア構

成管理グループ(SCM)」の７者に限定して考察を進めた。この理由として多くのソフトウェア組織は現実

このくらいの役者がそろえば十分であろうと考えたこと、又、ＣＭＭで要求することを主体的に実施す

る者はだれかを比較的容易に整理・把握できることがある。ここではＣＭＭの KPA 記述に明記されてい

る主体的作業者には◎、表記はないが担当と解釈できる者には○、主体的作業者に強く関連する者には

△、主体的作業者では無く弱く関連する者には▲をつけてその立場を注釈した。（図１）

この方法論の採用は我々のＣＭＭ理解をかなり効率

的にしてくれた。一方で実際の高レベル組織の調査

もヒアリング等試みた。その結果おぼろげながらみ

えてきた高レベル組織の姿がある。

２．高レベル組織はどういう組織か

レベル 4は「管理されたレベル」と呼ばれる。ソ

フトウェアプロセスが十分に定義され首尾一貫した

測定手法を備えている。このため、プロセスパフォ

ーマンス内のランダムな変動と意味ある変動を区別

することができる。従ってそのソフトウェアプロセ

スで実施される能力は「定量化可能」「予測可能」、

ということが特徴である。これにより限度を超える

事態が予測されるとき事前に是正の処置がとられ、

ソフトウェア成果物は予測可能で高品質なものとな

る。

ＴＩＭＥ　→

ＵＣＬ

ＬＣＬ

意味のある変動Special cause of

variation

ランダムな変動（ノイズ）

Randum variation

ＴＩＭＥ　→

ＵＣＬ

ＬＣＬ

ＬＥＶＥＬ４ＬＥＶＥＬ４

ＬＥＶＥＬ５ＬＥＶＥＬ５

図１ KeyPractice と主体的作業者

図２プロセス内の変動

KPACommonFeature

上級管理層

ＳＥＰＧ

プロジェクトソフトウェアマネージャ

ＳＱＡ

ソフトウェアエンジニアリンググ

ループ

ﾄﾚｰﾆﾝｸﾞグループ

SCM

定量的プロセス能力 1 組織の定量的プロセス管理活動の調整に責任を持つグループが存在 ○ ◎

管理する。

2 定量的プロセス管理活動のために適切な資源と資金が提供される。 ◎

3 選択されたプロセスおよび成果物の計測のためのデータの収集、記 ○ ○

録、および分析に対する支援が存在する。

Key Practi ces

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

5

LS 研: プロセス改善のためのＣＭＭ導入指針(CMM Level5)


次の段階のレベル 5は「最適化するレベル」と呼ばれる。弱点を把握する手段をもち、ソフトウェア

プロセスを評価することで欠陥の予防が可能となり、過去の教訓を組織全体に広めてゆく。非効率的な

共通原因を取り除きプロセスは改善されてゆく。これに従い管理指標値も収束してゆく。（図２参照）

３．高レベル組織の分析

図１に示す表を基本として我々は高レベル組織の分析を試みた。図１での◎(=1)、○(=1)、△(=1)、

▲(=0.5)の数を集計して表及びグラフにしたものが図３である。これらから高レベル組織に関しては以

下の事が読み取れる。

■ ＳＥＰＧの役割は高レベルになるに従って、ますます増加してゆく。

■ ＳＱＡは高レベルとなっても役割は減少しない。

■ プロジェクトソフトウェアマネージャは高レベルになるに従って、各レベルにおける役割は減少

してゆく。

■ ソフトウェアエンジニアリンググループの役割はレベル４まで増加し続け、レベル５の段階で減

少する。

我々が企業のヒアリング、或いは資料研究で

収集した情報によると、高レベル組織は CMM

の浸透活動もさることながら、それ以外にも

プロセスに関連する様々な活動をしている。

これらはいずれも「個人」に着目したものと

いう共通項を持っている。（PeopleCMM(Bill

Curtis)、PSP(Personal Software Process:

Watts Humphrey)など。） Bill Curtis は、

レベル３までは組織中心に組織的なプロセス

を定義し、これを根付かせたあとは個人への

信頼用でプロセスが実施される、と言ってい

る。ソフトウェアエンジニアリンググループ

の役割増加はそれを裏付けるものだとも思え

る。だが、現実的には組織の力、例えばＳＱ

Ａのような監査を実施する立場の組織は以前

として必要である。着目すべきはＳＥＰＧで

ある。組織プロセスに責任を持つ組織は、ま

すます増強が必要であることは分析結果が物

語っている。

４．組織が高レベルを目指す必要性

レベル３が属人的な作業から脱却して組織的なプロセスをもつレベルというのであれば、ISO9000 導

入済み企業がまずこのレベルを目指すのは自然な流れである。CMM 導入後は一日も早くレベル３を目指

し、開発者にこの効果を認識させることが肝要と我々は考えるが、この達成後のその先、具体的にどう

なるのであろうか？レベル４でいう「予測が可能」な組織に到達するために必要な期間は約３０ヶ月と

もいわれている。組織はこの間、活動を確実に維持しデータを蓄積してこれを有効活用してゆくことが

重要である。これによりプロジェクト、そしてマネージャーはより科学的な判断にたちプロジェクトの

コントロールが可能になる。大きな恩恵である。高レベル組織の如何を問うまでもなく、レベル３組織

がプロセス改善に真摯にとりくめばこの状態に達することになり、これは必然的に高レベルの世界とな

る。従ってレベル３の組織になって「もうここでいい」ということは、これらのデータ蓄積をはじめと

するプロセスが形骸化することに他ならない。組織プロセスの後退を意味する。

５．高レベル推進への提言

レベル４に到達する期間は約３０ヶ月必要といわれている。ＳＥＰＧはますます増強が必要になる。

ＳＱＡもなくなる事はない。従って上級管理層（経営者）には、この熟成に必要な期間への忍耐と組織

的な推進強化への投資が求められる。組織はレベル３の段階にとにかく達することだ。そしてそれ以降

のデータ活用、開発標準などＳＥＰＧに積極的に経営資源を投入するべきである。だがこの先に進んで

ゆくためには「個人」のプロセス推進力もおおきな要素となる。このため「個人」の育成、職場環境な

ど、従来の取り組みをますます見直さねばならない。企業は留まってはならないのである。

図３成熟度向上に伴う各グループの負荷

6

ＬＳ研:企業グループにおけるシェアードサービス


企業グループにおけるシェアードサービス

－競争力を高める経営改革手法－


１．研究の目的

企業グループにおける経営効率化のための手法として、近年「シェアードサービス」が注目され始め

ている。一般的にシェアードサービスとは、企業グループ内のいわゆるノンコア業務を標準化、集中化

して効率化を図る経営手法であると言われている。当分科会メンバーは経営層から「経営改革」に関わ

る課題を問われる立場にあるため、この手法は現実に自分たちの企業グループに適用すると効果がある

ものなのかどうかという疑問から、当分科会の研究目的を「シェアードサービスの有効性の検証と具体

的手順の明確化」に設定した。

２. 研究の概要

(1)シェアードサービスの実態把握

資料や文献から内外の実態を調べた。米国の大手企業ではシェアードサービスセンター（以下ＳＳＣ）

の導入が既に一般化したと言われている。各種の公開情報を集めると、国内でも各業界を代表する大手

企業グループを中心に３１社に導入されていた。シェアードサービスの有効性と導入手順を明らかにす

るために、取組みタイプの異なる４社を選び、ヒアリングやセミナー受講を行った。またコンサルティ

ング企業からコンサルティング事例や直近動向について情報収集をした。

表 1. 代表的な導入事例

取組ﾀｲﾌﾟ親会社内一組織ｸﾞﾙｰﾌﾟ内中心の共用会社外販も視野に入れた共用会社／カンパニー

企業ｸﾞﾙｰﾌﾟ富士通（株）パイオニア（株）コクヨ（株）オムロン（株）

背景･目的 1990 年代からのｸﾞﾙｰﾌﾟ経雇用を維持しつつｸﾞﾙｰﾌﾟ事ｸﾞﾙｰﾌﾟ間接ｺｽﾄの明確化本部の人員肥大化･ﾙｰﾁﾝ

営効率化要請.成果主義務･間接業務を全体最適化･とｺｽﾄ削減.ｵﾌｨｽのﾊｰﾄﾞ埋没にﾄｯﾌﾟの危機意識.

への人事の集中･ｵｰﾌﾟﾝ化. ﾌﾟﾛｾｽ改革し連結でｺｽﾄ削減. 販売からｿﾌﾄ販売への戦略立案と業務支援分離.

事務処理迅速化･効率化. 戦略立案と業務支援分離. 拡張. ｻｰﾋﾞｽのｱｳﾄｿｰｼﾝｸﾞ事業化.

効果間接ｺｽﾄ年 60 億相当の削減. ｺｽﾄﾀﾞｳﾝ､品質維持､ﾜﾝｽﾄｯﾌﾟｺｸﾖ側 2 億､SSC 側 20%のｺｽﾄ本社 800 名を､戦略機能

成果主義徹底.入力･承認ｻｰﾋﾞｽを目指し､初年度は削減.顧客満足度は 70 点､ 300 名に絞り本業へ 150

簡素化.ﾜﾝｽﾄｯﾌﾟｻｰﾋﾞｽ化. 目標を上回るｺｽﾄ削減を実現. 従業員満足度は 60 点に向上. 名ｼﾌﾄ.本社費 27 億削減.

成功ﾎﾟｲﾝﾄﾄｯﾌﾟの意思と一貫性.詳細なﾄｯﾌﾟﾀﾞｳﾝ＋ﾁｪﾝｼﾞﾘｰﾀﾞの力. ﾎﾞﾄﾑｱｯﾌﾟで事業意識高揚. ﾕｰｻﾞと専売権を約束し

業務ﾌﾛｰ分析と標準化.部門 ABC/ABM による課金体系. 定型業務は利益 0､ｽﾎﾟｯﾄ見返りに年 5%削減保証.

長へ承認権限委譲.まず人材顧客好感度調査への対応. 外販で稼ぐ構造.詳細な現場経理へﾊﾟﾗﾀﾞｲﾑｼﾌﾄ.

を集中し現実的に改善推進. 目標達成連動型成果配分. 業務分析･ｺｽﾄ分析. ﾒﾆｭｰ工数別原価管理.

苦労した点現業部門の意識転換. 現場に配慮し段階的に拡大. 本社･子会社との業務の市場価格化､ﾓﾁﾍﾞｰｼｮﾝ UP

今後の課題要員のｻｰﾋﾞｽ意識改革､ﾓﾁ本社意識の排除･ﾓﾁﾍﾞｰｼｮﾝ切分け不明確.事業会社のため外販へ.顧客評価

ﾍﾞｰｼｮﾝ･専門性向上･配転. 維持の仕組.現場への営業. としての真の自立化. QCD 向上を社員評価連動.

この事例研究から我々は、文献からは知り得なかった次の課題や困難さを共通認識とすることができた。

・ＳＳＣの成功には、分社化の如何を問わず、モチベーションの確保と教育が最重要課題である。

・ＳＳＣは、雇用の確保が前提、またはそれを強く意識しているケースが成功しやすい。

・トップダウンとプロジェクトリーダーの改革への強い意思、抵抗勢力に対する配慮が鍵。

・はじめからすべての会社に適用しようとせず、できるところから、スピードを持ってやる事が重要。

・外販するしないに関わらず、市場価格を意識した価格低減や付加価値提供を継続することが重要。

・継続的なコストダウン・サイクルの実現と、利用者拡大の努力を続けていくことが発展の鍵。

・効率化への取組みの成熟度の高さが、短期間でＳＳＣを成功裡に立上げる主要因とみられる。

(2)シェアードサービスのさらなる考察と定義

当分科会ではさらなる考察に基づき、シェアードサービスに必須と思われる要素を織り込み、次のと

7

ＬＳ研:企業グループにおけるシェアードサービス


おり定義づけを行った。「シェアードサービスとは、企業グループ内の雇用を維持しながら共通業務を集

中して効率化と専門化を図り、企業グループ全体最適による競争力強化を目指す経営手法である」。 (3)シェアードサービスの有効性と留意点の確認

我々は実態の検証を経て、シェアードサービス化が効果を生み出していることを確認できた。ただ、

その成功の陰には、留意しなければならない多くの課題があることも理解した。

表２. シェアードサービスの有効性と留意点

シェアードサービスの有効性シェアードサービス化の留意点

①ｸﾞﾙｰﾌﾟ資源（人･物･金･情報）のコアビジネスへのシフト ①配置転換される従業員のﾓﾁﾍﾞｰｼｮﾝ低下に備えた各種施策

②共通業務の集約化によるコストダウン ②大幅な変革に対する抵抗勢力出現への施策

③事務的処理から利益追求型への意識改革 ③スケールメリットを確保できる進め方や仕組み作り

④標準化・システム化による品質向上 ④経営トップの強い意思表示

⑤雇用の維持を図り易い経営改革手法 ⑤ＳＳＣ設立後への配慮

(4)手順書の作成と評価

これまでの研究成果の集大成として、シェアードサービス化のための具体的手順を策定した。まず、

このテーマが経営戦略そのものであるので、我々ＩＴ部門の枠を超えて全社の戦略部門挙げての取組み

プロセスの提示を念頭においた。また導入検討／企画立案／実施・展開のそれぞれのフェーズに、通常

は気付きにくい注意点を織り込みながら、各企業固有の風土・文化の如何に拘らず活用が可能な、標準

的な手順作りを心がけた。さらに先進導入企業等の第三者評価を受け、「狙いの明確化が欠落」「人間に

関わる部分の掘下げが物足りない」「スピードをもっと強調すべき」等の指摘を踏まえて改訂を加え適用

に供する水準の手順書として完成をみた。手順書類としては、以下の５つを作成した。

図１. 作成手順書類とその抜粋（実施・展開フローおよび手順書）

３．経営トップの方へ ―結論に代えて―

シェアードサービスは、コアビジネスの強化によってグループ全体の競争力を高めるための、有効な

経営改革手法である。しかしながらその成功には多くの解決すべき課題があり、安易な取組みには危険

が伴うため、導入にあたっては以下の点に留意する必要がある。

①トップが前面に顔を出し、抵抗勢力への最終的な説得やプロジェクトの後ろ盾になる。

②プロジェクトトップにはグループ会社に影響力のある人、メンバーには精鋭を投入する。

③ＳＳＣ設立のグランドデザインを描き、示し、従業員のモラールの維持・高揚に十分に配慮する。

④ＳＳＣの有効性を見極めて、一度に全部ではなく、やれるところから段階的にやる。

⑤人材育成・教育、システム整備などの必要な投資は惜しまない。

最後に、経営トップの強い一貫した改革への意思表明と強力なリーダーシップが、成功への鍵である

ことをご理解いただきたい。

導入検討企画立案実施・展開

・ｼｪｱｰﾄﾞｻｰﾋﾞｽ化検討要否のﾁｪｯｸｼｰﾄ・ｼｪｱｰﾄﾞｻｰﾋﾞｽ化企画立案ﾌﾛｰ

・ｼｪｱｰﾄﾞｻｰﾋﾞｽ化企画立案の手順書

・ｼｪｱｰﾄﾞｻｰﾋﾞｽ化実施・展開ﾌﾛｰ

・ｼｪｱｰﾄﾞｻｰﾋﾞｽ化実施・展開の手順書

8

LS 研: 企業グループの情報セキュリティ対策


企業グループの情報セキュリティ対策

－グループセキュリティ対策の実践－


１．背景

インターネットの普及により、情報漏洩、ホームページ改竄、コンピュータウィルス被害などは、一

般的なニュースとして取り扱われ、情報セキュリティ対策への関心が高まっている。

企業においても、企業間電子商取引、電子メールなどの利用拡大により、情報セキュリティ対策が重

要になっている。一度セキュリティ障害が発生すれば、業務の停止や復旧コストなどの直接的なダメー

ジ以外に、企業イメージのダウンや株価下落など信用の失墜による 2次的ダメージが発生する。

また最近、システムダウンや個人情報漏洩などの不祥事が多発している。グループ本社名やグループ

名で報道され、原因や責任の所在に関わらず、グループ全体の信用失墜につながっているケースが多い。

２．情報セキュリティに関する現状

２．１情報セキュリティへの取り組み（％）（2002 年調査データ N+I Network Guide 誌）

会社規模経営課題として認識システム部門が対応ポリシー導入

30 人未満 9.8 7.2 11.1

100 人未満 11.9 15.0 15.0

300 人未満 16.2 28.1 22.7

1000 人未満 20.8 38.1 29.2

1000 人以上 43.0 34.5 51.5

計 20.3 24.6 24.8

２．２セキュリティマネジメントの認知度（％）（2002 年調査データ N+I Network Guide 誌）

会社規模熟知し導入済み導入検討中知らない

30 人未満 3.7 4.9 42.4

100 人未満 7.9 9.9 34.4

300 人未満 7.6 13.0 28.6

1000 人未満 11.9 17.9 26.8

1000 人以上 27.3 16.4 23.9

計 11.4 11.0 36.1

２．３セキュリティポリシーの内容（％）（2002 年調査データ N+I Network Guide 誌）

環境・物理教育・訓練通信・運用資産管理法的準拠

導入済 32.9 24.5 34.3 19.5 18.1

導入予定 16.9 19.4 18.0 14.5 17.8

検討中 9.9 13.2 9.6 15.3 13.2

導入予定無し 7.4 9.5 6.4 9.1 8.7

わからない 32.9 33.4 31.7 41.6 42.2

３．本分科会の問題意識と研究方針

上記調査データから、以下のことが読み取ることができる。

・ポリシー導入率と認識率には相関があるが、システム部門主導でポリシーを策定しているケー

スがまだまだ多い。

・セキュリティ対策は継続的な改善サイクルが必要であるにも関わらず、セキュリティマネジメ

ント手法の認知度が極めて低い。

9

LS 研: 企業グループの情報セキュリティ対策


・ポリシーを導入しているにも関わらず、「わからない」という回答が極めて多い。

本分科会は、システム部門またはシステム子会社などに属するメンバーで構成されている。我々の果

たすべき役割は、既存のシステム技術分野のみならず、システムの活用や定着およびより上位の経営課

題や戦略への参画が求められている。本分科会では、以下の研究方針に基づき研究を実施することとし

た。

・「ソリューション」や「システム」の適用を研究の主眼から外す

・「仮想企業グループ」での実践シミュレーションを実施する

・国際標準・国際基準を適用する

４．研究内容と成果

我々は、分科会を通じて、以下の概念を明確にし、グループ経営におけるセキュリティ対策の実践シ

ミュレーションを実施した。

(1) ポリシーの重要性について

ポリシーとは、共通ルールの集まりである。ポリシーが明確に定義され認知されていれば、個

人の勝手な判断によるリスクを低減することができる。ポリシーを継続的に改定することで、リ

スクは企業レベルで低減されることになる。

(2) 情報セキュリティポリシーの重要性について

企業における資産は、「人」「もの」「金」に加え、「情報」「信用」が重要視されている。ＩＴに

より情報は活用度を増し、資産価値を増大させるが、ＩＴによって信用も失うこともある。ＩＴ

でのセキュリティ対策は必須であるが、それを支えるのは、ポリシーであることは言うまでもな

い。どのような管理をするべきかを決めるのはポリシーであり、それに準じたセキュリティ製品

を選択しなくてはならない。

(3) 情報セキュリティ対策を推進するには

ＩＴの発達により、リスクは確実に分散し、管理が困難かつ複雑になっている。セキュリティ

対策を実施する際、脅威の分析が必須であるが、情報の持ち出し、改ざんなどの方法は、従業員

であれば簡単に行える。結果としての脅威は、イメージダウンや信用の失墜による取引停止、社

会的制裁（株価下落）など企業の存亡を揺るがしかねない。これは明らかに経営課題であり、経

営の脅威である。もはや、情報セキュリティ対策に経営層の参画は不可欠なのである。

(4) グループ経営時代に対応するには

経営層への動機付け、グループセキュリティポリシー策定プロジェクトの実践シミュレーショ

ンを実施した。労務、法務、人事、システムなど各部門の連携と関係会社との調整、統合など、

我々では簡単に解決できない多くの複雑な課題があることを再認識させられることとなったが、

以下のヒントを得ることができた。

a. グループ経営における情報セキュリティ対策のあり方

b. グループ統制として本社の果たすべき役割

５．結論

グループ経営における究極の課題は、経営資源として「人」「もの」「金」「情報」「信用」を正しく捉

え、シナジー効果を増大させることと考える。ダイナミックなグループ内連携、共同事業、新規事業創

出を実施できるグループを形成できるかが課題ではないだろうか？グループとしての競争力を維持・増

大させるために、グループ共通のコンプライアンスの確立、情報取り扱いの標準化（グループセキュリ

ティポリシーの策定）、グループ全体の信用の維持・増大（グループでの PDCA 確立）、ＩＴ武装による情

報の高度活用と競争力強化とを前向きに本テーマと捉え、立ち向かって欲しい。

本報告書を参照いただき、

・コンサルティングの事前シミュレーション

・情報セキュリティ対策、体制の見直し、グループポリシー策定の手引き

・経営課題としての認識

・経営層への提言

などに活用頂き、経営層、システム部門の各ポジションの方が、前向きに情報セキュリティ対策を捉

えていただければ幸いである。

10

LS研:製造業におけるＣＲＭを活用したサプライチェーンの構築

2002年度研究成果報告書

製造業におけるＣＲＭを活用したサプライチェーンの構築

－ＳＣＭを成功に導くためのＣＲＭの活用－


1. 研究の背景と目的

製造業の多くは企業内・企業間のチェーンを強化し、プロダクトを市場へ最適供給するためにサプ

ライチェーンマネジメント（ＳＣＭ）を導入している。更に企業活動の向上を目指すには、カスタマ

ーリレーションシップマネジメント（ＣＲＭ）を活用することにより、市場や顧客の情報をサプライ

チェーンに取り込むことが有効であると言われ始めている。しかしながら、ＳＣＭとＣＲＭはそれぞ

れ独立した形で導入・発展してきているため、速やかな融合の実現が困難である。そこで、当分科会

ではＳＣＭとＣＲＭの融合を速やかに実現させる新ビジネスモデルの策定を目的とした。

2. 新ビジネスモデル策定に向けた研究項目

①ＳＣＭとＣＲＭの定義

当分科会として、ＳＣＭとＣＲＭの内容を定義しメンバの認識を統一させ、研究範囲を明確化した。

②ＣＲＭの事例研究

各種文献や事例を研究し考察すると、「優良顧客を峻別し囲い込む」「顧客ニーズを的確に把握す

る」ことがポイントであると認識した。

③ＳＣＭの事例研究

メンバ企業のＳＣＭの事例を取り上げて調査した。現状でも解決できない残課題があることを確認

できた。

④ＣＲＭの活用による解決可能なＳＣＭの課題を抽出

現状の標準的な業務フローを作成し、ＳＣＭの課題を洗い出した。事例研究の考察結果を元にＣＲ

Ｍの活用により解決できると考えられる課題を抽出し整理すると、「需要予測精度の向上」、「生産

の効率化」、「調達の効率化」、「Ｗｉｎ－Ｗｉｎ関係の確立と継続」の４つの重要課題に分類された。

3. 研究成果

① 新ビジネスモデル策定

ＳＣＭとＣＲＭを融合させた新ビジネスモデルを以下のように作成した。サプライヤメーカ

顧客（卸・小売・商社）

生産部門販売部門調達部門

　顧客情報・販売計画 /実績・イベント情報 etc.

終顧客

ニーズ

工程進捗在庫情報

需要予測販売計画

販売調達生産物流購買


ﾒｰｶ選定

生産物流販売調達

供給計画

工程進捗在庫情報廃番情報

ﾏｰｹｯﾄ分析

購買計画情報開示

顧客峻別

工程進捗情報開示

共同商品開発

物流販売

購買計画

生産計画情報開示

在庫 /生産 /調達計画

メーカ情報・生産計画

　・工程進捗　終顧客情報


情報公開・販売計画・イベント情報　　 etc.

ｻﾌﾟﾗｲﾔ選定

ｻﾌﾟﾗｲﾔ情報


サプライヤメーカ最終顧客

顧客（商社・卸・小売）

調達部門　　　　　　　　　生産部門　　　　　　　　　販売部門

サプライヤメーカ

顧客（卸・小売・商社）

生産部門販売部門調達部門

　顧客情報・販売計画 /実績・イベント情報 etc.

終顧客

ニーズ

工程進捗在庫情報


販売調達生産物流購買


ﾒｰｶ選定

生産物流販売調達

供給計画

工程進捗在庫情報廃番情報

ﾏｰｹｯﾄ分析

購買計画情報開示

顧客峻別


共同商品開発

物流販売

購買計画

生産計画情報開示


メーカ情報・生産計画

　・工程進捗　終顧客情報


情報公開・販売計画・イベント情報　　 etc.

ｻﾌﾟﾗｲﾔ選定

ｻﾌﾟﾗｲﾔ情報


サプライヤメーカ最終顧客

顧客（商社・卸・小売）

調達部門　　　　　　　　　生産部門　　　　　　　　　販売部門

11

LS研:製造業におけるＣＲＭを活用したサプライチェーンの構築

2002年度研究成果報告書

② 新ビジネスモデルの特徴

前述で分類した４つの重要課題は、従来のビジネスモデルにはない、新ビジネスモデルにおける

６つの画期的な特徴を活かすことで解決できると考える。

新ビジネスモデルの特徴解決されるＳＣＭの課題

(1)顧客情報を活用した需要予測需要予測精度の向上

生産の効率化

(2)メーカ内工程進捗情報の顧客への開示Ｗｉｎ－Ｗｉｎ関係の確立と継続

(3)メーカ内顧客峻別Ｗｉｎ－Ｗｉｎ関係の確立と継続

(4)メーカ内生産計画のサプライヤへの開示調達の効率化

Ｗｉｎ－Ｗｉｎ関係の確立と継続

(5)顧客購買予定情報のメーカへの開示生産の効率化

(6)最終顧客の市場動向情報を活用した顧客と

の共同商品開発

Ｗｉｎ－Ｗｉｎ関係の確立と継続

我々の提案する新ビジネスモデルは、ＣＲＭから顧客情報を取り込むのは勿論のこと、ＣＲＭを

介して自社の有益な情報を開示し、双方でＷｉｎ－Ｗｉｎ関係（顧客－メーカ、メーカ－サプライ

ヤ）を確立させている。また、確立させた強固なＷｉｎ－Ｗｉｎ関係は以下に記述した内容にて永

続的なものをめざしている。

・メーカが持つ技術力と顧客が持つ最終顧客ニーズを元に新商品を共同開発することをサポート

する仕組み

・メーカが持つ生産・調達計画とサプライヤが持つ供給計画を元にＶＭＩが強化され、双方の不

要在庫を削減し、原料・資材在庫の適正化を実現する仕組み

＊ＶＭＩ：Vendor Managed Inventoryの略。納入業者による納入先の在庫管理

新ビジネスモデルのコンセプトを図で表すと以下のとおりであり、従来の平面のサプライチェー

ンから強固なパートナーシップを永続的に継続させるカスタマーバリュー軸（時間軸）を奥行きに

とり、立体のイメージで表した。

4. 提言

製造業におけるＣＲＭを活用したサプライチェーンの構築について以下のように提言する。

１．ＣＲＭはもはや単体としてのツールではないため、ＳＣＭと融合し効果を上げよ！

２．ＣＲＭによって優良顧客を囲い込め！

これからは永続的なＷｉｎ－Ｗｉｎ関係を確立するＳＣＭだ！

３．情報公開を恐れるな！情報共有化で効果をあげよ！

新商品共同開発

サプライヤメーカ顧客

サプライチェーン

カスタマー

バリュー軸商品提供サイクル

販売調達・生産･物流・販売

供給計画、調達計画、生産計画

調達・生産･物流・販売

販売調達・生産･物流・販売調達・生産･物流・販売



CRM DBCRM DB


サプライヤメーカ顧客

サプライチェーン

カスタマー

バリュー軸商品提供サイクル

販売調達・生産･物流・販売


調達・生産･物流・販売

販売調達・生産･物流・販売調達・生産･物流・販売



CRM DBCRM DB

12

LS 研:情報システム部門の人材育成


情報システム部門の人材育成

－職種別コンピテンシーモデルの作成と活用－


1. 研究目的と着眼点

『情報システム部門の人材育成』は古くて新しい研究テーマである。これまでにも、ＩＴエンジニア

の人材モデルの作成やスキルＤＢの構築を通してＩＴエンジニアの育成に取り組んできたが、多くは当

初の期待に反して充分な成果を上げることができなかった。昨年末、経済産業省から『ＩＴＳＳ（IT Skill

Standard）』が発表された。各種ＩＴ関連サービスの提供に必要とされる能力を明確化・体系化した指標

とあり、スキル項目ごとに成熟度と知識項目を体系化したことには意義を感じるが、我々現場第一線の

育成担当者に具体的な育成方法を提示するものではなかった。

そこで、当分科会では現場で使えるＩＴエンジニア、信頼できるＩＴエンジニアの育成を、これまで

にない独自の視点で捉え、新たな育成方法の提案にチャレンジすることとした。近年コンピテンシーマ

ネジメントが静かなブームとなっているが、我々も、これまでの知識・スキルベースの育成体系になか

った『行動』に着目した。豊富な知識、高度なスキルも正しい行動があって初めて高い成果につなげる

ことができる。我々は、ＩＴエンジニアが高い成果を上げるために取るべき『基本行動』と、それら基

本行動に共通する『行動特性』について分析した。そして両者の相関関係を明確にすることにより、新

たな育成方法の突破口を見いだすことができた。

2. 高パフォーマの行動をベースとした職種別基本行動表

まず、一般的なコンピテンシーマネジメントのセオリーに従い、高い成果を上げている人材の行動（以

下「基本行動」）に着目した『高パフォーマ分析』を行った。当分科会参加各社の優秀なＩＴエンジニア

の行動を分析し、プログラマ、アプリケーションエンジニア、プロジェクトマネジャーの職種別基本行

動表を作成した。例として、プログラマの基本行動表の一部を示す。

3. ＩＴエンジニアの職種別コンピテンシーモデル

次に、我々は優秀なＩＴエンジニアに共通する行動特性(行動のパターン)３８項目を議論により洗い

出し、それと前項の職種別基本行動表とのクロス分析を行うことにより、最重要行動特性１０項目から

なる職種別コンピテンシーモデルを作成した。

我々は、これらのコンピテンシーモデルの信憑性を検証するために、後述する『行動特性評価シート』

を使用して、分科会参加各社のエンジニア６４名をサンプリング評価し、モデルの信頼性を確認した。

1 設計書の不明確な点は、自分で創造せず、ＳＥに確認する。

2 設計書が必ず正しいとは思わず、正しくないと思ったらＳＥに指摘する。

3 設計書に記述されている内容が、全てプログラムに反映されているか確認する。

4 生産性と品質の向上のために、雛形プログラムや共通部品を最大限利用する。

15 自分で解決できない問題が発生したい場合は、抱え込まず、上司に相談する。

16 テスト項目によって、プログラムの全ラインをテストすることができるか確認する。

17テストデータの件数や内容を確認する（「例外が発生するテストデータが存在するか」など）。

18 本番環境とテスト環境の違いを認識しておく。

19結合テストや総合テスト（システムテスト）工程では、バグや不具合を発見したとしても勝手にプログラムを修正せず、ＰＭやＳＥの指示を仰ぐ。

20 バグや不具合の原因が分からない場合は、早めに他人にコードレビューしてもらう。

21 工程が遅れていたとしても、テスト項目を減らさない。

プログラミング1

テスト2

No 工　程備考行基　本　行　動

13

LS 研:情報システム部門の人材育成


例として、プログラマのコンピテンシーモデルを示す。

Ｎｏ

1

2

3

4

5

6

7

8

9

1 0

客観的に物事を捉えられる

上司・リーダー・メンバーへタイミングよく「報告・連絡・相談」をしている

ルールを遵守している

自己レビュー（自分のやったことを見直す）をしている

行　動　特　性

危機意識（これをやらなかったら／できなかったら）を持って仕事をしている

結果を考えた行動をしている

チームワークを重視して仕事をしている

自分の責任範囲を理解して仕事をしている

プロとしての自覚と誇りを持って仕事をしている

目的を明確にした行動をしている（「何となく」とか「言われたから」でなく）

4.人材育成への活用(提案)

以上はコンピテンシーマネジメントのＩＴエンジニアへの応用であるが、我々はこれらのモデルの

人材育成への活用に知恵を絞った。実際の人材育成を考えたとき、基本行動表は項目が多すぎて強化

項目を絞りきれず、コンピテンシーモデルは抽象的すぎて具体的な指導内容とならない。

そこで、職種ごとのコンピテンシーモデル開発の過程で得られた、基本行動と行動特性のｎ対ｎの

相関関係に着目した。つまり、ある基本行動を確実に実行するためには、複数の行動特性が身につい

ている必要があり、逆に、ある行動特性が身についていれば、複数の基本行動を確実に実行できる可

能性が高いということである(下図)。

高い業績基本行動（仕事軸）行動特性（人間軸）

我々は、育成方法の突破口として以下の３点を提案する。

(1) 多数の行動特性に導かれる基本行動を抽出し、この基本行動を日々の指導項目として育成する。

(2) コンピテンシーモデルを評価項目として人材評価を実施し、弱いと判断された行動特性に関連

した基本行動を強化項目とする(下記に評価シートの一部を示す)。

(3) ケーススタディによる疑似体験を通して基本行動の強化を図る。あれこれ口で言われるより、

どう行動するのがベターか自ら思考することが行動力強化の早道と考えるからである。

コンピテンシーマネジメントなどと聞くと身構えてしまい、コンサルタントの指導がないとできな

いと思っていないだろうか。現場の人間が集まって議論するだけでここまでできるのである。是非我々

の成果(各種シートとアプローチ方法)を活用して、効果的な人材育成にチャレンジしていただきたい。

被評価者経験年数評価日

ランクチェック

Ａ

Ｂ

Ｃ

Ｄ

Ａ

Ｂ

Ｃ

Ｄ

Ａ

Ｂ

Ｃ

Ｄ

Ａ

Ｂ

Ｃ

Ｄ

自分の責任範囲を理解して仕事をしている

1 プロとしての自覚と誇りを持って仕事をしている

2 目的を明確にした行動をしている（「何となく」とか「言われたから」でなく）

評　価Ｎｏ行　動　特　性

3 危機意識（これをやらなかったら／できなかったら）を持って仕事をしている

4

プログラマ行動特性評価シート

年　　月　　日　評価者

チェック欄は「○」

ケース

現在、Ｏ社のＡ社へのレビューの確認も終わり、製造単体試験工程に入っていた。　また設計書がＦＩＸされたので運用を整理していたところ、A社よりこの運用では困るとのクレームがＯ社に入った。社内で検討した結果、設計の仕様変更が発生することになった。Ａ社に対し説明をし　仕様変更に関すること及び費用に関して納得いただいた。しかし、進捗状況を報告した際に、スケジュールが遅れ気味ではという指摘を受けた。　このままのプロジェクトメンバーだけでは間に合いそうもなく、増員の場合のコストの計算をしたが、

質問

　結果を考えた行動をしている。

　　今、Ｏ社では A社より受注した運用システムの開発に関するプロジェクトが進行中です。Ａ社は運用をベースにしたシステム設計を重要視し、Ｏ社にシステム開発依頼した。

　仕様変更が発生した場合、納期の遅延、または費用の増加となることを顧客に納得させる。（できるだけ仕様の変更を取り下げるように誘導する＞）

　あなたはＰＭとしてどのようなＡＣＴＩＯＮを取りますか？

ケーススタディ

行動特性

前提

基本行動

ケースＮｏ　ＰＭ（Ｂ）－２

品質の高いプログラム

雛形プログラムや共通部品を最

大限利用する。保守性の高い

プログラムまずはコメントを記述し、次にコ

メントに従ってプログラムを記

述する

テストデータの件数や内容を確

認する。

工程が遅れていたとしてもテス

ト項目を減らさない。

プロとしての自覚と誇りを持っ

て仕事をしている。

危機意識を持って仕事をしてい

る。

結果を考えた行動をしている。

コスト意識を持って仕事をして

いる。

自分の考え方を常にドキュメン

テーションしている。

14

LS 研:Ｗｅｂサービスの適用


Ｗｅｂサービスの適用

－今こそ取り組もう－


1. はじめに

今日、Web 上で動作するアプリケーション（Web アプリケーション）の利用は、企業および一般の利

用者に広まりつつある。２、３年程前からこの Web アプリケーションに新しい可能性をもたらす「Web

サービス」という技術が登場した。この技術を利用する事により、今までにない新しい Web アプリケー

ションの作成や新しいビジネスチャンスがあるなど、有効性、将来性のある技術と言われているが、実

態よりも世評が先行しているのが現状である。

2. 研究目的と研究手順

当分科会では、本当に、Web サービスは有効性、将来性のある技術であり、システムに適用して行く

べきなのかを明らかにする事を目的として、①WebアプリケーションとWebサービスの違いを把握する、

②技術的な有効性と将来性を確認する、③ビジネス的な有効性と将来性を確認するという観点で研究を

行った。研究手順としては、適用事例による分析から着手し、分析結果を受けて、実際にプロトタイプ

の構築・検証・評価を行い研究活動を進めた。

3. Web サービスとは

Web アプリケーションと Web サービスの違い

は右表に示すとおりであり、当分科会では、「Web

サービスとは、XML、SOAP、WSDL、UDDI を主な

技術要素とした疎結合型のシステム連携技術で

ある」と定義した。

4. Web サービスの有効性と課題

Web サービスの適用事例の分析から、適用パターンを導き出した。さらに、技術的、ビジネス的なメ

リット・デメリットを整理し、Web サービスの有効性と課題についてまとめた。

4.1 適用事例から導き出した適用パターン

適用事例から、次の３つの適用パターンを導き出し、その特徴をまとめた。

適用パターン特徴

システム連携人手が必要だった処理をデータ連携する事によって自動化する事が可能となる。既存システ

ム間とのデータ連携手段としても有効である。

サービス統合点在する各システムをポータルサイトにより仲介する事でサービスを統合して利用する事

が可能となる。複数のシステムを組み合わせるワンストップサービスの提供が可能となる。

機能提供必要なサービスや情報は、それらを得意とする企業に業務委託をするという事が可能とな

る。サービスの自動化、各種情報の提供。利用者はアプリに組み込んで利用する事も可能。

4.2 技術的・ビジネス的な有効性と課題

適用事例から、技術的な側面とビジネス的な側面について、有効性と課題についてまとめた。

研究の観点有効性課題

技術的・プラットフォームに依存しない

・疎結合による柔軟な対応

・ XML を利用する事による柔軟な対応

・相互接続の確認が取れていない

・処理速度

・トランザクション

・セキュリティ

ビジネス的・コストの削減

・新規ビジネスの創出

・データフォーマットの標準化

・商習慣の違い

比較項目 Web アプリケーション Web サービス

利用者人アプリケーション

言語 HTML XML

通信 HTTP SOAP

資源集中分散

15

LS 研:Ｗｅｂサービスの適用


5. Web サービスのプロトタイプによる評価

今回、プロトタイプとして、Web サービスの適用パターンの中から「サービス統合」によるワンスト

ップサービスを構築する事とし、「旅行代理店システム」を選定した。

プロトタイプによる評価項目は、適用事例の分析結果を基に、開発手順、相互接続性、性能、拡張性、

セキュリティの５点について検証・評価を実施した。以下にプロトタイプの概要と評価結果を示す。

①旅行者

インターネットを利用して、旅行代理店の Web サイト

より、航空会社と宿泊施設の空席・空室情報の照会と

予約を行う。

②旅行代理店

旅行者向けの Web サイトを提供する。航空会社サイト、

宿泊施設サイトと SOAP による XML メッセージ交換機

能を有する。

③航空会社

空席情報の管理機能と SOAP による XML メッセージ交

換機能を有する。

④宿泊施設

空室情報の管理機能と SOAP による XML メッセージ交

換機能を有する。

評価項目評価

開発手順今回は、SOAP サーバに Axis、SOAP クライアントに.NET を使用したが、どちらも Web サービスで

必要になるファイルや設定を簡単に行う機能が用意されており、容易に Web サービスのシステム

を構築する事ができるといえる。

相互接続性呼び出す側、呼び出される側、どちら共、プラットフォームを意識する必要がなかった。異なる

開発言語であっても意識する事なく接続が行われた。ＢｔｏＢで異なるプラットフォーム間の接

続を行う場合でも、クライアントから見て、利用しやすい大変に有効な仕組みといえる。

性能検索対象件数によってファイルサイズが増加し、Axis の処理時間が比例してかかる事が解った。

少量のデータ件数では処理時間に差が無く、返って効率の悪さが目立った。少量データを複数回

やり取りするのではなく、ある程度まとまったデータを扱うモデルに向いていると考えられる。

拡張性データ構造の変更については、十分な検証よる影響範囲の把握ができれば、問題ないと考えられ

る。新たな機能追加については、全く問題ない。Web サービスは業務、ビジネスの拡大に合わせ

て、サービス後の機能追加が可能であり、拡張性は高いと評価できる。

セキュリティ現在提供されているWebアプリケーション用のセキュリティ技術をWebサービスにそのまま適用

する事が可能である。なお、現在のセキュリティ技術は、特定の相手との通信に限られるため、

不特定多数の場合には、SOAP メッセージのデジタル署名や部分暗号化等を行う必要がある。

6. 提言

Web サービスは、XML、SOAP、WSDL、UDDI 等の基本技術インフラが整備されており、現時点で Web サー

ビスを利用したシステム構築も可能である。技術的な有効性は、プロトタイプによる検証結果により確

認できており、将来性についても Web サービスを取り巻くベンダや標準化団体の動向は普及に向けて活

発である。ビジネス的な有効性は、現在の主流である特定の相手との連携においてもコスト削減効果が

あり、将来性についても不特定多数との動的な連携や有料 Web サービスの公開などビジネスとして発展

していく。当分科会は、Web サービスを積極的に適用していく事を強く希望し、以下のとおり提言する。

提言先提言内容

開発者に向けて ● 今すぐ開発可能である！

● プラットフォームに依存しないという利点を活用せよ！

● 標準化動向に注意しろ！

経営者に向けて ● BtoB で業務拡大せよ！

● アウトソーシングとして利用しコスト削減せよ！

● コアコンピタンスを活かし利益拡大せよ！

旅行者

代理店

航空会社

Windows XP

HTTP

Apache Tomcat(WEBｻｰﾊﾞ,Servlet)

Apache Axis��

.NET Framework

業務アプリ

ＩＩＳ(WEBｻｰﾊﾞ)

ASP.NET

Windows XP

ブラウザ

WSDL

Windows 2000SOAP

業務アプリケーション

Ｊａｖａ

空席情報

宿泊施設


Apache Axis 業務アプリ

WSDL

Windows 2000

Ｊａｖａ

空室情報

旅行者

代理店

航空会社

Windows XP

HTTP


Apache Axis��

.NET Framework

業務アプリ

ＩＩＳ(WEBｻｰﾊﾞ)

ASP.NET

Windows XP

ブラウザ

WSDL

Windows 2000SOAP

業務アプリケーション

Ｊａｖａ

空席情報

宿泊施設


Apache Axis 業務アプリ

WSDL

Windows 2000

Ｊａｖａ

空室情報

16

LS 研:ＸＭＬを活用したシステム構築


ＸＭＬを活用したシステム構築

－ＸＭＬを迫られた開発者の方へ－


1. 研究の背景と目的

ブロードバンドネットワーク時代を迎えた今、通信速度の高速化や通信費用の低コスト化により、Ｘ

ＭＬフォーマットでのデータ交換が注目を集めている。それに伴い、各業界では、企業間の取引普及を

目的としたＸＭＬの標準化、整備を進めている。その反面、大手企業やバイヤの社内システムで必要と

される情報に特化した独自ＸＭＬフォーマットでの取引を迫られるケースも見受けられる。こうした中、

ＸＭＬデータ交換対応を迫られた企業では、既存システムにできる限り手を加えず、短納期、低コスト、

かつ、従来どおりの運用を考慮したシステム対応が求められている。

そこで、当分科会ではシステム部門としてどのような対応を取るべきか、また、どのようなシステム

を構築すべきかを検討し、ＸＭＬの最新技術を適用したシステムを実装することにした。さらに、実際

にシステム構築したことで得た知見を研究成果として提言する。

2. ＸＭＬデータ交換規約（ＳＯＡＰ：Simple Object Access Protocol）

今後のＸＭＬデータ交換規約において基盤技術として期待されているＳＯＡＰはネットワーク経由で

オブジェクト間の通信を行う軽量のプロトコルであり、封筒構造の仕組みで構成されている（図１）。

これまでも、ネットワーク経由でオブジェク

ト間の通信を行うものとして、ＣＯＲＢＡ

（Common Object Request Broker Architecture）

やＤＣＯＭ(Distributed Component Object

Model)などがあったが、ＳＯＡＰは、通信内容

の記述にＸＭＬを用いる点が特徴で、言語やプ

ラットフォームに依存しない。また、ＳＯＡＰ

はデータ構造のみが規定されており、転送用プ

ロトコルとして、ＨＴＴＰやＳＭＴＰなど既存

の任意の通信プロトコルを使用する点も特徴で

ある。

3. ＸＭＬの標準化動向と適用例

企業間取引（Ｂ２Ｂ）の本格的普及のカギを握る各業界の標準化動向について、活動状況を調査した。

また、適用例として、行政自ら進めている e-Japan 重点計画の「電子申請システム」と、すでに全世界

で本格的に稼動し先進的な事例となっている電子商取引の「RosettaNet」について詳細を調査した。

4. モデルケースにおけるシステム構築

モデルケースとして、大手企業Ａ社からの強い要望によりＸＭＬでのデータ交換を余儀なくされた量

販店Ｂ社が既存システムをできるだけ変更せず、低コストでかつ短納期で実現するシナリオを想定した。

また、将来、ＸＭＬ交換規約において基盤技術として期待されているＳＯＡＰを採用し、実装した(図２)。

実装した結果、以下のことが確認できた。

・基幹システムを変更せず、企業間連携システムのインタフェース部分を開発することにより、

技術的には短期間で開発できること

・ＸＭＬデータの伝送にＳＯＡＰを採用したが、容易に導入できること

また、今回はシステム構築前に採用する技術の研究調査を行わなかったが、実際のシステム構築では

図１ＳＯＡＰの構造

エンベロープ

ヘッダー

ボディ

<SOAP-ENV：Header>　　　・　　　・

</SOAP-ENV：Header>

<SOAP-ENV：Body>　　　・　　　・

</SOAP-ENV：Body>

<SOAP-ENV：Envelope>

</SOAP-ENV：Envelope>XML

SOAP

エンベロープ

ヘッダー

ボディ

<SOAP-ENV：Header>　　　・　　　・

</SOAP-ENV：Header>

<SOAP-ENV：Body>　　　・　　　・

</SOAP-ENV：Body>

<SOAP-ENV：Envelope>

</SOAP-ENV：Envelope>XML

SOAP

17

LS 研:ＸＭＬを活用したシステム構築


以下の点などに留意して行う必要がある。

・ソフトウェアのバージョンの組み合わせで動作しないケースがある。

・ＳＯＡＰは発展途上の技術であるため、最新動向およびそれに対応するソフトウェアを注視し

ておく必要がある。

図２ＸＭＬ適用後のシステム構成図

5. ＸＭＬ導入のポイントとシステム構築上の

留意点

今回のモデルケース構築では期間的制約によ

り省略したが、本来のシステム構築で行うべき

作業について、Ｂ２ＢおよびＩｎＢでの導入ポ

イントと構築上の留意点をＩＳＯ／ＩＥＣ

１４６６２（JIS X7001 標準電子取引参照モデ

ル（図３））に定義される標準電子取引シナリオ

を参考に、「業務運用ビュー」と「機能サービス

ビュー」から考察した。

さらに、ＩｎＢでは企業内共通となるタグ設

計を行う必要がある。タグ設計のポイントは以

下のとおりである。

(1) 社内業務標準の作成

(2) 社内標準メッセージ（タグ）管理の徹底

(3) 部門個別システム業務のメッセージと

社内標準メッセージとのＦｉｔ／Ｇａｐ

分析

6. ＸＭＬシステム構築を迫られた開発者への提言

ＸＭＬシステム構築を迫られた開発者は以下の点について留意して構築すべきである。

(1) 取引先からＸＭＬデータ交換を要望された場合

① 取引先と取引の合意をしよう！

② 業界標準なのか、取引先固有なのか確認しよう！

③ 自社の項目およびその内容と取引先の項目のＦｉｔ／Ｇａｐをしよう！

④ 社内システムとの連携方法を検討しよう！

⑤ ソフトウェアを選定しよう！

(2) ＸＭＬを社内システムで使用する前に（ＸＭＬのメリットを生かすために）

① 部分最適だけでなく、全体最適化を目指そう！

② 全社で共通な業務ルールと業務メッセージを作成しよう！

③ 個別システムメッセージと社内標準メッセージとのＦｉｔ／Ｇａｐをしよう！

ＢＯＶ（Business Operation View）：業務運用ビュー

ＦＳＶ（Functional Service View）：機能サービスビュー

図３標準電子取引参照モデル

出荷(XML)

Ａ社自社システム

WebｻｰﾊﾞSOAPｻｰﾊﾞ

SOAP

出荷(XML)

注文(CSV)

XML変換

注文(XML) 注文

(XML)

SOAP

Webｻｰﾊﾞ SOAPｻｰﾊﾞ

SOAP

出荷(XML)

注文(XML)

SOAP

出荷(XML)

XML変換

注文(XML)

業務アプリケー

ション

受注DB

A社(売り手）

出荷(CSV)

B社（買い手）

インターネット

レガシーシステム

出荷(XML)

Ａ社自社システム

WebｻｰﾊﾞSOAPｻｰﾊﾞ

SOAPSOAP

出荷(XML)出荷(XML)

注文(CSV)

XML変換

注文(XML) 注文

(XML)注文(XML)

SOAPSOAP

Webｻｰﾊﾞ SOAPｻｰﾊﾞ

SOAPSOAP

出荷(XML)出荷(XML)

注文(XML)注文(XML)

SOAPSOAP

出荷(XML)

XML変換

注文(XML)

業務アプリケー

ション

受注DB

A社(売り手）

出荷(CSV)

B社（買い手）


レガシーシステム

取引規約ガイド

業務モデル別運用シナリオ（業務シナリオ，セションの定義）

標準メッセージ（項目辞書，コード，利用ガイド）

メッセージ交換規約（XML）

認証／暗号化

インターネット（HTTP，SMTP，他）

情報システム運用規約

レイヤー

ＢＯＶＢＯＶ

ＦＳＶＦＳＶ

取引規約ガイド

業務モデル別運用シナリオ（業務シナリオ，セションの定義）

標準メッセージ（項目辞書，コード，利用ガイド）

メッセージ交換規約（XML）

認証／暗号化

インターネット（HTTP，SMTP，他）

情報システム運用規約

レイヤー

ＢＯＶＢＯＶ

ＦＳＶＦＳＶ

18

LS 研: Web システムの効率的開発Ⅰ


Web システムの効率的開発Ⅰ

－勝ち組の開発手法はこれだ！－エクストリーム・プログラミングへの挑戦


1. Web システムの開発手法を見直す

Web システムは新たなビジネススタイルを創造することができるため、つねに変化が求められている。

顧客満足を得るためには新技術と多様なコンテンツが必要となるが、より競争力を高めるにはリリー

スの早さが重要となってくる。

短期リリースが求められている Web システムにおいて効率的な開発を行うためには「ウォーターフォ

ール型開発」を見直す必要がある。従来手法ではドキュメントをマイルストーンとし、一歩一歩着実に

仕様を固め、システム仕様・設計仕様・実装仕様へ落とし込み、後に実装・テストするというスタイ

ルをとる。しかしこの手法では顧客のビジネスの変化に対応できなくなっている。

2. 開発プロセスの過ち

リリースの早さ、すなわち開発期間の短縮であるが、今までのウォーターフォール型開発手法では、

仕様凍結しないで次工程に進む事を許さず、システム開発に欠かせないリスク（技術、機能、性能、仕

様変更）が考慮されていない開発プロセスであるため、仕様凍結後に発生する仕様変更には耐えられず

納期に間に合わない。また開発期間の短縮（スピード化）を実現する事も難しいのが現実である。

3. 超高速型開発手法＝エクストリーム・プログラミング(XP)

当分科会では上記の理由により、効率的な開発には、まず開発手法を見直すことがキーポイントであ

ると判断した。

昨今、雑誌等ではアジャイル開発手法という言葉がキーワードとなり、その旗手として「エクストリ

ーム・プログラミング(以下 XP と記す)」が取り上げられている。XP とは、一言でいうと「必要な機能

を優先して、小規模で短期間に開発し、それを繰

り返す」ものである。不確定な仕様であっても、

ある程度まとまれば開発に着手でき、途中の仕様

変更も次の開発サイクルで「必要な機能」として

組み入れることができる。

当分科会では、効率的な開発を行う重要な鍵と

して XPに着目した。それを実証すべく｢ブックレ

ンタルの Web サイト｣のテストプロジェクトを発

足させ文献等で述べられている特長を実践により

調査・検証を行った。

3.1 実践で得られた XPの評価

実践で得られた XPの評価は以下である。

図 1 ブックレンタルの Web サイト

短期リリース・リスクマネジメントを考慮した新しい開発手法が必要！

19

LS 研:Web システムの効率的開発Ⅰ


さらに、次のような効果が期待できる。

プログラミングに先立ちテストコードを作成するため、詳細仕様を早期に認識できる。

（テストファースト）

２人で１台のパソコンを使用して開発を行う事により相互の教育効果を高め、ケアレスミス・手戻

りを削減できる。（ペアプログラミング）

意思伝達のための仕様書を小限にすることで、ドキュメント作成、整備の工数を軽減できる。

全工程を全メンバで実行し、各自が「責任者」という意識をもって作業を行うため、モチベーショ

ンが高まり開発効率・品質にも好影響を与える。(全員同席)

3.2 LS 研版 XP の策定

テストプロジェクトにおいて、「上流設計工程をいつ行うか」「成果物が何か」が不明確であった。そ

のため、以下の２点を追加し、LS研版 XPとして策定した。（図 2参照）

上流設計工程の追加(基本設計・DB設計・画面設計)

各工程の成果物の明確化

4. 勇気ある導入が勝者への近道！

実践結果より、XP は顧客のビジネス要求の変化にすばやく対応できる開発手法であると判断した。

なお実際には、従来の開発手法に XP で標榜している 13 の実践項目（ペアプログラミング、短期リリ

ース等）を徐々に組み込むことで、容易に導入することができる。

また、課題としては以下の点が挙げられるが、導入実績が増えることにより今後解決されていくであ

ろう。

・ SE/プログラマの作業区分がないため、見積り方法の検討が必要

・品質管理指標（ISO9001 など）への対応

どんな開発手法でも新しく経験のないものはたとえ優れていたとしても「不安」「不慣れ」「疑念」と

いった印象を受ける。XPとてそれは同じである。XPのさまざまな文献で述べられているように、結局は

「勇気」が必要である。勇気をもって導入したものが勝者への近道であると言える。

リリース計画

スパイク

見積り確定

不確定要素を検証

テストロジック作成

ｽﾄｰﾘｰｶｰﾄﾞ

ｽﾄｰﾘｰﾎﾞｰﾄﾞ

ｱﾌﾟﾘｹｰｼｮﾝ

ｱｰｷﾃｸﾁｬｰ

ＤＢ構造

ﾌﾚｰﾑﾜｰｸ

方式設計

成

果

物仕様変更管理リスト

ＬＳ研版

ｺｰﾃﾞｨﾝｸﾞ規約

ＥＲ図

画面遷移図ﾀｽｸｶｰﾄﾞ

ﾀｽｸｶｰﾄﾞコード

ﾃｽﾄｺｰﾄﾞ

機能ﾃｽﾄ

ｹｰｽ表

ｿﾌﾄｳｪｱ

スパイク

リリース計画

開発する機能( ストーリー )

を選択

基本設計

方式設計ﾐﾄﾞﾙｳｪｱ選定D B 選定

D B 設計

E R 図論理設計

画面設計

画面遷移決定ﾗﾌﾃﾞｻﾞｲﾝ

ｲﾃﾚｰｼｮﾝ計画

ストーリーを開発者に割り振る

イテレーション開発

ストーリーを実装する

ペアの決定

日次ミーティング

機能テスト

ストーリーの正当性チェック

リリース

顧客へ提供

ペア・プログラミング

図 2 LS 研版 XP

◇ 必要な機能を順次リリースが可能である

◇ 短期リリースを繰り返す事により、リスクを早期に回避出来る

XPはWebシステムの効率的開発に貢献できる！

20

LS 研:Ｗｅｂシステムの効率的開発Ⅱ


Ｗｅｂシステムの効率的開発Ⅱ

－資産の蓄積と再利用による効率化を目指す

(リサイクル＆ビルド)－アブストラクト

1.研究の背景

近年、企業におけるシステム開発への投資はこれまでのメインフレームから Web システムを代表とす

るオープン系システムへの移行が進んでいる。これは単にハードの移行に伴う投下費用の低減だけでは

なく、インターネットの普及に起因する B2B・B2C などの外部向けサービスの実現が容易になったことも

またその要因である。

インターネット技術を用いることで企業はこれまで達成できなかったサービスを実現したいと思うと

共に、新たなニーズとして｢もっと早く｣｢もっと安く｣｢もっと安定した｣システムの供給を開発サイドに

求めるようになっている。

新たなサービスの実現は、納期の長期化・新規技術使用によるリスクを伴い前述の３点の｢もっと｣を

吸収しきれない場合も発生し得る。しかし、システムを生業とする我々は顧客ニーズを満たすと共に企

業利益を追求することもまた重要な責務である。そのため、顧客ニーズと企業利益を両立させるための

効率化を模索した。

2.研究会の目的と進め方

当分科会では、Web システムの効率化とは何かを明示させることこそ主題であると判断した。巷で呼

ばれている Web システムとは何かの定義をするとともに、そもそもの開発における非効率要素は各参加

者が抱えるシステム開発における問題点であると定義し、具体的にどのような切り口のもと効率化を考

えるかを検討した。

また、決定した切り口の運営についても検討するとともに支援ツールを作成した。

(1) 業務経験など、情報意見交換

(2) Web システムとはどのようなものなのか

(3) 顧客とシステム開発側との関係を Web システムの開発という視点から再度明示化

(4) 参加各自が認識するシステム開発におけるこれまでの問題点はどのようなものか

(5) 問題点をより解消するための１つの切り口（サブテーマ）の決定

(6) サブテーマ（『資源の蓄積と再利用』）を実践するための支援ツールの開発

(7) 『資源の蓄積と再利用』を実践するための提言

3.研究内容

3.1 サブテーマ決定まで

各参加者の立場・業種の違いにより研究範囲の決定が難航したが、より多くの問題を吸収できる

方法として『資源の蓄積と再利用』に決定した。以下が見込まれる効果である。

■ 過去に作成したシステムを参考にし、顧客に提示し、意識を共有する

■ 過去作成した各種モジュールについて使用頻度が高い場合や作成難度の高いもの

を再利用することによって開発工程全般で省力化が実現される

■ 再利用を考慮した部品化を行うことで顧客に対して一定の品質を提供でき、障害発生

率を抑える

21

LS 研:Ｗｅｂシステムの効率的開発Ⅱ


3.2 支援ツールの作成

『資源の蓄積と再利用』をより効率的に実現するために、部品と人とを結びつけるための機能が

必要と考えた。１つの提案として、簡易的なものだが、部品を容易に検索できる支援ツールを準備

するに至った（下図参照）。併せて運営ルールについても列挙している。

4.まとめ

Web システムの効率的開発を実施する上で、『資源の蓄積と再利用』は、「見積」「設計」「開発」「検証」

の各開発工程にて横断的に作業負荷を軽減させる。さらに顧客と実現されるシステムを早期に共有認識

することが可能である。

システムは日々、様々な開発方法論が今後の主流となるであろうと雑誌などで流布されている。裏返

すとこれまで流布されていた解決方法論では足りない部分が少なからずあるということなのである。

我々の身の回りには失敗した開発もあるが成功した開発もある。過去の成功事例を有効に活用すること

が次の成功事例につなげる近道である。

■ すでに存在する資産を有効利用することによるメリットは顧客・システム作成側の双

方に利益をもたらす

・顧客は要求した内容の事前把握や想像が容易になる

・システム作成側は障害の少ない、高品質のシステム提供を効率的に実施できる

■ システム作成側は、資産化されていない機能に特化し作成を行うため作業負荷の

軽減が見込まれる。さらに新規作成部分を必要に応じて資産化することにより効率の

継続を行うことができる

■ 開発手法や解決方法論にとらわれない効率化が実現される

22

LS 研:ビジネスインテリジェンス指向のＤＢ構築


ビジネスインテリジェンス指向のＤＢ構築

－あなたのＢＩ活きてますか？－


1. はじめに

ビジネスインテリジェンス（ＢＩ）という言葉は、５年ほど前から世間一般に広まっており、多くの

企業でＢＩツールを導入してデータの活用に取り組んでいる。しかし、各企業の導入効果という観点か

ら見てみると、「導入はしたものの充分に活用できていない」といった内容の回答が多く、決して満足度

は高くないのが現状である。そこで、ユーザの満足度が高くなっていない原因がどこにありどのように

対処すれば良いのか、本来ＢＩに求められる利用効果とはどのようなものでありどのような手段で実現

して行けば良いのかを追求することにした。

2. ＢＩの定義

我々は、「ＢＩ指向」とは何かということについて共通認識を持つためＢＩを以下のように定義した。

・社会全般から広くデータを収集し、ビジネス上の意思決定を的確に行なうための情報として活用

すること

・データにビジネス上の知識を使用し、情報→知識→知恵→ルールを導き出し、ビジネスに反映さ

せること

・経験者のみが持つ「暗黙知（ノウハウ）」を企業全体で共有し、企業財産として活用すること

そして、ＢＩの実現を目指すために、２つの角度から分析を行なった。

(1) ＢＩ（ＤＷＨ）の現行運用での問題点の解決によるＢＩの実現

(2) ＢＩツールの新機能追求によるＢＩの実現

3．問題点解決からのアプローチ

現在データウェアハウス（ＤＷＨ）を導入している企業で問題になっている事項を抽出し、その問題

点を分類して根本原因を追求した。そして、根本原因に対する解決策は、以下の３点と考えた。

体制の整備

・キーマンの設定・運用グループの設置・ヘルプデスクの設置

教育の充実・教育カリキュラムの細分化・教育体制の整備

環境の整備・項目辞書の作成指針・メンテナンス指針

23

LS 研: ビジネスインテリジェンス指向のＤＢ構築


4.新機能追求からのアプローチ

一般の導入事例よりユーザニーズを調査し、どのような要件が求められているかを分析した。ここか

ら「ＢＩを実現するための１０の要件」を導き出した。

≪ＢＩを実現するための１０の要件≫

①様々なデータの取り込み ⑥外部（インターネット）データの検索

②自動マッピング ⑦分析手順の保存・再利用

③異種データの統一的検索 ⑧信頼性のあるビジネスルールの自動導出

④異種ＲＤＢＭＳの検索 ⑨分析ノウハウ（目的・手順）の蓄積・共有化

⑤テキストデータのＡＩ検索 ⑩分析後のアクション・結果の収集・比較

この１０の要件と現行ツールの機能のギャップを洗い出した。その中で、ＢＩを実現するために要求

される機能で我々の注目した部分は、⑦～⑩にて挙げられている要件である。なぜなら、これらの要件

は、分析、ルールといった暗黙知（ノウハウ）の共有を目指すものであり、この暗黙知の共有がより良

いＢＩサイクルを実現するためにも重要な要素であると考えるからである。そこで我々は、⑦～⑩の

要件を実現するためのツール機能の一つとして『ＢＩバインダー機能』を考案した。

『ＢＩバインダー機能』

分析者の分析手法そのものを、ノウハウとして蓄積し、他の分析者と共有する機能。

・分析時の操作ログや分析の目的、分析過程の着目点などを「バインダー」に保存できる。

・他の分析者は、「バインダー」の再現機能を使用し、分析ノウハウを習得できる。

・意思決定者の分析内容だけでなく、他の分析者の意思や分析内容も情報として蓄積できる。

・分析によって得られた知識がどのように実際の行動に結びつき、どのような結果が得られたかと

いった情報を蓄積できる。

5.おわりに

我々の研究では、ＢＩをあらためて定義し共通認識を持つところから開始した。そして、我々が定義

したＢＩを実現するためには、『人的な側面』（使う側）の問題解決、つまり、体制の整備・教育の充実・

環境の整備を行なう必要がある。この解決策は、今後ＢＩを運営する利用者に対しての処方箋として活

用できると考える。しかし、ＢＩ実現に向けて『人的な側面』だけを捉えたのでは不十分であり、『ツー

ル機能の側面』（使われる側）の強化を図ることも同時に進めていくことが不可欠である。これに対して

我々は、ツールに要求されるべき１０の要件を示した。この１０の要件は、ツールを提供するベンダに

対しての指針となり得るであろう。その中で我々が具体的に提案した『ＢＩバインダー』は、暗黙知を

企業の共有財産とすることができ、より良いＢＩサイクルを実現することができる。ツールを提供する

ベンダにおいて、この機能が実装されることを期待する。

24

LS 研:ブロードバンドにおける最適なシステム構成


ブロードバンドにおける最適なシステム構成

－ブロードバンドへの羅針盤－


1. 背景と課題

政府主導のｅ－Ｊａｐａｎ戦略も追い風となり、ブロードバンド回線の整備が急速に進み、国内のブ

ロードバンド利用者も今や 600 万人以上となった。これに対し企業側もビジネスモデルの変化などに対

処するため、必然的にブロードバンド対応をせまられている。

一方で現実には次のような問題が存在している。

① ブロードバンドに対応したシステム実践事例が少ない。

② ブロードバンドに対応できる知識を持った人材が少ない。

③ インフラ規模要件（回線、セキュリティ、スケーラビリティ、信頼性）があいまいである。

2. 研究目標

以上の課題を踏まえ、当分科会では、企業においてブロードバンド対応を行う際に、専門知識や経験

持たない人でも容易に構成設計ができるツールの作成を目的とした。

3.研究プロセス

ブロードバンドにおけるシステム構成を検討するにあたり、以下の手順で研究・調査を行った。

① 技術要素の研究

拡張性、信頼性、セキュリティという３つのキーワードに着目し、回線、サーバ、セキュリテ

ィ、負荷分散について技術要素研究および最新動向調査を行った。

② 「ブロードバンドとナローバンドでは何が変化するのか？」についての研究

まず、ナローバンドとブロードバンドの差異について研究を行った。

結果、ブロードバンドでは、サービスで取り扱うコンテンツのサイズが巨大化していることが

大きな違いであると捉えた。企業が今後提供していくと予想される「ダウンロード」「ストリー

ミング」「リアルタイム」の３種類のシステム構成について研究をすることとした。

③ 具体的なサービスコンテンツによるシステム構成モデルの研究

「音楽配信」、「株主総会のライブ配信」を例に、メンバーの SE 経験から得た知識に基づき、シ

ステム構成モデルを作成し研究した。

④ システム技術要素のブロック化と整理

設計作業の効率化・漏れの防止を目的とし

て、システム技術要素を「回線」、「セキュ

リティ」、「コンテンツ」の３つにブロック

化し、ブロックごとに設計ポイントの洗い

出しを行った。

⑤ 成果物のまとめ

以上の研究プロセスから成果物として「シ

ステム構成支援ツール」を作成した。

4.ブロードバンドにおけるシステム構成のポイント

ブロードバンド環境では以下のような検討を行う

必要があることがわかった。

IDS

Internet

ﾙｰﾀ

サーバ群

負荷分散装置

FW

回線ブロック

セキュリティ

ブロック

コンテンツ

ブロック

図 1システム構成

25

LS 研:ブロードバンドにおける適なシステム構成


表１ブロードバンドシステム構成のポイント

回線コストを主眼に、新技術の採用を検討

インターネットサーバ性能対策を主眼に、既存のシステムスペック見直しサーバ／

コンテンツサービス提供サーバ提供するサービスごとに機能仕様等を検討

ゲートウェイセキュリティ性能対策を主眼に、既存のシステムスペック見直し

コンテンツセキュリティ提供するサービスごとに機能仕様等を検討

セキュリティ

暗号化回線サービスと合わせて新技術の採用を検討

また、ブロードバンド特有の「ストリーミング（オンライン株主総会ライブへの適用）」「ダウンロー

ド（プログラムダウンロード販売サイトへの適用）」「リアルタイム（企業内線の事業所間接続部分に

VoIP を利用した IP電話への適用）」のサービスのモデル構成を作成し、企業のシステム構成を検討する

際のシステム構成例、課題、考慮点を導き出した。

5．研究成果：「システム構成支援ツール」の作成

この「システム構成決定支援ツール」は、事例が少なく規模要件があいまいである今般の業界通念で

ある「小さくスタート」のポリシーで基礎を作り、ビジネスサイズの増減を拡張性で吸収するよう作成

されている。また、専門知識や経験を持たない人でも、経営者等からサービス要件のヒアリングを行い、

システム構成の作成を行うことができるように工夫した。

特長は、以下の通りである。

このツールを利用することで上記のメリットを享受できるが、以下の制限がある。

・コストは変動要素が高いため、算出していない。

・このツールは自社でシステム構築する前提であり、アウトソーシングの選択は対象外とする。

・新技術・新製品に対応するため、「新 IT 製品一覧」は、適宜更新する必要がある。

ツールの有効性については、分科会メンバーの企業において適用した結果、「設計に要する時間が大幅

に短縮できた」と評価された。情報システム担当者は、自社のセンター構築を行うにせよ、アウトソー

シングサービスを選択するにせよ、適なシステム構成を比較検討するために、この「システム構成支

援ツール」を積極的に活用して頂きたい。

6.ビジネス視点での提言

ＩＴ技術の進歩が著しく速くなっているのは周知である。ブロードバンドの普及によってストリーミ

ングサービスが一般化してきたように、従来のインフラでは実現できなかったサービスが現実のものと

なってきている。これは、ブロードバンドに加え、ユビキタス社会と言うキーワードがトレンドになっ

てきていることをみてもわかる。従来のスピード追求型ビジネスモデルから使い易さ追求型ビジネスモ

デルへの変革を迫られていると考える。企業は、その成長を実現させるためにＩＴ技術を意識すること

なく、「新しいビジネスモデル」、または、「新しいサービス」を積極的に開発していくことが重要であ

る。

① サービスの規模要件までを織り込んだツールの実現

従来の機能要件にサービスの規模を加味することでよりフィットした構成設計を可能とす

る「チェックシート」・「フローチャート」の２つから構成する。

② ヒアリング項目に専門知識をもたない人でも理解できる言葉の採用

システム構築を担当する技術者が、経営者等からサービス要件をヒアリングするシーンを意

識して作成した。

③ 「小さくスタート」を意識したハードのオプション選択方式の採用

潮流である「小さくスタートし大きく育てる」を構成設計段階から実現するために可能な限

りオプション選択方式を採用した。

④ 「新 IT 製品一覧」の添付

添付に「新 IT 製品一覧」を載せており、製品選択の目安、市場調査をする上でも役立つ。

26

LS 研:IPv6 を活用した次世代企業ネットワーク


ＩＰｖ６を活用した次世代企業ネットワーク

－ビジネスチャンスをつかむために－

アブストラクト１．研究の背景

ここ数年、中国などアジア諸国のネットワーク接続が増大したことによる、IPアドレスの枯渇の問題

や、2000 年に政府が発表した e-Japan 構想などを契機に IPv6 を盛り上げる動きが盛んになっている。

我が国は IPv6 の技術に関しては世界的にもっとも進んでおり、ビジネスチャンス獲得の大きな期待が寄

せられている（政府は 2010 年のユビキタス市場の規模は 84.3 兆円と予測しているが、このユビキタス

化の鍵となる技術として IPv6 が存在している）。

そのような状況の中で、各企業は IPv6 の導入時期を窺っている。

２．研究目的と進め方

実際に IPv6 ネットワークの適用準備を行なっている企業はそれほど多くないのが現状である。

我々の分科会では、企業が IPv6 インフラ活用と移行をどのように行ってゆくべきかを考え、ネットワ

ーク管理者へ IPv6 導入のシナリオを提言する。また、IPv6 を適用した場合の効果を見極めることを目

的とした。進め方としては、IPv6 を企業ネットワークへ適用した場合の影響や何が変わるのかを下記の

手順でまとめた。

(1)現状調査

(2)どのようなモデルで利用できるのか

(3)IPv4 からの移行方法はどうすべきか

(4)導入評価

３．研究内容

(1)IPv6 の現状調査

IPv6 を使用したネットワークでは、豊富な IP アドレス、Plug and Play、双方向通信を特徴と

する、これまでの IPv4 ネットワークではできなかったサービスが提供できる。

ルータなどのネットワ－ク機器、OS、ISP などは既に対応しておりインフラはすでに整ってきて

いる。

(2)新しいサービス

IPv6 を用いた新しいネットワーク利用形態の

検討を行った。利用法の一例を右の図に示す。

この例では、物流分野における応用例を示して

おり、IP アドレスを商品などに割り振ることに

より、商品の在庫管理、自動発注処理、配送状態、

きめ細かな顧客管理が可能となる。

これらの技術は既に実現可能なものであり、

我々は、IPv6 を使用したネットワークが今後の

企業ネットワークにおいて有効であると結論づ

けた。

商品の鮮度、産地、おいしさ情報の提供

商品の自動出荷

配達状況確認

スーパー

家

ベンダー

コンビニ

自動発注処理、売れ筋商品の情報

走行順路確認積荷管理

在庫情報管理


視聴者によって異なるＣＭ放送

商品とレジの連係による自動清算

27

LS 研:IPv6 を活用した次世代企業ネットワーク


(3)IPv4 から IPv6 への移行方法

IPv4ネットワークからIPv6ネ

ットワークへの移行技術は数多く

あり、各企業の実態に合わせて行う

必要がある。

我々の分科会では、メンバ各社の

実態に則した移行シナリオを作成

した。右表にそのポイントを示す。

(4)コスト

コストに関しては、初期導入費、

運用費が IPv6 への移行後どのよう

に変化するかを議論した。

その結果をまとめると右図のとお

りとなる。

現在と比較し特段にコスト高とは

ならないと結論付けた。

(5)今後への課題

IPv6 を企業ネットワークに導入するにあたり、以下の課題がある。しかし、これらは全て、IPv6

ネットワークの普及と共に解決されることから、今後の導入の弊害とはならないと結論した。

・少ない導入実績

・技術的な課題（負荷分散装置がない。など）

・ビジネスモデルの具体化

４．まとめと提言

IPv6 の基本技術は確定しており、必要なネット機器、インフラは整いつつある。コンピュータ以外の

機器をネット化する動きが加速し、今後 IPv6 ネットが拡大することは確実であろう。

我々は、インターネット社会では初に導入した会社が大きなアドバンテージを握ることをここ数年

で学習してきた、Cisco Systems、Microsoft、Yahoo、Amazon.com、etc。

IPv6 は数年後には導入され、その周辺には膨大な市場が存在しており、今後企業がグローバル市場で

生き抜くためには IPv6 をより速く研究、実践し、各企業でいつでも導入できるような体制を整えておく

必要がある。提言を以下のようにまとめた。

シナリオ IPv4:IPv6 目的と実施内容

フェーズ 1

（導入期）

１：９・IPv6 ネットワーク運用のノウハウを蓄積

・一部のサーバ、端末をデュアルスタック化する

・社内利用者への IPv6 インターネット接続は禁止

フェーズ２

（発展期）

４：６・IPv6 インターネットへの接続

・拠点間の接続にはトンネリング技術を利用

フェーズ３

（普及期）

６：４・社内の基盤ネットワークを IPv6 化

・IPv6 に対応できないアプリ、サーバへの接続はトランスレータを使用

フェーズ４

（IPv4 衰退期）

９：１・IPv4 インターネットからの接続用の DMZ を撤去

・拠点間の接続に IPv6 インターネットを使用した VPN を利用

費用項目説明

初期導入費 IPv4 の機器と IPv6 対応機器とでは、値段は変わらない。IPv6 対応になっていない機器の

リプレースのタイミングで IPv6 対応機器を導入することにより、コスト高とはならない。

運用費 IPv6 特有のアプリを使用しない場合のコストは同等である。End to End のセキュリティな

ど IPv6 独自の管理を行う場合、運用コストは上昇する。

技術習得費ネットワーク技術者は IPv6に限らず常に新技術を習得しているため、常に教育費用のコス

トを払っているはずである。IPv6 だからといって特別にコストが跳ね上がるわけではない。

提言

◇ IPv6 に関する調査をすぐにでも始め、自社の今後の展開を検討せよ

◇ 機器のリプレースの際には IPv6 対応機器を選択せよ

◇ 移行技術は多様であり、その選択は自社の実情を調査し実施する必要がある

28

LS 研:ストレージの効果的な適用


ストレージの効果的な適用

－ネットワーク時代における総合的適用指針－

アブストラクト 1. 研究背景

人類が地球上に誕生してから現在までの約 5,000 年の間に創造したデータ量は、12,000 ペタバイトを

越えると言われている。この量を今後 2､3 年間だけで上回るデータが創造され、この大半がストレージ

に格納されると考えられている。企業、公共、個人の情報の急速なデジタル化と、ブロードバンドやイ

ンターネットの普及によってストレージに蓄積されるデータの増加はとどまることを知らない。また、

災害対策や 24 時間/365 日連続稼働などストレージに対する要望は多様化し、技術もまた日々進化して

いる。このような状況の中、要望や技術をすべて網羅したストレージを導入することは大変難しい状況

になっている。そこで当分科会では、利用企業の実体に合わせて効果的にストレージを選択できるよう

な指針の確立が望まれていると考え、研究を進めることとした。

2. 研究目的と進め方

当分科会では、多様化する顧客要件と進化する要素技術の調査・整理を通じて、『ストレージの効果的

な適用』に関するガイドラインの提言を目的とした。研究手順としては、①“生の声”を集めることを

重視し、参加メンバ企業が抱えるストレージを含む情報システムの課題や要望を聞くため調査票を作成

してヒアリングを行い、顧客要件を整理した。②進化しているストレージ技術の評価を行うことにより

体系化した。③顧客要件とストレージ技術をいかに合致させるかを議論し、２次元表（マトリクス）を

用いて適合度を評価し、手順を定めた。④メンバ企業の実際のストレージ構成と特徴を模したモデル構

成への適用と評価を行った。⑤現在のストレージを取り巻く IT 業界の動向と、ガイドラインから顧客要

件と要素技術との関係を分析し、ストレージの将来像を考察した。

3. 研究成果

3.1 多様化しているストレージへの要望の整理

メンバ各社のヒアリングによって“生の声”を

集め、分析を行った。この中で従来からの「デー

タを保存したい」といった単一の要件だけでなく、

「容量増加に対し迅速にデータ保存したい」とい

った、拡張性や性能など、多様な要望が複雑に絡

み合ったものが多いことが分かった。そこで当分

科会では、要件の共通性を見いだしながら分類整

理し、85 個の具体的な要件に分類した。更に、

類似性を見いだして 7つの大分類「運用効率化」

「拡張性」「コスト」「性能」「データ保護」「無停

止」「セキュリティ」に大別した。

3.2 進化しているストレージ技術の長所・短所の明確化

顧客要件の多様化とネットワーク技術の進歩により、

SANやNASを代表とするネットワークストレージや仮想

ストレージなど、日々新しいストレージ技術が出現して

きていることが判明した。そこで当分科会では、172 に

渡る技術・製品を調査して、6 つのストレージ技術と、

7 つのバックアップ技術を基幹技術と位置づけた。更に

図１顧客要件の整理

DAS NAS SAN

長所安価に構築可能

安定感が高い

同種や異機種のサーバ間

でファイル共用可能

業務ネットワークに負荷

がかからない

短所拡張性に乏しい

サーバ増加時は管理難

既存ネットワークに負荷

がかかる

対応製品が高価である

構成例

表１ストレージ構成の特徴

・障害時にシステムを止めない

・年災害時のデータ保護

無停止

・様々なベンダのストレージ接続

・データの移行を容易にしたい

・データを集中させたい

拡張性

・ネットワークの負荷を減らしたい

・サーバの負荷を減らしたい

・ディスク i/o を高速にしたい

性能・バックアップを短時間で実施

・遠隔地にバックアップしたい

・リストアを高速にしたい

データ保存

増大する要望・要件

・ストレージを集中管理したい

・ディスクの使用量がしりたい

・サーバを統合し数を減らしたい

・初期コストを抑えたい

・運用コストを抑えたい

コスト

運用効率化

・アクセス制御したい

・ウィルスからのデータ保護

ｾｷｭﾘﾃｨ

29

LS 研:ストレージの効果的な適用


表 1にあるように、それぞれの基幹技術についての特徴をまとめ、長所・短所を明確にした。

3.3 ガイドラインの提案

多種多様な顧客要件を的確に分析し、も適する要素技術を選択するために、「マトリクス」を作成

した。縦軸に顧客要件、横軸に要素技術を配し、１つ１つの要件に対して技術の適合度を評価してい

る。図 2のマトリクスにある顧客要件から必要な項目を選択することで、図 2のレーダーチャートを

含む提案書が出力される。これにより複数構成のバランスを比較して適なストレージを選択するこ

とが可能となる。これら一連の流れに手順書と用語集を加えたものをガイドラインとしてまとめた。

なお、本ガイドラインは、8つの既知事例を基に第三者の観点から TA 以外の富士通ストレージ技

術者が導出した結果と比較検証し、フィードバックを図り精度を向上させた。

3.4 ガイドラインの効用

メンバ企業へのアンケート調査から、以下の効用があることが判明した。

(1) ストレージの構成検討時間の短縮・・・・・・平均 2.5 ヶ月→1ヶ月以内へ

(2) ストレージ技術者のスキルに依存しない・・・ストレージ技術者と同様の技術が導き出せる

(3) 顧客がストレージ関連技術を認知できる・・・導入検討者の 18%しか知らない技術も認知できる

(4) 顧客要件をダイレクトに反映・・・・・・・・SAN や NAS に偏らず、良な技術を導き出せる

(5) あらかじめ顧客要件が明示されている・・・・検討漏れが無くなり、確実に要件を網羅できる

これらのことから、当分科会ではストレージを効果的に適用するためには、「ガイドラインを活用

すべきである」と提言する。

3.5 将来のストレージ像

表 2にあるように、ストレージ技術を分析する

と、現時点では NAS が幅広く顧客要件をカバーし

て全体のバランスがよいことが判明した。

しかし、今後の IT 業界の課題として、｢サーバ

の統合｣、｢異機種混合な環境｣、｢災害復旧｣があ

り、これらを解消できるのは以下の観点から仮想

ストレージであると考えた。

(1) 異機種サーバを統合し、ストレージの使用が可能

(2) 複数の環境を１つの「ストレージプール」で管理可能

(3) 「ストレージプール」を遠隔地へミラーリングが可能

これらを踏まえ、近い将来「仮想ストレージ時代」

になると予測するに至った。また、時代の流れから、

ストレージのアウトソーシングも一般化すると考えた。

4.まとめ

当分科会では、顧客要件に合致したストレージを効果的に適用するためのガイドラインを導出した。

この一連の手順を自動化した「活用ツール」を開発したので、検討時に利用して頂けたら幸いである。

基幹技術

項番大項目小項目要件選択

１コスト 1) 導入・運用 ①

Ａ ○ 0 1 2 1 1 2

…

４性能 1) システム ①

Ａ ◎ 2 2 0 0

…

６運用の効率化 9) 統合 ①

Ａ ◎ 2 0 2 2 2

Ｂ ◎ 1 0 2 2 2

…

７拡張性 1) 容易性 ①

Ａ ◎ 2 0 0 0 2

…

LANのトラフィック量を軽減して、サービスへの影響を少なくしたい

ストレージ

ネットワーク(ネットワークに負荷をかけたくない)

階層記憶（

ＨＳＭ）

FC-SAN

DAS（

ＳＣＳＩ）

ストレージの構築コストを削減したい　（段階的な投資．．）

初期構築コストを削減したい

サービス（業務）を止めずにディスクドライブを増設したい

顧　客　要　件

IP-SAN

ストレージ接続形態仮想ストレー

ジ

NAS

ストレージ統合によって様々な効果を得たい

ディスク空き容量を出来る限り無くし効率良く利用したい

ストレージ設置スペースを削減したい

容易なストレージの増設

【評価基準】

評価点：０～３点

０：要求を満たさない１：制限があるが要求を満たす２：制約がなく要求を満たす（現状標準のもの）３：魅力的な要求を満たす（標準以上）

図 2 ガイドラインの構成

DAS(SCSI) FC-SAN NAS総評価点 17 総評価点 45 総評価点 45

付加技術総評価点付加技術総評価点付加技術総評価点管理ストレージ集中／統合管理 ○ 31 管理ストレージ集中／統合管理 ○ 31 管理ストレージ集中／統合管理 ○ 31

ファイルアクセス制御（ＮＡＳ） 9 ファイルアクセス制御（ＮＡＳ） 9 ファイルアクセス制御（ＮＡＳ） ○ 9ゾーニング／LUマスキング／VLAN 10 ゾーニング／LUマスキング／VLAN ○ 10 ゾーニング／LUマスキング／VLAN ○ 10容量割り当て制御 4 容量割り当て制御 4 容量割り当て制御 ○ 4データ暗号化 ○ 0 データ暗号化 ○ 0 データ暗号化 ○ 0ディスク・アレイ（ＲＡＩＤ） ○ 12 ディスク・アレイ（ＲＡＩＤ） ○ 12 ディスク・アレイ（ＲＡＩＤ） ○ 12コントローラ／パスの冗長化 ○ 4 コントローラ／パスの冗長化 ○ 4 コントローラ／パスの冗長化 ○ 4筐体間／筐体内のディスク・ミラーリング（ソフト） ○ 10

筐体間／筐体内のディスク・ミラーリング（ソフト） ○ 10

筐体間／筐体内のディスク・ミラーリング（ソフト） ○ 10

ロード・バランス（パス）機能 ○ 8 ロード・バランス（パス）機能 ○ 8 ロード・バランス（パス）機能 ○ 8活性増設/活性挿抜 ○ 20 活性増設/活性挿抜 ○ 20 活性増設/活性挿抜 ○ 20

データ保護データ保護

高信頼性・高可用性


データ保護


レーダチャート

33

2 30

42

コスト

無停止

セキュリティ

性能データ保存

運用の効率化

拡張性


3

5

5

2

424

コスト

無停止

セキュリティ


運用の効率化

拡張性


2

54

43

5

5

コスト

無停止

セキュリティ


運用の効率化

拡張性

表 2 ストレージ接続形態の比較評価

用語集

マトリクス

図 3 仮想ストレージの一例

手順書

提案書

ストレージ技術

／基幹技術

運用

効率化

拡張性コスト性能データ

保護

無停止セキュ

リティ

DAS × × ◎ △ × × ◎

NAS ○ ◎ ◎ ○ ◎ ○ ○

FC-SAN △ ○ △ ○ ○ △ △

IP-SAN ○ ○ △ △ ◎ ○ △

階層記憶 △ ○ △ ○ ○ ◎ ○

仮想ストレージ ○ ◎ × △ ◎ ◎ ◎

30

LS 研:モバイル端末の業務システムへの活用


モバイル端末の業務システムへの活用

－ワークスタイルの変革－


1. 研究の全貌

モバイル端末の持つ携帯性、常時接続性といった特性が、近い将来、人とコンピュータシステムとの

間のコミュニケーションを仲介する役目を担っていくことは明白である。しかし、これまでのモバイル

適用による情報システム構築は、特定の業務の稼働率を向上させ、効率化を狙ったものが大半であった。

結果として業務処理速度が向上し、一定のコスト削減を達成することができたが、それらを利用する従

業員のワークスタイルの変革までは到達できていなかった。

それは、なぜか？私達は、研究を進めるにつれて、企業がモバイル技術の導入にあたり「モバイル」

という新規技術に目を奪われ、本質的な業務改善・改革に連携していないことを発見した。すなわち、

モバイル端末を従業員に渡し、効果的な利用方法を突き詰めて行くと、労務規則の改訂や、連携する他

情報システムの改造、関連する業務プロセスの見直しなど、全社的な業務改革活動に発展するため、単

なるモバイル端末の導入コストを大幅に上回る BPR(Business Process Reengineering)コストが発生し、

多くの企業がそれに対して尻込みしてしまうからではないだろうか。

ところで、ユビキタス社会におけるモバイル技術の利点は、図 1に示すように、従業員が「いつでも・

どこでも・ただちに・だれでも」企業活動の情報を入力・参照できるため、意志決定や情報共有が迅速

化されることである。また、情報自身をみると、新鮮な情報が企業へ入力され、直ちに共有されるため、

情報の精度の向上もはかれる。これが何を意味するかというと、業務を行っている従業員が精度の高い

情報を迅速に共有でき、自分自身の仕事の意志決定に役立てることができ、生産性の向上だけでなく、

業務品質が格段に向上する可能性があるということだ。

図 1. モバイル端末適用による効果

研究開始当初、私達は、モバイル技術の端的な利点である、情報共有の迅速化に着目した企業内情報

システムへの適用について研究を行っていた。しかし、モバイルの利点を突き詰め、企業の置かれてい

る様々な課題を見比べることにより、それらの多くの課題が、将来のユビキタス社会において、モバイ

ル技術の適用により解決できるのではないかという思いに駆られるようになった。そして、その考えを

立証するために研究の方向転換を行った。結果として研究当初に掲げた「ワークスタイルの変革」は、

単なる情報共有の迅速化によって起こるのではなく、業務改革と相まって従業員自身だけでなく企業経

営者の意識も変わることによって実現できることもわかってきたのである。

2.モバイル技術の発展とユビキタス社会の到来

さて、企業のおかれている環境に目を転じて見よう。夢のようなバブル景気がはじけ、出口の見えな

い暗いトンネルのような後退期市場にある企業は、製品や市場における競争優位性を中核としたこれま

でのような戦略ではなく、一人の顧客からいかに裏切られないようにするか、またライバル会社とのゼ

ロ・サム・ゲームを避け、限られた市場からお互いに大の利益を獲得するといった戦略を志向し始め

ている。とくに市場飽和状態の製造業では、多くの IT投資を個別の業務改善にとどめるのではなく、事

業戦略と密接した業務改革として実行しようとしている。

モバイル端末の利点：携帯性、常時接続性

情報共有の高速化、意志決定の迅速化

業務生産性の向上、ビジネス機会のロス低減

コスト削減売上向上、従業員・顧客満足度向上

31

LS 研: モバイル端末の業務システムへの活用


一方モバイル技術では、デバイス技術、液晶等のユーザインタフェース、バッテリ、通信技術などの

要素技術の進化発展により、時間・空間的制約を解放するというモバイル技術的特徴が、さらに顕著と

なる。かつて、必要な時に持ち歩いた自動車電話が軽量化され、サービスが全国規模になったとき、ほ

とんどの営業マンが携帯電話を所持したように、要素技術の高度化が、ネットワークサービスの一般化

と相まって技術が大衆化して行くのである。これにより、いたるところで様々なモバイル端末を利用し

たユビキタスコンピューティングが実現して行く。

ユビキタス社会とは「ユビキタスコンピューティングにより社会的目的を達成できる状態」を示して

いると私達は考える。企業における社会的目的とは「企業経営により社会貢献する」ことであり、その

ためには「厳しい競争に打ち勝ち、経営を継続、発展させる」ことである。すなわち、企業は自身の目

的を達成するために、いち早くモバイル技術を活用し、ユビキタス社会に向けた対応を講じなければな

らない。将来、従業員がいつでもどこでも仕事ができるだけでなく、顧客も同様にユビキタス環境にい

るわけで、企業にとって顧客の活きた情報をリアルタイムで処理することが可能となる。さらに企業に

入力される情報の精度も飛躍的に向上する。ゆえに、顧客の視点では、よい企業とは顧客要求を正しく

迅速に処理し、要求価値を上回る価値を与えてくれる「顧客満足度」の高い企業ということになる。

したがって、企業活動がこれまでの生産性中心のサプライチェーンから顧客満足度を企業活動の指標

においた、革新的なワークフローが必要となる。私達はこれをユビキタス CRM(Customer Relationship

Management, uCRM)と呼ぶ。これにより顧客と企業は一体となり、単なる One to one マーケティングに

よる顧客関係の改良にとどまらず、製造現場や製品開発、品質管理のようなビジネスコア業務、人事管

理や文書管理といった間接業務までも顧客満足度を向上させる活動へと再定義される。

ユビキタス社会では企業に勤める従業員一人々々が顧客満足を目的として働き、一方でその従業員は

別の会社の顧客としてサービスを受けて生活し、顧客満足度を実感しているという、企業が顧客に提供

する価値に対して顧客満足という実感を伴った指標が対流する社会的なバリューチェーンが構築されて

行くと考える。

3.モバイル技術適用によりワークフローやワークスタイルがどのように変わるのか

uCRM をどのように構築して行くのか。この問題を解決して一挙に構築できる企業は少ないと思われる。

しかし、私達は、保守運用業務に問題を抱えるある事務機器メーカを想定して、その解決策を模索した。

この仮想企業は、営業担当者と保守要員の情報連携の薄さや、保守作業実施の際の部品調達の間違いな

どによって、悪循環を起こしているため、顧客の信頼を失いつつある状況に追い込まれている。

私達は、まず顧客の信頼を勝ち得るために何をすべきかを議論し、モバイル技術を使って、営業担当

者が顧客先で発生しているイベントに対して適時にフォローできる仕組みを作ることにした。さらに保

守開始から終了までのサービス時間を小にするため、障害発生と同時に保守要員のその時点でのステ

ータス（作業中か否か）を入手し、短時間で駆けつけることのできる要員を見つけ、アサインできるよ

うな、モバイルシステムも検討した。その他様々な報告書入力承認の省力化、営業支援業務の簡素化な

ど検討を加えた結果、企業内における大半のワークプロセスの改善が必要となり、そのためにシステム

化されたワークフローも改良され、有機的に連携される事になった。

例えば部品の生産（従来のオフィス／工場固定で決められた作業時間に、チームで業務を行っている

ワークプロセス：基幹型ワークフロー）が、モバイル技術の活用により、他のワークフローと連携する

ことで、従来の仕事のやり方を変え、24 時間いつでもどこでも受付ができ、物流システムとつながり、

ほぼリアルタイムに工場から部品が供給されるので、顧客へのサービスが格段と向上する。

一方、保守要員のワークスタイルは、事務所と現場の往復だけでなく、自宅から現場、次の現場へと

短経路で向かうことも可能になり、社内に設置された保守用知識データベースや、製品情報、在庫管

理システムと連携することで無駄のない保守が可能になる。これは、業務作業自身の精度向上とともに、

無駄な問題に振り回されないワークプロセスが実現でき、ワークスタイルも時間的・場所的制約から解

放され、従業員自身の知識も徐々に向上する。

そこで、私達はモバイル技術を適用して uCRM を根付かせるために、以下のように提言する。

一、モバイル端末を特定業務だけに適用するな

一、企業にとっての顧客との接点を全社的に捉え、経営者が先頭に立って取り組め

一、時間的・空間的制約を解き放つモバイル技術を使ってワークプロセスをきめ細かく作り込め

一、ツールを使いこなすために、使いやすい環境・風土作りを全社挙げて取り組め

32

LS 研: CMM Level3 導入指針


開始フェーズ

診断フェーズ確立フェーズ

実施フェーズ

発展フェーズプロセス改善への刺激

CMM Level3 導入指針

－CMM によるステップアップのポイント－

アブストラクト表１：悪い癖の例

1. 何故ＣＭＭなのか

当分科会では、ＣＭＭの有効性を検証するために、

メンバ企業が抱える悪い癖を事例（表１）として抽出

し、ＣＭＭの導入によっていかに改善できるのかを分

析した。

結果、課題の大半は、ＣＭＭのキープラクティス（何

がなされるべきかを記述した項目）を当てはめること

で、組織の良い習慣へと改善する糸口を見出せた。改

めて、ＣＭＭによるプロセス改善の有効性を再認識で

きた。

メンバ企業９社中６社がＣＭＭに基づいたプロセス

改善に取り組んでいる。そこで得た経験から、「ＣＭ

Ｍによるステップアップのポイント」を提言する。

表２：悪い癖の事例とＣＭＭ（抜粋）

№ プロジェクトや組織の悪い癖関連するＣＭＭのキープラクティス（何がなされるべきかの記述）

【レベル３：組織プロセス重視】

活動４：「組織のソフトウェアプロセスデータベース」の使用について組織レベル

で調整する。

活動５：組織で限定的に使用される新しいプロセス、手法、及びツールを、モニタ

ーし、評価し、そして適切であれば組織の他の部分に移転させる。

活動７：組織やプロジェクトのソフトウェアの開発と改善に関する活動について、

ソフトウェアプロセスの実装に携わるグループに情報を伝える。

5 情報やノウハウが個人又はプ

ロジェクトなどの狭い範囲だ

けで蓄積されており、組織全

体での有効活用がされていな

い。

【レベル３：組織プロセス定義】（活動の詳細は省略）

活動１、活動４、活動５、活動６

2. 導入指針

ＣＭＭの導入を進めていくにあたり、分科会メンバ

企業情報やＣＭＭ活動をしている企業への訪問インタ

ビューなどを通じてまとめた注意点や当分科会の見解

などの概要は以下の通りとなる。

2.1 開始フェーズ

プロセス改善目的の明確化は、経営計画に基づいて、

企業のどの組織に対して、いつまでに、どのレベルま

で、といったプロセス改善計画の元となる範囲と目標

を初に決める。この範囲と目標が終的にＣＭＭ導

入後の評価指標に使われ、導入の効果測定が可能となる。

契約、およびその後の進捗について

・ユーザ要件が不確実なまま契約

・契約後の開発部門の対応遅延

・納品直前になって進捗遅延を部門長が認識

プロジェクト計画（リスク、人的資源等）について

・作業内容が考慮不足の計画

・要員計画不十分・仕様変更多発

・リスクを意識しない計画

資源(人的資源、開発環境)と役割分担について

・力量を無視した体制、役割分担・教育不十分

・開発環境未整備・資源(人，物、金)不足

・ノウハウの共通化が図られていない

作業成果物の品質について

・外注への任せきり・顧客要件の未反映

・仕様凍結に時間がかかる

・第三者による品質／進捗状況のチェックがない

図１：簡易ＩＤＥＡＬモデル

33

LS 研: CMM Level3 導入指針


2.2 診断フェーズ

ＣＭＭを、自組織に導入するには、先ずＣＭＭを理解し、現在の組織の不足部分を明確にする必要が

ある。そのためには、ＣＭＭと自組織のプロセス（例：標準化活動、ＱＭＳ）をできる限り具体的に対

比することがポイントとなる。当分科会メンバ企業では、自組織の現状を正しく認識し、かつ迅速に改

善活動を立ち上げるために、まず小規模なアセスメントを実施している（ギャップ分析）。この分析によ

り、自組織の弱点すなわちプロセス改善活動として力を入れるべきポイントが明確になり、今後の推進

活動の方向性が得られる。ギャップ分析は、ＩＤＥＡＬモデルに具体的に明示された活動ではないが、

プロセス改善活動の第一の活動として実施するべきである。

2.3 確立フェーズ

レベル３達成の観点からみれば、標準プロセスの作成・改善とプロジェクトでの活用がポイントとな

る。この活動を推進する核となるメンバはＳＥＰＧとＳＱＡである。

ＳＥＰＧの活動は、標準プロセスの整備、ＳＱＡやプロジェクトメンバに対するトレーニング、改善

機運を高めるための社内広報であり作業負荷が高い。そのためにこれら作業に当たるＳＥＰＧは専任担

当者であることが望ましく、ＣＭＭ導入時は導入対象組織要員の１．５～２．５％（導入企業に対する

当分科会調査による）が適当である｡

標準プロセスの整備に当たっては、開発現場から既存のプロセスを集めることから始める。その時、

プロセスの網羅性を高めるため、規模の大きいプロジェクトを対象にしたほうがよい。切り出した作業

項目は、ＷＢＳとして整理し、その中で成果物、開始基準、終了基準、検証（レビュー）方法・時期な

どのポイントをまとめるとよい。

ＳＱＡの活動はプロジェクトの活動情況の監視及び助言であり、１プロジェクトに１名割り当てる（非

専任化、複数のプロジェクトの受け持ち可）ことが重要である。このＳＱＡ活動からＳＥＰＧは標準プ

ロセス改善のための有益な情報を得ることができる。

2.4 実施フェーズ

実施に当たっては、初から組織の全てのプロジェクトを対象に導入するのではなく、パイロットプ

ロジェクトを選定して試行すべきである。全プロジェクトを対象に導入するためには、全プロジェクト

支援可能なサポート体制とパイロット運用により評価され組織として、ほぼ確立された標準プロセスの

提供が必須となる。これらは通常の組織では困難な課題であり、パイロットプロジェクトによる試行と

改善を通して、組織内へのプロセス改善の気運及び理解度の向上、標準プロセスの改善実施を行った後

に全社展開するべきである。

2.5 発展フェーズ

レベル３において組織プロセス定義が確立し、そのプロセスに従った活動が行われて行く中で、その

プロセスを継続的に改善していくための仕掛けを確立しておく必要がある。

プロジェクトが完了したときにそのプロジェクトのノウハウを組織に残し、後進に伝えるため、プロ

ジェクトの品質、スケジュール、コスト面の予定と実績、技術的なノウハウを資料としてまとめ、発表

する場を設けることをお勧めする。この発表会は、直接的にはノウハウ伝授の場となり、間接的には継

続的プロセス改善の広報の場となる。また、プロジェクトの結果の良かったこと悪かったことから組織

の標準プロセスを改善する重要なナレッジデータベース（情報源）となる。

3. 最後に

ソフトウェアの開発環境はめまぐるしく変わり、従来の開発プロセスを踏襲することができないプロ

ジェクトが発生してくる。

開発現場には、標準プロセスに対して、常に何らかの手を加える状況に遭遇する。個々のエンジニア

は、「今回のプロジェクト」にあったプロセスを標準プロセスに追加や変更・削除しその結果を「良く」

も「悪く」も計測し結果を残し活用することを学ばなくてはならない。企業は、エンジニアたちが今後

のプロセスを再設計できる能力が育てていく必要があると言える。

34

LS 研:システム開発・運用における資産管理


システム開発・運用における資産管理

－マルチ適応型ＳＣＭの探求－ (Software Configuration Management)


1. 研究成果

当分科会では、ＳＣＭ（ソフトウェア構成管理:Software Configuration Management）を理解し、

導入・定着の問題を解決する手段として、企業風土、プロジェクト特性等によりカスタマイズできる

ＳＣＭソリューションマニュアルを作成し、検証・評価を行った。その結果として、｢システム開発・

運用における資産管理においてＳＣＭは有効である。｣という結論を導き出した。

2. 研究の動機

研究当初、メンバは「ＳＣＭって聞いたことあるけど・・・」「あの、面倒なやつでしょ」「CMMI で

は必須の項目だが定着しないんだよね」といった様々な思いが入り交じって集っていた。そのような

中で、共通していたのは『ＳＣＭを理解し、簡単に導入できるようにしたい。』という強い想いであっ

た。そこで、ＳＣＭの全貌を明らかにし、簡単に導入できるノウハウ、仕組みを研究することにした。

3. 研究経過

3.1 調査フェーズ

3.1.1 ＳＣＭの現状

一般的に、ＳＣＭという言葉を聞くとサプライチェーンマネージメントを思い浮かべる方が多

い。このように認知度も低く、ＳＣＭを行えば何が実現できるのかも浸透していないのが現状で

ある。日本ではソフトウェアドキュメント管理は属人的に管理されている場合が多く、分科会メ

ンバの中でも、ＳＣＭは担当者任せと言う意見が大半だった。しかし、欧米諸国では、意思の統

一を取るため、意思を統一するための管理方法が明文化されており、ＳＣＭも日本より浸透して

いる。近年になって、日本でも ISO,CMMI の一部として注目を浴びるようになった。

3.1.2 ＳＣＭの機能と効果

ＳＣＭは以下３つの機能に要約できる。

(1)バージョン管理

管理対象物を明確にし、定められた手順通りにそれらのバージョン(変更履歴)を管理する。

(2)リレーション管理

プログラムソース間のリレーション(関係)、設計書とプログラムのように工程間のリレー

ションを管理する。

(3)プロセス管理

バージョン管理、リレーション管理から得られるデータを元にプロセス(工程)を管理する。

また、これらの管理を実践することで、品質、生産性、管理力、保守・運用力の向上が望める。

3.1.3 ＳＣＭ導入と定着の問題

(1)導入時の問題

ＳＣＭは扱う対象が社外秘のために、手法、導入手順があまり公開されていない。そのため、

どのように導入してよいか解らず二の足を踏むことが多い。

(2)定着時の問題

画一的なＳＣＭを導入したために、プロジェクトの現状と管理ルールが合わず、途中で管理

不能となっている場合や、ルールだけが形骸化して残っている場合が多い。

(3)管理規模の問題

大規模プロジェクトでは管理対象物が多くＳＣＭが導入されることが多い。しかし、全く同

35

LS 研:システム開発・運用における資産管理


じＳＣＭ手法をそのまま小規模プロジェクトに適用すると、管理工数と費用が膨大になり、

上手く導入できない場合がある。

以上の問題点を解決するためのひとつの手段として、マルチ適応型ＳＣＭの提言として「ＳＣ

Ｍソリューションマニュアル」の作成を行うこととした。

3.2 ＳＣＭソリューションマニュアル作成・検証フェーズ

3.2.1 ＳＣＭソリューションマニュアルの作成

ＳＣＭを導入するにあたり、導入手順の理想だけを示しても、実際はプロジェクト特性、企業

風土等様々な条件があり、定められた一つの方法だけでは全てをカバーできないものである。当

分科会で作成した「ＳＣＭソリューションマニュアル」は、ＳＣＭを導入、運用していくにあた

って、様々な規約、実行方法を示し、企業風土やプロジェクト特性に合わせカスタマイズができ

るようにした。さらに、導入後にＳＣＭを定着させるため監査を行い、ＳＣＭ手順の見直しを行

えるまでを目指したオリジナルの行動指針書である。

「ＳＣＭソリューションマニュアル」（40 ページ）は全体を以下のように４つのステップに分

けているので、段階を踏んで導入できる（図１）。

①ＳＣＭ診断表

ＳＣＭ診断表の結果で自社の推奨レベル、現状レベルを把握する（図２）。

②ＳＣＭカスタマイズ

診断表の結果を元に、ＳＣＭ実施要領から企業風土、プロジェクト特性を加味し、必要な事

項を選択してカスタマイズし、目的に応じた導入を効果的に行う。

③ＳＣＭ導入実施

カスタマイズした計画に従って実践する。

④監査

ＳＣＭルール通りに運用されているか監査を行う。その時に問題点、改善点を収集し、ＳＣ

Ｍ活動改善に繋げる。

3.2.2 ＳＣＭソリューションマニュアルの検証と評価

作成したＳＣＭソリューションマニュアルを基にして、「大規模システム開発時」、「小規模シス

テム開発時」「システム運用時」の 3パターンについて仮想的に導入評価を行った。この検証で、

カスタマイズを行うことにより様々なシステムにＳＣＭを導入する手順を提示できることが証明

された。

4. まとめ

当分科会の成果物は、「ＳＣＭの機能、効果、問題の調査結果」と「ＳＣＭソリューションマニュア

ル」である。これらの成果物は、今後ＳＣＭの導入を考えている企業、現在導入済のＳＣＭに問題を

抱えている企業にとって有益な情報、資料になると自負している。

0

1

2

3

4

5

実行【Ver】

管理項目【Ver】

ツール【Ver】

その他【Ver】

実行【Rel】

工程内・工程間【Rel】

その他【Rel】

実行【Prc】

定義【Prc】

体制【Common】

図２診断表の結果例

推奨レベル

貴社現状レベル

図１実施要領図

ＳＣＭ

診断表ＳＣＭ

カスタマイズ

ＳＣＭ

実施要領

見直し

監査ＳＣＭ

導入実施

参照 ① ④ ③ ②

36

Documents

ITガバナンスの策定 －ITガバナンス策定のためのガ …jp.fujitsu.com/family/lsken/activity/work-group/02/...「われわれのCOBIT」の策定 と「ITガバナンス成熟度セルフチ

ITガバナンスの策定－ITガバナンス策定のためのガ …jp.fujitsu.com/family/lsken/activity/work-group/02/...「われわれのCOBIT」の策定と「ITガバナンス成熟度セルフチ