ITアーキテクト Vol.21 00.pdf

7/14/2019 IT Vol.21 00.pdf

http://slidepdf.com/reader/full/it-vol21-00pdf 1/126

w w w . i t a r c h i t e c t . j p

エンタープライズでクラウドを使う時代がやがて来る

ITシステムを

〝創る〟人のため

の

技術情報誌

その技術的核心はどこにあるのか？ユーザー企業にもたらすメリットは？アーキテクトは何をどう準備すべきか？

特集 1

特集 2

企業システム再利用への挑戦

特集 3

再点検！Webシステムの脆弱性対策

特別企画

「工事進行基準」が始まる！

クラウド時代への備え

21 Vol.

7/14/2019 IT Vol.21 00.pdf


21 V o l .

024

エンタープライズでクラウドを使う時代がやがて来る

クラウド時代への備えその技術的核心は何か？ユーザー企業にもたらすメリットは？

アーキテクトは何をどう準備すべきか？

●「システムズ・エンジニアリング＆アーキテクチャ」の手引き

SE＆Aの実践に向けて

●ビジネス・プロセス・モデリング講座

BPMSによるIT化を踏まえた業務フロー図の描き方

●上流工程を極める！【事例編】

シフト・フェーズにおけるシステム開発への移行準備

●ステークホルダーを納得させる問題解決テクニック

戦略論の古典から、IT“戦略”の本質を学ぶ

●ITアーキテクトのためのアタマの体操

共通性を発見するための地道な「標準化」作業

Bu s i n e s s M ode l i ng

Commun ica t i on T echn ique

特集1

076

052

066

A r ch i t ec t u r e D es ign

C o n t e n t s

060

090

「工事進行基準」が始まる！もう準備は万端？アーキテクトは契約形態や、見積もり／進捗管理手法を再確認すべし

特別企画044

7/14/2019 IT Vol.21 00.pdf


21 V o l .

C o n t e n t s

●トップ・アーキテクトの履歴書

出光興産澤井隆慶氏

●勝手にアーキテクチャ分析

ドラえもんのひみつ道具を作ってみよう

018

083

117

142

084

086

094

ビジネス／技術の変化を踏まえて、既存 IT 資産をどう活用するか

企業システム再利用への挑戦損害保険ジャパンの10余年にわたる取り組みに学ぶ、“守るべき資産”の選び方、

再利用を促進するアーキテクチャの作り方、再利用を統制／推進する体制の築き方

特集2

●News & Topics

●Books

●Present

●執筆者紹介

Part 1

再利用を実現するアーキテクチャポイントは“守るべき資産”の分離――損保ジャパンの再利用促進を支える「アプリケーション・レイヤ」の仕組み

Part 2

再利用推進のための施策と体制取り組みのきっかけと、再利用を推し進めるためのガバナンス施策、保守／運用体制

安全なWebシステムが企業のビジネス・チャンスを広げる！

再点検！Webシステムの脆弱性対策架空事例で再確認する、システムの計画から設計／開発、構築、運用フェーズで実施すべき主な施策とアーキテクトの役割

特集3118

096

108

7/14/2019 IT Vol.21 00.pdf


018 IT アーキテクト Vol.21

News & Topics

日本IBMら3社、アジャイル開発の適用を推進

日本IBM、チェンジビジョン、SRAは

2008年12月、大規模／分散開発

へのアジャイル開発プロセスの適用

に関して協業したと発表した。IBMが

分散開発プラットフォーム「IBM Rat

ional Team Concert」を、チェンジビ

ジョンが同プラットフォーム上で稼働

するプロジェクト管理ツール「TRICH

ORD for Rational Team Concert」

を提供し、SRAは両製品を組み入れ

たアジャイル開発支援サービス「アジ

ャイル開発プロセス可視化」を展開す

る。サービスの開始にあたっては、3社

で専任組織を立ち上げるという。

ITシステム開発を巡る

最新動向を伝える

富士通、仮想化を支援するサポート・センターを設立

富士通は2008 年12月、同社技

術者、ならびにパートナー企業を対

象に、仮想化に関する技術支援を行

うための「仮想化ソリューションセンタ

ー」を開設した。同センターには、サ

ーバやストレージなど各分野の仮想

化技術に精通した40名の専門家が

配置され、仮想化システムの最適な

構成を検証するほか、仮想化システ

ムに関する情報提供から設計、構築、運用までのサポート、技術者の育成

などを行う。検証対象となる仮想化

技術は、ヴイエムウェアの「VMwar

e」やマイクロソフトの「Hyper-V」など。

アイテックら、ICT技術者の育成サービスを開始

アイテックとスキルスタンダード研

究所は今年1月、共同でICT（Inform

ation and Communication Techn

ology：情報通信技術）技術者の育

成を請け負うコンサルティング・サービ

スを開始した。同サービスは、ITスキ

ル標準をベースに顧客企業が求める

ICT人材像を洗い出したうえで、理想

と現状のギャップを分析し、適切な教

育／評価プログラムを提供するという

もの。人材像の構築コンサルティン

グはアイテックが、教育プログラムの

作成／提供はスキルスタンダード研

究所が中心となって行う。

NECと日本オラクル、サポート・サービスを強化

NECと日本オラクルは2009 年1

月、日本オラクル内に「共同サポート

センター」を開設した。同センターは、

オラクル製品の技術サポートに対す

る顧客満足度の向上を目的に設立さ

れたもの。両社から配属された合計

20名の技術者が、NECのサーバ／

ストレージ製品上で動作するオラクル

製品の技術サポートを行うほか、その

品質向上に向けた検証作業を実施

する。サポート対象となるのは、デー

タベース製品「Oracle Database」、

インメモリ・データ・グリッド製品「同

Coherence」などのソフトウェア。

NTTと米国MS、SaaS型ビジネスの事業化を検討

NTTと米国マイクロソフトは2008

年12月、ネットワークとアプリケーショ

ンを融合したサービスの分野で協業

すると発表した。それによれば、両社

は今後、「NTTのSaaS基盤上でMSのアプリケーションを稼働させる」とい

ったSaaS型ビジネスの事業化を検討

していく。検討に際しては、NTTグル

ープ各社と米国MS／日本法人のメ

ンバーから成るチームを発足し、国際

展開も視野に入れる。NTTは現在、

NGNを活用したSaaS市場の形成を

推進しており、今回の協業はその活

動の一環に当たる。

日立製作所とSAP、グローバルな協業体制を構築

日立製作所とドイツの SA P は

2008年12月、SAP製品の販促や

システム構築に関して、グローバルで

協業すると発表した。これにより、日

立の海外拠点を活用したSAP 製品の導入支援サービスが世界規模で

展開される。例えば、日系企業が海

外進出する際、米国日立コンサルテ

ィングやインドのパートナー企業など

が連携してSAP 製品の導入を支援

することになる。また両社は、日立のミ

ドルウェア製品／プラットフォーム製

品とSAP 製品の適合性検証などを

共同で行っていく。

米国サン、RIA開発環境の「JavaFX 1.0」をリリース

米国サン・マイクロシステムズは

2008年12月、Javaプラットフォーム

上で動作するRIA（Rich Internet A

pplications）環境「JavaFX 1.0」を

リリースした。同プロダクトは、「JavaFX Development Environment」、

「同 Production Suite」、「同 Des

ktop」の3つのコンポーネントで構成

されており、このうちDevelopment

Environmentには、コンパイラや実

行環境、モバイル用エミュレータ、統

合開発環境「NetBeans Integrated

Development Environment 6.5」

などが含まれる。

7/14/2019 IT Vol.21 00.pdf


01IT アーキテクト Vol.21 01

F5ネットワークス、トラフィック管理製品を拡充

F5ネットワークスは2008年12月、ト

ラフィック管理製品「BIG-IP」シリーズ

の新モデル「BIG-IP 6900」を発売し

た。同製品は、すでに販売されているエ

ントリー・モデル「BIG-IP 1600」、「同3600」とハイエンド・モデル「VIPR

ION」の中間に位置するミッドレンジ製

品。IPv6ゲートウェイやSSLオフロード、

圧縮機能などを標準で備えるほか、2

つのデュアルコア・プロセッサを搭載し、

VIPRIONで培われたクラスタ・マルチ

プロセッシング技術を採用している点

を特徴とする。価格は、1,438万5,0

00円。

ソニックとデータディレクトが統合し、日本プログレスを設立

米国プログレスソフトウェアの傘

下にあるソニックソフトウェアとデータ

ディレクトテクノロジーズは2008年

12月、統合して新たに日本プログレ

スを設立した。新会社の代表取締役社長には、2社の代表取締役社長を

兼務していた田上一巳氏が就任。

また、併せて田上氏は、同じく米国プ

ログレス傘下にある日本アイオナテク

ノロジーズの代表取締役社長にも就

任しており、今後はアイオナと日本プ

ログレスの連携を強化することで、両

社の事業を段階的に統合していくと

いう。

データベース設計／管理ツール

CA ERwin Data Modeler r7.2JCA

製品名 CA ERwin Data Modeler r7.2J

稼働環境【対応OS】Windows 2000/XP SP2

/Vista、Windows Server 2003/2008

価格 94万5,000円

出荷時期出荷済み発売元日揮情報ソフトウェア

（☎：045-474-7852）

「CA ERwin Data Modeler

r7.2J」は、データベース設計／管理

ツールの新版。新たに、約100種類

の製品と連携してメタデータをインポ

ート／エクスポートする機能や、モデ

ル内のメタデータから文字列を検索

／置換する機能などが追加されたほ

か、ネーミング・ルール管理機能が強

化された。

データ連携／統合製品群

Informatica Release 8.6インフォマティカ

製品名 Informatica Release 8.6

稼働環境要問い合わせ

価格要問い合わせ

出荷時期出荷済み

発売元インフォマティカ（☎：03-5229-7211）

「Informatica Release 8.6」は、

データ統合製品「Informatica Po

werCenter 8.6」やデータ・アクセス

製品「同PowerExchange 8.6」など、

4製品から成るデータ連携／統合製

品群。新版では、複数のデータ・マ

スキング手法とアルゴリズムによって

データのプライバシーを確保する機能

やデータ・マッピング・ツールなどが追

加された。

E vent Calendar

ソフトウェアジャパン20091月27日（火）

会場：大手町サンケイプラザ

連絡先：情報処理学会事業部門

☎：03-3518-8373

URL：http://www.ipsj .or.jp/10jigyo/forum/software-j200

インターネプコン・ジャパン1月28日（水）〜 30日（金）

会場：東京ビッグサイト

連絡先：インターネプコン・ジャパン事務局

☎：03-3349-8502 FAX：03-3349-4900

E-mail：[email protected]

URL：http://www.nepcon.jp/inj/

Developers Summit 20092月12日（木）〜 13日（金）

会場：目黒雅叙園

連絡先：Developers Summit運営事務局


URL：http://codezine .jp/devsumi/2009

ITアーキテクト・サミット 20092月18日（水）

会場：東京国際フォーラム B7ホール

連絡先：ITアーキテクト・サミット事務局

☎03-5800-3534 FAX：03-5800-3979

URL：http://www.itarchitect. jp/event/summit/2009/

SECURITY SHOW 20093月3日（火）〜 6日（金）


連絡先：日経展示会サイト事務局

☎：03-5777-8600


URL：http://www.shopbiz.jp/ss/

CMO Conference 2009/Spring3月4日（水）

会場：六本木アカデミーヒルズタワーホール

連絡先：CMO Conference 事務局

☎：03-5800-4831 FAX：03-5800-3973

E-mail：[email protected] .jp

URL：http://www.idg.co.jp/expo/cmo/2009spring/

ソフトウェア開発環境展5月13日（水）〜 15日（金）


連絡先：ソフトウェア開発環境展（SODEC）事務局

☎：03-3349-8504 FAX：03-3349-8500

E-mail：[email protected]：http://www.sodec.jp/SODEC/

Interop Tokyo 20096月18日（月）〜 12日（金）

会場：幕張メッセ

連絡先：CMPテクノロジージャパン

☎03-5772-0612


URL：http://www.cmptech.jp/dcw/interop/

1月

2月

3月

コベリティ、アーキテクチャの解析ツールなど2製品を販売開始

コベリティ日本支社は2008年11

月、アーキテクチャ解析ツール「Cove

rity Architecture Analyzer」とリス

ク解析ツール「Coverity Software

Readiness Manager for Java」の

国内販売を開始した。前者は、ソフト

ウェア内のクラスやモジュールといっ

た要素間の依存関係を解析し、その

結果を図や表の形で可視化するほか、

アーキテクチャ変更時の影響をシミュレーションすることもできる。一方、後

者は、Javaコードを解析し、プログラム

の品質に影響を及ぼすリスク要因に

関する情報を提供する。

日本オラクル、異種アプリ連携製品を強化

日本オラクルは2008年12月、異

種アプリケーションによる業務プロセ

ス連携を実現するためのフレームワー

ク製品群「Oracle AIA（Application

Integration Architecture）」の拡充

を発表した。具体的には、SOAによ

るプロセス統合を支援する「プロセス

統合パック」に、連携対象としてオラ

クルのERP 製品「Ora le E-Busi

ness Suite」などが追加されたほか、根幹となるフレームワーク「ファウンデ

ーション・パック 2.2」が、アプリケー

ション・サーバ「Oracle WebLogic

Server」に対応した。

5月

6月

7/14/2019 IT Vol.21 00.pdf



オフショア開発の課題解決に

UMLを活用

今日多くの日本企業が、オフショア

開発として中国やインドなどアジア諸国

の企業にソフトウェア開発の作業を委

託している。ご存じのとおり、その主な

目的は、開発コストの削減と優秀な人

材の活用の 2点にある。しかしながら、言葉や文化、企業風土、ビジネス環境

などの違いもあり、必ずしもすべてのオ

フショア開発プロジェクトが成功してい

るわけではないようだ。

こうした状況の中、オフショア開発に

モデリング技術を活用し、発注者／受

注者間の意思疎通を円滑化すべく動き

Topic

を活発化させているのが、UMTP（UM

Lモデリング推進協議会）だ。同協議会

のオフショアソフトウェア開発部会では、

オフショア開発の課題とUMLの利点を

踏まえ、図1に示すような観点から、オフ

ショア開発におけるUML活用の指針を

まとめた「オフショア開発向けUML適用

ガイドライン（以下、ガイドライン）」を策

定してきた。

調査に基づき、オフショアでの

UML活用のノウハウを紹介

ガイドラインは、2007年6月に第1版

が策定され、2008年7月に第2版が公

開された※1。大別して5つのパートから

構成されており、各パートの概要は次の

ようになる。

●目的：オフショア開発全体におけるガ

イドラインの位置づけを説明

●オフショア開発における現状の問題

点と対策：アンケート調査に基づき、

現状の問題点とその対処策を解説●UMLモデリング：UMLの概要と、ガイ

ドラインが前提とするUMLモデリング

のスキル・レベルを説明

●UMLの適用範囲と開発のノウハウ

（Hints＆Tips）：オフショア開発にお

けるUMLの適用範囲と活用ノウハウ

を解説

●成果物サンプル：要求分析／定義

や詳細設計など、開発の各工程で

作成するUMLモデルの一部と、アー

キテクチャ説明書、詳細設計ガイドラ

インの一部をサンプルとして提示

業務アプリのカスタム開発にフォーカス

ガイドラインは、オフショア開発にお

いて特に難易度が高くなる業務アプリ

ケーションの中でも、とりわけ新規開発

となるカスタム開発に焦点を当てている。

開発のスタイルとしては、現在のオフシ

ョア開発における典型的なパターンとも

言える「オフショア側で、詳細設計から実装／単体テストまでを行う」というケー

スを想定。対象範囲については、日本

側で要件／設計をまとめ、それらをオフ

ショア側に伝達し、オフショア側と日本

側の双方で開発結果を点検するところ

までをカバーしている。そして具体的な

内容としては、「オフショア側のメンバー

に渡す仕様は、UMLで何を、どう作れ

ばよいのか」、「成果物は何に気をつけ

て点検すればよいのか」といったことが

まとめられている。

なお、オフショアソフトウェア開発部

会では今後、より多くの事例を収集して

サンプルを充実させたり、利用者からの

フィードバックを反映させたりしながら、

ガイドラインを更改していく予定だ。オフ

ショア開発に関係する読者は、定期的

にチェックするとよいだろう。

オフショア開発における言語／文化の壁を

UMLで乗り越える国内企業がソフトウェア開発作業をアジア各国の企業に委託する、

いわゆる“オフショア開発”が本格化して数年がたつ。

国内で行ってもトラブルの絶えないソフトウェア開発を、

言葉や文化が違う国との間で行うには課題が伴い、

生じるトラブルも少なくない。そこで、そうしたトラブルを回避する手段の

1つとして注目されているのが、「UMLの活用」だ。

UMTPがオフショア開発でのUML活用を推進

図1：オフショア開発でUMLを使うメリット

オフショア開発における主な課題

●不慣れな言語で読み書きするため、意図／理解に齟齬が生じる●日本語の文章で仕様を記述するのは難しい●書き手が、読み手に対して過度に理解力を期待してしまう（行間を読むなど）●日本／オフショア間で同じ認識を共有するのが難しい●仕様に対する誤解が、開発工程の後半で発覚することがある

UMLに対する期待／見解●図として表現でき、表記が統一されている●仕様の曖昧さを少なくできる●将来的に広範に普及すると期待される

オフショア開発でのUMLの活用

「UML＋オフショア開発」のメリット●言語に依存せず、ビジュアルにドキュメントを表記できる●上流から下流まで、統一的なコミュニケーション手段を使える●仕様書やコードに対して、変更個所や一貫性を調査しやすい●グローバル・スタンダードな表記法／開発方法が使える

※1 ガイドラインは、UMTPのWebサイト（http://

www.umtp-japan.org/）のオフショア・ソフトウェア開発

部会のページより入手することができる。

7/14/2019 IT Vol.21 00.pdf


02IT アーキテクト Vol.21

イノベーション創出にSOAを生かす

近年、企業が取り組むべき課題の 1

つとして、よく「イノベーションの創出」

が挙げられる。イノベーションという言葉

は「新技術の発明」といった文脈で使わ

れることが少なくないが、基調講演に登

壇した日立製作所の林重年氏（ソフト

ウェア事業部アプリケーション基盤ソフ

トウェア本部本部長）は、「技術革新だ

けがイノベーションではない」と主張する。

氏によれば、企業内での業務改革など

も、イノベーションの一種である。

林氏は、「イノベーションとは、多くの

人の知識や経験、あるいは作業手順な

どを組み合わせたり、連鎖させたりするこ

とによって起こるものだ」と説明する。し

たがって、企業でイノベーションを生み

出すには、人々の知識や経験が凝集さ

れた情報の統合／分析や、作業手順であるビジネス・プロセスの組み替えなど

が不可欠になる。そうした活動を推進す

るのに、今日ではITが大きな威力を発揮

するわけだが、なかでも、ビジネス・プロ

セスを柔軟に変更可能なSOAは、特に

有効な手段の1つに挙げられる。

そのSOAによるシステム構築の基盤

製品として、日立はCosminexusを擁し

ており、2008年10月には、その新版で

E vent

ある「Cosminexus Version 8」がリリ

ースされた。新版では、日立が蓄積した

開発ノウハウに基づき、開発手順など

を指示するシステム構築支援ツール「u

Cosminexus SI Navigation Syste

m」などが追加されている。基調講演で

は、こうした新製品のデモも実施された。

寸劇仕立てで業務改革におけるSOA/BPMの有効性を提示

林氏は業務改革を企業におけるイノ

ベーションの1つに位置づけたが、その

業務改革で長年ITを駆使してきたのが、

日立化成工業（日立化成）だ。同社の

管政之氏と日立コンサルティングの小

池博氏を招いた対談は、まず管氏が日

立化成の抱える課題を述べた後、コン

サルタントの小池氏が課題の解決策を

提案するというかたちで行われた。林氏によれば、日立化成では、20

00年ごろから業務改革を推進するとと

もに、それに合わせて全社のシステムを

改善してきた。その中では、“脱ホスト”

や全社システムのWeb化などを実施し

たという。

しかし、顧客の多様化に伴って複雑

化したビジネス・プロセスの改善など、ま

だ未解決の課題もある。そこで、同社

では現在、「ポスト業革」の掛け声の下、

さらなる業務改革／システム改善に取

り組もうとしている。ただし、システム改

善については、現時点で具体的な活動

が定まっておらず、これが同社の抱える

課題となっている。

解決策は「SOA/BPMで基盤を

構築し、支援組織を編成」すること

以上の課題に対して小池氏が提案

したのは、「SOAベースのシステム基盤

の構築」と「支援組織の立ち上げ」とい

う2つの取り組みである。前者は、SOA

やBPM（Business Process Mana

gement）を活用して、ビジネス・プロセ

スを柔軟に変更／拡張できる仕組みを

作るというものだ。また、「SOAベース

で開発／保守するために、方法論／ガ

イドの整備も行う」（小池氏）という。一

方、後者は、業務改革を支援する「BP

Mチーム」を編成することを指す。この

チームは、アーキテクチャの管理や、ビ

ジネス・プロセスの実行状況のモニタリ

ングといった作業を実施する。

こうした2人の対談からは、今日、業

務改革などでSOA/BPMがどう使われ

ようとしているのかをうかがい知ることが

できた。小池氏の提案の中で、特に注目すべきは2つ目の「支援組織の立ち

上げ」だろう。SOA/BPMを活用した業

務改革では、単にシステム基盤を作る

だけでは目的を果たせない。IT部門も

参画して推進組織を編成し、業務部門

／IT部門が一体となって改革を進める

必要がある。この体制こそが、SOA/B

PMによるイノベーション創出の鍵なの

だろう。

SOA/BPMにより、ビジネス・プロセスの

多様化に備える日立製作所は2008年11月18日、東京都の六本木アカデミーヒルズ40において、

「SOA（Service Oriented Architecture）」をテーマに掲げた技術セミナー

「HITACHI Open Middleware World 2008 Autumn Cosminexus Day」を

開催した。同セミナーでは、企業でのイノベーション創出において

SOAの活用を説く基調講演のほか、

複雑化するビジネス・プロセスの解決手段を討議する対談などが行われた。

ここでは、それらの講演／対談の内容をリポートする。

「HITACHI Open Middleware World 2008 Autumn Cosminexus Day」リポート

「イノベーションの創出」と「業務変革」を支えるITの姿とは

業務改革を巡る自社の課題につい

て説明する日立化成の管氏

7/14/2019 IT Vol.21 00.pdf



——DITAを考案した理由と、標準化

の経緯を教えてほしい。

私は長年、テクニカル・ライターとして、

IBM 社内の情報管理や製品マニュア

ルの作成などに携わってきた。それらの

業務に取り組む中で常に頭を悩ませて

きたのが、「多数の技術文書の作成／

管理を、効率良く行うにはどうすればよ

いのか」ということだ。そして、この問題を解決するために考え出したのがDITA

だ。つまりDITAは、当初はIBM社内の

文書を管理するのが目的だった。

わが社がDITAの仕様を策定し、ドラ

フト版として公開したのは2002年のこ

とだ。その後、標準化団体であるOAS

IS の中に専門委員会が設置され、標

準規格として仕様が策定されることに

なった。2004 年にバージョン1.0が公

開され、2007年にはバージョン1.1をリ

リース、現在はバージョン1.2の仕様策

定に取り組んでいるところだ。

——DITAはどのような特徴を持った

規格なのか？

DITAは、技術文書を作成／管理す

るための、XMLベースの情報アーキテ

クチャだ。一般に、技術文書は、作業

手順や用語集など、さまざまな情報に

よって構成されるが、それらの情報は文

Interv iew

書間で共通している場合が多い。そこ

で、そうした情報を再利用可能なかたち

で蓄積しておくことで、新たな文書を作

成する際、一から記述することなく、必

要な情報を組み合わせて作れるように

なる。それを実現するための規格が

DITAだ。つまり、DITAとは、技術文書

の構成要素をコンポーネント化し、その

コンポーネントを組み合わせて文書を作るための規格だと言えるだろう。

DITAでは、コンポーネント化された構

成要素のことを「トピック」と呼び、各ト

ピックをどのように組み合わせて1つの文

書にするかを定義したものを「マップ」と

呼ぶ。そして、トピックとマップを定義する

ためのマークアップ言語を定めている。

——DITAを使うことにより、主にどの

ようなメリットが得られるのか？

DITAによって得られるメリットとしては、

ドキュメント作成／管理の「高品質化」、

「低コスト化」、「迅速化」などが挙げら

れる。

例えば、高品質化とは、各トピックを

詳細かつ正確に記述できるようになるこ

とを指す。通常、技術文書の作成には

さまざまな分野のスペシャリストがかかわ

るが、このとき、だれがどこを記述する

のかといった割り振りが曖昧になりがち

だ。一方、DITAを使って文書作成を分

業化すれば、それぞれのスペシャリスト

は自分の専門分野のトピックに注力し

やすくなる。スペシャリストが余計な作

業に煩わされず、自分が専門とするト

ピックの執筆に専念することで、文書

品質の向上が期待できるだろう。

——DITAはあくまでも規格であり、こ

れを実際に利用するには、実装が必要

になる。DITAの実装の開発状況はど

うなっているのか？

まず、DITAはXML ベースの規格な

ので、DITAに基づく文書コンポーネント

（トピック）はテキスト・エディタやXMLエ

ディタなどによって作成することができる。

そして、トピックを組み合わせてHTML

形式や PDF 形式の文書を生成する

ツールとして、「DITA Open Toolkit」

がオープンソースで提供されている。

また、2008年11月にリリースされた

わが社の「IBM FileNet Content Ma

nager V4.5（FileNet CM V4.5）」で

は、DITAを正式にサポートした。この

製品では、DITAに基づくコンテンツ管

理機能とビジネス・プロセス管理機能を

融合させている。具体的には、DITAに

基づくコンテンツ（技術文書）を作成／変更すると、それに関連づけられたビジ

ネス・プロセスが自動的に起動されるよ

うになっている。

日本にも、すでにDITA Open Tool

kitを使っている企業があるが、FileNet

CM V4.5を利用すれば、さらにDITAの

メリットが得られるようになる。今後は、

FileNet CM V4.5の日本での展開を

積極的に進めていきたい。

XML規格の「DITA」で技術文書の

コンポーネント化を推進する製造業などの企業は、製品マニュアルなど多くの技術文書を抱えている。

そうした文書を一元的に作成／管理する目的で考案された

情報アーキテクチャがある。それが現在、OASISで標準化が進む

「DITA（Darwin Information Typing Architecture）」だ。

本誌は、このDITAの仕様策定を主導した

米国IBM Lead IBM DITA ArchitectのMichael Priestley氏に、

DITAが誕生した経緯や、これを使うメリットなどを聞いた。

米国IBM Lead IBM DITA Architect Michael Priestley氏に聞く

DITAを使うメリットを説明するMich

ael Priestley氏

7/14/2019 IT Vol.21 00.pdf


その技術的核心は何か

？

ユ

ーザー企業にもたらす

メリットは？

アーキテクトは何をどう

準備すべきか？

スケーラブルなインフラを、インターネットを介して

安

価に提供するクラウド・コンピューティング。

増

大するITコストの削減に向けたソリュー

ションとして、昨今高い注目を集めている。

現

在はまだ〝幼年期〟にあり、多くの課題を

抱えているものの、

いずれはそれらの課題が克服され、企業での本格利用が始まることだろう。

本

特集では、来るべき〝クラウド時代〟への

備えとして、

クラウド・コンピューティングの技術的な特性や、クラウドが企業にもたらすメリット

、

そ

してクラウドの導入に向けてアーキテクトが準備すべきことなどについて考察する

。

丸

山不二夫F u j i o M ar u y a m a

早稲

田大学

客員教授


7/14/2019 IT Vol.21 00.pdf


特集 1

エンタープライズで

クラウドを使う時代が

やがて来る

特集 1


7/14/2019 IT Vol.21 00.pdf


クラウド・コンピューティングとは何か

まず初めに、クラウド・コンピューティングとは何なのか

を、歴史的な経緯も含めて簡単に説明しておこう。

クラウドの起源はインターネット・クラウド

そもそも「クラウド」という言葉は、コンピュータ・ネットワ

ークの世界では随分前から使われていたものだ。例え

ば、図1はSOA（Service Oriented Architecture）

の技術の 1つである「SCA（Service Component

Architecture）」の概要を示したものだが、この図の中

には小さな雲のアイコンが2つ描かれている。これら雲の

アイコンは、慣例として、ネットワークが外部のネットワー

ク、すなわちインターネットに接続されていることを示したも

のだ。このインターネットを指したクラウド、すなわち「イン

ターネット・クラウド」こそ、現在クラウド・コンピューティン

グなどで使われている「クラウド」という言葉の起源なの

である。

クラウドという言葉がインターネット・クラウドを起源にし

ていることは、「クラウドとは何か」を考えるうえで重要な

意味を持つ。なぜなら、概念的にも、機能的にも、クラウ

ド・コンピューティングは、このインターネット・クラウドの直

系の“子孫”だからだ。ただし、インターネット・クラウドと

いう言葉が登場した当初のインターネットがWebを中心

としたハイパー・テキストの世界であったのに対して、その子孫であるクラウド・コンピューティングの世界は、Web

を中心としたネットワーク・サービスの世界へと急速に変

わろうとしている。

クラウド史における記念碑的イベント

「Web 2.0 Summit 2006」

それでは、現在使われているクラウド※1 の概念は、い

つごろ登場したものなのだろうか。筆者は、2006年11月

に米国サンフランシスコで開催された「Web 2.0 Sum

mit 2006」が、この概念が広く浸透するきっかけの1つ

になったと見ている。Web 2.0 Summitは、2004 年、

2005年にオライリーが主催し、Web 2.0ブームを巻き起

※1 以降、本特集では、特に断りのない限り、クラウドという言葉をクラウド・

コンピューティングの意味で用いる。

implements

図1：SCAの概念図に描かれた“クラウド”

MyValueSubsystem

MyValueModule

ModuleComponentMyValueModuleComponent

ModuleComponentCustomerModuleComponent

http://www.NEWstockquote.org/services/StockQuote

CustomerModule

implements


その技術的核心は何か？

ユーザー企業に

もたらすメリットは？

アーキテクトは

何をどう準備すべきか？

7/14/2019 IT Vol.21 00.pdf


特集 1

こしたWeb 2.0 Conferenceが名前を変えたものだ。W

eb 2.0 Summit 2006では、米国マイクロソフト、グーグ

ル、アマゾンの3社が、クラウド・コンピューティングとそれ

によるインフラの重要性を強調した。

●クラウドは巨大なデータセンター

例えば、『It's All About the Infrastructure』と題した講演において、米国マイクロソフトでWindows Live

の運用担当副社長を務めるDebra Charapaty氏は、

次のように述べている。

「世界中の人が々、いつもインターネットのクラウドにつ

ながっていると信じている。それはまさに、われわれが望ん

でいたことだ。われわれの顧客は、望んだものを、望ん

だ時間に、望んだデバイス上で得ることができる。われわ

れの顧客は、サービスや情報がクラウドから来ると考え

ている。この経験こそ、まさにわれわれが彼らにもたらした

かったものなのだ」

クラウドがサービスを提供する、そして、われわれは常

にそれにつながっている――こうした感覚が広まっている

ことを、Charapaty氏は「偉大な経験」と呼ぶ。ネットワ

ーク上でわれわれが経験しつつある変化を、こうした視

点からとらえるのは重要なことのように思われる。

ただし、問題はその先にある。現代が“サービスが空

から降ってくる時代”であるとしたら、だれが、どうやって、

それらのサービスを提供するのか。Charapaty氏は、次

のように続ける。「イメージとしてのクラウドはフワフワした印象を与えるか

もしれないが、実際にサービスを提供しているクラウドに

は固い実体がある。それは、ネットワークのインフラであ

り、多数のサーバ群であり、それらを統合した巨大なデ

ータセンターである」

●クラウド・インフラの重要性にいち早く気づいたグ

ーグル

Web 2.0 Summit 2006において、グーグルで検索

サービス担当マネジャーを務めるMarissa Mayer氏が

行った『A Secret Google Discovered .. .』という講演

も印象深いものだった。

Mayer氏は、同社の代表的なサービスである検索

が、「検索文字列を入力するだけ」という非常に単純な

ユーザー・インタフェースで提供されつつも、その背後では極めて複雑な処理が行われていることを紹介した（次

ページの図2）。それによれば、ユーザーが入力した検

索文字列はデータセンターに送られるが、もし最初にア

クセスしたデータセンターが混み合っていたら、空いてい

る別のデータセンターにリクエストが自動的に転送され

る。そして、それぞれのデータセンターでは数千台のコン

ピュータが協調して動作し、検索処理を実行する。

グーグルは、どんな検索要求に対しても、0.5秒以内

に検索結果を返すよう努力しているという。1分はもちろ

ん、1秒かかっても遅すぎるのだ。Mayer氏は、「サービ

スとして多くの人に使ってもらうためには、“サービスのス

ピード”が決定的に重要な意味を持つ」と説いて講演

を締めくくった。氏が講演タイトルに冠した「A Secret

Google Discovered（グーグルが見つけた秘密）」と

は、Webのスケールで高速なサービスの提供を可能に

する巨大なインフラの重要性に、グーグルがだれよりも早

く気づいていたことを指していたのだ。

●アマゾンがAmazon EC2/S3を発表

もう1つ、Web 2.0 Summit 2006におけるアマゾンCEOのJeff Bezor氏による『Web-Scale Computing』

と題した講演も、クラウドの歴史において重要なものだっ

た。

Bezor 氏はこの場で、「Amazon EC2（Elast ic

Computer Cloud）」と「Amazon S3（Simple Sto

rage Service）」という2つのクラウド・サービスの開始を

宣言したのだ。このうち、Amazon S3は「Storage in

the Cloud（クラウド上のストレージ）」、Amazon EC2は


7/14/2019 IT Vol.21 00.pdf


たらした。後世、クラウドの歴史が語られるときには、グ

ーグルの大規模分散システムとともに、Amazon EC2/

S3も必ず取り上げられることだろう。

クラウドの中核的な概念

筆者は別に、本稿でクラウド・コンピューティングに対

して厳密な定義を与えようとは思っていない。なぜなら、

これは現在も進行中の歴史的な現象だからだ。現在

進行形で変化／進化を続け、今後どのようになるかわからないものに対し、その枠組みを規定（定義）するような

ことなどできない。

ただし、クラウドという言葉が初めて登場したWeb

2.0 Summit 2006の開催時点において、マイクロソフト、

グーグル、アマゾンら3社の間には、クラウドの概念につ

いて次のような共通認識があったことは確かだ。

●インターネットを通じて多様なサービスを提供する

●Webのスケールで膨大な数の顧客を対象とする

「Computer Capacity in the Cloud（クラウド上のコ

ンピュータ資源）」という位置づけを与えられていた。

「Webのスケールで、高度な分散処理を展開すると

しよう。現状では、その規模の大小にかかわらず、開発

者は70％以上の時間とエネルギー、そしてお金を、裏

方で何の差別化ももたらさない仕事のために費やさなけ

ればならない」とBezor氏は言う。氏によれば、今後はそ

の裏方の仕事が、Amazon EC2/S3のようなクラウド・

サービスによって不要になる。「革命は始まったばかりだ。それはビットやテラ・バイト

といったストレージの革命ではない。これは、われわれが

働いている領域から、つまらない仕事、価値を生み出さ

ない仕事を追い出し、われわれがイノベーションを行う時

間を持つのを可能にする革命なのだ」（Bezor氏）

実際、スケーラブルなサービスを完全従量制で提供

するというAmazon EC2/S3の特徴と新たなビジネス・

モデルは、クラウド技術の発展に小さくないインパクトをも

図2：グーグルの検索サービスの仕組み（Marissa Mayer氏の講演資料より）

Serch Query"lightning fast Ajax"

LoadBalancer LoadBalancer

Result Page

GoogleWeb Server Ads ＋WebSearchMixerGoogleWeb ServerMixer







7/14/2019 IT Vol.21 00.pdf


特集 1

を向けさせた。

クラウド環境にもOSが必要

マイクロソフトの場合は、自社のクラウド・プラットフォー

ムである「Azure Services Platform」の中核となる

「Windows Azure」のことを、端的に“クラウドOS”と呼んでいる。

例えば、何かデスクトップ・アプリケーションを作るとき、

ハードウェアを一から組み立てたり、デバイス・ドライバや

ファイルシステム、ジョブ・スケジューラなどを自分で書いた

りしなければならないとしたら、アプリケーションの開発は

非常に大変な作業になるだろう。そして、多数のコンピ

ュータを協調動作させる大規模な分散処理環境でア

プリケーションを動かそうとしたら、さらに複雑な作業が必

要になる。

PCにおいて、開発者がそうした面倒な作業を意識し

なくても済むのは、OSが存在するからだ。つまり、クラウド

にもOSが必要なのである。マイクロソフトのクラウドOSで

あるWindows Azureは、PCのOSと同様に、ただし1

台のコンピュータではなくネットワークで結ばれた多数の

コンピュータに対して、具体的なハードウェアやデバイス

の構成からは分離された抽象的な実行環境、共有ファ

イルシステム、リソース割り当て／管理機能、使いやすい

開発環境などを提供する。

もちろん、グーグルもすでにこの課題には取り組んでおり、同社なりの解決策も得ているようだが、残念ながら

“グーグルのクラウドOS”と呼ぶべきものについて、今のと

ころ詳細な情報は公開されていない。もっとも、グーグル

のクラウド・サービスを構成する個々の技術については、

その詳細が徐々に明らかになりつつある。以降では、ク

ラウド・コンピューティングの先駆者であるグーグルの分

散処理技術とマイクロソフトのクラウドOSを通して、クラウ

ドを実現する技術の特徴を詳しく見てみたい。

●上記を可能にする巨大なインフラを構築／運営／管

理する

この3社が、現在のクラウドの主要なプレイヤーである

ことを踏まえれば、今日形成されつつあるクラウドという概

念の中核には、これらの特徴があると考えられる。

クラウドの技術的な核心

それでは、クラウド・コンピューティングは、果たしてどの

ような技術によって可能になるのか。これについて、アマ

ゾンのAmazon EC2/S3を例にとって考えてみよう。

クラウド上のリソースを協調動作させ、

管理する仕組みの重要性

Amazon EC2/S3が提供している「ネットワーク上の

ストレージ／サーバ」は、一見すると非常に簡単なサー

ビスに見える。ただし、ここで注意しなければならないの

は、アマゾンがユーザーに提供しているサービスの単純

な総和が、アマゾンが擁するシステムのすべてではないと

いうことだ。

Amazon EC2/S3のようなサービスを提供するため

には、ネットワーク上に分散して存在する物理的なディス

クやサーバを仮想化して論理的に管理し、稼働してい

ないものはリソース・プールに登録して、変動する要求に

応じてリソース・プールから動的に取り出して処理を割り当てることにより、サービスのスケーラビリティを保障しなけ

ればならない。

つまり、Amazon EC2/S3のようなサービスをユーザ

ーに提供するためには、その背後に、クラウド上の膨大

なリソースを管理して協調動作させる大掛かりな仕掛け

が必要であり、アマゾンはそうした仕掛け（インフラ）を作

り上げたのだ。Amazon EC2/S3のサービス開始は、

クラウドの実現にかかわるこの課題の重要性に皆の眼


7/14/2019 IT Vol.21 00.pdf


ンスは、クロック数が1MHzの8ビット・マシンからクロック

数が3.5GHzの64ビット・マシンへと1万倍以上も向上し、

メガ・バイト当たりのメモリの価格は3,500ドルから10セント

へと3万分の1に下がった。ディスクに至っては、メガ・バ

イト当たりの単価は1,200ドルから0.33セントへと、360万

分の1に低下している。ネットワーク速度の向上もめざましく、この25 年間で100baud以下のスピードから100M

bpsへと100万倍以上高速になった。われわれが持つ

技術のコスト・パフォーマンスは、めざましい勢いで向上し

ているのである。

ネットワーク上における分散処理

「全世界の情報」は近年、加速度的に増大を続け

ており、「全世界の情報をアクセス可能にする」というグ

ーグルの夢は、いまだに達成されていない。ただし、その

成否にかかわらず、グーグルがその目標に対してどうアプ

ローチしたのかは注目する必要がある。

グーグルがとったのは、「コモディティ化した安価なコン

ピュータ（PC）をネットワーク上にたくさん並べて協調動

作させる」という、典型的なスケールアウトのアプローチ

だ。同社がこのアプローチを選択した背景には、「ハイ

エンドなコンピュータよりもコモディティ化したPCのほうが

技術革新の恩恵を受けるファクターが大きく※2、ネットワ

ーク速度の向上スピードが、CPU速度の向上スピード

を上回っている」という認識がある。以下に、グーグルの分散処理技術の代表として、

「GFS（Google File System）」と「MapReduce」とい

う2 つのインフラ技術を紹介するが、これらの技術でも、

上記のアプローチが貫かれている。そしてGFSとMapR

educeという、ネットワーク上でのスケールアウトを実現す

る分散処理技術こそが、グーグルの技術的競争力の

グーグルの分散処理技術

グーグルは奇妙な会社だ。同社が最先端のITの担

い手であることを疑う余地はないが、彼らは、その技術を

マイクロソフトやオラクルのようにソフトウェア・パッケージと

して提供しているわけではない。グーグルはクラウド上で、検索をはじめとする多彩なサービスを提供している

が、そのほとんどは無料である。では、同社はどこから収

益を上げているのか。よく知られているように、グーグルは

ネットワーク上のコンテンツに対し、それに関連する広告

を結び付けることで収入を得ている。その意味では、グ

ーグルは“広告会社”である。

とは言え、そう決め付けてみたところで、グーグルの特

徴を十分にとらえることはできない。同社が従来の広告

会社と大きく異なるのは、「世界中のWebページにイン

デックスを付けてそれらを組織し、全世界の情報をアク

セス可能にする」という目標を掲げ、それら膨大なコンテ

ンツを広告の新しい舞台にしようとしているところだ。

グーグルの技術の背景にあるもの

――急速に低下した技術コスト

ここで技術的な側面から、同社の事業が対象にして

いるWebの世界の“規模”に注目してみよう。グーグルが

インデックスを付けているWebページの数は数十億に上

り、そのデータ・サイズはペタ・バイト・レベルに達する。それにもかかわらず、同社の検索サービスは、それらのデ

ータに対する検索処理を0.5秒以内に行うスピードを誇

っている。

グーグルが「全世界の情報をアクセス可能にする」と

いう目標を掲げたのには、技術的な背景がある。その

背景とは、20世紀後半、より具体的には1980年代から

始まったIT革新だ。

この4半世紀の間に、マイクロ・プロセッサのパフォーマ※2 彼らの試算では、同じ能力の場合、ハイエンド・コンピュータはPC によ

るクラスタの30倍以上のコストがかかるという。







7/14/2019 IT Vol.21 00.pdf


特集 1

十億個のファイルとして扱ったのでは管理が煩雑になる。

そこでGFSでは、数十億個のWebドキュメントを1つにま

とめ、数テラ・バイトのサイズの巨大なファイルとして扱う。

その結果、I/O操作やブロック・サイズに関する設計が

見直されることになった。例えばGFSでは、ブロック・サイ

ズの値として、通常のファイルシステムよりもかなり大きい64MBという値を選んでいる。この64MBのデータの固ま

りを、GFSでは「チャンク」と呼んでいる。

第三に、ほとんどのファイルは、既存のデータに上書き

されるのではなく、新しいデータとして追記（Append）さ

れる。GFSの運用では、ファイル内のランダムな書き込み

は事実上、存在しない。主要なアクセス・パターンは、

クローラが世界中から収集してきたインターネット上の大

量のWebドキュメントを、ファイルに追記していくことだ。

一度書き込まれた後、そのファイルは読まれるだけであ

る。しかも、シーケンシャルに読まれる。巨大なファイルへ

のアクセス・パターンがこのように固定されると、ファイルシ

ステムへの追記の機能に関しては、パフォーマンスの最

適化とデータの単一性（Atomicity）保証が焦点とな

る。そしてこれらの観点から、GFSには細かなチューニン

グが施されている。

第四に、GFSでは、アプリケーションとファイルシステム

の協調設計（Co-Design）をとることで、柔軟性を高め、

システム全体にメリットをもたらしている。具体的には、ア

プリケーションに面倒な負担をかけることなくファイルシステムを大幅に単純化するために、ファイルシステムの整合

性のモデルを緩めている。また、64MBの追記操作をア

トミックなものにし、追記操作が完了するまで他の操作を

ロックすることにより、「単一消費者／複数生産者（Ma

ster/Worker）」パターンを使い、複数のクライアントが

余分な同期をとることなくファイルへの追記を行えるように

核心なのだ。

Google File System

GFSとは、安価なPCサーバから成るクラスタ上に構

築された分散ファイルシステムであり、これがグーグルの

分散処理インフラの中心的な構成要素となる。GFSにおいて、1つのクラスタは2,000台以上のサーバから構

成される※3。GFSはペタ・バイト・サイズの巨大なファイル

システムであり、1秒間に2,000MBのデータを読み書きす

る性能を持つ。ここでは、グーグルが公開している文献

（http://labs.google.com/papers/gfs.html）に基づ

き、GFSの特徴を紹介しよう。

●GFSの主要な特徴

GFSには、次のような特徴がある。

第一に、GFSのシステムは、安価でどこでも手に入る

部品で構築された数千台のコンピュータによって構成

されるため、ハードウェアの故障は例外的な出来事で

はなく、常に起こりうることだと考えられている。したがって、

「恒常的なモニタリング」、「エラーの検出」、「誤りに

対する強さ」、「自動的な回復機能」などがシステムに

統合されていなければならない。グーグルはこの課題

に、ハードウェアではなくソフトウェアの力で対処している。

筆者は、同社でPlatforms Architectを務めるBen

Jai氏が2006年、台湾の大学の講演で次のように発言

したと知り、大いに感心した。「なぜ、皆さんは高価で信頼性の高いハードウェアの

ことで思い悩んでいるのでしょうか？信頼性の高いハード

ウェアは、ソフトウェア・エンジニアを怠け者にするだけで

す。障害に強いソフトウェアが、安いハードウェアを役立

つものに変えるのです」

第二に、GFSが扱うファイルは、これまでの常識から

すれば巨大である。クローラが集めてきたインターネット

上のWebドキュメントを、そのままキロ・バイト・サイズの数※3 グーグルに現在どのくらいのクラスタがあるのか、正確な数は公表され

ていない。


7/14/2019 IT Vol.21 00.pdf


け、Map関数と同様に〈Key,Value〉という形式で出力

するが、Reduce関数は同じキーのグループだけを対象

にし、その出力範囲は、Map関数とは異なり同じキーの

グループとなる。

ところで、図4に示す例では、Map関数による出力を

Sortする前に、同じキーが同じノードに属するよう、3個のブロックに分割している。この操作はPartitionと呼ばれ、

直後に続くSortと並び、MapReduceの本質を成す重要

な処理となる。もっとも、これらの処理は、グーグルの

MapReduceのシステムではMapReduceのライブラリが

自動的に実行するため、プログラマーがその動作を意識

することは少ないかもしれない。このPartitionとSortを合わ

せた処理を、グーグルではShufingと呼んでいる。

では、MapReduceのまとめとして、以下にMapR

なっている。

MapReduce

一方のMapReduceは、グーグルの分散処理を支え

る基本的なアルゴリズムだ※4。このアルゴリズムに従って

「Map」と「Reduce」という2 種類のコードを書くと、MapReduceのシステム・ライブラリの助けを借りて、初

心者でも数千台のコンピュータが協調動作する見事な

分散処理のプログラムを作ることができる。

●MapReduceのアルゴリズム

MapReduceのアルゴリズムは、一見すると単純であ

り、その応用範囲は限定されているように思える。だが

筆者は、この単純さこそが、分散処理の可能性の基本

的なエッセンスを表現しているのだと考える。実際、近年

では、グーグルの内部にとどまらず、さまざまな分野で

MapReduceの応用が進んでいる。以下に、ログ・ファイ

ル中でのURLの出現回数をカウントする処理を例にと

り、MapReduceのアルゴリズムの概要を簡単に紹介す

る（図3）。

前述したように、MapReduceのプログラムは、大別し

てMapとReduceの処理（関数）から成る。このうちMap

関数は、通常キーと値のペア（〈Key,Valu〉という形式）

で処理結果を出力する。図3の例では、Map関数はロ

グ中にURLを見つけると、それを〈URL,1〉というかたち

で出力している（この例では、Valueは常に1となる）。続いて、Map関数による出力は、キーごと（この例で

は、同じURLごと）にグループ分けされる。グループ分け

には、一般にキーによるソート（Sort）が用いられる。

そして次に、Reduce関数による処理が行われる。図

3の例では、同じキー（URL）の値（1）を足し合わせてお

り、それによってログ中のURLの個数がカウントアップされ

ることになる。

なお、一般にReduce関数はMap 関数の出力を受

URL_A,1

URL_A,1

URL_A,1

URL_H,1

URL_I,1

URL_K,1

URL_K,1

URL_N,1

URL_O,1

URL_W,1

ReduceSort

URL_W,1

URL_A,1

URL_K,1

URL_K,1

URL_A,1

URL_N,1

URL_A,1

URL_I,1

URL_H,1

URL_O,1

URL_A,3

URL_H,1

URL_I,1

URL_K,2

URL_N,1

URL_O,1

URL_W,1

図3：MapReduceのアルゴリズム（ログ中のURLをカウント）Map

URL_W

URL_A

URL_K

URL_K

URL_A

URL_N

URL_A

URL_I

URL_H

URL_O

URL_K,1

URL_K,1

URL_I,1

ReduceSort

URL_W,1

URL_A,1

URL_K,1

URL_K,1

URL_A,1

URL_N,1

URL_A,1

URL_I,1

URL_H,1

URL_O,1

図4：MapReduceにおけるShuffling（Partit ion+Sort）の処理Partition

URL_W,1

URL_N,1

URL_O,1

URL_A,1

URL_A,1

URL_A,1

URL_H,1

URL_I,1

URL_K,1

URL_K,1

URL_N,1

URL_O,1

URL_W,1

URL_N,1

URL_O,1

URL_W,1

URL_A,1

URL_A,1

URL_A,1

URL_H,1

URL_A,3

URL_H,1

URL_I,1

URL_K,2







7/14/2019 IT Vol.21 00.pdf


特集 1

市場への本格参入を画する同社の戦略的なプロジェク

トだ。

Webアプリケーションにおける

スケールアウトの課題

マイクロソフトがフォーカスしているエンタープライズ分野において、現在主流となっているのはWebアプリケー

ションである。Windows Azureの技術的な特徴を見

る前に、このWebアプリケーションにおけるスケールアウト

に関する現状の課題を確認しておこう。

Webアプリケーションでは、最前面にWebサーバか

ら成るWeb層を置き、その背後にビジネス・ロジック層を

配置して、最背面にはデータベース層を置くという、多

階層モデルが一般的な構成となる。この多階層モデル

におけるスケールアウトは、次のような方式で行われること

が多い。

まず、Web層とビジネス・ロジック層のコピー／レプリ

カを複数作って並べ、その前面にロード・バランサを置

く。外部からのアクセスはロード・バランサによって振り分

けられ、それぞれのリクエストはレプリカで並行して処理さ

れるといった具合だ。

上記の方式には、1つ弱点がある。それは、Web層と

ビジネス・ロジック層のスケールアウトが可能になったとし

ても、データベースへのアクセスがシステム全体のボトル

ネックになるということだ（次ページの図 5）。オラクルのRAC（Real Application Clusters）のような製品は、

この問題に対処するために考案されたものである。

現状、この問題に効率的に対処する方法として注目

educeにおける処理のポイントを列挙しておこう。

●Map関数とReduce関数は、いずれも分散処理が

可能であり、同一ノード内で処理が完了する

●分散処理のパターンにはMaster/Workerパターン

を採用しており、そのためTuple Space※5のパターン

に従っている●Map関数により、出力のキー領域はさまざまに変更さ

れるが、Reduce関数による出力は、入力と同じキー

領域にとどまる

●MapReduceのアルゴリズムにおけるShufingの重

要性は上述したが、実際の処理時間においても、各

ノード間をデータが一斉に移動するShufing処理に

最も多くの時間が使われる

●MapReduceの出力（直接的には、Reduce関数の

出力）は、再びMap関数の入力となりうる

マイクロソフトのクラウドOS技術

続いては、マイクロソフトのクラウドOSであるWindows

Azureを通して、同社のクラウド戦略を概観してみた

い。Windows Azureに関しては、まだ比較的、技術

情報が少ないので、誌面を多めに割くことにしよう。

マイクロソフトは「Software＋Service」というスローガ

ンの下、これまでのWindows OS、Ofce製品、Visu

al Studioといったパッケージ・ソフト中心のビジネスを大胆に転換し、それらに加えてエンタープライズ向けのクラ

ウドによるサービスの提供をビジネスの大きな柱にしようと

している（その中では、上記のソフトウェア群が、Softw

are＋ServiceのSoftwareに当たる）。同社は現在、1

カ月に1万〜3 万台という猛烈なペースでサーバの増強

に努めており、数年後には100万台規模に達するという

巨大なインフラの構築に邁進している。そのマイクロソフト

が昨年10月に発表したWindows Azureは、クラウド

※4 MapReduceは、グーグルの基幹を成す分散処理システムの実装系の

別名にもなっている。

※5 並列プログラミング言語のLindaで採用されている共有メモリ空間の概

念。メモリ空間への値の出し入れの手続きが定められており、それに従うこと

で、相互に無関係なプロセスの間で値を共有することが可能になる。


7/14/2019 IT Vol.21 00.pdf


ここで、図6をご覧いただきたい。図中のWebロール

層、ワーカー・ロール層は、それぞれ図5のWeb層、ビ

ジネス・ロジック層に対応するものだが、これらの層は相

互に切り離されており、いずれもデータベースを含むスト

レージ・サービス層に結び付いている。もちろん、この図

では表現していないが、Webロール層もワーカー・ロー

ル層もそれぞれ複数個のインスタンスを配備することがで

き、必要に応じてスケールアウト構成をとることが可能だ。

これは、Windows AzureにおけるWebアプリケーショ

ン実装の最も重要な特徴の1つである。単純なページ・

を集めているのは、データベースの前に高速の分散メモ

リ・キャッシュを置くという手法だ。オラクルのCoherence

やIBMのObjectGridなどは、このアプローチに基づく

製品である。これらの分散メモリ・キャッシュでは、データ

ベースからのデータの読み込みだけでなく、書き込みま

でもメモリ上のキャッシュに対して行い、データベースとの

間で自動的に同期がとられる。低速なデータベースへ

の読み書き処理が、高速なメモリへの読み書き処理に

置き換わるわけだ。なお、分散メモリ・キャッシュへのアク

セスは、見かけ上は、システム全体にまたがる単一の仮想的なキー／値のハッシュテーブルに対するアクセスとし

て行われる。

Windows Azureにおける

Webアプリケーションの実装

Windows AzureにおけるWebアプリケーションの実

装は、基本的には上述した多階層の考えに基づくが、

トポロジーが少し異なる。

図 5：Webアプリケーションのスケールアウトではデータベース・アクセスがボトルネックになる

ロード・バランサ

Web 層ビジネス・ロジック層

ボトルネック！

データベース

図6：Windows AzureにおけるWebアプリケーションの構成例①

Webロール層

ストレージ・サービス層

ロード・バランサ

ワーカー・ロール層

パブリック・インターネット







7/14/2019 IT Vol.21 00.pdf


特集 1

「サービス・モデル」と呼んでいる。現在のところ、Web

アプリケーションなど3種類のテンプレート／サービス・モ

デルが用意されているだけだが、今後テンプレート／サ

ービス・モデルが拡充され、それらに従ってシステムを自

動構成することが可能になれば、インフラの準備が非常

に楽になるだろう。なお、読者の中には、こうしたアイデアを“空想的”だ

と思う方がいるかもしれないが、実はそうでもない。最近、

一部で注目を集めているスリーテラのAppLogicという

製品は、Webサーバやロード・バランサ、ロガー、デー

タベースといった“部品”の間をワイアリングによって結合

すると、データセンターの内部にその構成のシステムを自

動的に準備してくれる。

また、冒頭に紹介したSCAでは、ハードウェアの配備

まではできないものの、ソフトウェア・コンポーネントをワイア

リングによって結合してダイアグラムを作れば、複数ノー

ドのコンポーネントから成るシステムを配備することが可能

だ。

Windows Azureは、こうしたデータセンター管理技

術、コンポーネントの配備技術の到達点を踏まえて作ら

れているのだ。

Azureのストレージ・サービス「Azure SDS」

さて、クラウドのエンタープライズ利用において焦点の

1つとなっているのは、クラウドが提供するデータベース機能、つまりデータ・サービスである。Windows Azure

では、このデータ・サービスとして「Azure SDS（SQL

Data Services）」が提供される。

Azure SDSは、構造化されたデータに対し、リレー

ショナルなクエリを実行可能なクラウド上のデータベース

だ。少しまどろっこしい表現となったが、要はAzure

SDSはリレーショナル・データベース（RDB）ではないが、

RDBであるかのように扱えるデータ・サービスである。

ベースのWebアプリケーションは、Webロール層とストレ

ージ・サービス層だけで処理される。

それでは、もう少し複雑なビジネス・ロジックを必要とす

る処理は、どのように実行されるのか。その場合、複数

のWebロール層からのメッセージは、共通のキューに送

られ、それを複数のワーカー・ロール層が読み出す（逆の流れもありうる）。

このように、Webロール層とワーカー・ロール層を直接

結合させず、間にキューを挟んで疎結合にすることによ

り、Webロール層では面倒な排他制御や同期処理のこ

とを考えずに済むようになる。このアーキテクチャは、Web

ロール層とワーカー・ロール層が1つずつのシステムでは

オーバーヘッドが高そうに見えるだろうが、Webロール層

がm個、ワーカー・ロール層がn個といった具合にスケー

ルアウトしていくシステムでは、非常に合理的な選択であ

る。

システム構成の柔軟な変更が可能

Windows Azureの大きな特徴の1つは、システムの

構成を柔軟に変更可能な点だ。

上で、Windows AzureにおけるWebアプリケーショ

ンの構成上の特徴を述べたが、これがWi ndow s

Azureの構成のすべてかというと、そうではない。上に記

したのは、Windows Azureが提供するサービス構成

の一例にすぎず、Windows Azure自身は、そのかたちをどのようにでも変えられる能力を持つのだ。

例えば、ユーザーが「Webアプリケーションのシステム

がWindows Azure上にほしい」と思ったとしよう。その

場合、ユーザーはWebアプリケーションのテンプレートを

選べばよい。そうすると、Windows Azureは、そのテン

プレートを具体的なシステム構成を表すダイアグラムに

変換し、それに従ってそのシステム構成が実際に配備さ

れる。Windows Azureでは、このダイアグラムのことを


7/14/2019 IT Vol.21 00.pdf


という名前を持つカラム（プロパティ）が存在するが、一

方はDatetimeという型を持つのに対し、もう一方は

Stringという型を持っている。これは、スキーマの型定義

に従うRDBではありえないことだ。

それだけではない。この例では、下の行（エンティティ）

に、上の行（エンティティ）にはないEngineSizeというカラム（プロパティ）が追加されている。これは、RDBで言えば、

テーブルの行ごとにカラムの数が違うということを意味する

が、もちろん、これもRDBではありえないことだ。

このように、Azure SDSのテーブルでは、行（エンティ

ティ）はスキーマで定義されるような構造を持たず、任意

の型を持つカラム（プロパティ）の単なる“入れ物（Bag）”

でしかない。このことは、Azure SDSのテーブルでは、

RDBのようにスキーマを持つ行ではなく、プロパティのよう

なキー／値型の存在が重要であることを示している。事

実、Azure SDSのテーブルの行に相当するエンティティ

自身が、ある値をキーにしてプロパティの入れ物を値とし

て持つキー／値型の存在として実装されている。メタレ

ベルで言えば、エンティティのキーも型を持つが（図7の

kindがそうである）、それもエンティティごとに違っていてか

まわない。

RDBのように扱えることの重要性は、本誌読者には

説明するまでもないだろう。RDBは、今日最も普及した

データベース形式であり、これになじんだ開発者の数は

多い。

それでは、そもそもなぜ、Azure SDSはRDBとして作

られていないのか。それについては以降の説明を読めばご理解いただけるだろう。

●Azure SDSの技術的特徴

では、Azure SDSの特徴を述べていこう。まずは

Azure SDSにおける“テーブル”の構成に関する特徴を

見てみたい。

通常のRDBと同様、Azure SDSでも、情報はテー

ブルという形式に構造化されて蓄えられる。ただし、

Azure SDSでは、テーブルは「エンティティ」の集合であ

り、エンティティは「プロパティ」の集合である。ここで、エ

ンティティを“行”に、プロパティを“カラム”に置き換えれ

ば、RDBとの見かけ上の類似が成立する。

もっとも、RDBでは、テーブル内のすべての行は決ま

った型を持つカラムからできていなければならない。例え

ば、あるテーブルの1行が「名前」という文字型のカラム

を持つのならば、そのテーブル内のすべての行は「名

前」という文字型カラムを含むことになる。

また、RDBでは、テーブルを定義したスキーマが存

在するが、このスキーマが規定するのは、あるテーブル

の行を構成するカラムが持つ型の並びである。それに対して、Azure SDSのテーブルの行に相当するエンティテ

ィでは、その行（エンティティ）を構成するカラム（プロパテ

ィ）は、行（エンティティ）ごとに異なる型を持っていてよい。

つまり、Azure SDSのテーブルには、スキーマ定義が

存在しないのだ。

ここで、図7を見ていただきたい。この図は、Azure

SDSのテーブルの2つの行（2つのエンティティ）を示した

ものだ。これらの行（エンティティ）には、同じListingDate

図7：Azure SDSの特徴

エンティティのプロパティの型は、エンティティごとに違っていてもかまわない

プロパティ型値

Metadata ID EntityID VWGOLF-01kind EntityKind Car

Description String Reliable, one owner, ...

FlexPropsPrice Numeric 12000.00

ListingDate Datetime 01-01-2008

LocationZip String 98052

プロパティ型値

MetadataID EntityID MINICOOPER-264

kind EntityKind FunCar

Description String Reliable, one owner, ...

Price Numeric 12000.00

FlexProps ListingDate String 1st January, 2008

LocationZip String 98052

EngineSize Numeric 1600

異なるkind

異なるインスタンス型

プロパティの追加







7/14/2019 IT Vol.21 00.pdf


特集 1

の行（エンティティ）が同じカラム（プロパティ）を持つ必要

がないので、図8-②に示すように3つのテーブルを1つにま

とめることが可能だ。ここでは、あるエンティティにはないプ

ロパティのカラム欄にはNullを入れている。こうして、疎な

（ところどころにNullが含まれた）大きなテーブル1つで、

複数のテーブルから成る情報と同じ情報を表現することができる。もちろん、テーブルが1つなのでJoin操作は必

要ない。必要な情報は、すべてこのテーブルに含まれて

いる。

もともと、テーブルのJoin操作は非常に重たい処理で

ある。理論的には、テーブルAとテーブルBのJoinは、2

つのテーブルの直積、すなわち「2つのテーブルの行に

ついて可能になるすべての組み合わせの空間を作る」と

いう操作だ。例えば、100行から成るテーブルAと、同じ

く100行から成るテーブルBのジョインとは、100×100＝1

万行のテーブルを仮想的に作り、その中で検索を行うこ

とを意味する。しかし、Joinを用いたほとんどの検索で

は、1万行のテーブルを想定する必要はないだろう。ここ

で、上に述べた“大きく疎なテーブル”こそが、3つのテー

ブルで考えうるすべてのJoinに必要かつ最小限のテー

ブルであることに注意してほしい。

こうした特徴は、Azure SDSでテーブルを作る際、

RDBとは違ったデータ・モデリングの手法が必要になる

ことを意味する。例えば、複数のカンファレンスについて、

各カンファレンスのトラックと、トラック内のセッションの検

索を可能にするデータベースのテーブルを考えてみよう。

RDBならば、次のように3つのテーブルを作るのが普通だろう（図8-①）。

①すべてのカンファレンスにIDを振り、Conferenceテー

ブルを作る

②すべてのセミナーのトラックにIDを振り、Trackテーブ

ルを作る。このテーブルは、セミナーIDを外部参照キ

ーとして持つ

③すべてのセミナーのすべてのトラックのセッションにID

を振り、Sessionテーブルを作る。このテーブルは、セミ

ナーIDとトラックIDを外部参照キーとして持つ

こうしておけば、外部参照キーによってJoinを行えば、

あるセミナーのすべてのトラックを検索したり、あるセッショ

ンが行われたすべてのセミナーを検索したりといったこと

が容易になる。ただしこれは、複数のテーブルのJoinが

必要であることを意味する。

それに対して、Azure SDSのテーブルでは、すべて

図8：RDBのテーブルとAzure SDSのテーブル

①RDBのテーブル ②Azure SDSのテーブル

CID ConfTitle

1 PDC

2 Tech ReadyConf ID Track ID Session ID Conf Title Track Subject Session Subject

1 Null Null PDC Null Null

1 1 Null Null Cloud Compute Null

1 1 1 Null Null Live Meeting

2 Null Null Tech Ready Null Null

2 1 Null Null SQLServer 2008 Null

2 2 1 Null Null SQLServer FILESTREAMSID CID TID Session Subject

1 1 1 Live Meeting

1 2 1 SQLServer FILESTREAM

TID CID Track Title

1 1 Cloud Compute

1 2 SQLServer 2008

Partitioning key

Primary key

Row key

Rowgroup

Rowgroup


7/14/2019 IT Vol.21 00.pdf


故障した際には、そのノードはネットワークから切り離さ

れ、レプリカの1つがプライマリに昇格する。レプリカの数

は任意に設定可能であり、高可用性の要求にも柔軟

に対応できる。

また、Azure SDSは、パーティションを格納する多数

のデータ・ノードとマスタ・ノードで構成される。このうちマスタ・ノードは、「グローバル・パーティション・マップ」とい

う、どのデータ・ノードにどのパーティションが格納されて

いるのかに関する情報を持つ。パーティションのデータに

アクセスする際には、まずマスター・ノードに対して、その

パーティションがどのノードに含まれているのかを問い合

わせ、ノードの情報を取得したら、そのノードにアクセスす

る。こうした機構は、レプリカの扱いも含め、先に見たグ

ーグルのGFSとよく似ている。

なお、表面上はまったくわからないが、Windows Az

ure/Azure SDSの深部で動作している興味深い機構

がある。それは、P2PのDHT（Distributed Hash Ta

ble）に基づくオーバーレイ・ネットワークであり、Wind

ows Azureでは、これをクラウドOSの基礎に使っている

のだ。紙数の都合上、詳細は割愛するが、これは下位

のネットワークでノードが頻繁に出入りしても、オーバーレ

イされた上位ネットワークの機能はその影響を受けないと

いう仕掛けである。Windows Azureでは、P2Pオーバ

ーレイ・ネットワークの特質を、多数のノードから成る大

規模分散システムの耐障害性向上に利用するという、非常に斬新なアプローチをとる。このアプローチは、クラ

ウドによるインフラ構築に、今後大きな影響を与えると筆

者は見ている。

クラウドがエンタープライズにもたらすメリット

ここまで、グーグルとマイクロソフトのサービスを通して、

こうしたテーブルのモデルは、RDBに慣れきった頭には

奇妙なものに映るだろう。しかし、これはモデリングのスタイ

ルの違いでしかないのだ。以下に、Azure SDSを理解す

るうえでのその他のポイントを2つほど挙げておこう。

●Azure SDSのエンティティ／プロパティから成るテーブ

ルの概念は、RDBのテーブルの概念の拡張である。Azure SDSのテーブルは、RDBのテーブルとして解

釈できるとは限らないが、すべてのRDBのテーブルは

Azure SDSのテーブルとして解釈できる

●現在のAzure SDSの実装では、テーブル間のJoin

操作はサポートされていないが、次にリリースされる実

装ではJoin操作もサポートされる。そのとき、RDBとの

見かけ上の違いはもっと小さくなる（ただし、そうした操

作が本当に必要で効率的かは、テーブル設計時に

十分考慮する必要がある）

●Azure SDSの可用性技術

スケールアウト構成をとる大規模な分散システムでは、

コンピュータの障害にどう対応するかが重要な課題とな

る。先に、グーグルの大規模分散システムでは、この課

題にどう対処しているのかを見たが、Windows Azure

でも、耐障害性を高め、システム全体の可用性を上げ

るための周到な仕掛けが用意されている。

Windows Azureにおいて、システム全体の可用性

を高めるうえで最も中心的な役割を果たすのは、P2P技

術を応用した斬新なクラウドOSの設計だが、ここではAzure SDSに関する可用性向上のための仕組みを見

てみよう。

Azure SDSのテーブルを構成するパーティションは、

Azure SDSのデータ・ノードに格納されるが、同時にそ

のレプリカが複数個、別のノード上に作られる。そして、

データの読み込みはプライマリのノードから行われるが、

データの書き込みはプライマリだけでなく、すべてのレプリ

カに対しても行われる。そのうえで、プライマリのノードが







7/14/2019 IT Vol.21 00.pdf


特集 1

系は、こうした問題をきれいに解決する可能性があるの

だ。

なお、クラウドを利用したピーク時対応に関しては、

興味深い事例がある。米国アニモト（http://animoto.

com/）は、画像と音楽をアップロードすると、音楽に合

わせたスライドショーを自動的に作成するサービスを提供している会社だ。あるとき、Facebookで同社のサービス

が評判になり、アクセス数が爆発的に増加した。もともと

Amazon EC2を使ってサービスを提供していたが、同

社はわずか3、4日の間に、サーバ数を50台から3,500台

に増設したという※6。

●コスト・パフォーマンス上のメリット

また、ピーク時への対応だけでなく、システムのコスト・

パフォーマンスの面で、クラウドには次のようなメリットもあ

る。

まず、クラウドのサービスを提供するクラウド・プレイヤ

ーらは、それぞれ100万台に届こうかという規模にまでサ

ーバ設備の増設を推し進めようとしている。安価なコンピ

ュータを多数並べるスケールアウトのメリットに加えて、設

備の大規模化によるスケール・メリットにより、各社のサ

ービス提供価格はさらに下がると考えられる。

もう1つ、ムーアの法則によれば、ハードウェアの価格

は1.5年で半額になる。これは、3年で4分の1、4年半で

8分の1、6年で16分の1という劇的なペースだ。企業で

の設備更新は、減価償却に合わせた5年単位で行われることが多い。これは、5年の間は、その間に技術革

新によってもたらされたコスト削減のメリットを享受できな

いということを意味する。一方、クラウドの場合、適宜新

たなサーバを追加投入できるというクラウドの特性により、

さしたる運用／管理のオーバーヘッドなしに、システムの

クラウドを成り立たせている主な技術を概観してきた。こ

こからは視点を変え、クラウドが、それを利用する側にど

のような影響を与えるのかを考察していこう。まずはクラウ

ドがもたらすメリットについて考える。

クラウドの経済的なメリットエンタープライズ分野でのIT利用に対して、クラウド

の登場が大きな変化をもたらすのは間違いない。クラウ

ドを使うことで、企業は自前のサーバ設備を持たずに、

クラウドからエンタープライズ向けのサービスを受けること

が可能になる。これにより、ユーザー企業では、サーバ

の導入といったインフラ構築に伴う固定経費がなくなる。

また、サーバ設備の保守／管理にかかる人的負担とコ

ストからも解放される。クラウドを使うことには、明らかに経

済的メリットがあるのだ。

●慢性的に抱えていた過剰設備の軽減

今日、多くの企業のITインフラは、当然のことながら、

想定されるピーク時のニーズに対応できるように設計さ

れている。ただし、システムがピーク・レベルで稼働する

時間は、大抵の場合、年単位で見るとそれほど長くはな

い。自社で固定的な設備を抱えることは、実は慢性的

に過剰施設を抱えるのと同じことなのだ。そのうえ、ピー

ク・レベルそのものが、市場の状況に応じてダイナミック

に変動する。現在のように不況期になれば、設備はます

ます過剰なものとなり、市況が好転すれば、一転して設備不足となる。いずれにしても、市場ニーズへの柔軟な

対応は困難である。

ピーク時にも対応できるインフラを準備する、あるいは

不足時には設備を追加するというのは、確かに現時点

では合理的な経営判断だ。しかし、これはあくまでも「現

時点での技術水準」の中で行われている経営判断だと

いうことを忘れてはならない。クラウド技術が実現するスケ

ーラビリティと、利用の多寡に応じた従量制の課金体

※ 6 このエピソードの詳細については、アニモトのブログ（htt p: //bl og .

animoto.com/2008/04/21/amazon-ceo-jef-bezos-on-animoto/）を参

照されたい。


7/14/2019 IT Vol.21 00.pdf


ビスとしては、セールスフォース・ドットコムのSaaS（Softw

are as a Service）が知られている。セールスフォース

は、汎用のPaaS（Platform as a Service）も提供して

いるが、そちらはまだこれからという段階だ。

SaaS型のサービスは、スケーラビリティの側面よりも、

アプリケーション開発の手間をかけずに直ちにサービスインできるという側面がメリットとして大きく、開発要員が少

ない小規模な企業に向いていると言える（ただし、セール

スフォースのユーザーには、郵政公社のような大手もい

る）。サービスを迅速に投入し、いち早くクラウドのコスト・

メリットを享受したいと考える向きには、魅力的な選択肢

の1つだろう。セールスフォースは、アマゾンやグーグルと

いった他のクラウド・プレイヤーとの連携を打ち出してい

る点も興味深い。

今後の成長株はGoogle App Engineと

Windows Azure？

筆者が今後、エンタープライズ分野で急速に成長す

ると見ているのは、グーグルの「Google App Engine」

とマイクロソフトのWindows Azureである。両者は、ま

だ商用サービスは始まっておらず、提供されているのは、

いずれも機能が制限されたものばかりだ。いわば“幼年

期”と言える段階にある。ただし両者は、今後1、2年で

恐るべき“怪物”に成長するだろう。

詰まるところ筆者は、エンタープライズ・システムをクラウドに移行するには、少なくともあと1、2年の猶予期間が

あると考えている。この猶予期間をどう過ごすかが非常

に重要だ。これは、現在の不況期が明けた後、ビジネ

スの世界がどう変わっているかについての展望とも結び

付いている。

今行うべきは、一言で言えば「クラウド時代への変化

に備えよ」ということに尽きる。クラウド時代の到来は不可

避である。そして、その時代を迎えるにあたってそれぞれ

構成を随時コスト・パフォーマンスの高いものに更新して

いける。これは、正常かつ競争的な環境の下では、サ

ービス・コストの低下として現れるはずだ。

繰り返すが、クラウドを利用することには、以上のよう

に明確な経済的メリットがある。その意味では、クラウド

を使うかどうかは、すこぶる経営的な判断だ。筆者は、現在の世界的な不況が、グローバルな規模でクラウド

が普及する強力な誘因になると見ている。

エンタープライズ向けクラウドの現状

もっとも、クラウドに経済的メリットがあるとは言うもの

の、現時点において、エンタープライズ向けのクラウド・

サービスは十分に成熟しているとは言い難い。

実用レベルのサービスは

Amazon EC2ベースのみ

現在、グローバルな規模で商用の汎用的なクラウド・

サービスを提供しているのは、アマゾンのAmazon EC2

を利用したもののみである。アマゾンのサービスは、スケ

ーラビリティの面で大きなメリットがあるが、それを生かした

システムを構築するには、かなりのスキルが必要になる。

一般に、アマゾンのサービスは、前出のアニモトのように

技術力の高いスタートアップ企業／ベンチャー企業に向

くとされているが、この評価は妥当だろう。ただし、クラウドへの移行には、いずれにせよそれなり

の技術的準備が必要なのであり、技術的な問題を移

行の障害だと見るのは正しくない。クラウドがどのようなも

のかを知り、そのスケーラビリティを実感するのに、Am

azon EC2は格好のサービスであろう。

中小企業に向いたセールスフォース

一方、特定アプリケーションに特化したクラウド・サー







7/14/2019 IT Vol.21 00.pdf


特集 1

のスケールアウト手法では実現が難しかった、大規模な

データベースのスケールアウトにある。アマゾン、グーグ

ル、マイクロソフトのエンタープライズ向けクラウドへのアプ

ローチはそれぞれ異なるが、3 社ともに、その中核に

SimpleDB（アマゾン）、BigTable（グーグル）、Azure

SDS（マイクロソフト）といったクラウド上のデータベース・サービスを据えているのは偶然ではない。クラウド上のデ

ータベースが提供するデータ・サービスを使うことこそ、

エンタープライズにおけるクラウド活用の根幹なのだ。

なお付け加えれば、企業が提供するサービスのネット

ワーク化／コンシューマー化が一層進むにつれて、

MapReduce 型のデータ処理技術も、将来のエンター

プライズ・システムでは活発に利用されるようになると筆者

は見ている。

クラウドのSLAは低いのか？

昨年、筆者はAmazon EC2のSLA（Service Le

vel Agreement）が99.5％であることを知り、ある種のシ

ョックを受けた。「そんなに低いのか」という驚きではなく、

低めのSLAを提示し、それで安価なサービスを提供しよ

うというアマゾンの割り切ったビジネス・モデルにショックを

受けたのだ。確かに、SLAが99.5％のシステムよりは、

99.999％のシステムのほうが信頼できるのは当たり前であ

る。しかし、SLAをわずか0.499％高めるのに何十倍もの

コストがかかるとしたらどうだろうか。ここで、投資対効果（ROI：Return On Investment）というビジネス上の合

理性に基づく判断の余地が生じてくる。

もっとも、このことから、クラウド・サービスのSLAが低い

と思い込むのは早計だ。Amazon EC2の「SLA＝

99.5％」という数字は、クラウド上でコンピュータを貸し出

すというアマゾンのサービス提供スタイルによって規定さ

れている。グーグルのGFSやマイクロソフトのAzure

SDSでは、基本的にデータのレプリカ数によって可用性

の企業が考え、準備する時間はまだ十分にあるのだ。

クラウド環境への移行に際しての課題

クラウドの利用に関しては、考慮すべき課題も少なくない。また、クラウドへの移行をためらわせる理由の中に

は、合理的な根拠を持つものもあれば、明らかな誤解

や心理的な障壁にすぎないものも見受けられる。ここで、

よく指摘される課題をいくつか取り上げてみたい。

「クラウドはエンタープライズに向かない」

という誤解

最初に取り上げるのは、今日では大分少なくなったも

のの、一部ではいまだに根強い、「クラウドは、グーグル

のようなコンシューマー向けのサービスには向いている

が、エンタープライズには向かない」という指摘である。こ

れは明らかな誤解だ。

確かに、目下のクラウドの中心は、コンシューマー向

けに展開されているサービスである。ただし、現在のクラ

ウド・プレイヤーらの主な関心は、エンタープライズ分野

でのクラウド利用に向けられている。

また、「グーグルのMapReduceのようなシステムは、

通常のエンタープライズ・システムには応用できない」とい

う指摘もある。この指摘は、その限りでは確かに正しい。もっとも、クラウドの技術的な核となるスケールアウト技術

には、MapReduceのように大量のデータをバッチ処理

して有用なデータを取り出すことでスケールアウトする大

規模分散処理技術と、通常のWebアプリケーション向

けのスケールアウト技術の2タイプがある。この2つのタイ

プを混同するのは正しくない。

クラウドのエンタープライズ利用における焦点は、明ら

かに後者のタイプ、とりわけ従来のWebアプリケーション


7/14/2019 IT Vol.21 00.pdf


ことにある。かつてNTTが東西に分割される際、国が

県域を越えるサービスの提供を禁じたことがあった。その

ため、すべての都道府県にサーバを立てたのだという。

これは、ネットワークを通じたサービス提供の特質を理

解しない判断だと言わざるをえない。県を国に置き換え

てみれば、上の2つの議論が同じ構造であることに気づくだろう。

なお筆者は、こうした反応が起こる背景には、もう1つ

別の問題が潜んでいると考えている。それは、いまだ国

内企業の中から有力なクラウド・プレイヤーが出てきてい

ないということだ。日本から有力なクラウド・プレイヤーが

誕生すれば、当然その企業は、アジアをはじめとする諸

外国にサービスを提供したいと望むだろう。国内クラウ

ド産業の育成は、日本経済にとって重要な課題だ。イン

ターネットをベースとする今日のIT産業は、国境を越え

た産業である。この産業において、外部からの攻勢に

対して人為的な障壁を設け、保護主義に陥ってはなら

ない。

企業が本当に国際的な競争力を付けたいと考えるな

ら、クラウドのインターネット利用は前向きに検討する価

値のあることだろう。筆者は、多くの日本企業が、クラウ

ドの利用を通じて積極的に海外に進出していくことを期

待している。

クラウドはミッション・クリティカルなビジネスには向かないか？

最後に、「クラウドはミッション・クリティカルなビジネスに

は向かない」という議論を取り上げよう。

前述したクラウドの現状を見る限り、この判断は正し

いように思われる。クラウドの利用は、エンタープライズの

“心臓部”からではなく、その周辺部から、またSaaSのよ

うに大企業ではなく、中小企業から拡大していくだろう。

ただし、ミッション・クリティカルな領域が、オンプレミス※7

が決まる。両者とも、レプリカの数は任意に設定可能で

あり、必要なら高いレベルのSLAを設定できる。

もちろん、クラウドでも、SLAを上げればコストは増大す

る。しかし、そのコストは、スケールアップによって独自にシス

テムを増強するのにかかるコストよりもはるかに安いはずだ。

そもそも、「高価なシステムはダウンしない」というのは“神話”にすぎず、実際にはどのようなシステムでも障害が起き

る可能性がある。その可能性を確率的な数値として把握

し、対処策を必要なコストと合わせて明確に意識するクラ

ウドのアプローチのほうが、根拠のない安全神話をあてに

するよりもはるかに合理的ではないだろうか。

クラウドのインターネット利用を巡って

クラウドを使うことに対する拒否反応のいくつかが、パ

ブリックなインターネットを利用することに向けられているの

は残念なことだ。現代のネットワーク技術、セキュリティ

技術、大規模トランザクション技術、データセンター技

術などは、すべてインターネットの商業利用の拡大ととも

に発展してきたものである。クラウドを使うということは、そ

れらの自然な発展形にすぎないのだ。

そもそも、必要であれば、われわれの前にはさまざまな

選択肢が用意されている。VPN（Virtual Private Ne

twork）の中にシステムを閉じることもできるし、NGN（N

ext Generation Network）を使って高いセキュリティを

確保するという手もある。どの選択肢をとるかは、各社が事業の特性と投下できるコストを踏まえて判断すべきこと

だ。

また、クラウドのインターネット利用を巡っては、「自社

のデータを、どこの国にサーバがあるのかわからないクラ

ウドに預けるのはためらわれる」という声も聞かれる。これ

はなぜだろうか。インターネットに国境はない。クラウドで

インターネットを使うメリットは、ネットワークさえあれば、ど

こからでも簡単に高品質の安価なサービスを入手できる







7/14/2019 IT Vol.21 00.pdf


特集 1

クトである読者は経営層に対し、技術的なメリットだけで

なく、クラウドに移行することのコスト・メリットも説明しなく

てはならないかもしれない。

仮想的に思考実験するのなら、クラウドへの移行がも

たらす影響を考えてみるのもよい。顧客に対するサービ

スはより充実するか、新しいサービスが生まれる可能性はないか、会社の組織にはどのような影響が出るのかな

ど、ここでもビジネス視点でシステムの価値を見直すこと

が重要である。

技術的には、システムがきれいにモジュール化されて

疎結合の状態になっていると、柔軟なクラウド移行の戦

略をとることが可能になる。その意味で、SOAの考え方

に沿ってシステムの見直しを進めることは、クラウドへの

移行に向けても有益だろう。

筆者は、成熟したクラウド環境は、エンジニアにとって

は「開発の容易さ（EoD：Ease of Development）」を

加速する環境として登場すると考えている。クラウド・サ

ービスの充実が進む現状を鑑みれば、システム開発の

作業は今よりも必ず容易になっていくだろう。エンジニア

がクラウドへの移行をためらう理由は1つもないのだ。

＊＊＊

以上、本特集では、来るべきクラウド時代への備えと

して、クラウドの技術的な特徴や、これが企業にもたらす

利点などについて解説してきた。クラウド時代への移行は、もはや避けられない歴史の

流れである。筆者は、現下の不況期が明けた暁には、

日本企業の多くがクラウド活用のトップランナーとして、

世界のIT業界を主導していることを期待する。また同時

に、日本発の強力なクラウド・プレイヤーが登場すること

を強く願っている。

の聖域として今後も維持されると考えるのは妥当ではな

い。クラウドは、まだ幼年期にあることを忘れてはならな

い。先に、クラウドでは、コストとの兼ね合いで可用性の

レベルを設定できることを述べた。現在進行中のクラウド

技術の革新は、ミッション・クリティカルなエンタープライズ

の心臓部をターゲットにしている。アーキテクチャの面で見ても、現在の企業システムが、クラウドによる大規模

分散システムにいつまでも勝っていられるとは思えない。

現に米国の金融業界では大規模なスケールアウト型の

システムが主流になっているし、スーパーコンピュータのラ

ンキングのトップ500はすべて分散クラスタが占めている。

企業向けのハイパフォーマンス・コンピューティングでも、

今後クラウドは大いに力を発揮していくことだろう。

クラウド時代に備え、アーキテクトがやるべきこと

最後に、クラウド時代の到来に向け、アーキテクトは

何を準備しておくべきかを考えてみたい。

まずは何よりも、クラウドの技術を知る必要がある。そ

れには、代表的なクラウド・プレイヤーが持つ技術の概

要を学ぶことから始めるとよい。グーグルの技術もマイクロ

ソフトの技術も、それぞれに際立った特徴がある。また、

アマゾンのAmazon EC2を実際に動かしてみるのもよ

い。雑誌や書籍、Webなどの情報を読むだけでなく、クラウドがどのようなものかを実際に試し、自分の中で整理

することも重要だ。まだ時間は十分にある。

次に、自社のシステムが、どのようにすればスムーズに

クラウドへ移行できるかを考えてみる。すべてのシステム

を、すぐにクラウドに移すのがよいとは限らない。ここでは、

コストの問題を意識することが決定的に重要だ。これま

で度述々べてきたように、クラウドへの移行を判断すると

は、極めてビジネス上の決定なのである。特にアーキテ ※7 ITシステムを、自前の設備により、自ら運用する形態。


7/14/2019 IT Vol.21 00.pdf


特別企画

もう準

備は万端？

アーキテクトは契約形態や、

見積も

り／進捗管理手法を

再確認

すべし

工

事

進

行

基

準が始まる！ご存じのとおり、今年4月、ソフトウェアの受託開発契約に

「工事進行基準」という会計基準を適用する制度が開始される。

その適用対象企業では、ソフトウェア開発の進捗に応じて売り上げの計上を行わなければならない。

単なる経理上の話題のようにも聞こえるが、これに従うには、

厳密な見積もりと徹底した進捗管理が不可欠であり、

ソフトウェア開発の受注側はもちろん、発注側にとってもひと事ではない。

本誌読者であるアーキテクトの活動の仕方にもさまざまな影響が及ぶことだろう。

本企画では、同基準の適用によってソフトウェア受託開発に起きる変化について再確認するとともに、

これに適応するために有効な契約形態、見積もり手法、進捗管理手法の概要など、アーキテクトも知っておくべき基礎知識を解説する。

細川努 Tsutomu Hosokawa

アーキテクタス


7/14/2019 IT Vol.21 00.pdf


「工事進行基準」制度のスタート

今年4月より、公認会計士監査の対象となる国内企

業（上場企業、および商法上の「大会社」に当たる企

業）のソフトウェア受託開発契約において、「工事進行基準」という会計基準の適用が義務化される。会計基

準と言われても、エンジニア諸氏にはピンと来ないかもし

れない。これは簡単に言えば、ソフトウェア開発を受注し

た企業が、開発工程のどの段階で売り上げ（収益）を

計上するのかを取り決めたものである。

従来、国内のソフトウェア開発受託契約では、会計

基準として工事進行基準もしくは「工事完成基準」の

いずれかを選択できるようになっており、どちらを選択する

かは企業の判断に委ねられていた。

工事進行基準では、ソフトウェアの完成度合いに応

じて売り上げを計上する（図1）。例えば、2年間で10億

円の売り上げとなるソフトウェア開発プロジェクトの場合、

1年目の年度末に作業進捗率が50％ならば、その時点

で10億円の50％である5億円を企業会計に計上するこ

とになる。

一方、工事完成基準では、ソフトウェアが完成し、

発注側からの検収を受けた時点で売り上げが発生した

と見なす（図2）。完成したソフトウェアの提供に伴って収

益を計上するので、シンプルでわかりやすい。そのため、

従来のソフトウェア受託開発においては、こちらの会計

基準が多く用いられてきた。ただし、ソフトウェア開発では長期間にわたって開発

作業が行われることが多く、完了まで数年かかるプロジェ

クトも少なくない。2年計画のソフトウェア開発プロジェクト

ならば、プロジェクトの開始から2年後にようやく売り上げ

やコストなどが計上されることになる。そのため、企業会

計の実態が見えづらいという点が問題視されていた。

こうした背景の下、2007 年12月に企業会計基準委

員会が公開した『工事契約に関する会計基準』（企業

会計基準第15 号）において、該当企業が今年 4月以

降に結ぶソフトウェア開発受託契約では、原則として工

事進行基準を採用しなければならないことが明記された

のである。

ソフトウェア開発の受発注に及ぶ影響

前述したように、工事進行基準自体は企業会計に

関するものだが、これが導入されることにより、ソフトウェア

図1：工事進行基準図2：工事完成基準

収益

進捗

開始年度末完成／引き渡し

成果物の完成／引き渡しの段階で収益を計上する収益

進捗

開始年度末完成／引き渡し

進捗に応じて収益を計上する


7/14/2019 IT Vol.21 00.pdf


工

事

進

行

基

準が始まる！

特別企画

開発の受発注に関して、発注側と受注側にはそれぞれ

次のような影響が及ぶことになる（図3）。

●発注側への影響

まずは発注側に及ぶ影響について、ユーザー企業

が自社で利用するシステムのソフトウェアを外部のSIerに発注するケースを例にとって考えてみよう。

従来は、基本要件や金額、納期などを指定して

SIerにソフトウェア開発を請け負わせることが多く、見積も

り／契約の時点では、詳細な仕様までは決まっていな

いのが常であった。しかし、工事進行基準では、受注

側が作業の進捗に応じて売り上げを計上する都合上、

契約時には契約内容の全容が明確になっている必要

がある。したがって、ユーザー企業がSIerに発注するに

は、契約前にソフトウェアの仕様を詳細に決定しておき、

発注時に提示しなければならない。

●受注側への影響

これまでの受託開発では、大ざっぱな仕様と金額、

納期だけが提示された状態で契約を締結することが珍

しくなかった。しかし、今後はそうした“曖昧な取り引き”は許されなくなる。受注側が行う作業の中でも、特に厳

密さが求められるのは、「見積もり」、「進捗管理」、

「契約の見直し」の3つである。

従来なら、受託契約の締結後にソフトウェア仕様に

修正が入っても、契約を変更せずに応じるのはよくあるこ

とだった。だが、工事進行基準を適用する場合、進捗

やコストに影響が及ぶような仕様変更が発生したら、速

やかに見積もりの見直しや契約の変更を行わなければ

ならない。

図3：ソフトウェア開発の受発注における変化

進捗率

収益

原価

2008/5

10％

500万円

200万円

2008/6

20％

1,000万円

400万円

2008/12

100％

5,000万円

4,000万円

進捗と収益／原価の管理

収益と原価の確定

納品

検収発注要件発注側

見積もり受注側開発作業

契約

仕様や納期の変更があれば、必ず見直す

要件の明確化

【見積もりでの収益／原価】見積総収益：5,000万円見積総原価：4,000万円


7/14/2019 IT Vol.21 00.pdf


会計基準はもともと国ごとに異

なっていたが、経済の国際化が

進んだ結果、世界的に会計基準

を統一しようという動きが広まって

きた。そして2002 年、欧州連合

（EU）と米国が会計基準の統合

に合意して国際基準を作り出し、

日本も自国の会計基準をそれに

合わせる運びとなった。工事進

行基準の適用は、こうした国際

基準に足並みをそろえるうえで必

要な事項の1つである。またかつて、ソフトウェアの受

託開発を巡る「循環取引」が摘

発され、マスコミに大きく報道され

工事進行基準を適用する意義

たことがあった。循環取引とは、

複数の企業間で伝票上だけの

取り引きを行い、売り上げの水増

しを行うというものだ。ソフトウェ

アが無形の商品であることに加

え、曖昧な契約が通用していた

ために、循環取引をしやすい環

境になっていたのである。

しかし、工事進行基準が適用

されたら、契約に際しては収益総

額や費用総額を適正に見積もり、

厳密な進捗管理を行わなければならない。これが、循環取引のよ

うな不正に対する牽制となること

が期待される。

もちろん、工事進行基準の適用義務を負わない企業

もあるが、同基準の適用はプロジェクトの信頼性保証に

もつながるため、実質的にはほとんどの受託開発契約

に適用されることが予想される。

契約の工夫による対応

上述したように、工事進行基準の導入により、これま

で曖昧だった契約内容の明確化が求められるようにな

る。この「契約内容の明確化」に関して、受託開発契

約を結ぶ際に、今後はどのような工夫が必要になるのか

を述べる。その前に、まず今日のソフトウェア開発の主な

形態を復習しておこう。

ソフトウェア開発の代表的な契約形態

表1に示すのは、現代のソフトウェア開発の代表的な

契約形態だ。以下に、これらの契約形態の特徴を説明する。

●請負契約

請負契約とは、受注側が成果物の完成を請け負い、

発注側が成果物に対する報酬を約束する契約形態で

ある。ソフトウェア開発の契約形態としては、最も一般的

なものだ。

ただし、現在多いのは、開発の全工程（要件定義、

設計、開発、テスト、本番環境への移行）を受注側に

請け負わせる「一括請負契約」の形態をとるパターンで

ある。一括請負契約では、開発するソフトウェアの詳細

な要件が見えていない状態で契約金額や納期を決め

ることも少なくない。そのため、何をもって最終成果物とす

るのかが明確でないケースが多く、工事進行基準を適

用しにくいという問題がある。

●準委任契約

準委任契約とは、ソフトウェア開発に関する業務を委

託する契約形態である。この場合、成果物の完成責任

は発注側が負い、受注側は契約で取り決めたとおりの

業務のみを実施する。万が一、出来上がったものに不

足があっても、契約どおりの業務が行われていたら、発

注側は報酬を支払う義務がある。準委任契約では、

表1：受託開発契約の形態

契約の種類説明成果物の完成責任受注側の瑕疵担保責任売り上げを計算する際の基になるもの

請負契約受注側が成果物の完成を請け負う受注側あり成果物

準委任契約

発注側なしシステム開発作業の期間／工数

発注側なしシステム・エンジニアの単価×作業時間システム・エンジニア

リング・サービス契約

システム・エンジニアの能力に対し

て報酬が定められる

発注側が、受注側にシステム開発

作業を委託する


7/14/2019 IT Vol.21 00.pdf


工

事

進

行

基

準が始まる！

特別企画

「予定どおりに委託業務を実施しているかどうか」を確

認することで成果を測れるため、工事進行基準を適用

しやすい。

●システム・エンジニアリング・サービス契約

これは、システム・エンジニアの能力に対して報酬を定める契約形態であり、業務委託の一種に位置づけられ

る。通常は、プロジェクトに参加するエンジニアの能力に

応じて時間単価を決めて契約する。この契約形態でも、

成果物の完成責任は発注側が負い、契約で取り決め

た時間単価に基づく報酬が受注側に支払われる。受

注側では、プロジェクトに参加したエンジニアの「単価×

時間」を管理することで、進捗に応じた売り上げを計算

できる。したがって、これも工事進行基準を適用しやす

い契約形態だと言える。

一括請負契約から分割契約へ

システム構築にあたっては、ソフトウェアの開発だけで

なく、ミドルウェアなどの基盤環境やハードウェア環境、

ネットワーク環境の構築に加えて、それらのテストや本番

環境への移行などの作業も必要になる。従来は、こうし

た作業を一括して発注／受注する一括請負契約が主

流だったが、このやり方では契約内容が大ざっぱになり

やすく、受注側が正確な原価見積や進捗管理を行い

にくい。そこで有効なのが「分割契約」だ（図4）。分割契約では、ソフトウェア開発の全工程を分割し、

各工程に合った契約形態を選択する。例えば、要件

定義や設計のようにあらかじめ詳細に成果物を定義す

るのが難しい作業については、準委任契約やシステム・

エンジニアリング契約を結ぶ。そして、明確になった仕様

に基づく開発作業については請負契約を結ぶといった

具合だ。こうすることにより、工程ごとに最適な方法で見

積もりや進捗管理、評価を行えるため、工事進行基準

を適用しやすくなる。

なお、ここでシステム構築の発注側、すなわちユー

ザー企業が覚悟しなければならないことがある。分割契

約では、発注側がシステムの完成責任を負う。したがっ

て、これまでのように大体の仕様と金額、納期だけを決

めてSIerに“丸投げ”して終わり、というわけにはいかない

図4：一括請負契約と分割契約

●システム構築全体を一括して請け負う契約●契約時には、要件や見積もりが詳細化されていない

請負

要件定義テスト移行

設計

基盤環境構築

ハードウェア環境構築

ネットワーク環境構築

開発

一括請負契約

●システムの主な工程を分割して契約●それぞれの契約ごとに、要件と見積もりを明確にする

準委任準委任準委任準委任

準委任

準委任

準委任

請負

要件定義テスト移行

設計

基盤環境構築

ハードウェア環境構築

ネットワーク環境構築

開発

分割契約


7/14/2019 IT Vol.21 00.pdf


だろう。

さまざまな見積手法

工事進行基準を適用するにあたっては、収益総額や費用総額の見積もりの精度が非常に重要になる。こ

れまでのソフトウェア業界では、見積もりを“勘”と“経験”、

そして“度胸”に頼る傾向が強かったが、曖昧な契約か

ら脱却するにはこうした風習を捨て、理論的な手法も駆

使して見積もり精度を高めなければならない。

見積もりにはさまざまな手法があり、「名称だけなら

知っている」というものも多いだろう。ただし今後は、それ

らを知っているだけではなく、積極的に使いこなしていく

必要がある。

そこで以降では、再確認の意味も込め、代表的な見

積もり手法である「FP（Function Point）法」を中心に

主要な見積もり手法を5つ挙げ、その概要を説明する。

それぞれにメリット／デメリットがあり、得られる見積値の

信頼性は一定ではない。ここで紹介するもの以外のもの

も含め、できるだけ複数の見積手法を実施し、その結果

を比較することが望ましい。

FP法

FP法は、ソフトウェアの機能を定量化してFP（ファンクション・ポイント）という点数で表す手法だ。具体的には、

ソフトウェアの機能を「データ・ファンクション」と「トランザ

クション・ファンクション」に分け、それぞれを定量化したう

えで、マトリクスを使って最終的なFPを算出する。各ファ

ンクションの概要は、次のとおりだ。

●データ・ファンクション：アプリケーションが扱うデータ

の複雑さを定量化したもの。データの物理形式（シーケンシャル・ファイルやデータベースなど）に関係

なく、データの論理構造を定量的に評価する。複雑

さの評価は、論理ファイルのデータ項目数やレコード

の種類の数を「複雑度マトリクス」（図5）に当てはめ

て行う

●トランザクション・ファンクション：アプリケーションと

外部のインタフェースの複雑さを定量化したもの。

「外部入力」、「外部出力」、「外部検索」の3つに

分類して分析を行う。複雑さの評価は、データ項目

数や関連ファイル数を複雑度マトリクスに当てはめて

行う

これらの複雑さを評価した後は、「未調整FP表」とい

うマトリクスを使ってFP値を集計する（次ページの図6）。

例えば、複雑さが「高」と判定された内部論理ファイル

が1つあれば、15FPが加算されるといった具合だ。こう

して算出したFP値を「未調整FP」と呼び、これにシステ

ムの特性に応じた調整係数を乗じたものが最終結果で

ある「調整FP」となる。

調整FPは、ソフトウェアの機能を論理的に定量化したものにすぎず、これだけでは見積もり工数や金額を算

出することはできない。具体的な見積もり工数／金額な

図5：論理ファイルの複雑度マトリクス

データ項目数とレコードの種類の数から、複雑さの低中高を判定する。

レコードの種類の数

1

2∼5

6∼

1∼19

データ項目数

低

低

中

20∼50

低

中

高

51∼

中

高

高


7/14/2019 IT Vol.21 00.pdf


工

事

進

行

基

準が始まる！

特別企画

どを出すには、後述する「LOC（Lines Of Code）」や

「COCOMO（Constructive Cost Model）」などの手

法を併用する必要がある。

LOC

LOCは、現在広く用いられているソフトウェア定量化

手法の1つで、ソフトウェアのコード行数によって見積もり

を行う。既存のソフトウェアに似たものを開発する場合や、

既存ソフトウェアの改修において有用性を発揮するが、

まったく新規に開発を行う場合は、あまり役に立たないこ

ともある。

COCOMOⅡ

ソフトウェアの予想コード行数とエンジニアのスキルから割り出した補正因子によって開発規模や工数、期間

を算出する「COCOMO」に、FPやCMM（Capability

Maturity Model：能力成熟度モデル）を取り入れて拡

張した手法。

類推法

類似したソフトウェア開発プロジェクトの実績をベース

に、規模や工数などの見積もりを行う手法。ある程度の

精度を持った見積もりが可能だが、あくまでも類推である

ことに留意しなければならない。

積算法

作業を詳細に洗い出し、それぞれに必要な作業工

数を加算していくことで全体の作業工数を見積もる手法。WBS（Work Breakdown Structure）法とも呼

ばれ、ソフトウェア開発以外の作業にも適用できる。

有用な進捗管理手法

ソフトウェア開発にかかるコスト／期間などについて信

頼できる見積もり値を出せたとしても、プロジェクト開始

後の進捗状況を正確に把握できていなければ、決算

時に計上する売り上げを算出するのは難しい。したがっ

て、これまで以上に厳密な進捗管理が必要となる。現

状、有用な進捗管理方法には、以下に紹介する「原

価比例法」と「EVM（Earned Value Management：

出来高管理）」の2つがある。

原価比例法

原価比例法は、ある時点までに発生した原価（実際

発生原価）を見積もり時の総原価で割り、進捗率とす

る方法だ。この進捗率を信頼性の高いものにするには、

見積もりの精度が高いことと、実際発生原価を正確に測定することが必須となる。

EVM

EVMは、予算／予定の観点から、プロジェクトの進

捗状況を定量的に評価する手法である。WBSによって

詳細な計画を立ててプロジェクトを開始した後、「投入

実績値（プロジェクトに投入したコストの累積値）」と「出

来高実績値（その時点までに完成した成果物を作業

工数に換算した値）」を収集／分析し、その結果を基

図6：未調整FP表

内部論理ファイル

外部論理ファイル

外部入力

低

複雑さ

×7

×5

×3

中

×10

×7

×4

高

×15

×10

×6

外部出力 ×4 ×5 ×7

外部検索 ×3 ×4 ×6


7/14/2019 IT Vol.21 00.pdf


近年はIT 業界でも、いわゆる

「多重下請け」が頻繁に行われ

ている。多重下請けでは、ユー

ザー企業などの発注側と請負契

約を結んだ企業が元請けとなり、

受注した内容を外部の企業（二

次請企業）に発注し、さらに二次

請企業が三次請企業に委託す

る……、といった具合に委託が

繰り返される。

ここで、工事進行基準の適用

が始まると、元請企業は曖昧な

請負契約を締結するわけにはい

かなくなる。また、元請企業が高

精度な見積もりや厳密な進捗管

理を行うには、下請企業でも同

様に高精度な見積もりと厳密な

進捗管理を行っていなければなら

ソフトウェア業界の変化

ない。大幅な仕様変更などが生

じた場合は、発注側と元請企業

の間の契約はもちろん、元請企

業と二次請企業、二次請企業と

三次請企業の間の契約内容も

見直す必要がある。つまり、元請

企業だけでなく、二次請け、三次

請けの企業も影響を受けるのだ。

これまでのような不明瞭な契約

形態の下、多重下請けを行うの

は実質的に不可能となるだろう。

大手 SIerの中には、見積もり

や進捗管理の複雑化を避けるた

めに再々委託を自主的に控え始

めた企業もある。こうした動きが、

今後のソフトウェア業界の発展

に良い影響を与えることを期待し

たい。

に進捗状況を予測する。実績値の収集／分析には相

応の手間がかかるため、プロジェクトの規模に合わせて、

商用の進捗管理ツールなどを活用するとよい。

奮起すべきは発注側のユーザー企業

ここまで、工事進行基準の適用が受注側と発注側

に及ぼす影響や、同基準への対応で必要となるであ

ろう見積手法、進捗管理手法などを簡単に紹介して

きた。受注側／発注側のいずれにも影響があるとは言

え、工事進行基準自体は、受注側であるベンダーや

SIerの企業会計に適用されるものなので、発注側の

ユーザー企業では“対岸の火事”のようにとらえられや

すい。

しかし、前述したように、工事進行基準の適用に

伴って一括請負契約が減り、分割契約が増加すること

が予想される。つまり、ユーザー企業は、これまでベン

ダーやSIerに“丸投げ”していた一連のシステム開発作

業を分割して委託することになるわけだ。結果として、シ

ステム全体の完成責任はユーザー企業側が負うことに

なる。こうしたことから、今後ユーザー企業の情報システ

ム部門では、システムの全体像を把握し、統括管理で

きるアーキテクト、もしくはそれに準ずる人材の育成が急務となるだろう。

ユーザー企業主体のソフトウェア開発を

分割契約には、デメリットもある。例えば、要件定義

／設計と開発で異なる契約を結んでいた場合、開発

途中で要件の変更が発生しても、柔軟な対応ができな

いのだ。

ベンダーやSIerの融通が利かないことでユーザー企

業の負担が増えるようならば、むしろユーザー企業が主

体となって開発を進めたほうが効率良く、柔軟に作業で

きる可能性がある。そうしたスタイルの開発手法の1つとし

て、アジャイル開発が挙げられる。

アジャイル開発では、ユーザーのいる現場でソフトウェ

アを開発／テストし、迅速にリリースしようというコンセプト

を掲げている。つまり、ユーザー企業が主体となる開発

に非常に適しているのだ。アーキテクトとプロジェクト・マ

ネジャー、アジャイル開発チームが連携して開発を行い、必要に応じて一部を外部に委託するスタイルをとれば、

ユーザー企業のシステム部門を中心とした効率の良い

システム構築が可能になるだろう。

工事進行基準の適用は、これまでベンダー／SIer

とユーザー企業との間で曖昧に結ばれていたソフトウェ

アの開発契約を明確化する良い機会となるのは間違

いない。ユーザー企業では、さらにこれを自社の情報

システム部門のあり方を見直すきっかけにもしていただ

きたい。


7/14/2019 IT Vol.21 00.pdf


業務フローの可視

化／IT化でビジネスとITの〝溝〟を埋める!!


明庭聡 Satoshi Akeniwa

日揮情報ソフトウエア技術本部シニア・コンサルタント

BPMSによるIT化を踏まえた業務フロー図の描き方

第3回

ビジネス・プロセス管理のためのツール「BPMS」

ビジネス・プロセスは、「人による手作業」と「システムによ

る処理」を繰り返しながら、業務目標の達成に向けて進ん

でいく。例えば、営業担当者が顧客からの注文を受け付けて登録すると、販売システムが出荷指示書を出力し、そ

れを見た倉庫担当者が出荷して出荷データを登録した

ら、会計システムで売り上げを計上するといった具合だ。

このように、複数の人とシステムが複雑に絡み合うビジネ

ス・プロセスを効果的／効率的に管理するには、人と人、

人とシステム、システムとシステムのつながりを統一された環

境で管理することが不可欠となる。この“統一された環境”

として今日提供されているのが、ビジネス・プロセスの管理

に必要なツールを統合した「BPMS」である。

BPMSが提供する機能の全体像をまとめると、図1のよ

うになる。図からもわかるように、BPMSでは「プロセス・エン

ジン」がシステム構成の中核となる。このプロセス・エンジン

には、人による手作業を管理する機能が充実した「ヒュー

マン・セントリック（人中心）」と、ERPやCRMといった各種

システムとの接続機能が充実した「インテグレーション・セン

トリック（システム統合中心）」という2つのタイプがある。

前回は、目標とすべきビジネス・プロセスの姿を示したうえで、そこに到達す

るために求められるビジネス・プロセス分析の進め方や、ITを活用した定

量分析の具体例としてシミュレーション・ツールによる検証方法などを解説し

た。今回は、業務フロー図をITシステム化するためのツールとして「BPMS

（Business Process Management Suite）」の概要を紹介し、BPMSによ

るIT化を前提とした業務フロー図の描き方を説明する。

7/14/2019 IT Vol.21 00.pdf



BPMSを導入する際には、それぞれのタイプが向いた領

域に適用しつつ、図1のように各プロセス・エンジンを連携

させて使うのが典型的な形態になる。

連載第1回で「業務フロー図にはシステム処理までは

記述しない」と述べたが、それは業務フロー図はヒューマ

ン・セントリックで動かすものだからだ。つまり、人による手

作業の管理を主な目的とする。それに対して、インテグレー

ション・セントリックで動かすのは、システム上での処理をフ

ローチャートとして整理した「システム処理フロー図」の内

容となる。

なお、図1の構成に関しては、「ルール記述書」としてビ

ジネス・プロセスから「ビジネス・ルール」を分離し、それを

「ルール・エンジン」という独立した環境で実行する形態を

とっていることにも注目していただきたい。

ビジネス・ルールとは、「もし前年の購入総額が10万円

以上ならば、代金を2割引きする」といったIf Then構文

（条件−動作）で表される業務ロジックのことを指す。この

ビジネス・ルールは、一般にビジネス・プロセスと比べると変

更の頻度が高い。そのため、変更のライフサイクルが異な

る両者を分離しておけば、保守が容易になるというメリット

がある。特に、前述のルールに「もし前月の購入総額が1

万円以上ならば、送料を無料にする」といったルールが組

み合わさり、複数のルールから請求金額を求めるような複

雑な場合には、その複雑なルールを独立させて管理する

ことで、保守コストの削減が図れるだろう（変更の頻度が

同程度、かつ単純なルールであれば、ビジネス・プロセス

とビジネス・ルールを一緒に管理することもある）。

またBPMSには、モデル駆動型のシステム開発を実現

できるという特徴もある。具体的には、業務フロー図とシス

テム処理フロー図、そしてルール記述書という各モデルか

図1：BPMSの機能の全体像

レガシー・システム

ERP

業務担当者

作業報告BPMS

作業指示

CRM RDBMS

●ポータル（電子フォーム、ワーク・リスト）

業務管理者

業務パフォーマンス

プロセス・データベース

プロセス・エンジン（ヒューマン・セントリック）

モデリング・ツール


ビジネス・プロセス・モデリング

業務フロー図

プロセス・エンジン（インテグレーション・セントリック）

●BI（Business Intell igence）ツール●BAMダッシュボード※

実行コード生成

生成実行コード

実行コード


ルール・エンジン

システム処理フロー図

生成

ルール記述書（ディシジョン・テーブルなど）

※ BAM（Business Activity Monitoring）ツールのダッシュボード機能。

7/14/2019 IT Vol.21 00.pdf



BPMSによるIT化を踏まえた業務フロー図の描き方第3回

ら、それぞれをエンジン上で実行するためのコードを自動

生成できるのだ。前回に説明したように、ビジネス・プロセ

スの改善活動では、継続的に改善を繰り返していくことが最終的な目標となる。モデル駆動型の仕組みがあれば、

改善策を直ちにシステムに反映できるので、継続的な改

善の実現が容易になるだろう。

BPMSによるビジネス・プロセスの自動化

ここからは、ヒューマン・セントリックなプロセス・エンジン

に焦点を当て、「ビジネス・プロセスの自動化」と「業務パ

フォーマンスの管理」という2 つの視点について詳細に解

説していく。まずはビジネス・プロセスの自動化について述

べる。

「ビジネス・プロセスを自動化する」と聞くと、多くの方は、

「人が手作業でやっていたことをITシステムが代わってやってくれるのか」と思うかもしれない。だが、これはそういう

意味ではなく、業務フロー図に描いた作業順序のとおりに、

ITシステムが各作業を担当者に割り当てていくことを指す。

つまり、システムからの指示に従い、それぞれの担当者が

次に々作業を実施していく様子をイメージするとわかりやす

い。人への作業指示を自動化すれば、人から人へ伝達

する際の遅延や漏れをなくし、業務の迅速化、作業品質

の向上などを図れるのだ。

図2は、BPMSがビジネス・プロセスを自動化する様子

図2：ビジネス・プロセスの自動化

システム処理（ビジネス・ルール）

手作業

手作業

システム処理（システム・インテグ

レーション）

システム

人

人

業務依頼の登録

ポータル

電子フォーム

電子フォーム

ポータル

プロセス・インスタンス

作業指示作業報告


判定依頼

ルール・エンジンプロセス・エンジン

（インテグレーション・セントリック）

ビジネス・ルールの判定結果は？

判定結果処理依頼処理結果

ワーク・リスト

①作業一覧の確認 ②作業指示の確認

③手作業の実施④作業報告の登録

作業

作業

作業

プロセス・エンジン（ヒューマン・セントリック）

7/14/2019 IT Vol.21 00.pdf



を表したものである。

BPMSによって自動化されたビジネス・プロセスでは、ま

ず業務を依頼する人が業務ポータル（業務アプリケーション）にログインし、電子フォームで依頼内容を登録する。す

ると、プロセス・エンジン上ではその業務依頼に対応したプ

ロセス・インスタンスが新たに生成され、業務フロー図で示

された経路を進んでいく。その途中でシステムによる自動処

理が必要になった場合は、ルール・エンジンなどと連携し

てそれを実施する。一方、人手による作業が必要になった

ら、「ワーク・リスト」と呼ばれる作業一覧に作業指示を書

き出す。ワーク・リストには、それぞれの作業担当者ごとに、

行うべき作業名や優先順位、期限などが示されている。

各担当者は、ここから実施する作業を選択し、電子フォー

ムでその内容を把握する。その後、作業が完了して電子

フォームで作業報告が送られると、プロセス・エンジンの処理に戻り、プロセス・インスタンスはさらに先の処理へと進ん

でいく。

BPMSによる業務パフォーマンスの管理

BPMSによってビジネス・プロセスを自動化すると、業務

のパフォーマンスを定量的に把握するための実績データ

を収集することができる。図3は、プロセス・インスタンスの進

行に伴い、さまざまな実績データがプロセス・データベース

図3：業務パフォーマンスの管理

システム処理（ビジネス・ルール）

手作業

手作業

システム

人

人


業務管理者



●業務依頼データ●受信：10時5分

●作業指示データ●指示：10時6分

●作業指示データ●指示：11時45分

●作業報告データ●報告：12時35分

●データ加工／集計

●問題発生の自動通知

●作業報告データ●報告：11時45分

●判定結果データ●受信：10時6分

●判定依頼データ●依頼：10時5分

システム処理（システム・インテグ

レーション）

プロセス・データベース

電子メール

BAMダッシュボード

業務パフォーマンスを把握／分析することで、問題の早期発見（迅速な対応）が可能になる

7/14/2019 IT Vol.21 00.pdf




ための図面」という役割だ。この役割を果たすために、業

務フロー図上の特定のポイントには、どの業務パフォーマ

ンス指標をどのように測定するのかを関連づけて表現しなければならない。ここで言う“特定のポイント”とは、図3に

示したようなイベント（丸の中に絵の記号が描かれた図

形。図3では、業務フロー図の左下にあるメッセージの記

号が描かれた図形が該当）の発生個所と、タスク（作業

を表す長方形）の開始点／終了点を指す。業務パフォー

マンスは、それらのポイントで取得したプロセス・データとタ

イムスタンプを基に分析するが、それを行うためには、業務

フロー図にすべてのマイルストーンを正確に示す必要があ

る。

このように、BPMSを使ううえでは、業務フロー図でハン

ドオフとマイルストーンを適切に表すことが不可欠となる。こ

のハンドオフとマイルストーンの表現について、以下に「人に

よる手作業の描き方」と「システムによる処理の描き方」、

「ビジネス・ルールの切り出し方」の3つに関するポイントを

説明しよう。

人による手作業の描き方

人による手作業については、作業指示と作業報告が

あったタイミングを管理できるように表現すればよい。つまり、図3に示したように、1つの作業に関する作業指示と作業

報告をセットにして、それを1つのタスクとして記述していくの

だ。

ここで注意すべきことは、人への作業割り当てに関する

詳細なロジックは、業務フロー図には記述しないという点

である。例えば「見積承認」という作業を例にとると、この

作業では、「上長1名だけが承認する」、「上長と上長代

理の2名のうち、いずれか1名の承認があればよい」、「最

初に上長に承認依頼するが、決められた期限が過ぎたら、

上長代理にエスカレーションする」といったさまざまなパター

ン（ロジック）が考えられる。

これらの作業割り当てに関するロジックは、わざわざ業

務フロー図内に記述してプロセス・エンジンで自動化しなく

ても、BPMSのポータルの機能によって実現できる。見積

承認者への作業指示がプロセス・エンジンからワーク・リス

トに書き込まれたら、決められた作業割り当てのロジックに

に蓄積されていく様子を示したものだ。

BPMSによって自動化されたビジネス・プロセスでは、

最初に「業務依頼の受信」というイベントが発生すると、プロセス・データベースに業務依頼データが送られる。また、

人による手作業に関しては作業指示データと作業報告

データが、システムによる自動処理では処理依頼データと

処理結果データがそれぞれ蓄積される。これらすべてのプ

ロセス・データ（プロセス・インスタンス全体で共有し、参照

／更新するデータ）がタイムスタンプ付きで蓄積されるため、

リードタイムや納期順守率など、時間の視点に基づく業

務パフォーマンスを定量分析することができる。

プロセス・データベースに蓄積された実績データは直ち

に加工／集計され、BAM（Business Activity Moni

toring）ダッシュボードによってグラフ／表／メーターなどと

してビジュアルに表示される。業務管理者は、このBAM

ダッシュボードを見れば、現在の業務状況をリアルタイム

で把握できるというわけだ。

前回はシミュレーション分析で最適な業務体制を仮説

検証する例を紹介したが、プロセス・エンジンによってビジ

ネス・プロセスを自動化すれば、実績データに基づいて業

務体制を随時見直すといったことも可能になる。また、あら

かじめしきい値を決めておき、問題が発生したら自動通知されるように設定しておけば、業務管理者が問題を早期

に発見し、迅速な対応をとれるようになるだろう。

BPMSによる自動化を踏まえた業務フロー図の描き方

以上に見てきたように、業務フロー図は、BPMSを活

用するうえで2つの重要な役割を担う。

1つは、「ビジネス・プロセスを自動化するための図面」と

しての役割である。業務フロー図に示された内容に基づ

き、プロセス・エンジンが人への作業指示とシステムへの処

理依頼を出しながらビジネス・プロセスを進めていくことにな

る。BPMSがこの役割を果たすためには、業務フロー図

が人やシステムのハンドオフ（作業委譲）を正しく、かつ漏

れなく表現したものとなっていなければならない。

また2つ目は、「業務パフォーマンスを把握／分析する

7/14/2019 IT Vol.21 00.pdf



従い、ポータルの機能によって見積承認者である上長や

上長代理のワーク・リスト上に表示するように設定しておけ

ばよいのだ。このように、業務フロー図に描かなくてもよいハンドオフも

あるということを覚えておいてほしい。ハンドオフに限らず、

業務パフォーマンスの把握に不要なロジックは、業務フ

ロー図をわかりやすくし、業務分析をやりやすくするために、

記述しないほうがよいのである。

システムによる処理の描き方

ある処理をシステムで行う場合は、その処理依頼を出

す個所で1つのタスクを起動する。そうすれば、いったんプ

ロセス・エンジンに処理を依頼した後は、人手による作業

が必要になるまで、システムに処理を任せておくことができ

る。

なお、処理の任せ方には、処理が完了して処理結果

を受け取るまで、次のビジネス・プロセスに進まない「同期

型」と、（処理が完了していなくても）処理依頼を出した時

点で次のビジネス・プロセスに進む「非同期型」の2タイプ

がある（図4）。このうち、非同期型で、なおかつ処理結果を受け取る必要がある場合には、処理を依頼するタスク

のほかに、処理結果を受け取るタスクも記述しなければな

らない。

ビジネス・ルールの切り出し方

業務フロー図にビジネス・ルールを入れ込み過ぎて、複

雑でわかりにくいものになってしまうケースは少なくない。次

ページの図5の上部に示した業務フロー図のように、請求

金額の算出ルールを含めるような描き方をした場合だ。こ

うした表現が望ましくない理由は2つある。

1つは、前述した「業務パフォーマンスの把握に不要な

ロジックは、業務フロー図をわかりやすくし、業務分析をや

りやすくするために、記述しないほうがよい」という理由によ

る。図5の上部をご覧いただけば、「前年購入総額の確

図4：システム処理の2つのタイプ（同期型／非同期型）

システム処理

手作業

システム

人

システム処理（処理結果受信）

処理依頼処理依頼処理結果処理結果

プロセス・エンジン（インテグレーション・セントリック）

同期型

システム処理（処理依頼）

非同期型

7/14/2019 IT Vol.21 00.pdf




業務フロー図を中心にした改善サイクル

以上に述べたように、業務フロー図の役割には、「ビジ

ネス・プロセスを自動化するための図面」と「業務パフォー

マンスを把握／分析するための図面」の2つがある。図6は、

それら2つの役割を業務フロー図が担うことにより、同ドキュ

メントはもちろんのこと、作業手順書やシステム処理フロー

図、ルール記述書といった他のドキュメントでも改善のサイ

クルが実現できることを表したものだ。具体的には、例えば

次のようなサイクルで作業手順を改善できるようになる。

①BAMダッシュボードでプロセス・サイクル時間（ビジネス・

認」や「代金割引の適用」といったレベルで業務の進捗

を管理したり、作業時間の分析を行ったりしないことは明

らかだろう。もう1つは、「保守性を高めるために、ビジネス・プロセス

からはビジネス・ルールを切り出すべし」という考えからだ。

図5のように、単純なビジネス・ルールは業務フロー図に1

つのタスクとして記述し、詳細なビジネス・ルールは別途

ルール記述書に記しておく。このようにすると、ビジネス・

ルールを変更した際の影響が業務フロー図に及ばなくな

る。例えば、現在は人が行っているビジネス・ルールの判

定をルール・エンジンで自動化するよう変更する場合であっ

ても、業務フロー図を変える必要がなくなるのだ。

図5：業務フロー図に入れ込みすぎたビジネス・ルールを切り出す

代金／送料の計算

判定依頼判定結果

ルール・エンジン

前年購入総額の確認

10万円以上

5万円以上10万円未満

5万円未満

1万円以上

1万円未満

前月購入総額の確認

送料割引の適用（無料）

①業務フロー図では1つのタスクで記述する

②詳細なルール・ロジックはルール記述書を作成する

代金／送料の計算


●ワーク・リスト●電子フォーム

人が判定する場合ルール・エンジンで判定する場合ルール記述書（ディシジョン・テーブルなど）

ルール・エンジンへ実装

ドキュメントとして参照

代金割引の適用（1割引）

代金割引の適用（2割引）

ケースNo.

1 2 3 4 5 6

前年購入総額≧10万円 Yes Yes No No No No

No No Yes Yes No No

前月購入総額≧1万円 No Yes No Yes Yes No

代金割引の適用（2割引） ● ●

代金割引の適用（1割引） ● ●

送料割引の適用（無料） ● ● ●

10万円＞前年購入総

額≧5万円条件

動作

7/14/2019 IT Vol.21 00.pdf



プロセスの実行にかかる時間）に関する問題点を発見

する

②BI（Business Intelligence）ツールで過去の履歴を

分析し、原因となっている作業を見つけ出す

③原因となっている作業の作業手順書を見直す（作業レ

ベルの業務改善を実施する）

④BAMダッシュボードでプロセス・サイクル時間が改善さ

れることを確認する

実際には、業務パフォーマンスを定量分析して見つけ

出した問題点に対し、作業手順書やルール記述書の見

直しで解決を図るというケースが多いだろう。ただし、ビジ

ネス・プロセス自体の変更という根本的な改善が要求され

るケースでは、業務フロー図も見直す必要がある。また、こ

うした改善を行う中で、システム処理に修正があれば、シ

ステム処理フロー図も見直す必要がある。

＊＊＊

以上、今回はBPMSの機能を説明したうえで、BPMS

によるビジネス・プロセスの自動化を踏まえた業務フロー図

の作成方法を解説した。

業務フロー図は、業務改善サイクルの中心となる重要

なドキュメントである。ビジネス・プロセス・モデラーは、

BPMSを使うと何が実現できるのかをしっかりと理解したう

えで、業務パフォーマンスを定量的に把握可能になるよう

に、業務フロー図を適切に描いていただきたい。

本連載も、次回でいよいよ最終回となる。次回は、これ

までの説明の復習も交えながら、効果的な業務フロー図

を作成するための秘訣を紹介する。

図6：業務フロー図の位置づけ

ビジネス・プロセス●ハンドオフ・レベル●マイルストーン・レベル

BAMダッシュボード

改善効果の確認

実績データ

改善

業務フロー図

作業手順書

●業務パフォーマンスの分析●問題の発見

業務管理●ビジネス・プロセスの自動化（人による手作業の自動割り当て）●業務パフォーマンスの把握

担当者レベルの作業管理●作業品質を確保するためのマニュアル●作業レベルでの業務改善

ビジネス・プロセスからルールを分離して管理●ルール改訂の容易性を確保

システム管理（設計／運用／保守）


改善

システム処理フロー図


改善

ルール記述書（ディシジョン・テーブルなど）


改善

7/14/2019 IT Vol.21 00.pdf



ITがビジネスの重要なツールと認識されるようになって久しいが、

いまだに満足のいくIT戦略を策定できていないという企業が少なくない。

その一因として、「戦略」の意味や指し示す範囲などが曖昧であることが

挙げられる。これを整理し、理解するうえで有用なのが軍事戦略論の古典だ。

今回は、戦略論の古典からそのエッセンスを学び、

IT戦略のあり方をとらえ直してみたい。

荒井岳 Takashi Arai

コンサルタントの

技

を

盗

め！

戦略論の古典から

、IT〝戦略〟の本

質を学ぶ

第10回

「戦略」とは何か？

今日のビジネスの世界では、「戦略」という言葉

が広く使われている。例えば、「事業戦略」や「販

売戦略」、「マーケティング戦略」など、企業全体の

活動から個々の業務や施策に至るまで、さまざまな

レベルでこの言葉が見られる。その多くは「計画」と

ほぼ同義で用いているようだが、あえて「戦略」とい

う言葉を使う場合は、単なるスケジュールではなく、

重要な目標や難易度の高い施策を指しているよう

だ。言葉の使い方は各企業／個人の自由であり、

それについてとやかく言うつもりはないが、従来とは異

なる着眼点や発想を得るために、ここではまず「戦

略」という言葉が持つ本来の意味を確認しておきた

い。

「戦争」から生まれた「戦略」

「戦略」とは、その文字面が示すとおり、本来は

「戦争における企て」のことを指す。実際、この言葉

を辞書で引くと、「戦争に勝つための総合的／長

期的な計略」とか「長期的／全体的展望に立った

闘争の準備／計画／運用の方法」と説明されて

いる。つまり、この言葉を狭義にとらえれば、「明確

に定義された敵が存在する状況で、その敵に勝つ

ため（または制するため）の総合的／長期的な計

画」ということになる。よって、敵が存在しなければ、

戦略とは言い難い。

それではなぜ、「戦略」という言葉がビジネスの世

界で使われるようになったのだろうか。おそらく、競合

他社との激しい競争にさらされた企業が、その競争

に勝つために、かつて戦争で使われたテクニックを

模倣したことに伴い、「戦略」という概念が広まった

7/14/2019 IT Vol.21 00.pdf



のだと思われる。

この「戦略」という言葉を厳密に使い分けるなら

ば、「IT計画」と「IT戦略」の違いは、前者が「IT

を活用するための計画」であり、後者は「ITを活用

して競争に勝つための計画」となる。つまり、競争に

勝つことが目的でなければ、戦略ではないというわけだ。

クラウゼヴィッツの『戦争論』

カール・フォン・クラウゼヴィッツは、ナポレオンが活

躍した時代を生きたプロイセンの軍人で、現代の戦

略論の根幹となる理論を体系化した人物である。

氏の名の下に刊行された『戦争論』は、孫子の

『兵法』と並び、戦略論の古典として名高い。ただ

し、『戦争論』は未完に終わっており、彼の死後に

夫人が遺稿を編集／出版したものだ。そのため、

理論には数々の矛盾点があるばかりか、極めて難

解であり、多くの誤解を招いてきた。これを補完する

ため、『戦争論』に関する研究は現在に至るまで盛

んに行われており、多数の解説書が刊行されてい

る。

今回は、この難解な理論をビジネスとITの世界

に適用すべく、そのエッセンスを紹介する。ただし、ク

ラウゼヴィッツの主張のすべてや、その背後の意図をあますことなく伝えるのは筆者の手に余るため、そ

れについて深く理解したい方は専門書などを当たら

れたい。

クラウゼヴィッツの『戦争論』におけるポイントは、

次の3点である。

●「絶対戦争」と現実の戦争

●「摩擦」と「天才」

●三位一体以降では、これらのポイントを解説しながら、IT戦

略への具体的な適用方法を考察する。

「絶対戦争」と現実の戦争

クラウゼヴィッツは、「戦争の原型は、敵の戦闘

力を無効たらしめる絶対戦争にあり」とし、絶対戦

争の目的を「敵の戦闘力を撃滅して完全に無力化

することにより、自国の意のままに講和を強制すること

だ」と説く※1。

それ以前、戦争は貴族に雇われた職業兵士（傭

兵）によって行われていたが、革命後のフランスで

徴兵制が始まってからは、戦争は「国力／国民を

総動員して敵の殲滅を目標とするもの」という位置づ

けになった※2。

クラウゼヴィッツが提唱する主な戦略を整理すると、

敵を完全に殲滅し、意のままに講和を強制する

絶対戦争

地の利奇襲数の優性

第1原則「集中」第2原則「迅速」

図1：クラウゼヴィッツの「戦争論」

※ 1 これは、孫子の『兵法』の「戦わずして人の兵を屈するは、善の善

なる者なり（戦わずに勝つことが最良の戦い方である）」という考え方とは

大きく異なるものである。

※ 2 ただし、クラウゼヴィッツ自身は、「絶対戦争」はあくまでも理念的

なものであり、実際の戦争はさまざまな要因から、敵の完全な殲滅には

至らないとも述べている。

7/14/2019 IT Vol.21 00.pdf



前ページの図1のようになる。

まず、理想とする目標は敵を殲滅することであり、

それには2つの大原則がある。

1つ目の原則である「集中」とは、敵の“重心（最

も重要な攻撃対象）”を1個所に絞り、これに対する

攻撃はできるだけ1つの行動に絞ることだ。また、2つ目の「迅速」とは、迅速に行動し、途中で停止／

迂回するのは避けることである。つまり、「勝敗は短

期で決する」という考え方だ。

さらに、勝利を確実にするための要素として、次

の3点を挙げている。

●数の優位：戦争において勝利するための最も基

本的な条件は、兵力数／資源面で優位に立つ

ことである

●地の利：土地勘を生かすことで、敵の弱点を突

いたり、自軍の弱い部分を守ったりできる※3

●奇襲：どのような攻撃をするにせよ、相手の隙を突

くことが肝要である

これらの要素をIT戦略に適用するならば、最も適

しているのは「ERPシステムのビッグバン導入」であ

る。例えば、社内の業務システムの全面的な刷新

により業務コストを大幅に削減したり、商流の各点

で発生している非効率を解消して強固なチャネルを

確立したりといった、相当に大掛かりなIT導入が該

当する。こうした状況で「絶対戦争」から学び、目指すべきは、ITの活用による市場の完全なる制圧

だ※4。

そして、これを達成するために第 1原則に倣うとす

れば、全社の資源をすべてこの活動に集中し、トッ

プ自らが直接関与する全社的な活動として取り組

む必要がある。また、競争優位の確立にあたって

は領域を絞り、競合他社の重心となる部分を狙っていく。さらに、第2原則に従い、それらの活動をでき

るだけ短い期間で一気に実施し、競争相手にとっ

て奇襲となるようにすることが重要だ。そのためには

「数の優位」にもあるように、相当な額の投資が必

要となる。

「絶対戦争」を狙うものが「戦略」であるとするな

らば、「IT戦略」とはこうした大掛かりな目標を達成

するための全社的かつ総合的な長期計画ということ

になる。逆に、小規模なシステムの入れ替えなどは、

「戦略」ではなく「計画」と呼ぶべきだろう。

「摩擦」と「天才」

クラウゼヴィッツが『戦略論』で述べている「摩擦」

と「天才」という概念は、戦略とその実行に関して、

重要な示唆を与えてくれる（図2）。

氏によれば、戦略とは極めて単純なものであり、

敵の側面から弱い部分を討つとか、迂回して包囲

するなど、子どもでも理解できる内容だという。ただし、実際の戦場では、予期せぬさまざまな障害が出現

する。「摩擦」とは、戦略とその実行との間にあるこう

したギャップのことを指す。クラウゼヴィッツは、戦争

では、机上の計画では予測できない無数の小さな

事象のために、すべてが目算を下回り、当初の目

※ 3 戦闘では必ず攻撃側と防御側が交戦するが、防御側が地理的

な要因から優位にある場合、それを責めるには防御側の 3 倍の兵力が

必要だとしている。

※4 ただし、これはあくまでも目指すべき理想という位置づけである。

絶対戦争

現実の戦争

摩擦天才

図2：「摩擦」と「天才」

7/14/2019 IT Vol.21 00.pdf



標のずっと手前までしか到達できないのが普通だと

述べている。兵士とは、強さと弱さを併せ持った1人

の人間であり、軍隊はその兵士によって構成されて

いる。そのため、戦争に付き物のさまざまな危険や

肉体的辛苦が人間たる兵士を苦しめ、数々の障

害を生み出し、それが摩擦となるのだ。摩擦を克服して目的を達成するには、軍隊の長

たる将軍に高い知性と精神力が求められる。クラウ

ゼヴィッツは、この2つを備える者を「天才」と呼んで

いる。戦争では、情報や予測がすべて不確実であ

り、偶然が矢継ぎ早に介入するため、将軍は絶え

ず想定外の事態に対応し、必要に応じて新しい策

を講じなければならない。しかも、情報や資料は乏し

く、次善策を練る時間的余裕すら与えられないまま

に決断を迫られる。いわばパニック状態の中で、

“真実を見極める知性”と、決断したことを実行に移

す“勇気”が天才には求められるのだ。この“真実を

見極める知性”をフランス語では「クー・ディユ（coup

d' oeil）※5」と言うが、これは即座に判断する能力の

ことを指す。また、後者の“勇気”はフランス語で「ク

ウラージュ・デスプリ（courage d' espri）※6」と呼ば

れる。これは、身体的な危機を克服する勇気ではな

く、責任に対する勇気、すなわち“精神的な危機”

を克服する勇気のことを指す。

なお、「摩擦」とは、リスクとは異なる不確実性を意味する。リスクは、それを予見することができ、対

策を講じられるが、不確実性は予見できない障害

である。予見できない障害には対策を講じられない

ので、「天才」の資質で対抗すべしというのがクラウ

ゼヴィッツの主張だ。

今日のビジネス環境は、極めて不確実性が高い

と言われている。つまり、予見できない障害である「摩擦」が非常に多いということだ。そのため、すばら

しいIT戦略を立てても机上の空論となりかねない。

戦略を実行に移すうえで、「摩擦」と「天才」という

概念に学ぶことは多い。IT戦略が「社運をかけた

挑戦」だとすれば、その実施にあたっては、予見で

きないさまざまな摩擦に悩まされるはずだ。そして、そ

れに適宜対処していくためには、不屈の精神と研ぎ

澄まされた知性を持ち、瞬時に決断を下せる判断

力が備わっていなければならない。昨今では、半ば

流行語のように「IT戦略」という言葉が使われてい

るが、「戦略」という言葉を使うのなら、同時に「摩

擦」や「天才」という概念も念頭に置いていただきた

い。

三位一体

クラウゼヴィッツは、戦争を次の3つの要素から成

る社会現象としてとらえた（図3）。

●政治目的：戦争は政治目的を達成するための外交以外の手段であるため、政治目的の変化に

影響を受ける

●軍事：戦争は、将軍や軍隊の才能や能力の影

響を受ける

●国民：戦争の本質は原始的な暴力行為である

※ 5 当時の軍事用語で、的確な攻撃点を瞬時にとらえる眼力のこと。

肉眼ばかりでなく、精神的な眼力を含む。

※ 6 精神的な勇気を意味する。さまざまな種類の勇気が結集すること

により、何事にも屈しない“完璧な勇気”が構成される。

政治目的

軍事国民

図3：クラウゼヴィッツが提唱する戦争の3要素

7/14/2019 IT Vol.21 00.pdf



活用して、論理的で科学的な経営やプロジェクトを

遂行しようとの気運が高まっている。クラウゼヴィッツ

が提唱する「天才」という概念は、非科学的で不

可測な精神論的資質であり、論理的／科学的な

方法論になじんだ読者には馬鹿らしいものと映るかも

しれない。しかし、現在のビジネス環境は不確実性に満ちており、予期せぬ事態に遭遇することが多い

はずだ。IT戦略を担うCIOやアーキテクトらは、「天

才」と呼ばれるほどの資質を持ち合わせてはいないと

しても、少しでもそれに近づくべく「クー・ディユ」のス

キルを磨いていただきたい。

＊＊＊

ビジネスにおいて、「戦略」として掲げた目標はど

の程度達成されているのだろうか。「戦略」が、

クー・ディユ／クウラージュ・デスプリを備えた者だけ

が使うことを許される言葉だとしたら、われわれはあま

りにも軽率にこの言葉を使っていることになる。兵を

見殺しにすることをいとわなければ、将軍は楽な仕

事だ。賢将は兵を無駄死にさせず、かつ最大の戦

果を得るのである。それには、その指導者に鍛え抜

かれた精神力と卓越した知性が不可欠になる。ここ

数カ月、企業による派遣社員の大量解雇がメディア

を賑わしており、ついにその手は正社員にまで及んで

いる。いとも簡単に兵を切り捨てることが、果たして経営者の“勇気（クウラージュ・デスプリ）”なのだろ

うか……。

ため、国民に内在する自然本能的な憎悪や敵

意の影響を受ける

これらの要素は、いずれも戦争の本質に深く根ざ

しており、それぞれが独立しながらも、相互に深く関

連し合う“三位一体”の存在だ。そのため、どれか1

つの要素を無視したり、あるいは3つの要素に勝手な意味づけをしたりすると、たちまち現実との矛盾に

陥る。つまり、戦争を構成する3要素は、一体となっ

て初めて正常に機能するのである。よって、戦争理

論では、これら3要素のバランスをいかにしてとるかが

課題となる。

ビジネスにおいて、戦争を競争と言いかえ、戦争

に勝つことを「競争優位の確立」と言いかえると、

「政治目的」は「戦略／目標」に、「軍事」は「業

務／IT」に、「国民」は「人／組織」に相当する。

この3要素は、第6回（本誌Vol.17に掲載）で紹介

した「経営の三角定理」で紹介したものだ。これに

ついて改めて説明することはしないが、「業務／

IT」の要件を定義する際、他の要素である「戦略

／目標」、「人／組織」を無視すると、たちまちバラ

ンスが崩れ、プロジェクトは失敗する。こうした意味

で、クラウゼヴィッツの戦略論と経営の三角定理は

相通じる部分があると言えるだろう。

クラウゼヴィッツの教え

近年、ロジカル・シンキングや各種方法論などを

人間が目や耳で知覚して脳で処理

してから身体を動かすまでの反応速度

は、生理学的な所見では0 .2 秒が限

界だそうだ。ところが、一流のスポー

ツ選手たちはそれ以上の速さで反応

するという。

例えば、野球で時速 150 km の

ボールが投手の手を離れてから打者

の元に届くまで、およそ0.45 秒しかな

い。実際に球種やコースが判断でき

るのは、ボールが投手の手を離れてか

ら約0.2 秒後であり、ここで打者が球

筋を判断した場合、動作が始まるの

はボールが手元に来てからということ

になる。つまり、実際に目で確かめて

から動作していたのでは間に合うはず

がない。しかし、一流のプレイヤーは、

「手元でボールが止まって見える」とい

うのだから驚きだ。

球技のように対戦相手が存在する

スポーツでは、相手に次の動きを察

知されるような初期動作を見せない

のが常である。ただし、一流のプレイ

ヤーは自分が動くべき瞬間が「見え

る」という。これは、クー・ディユに近

い能力である。逆に言えば、人並み

外れた強靭な筋力の持ち主でも、

クー・ディユがなければ一流のプレイ

ヤーにはなれないということだ。

名将に備わる、「いかなる時でも、

とるべき行動が“見える”能力」、一流

スポーツ選手の「動くべき瞬間が“見

える”能力」、そして優れた経営者の

「ビジネス・チャンスが“見える”能力」

は、いずれも目には見えないものをと

らえる特別な力であり、究極の問題

解決テクニックだと言えよう。ただし

残念ながら、この能力を盗みとる術

は今のところない。

究極の問題解決テクニック ――クー・ディユ

7/14/2019 IT Vol.21 00.pdf



山岸耕二 Koji Yamagishi

豆蔵代表取締役社長

前回の後半部では、デザイン・フェーズで描く課題解決のため

のTo Beモデルについて説明した。続くシフト・フェーズは、いよ

いよ要求開発からシステム開発に移行するための行程だ。ここ

で、上位システムである業務のスコープから、そのサブシステムで

あるITシステムのスコープへと視点が移動する。最終回となる今

回は、まずシフト・フェーズで作成するモデルについて解説する。

さらに、これまでの復習として下流の要求開発のプロセスを振り

返ったうえで、“上流の要求開発”の話題にも触れてみたい。

シフト・フェーズにおける

システム開発への移行準備

回最終

要求開発と機能要件

RFP（Request For Proposal：提案依頼

書）でカバーすべき内容の中で、要求開発を通

じてアウトプットされるのは、機能要件と非機能要件だ。このうち機能要件は、「システム・ユー

スケース」というモデルで表現される。システム・

ユースケースは、下流の要求開発で最後の

フェーズとなるシフト・フェーズにおいて、業務フ

ロー（動的モデル）から切り出される。このシステ

ム・ユースケースの切り出しは、シフト・フェーズの

中でも重要な作業の1つだが、その詳細を説明

する前に、まず機能要件について述べておこう。

要求開発を通して得られた機能要件は、ビ

ジネスのゴールや業務との間のトレーサビリティ

を保った状態で表現される。つまり、各機能要

件がどの業務で求められているのか、あるいはど

のようなビジネス・ニーズから必要とされているの

かといった背景／根拠が、その要件の説明とと

もに記述されているわけだ。こうした背景／根拠

を理解していれば、たとえ業務が変化したとして

も、その変化によってITシステムのどの部分が影

響を受けるのか、そのシステムの機能要件をどう変更すべきかといったことが高い精度で予測で

きるようになるだろう。

なお、機能要件を表現したシステム・ユース

ケースのほかに、前回までに取り上げたプロジェ

クト定義書やゴール記述書、ステークホルダー・

リスト、要求分析ツリー、業務フローなどのモデル

は、プロジェクトの背景や対象システムが目指す

姿を把握するうえで重要な情報源となるはずだ。

システム・ユースケースの

切り出し方

それでは、業務フローからシステム・ユースケー

7/14/2019 IT Vol.21 00.pdf



に、アクティビティの粒度を意図的に粗くするケー

スなど）。この場合でも、システム・ユースケース

の粒度は一定にすべきなので、図1に示すように

システム・レーンとは別にシステム・ユースケース用のレーンを設け、そちらに細かいアクティビティ

を記述する。そして、システム・レーン側のアクティ

ビティの粒度は、他のレーンのアクティビティ（図1

の場合、店舗販売員のレーン内のアクティビ

ティ）と合わせておくと辻褄が合う。このように、1

つのシステム・アクティビティは、1つのシステム・

ユースケースになることもあれば、複数のシステ

ム・ユースケースに分かれることもある。

●システム処理を伴うアクティビティの切り分け

ITシステムによる処理を伴うアクティビティにつ

スを切り出す方法について解説する。

システム・ユースケースは、To Beモデルの業

務フローの中で、システム・レーン※1内のアクティ

ビティ（以下、システム・アクティビティ）として抽出される。つまり、システム・ユースケースを適切に

切り出すには、システム・アクティビティをどう表現

するかがポイントになる。

●システム・アクティビティの粒度

まずは、システム・アクティビティの粒度につい

て説明しよう。本連載の第5回で、アクティビティ

の粒度を決めるうえでの指針を紹介したが、そ

れに従ってシステム・アクティビティを記述すれば、

システム・ユースケースとしても適切な粒度になる

はずだ。

しかし、さまざまな理由によって、アクティビティ

の粒度を変える場合がある（例えば、普通にや

れば長くなる業務フローの見通しを良くするため

※1 レーンとは、業務フローを縦に仕切った枠のこと。この枠に

より、各アクティビティの作業担当を表現する。作業担当には「顧

客」や「システム」などがあるが、本稿では、システムが作業担当の

レーンを「システム・レーン」と呼ぶ。

大口顧客店舗販売員システムシステム・ユースケース

商品の引き合いをする

候補を絞る

納期確認を行う

店舗商品の条件検索

検索結果を照会する

一括出力する

紹介候補として登録する

購入を決定する

条件に合う商品を勧める

条件に合う商品を検索する（店舗検索）

登録候補内の納期照会

を行う

商品の仮引き当てを行う

当該商品の納期を回答する

システムを用いて参照（検索）するだけなので、システム・レーン内に記述する。対応するアクティビティとの依存関係は、点線矢印で表しておく

システム・アクティビティは、店舗販売員レーン内のアクティビティと粒度を合わせる

システム・ユースケース用のレーンを設ける

図1：システム・ユースケース用のレーンを設ける

7/14/2019 IT Vol.21 00.pdf



シフト・フェーズに

おけるシステム開発への移行準備

最

回

終

いては、その内容によって業務のメイン・フロー※2

の中に入れるかどうかを判断する必要がある。

例えば、あるアクティビティの内容が、作業者

がITシステムを使って参照／登録するだけというものなら、図1のように作業者のアクティビティから

点線矢印（依存を表す）でシステム処理を伴う

アクティビティを参照するようにして、業務のメイン・

フローには入れないようにする。逆に、システム・

アクティビティであっても、システムの処理によって

業務フロー全体の流れが変わるような重要なア

クティビティの場合は、実線の矢印で連結して、

業務のメイン・フローに含めるようにするとよい。

いずれにせよ、業務フローの中にシステム・

レーンを設け、他のレーンとの連携を明確に記

述しておくと、対応する業務とひも付いた状態で

システム・ユースケースを切り出すことができる。ま

た後々、業務とのトレーサビリティを確保しつつ、

システム・ユースケースを管理していくことも可能

になる。

システム・ユースケースのまとめ方

RFPに対して、システム・ユースケースをどの

程度ドキュメントにまとめるべきかは、発注側が求める提案のレベルに応じて異なる。例えば、

「ざっくりした予算感を得たい」というレベルの場

合、各システム・ユースケースと、それぞれの概

要を一覧表に整理する程度で、必要な情報を

提供できるだろう。一方、「提案の内容で見積

もりをとり、その結果次第で契約締結まで進めた

い」というレベルなら、より詳しくシステム・ユース

ケースを記述しておく必要がある（ただしこれは、

システム開発への移行直後に行う要件定義と、

重複した作業になる可能性がある）。この場合

のまとめ方については、筆者が翻訳に携わった

『ユースケース実践ガイド』（著者：Alistair

Cockburn、ほか／発行：翔泳社）などを参考

にされるとよいだろう。

非機能要件の抽出

以上が機能要件を表現したシステム・ユース

ケースの切り出し方だが、非機能要件の切り出

し方についても述べておこう。シフト・フェーズで

は、いくつかの非機能要件を抽出し、それらを

「非機能要件一覧」にまとめることも重要な作業

の1つなのだ。

発注側は、RFPの中で非機能要件を提示

する必要がある。ただし実際には、その定義が

不十分なためにトラブルが生じることも少なくない。

しかし、その割りには、非機能要件の定義につ

いて広く合意されたものがあるわけではなく、体

系的な整備も遅れている。ごく最近になり、それ

に関する取り組みが始まりつつあるような状況だ。

以下に、具体的にどのような内容を一覧にまとめ

るべきかを説明する。

RFPの中に含めるべき非機能要件としては、端末へのレスポンス・タイム、トランザクション分

離レベル、単位時間当たりの処理数といった

性能に関する指標や、セキュリティ、可用性など

が挙げられる。このうち、特にセキュリティには、

個人情報保護やコンプライアンス強化、IT統制

といった観点から、近年ますますウェイトが置かれ

るようになってきている。

非機能要件は業務の視点から定める

なお、非機能要件の記述の仕方だが、よく

「ITシステム全体を、その要件に合わせて設定

する」といった簡素な表現を用いているケースを

見かける。例えば、性能面ならば、「レスポンス・

※2 業務の流れを作っているアクティビティを実線矢印で連結し

た一連のフロー。図1の場合、大口顧客のレーンと店舗販売員の

レーンに書かれたフローが該当する。

7/14/2019 IT Vol.21 00.pdf



タイムは通常3秒以内、最大8秒以内」といった

具合だ。しかし、非機能要件は本来、業務の

視点で決定すべきものである。なぜなら、「他の

機能はレスポンス・タイムが20秒でもかまわないが、納期確認の機能だけは必ず5秒以内に応答し

ないと、営業担当者が顧客との電話中に納期

を答えられない」といったように、業務上の特殊

事情によって要件が変わるからだ。

業務の視点から非機能要件を定めるには、

上の例の後半部のように、「その非機能要件

が守れないときには、業務の現場で何が起こる

のか」とさかのぼっていくとよい。このアプローチ

は、性能面だけでなく、セキュリティについても有

効である。ある場面でだれが対象の機能にアク

セスできるべきかは、職務分掌や業務内容から

おのずと決まっていくはずだ。

これは可用性についても同様である。あらゆ

る場合に備えて多重化などを行うと、初期投資

と運用コストが過剰なものになってしまう。アーキ

テクトたる読者の立場からすると、不測のシステ

ム停止はあってはならないことだろうが、「ここで

仮にシステムがハングアップしても、現場でリブー

トして復帰すれば、さほど問題にはならない」というケースも考えられる。本当に必要なところを手厚

くし、それ以外は薄くするというメリハリを付けるこ

とが重要である。

●業務フローを使って個々の事情を確認する

業務にさかのぼっていく際には、業務フロー

を使うとよい。前述したように、業務フローは、業

務とITシステムとの間でトレーサビリティを持つ。

そのため、業務フローに沿って実際の作業をな

ぞっていけば、場面ごとの特殊事情がわかるは

ずだ。

この方法で確認すると、システム全体に共通

する非機能要件に加えて、特定の利用シーン

／機能に関する非機能要件も把握できる。そし

て、各非機能要件を満たせなかったときのリスク

を業務的な表現でまとめておけば、それぞれの

要件の実現にかかるコストが妥当なものかどうか

を関係者間で議論するといったことも可能になるだろう。

このように、要求開発のプロセスを通すと、機

能要件だけでなく非機能要件に対しても、業務

の視点から明確な裏付けを持たせることができ

るのだ。

分析クラス図の作成

シフト・フェーズでは、システム・ユースケース

の切り出しと、非機能要件一覧の記述のほか

に、「分析クラス図」の作成もオプションとして行

うことがある。分析クラス図は、業務というシステ

ムを表現した概念モデル（静的モデル）からIT

システムのスコープで抽出した要素を、より詳しく

記述したものだ。なお、RFPのレベルであれば、

概念モデルのままでも必要な情報は提供できる

ので、システム開発に入った後の要件定義で

作成してもかまわない。後々、この分析クラス図

がクラスの仕様になったり、ER図に転換されたりした後、データベース・テーブルとして実装され

ることになる。このモデルは、ITシステムの規模

や管理すべきデータを理解するうえで有用な情

報になるだろう。

下流の要求開発における

モデル間の関係

ここで、下流の要求開発における4 つの

フェーズの中で、それぞれのモデルがどう関係し

ていくのかを簡単におさらいしておこう。

最初の準備フェーズは、次ページの図2に

示す流れで進める。まず、プロジェクトの外枠を

7/14/2019 IT Vol.21 00.pdf





最

回

終

プロジェクト定義書

ステークホルダー・リスト

要求分析ツリー

ゴール記述書

ゴール記述書

重視すべき立場からのインプット（課題、要求、解決案）

当初定めたプロジェクトの目的との整合

スコープからステークホルダーを特定

既出のインプット情報（課題、要求、解決案）

適切なレベルの目標を設定

ステークホルダー・リスト

ビジネス・ルール・リスト

要求分析ツリー

ゴール記述書

ゴール記述書

要求に関連したサービスの抽出

ゴールに関連したサービスの抽出

業務遂行上のルールを整理

アクタと提供すべきサービスの抽出

ビジネス・ユースケース業務に現れる概念を整理

サービスを実現する手順を表す

サービスに関係する概念を整理

業務フロー

概念モデル

立案フェーズでは、基本的にAs Isモデルを作成

図2：準備フェーズの作業の流れ

図3：立案フェーズの作業の流れ

7/14/2019 IT Vol.21 00.pdf



固めるためにプロジェクトの概要を記述したプロ

ジェクト定義書を作り、そのプロジェクトに関係す

る人を々特定してステークホルダー・リストにまと

める。さらに、課題と要求、解決案の関係を要求分析ツリーでとらえ、プロジェクトの目的や成

功指標をゴール記述書に整理する。

次の立案フェーズの進め方は、図3に示すと

おりだ。ゴールの達成に関連する業務上のサー

ビスを特定し、それをビジネス・ユースケースとし

て抽出したうえで、そのサービスを実現している

現状の仕組みを業務フローと概念モデル、ビジ

ネス・ルール・リスト（ビジネス・ルール）で表現する。

こうした作業により、現行（As Is）の業務をシス

テムとしてとらえ、見える化できるようになる。ここで

重要なのは、これらのモデルの中から、プロジェク

トの課題と関係する個所を見つけることだ。

続くデザイン・フェーズとシフト・フェーズの作

業の流れは、図4のようになる。

まず、デザイン・フェーズでは、特定された課

題が解決されるように、立案フェーズで描いた4つのモデル（ビジネス・ユースケース、業務フロー、

概念モデル、ビジネス・ルール・リスト）を変更して、

To Beの業務構造を設計する。

一方、シフト・フェーズでは、デザイン・フェー

ズで変更した業務フローから、システム・レーン

のアクティビティをシステム・ユースケースとして切

り出す。また、非機能要件を抽出して非機能

要件一覧に記載するほか、概念モデルからIT

システムのスコープで絞り出した要素を、分析ク

ラス図を用いて詳細化する。これらの成果物を

RFPなどにまとめ、システム開発に引き渡す情報

とするのだ。

ビジネス・ルール・リスト

As IsモデルからToBeモデルに変換

業務フロー

デザイン・フェーズシフト・フェーズ

概念モデル

人間系とシステム・レーンのインプット／アウトプットを取り出す

ITシステムのスコープで切り出し

システム・ユースケース

非機能要件リスト

1.レスポンス

a）

b）

2.セキュリティ要件

分析クラス図

図4：デザイン・フェーズ／シフト・フェーズの作業の流れ

7/14/2019 IT Vol.21 00.pdf





最

回

終

SOAと要求開発

以上が下流の要求開発プロセスだが、筆者

が所属するコンサルティング会社では、このプロ

セスをSOA（Service Oriented Architecture）に適応させ、企業システムの開発方法論

としてドキュメント化している。

SOAに基づいてシステムを設計する際に最も

難しいのは、ITシステムからサービスを一定の

粒度にそろえて切り出すことだとよく言われる。一

方、ここまで紹介してきた要求開発は本来、IT

システムが提供すべきサービスを業務の視点か

らトップダウンで導くという手法であり、サービス

の適切な粒度を見極めるのに役立つ。

SOAに関しては、「どうせベンダーが新たに

ひねり出したバズワードだろう」といった声のほか

に、「従来のEAI、あるいはRPCやCORBAとど

こが違うんだ」といった疑問を聞くことがある。確

かに、要素技術の面では、従来から存在する

技術に“化粧直し”を施しただけのように見えるか

もしれない。

しかし筆者は、SOAには従来の技術から大き

く進化したところが1つあると思っている。それは、

SOAが、業務の視点による再利用や共有モジュールを意識して作られた初めての技術だと

いう点である。これまでの技術では、再利用や

共有モジュールの単位は、凝集性や結合性な

どエンジニアリングの視点に基づく、いわば設計

／実装する側の都合によるものだった。この進

歩により、「経営とITの融合」という普遍的なお

題目も、“絵に描いた餅”ではなくなるだろう。

要求開発では、SOAのコンセプトが広まる以

前から、業務の視点でサービスを切り出し、業

務とITを連動させることの重要性を訴えてきた。

要求開発は、ベンダーが提供するSOAの実装

技術をコンセプトどおりに使いこなすための具体

的手法としても、大いに活用できるだろう。

上流の要求開発と

IT戦略の重要性

ところで、連載第1回の冒頭において、「要求開発は、上流の要求開発と下流の要求開

発に大きく分けられる」と書いたのをご記憶だろ

うか。本連載では、後者の下流の要求開発に

焦点を当て、特徴的な部分を示しながらそのプ

ロセスを解説してきたが、最後に上流の要求開

発についても簡単に触れておきたい。

ベンダーの側にいると、どうしても“作る話”ば

かりに気をとられがちだが、企業の情報システム

部門では今日、IT 投資全体の7、8割が保守

／運用コストだと言われるほど、現状のITシステ

ムを維持するのに多くの予算／リソースを割いて

いる。つまり、新規システムの開発などの投資案

件には、非常に限られた予算／リソースしかか

けられない企業が少なくないのだ。こうした状況

下で、投資判断を適正に行うためには、個々の

プロジェクトだけではなく、自社のIT全体の方

向性を指し示すIT戦略が必要になる。

実際のところ、戦略と呼べるレベルの計画が

立案できている企業は多くはない。筆者は、自社のITの全貌をつかまないまま、個別の課題へ

の対処に追われている状況をよく見聞きする。ま

た、IT投資の予算についても、どこにいくらかけ

るという吟味をせず、業界内の平均的な投資

率を基に横並び的に計算し、後から使い方を

考えている企業が少なくないようだ。

しかし、戦略と呼ぶからには、横並びではなく、

企業ごとの意志や特徴が表れるべきである。例

えば、物流企業の事業戦略なら、「価格は高

いが、配送のスピードは圧倒的に速くして、特

定の顧客層をねらう」、「そこそこの配送スピード

だが、価格は安く設定し、広い顧客層をター

ゲットにする」といった具合に、各社が置かれて

7/14/2019 IT Vol.21 00.pdf



いる環境と保持する資源、ビジョンなどによって

方針が変わるだろう。

IT戦略とは、そうした事業戦略を支えるため

に、システム環境をどのように提供していくべきかを定めるものだ。したがって、IT戦略を策定す

る際には、「事業で強化すべきポイントにはIT投

資を集中させ、他の部分はトレードオフとして、

多少の不自由は我慢する」という“選択と集中”

が不可欠になる。全体を把握できる“地図”を

持っておらず、何と何がトレードオフの関係にあ

るのかの“力学”も明確でないという状況では、

確固とした根拠に基づく投資判断はできない。

IT戦略策定の進め方

IT戦略という言葉は今日、さまざまな場面で

使われているが、その定義は今ひとつ曖昧であ

る。そもそも、IT戦略としてカバーすべき範囲や、

IT戦略を検討する際のプロセスについて、業界

内に十分なコンセンサスがあるわけではない。し

かし、対象が個別のプロジェクトではなく、組織

のIT全体という違いこそあるが、やるべきことは

下流の要求開発と同じである。

IT戦略の策定にあたっては、まず自社のIT

の現状を系統立てた考え方で整理し、眺め渡

せるようにすることが重要だ。そのためには、適切な段取りやモデルなどが必要になる。次に、それ

らを通じて見える化した自社のITの姿が、現在

の事業構造や、今後の事業戦略に則したものと

なっているかどうかを調査する。そのうえで、自社

の投資能力を踏まえ、優先順位を付けて投資

内容を決定し、リソースや期間の制約に配慮し

ながら計画を策定することになる。こうして決定し

た計画の下に、現状からあるべき姿に遷移する

ための活動として複数のプロジェクトが開始され、

下流の要求開発へとつながっていくのだ。

このように、まずはIT戦略の策定が行われ、

その後の工程として下流の要求開発が開始さ

れる。したがって、上流の要求開発とは、すなわ

ち「IT戦略を策定するための活動」だということ

になる。

筆者も、時折エンタープライズ・アーキテクチャ

（EA：Enterprise Architecture）やIT戦略と

従来のシステム開発では、システ

ムが果たすべき機能がほぼ見えてき

た開発プロジェクトに対して、いきな

り要件定義を始めていた。それに対

して、下流の要求開発は、そこから

いったん2、3歩下がり、上位の目

的や業務との整合性を確認してか

ら始めようというアプローチをとる。したがって、下流の要求開発を適

用するには、すでに開発プロジェク

トが開始されていることが前提にな

る。

開発プロジェクトが起こるのは、

自社のIT全体（既存のIT資産から、

その運用状態まで）と、自社の事業

内容や今後の事業の方向性を照ら

し合わせた際に、現状のITに何らか

の満たされていないものがあるとわ

かり、あるべき状態のITに持ってい

く必要性が生じたときだ。ただし、開発プロジェクトが起こる原因はこのよ

うに1つしかないが、その目的はさま

ざまである。

最も一般的なのは、システムの

新規開発や追加／改変を想定した

プロジェクトだろう。下流の要求開

発がターゲットとするのは、主にこう

したプロジェクトだ。そのほかに、

ハードウェアの耐用年数やOSの保

守期限が切れた場合など、経時的

な変化に対処するためのものもある。

また、日本版SOX法や個人情報保護など、コンプライアンスに関する

要件に対応するために、システム機

能やセキュリティを強化することを目

的としたプロジェクトも存在する。

プロジェクトが起こる原因と、プロジェクトの目的

7/14/2019 IT Vol.21 00.pdf





最

回

終

いったキーワードも絡めながら、要求開発支援

の相談を受けることがある。本連載で取り上げて

きた下流の要求開発（具体的なシステム開発

を前提とした要求開発）に比べると件数が少ないので、筆者自身もまだ十分に上流の要求開

発をこなし切れているわけではない。ただ、IT先

進国と比べて遅れているとされる国内企業のIT

化を推進していくためには、この辺りの方法論も

早期に整備する必要があると考えている。

アーキテクトと要求開発

さて、『上流工程を極める！』というテーマで本

誌創刊以来、3年あまりの間、寄稿してきたが、

この間に「アーキテクト」という職種は、ITエンジ

ニアが最終的に目指すキャリア・パスとして確実

に市民権を得たように思う。

筆者がイメージするアーキテクト像とは、「さま

ざまな制約条件がある中で、最適なアーキテク

チャを設計できる人材」である。今日関心が持

たれるべきアーキテクチャは、Java EEのフレー

ムワークといったアプリケーション単体のレベルに

とどまるものではない。分散システムを統合するSOAのような連携アーキテクチャ、人間系も含

めたビジネス・アーキテクチャなど、より上位のシ

ステムにおける複雑な制約を含んだものへとシフト

している。こうした中でアーキテクトとして活躍して

いくためには、ITレベルの最適化を考えるだけ

でなく、上位のシステムのレベルに視点を移して、

そこでの最適化の問題にも取り組まなければなら

ない。視野を広げると、広範囲の制約を考慮し

て最適化でき、焦点を絞れば、実装の詳細にまで立ち入れる――この“ズーム倍率”こそが、

アーキテクトの能力の肝だ。

近年、ITシステムにかかわる者が視野に入れ

なければならない技術エリアは、拡大の一途を

たどっている。開発経験の少ない方がそのエリア

を見渡すと、自分がこれから切り開かなければな

らない“未開地”の広さに圧倒されてしまうかもし

れない。さらに、「業務や事業のレベルまで視野

に入れるべし」というのでは、カバーすべき領域

があまりにも広すぎると思うだろう。

しかし、「そもそも何のためのITなのか」という

原点に立ち帰れば、おのずと起点は明らかにな

る。今回少し触れた上流の要求開発から、下

流の要求開発、システム開発、運用までをイ

メージすることで、企業ITの全体構造が把握で

きるはずだ。その全体構造のどこからどこまでが

意識すべき範囲なのかを知り、その中で自らが

軸足を置くべきところを理解すれば、技術の進

展がいかに早くても、惑わされることなくスキルの幅を広げていけるだろう。

本連載で紹介してきた要求開発の手法が、

アーキテクトを目指す方々、あるいはアーキテクト

としてさらなる能力向上に努める方々に、わずか

でもお役に立てば幸いである。

要求開発に関する参考文献

●『要求開発∼価値ある要求を導き出すプロセスとモデリング』（著者：要求開発アライアンス、ほか／発

行：日経BP社／発行年：2006年）

●『戦略的要求開発のススメ』（著者：安井昌男／発行：翔泳社／発行年：2006年）

●『成功する要求仕様失敗する要求仕様』（著者：Alan M. Davis／発行：日経BP社／発行年：2006年）

●『ストリームラインオブジェクトモデリング』（著者：Jill Nicola、ほか／発行：ピアソンエデュケーション／

発行年：2002年）

●『UMLモデリングレッスン』（著者：平澤章／発行：日経BP社／発行年：2008年）

●『ユースケース実践ガイド』（著者：Alistair Cockburn、ほか／発行：翔泳社：発行年：2001年）

7/14/2019 IT Vol.21 00.pdf



SE＆Aのおさらい

現在、アーキテクトとして働くAさんは、大学の同窓会

でBさんと再会した。聞けば、Bさんも自分と同じく、アー

キテクトとして活動しているという。そこでAさんは、今、頭

を悩ませているシステム統合プロジェクトについて相談したところ、Bさんが教えてくれたのが「SE＆A（システムズ・

エンジニアリング＆アーキテクチャ）」という手法であった。

Bさんの説明をひととおり聞いたAさんは、SE＆Aを実践

してみようと思い始めた。

Aさん：「いやぁ、SE＆Aのことを教えてもらってよかったよ、

ありがとう」

Bさん：「一気にいろいろと説明したから、理解するのが

ちょっと大変だったかな。もう一度、おさらいしておこう

か」

SE＆Aの背景

日々大きく変動するビジネス環境に適応し、企業が勝

ち残っていくには、その基幹業務を支えるITシステムの

柔軟性が鍵となる。また、構築するITシステムは大規模

かつ複雑になっているのにもかかわらず、それにかけるコ

ストや期間は削減／短縮される傾向にあり、従来のプロ

ジェクト管理手法では対応しきれなくなっているのが実

情だ。こうした背景の下に誕生したSE＆Aは、システムの全

ライフサイクルにわたり、システムの複雑さに起因する曖

昧さ／不確かさを克服することを目的としている。その

ベースになっているのは、航空宇宙や軍事といった分野

で、高度な技術に基づく複雑な製品（宇宙船や軍艦、

航空機など）の開発に挑み、大規模で達成困難なプロ

ジェクトを成功させるために生み出された「システムズ・

エンジニアリング」の手法だ。それをITシステム構築プロ

ジェクトに適用できるようアレンジしたものがSE＆Aという

わけである。

SE＆Aのアプローチ

SE＆Aでは、ITシステムの設計に着手する前に、そ

のシステムがどのようなビジネス目標やゴールを掲げてお

り、何を実現するために必要とされているのかといった要

求／制約を理解することからスタートする。具体的には、

プロジェクトのライフサイクルに沿って、6つのベースライン

を確立していく。その中で基本となるのは、次の2つの要

求ベースラインだ。●ビジネス要求ベースライン：実現するビジネス要求や

その優先順位などを決定したもの。作成にあたっては、

まずビジネス・ユースケースを定義し、それを具体的な

ビジネス・プロセスにする。そのビジネス・プロセスを構

成するビジネス・タスクをビジネス用語で記述したもの

がビジネス要求となり、それに優先順位を付けてそれ

「システムズ・エンジニアリン複雑化／大規模化するシステム開発を成功に導くための開発方法論

SE＆Aの実践に向けて

最終回

最終回となる今回は、復習の意味も込め、

これまでに解説した内容をざっと振り返る。

併せて、実際のプロジェクトにSE＆Aを

適用した事例を紹介し、総括としたい。

Judy Barkal日本IBM エンタープライズ・アーキテクチャ＆テクノロジーチーフ・システムズ・エンジニア

大嶽隆児 Ryuhji Ohtake

日本IBM エンタープライズ・アーキテクチャ＆テクノロジーエグゼクティブITアーキテクト

訳者長島礼 Rei Nagashima

日本IBM エンタープライズ・アーキテクチャ＆テクノロジー ITアーキテクト

7/14/2019 IT Vol.21 00.pdf



ぞれに受入基準を定め、ステークホルダー（利害関

係者）と合意したものがビジネス要求ベースラインとな

る

●システム要求ベースライン：ITシステムが実現すべき

内容やその優先順位を決定したもの。作成にあたっ

ては、まずビジネス・プロセスを分析し、ITシステムによって自動化すべきタスクを見極めて、その目的を明

確に定義する。そして、目的を達成できるようなシステ

ム・ユースケースを定義した後、ITシステムが実現す

べき事柄を明らかにしたものがシステム要求となり、そ

れに優先順位を付けて受入基準を定め、ステークホ

ルダーと合意したものがシステム要求ベースラインとな

る

この2つの要求ベースラインを確立することで、SE（シ

ステムズ・エンジニア）やビジネス・アナリストは目的達成

に必要な要求を絞り、無駄なプロセスやシステムの設計

／構築を回避できるのである。なお、要求ベースライン

で扱う対象には、機能要件だけでなく、非機能要件も

含まれる。

これらの要求ベースラインを踏まえ、次に以下の2つの

設計ベースラインを確立する。

●基本設計ベースライン：「システムは何をすべきか」に

着目したビジネス要求／システム要求の定義を基に、

「システムをどのように実現すべきか」を定めたもの。IT

システムの各構成要素（コンポーネント）にシステム要求を割り当てて定義したコンポーネント要求に、コン

ポーネント・アーキテクチャ設計仕様を加えたものが

基本設計ベースラインとなる

●詳細設計ベースライン：本番稼働後の保守までを含

むITシステム・ライフサイクルにおいて、設計の一貫

性／追跡可能性を維持するための基礎となるもの。

コンポーネント設計に対し、データ設計やコンポーネン

トのテスト計画などを加えて作成する

これらの設計ベースラインの確立にあたって、SEと

アーキテクトは、ビジネス要求／システム要求の追跡可

能性を確保するとともに、その設計内容が適切なもので

あるかどうかを検証する。また、技術的なリスクや問題点がないかどうかを常に監視し、最終目標の達成に影響

を及ぼすような設計面の問題が生じないようにしなけれ

ばならない。

設計ベースラインを確立した後は、以下のテストに関

するベースラインと最終確認を行うためのベースラインを

確立する。

●テスト準備ベースライン：設計したすべての機能の

開発と単体テストが完了しており、統合テストの開始

が可能な状態になっているかどうかを判断するための

基準となるもの。確立にあたっては、テスト・アーキテク

チャを確認するほか、テスト計画などの準備状況を評

価する

●本番準備ベースライン：システム構築の最終段階を

確認することによって確立されるもの。具体的な評価

事項としては、最終的な要件とそのカバレッジが明確

化され、追跡可能性マトリクスが完成していることや、

リスクが除去（あるいは軽減）されていることなどが挙げ

られる

これら2つのベースラインを、SEは開発者やテスト担当者などとも協力して確立する。

SE＆Aは、プロジェクトを必ず成功に導く“銀の弾”や

“抜け道”ではない。良いITシステムを構築する唯一無

二の道は、「ビジネス上のゴールの達成、またはビジネ

ス・リスクの回避に必要なビジネス要件／システム要件

に関連するプロシージャ、ルール、エンティティをトップ・ダ

グ＆アーキテクチャ」の手引き

7/14/2019 IT Vol.21 00.pdf



「システムズ・エンジニアリング＆アーキテクチャ」の手引き

体の品質／性能確保に至るまで、多岐にわたって活躍

し始めている。

SE＆Aの実践

再び2人の話に耳を傾けてみよう。SE&Aの導入を検討し始めたAさんは、事例にも興味を持ったようだ。

Aさん：「実際にSE＆Aを実践しているプロジェクトの話

を教えてもらえないかな」

Bさん：「じゃあ、米国IBMの事例なんかどうかな。IBM

の場合、自社のビジネス・チャネル拡大を目的にしたチャ

ネル支援システム構築プロジェクトに、SE＆Aを適用した

んだ。ただし、初めからSE＆Aを使っていたわけではな

かった。最初は通常の手法で進めていたんだけど、

個々のステークホルダーが主張する要件を管理しきれな

くなり、進捗が遅れ始めた。そこで途中から計画を変更

し、要件を約半分に絞り込んだバージョンを『第1ステー

ジ』として開発することにしたんだけど、それでも予定は遅

れたんだ」

Aさん：「それで、SE＆Aの登場というわけだね。どんな

変化があったんだい？」

プロジェクトへの適用

第1ステージでの反省を踏まえ、残り半分の機能を開

発する第2ステージでは、新しく任命されたPM（プロジェクト・マネジャー）から以下の3つの基本方針が提示さ

れた。

●明確かつ達成可能な目標を設定する

●適切なプロセスと規律をプロジェクトに適用する

●可能な限り、現場に近いレベルで意志決定する

また、プロジェクトの納期を重視し、これを厳守するた

めに、重要な機能を最優先で実装し、その他について

は優先順位を下げることも決定された。

この方針に従うべく、開発チームはプロジェクトにSE

＆Aを適用することをPMに提案したのである。要件の

ウンで定義すること」だ。SE＆Aは、このビジネス駆動型

のシステム構築をサポートするための“道標”を提供する

ものなのである。

SEのスキル

これまでに教えてもらったSE＆Aの内容を思い返し、

AさんはSEだからこそ得られる“やりがい”にも思い至った

ようだ。

Aさん：「SEには、さまざまなスキルが求められるんだった

ね」

Bさん：「そうだね。SEはITシステム構築の全ライフサイク

ルに関与するから、その分、どうしても広範なスキルと経

験が必要になるんだ」

Aさん：「それを聞いて、最初は敷居が高いと感じたんだ

けど……よく考えると、プロジェクトを最初から最後まで見

通すことのできる、エンジニア冥利に尽きる役割とも言える

よね」

活躍し始めるSE

IT業界で働く人材に求められる「スキル」、すなわち

知識や経験、実務能力を体系的に整理したものとして、

欧米のスキル標準や日本IBMの人事制度などを参考

に経済産業省が策定した『ITスキル標準（ITSS：IT

Skill Standards）』（http://www.ipa.go.jp/jinzai/itss/itss1.html）がある。これには、専門職種の1つとし

てITアーキテクトは定義されているものの、SEという職

種名はまだ登場していない。ただし、独自にSE、もしくは

それに順ずる役割を設けている企業は存在する。例え

ば、IBMの社内制度では、ITスキル標準をベースに

ITアーキテクトがカバーする分野の1つとしてSE＆Aを

追加しており、SEの育成に力を入れている。育成され

たSEは、部分的な機能の設計や自社製品の技術支

援だけでなく、開発プロジェクトにおいて管理から業務

分析、要件定義、詳細設計、テスト計画、システム全

7/14/2019 IT Vol.21 00.pdf



SE&Aの実践に向けて最終回

約53％がテストで検出されたのに対し、第2ステージで

は欠陥の56％が要件定義から詳細設計までの間に

検出された（図2）

●手戻りコストの抑制：第2ステージは第1ステージと

ほぼ同じ開発規模だったが、欠陥が早期に発見さ

取捨選択をしきれなかった第1ステージの結果を見た

PMは、プロジェクトのスコープを明確にし、現実的な目

標に的を絞る必要性を強く認識していた。また、過去に

SE＆Aと同様のアプローチでプロジェクトを管理した経

験があったことから、さほど抵抗もなくSE＆Aの採用を受

け入れた。SE＆Aの適用にあたり、まず開発チームは、第1ス

テージで正式に文書化された要件以外に、電子メール

や議事録といった非公式な文書に散在していた要件を

かき集めて整理し、リポジトリで一元管理することにした。

これにより、初めは随所で生じていた要件の衝突が「見

える化」され、優先順位づけやトレードオフの検討をしや

すくなった。その後、公式／非公式な要件レビューを数

回行い、当初は100個以上あった要件を46個にまで絞

り込んだ。

こうして、すべてのステークホルダーが合意したシステ

ム要件がベースラインとして確立された。それにより、要

件が明確になっただけでなく、プロジェクト管理における

評価基準も明らかになった。

また、同時に、ビジネス要件／システム要件やユース

ケース、アーキテクチャ、設計仕様、テスト仕様、追跡

可能性の管理も始められた。

SE＆Aの効果

複数回のレビューを実施しながら開発作業を進めた結果、第2ステージで開発された機能は納期どおりに

本稼働を開始することができ、しかもコストは予定よりも

5％低く抑えられた。

このプロジェクトでのSE＆Aの適用効果をまとめると、

次のようになる。

●欠陥数の減少：システム結合テストでは1,375件の機

能検証テストを実施したが、ここで発覚した欠陥は予

測数の10％未満だった（図1）

●欠陥の早期検出：第1ステージと第2ステージの欠陥

検出状況を比較したところ、第1ステージでは欠陥の

図1：欠陥発生率（予測と実績）

300

250

200

150

100

50

09月23日

9月24日

9月25日

9月26日

9月27日

9月30日

10月1日

10月2日

10月3日

10月4日

10月7日

10月8日

10月9日

10月10日

予測数実数解決数

図 2：欠陥検出状況

10090

807060

5040

302010

0基本設計

詳細設計

開発

テスト

本番準備

第 1ステージ第 2ステージ

図3：手戻りコストの比較

8万

7万

6万

5万

4万

3万

2万

1万

0

（ドル）

基本設計

詳細設計

開発

テスト

本番準備

第1ステージ第2ステージ

7/14/2019 IT Vol.21 00.pdf




を正確に伝えるのが難しい

●投資の可否を決定する前に、開発予定のシステムが

ステークホルダーの要求や予算／納期の条件を満

たしたプロジェクトであるかどうかを確認する方法が必

要である

SE＆Aは、これらの要求に応え、懸念を解消する手助けとなる手法だ。しかし、SEとともに活動するPMやそ

の他のメンバーにとって、この新しい設計／開発手法は

まだなじみが薄いため、その効果に疑念を抱かれることも

少なくない。

従来の手法から脱却し、新しいやり方にシフトしていく

には、SEがこうした不安を拭い去り、新手法の導入をプ

ロジェクト内部でサポートしていく必要がある。以下に、

従来型のプロジェクト・マネジメントに慣れたPMからよく

挙がる疑問／意見を見てみよう。

●なぜハイレベルなビジネス要件が必要なのか？

PMから挙がる意見の中で、最もよく聞かれるのは、

「わざわざハイレベルなビジネス要件を記述する理由が

わからない」という声だ。ここで言う「ハイレベル」とは「経

営層レベル」のことであり、「ハイレベルなビジネス要件」

とは、ビジネス・ゴール（「利益の向上」や「顧客数増

大」など）を達成するための「攻めの施策」と、ビジネス・

リスクを回避する「守りの施策」に必須となる「本質的な

要件」のことを指す。

ハイレベルなビジネス要件は、現場で稼働するシステムとは縁遠いものと思われがちだが、これこそが各システ

ムが最終的に達成すべき目標であるということを思い出し

てほしい。無駄なIT投資をしないように、システム化する

対象を絞るには、ハイレベルなビジネス要件の定義が欠

かせないのだ。

●受入基準はどう定義したらよいのか？

ハイレベルなビジネス要件の必要性を理解してもらっ

たところで、次によく挙がる疑問が「ハイレベルなビジネス

要件の受入基準として何を定義したらよいかわからな

い」というものだ。

れた結果、欠陥除去のための手戻りコストが第 1ステ

ージの半分以下に抑えられた（前ページの図3）

国内での適用事例

それでは、再び2人の会話に耳を傾けてみよう。今度は、国内事例に目が向けられている。

Aさん：「なるほど、SE＆Aを適用することで、随分と顕

著に差が出るものなんだね。これだけ効果があるなら、

やっぱり使ってみたいな。ところで、国内のプロジェクトで

の事例はないのかな？」

Bさん：「日本IBMではまさに今、SE＆Aを適用したプロ

ジェクトがいくつか走っているところだよ。残念ながら、ど

のプロジェクトも進行中のため、6つのベースラインをすべ

て完了したものはないんだけどね。それでも、順調に進ん

でいるようだよ。」

Aさん：「どんなシステムを開発するプロジェクトに適用して

いるんだろう？」

Bさん：「『こういうシステムでないと』ということはないんだ。

システムの規模も、対象となる業界もさまざまだし、プロ

ジェクトのゴールや特徴もまったく違う。しかし、どのプロ

ジェクトでも、リードSEがSE＆Aを推進するという基本ス

タイルは同じだよ」

現場の声表1は、日本IBMが現在SE＆Aを実践しているプロ

ジェクトの特徴や、適用状況をまとめたものだ。いずれも、

ビジネス要求ベースラインやシステム要求ベースラインを

確立している段階であり、効果を実感できるのはもう少し

先になる。プロジェクトによってゴールは異なるが、いずれ

においても、要求／懸念事項として挙がったのは次の

事柄だ。

●複雑なプロジェクトに潜むさまざまなリスクを減らす必

要がある

●SIerに対して、本当に必要な機能や求めている性能

7/14/2019 IT Vol.21 00.pdf



SE&Aの実践に向けて最終回

になっているかどうか」といったことを確認してみるとよいだ

ろう。

●見積もりが不安だ……

PMの中には「ハイレベルなビジネス要件では、見積も

りができない」と考え、「先にユーザー・インタフェースや

プロシージャ、ルール、エンティティ（データ）を詳細に分析するべきだ」と主張する人も多い。確かに、そうした項

目の分析／定義は、アプリケーションの開発規模やコス

トを詳細に見積もるうえで有効である。しかし、それらを詳

細に定義するには相応の工数やコストがかかる。従来

型の手法で大量のDFO（Design For Operations）

やER（Entity Relationship）図などを作成したのにも

経営目標であるビジネス・ゴールには、「経営目標達

成指標（KGI：Key Goal Indicator）」が定義され、こ

のKGIを達成する戦略的な手段として「重要成功要因

（CSF：Critical Success Factor）」が定義される。そ

して、それぞれのCSFの実行状況を計測するために

「業績評価指標（KPI：Key Performance Indicator）」を定義するわけだ。

ビジネス・ゴールの達成やビジネス・リスクの回避にお

いて必須となるビジネス要件はCSFに、受入基準は

KPIに相当する。もし、ビジネス要件に対して受入基準

が定義できない場合は、そのビジネス要件が「CSFに

なっているかどうか」、「KPIを定義できるレベルのタスク

表1：SE＆Aの実践プロジェクト例

業種

不動産

保険

商社

金融

製造

プロジェクトのゴール

既存のホスト・システムを、オープンか

つ標準のシステムに移行する

ビジネスのスピードと品質を強化する

ため、基幹業務ワークフローを自動化

する

複数業務領域において業務プロセス

の効率化を実現する

複数社の業務統合に伴い、基幹シス

テムを統合する

システムの信頼性を高め、法制度に

適合させる

進行状況

パイロット版を通じて、顧客から業務

要件とシステム要件の定義プロセス

と、その重要性に関する理解を得た

ビジネス要求ベースラインのレビュー

を行った段階。基本的には前向きの

評価を得て進んでいるが、導入にあた

っての混乱やSE＆Aに対する理解不

足が感じられる面も多い

PMが追跡可能性マトリクスの重要性

を認識した。また、顧客も業務要件と

システム要件の間の追跡可能性を維

持することの効果を理解している

プロジェクト・リーダーが、業務要件定

義作業を高く評価し、新業務フローと

業務要件は、顧客の重要な資産にな

るとまで考えられている

経営層がSE＆A の導入に同意。ま

た、業務部門のリーダーは、SE＆Aに

よる業務要件定義の方法が、業務要

件をビジネス目標に適合させるための

重要な方法であることを認識した。さ

らに、PMはベースラインが後工程で

の意思決定の助けになることや、要

件漏れを防げることを認識している

SE＆Aの貢献内容

要件ベースラインを確立することによ

り、「既存システムと同等の機能」が

可視化され、後工程で顧客との認識

の齟齬を回避できる

システムに基づく新業務プロセスと業

務要件が定義できる。また、品質の

向上が期待できる

顧客が業務プロセス改善計画の局面

で定義した業務要件を開発チームが

評価できる。また、顧客の業務部門

が定義した業務要件と、IT 部門が定

義したシステム要件の追跡可能性を

維持できる

業務要件がビジネス目標に適合して

いることを評価できる。また、要件の

品質向上も期待できる

SE＆Aによって、RFP（提案依頼書）

とビジネス・プロセス、業務要件、シス

テム要件などの追跡可能性が維持で

きる。また、アーキテクチャ上の要件

を定義したり、決定と要件との間の追

跡可能性を管理したりできる

プロジェクトの複雑さの要因

仕様書もなく、機能が肥大化したレガ

シー・システムの現行機能を踏襲する

ために、該当機能を可視化しなくては

ならない

現行の紙ベースのビジネス・プロセス

からの改革であり、早急な対応が法

的にも社会的にも求められている

業務部門が業務要件を、IT 部門がシ

ステム要件をそれぞれ定義し、IT子会

社がプロジェクトをリードしている。プロ

ジェクトを推進するには、これら3つの

企業に存在するすべてのステークホ

ルダーの合意が必要

合併を伴わない純粋な業務統合のため、各社それぞれにステークホルダー

が存在する。また、各社固有の業務

プロセスは残しながら、機能を統合し

なければならない。各社は既存機能

の再利用を望んでいるが、同時にいく

つかの新規要件も存在する。また、

開発対象システムには、多くの外部イ

ンタフェースが存在する

技術的な難しさを伴う非機能要件が

存在する。法令や規則の厳守が求め

られている

7/14/2019 IT Vol.21 00.pdf




turity Model Integration）をベースにした「IGSDF

（IBM Global Solution Delivery Framework）プロ

セス」を導入しており、その中に、SE＆Aのテクニカル・レ

ビューによる監査プロセスを組み込んでいる。プロジェクト

の各局面で実施するレビューでは、経験豊富なSEに

よって要求、設計、技術のあらゆる側面における欠陥や課題が洗い出され、たとえ少数でも重大な欠陥／課

題が残っていたら次のプロセスに進めないような“関所”

が設けられている。

＊＊＊

「初めにしっかりと要件を定義する」、「早期にテストを

行って欠陥を検知し、品質を高める」といったSE＆Aの

基本コンセプトは、ITシステム構築に携わるエンジニアな

らば受け入れやすいはずだ。ただし、従来とは異なるプ

ロセス／成果物となるため、周囲の賛同を得られない

ケースもあるだろう。これは顧客に限った話ではなく、時と

してプロジェクト・メンバーの理解を得るのに苦労すること

もある。どんな事柄にせよ、新しいものを取り入れるのに

少なからず抵抗があるのは世の常だ。

とは言え、SE＆Aでは、何かまったく新しいことをやろう

としているわけではない。「できて当たり前のことをきちんと

やろう」という、いわば“初心に帰る”ことを訴えているだけ

だ。忍耐と根気、そしてITアーキテクトとしての倫理観を

持って周囲を説得すれば、この手法に対する理解は必ず得られるはずである。ぜひ本誌読者にも、実プロジェク

トへのSE＆Aの適用に挑戦してみていただきたい。そこ

に費やす時間的／金銭的コストには、必ず十分な見返

りがあるはずだ。

かかわらず、失敗してしまったというプロジェクトは少なくな

いはずだ。その原因は、新システムの構築目的／理由

を見失ったまま、現行システムを踏襲する機能の詳細に

とらわれたことにある。これは「木を見て森を見ず」の状

態だと言えるが、プロジェクトを成功させるには「森を見

てから、残す木と間伐する木を見分ける」ことが重要なのだ。

プロセスを形骸化させないために

ITアーキテクトは、ビジネスとITシステムとの間にある

論理的な因果関係、つまり追跡可能性を明確にすると

ともに、アーキテクチャ上の決定に対して説明責任があ

ることを心しておかなければならない。そして、この説明

責任を果たすうえで助けとなるのが、SE＆Aのプロセス

なのだ。

ここまでの話を聞き、Aさんは素朴な疑問を抱いたよう

である。

Aさん：「でも、プロセスってものは、結局は形骸化してし

まうんじゃないのかな？例えば、少し前に耐震偽装問題

があっただろう。あれだって、法律では建築の外部監

査がきちんと決まっていたのに監査が形式だけのものに

なってしまっていたから、それでああいう事件が起きたわ

けだよね」

Bさん：「そうならないように、SE＆Aで行うテクニカル・レビューは、十分な実務経験のあるSEやITアーキテクト

が責任を持ってきちんと行うことになっているんだよ。単に

“レビューしました”という報告だけになってしまわないよう

にね」

外部監査の仕組み

IT業界には、システムの開発工程に関して、法律に

基づく外部監査は存在しない。そのため、企業ごとに独

自の監査基準が設けられている。日本IBMの場合、提

案案件やプロジェクトに、CMMI（Capability Ma

『ProVISION No.57 Spring 2008 ソフトウェア開発

における“学習する組織を目指して”』（URL：http://

www-06.ibm.com/jp/provision/no57/pdf/57_

article1.pdf）

参考文献

7/14/2019 IT Vol.21 00.pdf


08

新刊書籍情報

Books

アー

キテクチャ設計で

核とな

る思考法を伝授

『システムアーキテクチャ構築の原理』

著者■Nick Rozansk i、ほか

訳者■榊原彰、ほか

発行■翔泳社

価格■5,040円

「ステークホルダー」、「ビュー・ポイント」、

「パースペクティブ」という3つのキーワードを軸

に、アーキテクチャ設計に際して、アーキテク

トはどのように物事を見て、考えればよいのか

をまとめた1冊。前半では、アーキテクチャの

構成要素や記述法といった基本事項のほか、

ステークホルダーを選出する際のポイントなど

を説明し、後半では、ビュー・ポイント／パース

ペクティブについて解説。最後に、アーキテク

トの役割を示して総括としている。

『ITコンサルタントのための要件開発入門』著者■工藤浩志、ほか

発行■技術評論社

価格■2,289円

ユーザーの要求を要件とし

てまとめる“要件開発”につい

ての入門書。まず、システム開発における要求工学の位

置づけや、要件開発を成功

させる秘訣などを説明したうえ

で、要件とシステムの間のト

レーサビリティを確保する仕

組みとして「要件開発アーキ

テクチャ」を紹介している。

『ITロ−ドマップ 2009年版』著者■野村総合研究所技術調査部

発行■東洋経済新報社

価格■2,310円

野村総合研究所では、

毎年ITの動向調査を行い、

その結果を基に翌年以降の

注目技術を予想／解説した

書籍を刊行している。その

2009 年版が本書だ。今回

は、クラウド・コンピューティ

ングや次世代検索技術、メ

タデータ管理技術などが取

り上げられている。

『はじめての設計をやり抜くための本』著者■吉原庄三郎

発行■翔泳社

価格■2,499円

アプリケーションはもちろ

ん、データベースやネットワ

ークなど、さまざまな分野の

設計テクニックを1 冊に凝

縮。開発標準の策定方法

や外部設計／内部設計の

ポイント、サブシステム分割

の基準、効果的なレイヤ構

成といった設計のノウハウを

豊富に紹介している。

『UML オブジェクト指向分析／設計教科書』著者■金澤典子

発行■ソフト・リサーチ・センター

価格■2,730円

オブジェクト指向に基づくシ

ステム分析／設計の基本を

徹底的に解説。「クラス」や

「継承」といった概念の説明

に始まり、業務分析の手法や

UMLによるモデルの描き方、

有用なデザイン・パターンなど、

オブジェクト指向分析／設計

に必要な基礎知識を網羅して

いる。

ITアーキテクト Vol.21

『実装パターン』著者■Kent Beck

訳者■長瀬嘉秀、ほか

発行■ピアソン・エデュケーション

価格■2,310円

Javaプログラミングにおけ

る実装パターン（Implemen

tation Pattern）について解

説した1冊。初めにプログラ

ミングの基本理論と実装パ

ターンのコンセプトを説明し

た後、「クラス」や「メソッド」

など5つの項目について、そ

れぞれ10以上の実装パター

ンを紹介している。

7/14/2019 IT Vol.21 00.pdf


084

澤

井隆

慶

Takayoshi Sawai

出光興産

情報システム部

企画課

澤井隆慶氏は1993 年、新卒で出光興産

情報システム部に入った。大学では金属特性を

研究。コンピュータは単なる道具の1つとしてしか

見ておらず、仕事にするつもりはなかったが、「若

いうちから自分が何に向いているかわかるわけが

ない」（澤井氏）とこの道に入った。配属先として希望したのは、「できるだけ“人”

に近いところ」。しかし、最初に任されたのは、ホ

ストの運用管理だった。人よりもコンピュータを相

手にすることが多く、入社直後はモヤモヤとしたも

のを感じていたという。

その気持ちを振り払うため、周囲に「1年でプロ

になってみせる」と宣言し、あえて高い目標を掲げ

た。さらに、夜間勤務や休日出勤を買って出て、

マニュアルも読み漁った。検証環境の構築や、

内製ジョブ・スケジューラの保守も行った。そんな

日々を2年も送るうちに、氏は一人前のホスト技術

者となり、モヤモヤした気持ちはいつしか吹き飛ん

でいたという。

そうした折、新技術の研究／開発を行う部署

へ異動となり、今度はオープン系技術を吸収して

いく。2000年に入ると、社内初のWebアプリケー

ション開発を担当し、企画から運用までを1人でこ

なした。

そのころから、澤井氏の中では「標準化」が大きなテーマとなる。当時、社内では新規システムが

次に々稼働し始めていた。だが、それらのシステム

は、各業務に応じて最適化されたものだ。澤井

氏は、「このままでは個別最適化されたシステムが

乱立して、遠からず保守／運用が困難になる」

と、ITインフラの共通化を提案／実行する。

また、2002年には初めてJavaに触れたが、SIer

から納入されたアプリケーションを見て愕然とした。

「アーキテクチャの設計があまりにもひどい。Javaこ

そ開発標準が必要だ」と感じた澤井氏は、Java

開発標準の策定を起案する。ただし、標準化と

いう規模の大きな取り組みに対しては、会社も慎

重になる。提案は、上層部から「費用対効果が見えない」と保留にされた。しかし澤井氏は諦め

ず、あるプロジェクトに掛け合い、考えていた開発

標準を適用する。そこで、開発コストを当初見積も

りの半分にまで抑えることに成功し、標準化へのゴ

ーサインを勝ち取った。

2004年から行われた基幹系システム再構築プ

ロジェクトでは、アーキテクトを任され、共通基盤

の設計や開発プロセスの標準化を進める。共通

基盤には、管理性を考えてESB（Enterprise

Service Bus）を採用し、開発プロセスに関して

は、優先度の高い機能から作る「リファレンス先

行開発」という仕組みを取り入れた。こうした新

標準の導入に、多忙を極める現場は当初反発

を示したが、澤井氏は「こちらが譲れないところは

譲らない分、自分たちもプロジェクトの当事者とし

て、できる限り開発に加わる」という心意気で臨ん

だ。そうした努力の甲斐もあり、最終的には現場

の開発者に受け入れられたという。

「1つの分野を極めれば、そこからキャリア／スキルが広がっていく」と語る澤井氏。実際、ホスト

の運用管理者から始まった氏のキャリアは、新技

術の研究／開発や標準化の推進を経て、アー

キテクトへとつながった。現在はCIOのスタッフ組

織で働くが、幅広い経験を経て現場から全社シ

ステムまで熟知した澤井氏の存在は、CIOにとっ

て心強い助けとなっているに違いない。

20 Vol.

P e r s o n a l H i s t o r y o f T o p A r c h i t e c t

坂口正憲 Masanori Sakaguchi

KOYO代表

IT アーキテクト Vol.21

7/14/2019 IT Vol.21 00.pdf



1つの分野を極めれ

ば、

そこからキャリアが

広がっていく

写真：小林直

1969年東京都生まれ

1993年東京理科大学理工学部を卒業後、

出光興産に入社。情報システム部

業務課に配属され、メインフレームの

運用管理とジョブ・スケジューラの開

発を担当する

1995年システム総合研究所に転属。当時

の最新技術を用いて開発を行う

2004年総括課に異動し、マネジメント業務に

携わる中で標準化のスコープを広げ

ていく。また、同課に在籍しつつ、組

織を横断して編成した標準化チーム

のリーダーも担う

2006年システム総合研究所に戻り、アーキ

テクチャ担当の技術チームでリーダー

を務める

2008年現在は企画課で、CIOスタッフとして

中短期計画の策定、投資管理、調

達レベル向上に向けた活動などに取

り組んでいる

趣味◎今年から始めた少年野球のコーチ。小さな自

宅菜園での野菜作り

7/14/2019 IT Vol.21 00.pdf


ドラえ

もんの

ひみつ

道具

を作っ

てみよう


ドラえもんの“ひみつ道具”

ドラえもんは、2112年に子守用ロボッ

トとして開発された。22世紀では、おそら

くロボットが白物家電化しているのだろう。

ドラえもんが四次元ポケットから取り出す

“ひみつ道具（アイテム）”も、22世紀で一

般消費者向けに普通に販売されている

ものだ※1。ドラえもんは、アイテムを購入

する際に、いちいちセワシ※2 に決済を仰

いでいないことから、どれもさほど高額な

ものではないと推測される。ドラえもん自

体が子守用ロボットなのだから、彼が出

すアイテムも、子どものお小遣い程度で

買えるものだと考えるのが自然だ。

19 世紀には、鉄の塊が空を飛ぶなど

とはだれも思っていなかっただろう。それ

が、20世紀末には、ごく少数の金持ちだ

けとは言え、自家用ジェット機を持つまで

になった。100年間で科学や工業技術が

どれだけ進化したかを考えると、21世紀に

はどんな発展を遂げているのか、筆者に

は想像もつかない※3。22 世紀に至って

は、言わずもがなだ。

今回は、現在考えられる技術要素によ

って、ドラえもんのアイテムの中でも最も

よく知られている「タケコプター」と「どこで

もドア」を作るにはどうしたらよいかを考え

てみる。

タケコプターを作ろう

昨年3月、GENコーポレーションが開

発／製造する「GEN H-4」（写真1）が、

世界最小の有人飛行可能なヘリコプタ

ーとしてギネス・ブックに認定された※ 4。

世界最小と言ってもまだまだ大きいが、

実在する製品としては最もタケコプター

に近いものだろう。しかも、試作品という

レベルではなく、れっきとした一般消費者

向けの商品である。約600万円という価

格は、小金持ちならば道楽で買えるレベ

ルだろう。国内で飛行するには、国土交

通省航空局の許可が必要なため※5、法

制上の整備が進まないと普及は見込め

ないが※6、その点さえクリアできれば、急

激に普及する可能性もないとは言えな

い。

22世紀では、小学生もタケコプターを

使っているのだから、自転車なみの気軽

さで利用できるものであってほしいところ

だ。それでは、GEN H-4を、よりタケコプ

ターに近づけるにはどうしたらよいか考え

てみよう。

●脚を外す

GEN H-4 にはかなり大きな脚が付い

ているが、これは機体を置いておく際に

使うもので、着陸時はパイロットが地面

に足を着くのだという。そこで、実用性は

犠牲になるが、駐機用の台を別に用意

することにして脚を取り外してしまえば、

雰囲気はタケコプターに近づく。22世紀

には、駅前に駐輪場ならぬ駐機場を整備

し、タケコプターを固定するための台を備

※1 ドラえもんは、四次元ポケットから取り出すアイテムの多くを「未来デパート」で購入している。

※2 のび太と静香の玄孫。ドラえもんを20 世紀で暮らすのび太の下に送り込んだ張本人。

※3 コンピュータはどうなっているのか、まったく想像がつかない。ノイマン型のアーキテクチャではなくなっているかもしれな

い。量子コンピュータが主流になっている可能性も否定できない。逆に、100年後の姿がある程度想像できるものもある。例えば、自動車の基本要素は、1950年代にほぼ完成の域に達していたと言われる。環境性能や安全性能などは年々進化しているが、レシプロ・エンジンによって走行する点や、外観、運転方法などは、50 年前とほとんど変わっていない。遠くない未来、動力は電気モーターに切り替わるだろうが、それ以外のメカニズムは大きく変わらないだろう。22世紀になっても、『バック・トゥ・ザ・フューチャー』のように、自家用車

に小型原子炉が搭載されたり、空を飛んだりするようなことはまずないはずだ。

※4 この製品は、実は1997年にはほぼ完成していた。なぜ10年以上たってからギネス認定されるに至ったのかは謎である。

※5 現在は、「ウルトラ・ライト・プレーン」という、趣味で自作した軽飛行機などと同じカテゴリーで扱われる。そのため、運転

に際して免許は不要だが、航空局の許可が必要で、しかも許可証は1カ月ごとに更新しなければならない。

※6 2001 年に“革命的な製品”と話題になった「セグウェイ」と同じ運命をたどる可能性が高い。

本連載では、これまでに何度かフィクション（SFやアニメ）を

“勝手に分析”してきたが、いよいよ今回は、

突っ込みどころ満載の名作漫画『ドラえもん』に迫る。

と言っても、ドラえもんがポケットから取り出す道具について、

「非現実的だ」とか「ありえない」などと言うのではつまらない。

ドラえもんの“ひみつ道具”の中から「タケコプター」と

「どこでもドア」を取り上げ、「これらを作るとしたら

どのような仕掛けになるのか」を考えてみたい。

笠原規男 Norio kasahara

豆蔵主幹コンサルタント

イラスト：花くまゆうさく

Vol.19

7/14/2019 IT Vol.21 00.pdf



えればよいのだ。

●操縦桿を外す

GEN H-4では、操縦桿を傾けるとそ

れに合わせてローター（プロペラ）が傾き、

前後左右に移動できる。この操縦桿が、

“タケコプター感”を削ぐ大きな原因になっ

ている。操縦桿を通じた機械制御でロー

ターを傾けているが、これを電子制御に

するのは技術的にそう難しいことではない

はずだ※7。電子制御ならば、例えば首に

センサーを付け、頭を前後左右に動かす

とその方向に進むようにするのは簡単だ

ろう。

同様に、上下に移動するためのアク

セル※8 や、左右に向きを変えるためのヨ

ー・コントロール・スイッチ※9も電子制御

にし、頭の動きに連動するようにすれば

よい。

●座席を外す

脚と操縦桿を取り外したら、ぜひ座席

もなくしたい。ただし、タケコプターのよう

に機体を頭に取り付ける方法では、人が

頭をつかまれて宙吊りになっているのと同

じである。そんな状態で移動したら、首の

骨が耐えられない。

ここは残念だが、ライフ・ジャケットのよ

うなハーネスを身に付けて、機体にぶら

下がるスタイルで妥協することにしよう。

●ローターの改良

GEN H-4のローターは、上下に2枚

並ぶ、ツイン・ローターと呼ばれるタイプ

だ。これをタケコプターのようにシングル・

ローターにしたいところだが、それを実現

するのは難しい。

プロペラが回転すると、反作用で機体

（タケコプターでは人体）は反対の方向に

回転しようとする。タケコプターのように

頭に直接取り付けるタイプでは、首がね

じれてパイロットが死んでしまうのだ。上述

したように、機体を胴に固定すれば死に

はしないかもしれないが、身体全体が高

速回転することになるので操縦どころで

はない。

ツイン・ローターならば、上下のロータ

ーを逆方向に回転させることで、反作用

を打ち消し合える※10。やはり、現実のタ

ケコプターもツイン・ローターにせざるをえ

ないだろう。

では、シングル・ローター化は諦めると

して、せめてタケコプターのようにローター

を直径数十センチ程度のサイズにできな

いだろうか※11。だが、小さくして元のサイ

ズと同じ出力を得るには、回転数を上げ

なければならない。すると、巨大な（もしく

は多数の）ギアが必要になり、トランスミッ

ション（変速機）がローターよりも大きくな

る可能性がある。また、ひたすら回転数

を上げて出力を得ようとするのは、自動車

で言えばロー・ギアで高速道路を走ろうと

するようなもので、とても効率（燃費）が

悪い。やはり、ローターもそれなりのサイ

ズが必要だ※12。

●全体を小型化

タケコプターと言えば、頭の上にちょこ

※7 GENコーポレーションはとても小さな会社で、設計／開発担当者は76 歳と高齢だ。そのため、電子制御技術を持ち合わせていないことも考えられる。しかし、そこは新しい技術者を投入すればよいだけの話で、現代の工業技術の限界とは関係ない。ちなみに、電子制御による操縦方式は「フライ・バイ・ワイヤー」と呼ばれる。その名前のとおり、航空機技術をベースに発達したものだ。最近は、自動車のアクセルやハンドルも、フライ・バイ・ワイヤーになっているものが少なくない。

※8 GEN H-4のアクセルは、オートバイのようにグリップをひねる方式になっている。

※9 GEN H-4 の技術的ハイライトは、ヨー・コントロールにある。2つのローターの回転数に差を付けることで、方向転換を実現しているのだ。仮に上のローターが右回りで、下のローターが左回りだとすると、上のローターの回転数を落とせば下のローターの反作用（左回りの反作用なので右回り）が優勢になり、右を向くことが

できる。

※10 一般的なヘリコプターはシングル・ローターだが、機体尾部についたテール・ローターによって機体の回転を阻止している。タケコプターのようにテール・ローターを持たないタイプでは、ツイン・ローターが必須なのだ。

※11 GEN H-4のローターは直径4mである。

※12 ヘリコプターでエンジンが停止してしまった際、軟着陸するための機能に「オート・ローテーション」というものがある。オート・ローテーションでは、落下するときの風圧を使ってローターを回し、揚力を得て、落下速度をコントロールする。だが、タケコプターでローターがあまりにも小さい場合、ローターが身体の影になって風が当たらず、オート・ローテーションを行えなくなる。こうした理由からも、ローターを極端に小さくはできない。

勝手

に

ア

ー

キ

テ

クチ

ャ

分析

A

n

a

l

y

z

i

n

g

t

h

e

a

r

c

h

i

t

e

c

t

u

re

f

r

e

e

l

y

写真1：GEN H-4。GENコーポレーションのWebサイト

（http://www.gen-corp.jp/product/categories/

p3.html）より

図1：GEN H-4をベースに筆者が考えたタケコプター

の想像図

全体を小型化

首にセンサーを付けるハーネスを着用

7/14/2019 IT Vol.21 00.pdf



んと乗せられるコンパクトさも魅力の1つ

だ。前述のとおり、頭乗せタイプは現実

的ではないが、それでもデイ・パックくらい

のサイズになってくれれば、パーソナル飛

行ツールの雰囲気はかなり出る。それで

は、機体全体を小型化する方法につい

て考えてみよう。

GEN H-4は、125ccのガソリン・エン

ジン※13を4機搭載している。排気量を変

えずに小型化するのは物理的に限界が

あるし、排気量が小さくて高出力が出せ

るエンジンを追及するのにも限界がある。

加えて、ガソリンも搭載しなければならな

い※14。ガソリン以外の燃料を使うにして

も、内燃機関を使っている限り、現在の

何十分の一といった劇的な小型化は望

めない。

可能性があるとすれば、電気モーター

を使う方法だろう。現在の技術では、バ

ッテリーが大きくて重いのが最大の問題

点だ。今後、燃料電池の技術が進歩し

て※15、小型で大容量の電源が登場する

ことに期待したい。

どこまで小型化できるかはともかく、自

転車のように手軽に近距離を移動する

手段としての小型ヘリコプターは、現在

の技術でも十分に実現可能だ（前ページ

の図1）。22世紀を待つまでもない。もし、

読者が製品化を考えるならば、「タケコプ

ター」が商標登録されていないかどうか、

今すぐ確認しておくことをお勧めする。

どこでもドアの作り方を

考える

どこでもドアは、タケコプターに次いで

のび太がよく使っているアイテムである。

しかし、タケコプターの実現方法にはリア

リティがあったが、どこでもドアについて

は絵空事となるのは否めない。22世紀に

なっても、実現は難しいだろう。だが、そ

れでも理論的にはどのような方法が考え

られるのか、夢想してみる。

●ワームホール方式

どこでもドアは、時空をゆがめて任意

の2 地点を張り合わせてしまう、いわば

「ワームホール」である※16。そして、ワー

ムホールの出入り口はブラック・ホール

だ。どこでもドアと称して、小型のブラッ

ク・ホールを持ち歩かれては、周りはたま

ったものではない※17。

それに、巨大な質量を持つブラック・ホ

ールを移動させるよりは、人が自ら飛行

機などで移動するほうがよほど簡単だ。2

地点間の移動を瞬間的に行えても、どこ

でもドア自体を移動させるのに多大な時

間と費用がかかるようでは、本末転倒で

ある。

●量子テレポーテーション

どこでもドアは、瞬間移動、すなわちテ

レポーテーションを可能にする装置であ

る。テレポーテーションは大概、超能力

の1つとして語られる。自然科学とは相容

れない価値観の世界だ。

物理学で唯一、テレポーテーションと

いう言葉が使われるのが「量子テレポー

テーション」である。こちらは、オカルトと

は無縁の量子力学の用語だ※18。量子テ

レポーテーションは、量子的に絡み合っ

※13 一時はオートバイ用のエンジンに多く見られた2サイクル・エンジンだ。小型高出力だが、環境性能が悪い。そのため、最近はほとんど4サイクル・エンジンに切り替えられている。

※14 GEN H-4 の燃料タンク容量は10リットルとなっており、30分程度の飛行が可能だという。

※15 携帯電話やノートPCでは、現在

主流のリチウム・イオン電池に代わって燃料電池を使うものの試作が始まっている。燃料電池が実用化されれば、タケコプターの小型軽量化に大きく貢献するはずだ。

※16 2つのブラック・ホールをつなぐ時空へのトンネル。ワームホールを通り抜けることで、瞬間的に遠く離れた場所や過去／未来へと移動することができる。詳細については、連載第14 回『タイムマシンのアーキテクチャ』（Vol.16掲載）を参

照されたい。

※17 「人がブラック・ホールに落ちる」という事故が多発するだろう。

※18 量子力学の基礎を正確に説明するのは今回の主旨から外れるし、筆者にもそんな知識はない。したがって、ここでは量子テレポーテーションとはどんな現象なのかを簡単に説明するにとどめる。

※19 相反する状態を持つ素粒子のペアがあり、その状態が定まっていないとき、これを「量子的に絡まった状態」と言う。

図2：量子テレポーテーション

ベル判定

通常通信

量子的絡み合い

量子チャネル

S SX Y

ユニタリー変換

7/14/2019 IT Vol.21 00.pdf



た状態にある2 つの素粒子で構成される

「量子チャネル」を利用する※19。絡み合

った素粒子は、たとえ何万光年離れてい

ても、片方の素粒子を観測して、一方の

状態が定まるともう一方の状態も決ま

る。影響は瞬時に相手側に伝わり、これ

がある種の通信路として使えるので、量

子チャネルと呼ぶのである※20。

図2に、量子テレポーテーションの様

子を示す。素粒子XとYが絡み合った状

態にあり、量子チャネルを構成している。

Xにテレポーテーションさせたい素粒子S

を衝突させ、その結果生成された素粒子

2つを「ベル判定」という方法で観測す

る。観測結果は、通常通信でY 側へ送

信する※21。ベル判定によって絡み合っ

た状態が解消され、Yは状態を変化させ

ている。そのYに対して、ベル測定の結

果を使って「ユニタリー変換」という操作

を行うと、YはSを正確に写し取った状態

になる。

量子論的には、同じ状態を持つ素粒

子は区別できない。そのため、オリジナル

のSと量子チャネルの反対側で生成され

たS（元Y）は同じものだと見なされる。こ

れにより、量子チャネルを使って、Sがテ

レポーテーションしたことになる。

人間を構成する原子をすべて量子テ

レポーテーションさせる装置を作れれば、

それがどこでもドアになる。ただし、このど

こでもドアには大きな欠点がある。人を

構成する原子と同じ数だけ、量子チャネ

ルが必要になるのだ※22。人体を構成す

る原子の種類／数は、人によって異な

る。したがって、どこでもドアでは標準的

な人間1人分よりも多めの原子をあらかじ

め絡み合った状態にして用意しておかな

ければならない。しかも、量子テレポーテ

ーションを行うと、量子チャネルは消滅し

てしまう。このどこでもドアは、大掛かりな

うえに使い捨てなのだ※23。

ほかにも、どこでもドアを実現するため

のアイデアはいくつかあるが、それらのア

イデアと“本物”とで最も異なる点は、出

口が固定されてしまうことだ。上述の方

法でどこでもドアを具現化しようとすると、

出口側にもそれなりの装置が必要になる

ので、目的地は「どこでも」というわけには

いかないのである。空港のように、地域

ごとにどこでもドアの出口となる装置を置

いた施設を設け、どこでもドアを出た後は

従来の交通機関を使って移動することに

なるだろう※24。

＊＊＊

コストや法制面をクリアすれば、すぐに

実現できそうなタケコプターと、まったく現

実味のないどこでもドア。しかし、より大き

く未来を変える可能性を持っているのは、

どこでもドアのほうだ。量子テレポーテー

ションは、現実には人体のような大きな

物体を移動させることはできないが、情報

を転送するには有用なので、量子コンピ

ュータを実現するための重要な技術要素

だと考えられている。

「夢物語のアイテムが、IT の世界を大

きく変える可能性を持つ技術とつながっ

ている」というのは面白いと思うのだが、

皆さんはどう思われるだろうか。

08

※20 量子チャネルの伝播は瞬間的なもの（速度無限大）だが、量子テレポーテーションには通常通信で送信されるベル判定の結果が必要となるため、光速を超えることはできない。決して、相対性理論と矛盾するものではないのだ。

※21 通信手段は、衛星通信でもインターネットでも何でもよい。

※22 炭素をテレポーテーションさせるに

は、絡み合った炭素による量子チャネル

が必要である。同様に、水素には水素の量子チャネルが必要だ。

※23 実は、人を原子レベルに分解し、量子チャネルを使って転送した後、元の人体に再構成するのが最大の技術的難問である。どんな乗り物にも事故は付き物だが、量子テレポーテーションに失敗すると人体が原型をとどめず、かなり悲惨な結果になりそうだ。

※24 遠距離の移動はどこでもドア、近

距離はタケコプターという使い分けになるのではないだろうか。中距離移動には、鉄道や航空機を使えばよい。現在のカー・シェアリング・システムのように、駅や空港にタケコプターが置かれていて、契約者が共用するようになっているかもしれない。

勝手に

ア

ー

キ

テ

ク

チ

ャ

分析

ドラ

えもんのひみつ道具を作ってみよう

Vol

ドラえもんの連載が開始された1970年前後、科学は万能であり、

無限の可能性を持っているという考え方がまだ有力だった。

そうした楽天的な時代背景の下に考えられたアイテムの数々は、

技術的な裏付けなどまったく考慮されず、「こんなものがあったらいいな」

という欲求のみに基づいて考え出されたものである。

それゆえ、荒唐無稽ではあるけれど、

どれも楽しいものばかりであり、確かに人を幸せにしてくれそうだ。

われわれが携わっているITという道具も、

そんなアイテムの1つであってほしいものである。

7/14/2019 IT Vol.21 00.pdf


7/14/2019 IT Vol.21 00.pdf


ビジネス／技術の変化を踏まえて、既存I

T資産をどう活用するか

損害保険ジャパンの10

余年にわたる取り組みに学ぶ、

〝守るべき資産〟の選び

方、再利用を促進するアーキテクチャの作り方、

再利用を統制／推進す

る体制の築き方

特集

2


7/14/2019 IT Vol.21 00.pdf


システム開発の世界における長年の課題である「再利用」。

その効用としては、ITコストの削減や開発スピードの向上、

品質確保などが挙げられる。ただし、この再利用の仕組み

をシステムのアーキテクチャに取り込み、継続的に効果を

出していくためには、いくつもの課題を克服しなければなら

ない。これに長年にわたって取り組んでいるのが、損害保

険大手の損害保険ジャパン（損保ジャパン）である。同社で

は、段階的に再利用の仕組みを整備し、オンライン系のシ

ステム全般で活用している。事業の核となるIT資産を再利

用し、システム、ひいてはビジネスの俊敏性を高めることに

成功しているのだ。本特集では、損保ジャパンのオンライ

ン・システム基盤を長年にわたって設計／保守してきたアー

キテクトが、同社が築き上げた再利用のためのアーキテクチ

ャについて解説する。また併せて、そのアーキテクチャを浸

透させるために同社が実施してきた取り組みも紹介する。

服部浩憲 Hironori Hattori

損保ジャパン・システムソリューション基盤システム事業部シニアシステムアーキテクト


7/14/2019 IT Vol.21 00.pdf


Part 1

損保ジャパンの

ビジネス環境とITシステム

本特集では、筆者がアーキテクトとして長年にわ

たって構築／保守に携わってきた損保ジャパンのシ

ステムを例にとり、企業システムにおける再利用のポイ

ントを解説していく。まずはその前提事項として、金

融業界の業務の特徴や損保ジャパンのシステム環

境などについて説明したうえで、同社がなぜ再利用

を重視するのかを述べよう。

金融機関の業務の特色

金融業とは、“バーチャルな商品”を取り扱う業

種だ。

金融機関では、商品ルールそのものが商品であ

り、契約内容や入出金を台帳に記録することが業

務処理の中核となる。例えば、銀行の場合、預け入れ／貸し付けに関する規定や利率そのものが商

品であり、預金口座が台帳となる。一方、損害保

険の場合、商品は保険引き受けや保険金支払い

の規定と保険料率であり、台帳は契約内容と保険

料の収納、および保険金の支払いを記録したもの

のことを言う。

商品ルールはプログラムのロジックと親和性が高

く、台帳はデータベースそのものである。故に、金融

機関の業務はそのほとんどがITシステム上で処理さ

れる。今日の金融機関は、ITシステムなしでは成り

立たないと言っても過言ではないのである。

ポイントは〝守るべき資産〟の分離――

損保ジャ

パンの再利用促進を支える

﹁アプリケ

ーション・レイヤ﹂の仕組み

既存IT資産の再利用がさまざまなメリットをもたらすことは、

本誌読者に改めて説明するまでもないだろう。

それでは、ITシステムを構成する要素のうち、

どの部分を再利用するのが効果的なのか、

また再利用可能な資産を蓄積したとして、

それをどう活用すればよいのか――

本パートでは、初めに損保ジャパンを取り巻く

ビジネス環境と同社のITシステムの全体像を紹介する。

そのうえで、損保ジャパンが再利用の実践に向けて

独自に策定したアーキテクチャ設計概念

「アプリケーション・レイヤ」について解説する。


7/14/2019 IT Vol.21 00.pdf


特集

2

損保ジャパンのシステム環境

次に、損保ジャパンのシステム環境の変遷を、前

身となる安田火災海上保険の時代から振り返ってみたい。1950 年代から1980 年代にかけては、主に

次のようなことがあった。

●1950年代：IBM製のパンチ・カード・システムを

採用

●1960年代：コンピュータによる事務処理を開始

●1980年代初頭：全店全種目オンライン・システム

が完成。データベース上の台帳が完備され、主

要商品の商品ルールがシステム化された

●1980年代後半：損害保険代理店においてオンラ

イン・システム（代理店システム）の利用が始まる。

1980年代終盤には手書きOCRシステムによる営

業店計上を開始し、保険の引き受けチェックが

全面的にコンピュータで処理されるようになった

こうした変遷を経て、1990年代後半にはインター

ネットの業務活用を進め、代理店システムをWeb

ベースのシステムとして再構築する。その結果、個

人顧客はインターネット経由で保険料を試算し、簡

易な商品の申し込みが行えるようになった。また、法

人の従業員への保険募集もWeb上で行えるように

したほか、保険料比較サイト（損害保険各社の保

険料を比較するWebサイト）からの保険料試算の

要求に応答するシステム・サービスも開始した。現在、損保ジャパンのシステムは、図1に示すよう

なさまざまな利用者層に向けてサービスを提供して

いる。

システムの全体像と

開発の流れ

次ページの図2に示すのは、損保ジャパンの業

務で中核となる、保険契約の募集／計上／保全

と保険金支払いに関するシステムの全体像だ。基

幹系の保険システム（基幹保険システム）がメインフ

レーム上で稼働し、販売チャネルごとのシステム（社

内システム、代理店システム、コールセンター・システ

ム、個人顧客システムの4種類がある。本稿では、

これらを総称して「販売チャネル・システム」と呼ぶ）

がオープン系サーバ上に構築されている。この構成

を踏まえて、新商品の発売時には実際にシステム側

でどのような対応（システム対応）がとられるのかを説

明しよう。

●契約照会●試算

●計上

●事故

●成績

●人事

社員


●計上

●事故

代理店


●計上

個人顧客


●計上

法人顧客


●計上

共通の業務処理

システム連携

図1：損保ジャパンのシステムの利用者層


7/14/2019 IT Vol.21 00.pdf


再利用を実現する

アーキテクチャ

Part 1

各処理の概要

●契約照会：契約内容の現在／変更後の状態など、契約に関する情報を参照するための処理

●保険料試算：新規に保険契約を締結する場合と、保険契約を変更した場合のそれぞれについ

て保険料を試算する処理

●契約計上：新規保険契約の締結（新規計上）と、既存契約の内容変更（異動計上）を行う処理

●事故受：受け付けた保険事故を記録する処理

●支払：保険金額を確定して支払いを行う処理

●再保険：再保険契約の締結／管理／保険金請求を行う処理

●収納：保険料の収納を管理する処理

●販売管理：保険商品の販売成績を管理する処理

●更改申込書作成：近々契約期間が終了する契約を対象に、継続して締結する契約の候補とな

る補償内容で申込書を作成する処理

再保険

契約照会保険料試算

新規

保険料

異動

保険料

契約計上事故受

／支払

新規

計上

異動

計上

成績契約


新規

保険料

異動

保険料


新規

計上

異動

計上


新規

保険料

異動

保険料


新規

計上

異動

計上


新規保険料

契約計上

新規計上


新規保険料

契約計上

新規計上

契約照会事故受支払

事故受／支払

契約事故受

／支払

保険料収納

収納販売管理更改申込書

作成

●基幹保険システム●社内オンライン

●ステージング・データ

顧客

●CRMデータ

●代理店システム

●個人顧客システム●社外システム連携

●職域システム ●保険金支払いシステム

●コールセンター・システム●コールセンター・システム

＜各記号の凡例＞

矢印の意味

処理のリリース順

：処理連携

：リスク・アタッチ3カ月前にリリース

：データ連携

：リスク・アタッチ1カ月前にリリース

：リスク・アタッチ直前にリリース

図2：損保ジャパンの保険システムの全体像


7/14/2019 IT Vol.21 00.pdf


特集

2

保険会社の保険責任の開始を「リスク・アタッチ」

と呼ぶが、システム対応はこのリスク・アタッチを基準

にして行われる。リスク・アタッチの3カ月前には、更改申込書作成処理をリリースする。満了が近い既

存契約について、その契約を結んでいる顧客が新

商品に移行した場合の補償内容を試算するためだ。

リスク・アタッチの1カ月前には、新商品の販売が

始められるように、新規契約の保険料試算と契約

計上処理をリリースする。また、新商品の契約を計

上するには、その新商品に応じた保険料収納処理

を準備する必要があり、販売成績を管理する販売

管理システムでも新商品への対応を済ませておかな

ければならない。さらに、計上した新商品の契約内

容を参照できるよう、契約照会処理での対応も必

要となる。

リスク・アタッチの直前には、締結済みの契約の

変更を受け付けられるよう、異動保険料試算と異

動計上処理をリリースする。保険事故の発生を記

録し、保険金の支払いを行う事故受／支払処理

も稼働させなければならない。

なお、図1、図2に示したように、基幹保険システ

ムと販売チャネル・システムには、契約照会／試算／計上という共通の業務処理がある。上記の対応

に加えて、これらの共通処理の開発／リリースも、両

システムの担当者が歩調を合わせて行わなければ

ならない。

再利用の必然性

以上のように、損害保険事業では、新商品を発

売する際のシステム対応が多岐にわたるうえ、各処

理のリリース順とリリース時期も順守しなければならな

い。つまり極言すれば、システム開発のスピードが、

商品投入時期などのビジネス戦略にまで大きな影

響を与えることになる。しかし、個別のシステムごとに

設計／開発／テスト／リリース／保守という一連の

工程を実施していたのでは、開発工数がかさみ、開発要員も多く必要になるうえ、十分な開発スピー

ドが得られない。そこで損保ジャパンでは、経営のス

ピードにシステムの開発スピードを追従させるために

も、システム構成要素の再利用に注力してきたのだ。

アプリケーションの変更を

引き起こす3つの要因

ここまでの説明から、損保ジャパンではなぜ、再

利用への取り組みが必要だったのかがおわかりい

ただけただろう。以降では、再利用を実践するため

に、具体的にどのような仕組みを構築してきたのかを

解説していく。ただしその前に、アプリケーションの変

更を引き起こす要因と、それによってアプリケーション

に生じる変化、さらにそれらを踏まえてアプリケーション

のどの部分が再利用に適するのかを以下に述べて

おきたい。再利用対象のIT資産を選定するうえで

は、これに関する見極めが非常に重要になるからだ。

●技術の変化

アプリケーションに変更を引き起こす要因としてま

ず挙げられるのは、「技術の変化」だ。特にデバイス

技術（ここで言うデバイス技術には、端末機器だけ

でなく、その上で動作するリッチ・クライアントやWeb

ブラウザなどのクライアント技術も含む）の変化は早く、

そのバリエーションも多い。ここ10年あまりを見ても、

Webブラウザや携帯電話、PDA、アドビのFlashや

マイクロソフトのSilverlightに代表されるリッチ・クラ

イアント技術などが次に々登場してきている。メインフ

レーム用端末の時代が終焉を迎えた今、もはや1つ

の技術だけで10年持たせるのは不可能な状況だ。


7/14/2019 IT Vol.21 00.pdf




Part 1

また、印刷メディアも、紙からPDFへと移りつつある。

こうした変化の早いデバイス技術に追従していく

必要があるユーザー・インタフェース（UI）の部分は、再利用には向いていない。逆に、業務ロジックや

データベース周辺の技術は、UIに比べると変化が

緩やかであり、再利用に向いていると言える。

●利用者層の違い

「利用者層の違い」も、アプリケーションの変更を

促す大きな要素の1つだ。損保ジャパンの場合、オ

ンラインで提供するサービスの利用者は、社員、代

理店、個人顧客、法人の従業員、コールセンター

である。また、オンライン・サービスはさまざまなシステ

ムとも連携する。UIは、これらの各利用者層やシステ

ムの特性に応じて表現する必要がある。例えば、保

険契約に採番する証券番号の項目見出しは、業

務をよく知る社員向けの画面では、保険証書番号

を意味するPolicy Numberの略称をとり「PN」と

表示する。しかし、個人顧客向けの画面では、実

際の証券の券面上の表記に合わせて「保険証番

号」と表示しなければならない。

このように、UIは技術の違いのみならず、利用者

層の違いに応じても表現が異なるため、再利用には向かないのだ。

●商品の変化

アプリケーションの変更を引き起こす3つ目の要因

は、「商品の変化」である。保険商品には、認可

／約款／内規※1という商品ルールが階層的に定め

られている。先述したとおり、金融機関ではそれらの

商品ルールそのものが商品になり、業務ロジックとな

る。したがって、商品が変化すれば、当然ながら業

務ロジックの変更も必要になる。

しかし、主力商品にもなると、商品ルールを記載し

た文書の厚さは百科事典ほどにもなる。そうした商品の業務ロジックを担当する開発者は、膨大な

ルールを理解して設計できなくてはならないが、残念

ながら、このようなスキルを備えた人材は多くはなく、

速急に育成するのも困難だ。そのため損保ジャパン

では、業務ロジックを再利用することで開発効率の

向上を図っている。

アプリケーション・レイヤの

基本概念

それでは以降、損保ジャパンが構築した、再利用

を実現するための仕組みを具体的に解説していこう。

この仕組みで最も重要な概念は、「アプリケーショ

ン・レイヤ」だ。これは、再利用すべきIT資産を切り

分けるために、損保ジャパンが独自の基準で定めた

レイヤ構成である。アプリケーション・レイヤには、「FC

（Flow Control Logic）」、「PL（Presentation

Logic）」、「BL（Business Logic）」、「DA（Data

Access Logic）」という4つのレイヤがある。図3

に、各レイヤの概要と、それぞれの関係性を示す。

なお、各レイヤはあくまでも設計上の概念であり、

具体的なコンポーネントを指すわけではない。実際

の設計では、各レイヤを1つのコンポーネントとしても

よいし、複数の機能に分割したコンポーネントとしても

よい。このことを踏まえて、以下を読み進めていただ

きたい。

●“守るべき資産”のBLとDA

4つのレイヤの中で中核となるのはBLである。BL

は、商品ルールや事務処理ルールの処理を行うロ

ジックだ。図3にも記したように、損保ジャパンでは、

※1 認可とは、金融庁に申請して認可を受けた保険商品の内容のこ

と。また約款は、その保険商品が担保する保険事故や支払い条件など

について、あらかじめ作成した契約条項を指す。そして内規は、販売や

支払いに関する事務処理ルールを指す。


7/14/2019 IT Vol.21 00.pdf


特集

2

このBLをDA（およびデータ）とともに“守るべき資産”、

すなわち再利用すべき資産と位置づけている。

通常、商品ルールや事務処理ルールなどは、販

売チャネルごとに要件が異なってくる。例えば、保険

料試算処理の場合、社員向けシステムではあらゆ

る補償内容を試算できるようにし、個人顧客向けシ

ステムでは試算可能な補償内容を提供商品に応じ

て少なくするといった具合である。

損保ジャパンでは、このような販売チャネルごとの

処理に関して、フルスペックの機能を搭載した1つの

BLのみで対応している。具体的には、このBLに、認可／約款／内規のすべての処理を実装し、1回

の呼び出しで各処理が完結するように設計している。

これは、BLを、オンラインだけでなくバッチ処理でも

再利用するためだ。BLには、各販売チャネルやデ

バイスに非依存とするために、画面遷移の制御は

組み込まない。処理結果やエラーについては、文

字列を返すのではなく、コード値を返すようにする。

また、BLとともに“守るべき資産”となるDAは、

データベースなどのデータ・ストア固有の処理をBL

に持ち込まないために設けたレイヤである。業務処

理からデータ処理部分をDAとして切り離すことで、

BLをメインフレームとオープン系サーバのどちらでも

再利用できるようにしているわけだ。本来、再利用す

べきなのはBLとデータなのだが、データ処理のため

にはDAが不可欠であることから、DAも再利用の

範疇に含めているのである。

●再利用対象外のFCとPL

一方、BL/DAとは逆に、再利用の対象外となる

のがFCとPLだ。

このうちFCは、ユーザーに表示する画面の遷移

と、BLの呼び出しを制御するレイヤである。FCでは

まず、ユーザーがアプリケーションの操作権限を有しているかどうかをチェックする。また、Webベースの

オンライン・システムでは、ユーザーの操作によってア

プリケーションが対象としていない画面に移動するこ

とがあるため、想定外の画面である場合には適切

な画面に遷移させる処理も行う。そして、操作権限

と画面遷移のチェックをパスしたら、次にユーザー

の入力内容を単一項目のレベルで確認する。例え

ば、必須項目は入力されているか、入力文字は定

められた数値や文字の範囲内か、日付は妥当かと

いった具合だ。これらのチェックにパスし、入力内容

が単一項目レベルでクリーンになって初めて、BLを

FCBL DA

PL

販売チャネルと

デバイスの特性に対応

守るべき資産（再利用する資産）

PLとBLの流れを制御

業務処理を実装

対話画面を構成。帳票定義体もPL

各種デバイス

業務処理とデータ処理の分離

データ

図3：アプリケーション・レイヤの概念図


7/14/2019 IT Vol.21 00.pdf




Part 1

呼び出すのだ。

こうしたFCの機能により、BLは画面遷移の制御

から解放され、1回の呼び出しで処理を完結できるようになる。

一方、PLは、各利用者層やデバイスに対応した

画面を生成するロジックである。Webブラウザ向け

のHTMLの生成や、携帯電話の機種に応じた

マークアップ言語によるページ生成などは、このレイ

ヤが担当する。また、利用者層に応じて適切な内

容の画面を表示したり、BLの処理結果として渡さ

れたコード値を文字列に置換して出力したりするの

もPLの役割だ。これらの処理により、BLは利用者

層の違いやデバイスの違いから開放されるのである。

なお、このレイヤ構成では、帳票定義体も“表示だ

けを行うPL”と位置づけている。

FCとPLは、各利用者層やデバイスの特性を“守

るべき資産”の領域に持ち込まないために設けたレイ

ヤだ。この2つのレイヤについては、新たな利用者や

最新のデバイスに柔軟に対応していくために、最新

技術の取り込みを積極的に行うようにしている。

アプリケーション・レイヤの効果ここで、上記のような特徴を持つアプリケーション・

レイヤが大きな効果を発揮した事例を1つ紹介して

おこう。

旧安田火災、日本興亜損害保険、あいおい損

害保険は、2002年4月から代理店システムの共同

開発プロジェクトを進め、2003年4月に完成させた。

3社共同としたのは、開発コストを抑える目的からだ。

プロジェクトでは、まずすべてのアプリケーションを、

各社の個性が発揮できる競争領域のアプリケーショ

ンと、3社とも同じ設計となる（個性が出せない）非競

争領域のアプリケーションとに分類した。そして、競

争領域に該当する3社のアプリケーションの構成要

素を、アプリケーション・レイヤの考え方に基づいて

分析すると、それらの中から、共通化が可能なレイヤが浮かび上がってきたのである。

損保商品は、火災保険、傷害保険、賠償責任

保険などの基本となる保険の組み合わせによって出

来ており、各社それぞれの組み合わせと配分の違

いが商品ルールとなる※2。調査の結果、BL/DAの

中には、3社で共通の部分、つまり再利用できる部

分が存在していたのだ。

このように、アプリケーション・レイヤの仕組みは、

競合企業間における競争領域のアプリケーションの

一部を共通化することを可能にし、これがコスト削減

に大きく貢献した。

4レイヤ構成に基づく処理モデル

さて、アプリケーション・レイヤの基本概念は上に

述べたとおりだが、それを実際に適用したアーキテク

チャはシステムの特性や形態によって異なる。以下

に、どのようなアーキテクチャ（損保ジャパンでは、こ

れを「処理モデル」と呼んでいる）があるのかを解説しよう。

なお、各処理モデルは、テスト用のアプリケーショ

ンを用いて、あらかじめオンライン基盤上で機能／

性能の検証が行われる。したがって、アーキテクトが

アーキテクチャ設計を行う場合、目的に合った処理

モデルを選択すれば、検証の必要なく利用できる。

また、これらの処理モデルを使うことで、方式設計を

省略できるため、早期に開発に着手することが可能

※2 火災保険や傷害保険などとは反対に、自賠責保険（自動車損害

賠償責任保険）は国が定める制度保険なので各社の個性は出せず、そ

の処理を担うアプリケーションは非競争領域に分類される。


7/14/2019 IT Vol.21 00.pdf


特集

2

だというメリットもある。

●サーバ型Webオンラインとサーバ型リッチ・オ

ンライン

「サーバ型Webオンライン」と「サーバ型リッチ・オ

ンライン」は、前記4つのレイヤをすべてオープン系

サーバ上に実装し、各資産の再利用を図るという

処理モデルだ。損保ジャパンでは、Webブラウザや

携帯端末など、マークアップ言語を用いるデバイス

を想定した処理モデルを「Webオンライン」と称し、

リッチ・クライアント用の処理モデルを「リッチ・オンライ

ン」と呼んでいる。

図4に、それぞれの処理モデルを示す。Webオンラ

インのシステムとリッチ・オンラインのシステムはBL/DAに同一のものを使っており、FC/PLだけが異なる。

なお、WebオンラインのシステムではASP.NETを

使用しており、実装としてはFC/PLが1つのクラスに

なる。そのため、図4では1つのシンボルとして記した。

その他のレイヤについては、先述した基本構成から

異なる部分はない。

一方、リッチ・オンラインのシステムでは、FCの一

部とPLがWebアプリケーションとしてクライアント側に

置かれる。FCは、クライアント側で画面を制御する

部分（PFC：PL Flow Control Logic）と、サーバ

側でBL呼び出しを制御する部分（BFC：BL Flow

Control Logic）とに分割して設計する。

●ホスト型Webオンラインとホスト型リッチ・オン

ライン

次に、図5に示すのは、「ホスト型Webオンライン」

と「ホスト型リッチ・オンライン」の処理モデルだ（損保ジャパンでは、メインフレームを「ホスト」と呼んでい

る）。これらは、PL/FCをオープン系サーバ上に、

BL/DAをメインフレーム上に実装するという構成で

クライアントアプリケーション・サーバデータベース・サーバ

DABL

BFC

PL/FC

リッチ・クライアント

PL/PFC

Webブラウザ

図4：サーバ型Webオンラインとサーバ型リッチ・オンラインの処理モデル

クライアントアプリケーション・サーバメインフレーム

BFC

PL/FC


PL/PFC

Webブラウザ DABL

図5：ホスト型Webオンラインとホスト型リッチ・オンラインの処理モデル


7/14/2019 IT Vol.21 00.pdf




Part 1

ある。この構成をとるのは、メインフレーム上のIT資

産を再利用するためだ。

●非同期オンライン「非同期オンライン」は、オンラインで受けたユー

ザーからのリクエストを非同期で処理するという処理

モデルだ。ユーザーからのリクエストを受け取り、そ

の際にユーザーにはリクエストを受け付けた旨を返

すが、実際の処理はクライアントの画面とは同期せ

ずに実行する（図6）。

この処理モデルでは、実行する処理が軽く、オン

ライン・システムのレスポンスに影響がない場合はアプ

リケーション・サーバで、処理が重い場合は専用

サーバで実行する。それぞれのケースに応じてFC

の名称／機能を変えており、アプリケーション・サー

バ内のFCは「AFC（Asynchronous FC）」、専

用サーバ内のFCは「DFC（Dedicated FC）」と呼

ぶ。このうちDFCは、未処理のリクエストを取り消し

たり、処理時間にタイムアウトを設定したり、同一

ユーザーからの要求をシリアルに実行したりといった、

AFCにはない機能を備えている。

●スケジューラ型バッチ

アプリケーション・レイヤの考え方は、バッチ処理に

も適用している。その処理モデルを「スケジューラ型バッチ」と呼ぶ（図7）。

損害保険業務のバッチ処理には、ある一群に対

して同一の処理を適用するものが多いという特徴が

ある。例えば、更改申込書の作成を行うバッチ処理

は、満了が近い契約を対象に、現在の契約と同じ

補償内容と、新たに顧客に提案する補償内容のそ

れぞれについて保険料を計算し、各更改申込書を

作成する。この処理では、オンライン・システムで使用

している保険料計算のBLが再利用できるので、そ

のBLを対象の契約数だけ繰り返し実行すればよい。

この繰り返しの処理は、「JFC（Job Flow Control

Logic）」というレイヤにあるプログラムで制御している。


適用範囲

損保ジャパンでは、以上に紹介したアプリケーショ

クライアントデータベース・サーバアプリケーション・サーバ

AFC BL

PL/FC キューWebブラウザ

専用サーバ

ランチャ

DA

DFC BL DA

図6：非同期オンラインの処理モデル


7/14/2019 IT Vol.21 00.pdf


特集

2

ン・レイヤの仕組みを、1990年台後半から適用して

きた。当時、スタンドアロンPCで展開していた代理

店システムからメインフレームに直接計上する機能を

開発することになり、その際、メインフレーム上のアプ

リケーションの一部（保険料計算と規定チェック処

理）をBL/DAとして再構築したのが始まりだ。その

他のメインフレーム上のアプリケーションも、社内オン

ラインをWeb化（これについてはPart 2で紹介する）

するタイミングですべてBLに準じた構造に変更した。また、オープン系サーバ上のすべてのアプリケーショ

ンは、もともとアプリケーション・レイヤにのっとって開発

している。

なお、アプリケーション・レイヤの概念は、特定の

アプリケーションだけに適用するのではなく、すべての

アプリケーションに対して適用している。これは、「社

内の全アプリケーションが1つの技術標準の下に作

られていることは、ビジネス環境やIT技術の変化に

強いシステムを生む」、「どのようなビジネス戦略が

策定されても即座に対応できるように、すべてのIT

資産を再利用可能な状態にしておく」という2つの考

えに基づいている。

損保ジャパンではこのように、アプリケーション・レ

イヤによって“守るべき資産”を活用しているわけだが、

最終的に目指しているのは次ページの図8に示すよ

うなモデルだ。このモデルでは、アプリケーション・レイ

ヤの考え方に沿って開発した“守るべき資産”を、各

種の処理モデルで共通に再利用することを目指す。

今後、FCレイヤにBPM（Business Process Ma

nagement）製品を導入することも検討しているが、図8のモデルを実現すれば、それも難しくはないだろ

う。アプリケーション・レイヤの概念の下、画面遷移

やBLの呼び出しを制御するFCレイヤは、ビジネス・

プロセスの制御層だと見ることもできるからだ。

運用要件に応じたメンテナンス

さて、ここからは少し話題を変え、損保ジャパンが

再利用の対象とした資産をどのようにメンテナンスし

ているのかを説明する。まずは、具体的な変更／

配置の方法を紹介する前に、システムの運用要件

バッチ・サーバ

ホスト型

サーバ型

メインフレーム

JFC BL

バッチ・サーバデータベース・サーバ

DA

JFC BL DA

スケジューラ

スケジューラ

図7：スケジューラ型バッチの処理モデル


7/14/2019 IT Vol.21 00.pdf




Part 1

について述べておきたい。

損保ジャパンでは、運用の対象範囲として、運

用担当者が「サイト」を設定し、さらにそのサイトの中

に「仮想システム」を定めている。仮想システムとは、

アプリケーションやシステムのメンテナンスを実施する

単位であり、サービス提供時間ごとに分割される。

このように分割するのは、システム障害によるサービ

ス停止の範囲を限定するためだ。

仮想システムには、販売チャネルに応じて「社

内」、「コールセンター」などいくつかの種類があり、

それぞれの運用要件を次のように定めている。

●社内仮想システム：サービス提供時間は、損保

ジャパンの営業日である8時〜22時●コールセンター仮想システム：コールセンターは

電話での問い合わせに24時間対応しているが、

3時〜6時は着電数が少ないので、この時間帯

にはアプリケーションのメンテナンスが可能。その

ため、コールセンター仮想システムのサービス提

供時間は、6時〜27時（翌3時）としている

●代理店仮想システム：24 時間 365日、常にサー

ビスを提供している。利用者である代理店には

サービス停止を周知させることができるので、オン

ライン・アプリケーションの変更は計画停止を実

施して行う

●個人顧客仮想システム：個人顧客仮想システム

のサービス提供時間も、24時間365日としている。

ただし、個人顧客に対してはサービス停止を周

知することができないため、さまざまな工夫を凝ら

し、サービスを止めずにアプリケーションのメンテナ

ンスを行っている

なお、損保ジャパンは近年、企業全体として顧

客サービスの向上を目指しており、システムのサービ

ス提供時間が長期化する傾向にある。このため、メ

ンテナンス時間の確保がさらに難しくなってきている。

ライブラリ管理システムと

配置反映システム

上記のように、仮想システムごとに異なる運用要

件を定める中で、アプリケーションのメンテナンスを効

率的に行うための仕組みとして導入しているのが、

「ライブラリ管理システム」と「配置反映システム」だ。

これらのシステムを用いてアプリケーションを変更／

配置する際の手順を、自動車保険の内規に関する

事務処理ルールを実装したBLコンポーネントを例に

とって説明しよう（以降の解説と併せて、図9も参照

されたい）。

まず開発者は、該当するコンポーネントのソース・

コードをライブラリ管理システムから取り出して変更す

守るべき資産

DABL

DFC

AFC

PL/FC

BFCPL/PFC

JFC

PL/FC

キュー

同期型オンライン

非同期型オンライン


スケジューラ型バッチ

図8：守るべき資産を活用するための究極のアーキテクチャ


7/14/2019 IT Vol.21 00.pdf


特集

2

る。次に、ライブラリ管理システムに変更後のソース・

コードを登録して、コンポーネントの配置先を定義す

る。コンポーネントの配置先の候補は、社内仮想システムとコールセンター仮想システム、代理店仮想シ

ステム、個人顧客仮想システムのそれぞれに存在す

るアプリケーション・サーバと非同期処理サーバだ。

配置先が定義されたら、各サイトの運用担当者は、

仮想システムごとに定められたアプリケーション反映

時刻に配置反映システムを操作する。そして、配置

反映システムにより、開発者が定義した配置先に対

して対象コンポーネントが配置されることになる。

こうして極力自動化したメンテナンスの仕組みによ

り、オンライン・サービスを実施しながらコンポーネント

を配置することが可能になっているのだ※3。

＊＊＊

以上、本パートでは、損保ジャパンの再利用に

対する考え方やアプリケーション・レイヤの基本概念、

各処理モデルの構成、メンテナンスの方法などを解

説した。続くPart 2では、こうした再利用の仕組み

を確立するまでの経緯や、ガバナンスに関する施策

などを紹介する。

※3 ただし、データを変更する場合には、そのデータに関連する処理

のサービスを停止しなければならないこともある。

サイトA（アウトソース先1）サイトB（アウトソース先2）

アプリケーション・プログラムに配置先定義を付加して配布する

社内仮想システム（8：00∼22：00）

アプリケーション・サーバ

非同期サーバデータベース・サーバ


BL BL BL BL BL BL BL

BL BL

コールセンター仮想システム（6：00∼27：00）




開発者PC

ライブラリ管理システム


BL BL

代理店仮想システム（24/365 計画停止あり）





BL BL

個人顧客仮想システム（24/265 ノンストップ）





BL BL

BL BL

配置先定義●社内仮想システム：アプリケーション・サーバ、非同期サーバ

●コールセンター仮想システム：アプリケーション・サーバ、非同期サーバ

●代理店仮想システム：アプリケーション・サーバ、非同期サーバ

●個人顧客仮想システム：アプリケーション・サーバ、非同期サーバ

配置反映

システム

配置反映

システム

配置反映

システム

配置反映

システム

図9：具体的な実装形態と運用方法


7/14/2019 IT Vol.21 00.pdf


Part 2

再利用に向けた取り組みの変遷

本パートでは、まず損保ジャパンがどのような経緯

を経て再利用の仕組みを構築してきたのかを、これまでに取り組んだ開発プロジェクトを交えて説明する。

なお図1に、1990年代から2000年代にかけて同社

が実施してきたプロジェクトを示すので、これも参照

しつつ読み進めていただきたい。

再利用への気づき

損保ジャパンの前身となる旧安田火災は1996年、

旧アイ・エヌ・エイ生命保険から業務の代理と事務

の代行を請けるという方法によって生保事業に参入

した。これに伴い、当時スタンドアロンPCで展開して

いた代理店システムに対して、生損保商品のクロス

セル※1を支援するツールを提供することになった。

IT部門は、ツールを開発するために生保商品の

学習から始めたが、その膨大な知識を身に付けるだ

けでも大変な作業だった。さらに、開発過程では大きな問題も発覚する。生保商品の解約返戻金の

計算において、数万件に1 件の割合で違算が生じ

ていたのだ。解約返戻金は、保険募集時に試算し

て顧客に提示するものである。1円単位で正確に算

出する必要があり※2、契約前の価格（代理店システ

ムで試算）と契約後の価格（メインフレームで計算）

が少しでも違っていてはならない。

※1 特定の商品を販売する際に、関連する商品も同時に提案すること。

※2 当時のアイ・エヌ・エイ生命の商品は無配当のものが主流であり、

それらの商品の解約返戻金は配当を含まない。そのため、将来の解約

返戻金を円単位で確定できる。結果、違算は円単位で発生していた。

取り組みのきっか

けと、

再利用を推し進

めるための

ガバナンス施策、保守／運用体制

損保ジャパンでは、Part1で紹介した再利用のための

アーキテクチャを策定し、実際に広く活用している。

再利用に関しては、仕組みを考えるのと同じかそれ以上に、

仕組みを浸透させ、

統制していく取り組みが難しいと言われる。

本パートでは、まず損保ジャパンが再利用の仕組みを

構築するに至った経緯を述べたうえで、

その仕組みを浸透させるために同社が導入した

ガバナンス施策や保守／運用体制などを紹介する。


7/14/2019 IT Vol.21 00.pdf


特集

2

調査の結果、メインフレームで使っているCOBO

Lと、代理店システムで使っているPC上のプログラミ

ング言語との間で数値変数の精度に差があること

が原因だと判明する。これを踏まえて、まずメインフレームと同じ計算精度を持つPC向けのCOBOLプ

ログラム実行環境を導入し、そのうえでメインフレーム

から抽出した解約返戻金の計算プログラムをPCで

再利用して問題の解決を図った。これが、損保

ジャパンが再利用の道に踏み出した第一歩である。


検討を始めたきっかけ

1990年代後半には、Part 1で説明したように、ス

タンドアロンPCで展開する代理店システムからメイン

フレームへと、契約を直接計上する機能を開発する

ことになる。先のクロスセル・ツールの開発では業務

知識の習得が大変だった点や、メインフレームとPC

との間で違算が生じた点などを考慮し、このプロジェ

クトでは当初からメインフレーム上のCOBOLプログラムを再利用する方針をとった。

ここでまず取り組んだのは、保険料計算と規定

チェック処理をBL/DAの役割に分離して再構築

することだ。次に、COBOLで記述されたBL資産を

PCでも使えるようにコンパイルし、RDBMSに接続す

るためのDAも開発して、双方をPC上に配備した。

これで、基幹保険システムと代理店システムで同じ

BLを使えるようになったのだ。

また1998年には、近い将来インターネットの商用

利用が進み、保険商品もWeb上で販売するように

なるとにらんで、新技術開発チームを編成する。この

1990年代

▲生命保険事業参入 ▲損害保険ジャパン（2002年7月合併）

会社沿革

メインフレーム系

オープン系

2000年 2001年 2002年 2003年 2004年 2005年 2006年 2007年 2008年 2009年

▲国内リテール分野の成長戦略策定

▲手書きOCRシステムによる営業店計上の開始

▲サービス・センター・システム刷新

▲代理店システムから直接計上開始

▲本社部門データ・ウェアハウス活用開始


▲顧客データベースをサーバに移行


▲第1 世代Webオンライン基盤稼働

▲Web型代理店システム稼働

▲アライアンス型代理店システム稼働


▲第2世代Webオンライン基盤稼働

▲メール掲示板稼働開始

▲システム統合（2002年7月）

▲社内オンラインがWebベースに移行完了

ダム端末型オンライン

クライアント／サーバ型オンライン

Web型オンライン

リッチ・クライアント型オンライン

アプリケーション・レイヤの発展

アプリケーション・レイヤの確立

図1：損保ジャパンにおける再利用への取り組みの歴史


7/14/2019 IT Vol.21 00.pdf


再利用推進のための

施策と体制

Part 2

とき、Webのノウハウを習得するために、JCL自動生

成システムをWebベースのオンライン・システムとしてリ

プレースすることになった。このプロジェクトで問題となったのは、HTMLとビ

ジネス・ロジックが混在したプログラムの開発は容易

ではなく、保守性はCOBOLプログラムよりも著しく劣

るという点だ。この問題への対処を考える中で、アプ

リケーション・レイヤのFC/PLの概念が生まれた。

アプリケーション・レイヤの確立

1999年、リニューアルが予定されていた保険金

支払いシステムと手書きOCRシステムを支える基盤シ

ステムとして、第1世代Webオンライン基盤の検討に

着手した。「経営が要求するスピードにシステム開

発を追従させる」ことが、その基本コンセプトである。

第1世代Webオンライン基盤は、その名のとおり、

Webベースで開発することになった。今後は、イン

ターネットの業務利用が本格的に進むだろうとの判

断からだ。このWeb技術の採用に代表されるように、

当時は販売チャネルやデバイスの種類が急増してお

り、その動きに対応するために新たな仕組みと方法

論が必要になった。このとき、それまでの経験を総合して整備したのがアプリケーション・レイヤである。

ここで確立したアプリケーション・レイヤに沿って各

種アプリケーションを開発し、第1世代Webオンライ

ン基盤は、それらのアプリケーションを再利用できるよ

うに設計した。この基盤と、リニューアルした保険金

支払いシステム、手書きOCRシステムは、2001年に

カットオーバーを迎える。

また、第1世代Webオンライン基盤の開発と並行

して、Webベースの代理店システムの構築にも取り

組んでいる。これは2002年にリリースされ、2003年に

はアライアンス型代理店システムへと発展していく。

メインフレーム資産の大改修

アプリケーション・レイヤの考え方に従い、メインフ

レーム上にあるIT資産を大改修したのが2003年から始まったプロジェクトである。このプロジェクトは、2

年をかけて約500メニューある社内オンラインをWeb

化するというものだ。

ここで、損保ジャパンのオンライン・サービスの変

遷について簡単に説明しておこう。

損保ジャパンでは、かつて社内オンラインを利用

するのにダム端末を用いていた。その後、社内オンラ

インを全社に展開する際、メインフレームの負荷軽

減のために中継器を使うように発展させ、1990年

代半ばには中継器機能とオンライン・エミュレータを

クライアント／サーバ型の基盤に置き換えている。こ

のように基盤を変更してきたわけだが、そうした際に

重視されたのはアプリケーションに影響を及ぼさない

ことだ。そのため、当初からオンラインのアプリケーショ

ンには、大きな変更が入ることはなかった。

そして、2003年ごろに、社内オンラインをWebベー

スのシステムへと作り替えるために検討を開始する。

その際、これまでと同様にアプリケーションは変えない

よう基盤機能を作り込んで対応するか、将来をにらんでアプリケーションに手を入れるかで議論になった

が、結果的に後者の意見が採用され、アプリケー

ションを再利用できるよう改修することが決まったので

ある。

ただし、当時のアプリケーションには、Web上で稼

働させるには問題があった。図2に、改修前のメイン

フレーム上のIT資産がとっていたアーキテクチャを

示す。これらの資産は、端末とのセッションが維持さ

れることを前提に作られており、プログラム内部に状

態（ステート）を保持していたため、1回の呼び出しで

は処理が完結しないようになっていた。また、1件のリ


7/14/2019 IT Vol.21 00.pdf


特集

2

クエストについて、画面とプリンタのそれぞれに対して

リターンが発生する。こうしたアーキテクチャのままで

は、Web上でオンライン・サービスとして利用するの

は不可能だったのだ。

この問題を解消するため、メインフレーム上のすべ

てのオンライン用プログラムについて、プログラムの中

に状態を持たないよう、また1件のリクエストに対して

1件だけリターンするよう改修を加えた。図3に示す

改修後のアーキテクチャから、アプリケーション・レイ

ヤの概念に沿って再構築していることがおわかりい

ただけるだろう。

アプリケーション・レイヤの発展

以上の活動を通じてアプリケーション・レイヤの整

備が徐々に進んできたが、それを一気に発展させる

きっかけとなったのが、次に紹介するプロジェクトだ。

データベース

入力内容チェックシノニム画面表示、データベース・アクセス

ビジネス・ロジック、データベース・アクセス

結果画面表示プルーフ印刷、プリンタ出力

プリンタ端末

帳票マップ画面マップ

中継器

メインフレームメイン・プログラム

中継装置プログラム

端末とのセッションを維持するステートフルなものがある

1つの入力に対して複数の出力が発生する（HTTPでは、1リクエストに対して1リターンとする必要がある）

図2：改修前のメインフレーム上の資産

データベース

入力内容チェックシノニム画面表示、データベース・アクセス

ビジネス・ロジック、データベース・アクセス

結果画面表示プルーフ印刷

プリンタ端末

Webサーバ

メインフレームメイン・プログラム

FCPL1リクエスト1リターンとなるように変更

ステートレスとなるように変更

シノニム画面COPY句画面表示COPY句帳票出力COPY句

図3：改修後のメインフレーム上の資産


7/14/2019 IT Vol.21 00.pdf



施策と体制

Part 2

2005年ごろ、上述した第1世代Webオンライン基

盤を構成するプラットフォーム製品の寿命に限界が

見え始めていた。そこで、寿命が切れるまでに後継のオンライン基盤を構築すべきだと判断し、第2世代

Webオンライン基盤の構想に着手した。

このときにはすでに、メインフレーム上の資産もオー

プン系サーバ上の資産も、かなりの数をアプリケー

ション・レイヤに従ったアーキテクチャで開発してきて

おり、社内のIT 資産は大半が再利用可能な状態

にあった。このことを踏まえて、第2世代Webオンライ

ンのプロジェクトでは、「ベスト・プラクティスの再利

用」をコンセプトに掲げ、社内外の資産の再利用を

さらに推し進めることを目指した。

このプロジェクトで特に気を配ったのが、第2世代

Webオンライン基盤上に置かれるアプリケーション／

ミドルウェアを、OS／ハードウェアに非依存なものと

するということである。第1世代Webオンライン基盤は

OS／ハードウェアに依存していたため、それらを更

改する際には、アプリケーション／ミドルウェアの変更

や、膨大なリグレッション・テストが必要であった。こ

れらの負担を軽減するために、第2世代ではアプリ

ケーション／ミドルウェアをOS／ハードウェアから独立させ、.NET Frameworkのみに依存するよう変

更したのである※3。

また、第2世代Webオンライン基盤には、以下に

挙げるようなさまざまな改良や工夫を盛り込んだ。

●オブジェクト指向手法を駆使して、アプリケーショ

ン内部に基盤ロジックを記述しなくても済むように

した。基盤ロジックとアプリケーション・ロジックを

分離したことで、開発者がアプリケーション部分

だけに注力できるようになったほか、アプリケーショ

ンの可搬性も高まった●アプリケーション実行時に、基盤機能を動的に組

み込む方式を採用した。これにより、監査ログの

出力など、すべてのアプリケーションが一律に備え

なくてはならない機能を、アプリケーションの改変

なしに組み込めるようになった

●社外のサービスを利用できるように、Webサービ

ス技術を導入した

●Webベースの画面では複雑な業務画面を実現

できないという不満を解消するために、リッチ・クラ

イアント技術を採用した

●第1世代Webオンライン基盤にはなかった新しい

処理形態として、非同期処理を実現した

●アプリケーションの利用状況や性能情報、障害

情報を開発担当者に直接フィードバックする機

能を搭載し、運用品質の向上を図った

●再利用するコンポーネントの保守性を高めるため

に、それらのコンポーネントをどのように分散配置し

たのかを把握するための機能を追加した

●データ項目を格納するコンテナとしてビジネス・エンティティを定義した。保険業務には扱うデータ

項目が多いという特性があるが、契約の単位、あ

るいは保険金支払いの単位をビジネス・エンティ

ティとして定義し、それらの中にデータ項目を格納

することで、コンポーネント間のインタフェース設計

を簡素化することができる

なお、このプロジェクトの実施にあたっては、同一

のプログラムに対する複数の変更を並行して行える

ように、ライブラリ管理システムの機能も強化している。

そして昨年2月には、保険金支払いシステムを刷

新し、第2世代Webオンライン基盤上で稼働させて

※3 そのほかに、第1世代 Webオンライン基盤には、OSとハードウェ

アのサポート期間が異なるという問題もあった。双方のサポート期間が

一致していないと、OSに対応したハードウェアが調達できなくなったり、

ハードウェアのサポート終了前にOSのサポート期限が到来してしまったり

することがある。


7/14/2019 IT Vol.21 00.pdf


特集

2

いる。この新たな保険金支払いシステムでは、業務

担当者が保険金請求者と電話機を手にしながら保

険事故の内容を記録できるよう、良好な操作性を実現する必要があった。また、保険事故の写真を

表示して、支払うべき保険金額を判断しつつ結果

を入力できるようにすることも求められた。こうした要

件に対応するために採用した処理モデルが、Part

1で紹介したホスト型リッチ・オンラインである。

ちなみに、保険金支払いシステムの刷新では、第

1世代Webオンライン基盤上に構築されていた旧シ

ステムを、第2世代Webオンライン基盤上で改善しつ

つ再構築するという方法をとったが、旧システムはア

プリケーション・レイヤに従って開発していたため、再

構築する部分はほぼFC/PLだけにとどめることがで

きた。

再利用推進のためのガバナンス

以上に説明した経緯を経て、損保ジャパンではアプリケーション・レイヤの仕組みを確立／発展させ

てきた。ただし、ただ単にこの仕組みのコンセプトを

打ち立てるだけで、再利用の取り組みが自動的に

進んだわけではない。設計から実装に至るまで再利

用の活動を浸透させるために、「技術標準」、「教

育プラン」、「開発環境の仕掛け」を用意し、それら

も同時に推進してきたのだ。以下に、これら3つの取

り組みの概要を紹介する。

技術標準

表1に示すのは、損保ジャパンが策定している技

術標準の一部である。この技術標準は、システム

表1：損保ジャパンが定める技術標準の例

技術標準の種類技術標準の例

●開発工程ガイド

●開発環境本番後の後処理

●ドキュメント標準

●サンプル設計書

●設計ガイド

●設計チェックシート

●リソース・ネーミング標準

●コーディング標準

●コーディング・チェックシート

●コーディング・ガイド

●ライブラリ管理操作マニュアル

●配置反映操作マニュアル

●開発ツール操作マニュアル

●開発ツール用入力ファイル

●べからず集

●テスト・ガイド

●フィードバック操作マニュアル

●機能分析マクロ操作マニュアル

●アスペクト設定ガイド

●アスペクト設定GUI操作手順書●アプリ資源取得申請

●ライブラリ管理システム臨時使用申請

その他の技術標準 ●FAQ集

開発関連の技術標準

設計関連の技術標準

コーディング関連の技術標準

各種ツール関連の技術標準

開発／テスト／運用での品質

向上を目的とした技術標準


7/14/2019 IT Vol.21 00.pdf



施策と体制

Part 2

開発に携わる社員と協力会社の要員が利用する。

技術標準の中で要となるのは「設計ガイド」だ。

このドキュメントには、アプリケーション・レイヤの基本概念と各種処理モデルに始まり、さまざまな基盤

サービス、そして処理モデルごとの設計ポイントなどが

まとめられている。初めて損保ジャパンのシステム環

境で開発を行うエンジニアでも、設計ガイドを読め

ば何が準備されており、どのように設計すればよい

のかがわかるようになっている。

技術標準には、設計ガイドのほかにも次のような

ドキュメントが用意されている。

●ドキュメント標準：設計書の記述ルールを定めた

もの。このルールに従って記述すれば、第三者

が設計書を見たとき、どの部分が再利用した資

産なのかがすぐにわかるようになっている

●サンプル設計書：各種の技術標準にのっとった

具体的な設計例を示している

●コーディング標準：ソース・コードの保守性を高く

保つためのコードの記述方法を定めるとともに、シ

ステムのリソースと性能に悪影響を及ぼすコーディ

ングの仕方を“禁じ手”としてまとめている

●べからず集

：設計／コーディング／テスト／運用の各局面における失敗経験をまとめたドキュメント

●FAQ集：エンジニアから寄せられた質問を分類し

たもの。知識の共有を図るのが目的

教育プラン

損保ジャパンでは、実装技術と設計手法に関す

る教育プランを準備し、研修を行っている。特に設

計手法については、再利用を実現するうえで核とな

るスキルとして重視しており、その研修は社員のみな

らず協力会社の要員に対しても実施している。

研修を受けたエンジニアは、研修終了後に最初

に担当する開発業務において、要件定義／設計

／コーディングの各局面で数回の OJT（On the

Job Training）を受けることになる。また、2度目の開発業務では、設計書とソース・コードのレビューを受

ける。

単に研修を実施するだけでなく、その後に繰り返

しOJTを行うことで、知識／スキルの定着を図って

いるのだ。

開発環境の仕掛け

開発環境については、Part 1で紹介したライブラ

リ管理システムが、再利用の実践において重要な

役割を担う。

またそのほかに、アプリケーション・レイヤごとにコン

ポーネントのテンプレートを準備している。このテンプ

レートには、アプリケーションの実行時に動的に組み

込まれる共通の基盤機能が組み込んである。つまり、

このテンプレートを使えば、アプリケーションの開発者

は、共通の基盤機能をコーディングする必要がなく

なるというわけだ。

さらに、統合開発環境（IDE）のコンパイラとビル

ド・サーバ（コンポーネントの最終コンパイル環境）には、静的コード・チェック機能を組み込んでいる。こ

の機能は、コーディング標準で定めた規約に違反

したコードを検出するためのものだ。こうした機能によ

り、再利用するコンポーネントの品質を高めるよう努

めているのである。

アプリケーション・レイヤに応じた

保守／運用体制

続いて、損保ジャパンが再利用対象のIT資産を

どのように保守しているのかを紹介する。


7/14/2019 IT Vol.21 00.pdf


特集

2

各アプリケーション・レイヤには、それぞれ開発／

保守を担当する主体（オーナー）が存在し、責務が

ある。この責務を「オーナーシップ」と呼んでいる。

オーナーには、「オンライン・オーナー」、「BLオー

ナー」、「データ・オーナー」の3種類がある（図4）。

それぞれのオーナーシップは次に述べるとおりだ。

●オンライン・オーナー：販売チャネルとデバイスの

特性に応じたFC/PLの開発を担当する。また、

ユーザーに最も近いレイヤを担当するので、ユー

ザーからの問い合わせに対応したり、BLオー

ナーやデータ・オーナーと協業しながら障害の対応にあたったりする

●BLオーナー：BLをさまざまな販売チャネルとデバイ

スで再利用できるように開発し、オンライン・オー

ナーに提供する

●データ・オーナー：データの整合性とデータ処理

の性能が保証されたDAをBLオーナーに提供す

る

では、これらのオーナーシップに基づき、実際にど

のような運用体制を組み、開発を行っているのか。

基幹保険システムでも販売チャネル・システムでも、

それぞれの担当部署が各システムについて3 種類の

オーナーを担っている。もし、ある販売チャネル・シス

テムの担当部署が、特定の要件に応じて基幹保険

システムのBLオーナーやDAオーナーに再利用可

能なコンポーネントの提供を依頼したとしよう。すると、

依頼を受けたオーナーは、要求された機能要件と

運用要件に見合ったコンポーネントを新規開発した

り、既存のコンポーネントから再利用可能なコンポー

ネントを選んだりして提供する。一方、各販売チャネ

ル・システムに固有の処理については、そのシステム

のオーナーが開発する。

こうした運用体制は、販売チャネルが多様化していく中で、現場が考え出したものだ。そして、多くの

プロジェクトをこなすうちに、徐に々定着していったの

である。

再利用を実現させた

2つのキーポイント

以上、本特集では、損保ジャパンの基幹システ

ムにおけるIT資産再利用の概要とノウハウを紹介し

てきた。最後に、約10年にわたるこの取り組みの中

で、特に鍵となった2つのポイントを紹介したい。

FC

BL DA

PL

オンライン・オーナー BLオーナー DAオーナー

●FC/PLを販売チャネルとデバイスの特性に対応させる●問い合わせと障害への対応

各種デバイス

データベース

各種販売チャネルとデバイスで使い回せるようにBLの機能を開発する

データの整合性とデータ処理の性能を保証したDAを提供

図4：アプリケーション・レイヤのオーナーシップ


7/14/2019 IT Vol.21 00.pdf


Part 2


施策と体制

特集

2

まず1つ目のキーポイントは、「アプリケーション設

計の標準（Standards）」を確立し、それにのっとっ

てアプリケーションを築いてきたことである。コンセプトを打ち立てて設計原則を確立し、それに従ってアプ

リケーションを設計して、標準基盤上で動作するコ

ンポーネントを開発する――こうした取り組みを継続

してきた結果、メインフレーム／オープン系サーバ上

のBLの“品ぞろえ”が整い、BLを容易に再利用でき

るようになったのだ。

2つ目のキーポイントは、「アーキテクチャ設計／

IT投資の原則（Principles）」を貫き、場当たり的

な対応でアーキテクチャを汚さなかったことである。

アーキテクチャ設計については、「新規のチャネル・

システムは標準基盤上に構築する」というコンセン

サスを形成し、アーキテクチャの乱れを防止した。

また、「再利用を推進するための取り組みには、積極的に投資する」というIT投資に関する原則も活

用されている。例えば、メインフレーム上のすべての

アプリケーションをBL 化するという取り組みは、短

期間での投資対効果が見えづらく、経営層として

はゴーサインを出しにくいものだろう。しかし、損保

ジャパンでは、上の原則に基づき、そうした取り組

みに対しても「投資をする」という経営判断がなさ

れている。この原則により、アーキテクチャを再利用

に適したかたちへと、スムーズに発展させることがで

きたのだ。

今後の課題は「基幹保険システムのサービス提供時間延長」

ここでは、損保ジャパンのシステ

ムが現在抱えている課題と、その解

決に向けた今後の取り組みを簡単

に紹介してみたい。

本文中でも述べたとおり、近年は

販売チャネルの多様化が著しい。それに伴って販売チャネル・システム

が増加するのに従い、基幹保険シ

ステムのオンライン・サービスの提供

時間に制約があることが課題として

浮上してきた。

基幹保険システムのオンライン・

サービスは販売チャネル・システムと

も連携しており、ユーザーはそれぞれ

の販売チャネル・システムを通じて、

基幹保険システムが保持するデータ

の参照／更新などを行っている。そ

して近年、各販売チャネル・システ

ムのサービス提供時間は長期化す

る傾向にある。24 時間サービスを

提供するシステムも出てきているほ

どだ。そのため、基幹保険システム

のオンライン・サービスには、販売

チャネル・システムのサービス提供

時間に合わせて、より長く稼働する

ことが求められるようになっている。

しかし、基幹系アプリケーション

（基幹保険システムのアプリケーショ

ン部分）は長年、「オンライン処理時間とバッチ処理時間の運用は区別

する」という前提で開発されてきた。

つまり、バッチ処理の間は、オンライ

ン・サービスを提供できないように

なっているのだ。この問題に対処す

るために、基幹保険システムが処理

／管理しているデータをバッチ処理

の最中だけオープン系サーバ上の

データベースへと切り離し（この切り

離したデータは「ステージング・デー

タ」と呼ばれる）、24時間の運用に

も堪えられるようにしている。

ただし、これだけでは不足がある。

現状のステージング・データは参照

しかできず、ユーザーが更新を行った

としてもオンライン・サービスが再開

するまでは内部的に蓄積され、実際

の更新処理は保留されるからだ。

この「リアルタイム更新ができな

い」という点は、契約者に対する

サービス・レベルの観点では好ましく

ない。例えば、最近転居した契約者

が、住所変更の手続きを行うためにコールセンターに連絡したとする。そ

れがちょうど、オンライン・サービスで

の更新ができない時間帯だったとき

には、基幹保険システム上のデータ

はバッチ処理が終わるまでは新住所

に変更されない。その状態で、先ほ

どの契約者がインターネットで自分

の契約内容を照会したら、当然、そ

のときに表示される住所は更新前の

ものとなる。これを見た契約者は、

「先ほどの変更手続きはきちんと処

理されたのだろうか？」と不安を抱くか

もしれない。

こうしたケースも勘案し、損保ジャ

パンでは現在、基幹系アプリケー

ションの24時間オンライン対応に取

り組み始めている。


7/14/2019 IT Vol.21 00.pdf


11

P resent

■応募方法巻末のとじ込みアンケート・ハガキに、

第1希望／第2希望のプレゼント番号をご記入のうえ、お送りください。

■応募締め切り

2009年2月24日（火）消印有効

1名様1製品の当選とさせていただきます。

なお、当選者は本誌Vol.22（2009年3月24日発売）で発表いたします。

3

スヌーズ機能とバックライト

機能、そして誤作動を防止する

ロック機能を備えた目覚まし時

計「JETLAG」を1名様に。幅

約9cm、高さ約2cmのシンプ

ルなボックス型で、持ち運びに

も便利です。カラーはレッド。

『システムアーキテクチャ構築の原理』

■提供：翔泳社

■2名様

4

83ページで紹介した書籍

『システムアーキテクチャ構築

の原理』を1名様に。「ステー

クホルダー」や「ビュー・ポイン

ト」といったキーワードを軸に、

アーキテクチャ設計のポイント

を解説しています。

5

83 ページで紹介した書籍

『ITコンサルタントのための要

件開発入門』を1 名様に。要

件開発のプロセスや取り組む

際の心構え、モデリングのコツ

などをITコンサルタントの視点か

ら説明しています。

『はじめての設計をやり抜くための本』

■提供：翔泳社

■2名様

6

83ページで紹介した書籍

『はじめての設計をやり抜くた

めの本』を1名様に。基本的な

設計プロセスに始まり、開発

標準の策定方法、データベー

ス／インフラの設計テクニック

などを丁寧に解説しています。

耐水USBメモリ■提供：リンクスインターナショナル

■1名様

2

ニンテンドーDSi■提供：IDGジャパン

■1名様

1

IT アーキテクト Vol.21

■Vol .20プレゼント当選者発表 ※敬称略

●プレイステーション・ポータブル：渡辺滋（神奈川県）

●MULTIMEDIA STATION E-Z：関上清（群馬県）

●USB外付け型ファン：若井典子（東京都）

●書籍『オブジェクト指向入門第2版方法論・実践』：吉田泰明（東京都）

●書籍『クラウド化する世界』：松田篤之（東京都）

●書籍『新・ソフトウェア開発の神話』：清水智充（東京都）

携帯型ゲーム機「ニンテンド

ーDSi」を1 名様に。旧モデル

を薄型化し、2つの液晶画面

は3インチから3.25インチへと

拡大。新たに、30万画素のカ

メラ機能とSDメモリ・カード・ス

ロットを搭載しています。

書籍

書籍

『ITコンサルタントのための要件開発入門』

■提供：技術評論社

■1名様

書籍

目覚まし時計■提供：IDGジャパン

■1名様

耐水深度200mを実現した

USBメモリ「Corsa ir Fl ash

Survivor（32GB）」を1名様

に。USB端子を保護するため

にシリンダー構造を採用し、ケ

ースには航空機の機体に用い

られる素材を使用しています。

7/14/2019 IT Vol.21 00.pdf


社会へのインタ

ーネットの浸透

に伴い、

今日の W e bシ

ステムは“ 企

業の顔 ”として

情報を提供す

るのみならず

、

ビジネス・チャネ

ルとしても非常

に大きな役割

を果たすように

なった。

だがその一方

で、 W e bシス

テムを舞台と

する情報漏洩

などの

事件／事故も

多数発生して

いる。

本特集では、

架空の企業で

起きた情報漏

洩事件を題材

にして、

W e bシステム

の計画から運

用までのフェー

ズで

セキュリティ／

脆弱性対策の

観点からやる

べきこととや留

意すべきこと、

そしてアーキテ

クトらの役割を

再確認する。

架空事例で再確

認する、シス

テムの計画か

ら

設計／開発、構築

、運用フェー

ズで

実施すべき主

な施策とアーキテクトの

役割

大西克美

Ka ts u m i O

h n ish i

日本 I B M I C Pエグゼク

ティブ I T アーキ

テクト


7/14/2019 IT Vol.21 00.pdf


特集

３

安全な W

e b システムが

企業のビ

ジネス・チャンスを広げ

る！

W e b

システムの

脆弱性対策


7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


仮想事例で再確認する、対策のポイントとアーキテクトの役割

メディアでも度々報道されているように、昨年辺りから

Webシステムをねらった攻撃が急増している。図1に示

すのは、日本 IBMが運営するセキュリティ・オペレーショ

ン・センター（SOC）の分析リポートから抜粋した、ここ1、

2年のWebシステムに対する攻撃数の推移だ※1。このデ

ータからも、今日のWebシステムがいかに危険にさらされ

ているかを感じていただけるだろう。

Webシステムは、登場からわずか10余年で世間に広

く定着し、飛躍的な成長を遂げた。1990 年代前半に

は、「コンピュータを顔の見えない相手とインターネットと

いう公共ネットワークを通じて接続する」という考え方は、

熟年のエンジニアにとっては大きな驚きであった。だが、

ネットワーク基盤の整備やサーバの高速化、一般家庭

へのPCの普及に伴い、インターネットは爆発的な発展

を遂げた。企業は年々サービスを多様化させて多くの

利便性を提供し、利用者はそれらのサービスを享受し

ている。現在では、インターネットなしには、人の々実生

活も企業の経済活動も成り立たなくなったと言っても過

言ではなかろう。しかし、急激に成長を遂げてきたインターネット、特に

そのサービス提供の中核となるWebシステムでは、近年

多くの事件／事故が起きている。今日のWebシステム

は、顔の見えない敵と戦い、情報を守る宿命に直面し

ているのだ。

では、現在のWebシステムが直面しているこの問題

を、企業の情報システム部門や、その中で活動するアー

キテクトはどのように解決していけばよいのか。本特集で

は、ある架空の企業で起きた情報漏洩事件を題材と

し、ケース・スタディ形式により、これに関する最新の指

針を提示することを試みる。事件発生後、システムの構

築過程をたどりながら、各フェーズで実施した作業につ

いてチェックすべき事柄や、それらの作業を行う際に留

意すべきことなどを解説していく。これを通して、Webシステムの脆弱性対策に関して、アーキテクトら当事者がな

すべきことを再確認し、読者の日々のセキュリティ対策活

動にお役立ていただければ幸いだ。

エピソード ①

情報漏洩事件が発生！

ある日、小売り業を営む「小東（こひがし）社」

の経営に重大な影響を与える事件が発生した。同社のWebシステムで管理している顧客情報が

流出しているとの連絡が入ったのだ。小東社の

関係者らは、確かに昨今のWebシステムに関し

て、その脆弱性が問題視されていることも、また

情報漏洩／盗難に関する事件／事故が頻発し

ていることも知っていた。しかし、それらはすべて

“対岸の火事”であり、まさか自社がその当事者に

なるとは夢にも思っていなかった。

報告によれば、約1万人の顧客情報の流出が

判明しており、情報の内容は氏名、住所、電話

番号、メール・アドレスなどの個人情報で、銀行

の口座番号やクレジットカード情報などは含まれ

ていない。漏洩の原因は現時点では特定できて

おらず、小東社のトップからは、CIOやアーキテク

ト、Webシステムの構築／運用担当者らに対し

て、早急に対応するよう指示が出された。取り急

ぎ、情報の漏洩が確認された顧客への連絡とお

わびについては、トップの指揮の下に広報部が

対応する。システム関係者らに対しては、漏洩の原因を究明し、一刻も早く必要な対策をとること

が求められたのだ。

CIO の北川：「今回の事件は、一体何が原因な※1 この統計分析は日本IBMが独自に行った結果であり、市場全体の傾

向を示すものではない。

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


のか？問題のWebシステムには、セキュリティ対

策は施していなかったのか？そもそも運用担当者

は気づかなかったのか？」

アーキテクトの中山：「もちろん、このシステムに

は、常識的なセキュリティ対策は施しています」

構築／運用担当の南田：「日ごろの運用の中で

は、特段、異常は感じませんでした」

北川：「中山君。今、君は『常識的』と言ったけれ

ど、そもそも『常識的なレベル』とはどういうレベル

を指すんだね。それについて説明してくれない

か？」

半ば反射的に「常識的な対策は実施済み」と

答えた中山であったが、北川からこう問われた瞬

間、システムに対するセキュリティ上の要件やリ

スクについて、第三者に正確に説明するのは容

易ではないことを感じていた。

今日のWebシステムを巡る状況と制約

筆者の経験から言えば、セキュリティ対策に関して、

その要件やリスクを明確に認識しているアーキテクトはあ

まり多くないのが実情だ。そこで、まずはWebシステムを

取り巻く状況や制約などについて説明しておこう。

Webシステムを取り巻く時代の変化

先述したように、ここ10年ほどの間に、インターネットを

ベースとするWebシステムは急速に進化／普及したが、

それに伴い、Webシステムにかかわるリスクも大きく変化し

た（次ページの表1）。1990年代後半から始まったインターネットの成長期、

Webシステムに求められた機能要件は「視覚効果の高

いWebコンテンツの提供」が主であり、非機能要件に

ついては「安定したパフォーマンスの確保」が主なもので

あった。

それが2000 年代に入ると、企業は利用者の利便性

向上、他社との差別化を図るために、Webシステムで

パーソナライズされたサービスを提供するようになる。ま

た、利用者がインターネット上で頻繁に購買活動を行う

ようになると、クレジットカード会社が参入し、銀行、証

券、保険などの金融業界もサービスを提供するようにな

った。これに伴い、識別／認証、暗号化通信などのセ

キュリティ技術が、Webシステムに必要不可欠な要件と

図1：Webシステムに対する攻撃数の推移

※ 日本IBM作成『2008年第2四半期 SOC情報分析レポート』（http://www-935.ibm.com/services/jp/iss/pdf/soc_report_08q2doc.pdf）より抜粋。

0

50,000

100,000

150,000

200,000

250,000

0

10,000

20,000

30,000

40,000

50,000

60,000

70,000

80,000

0 7 . 0 4

0 7 . 0 5

0 7 . 0 6

0 7 . 0 7

0 7 . 0 8

0 7 . 0 9

0 7 . 1 0

0 7 . 1 1

0 7 . 1 2

0 8 . 0 1

0 8 . 0 2

0 8 . 0 3

0 8 . 0 4

0 8 . 0 5

0 8 . 0 6

0 8 . 0 7

0 8 . 0 8

0 8 . 0 9

誘導型攻撃の検知数

SQ

Lインジェクション攻撃の検知数

7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


しているのは当然のことだろう。それに伴い、犯罪のグロー

バル化も進んでいる。例えば、日本企業のWebサイトは、

必ずしも国内だけから攻撃を受けているわけではない。

また最近では、五月雨式にWebシステムを攻撃する

やり方から、特定企業のWebシステムの特定の脆弱性

を狙う「スピア攻撃」と呼ばれる攻撃形態に変わりつつ

ある。一般に、インターネット上での防御では、攻撃を受

けたパターンの分析／報告に基づいて対処方法が立

案される。そのため、攻撃事例が多いほど多くの情報が集約でき、効果的な対策が立てられるのだが、スピア

攻撃のように攻撃の痕跡が残りづらい場合、防御方法

の開発が遅れることもある。

法制度の整備とIT要件への影響

もっとも、こうした危険性が野放しにされているわけで

はない。国内では、これまでに「不正アクセス禁止法」や

「個人情報保護法」といった法令が施行され、2009年

度には「日本版SOX法（通称）」も施行される。また、

企業のコンプライアンス対応が必須となり、世界的なセ

キュリティ標準である「PCIDSS（Payment Card Ind

ustry Data Security Standard）※2」など、ビジネス視

点での非機能要件の整備も進んでいる。

なる。

●急増する事件／事故、その理由は？

ここで少し視点を変え、インターネットの“暗黒面”につ

いて考えてみたい。

悪意のある者にとっても、インターネットは魅力的な市

場である。なぜなら、インターネット上には、普通ならば

入手が困難な金融情報、個人情報が豊富にあるから

だ。しかも、インターネット上にあるのは、十分なセキュリテ

ィ対策を施されたWebシステムばかりではなく、脆弱性の問題を抱えたWebシステムも数多く存在する。利用

者層も急増しており、彼／彼女らのすべてが十分なセキ

ュリティ・リテラシーを有しているとは限らない。

この「脆弱性の問題を抱えたWebシステム」と「不十

分なセキュリティ・リテラシー」という2つの要素の危険な

組み合わせが、昨今、問題になっているセキュリティ事

件／事故の要因の1つだと言えよう。第三者によって不

正に入手された個人情報／金融情報は悪用され、偽

造キャッシュカードによる預金搾取、振り込め詐欺など、

多くの実被害をもたらすようになった。

そもそもインターネットが大きな市場として成長した今日、

Webシステムへの攻撃目的が、コンテンツ改竄やサービ

ス妨害といった愉快犯的なものから、金融犯罪へと推移

表1：Webシステムと、それにまつわるリスクの変遷

分類

インターネット普及期

インターネット・ビジネス定着期

インターネット犯罪創世期

インターネット犯罪氾濫期

年代

1990年代後半

2000年代前半

2005年以降

2008年以降

利用形態／背景

Webが情報提供などの手段として定着

し、またインターネットを活用したビジネス

が普及し始めた

Webシステムの利用者が急増し、利用

者の利便性向上を目的としたパーソナラ

イズ化が定着した。インターネットをベー

スにしたB2B/B2C/B2Eの取り引きが

定着し始めた

個人情報保護法が施行され、企業に

おいて情報管理に対する意識が芽生え

た。また、インターネット・ビジネスは円熟

期を迎えた

情報漏洩事件／事故、金融犯罪が多

発する。PCIDSSをはじめとする標準が

策定される

代表的なリスク

コンテンツ改竄、ウイルス、シス

テム侵入、バッファ・オーバーフ

ロー

サービス妨害、クロスサイト・スク

リプティング、SQLインジェクシ

ョン、OSインジェクション、パス

ワード辞書攻撃

情報漏洩、情報盗難

フィッシング詐欺、スピア攻撃、

サービス妨害、誘導型攻撃

対抗策／対応技術

コンテンツ改竄検知ツール、ファ

イアウォール、パッチ／ウイルス・

ソフトの適用

ファイアウォール、IDS（不正侵

入検知システム）、Web 脆弱

性診断サービス

Web脆弱性診断サービス、IDS/

IPS（不正侵入防御システム）、

認証強化

ログ監査／監視、高度認証強

化、We b脆弱性診断サービス、

セキュリティ・アウトソーシング・サ

ービス

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


以下に、今日Webシステムを設計する際、考慮が必

要な主なリスクを挙げる。

●コンテンツ改竄：Webシステムが提供する情報／コンテンツの内容を改竄する攻撃

●サービス妨害：ファイアウォールでは防御できない正

規サービス（HTTPの場合なら80番ポート）などを利

用してサーバの処理能力を超える要求を発生させ、

レスポンスの遅延やサービスの停止を引き起こす

●ウイルス：OSやソフトウェアの脆弱性を突く不正なプ

ログラム

●バッファ・オーバーフロー：プログラムのバグや脆弱

性を利用して、システムの乗っ取りや遠隔操作、侵入

などを図る

●フィッシング詐欺：本物のサイトに酷似したコンテンツ

を提供し、利用者を欺いて個人情報や金融情報を

不正に奪取する

●クロスサイト・スクリプティング：Webシステムの脆

なお当然のことだが、ビジネス要件が変われば、IT

要件も変わり、それを具現化するWebシステムも影響を

受ける。特に法令への対応、業界標準の順守、監督省庁が策定するガイドラインへの対応などは、Webシス

テムを設計／構築／運用する者にとって大きな負担とな

っている。

その主な理由は、ビジネス要件とIT要件のひも付け

が容易ではないことだ。例えば、個人情報保護法が施

行されたときには、「個人情報をどのような方法で守れ

ばよいのか」、「妥当なレベルはどの程度か」、「セキュリ

ティ技術をどのように実装するのか」など、法令とITの対

応関係で悩んだ企業が多かった。それを踏まえると、前

出のPCIDSSは、クレジットカード業界に特化したもので

はあるが、個人情報と金融情報を保有する企業が参

考にできる、具体的な技術標準だと言える。表2に示す

のは、PCIDSSで規定された12の要件だが、こうした業

界標準をWebシステムのIT要件だととらえれば、自社に

セキュリティの専門家がいなくても「常識的なレベル」を

把握することはできるだろう。

Webシステムにまつわるリスク（脅威と脆弱性）

それではここで、Webシステムを取り巻く脅威と、システムの脆弱性について考えてみよう。なお、一般に「リス

ク」とは、大まかに言えば、システムに内在する脆弱性

と、外部からもたらされる脅威の総称を指す。

10 余年をかけてWebシステムの社会的重要性が高

まったのに伴い、現在ではWebシステムにまつわるリスク

も多様化／高度化している。こうした中でアーキテクトに

期待されているのは、そのリスクの変遷を踏まえてシステ

ムの設計を行うことだ。つまり、10年前と現在とではリス

クの内容／影響が異なるため、実施すべきセキュリティ

対策も違ったものになるのである。

※2 国内外の主要クレジットカード会社により、クレジットカードの安全な利

用を図るために策定された、ITシステムのセキュリティ基準。クレジットカード会

社のみならず、インターネット上で商取引を行う多くの企業で採用されており、

今日では代表的な国際セキュリティ基準と見なされている。

表2：PCIDSSの12の要件

安全なネットワークの構築／維持

①データを保護するためにファイアウォールを導入し、最適な設定を維持する

こと

②システム／ソフトウェア出荷時の初期設定値（セキュリティに関する設定値）をそのまま利用しないこと

カード会員情報の保護

③保存されたデータを安全に保護すること

④公衆ネットワーク上でカード会員情報やセンシティブ情報を送信する場合、

暗号化すること

脆弱性を管理するプログラムの整備

⑤アンチウイルス・ソフトを利用し、なおかつ定期的に更新すること

⑥安全性の高いシステム／アプリケーションを開発し、保守すること

強固なアクセス制御手法の導入

⑦データ・アクセスを業務上の必要範囲内に制限すること

⑧コンピュータにアクセスする際、利用者ごとに識別IDを割り当てること

⑨カード会員情報への物理的なアクセスは制限すること

定期的なネットワークの監視およびテスト

⑩ネットワーク資源やカード会員情報に対するすべてのアクセスを追跡し、監

視すること

⑪セキュリティ・システムおよび管理手順を定期的にテストすること

情報セキュリティ・ポリシーの整備

⑫情報セキュリティーに関するポリシーを整備すること

7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


エピソード ②

小東社Webシステムの

脆弱性対策は？

セキュリティ対策に関する「常識的なレベル」

はつかめた。では、それを踏まえて、小東社では

実際にどのような対策を講じていたのだろうか。

北川：「それでは、中山君がこのシステムを設計し

たときの方針や、実際に導入した脆弱性対策に

ついて説明してもらえるかな」

中山：「わかりました。私が実施したシステム設計

を整理して報告します。ただし、設計当時は『コス

ト削減』を理由に、いくつかの施策の導入を断念

しています。その辺りの経緯も含めて報告させて

ください」

こうして、中山による小東社Webシステムのセ

キュリティ設計に関する報告が始まった……。

システムのライフサイクル全般を通した脆弱性対策のあり方

脆弱性対策は、システムのライフサイクル全般にわた

弱性を利用して、悪意を持った第三者によるスクリプ

トとWebシステムを使って行われる攻撃。その手順は

図2のようになる

●SQLインジェクション：Webサーバと連携しているデ

ータベース・サーバにSQLコマンドを直接送信して実

行させることで、データを改竄／盗難する

●OSインジェクション：ユーザーが入力したデータに

対し、動的にコマンド・パラメータを付加することで、

Webシステムが稼働するOS上のプログラムやコマンド

を起動してシステムに攻撃を加える●スピア攻撃：特定企業のサーバの脆弱性をピン・ポ

イントで狙った攻撃。従来の多数のサーバを一斉に

攻撃する手法と比べて被害が表面化しづらく、発見

や対策も遅れがち

●パスワード辞書攻撃：辞書に登録された文字列を

パスワードとして利用し、順次認証を試みる攻撃

●誘導型攻撃：電子メールの添付ファイルや改竄した

Webサイトなどを使ってクライアント・マシンをウイルスに

感染させ、情報を不正に入手する攻撃

アーキテクトの中山が答えた「常識的なレベル」とは、

以上に述べたようなビジネス要件の変化を踏まえたIT

要件と、Webシステムを取り巻くリスクを踏まえたレベルの

ことを指していた。

図2：クロスサイト・スクリプティング攻撃

http://www.xxx.jphttp:// 有名サイトへのリンク

http://www.abc.us

①悪意のあるWebサイトと知らずにアクセス

②「スクリプトが埋め込まれた」有名サイトへのリンクを表示

③リンクをクリックして有名サイトのWebページを閲覧

④利用者のWebブラウザ上でスクリプトが実行される

⑤Cookieに含まれるセッションID、個人情報などが盗まれる

悪意あるWebサイト脆弱性のある有名サイト

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


する統一的な基準を策定し、それを推進するための施

策を導入するというアプローチで取り組むとよい。それぞ

れ、重要度が格付けされた情報がどのような形式のデータとして、どの物理ノードに格納されているのか、また

各アプリケーションでは、そのデータをどう利用するのかと

いったことを整理する。エンタープライズ・アーキテクチャ

（EA：Enterprise Architecture）と言うと大げさに聞こ

えるが、要はそれと同じ考え方で取り組むのだ。全社的

に統一された情報定義、管理方法があれば、セキュリ

ティ対策の推進も容易になるだろう。

●設計方針を明確にし、決定の経緯、判断の根拠

を残す

今回事件が起きた小東社のWebシステムに関して言

えば、扱う個人情報は1種類であり、保管場所はデー

タベース・サーバとディレクトリ・サーバの2個所であった。

中山はこのシステムについて、かつて自身が計画フェー

ズで検討した要件を整理してみた。その結果が次ペー

ジの表3に示す機能要件／非機能要件だが、これらは

今日の一般的なWebシステムの要件と同程度のものだ

ろう。

なお、要件が一覧などとしてきれいにまとまっている場

合でも、各要件の選定基準やシステム設計に関する決定事項の根拠が曖昧であり、設計に関する原理原則

（プリンシプル）がない場合は多い。そのようなケースで

は、別の者が設計を担当したら、違った設計のシステム

が出来上がる可能性がある。今日のWebシステムを

“企業の顔”ととらえるのであれば、個人の技量にシステ

ムの出来や品質が左右されるのは、企業にとって好まし

いことではないだろう。アーキテクトは、あらかじめ自身の

設計方針を明確にして臨んだうえで、機能要件／非

機能要件を決定した経緯や判断の根拠などを残してお

くのが望ましい。

●各種団体の情報サイトも活用し、常に最新の情報

を仕入れる

また、その他の課題として「エンジニアの知識の限

って実施するものである。以降では、アーキテクトである

中山の活動を中心に、システムの計画から設計／開

発、構築

※3

、運用の各フェーズにおける脆弱性対策のあり方について、中山が実際にどのような施策を実施し

たのかも含めて見ていこう。

計画フェーズでやること

アーキテクトがシステム設計で行う重要な仕事の1つ

は、「要件の確定」である。それにあたっては、システム

の設計時に考慮すべき要件を整理する。無論その中に

は、セキュリティに関する要件も含まれる。

●最初にやるのは「機密情報の棚卸し」

セキュリティに関して、計画フェーズで最初に行うべき

作業は「機密情報の棚卸し」だ。つまり、システムでどう

いった機密情報をどのように扱うのかを、くまなく調査す

るのである。

企業が保持するすべての情報は、それぞれに対して

適切なレベルの機密性が確保され、システムの重要度

合いにかかわらず、高度な可用性が保証されているの

が理想的だ。しかし、企業がセキュリティ対策に投下で

きるコストには限度があり、情報の機密レベル、システム

の重要性を評価したうえで、優先順位を付けて対策を講じているのが実情である。

●情報管理の統一基準を作る

ところで、システム投資に関して多くの方が頭を悩ませ

ているのが、システムの投資対効果（ROI：Return On

Investment）の評価だろう。セキュリティに関しては、こ

のROIの評価が特に難しい。なぜなら、情報漏洩など

が発生した際の企業のビジネス上の損失を数値化する

のは困難だからだ。そのため、稟議の段階でセキュリテ

ィ対策の必要性を強く主張できず、十分な対策をとれな

いケースが少なくないのである。

この問題を解決するには、企業内で情報管理に関

※3 開発（プログラミング）したシステムを実際に組み上げるフェーズ。このフ

ェーズで行う作業には、既存システムとの統合作業なども含まれる。

7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


さて、小東社のWebシステムだが、表3の要件を稟

議に上げた際、企画部門から「コスト削減」の要求が

出され、「外部からの不正攻撃の検知、報告機能」と

「システムの脆弱性診断の定期的な実施」の導入を断

念していた。さらに、詳細は割愛するが、中山は改めて

自身の設計方針を見直した結果、いくつか反省すべき点も発見した。その辺りのことについても、正直に北川に

報告することにした。

エピソード ③

現状システムの調査

北川：「調査報告ありがとう。コスト削減を優先し

て機能を削ったのは、今回の一件を考えると妥

当ではなかったようだね。この教訓は次のシステムに生かしてほしい。それと、顧客情報が流出し

たのはWebシステムの脆弱性に原因があるのだ

から、これについては引き続き詳しく調査してもら

界」がある。

今日のIT業界では、セキュリティ関連のエンジニアが

慢性的に不足していると言われる。ユーザー企業の社

内にセキュリティに精通したエンジニアがいることも少なく、

学習の機会も多いわけではない。社外で開催されるセミ

ナーの多くは、セキュリティ関連製品の紹介が中心であり、セキュリティを考慮した最新のシステム設計について

教えるようなものはまれである。

そのため、エンジニア個人の知識の限界が対策立

案の限界に直結することが懸念されるが、実はセミナー

に頼らなくても、セキュリティに関する最新情報を仕入れ

られる場はある。それは、各種の組織／団体がチュート

リアル的な知識を提供しているWebサイトや、セキュリティ

に関するニュース／情報を提供しているWebサイトなど

だ。参考までに、筆者がよく利用している組織／団体の

Webサイトを表4に挙げたので参考にされたい。こうした

Webサイトも有効に活用してアンテナを張っておけば、

最新の技術情報やソリューションの傾向を知ることがで

き、それが適切な判断を下す助けとなる。

表3：小東社Webシステムについて計画フェーズで検討した機能要件／非機能要件

要件種別具体的な要件説明

①静的コンテンツ配信機能（HTML、PDFなど）会社情報、製品情報などを会員／不特定利用者に提供する

②動的コンテンツ処理機能製品の購入／決済、配送手続きなどのサービスを会員に提供する③ID管理機能新規入会／脱会処理、プロファイルの登録／変更などの機能を提供する

機能要件 ④データ管理機能製品情報、各種申し込みのステータス管理、コンテンツ管理などの機能を提供する

⑤コミュニケーション支援機能メールによる購買履歴通知、メール会員配信サービスなどの機能を提供する

⑥認証機能利用者の認証サービス、認証履歴の取得などの機能を提供する

⑦セキュリティ通信機能暗号化通信（SSL）の機能を提供する

●サーバの物理的な保護

●ファイアウォールを使ったネットワーク・ゾーニングの実施

①セキュリティ要件 ●ウイルス対策の実施

●認証履歴の取得

●セキュア・プログラミングの実施

非機能要件 ●OSハードニング（要塞化）

●各サービス（ソフトウェア、アプリケーション）の稼働状況、ハードウェアの稼働状況、リソース使用

②運用／障害対策要件率の監視機能

●データの日次バックアップ

●外部からの不正攻撃の検知、報告機能（IDSまたはIPS機能）

●システムの脆弱性診断の定期的な実施

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


設計／開発フェーズの作業の見直し

今回、情報漏洩が起きた小東社のWebシステムの

アーキテクチャは、図3に示すとおりだ。中山は、このア

ーキテクチャについて、セキュリティの観点から再評価す

ることにした。

システムを評価する際に重要なことは、全体を鳥瞰的

にとらえ、そこで想定される脅威、脆弱性を洗い出すこと

である。この中で、各サーバがどのようなサービスを提供

し、それぞれがどういった関係を持ち、どう接続されてい

るのかを整理する。今回の事件では顧客情報が流出したわけであるか

ら、まずは事件の当事者である攻撃者がどのようにして

情報を流出させたのかを明らかにしなければならない。

えないか」

中山：「承知しました。もう一度、初心に戻り、ど

こに欠陥があったのかを調査します。しばらく時間

をいただけますでしょうか」

中山は、自身が設計したWebシステムを評価

してみることにした。今回の事件は残念なことで

はあるが、このようなことでもなければ、自分が過

去に設計したシステムやアーキテクチャを再評価

する機会など巡ってはこない。中山はまず、シス

テムの構成や提供しているサービスの内容、他

の社内システムとの関係から整理することにし

た。

表4：主なセキュリティ関連情報源

Webサイト名（提供機関）

内閣官房情報セキュリティセンター

情報セキュリティ

（情報処理推進機構［IPA］）

JPCERTコーディネーションセンター

JNSA：日本ネットワークセキュリティ協会

警察庁セキュリティポータルサイト@pol ice

フィッシング対策協議会

Security＆Trust（アイティメディア）

活動内容

日本における情報セキュリティ政策に関する基本戦略の決定

セキュリティに関する被害状況の把握、情報提供、セミナー・イベントを通じた啓発活動、セキュリティ評価／認証制度の推進、技

術開発／研究など

日本国内の Webサイトに関するコンピュータ・セキュリティ事案に

関連した報告の受け付けや対応支援、発生状況の把握、手口

の分析、再発防止に向けた対策の検討や助言の提供など

ネットワーク・セキュリティの必要性の啓蒙、問題解決に向けた活

動の支援など

セキュリティに関する情報の提供、啓発活動、ツールによる簡易

診断サービスの提供など

日本国内におけるフィッシング詐欺に関する事例や技術情報の収

集／提供など

セキュリティに関するニュース／情報の提供など

URL

http://www.nisc.go.jp/

http://www.ipa.go.jp/security/

http://www.jpcert.or.jp/

http://www.jnsa.org/

http://www.cyberpolice.go.jp/

http://www.antiphishing.jp/

http://www.atmarkit.co.jp/fsecurity/

図 3：小東社の Webシステムのアーキテクチャ

クライアント層 DMZ 層

Web

ブラウザ

メーラ

負荷分散

装置

プレゼンテーション層

セキュリティ管理

システム運用管理

コンテンツ・サーバ

Web

サーバ

認証サーバ

メール・ゲートウェイ

アプリケーション層

アプリケーション・

サーバ

メール・サーバ

データ・ストア層

データベース・

サーバ

ディレクトリ・サーバ

クレジット決済システム

外部ゲートウェイ層クレジット会社

決済ゲートウェイ・

サーバ

SSLアク

セラレータフ

ァイアウォール

ファイアウォール


顧客情報

顧客情報

7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


グ・ファイルを直接確認する方法もある。ただし、稼働

履歴のログ・ファイルは消去されたり、内容が改竄され

たりしている可能性もあるので、上記のコンポーネント設計にまでさかのぼり、取得しているログの有無などを調べ

る方法も覚えておくとよいだろう。

②機密情報の保管場所に着眼した調査

次に紹介するのは、機密情報がどこに保管されてい

るかという点に着眼した方法だ。この場合は、機密情

報に対して、どの利用者が、どのサーバ／コンポーネン

トを経由してアクセスできるのかを整理する。情報が漏洩

したということは、必ずその最終地点であるサーバ上で

何らかの操作が行われたはずだ。その痕跡を逆にたどる

ことで、攻撃手法を解明するのである。

小東社のWebシステムで扱う顧客関連の情報は、

データベース・サーバとディレクトリ・サーバに格納される。

このうち、ディレクトリ・サーバで扱うのは、システムの認

証に使うアカウント名やパスワード、ユーザー属性などだ

が、これらは今回流出した情報ではない。住所や電話

それには、次の3つの方法が考えられる。

①セキュリティ関連コンポーネントの調査

事件／事故が発生した際には、それが悪意によるものか、それとも過失によるものかに関係なく、必ずその“痕

跡”を調査する。このとき、一般に調査対象となるのが、

セキュリティに関連する情報を記録したログだ。ログは、

システムの利用者がどのような手順で、どのようなことをし

たのかを明らかにするのに役立つ。

小東社のWebシステムについて、システムの認証にか

かわるコンポーネント間の関連をUMLのシーケンス図で

整理すると、図4のようになる。この図を見ると、図中に

「調査対象」として示した範囲にある「認証履歴」コン

ポーネントによって認証履歴が記録されていることがわか

る。このログを調査すれば、「認証機能」コンポーネント

が取得した情報の詳細、例えば利用者のアカウント名

や利用日時、認証の結果（成功か、あるいは失敗か）

などがわかるだろう。

また、そのほかに、実機上に残ったシステム稼働のロ

図4：認証にかかわるコンポーネントの関連図

ユーザー

ログオン

User: ログオン

ログオン要求

認証

認証ログ履歴

<Return>認証ログ履歴

<Return>認証

<Return>ログオン要求

<Return>User: ログオン

<Return>ログオン

<Return>認可

認可

ダイアログ・マネジャ

認証／認可サービス・フロー

認証／認可マネジャ

認証機能認証履歴認可機能

調査対象

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


つまり、そのシステムで想定されるすべてのリスクを洗い出

したうえで、それが実際に起きる可能性を検討するので

ある。図5に示すのは、小東社のWebシステムについて、

情報漏洩に影響すると考えられるリスクの発生要因をま

とめたものだ。システムへの攻撃は、複数のリスク要因を

組み合わせて行われる場合もある。例えば、「バッファ・

オーバーフローの脆弱性を突いてサーバに侵入し、遠

隔操作を行う」、「安易なパスワードに対する辞書攻撃

を行い、その結果を悪用して第三者になりすまして攻撃

する」といった手口も考えられる。

こうした大局的な視点によるリスクの洗い出しは、当

然、アーキテクチャやシステムの設計時にも行う。アーキ

テクチャ／システムを設計したら、そこから予想されるリス

クを洗い出し、その対応策を設計に盛り込むのだ。

なお、開発フェーズに関しては、「セキュリティを考慮

したプログラミング」も重要である。2000年代前半に話

題となり、現在でも事件報告のあるSQLインジェクション

やクロスサイト・スクリプティングなどは、いずれもプログラミ

番号といった個人情報の流出元として疑わしいのは、

やはりデータベース・サーバである。

その仮定が正しければ、後はデータベース・サーバに対するアクセス方法を洗い出せばよい。なお、このシス

テムは、データベース・サーバに対して直接コマンド操

作を行うことはできない設計になっている。よって、データ

ベース・サーバにアクセスするアプリケーション・サーバと、

その前に置かれたWebサーバも含めてアクセス経路を

調査する必要がある。

セキュリティ関連の事件／事故における原因追及の

方法は、「仮説→確認／検証→判断」の繰り返しとな

る。この中で、アーキテクトが果たす重要な役割は、仮

説を立てることでも、確認／検証や判断を行うことでもな

い。仮説を確認／検証するための記録／証拠を残せ

るシステムを設計することが、アーキテクトの重要な務め

なのだ。

③一般的なリスクの調査

調査を網羅的に行うためには、現存する証拠から推

測するだけでなく、大局的な視点に立つことも重要だ。

図5：小東社のWebシステムにおける情報漏洩のリスク要因

Webブラウザ

メーラ

Webサーバ

認証サーバ




データベース・サーバ


決済ゲートウェイ・サーバ

ファイア

ウォール

ファイア

ウォール

顧客情報

顧客情報

サービス停止

通信データ盗聴

SQLインジェクション

遠隔操作

侵入

侵入

侵入

なりすまし

発生しうるリスク

7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


べる。

①リスク／セキュリティ対策の洗い出し：ここで重要な

のは、できるだけ網羅的にリスク／セキュリティ対策を洗い出すことである。この段階でリスクを見落とすと、

セキュリティ上の欠陥があるシステムが出来上がる危

険性が高い

②リスク／セキュリティ対策間のマッピング：想定され

る各リスクに対して、どの対策を適用するかの取捨選

択を行う。リスクとセキュリティ対策は、必ずしも1対1で

対応するわけではない。また、1つの対策を実施する

際、ネットワーク上の複数のノードに対策を適用しな

ければ意味をなさない場合もある。例えば、各種ログ

の取得／監査機能では、複数のノードから得たログ

を組み合わせて1つの監査情報を作る

③セキュリティ対策の配置：セキュリティ対策が重要で

あることは確かだが、その実施により多くの制約も生じ

る。例えば、データの暗号化を行った場合には、その

ノード上のパフォーマンスが低下することがある。また、

ログ監査を実施するためには、新たに監査担当者を

任命する必要があるかもしれない。こうした他の非機

能要件などとのトレードオフや組織上の制約なども考

慮しつつどのように判断していくかは、アーキテクトの腕の見せどころの1つだと言ってよいだろう

●不採用の理由は必ず残す

以上のような点にも配慮しながら、図7に示すようなか

たちで対策を配置していく。その際に重要なのは、不採

用にした対策については、その判断の根拠を残しておく

ングのレベルで対策が必要な脆弱性だ。ここでは、これ

らに関するプログラミング・ノウハウの説明は省くが、前

掲の表4に挙げたWebサイトのうち、IPA（情報処理推進機構）のWebサイトなどに、セキュアなプログラミングの

ガイドや参考情報が掲載されているので参考にされた

い。

設計／開発フェーズで大事なのは、システムで発生

しうるリスクを認識することと、それを回避するためのプロ

グラミングを行うことだ。これらを徹底するには、技術標

準などにセキュリティに関する考慮点を追加し、文書化

するなどしておくことが必要になるだろう。

●セキュリティ対策の手順

表 5に示すのは、代表的なセキュリティ対策の例だ

が、これを見て気づくのは、1つのリスク（表中の対策分

類）への対策が複数存在することだ。これらの対策に

は、それぞれに長所／短所があり、それらのトレードオフ

を考慮してどれを選択するかにより、対策の効果などが

違ってくる。この「選択肢が複数ある」という点が、セキュ

リティ設計が難しい理由の1つだと言えるだろう。

小東社のWebシステムに関しては、識別／認証、通

信データの保護、ファイアウォール、セキュア・プログラミ

ングなどの対策は実施していたが、結果として情報が漏洩した。対策が不十分であったか、あるいは対策の適

用個所が適切ではなかったことが考えられる。

ではそもそも、対策を適切に適用するには、どうしたらよ

いのだろうか。セキュリティ対策の一般的な手順は、図

6に示すとおりだ。以下に、それぞれの手順の要点を述

表5：セキュリティ対策の分類

対策分類代表的な対策

防止対策識別／認証、アクセス制御、ハードニング、パッチ適用、ウイルス／ワーム対策、ファイアウォール、

否認防止、不正機器接続排除（認証／検疫ネットワーク）、コンテンツ・フィルタリング

低減対策保管データの保護（暗号化、持ち出し制御）、通信データ保護（暗号化）、脆弱性検査、冗長化構成、

IPS、セキュア開発

検知対策システム・ログ取得／監査、認証ログ取得／監査、アクセス・ログ取得／監査、ネットワーク通信ロ

グ取得／監査、データ改竄検知、IDS（ネットワーク、サーバ）、不正機器接続検知（検疫ネットワーク）

復旧対策バックアップ（システム、データ）

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


図 6：セキュリティ対策の一般的な手順

①リスク／セキュリティ対策の洗い出し

③セキュリティ対策の配置

②リスク／セキュリティ対策間のマッピング

Webブラウザ

想定されるリスクセキュリティ対策識別／認証

アクセス制御

暗号化

.....

メーラ

Webサーバ

認証

サーバ



サーバ





サーバ

ファイア

ウォール

ファイア

ウォール

顧客情報

顧客情報

情報漏洩

図 7：セキュリティ対策の配置

Webブラウザ

メーラ

Webサーバ

認証サーバ



サーバ





サーバ

顧客情報

顧客

情報

適用するセキュリティ対策検討したが不採用の対策

ウイルス／ワーム対策

ハードニングファイアウォール

通信データ保護

識別／認証認証ログ取得／監査

アクセス制御


パッチ適用

脆弱性検査

保管データ保護

コスト削減のため、採用を断念

パフォーマンスが悪化するため、実装を断念

7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


中山：「いや、あくまでも可能性として指摘してい

るだけだよ。実際に世の中ではそういう事件が起

きているんだ」

北川：「まぁまぁ、言い争いはやめたまえ。それで

は、Webシステム以外にも対象を広げて、個人

情報の管理に関係しそうなシステムのセキュリテ

ィ対策を再調査してもらおうか」

事件／事故の原因究明の難しさ

実は、セキュリティ関連の事件／事故において、その

原因を完全に解明できないケースは少なくない。情報

漏洩が事故ではなく、「情報盗難」という事件であった

場合にはなおさら、その痕跡が残っていないことが多い。

その場合でも、仮説を立てつつ推論していくことになる。

原因が特定できない場合、それまで単一のシステムに

絞って調査してきたのであれば、その調査対象を広げる

ことになる。つまり、仮説立て／推論の対象範囲を広げ

るわけだが、広範囲にわたってリスク要因を把握するの

は容易ではない。この場合、自社のシステム設計を逐

一調べるものよいが、前掲の表 4に挙げたような情報源

を活用し、現在、世間ではどのような情報漏洩事件／事故が起きているのかを調査してみるとよい。

ことだ。どんな理由であってもよいので、その意思決定を

行った事実と、検討の経緯を残すことが重要である。

小東社のWebシステムについては、実施済みのセキュリティ対策を評価した結果、比較的、高いレベルの対

策が施されていることが確認できた。プログラミングのレ

ベルで見ても、ちょうど構築当時にクロスサイト・スクリプテ

ィング攻撃が話題になったこともあり、意識してセキュアな

プログラミングが行われていた。

これまで、Web経由で情報が漏洩したものと思ってい

た中山だが、それについて確たる証拠があるわけではな

い。むしろ、詳細に調べれば調べるほど、外部からWeb

システムにアクセスして情報を盗み出すのは技術的に困

難に思えてくる。中山の胸中では、「今回の情報漏洩

は、Web経由で起きたのではないんじゃないか？」という

思いが強まるのであった。

エピソード ④

調査のやり直し

中山：「さまざまな角度から調査／分析してみたの

ですが、率直に言って、外部からWebシステムが

不正アクセスされて情報が漏洩したとするのは不

自然です」

北川：「では、一体どこから漏洩したと言うんだ。

責任逃れはやめないか！」

中山：「いえ、決して責任逃れをするつもりはあり

ません。あくまでも、残された情報に基づく私なり

の判断です。そもそもわが社には、問題になって

いるWebシステムのほかにも、個人情報を扱って

いるシステムがあります。また、昨今よく問題にな

っているように、運用担当者が意図的に漏洩した可能性もあります」

南田：「それは心外だな。君は運用チームを疑う

のか！？」

図8：情報漏洩の媒体／経路

※ 日本ネットワークセキュリティ協会『2007年情報セキュリティインシデントに関する調査報告書 v1.3』（ ht tp://www.jnsa.org/result/2007/pol/incident/2007incidentsurvey_v1.32.pdf ）より数値を引用。

不明

5.1%その他

5.9%

可搬記録媒体

12.5%

紙媒体

40.4%PC本体

10.9%

電子メール

9.8%

Web

15.4%

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


れている。そのため、技術的に見れば、情報を盗み出す

のが容易な立場にある。内部の者による情報の盗難を防

ぐには、一般にアクセス／操作のログを記録し、それを定期的に監査するといった対策がとられる。

中山は、CRMシステムの担当者に、アクセス・ログの

確認を依頼することにした。さらに、システムの構築フェ

ーズや運用フェーズで実施した作業についても、問題

がなかったどうかを見直すことにした。

構築フェーズで考慮すること

システムの構築フェーズについてアーキテクトが特に

考慮すべきことは、主にサーバのハードニングとセキュリ

ティ・パッチの適用である。

また、自身が行った設計がセキュリティ上のリスクを見落

としていないかどうか、第三者の視点から評価してもらうの

も有効だ。これに関する一般的な方法は、脆弱性検査

の実施であろう。システムが本番稼働に入った後では、

脆弱性が見つかっても、すぐにサーバの設定を変更した

り、セキュリティ・パッチを適用したりするのは難しいことがあ

る。その点を考慮すると、システム構築フェーズのテスト時

などは、脆弱性テストを行うには良いタイミングだ。

例えば、図8に示すのは、日本ネットワークセキュリティ

協会が2007年に実施した情報漏洩の媒体／経路に

関する調査の結果だが、こうした統計資料も、仮説を立てるうえで重要な情報源になる。この調査によれば、

情報漏洩の15％以上がWebシステムなどのネットワー

ク・サービス経由で発生しており、これは原因としては2

番目に多い。一方で、約5％が原因不明であるというの

も無視できない事実だ※4。

ただし、こうした情報などを提示しつつ、漫然と「Web

システム以外に原因がある」と主張しても説得力に乏し

いので、中山は顧客情報を扱うシステムの全容を調査

することに決めた。具体的には、問題となっているWeb

システムを取り巻くシステム、データ、アクタ（システムの利

用者）を漏れなく調査し、その相関関係を図9のようなシ

ステム・コンテキスト図としてまとめた。

図に示したように、小東社のWebシステムは、バッチに

よってCRMシステムと連携しており、CRMシステム上にも

Webシステムと同じ顧客情報が保管されている。多くの

場合、CRMシステムを利用するのは社員に限られるが、

社員が不正を働かないとは限らない。実際、近年では、

企業内部の関係者が情報の盗難にかかわるケースが増

えてきている。内部関係者には、業務遂行のためにシステムのアカウントが付与され、また情報へのアクセスも許さ

※4 この結果は、日本ネットワークセキュリティ協会が独自に行った調査に

基づいており、必ずしも市場全体の傾向を示すものではない。

図 9：小東社の Webシステムにかかわるシステム／データ／アクタ

利用者PC

顧客マスタ保守作業員

CRMシステム

外部決済システム

Webシステム

バッチによる連携

HTTP/HTTPSによって送信されるHTML/XML文書

HTTP/HTTPSによるデータ要求

HTTP/HTTPSによって外部システムに送信される

XML文書

HTTP/HTTPSにより返信されるXML文書

対話的コマンド

バッチによる連携

7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


担当者の監視ならば、ログを検証することによって行える

が、特権ユーザーならば、そのログを消去し、改竄する

ことも可能だ。こうして改めて考えると、運用担当者などの保守作業

員は、情報の盗難を比較的、容易に行える存在である

ことがわかる。現実に、内部統制の強化に取り組んでい

る企業では、監査会社からこうした面での脆弱性を指

摘されることが多く、火急の課題として認識している。こ

れに対処するために、セキュリティ・ツールを導入したり、

OSのセキュリティ機能を強化したりするケースも見られる

が、それらと同時に「単独での保守作業を禁止する」、

「作業申請／報告などの手続きを強化する」といった運

用手順そのものの改善も検討するとよい。

さて、ここまでアーキテクトである中山の視点を中心に、

システムの計画、設計／開発、構築、運用の各フェー

ズの作業に関するチェックポイントを述べてきた。まとめとし

て、表6にシステム・ライフサイクルの各フェーズにおけるア

ーキテクトの責務と組織全体で行うべき取り組みを示す。

全社を挙げてセキュリティ対策に取り組む

企業システムを犯罪や事故から守るためには、アーキ

テクトだけが奮闘するのではなく、企業全体で総力を挙

げて取り組む必要がある。ここからは、企業システムのセ

キュリティ対策を継続的に実施していくうえで鍵となる取り

組みを、CIOとアーキテクト、運用担当者がそれぞれに

果たすべき役割と併せて説明していこう。

エピソード ⑤

次世代Webシステムのセキュリティ対策の検討

中山らは、Webシステム以外のシステムから

運用フェーズに関する留意点

運用フェーズに関して確認すべきことは、主に2つある。

●サーバの稼働状況のチェック1つは、サーバが当初の設計どおりに稼働していたか

どうかということだ。たとえ構築フェーズのテストにパスして

いても、長期間運用している間に新たな脆弱性が見つ

かっているかもしれない。「ファイアウォールは本当に外部

からのリクエストをルールどおりに遮断しているか」、「各

サーバは乗っ取られていなかったか」、「認証サーバは

登録されていないアカウントを拒否しているか」、「システ

ムを構成する各ソフトウェアの脆弱性を見落としていない

か」といったことについて仮説を立て、逐一検証を行う。

ただし、これらの検証を行うには、その基になるイベント情

報や稼働履歴などの記録が残っていなければならない。シ

ステムの要件定義や設計に際しては、そうした記録を残す

よう、運用のことまで意識して作業することが重要である。

●特権的な権限の管理を見直す

確認すべき2つ目は、内部の者の犯行を疑ってみると

いうことだ。小東社のWebシステムの場合、前掲の図9

から、保守作業員が対話的にコマンドを実行しているこ

とがわかる。一般の利用者は、顧客情報に直接的にア

クセスするのは不可能であり、必ずWebサーバ／アプリケーション・サーバを経由する。それに対して、保守作

業員ならば、コンソールなどから直接システム内のデータ

にアクセスできるのだ。特に、特権的な権限を持った保

守作業員の場合、システム内のデータを盗難するのは、

技術的にはさほど難しくないだろう。

実際、多くの企業で、その危険性が認識されつつも

対応が遅れているのが、特権ユーザーの管理だ。当

然のことだが、特権がなければ保守作業は実施できな

い。そして、サービスの起動／停止、バックアップの取

得、パッチの適用、ユーザー管理など、特権的な権限

によって行える操作は数多くある。また、多くの作業は休

日／夜間などのサービス提供時間外に実施されるた

め、担当者が単独で作業を行うこともあるだろう。業務

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


ていろいろと調査してみて、まだ技術面でも改善

の余地があることがわかりましたし、その辺りを少

し整理してみます」

南田：「私も、運用の観点から提言をまとめてみま

す。“餅は餅屋”と言いますが、セキュリティのプロ

に任せるべきことと、わが社で対応すべき事項を

整理して報告しましょう」

CIOが取り組むべきこと

――企業全体としての施策

セキュリティ対策を成功させるうえでの最大のポイント

は、やはり「トップダウンによる統制」だ。各部門が個別

に対策を実施することで、セキュリティ・レベルが向上する

こともあるが、全社横断的に実施しなければならない施

策もある。そうした施策に取り組む際には、例えば日本

情報処理開発協会が提唱する「情報セキュリティ・マネ

ジメント・システム（ISMS）」（http://www.isms.jipde

c.jp/isms.html）などのような、企業向けの情報セキュリ

ティ管理体系を参照するとよいだろう。こうした体系を参

個人情報が漏洩したのではないかとの推測の

下、他のシステムについても調査を行ったが、結

局、確たる証拠は得られなかった。そして、深く

調査すればするほど、計画フェーズでの考慮が足

りなかったことが悔やまれた。また、運用に脆弱

な部分があることも完全に見落としていた。いず

れにせよ、現段階では、これ以上の原因追求は

難しい。よって、調査はこれで打ち切りとし、次の

システム設計時には、運用作業に関するセキュリ

ティ対策を強化することに決めた。

北川：「中山君、南田君、今回はご苦労だった

ね。残念ながら、原因はわからなかったが、わが社のシステムが抱えているセキュリティ面のリスク

が把握できた。この機会に、1つ頼みたいことが

ある。今後このようなことを起こさないために、会

社として何を実施すべきかを提言としてまとめてく

れないか。私のほうでも、全社的に行うべき対策

を一度整理してみたいと思う」

中山：「わかりました。今回の事件をきっかけにし

表6：システム・ライフサイクルの各フェーズにおけるアーキテクトの責務と組織全体で行うべき取り組み

フェーズ

共通

計画フェーズ

設計／開発フェーズ

構築フェーズ

運用フェーズ

アーキテクトの責務

●セキュリティに関する情報源を持ち、知識／情報が陳腐化するのを防ぐ

●短いサイクルでPDCA活動を繰り返す

●セキュリティの実装に関する手順を確立する

●ビジネス要件／システム要件から導いたセキュリティ要件を可視化する

●機能要件／非機能要件で実現するセキュリティ機能を整理する

●全社的なセキュリティ施策に合致した対策レベルを決める

●要件の選定に関する原理原則を確立する

●セキュア・プログラミングの実践など、開発レベルからセキュリティを意識する

●考えうるリスクと、それに対応したセキュリティ対策を整理する

●意思決定に関する根拠を明らかにし、目に見えるかたちで残しておく

●内部統制の観点から、監査機能を設計に盛り込んでおく

●システムの評価時に第三者による評価を受ける

●脆弱性検査を実施する

●ITシステムに関するリスクを体系的／網羅的に分析／整理する

●運用に関する脆弱性を認識し、継続的に監視／監査を実施する

組織全体で行う取り組み

●全社的なセキュリティ体制を確立する

●PDCAサイクルの管理を推進する

●全社的なセキュリティ施策を決定し、以下の事項を整備する

○中長期セキュリティ計画

○研修／要員教育の計画

○セキュリティ対策の予算化

●全社的なセキュリティ施策を決定し、以下の事項を整備する

○セキュリティ・ポリシー

○各種の標準／規定／ガイドライン

●内部統制の観点から、定期的な監査を行う

●社員に対して、セキュリティ／コンプライアンス教育を継続的

に実施する

●セキュリティ専門会社への脆弱性診断、コンサルティング、

アウトソーシングを検討する

7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


急対応の体制を確立し、以下の活動を行う。

●情報漏洩の発生日時の特定

●被害の正確な把握（漏洩した総数、情報の内容）●漏洩原因の究明

●善後策の立案、対策の実施

●監督官庁への報告、情報開示

●相談窓口の設置、被害者へのおわび／対応

②PDCAサイクル管理の実践

他の取り組みと同様、セキュリティ対策に関しても、

PDCA（Plan/Do/Check/Act）サイクルを確立し、そ

れを管理することが必要になる。図10にそのサイクルの

例を示すが、重要なのはサイクルの周期をできるだけ短

くするということだ。今日のセキュリティ犯罪は高度化／

多様化が進んでおり、それに対処するためには、構築し

たシステムを恒常的に強化していくことが必要になる。そ

のためにも、短い周期でのPDCAサイクルが必要なの

である。

考にすることで、全社的な情報セキュリティの枠組みを

定め、何らかの事件／事故が起きた際に迅速に対応

できるようになる。特に全社的な取り組みとして必須なのは、次に説明する3つであろう。

①体制の確立

企業における情報セキュリティの位置づけを定め、そ

れを管理／運用するメンバーとしてセキュリティ委員会を

設立する。委員会のメンバーには、CIOをはじめとするシ

ステム部門のメンバーのほかに、社則の見直しや社員

への伝達／教育を担う総務部門、外部に報告する役

割を担う広報部門、全社的なリスク対策を考えるリスク

統括部門などのメンバーを参加させる。

委員会では、情報共有／意見交換をしたうえで、リ

スクの洗い出しや分析を行って対策を実施し、セキュリ

ティ関連の規定を整備していくが、取り組みが形骸化し

ないよう、定期的に会合を持つことが重要だ。

また、万が一、事件／事故が発生した際には、緊

図10：セキュリティ対策のPDCAサイクル管理

【リスク分析／評価】要求項目とビジネス・インパクトの評価●要求項目の整理●リスクの抽出と分析●ビジネス・インパクトの分析と評価●業務インパクトの分析と評価●基盤システムの分析と評価

Act

【セキュリティ・ポリシーの策定】情報セキュリティに関する基本的な考え方の見直し●ポリシーの作成（見直し）

●標準／規定の作成（見直し）●各種ガイドラインの作成（見直し）●セキュリティ要件の見直し

Plan

【セキュリティ監査】情報セキュリティの現状を把握●自己点検による日常的な診断の実施●マネジメント・プロセス・アセスメント●システム・アセスメント

Check

【システム設計／構築】セキュリティ強化のためのシステムの設計●業務レベル・セキュリティの設計／構築●基盤レベル・セキュリティの設計／構築●要件とセキュリティ対策の可視化●決定根拠の透明化●管理プロセス確立、要員教育

Do

ポリシー

監査

リスク分析設計／構築セキュリティPDCAサイクル管理

外部要因による要求

項目の追加／変更

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


また、システムの脆弱性対策に問題がなくても、システム

要件の変更や法令の施行、新種の攻撃手法の報告とい

った外部的な要因により、システムへの要求事項が追加／変更されることがある。そのため、特にリスク分析／評

価は定期的に実施するよう心掛けていただきたい。

③規定の整備

各種規定の整備は、意思決定を的確に行うために

も必要である。特にシステムの重要度や情報の機密度

については、全社的に統一された規定が求められ、そ

れに従うかたちでシステム設計に盛り込むソリューション

が決まる。

また、システム設計／運用が属人的にならないように、

技術標準／運用標準を整備しておくことが望ましい。そ

れらの標準は、すべてをIT化する必要はなく、あくまでも

網羅的であることを第一義とする。その中で、IT化すべ

き事項を、ビジネス方針やリスクの影響度などと照らし合

わせて決定する。IT化できない部分については、人手

やその他の方法でカバーする必要があるため、システム

要員を含めた社員への教育／研修、会社としての規

定／ポリシーの啓発活動などが必要になる。

図11：脆弱性対策の大まかな手順

①現状分析／情報資産洗い出し

アクタ

②リスク分析

リスク分析結果

③セキュリティ要件の定義１

④セキュリティ対策の選定 ⑤システム実装

リスク分析からの要件

リスク分析からの対抗策

脅威と対抗策のマッピング

対抗策一覧③セキュリティ要件の

定義2

法律／ガイドラインからの要件

業界ガイドライン

脅威一覧実装計画

残存リスクの確認

情報資産データ・フロー

機器稼働プロセス

データ・フロー

対抗策と実装案

主にアーキテクトなどが担当主に ITコンサルタントなどが担当

アーキテクトが取り組むべきこと

――脆弱性対策手法の確立と新技術の検討

一方、アーキテクトが取り組むべきことは、次の2つとなる。

●脆弱性対策手法の確立

1つは、まずシステム開発の上流工程における脆弱

性対策手法を確立することだ。各フェーズに関して検

討すべき事項は先に説明したとおりだが、それらの検討

作業を漏れなく円滑に行うには、その手順を確立するこ

とが重要である。

図11に、脆弱性対策の大まかな手順を示すが、特

に図中の前半部分の作業を苦手とする方もおられるかも

しれない。その場合は、もちろんITコンサルタントや業務

担当者らと共同で作業を行ってもかまわない。

なお、図中のステップ③に至るまでには、主に2とおり

の流れがある。王道は、①∼③の手順を順次実行する

というものだが、コスト面で余裕がない場合や、順守すべ

き業界ガイドラインなどが明確であり、それを要件として

採用する場合は、ステップ③の「セキュリティ要件の定

義2」から始めてもよい。

7/14/2019 IT Vol.21 00.pdf


W e b シス

テムの

脆弱

性対策


かは、保護対象となる資産の価値、Webにおける利用

形態、利用者のリテラシーなどを考慮して決定する。例

えば、保護対象の資産の価値が大きい場合でも、数年に一度程度しか使われないWebサイトに対して、非

常に堅牢かつコストの高い認証方式を採用するのは過

剰投資である。

また、Webシステムを提供する側の企業にとっては、

一般利用者のマシンのセキュリティ対策状況を管理／

統制できないという悩みがある。そのため、場合によって

はトロイの木馬のような仕掛けが組み込まれていることも

想定し、キーボードで入力された情報を盗聴（キー・ロ

ガー攻撃）されるのを防ぐための工夫も必要だ。その代

表的なものが、銀行などがインターネット・バンキングで

採用しているソフトウェア・キーボードである。

【Webアプリケーション・ファイアウォール】

Webアプリケーション・ファイアウォール（以下、WA

F）は、HTTPなどによる正規の通信に対しても、設定し

たポリシーに基づいてリクエストを選別し、不正な命令が

アプリケーション・サーバ上で実行されるのを防ぐ技術

である。Webシステムの脆弱性は開発時点でなくすこと

●新技術の評価／導入

アーキテクトが行うべきもう1つの取り組みは、セキュリ

ティの観点から、次に々登場してくる新技術などを自社のシステムに適用すべきかどうか検討することだ。例えば、

最近注目されているものとしては、次の3つが挙げられよ

う。

【システムの強度認証】

インターネット・バンキングなどのシステムでは、利用者

はWebシステム上で個人情報を入力／使用するため、

ここで情報が盗まれる危険性がある。厳密に言えば、

最初に盗まれるのはアカウント名／パスワードであり、それ

を再利用して本人になりすますことで、名前や住所だけ

でなく、口座番号などの金融情報まで盗まれてしまう可

能性がある。もっと大胆に、不正に入手したアカウントや

パスワードを利用して犯罪者が買い物をするかもしれな

い。

こうした犯罪に対処する目的から、最近ではパスワー

ドの再利用を禁止するために、新たな認証方式が導入

されるようになった。代表的な認証方式には、表7に挙

げたようなものがある。これらのうち、どの方式を採用する

表7：主な認証方式

認証形態

特徴や留意点

セキュリティ強度

利用者の負担／制約

市場定着度

パス・フレーズ

文字の組み合わせのため、

推測される危険性がある。

解読の難しさは利用者の

設定に依存

△

辞書攻撃などの総当たり

攻撃に弱い

◎

追加の負担はなし

◎

標準的な認証方法として

定着

ICカード

設計によるが、高度な識

別情報を組み合わせること

が可能

◎

電子証明書の情報が格納

できるため、強度は高い

△

ICカード・リーダと、クライア

ント側にWeb認証と連携す

るためのソフトウェアが必

要

△

政府系の申請など限定的

な採用実績はあり

ソフトウェア・キーボード

パス・フレーズと同様

○

パス・フレーズと同様。ただ

し、クライアント側が脆弱な

場合有効

◎

簡単ながら使用方法を理

解する必要がある

○

多くの銀行などで採用の傾

向が見られる

生体認証

設計によるが、高度な識

別情報を組み合わせること

が可能

◎

生体情報を利用できるた

め、強度は高い。ただし、

生体情報の管理が必要

△

生体情報認識デバイスと、

クライアント側にWeb認証

と連携するためのソフトウェ

アが必要

×

社内システムに限定される

ことが多い

ワンタイム・パスワード

パスワード盗難時でも再利

用を防御

○

パス・フレーズの再利用を

抑止できるという点で強度

は高い

△

セキュリティ・トークン媒体

の配布が必要。また、媒

体の有効期限の制限もあ

り

△

一部の金融機関など限定

的な採用にとどまる

◎：特に高い ○：高い △：普通 ×:低い

7/14/2019 IT Vol.21 00.pdf


再点

検！

特集３


Webシステムを提供する企業にとっていちばんやっか

いな点は、利用者が知らず知らずのうちに偽装サイトに

誘導され、アカウント名とパスワードを盗まれるため、自社のWebシステムでは対抗するすべがないということだ。こ

の問題を解決する手段の1つは、認証方式として、再

利用されない識別情報やワンタイム・パスワードを採用

することである。

なお、フィッシング詐欺では、利用者を偽サイトに誘導

する手段として偽メールを利用することが多い。よって、

被害を防ぐためには、間接的ではあるが、メール・サー

ビスへの対策が必要になる。例えば、登録会員に対し

て一斉メール配信サービスを提供している企業では、メ

ール本文に含まれるリンクから自社のWebサイトに誘導し

ているだろう。この場合、一斉配信するメールに署名な

どを付与し、本当に自社が送付したものであると利用者

が確認できるような手段を確保するとよい。実際、こうし

た対応をとる企業は増えており、フィッシング詐欺の被害

を減らすうえで効果を発揮している。

運用担当者が取り組むべきこと

――特権ユーザーの管理と専門機関の活用

最近、内部統制に関する重要な要求事項の1つとして、システムの運用／管理作業に対する統制が挙げら

れるようになってきた。経済産業省や金融庁などの監督

省庁が発行するガイドラインにも、IT全般統制の要求

事項としてシステムの運用／管理に関する項目が明記

されている。こうした要請に応えるために、運用担当者

に課せられた課題は大きい。自社の保守作業員が無

実であることを証明しつつ、作業の正当性を裏付けるよ

うな技術を導入しなければならないのだ。

また、高度化が進むセキュリティ犯罪からシステム／

利用者を守るには、やはりセキュリティ専門家の支援が

必要になる。最近では、Webシステムの脆弱性検査や

セキュリティ関連業務のアウトソーシング・サービスを提

供する運用会社も増えているので、そうしたサービスの

が最重要だが、攻撃手法の高度化などにより、システ

ム・リリース後に新たな脆弱性が見つかることもある。そう

したケースへの対応を目的に、近年ではWAFを導入する企業が増えている。

WAFには、主な方式として「ホワイト・リスト方式（ポジ

ティブ・モデルとも呼ばれる）」と「ブラック・リスト方式（ネ

ガティブ・モデルとも呼ばれる）」がある。このうち、ホワイト・

リスト方式は、明示的に許可したリクエスト・パターンだ

けを通過させる方式であり、ブラック・リスト方式は、その

逆に通過させないリクエスト・パターンを明示的に指定

するというものだ。どちらの方式を使うかは、企業／システ

ムの設計方針や運用などを考慮して決めることになるだ

ろう。

なお、ネットワーク用にIDS（不正侵入検知システム）

やIPS（不正侵入防御システム）を導入している企業の

場合、すでにそれらによってブラック・リスト方式が導入さ

れていることが多いので、それを補完する目的でホワイト・

リスト方式を採用するという考え方もある。

【フィッシング詐欺対策】

近年、フィッシング詐欺という攻撃手法が増加してい

る。この攻撃手法では、企業などが提供する本物の

Webサイトと酷似した偽のWebサイトをインターネット上に構築し、フィッシング・メール（偽メール）などを使ってそ

こに利用者を誘導して、ログインのためにアカウントやパス

ワードを入力させ、それを盗むという手口である。日本で

も数年前から被害が報告されるようになっており、フィッシ

ング対策協議会という団体が設立され、被害防止のた

めに啓発活動などを行っている。

現在のところ、国内ではフィッシング詐欺に対する危

機意識は必ずしも高くはないが、近い将来、これがWeb

システムにとって非常に大きな脅威となることが予想され

る。数年前の事例では、素人でも見破れるような稚拙な

メールやお粗末なWebサイトが使われていたが、昨今

では洗練されたメール／Webサイトも多く、一般の利用

者が見破るのは難しくなってきている。

7/14/2019 IT Vol.21 00.pdf



自社内に専門家を育成することを考えるよりも、外部の

サービス提供会社を活用するほうが効果的かつ経済

的だろう。さらに、ある程度大きな規模のWebシステムを運用す

るのにもかかわらず、社内にセキュリティ要員などを確保

するのが難しい場合は、セキュリティ・アウトソーシング・

サービスを利用するという手もある。実際、近年はセキュ

リティを専門とする会社がシステムの監視から運用、管

理までのサービスを提供し始めている。システム監視か

ら運用までを一貫して任せることで、高いセキュリティが

確保されるという仕組みである。

より安全なWebシステムを求めて

以上、本特集では、架空の企業の事例を題材に、

Webシステムの脆弱性対策のあり方について、最近の

動向なども交えて解説してきた。記事の締めくくりとして、

最後になぜセキュリティ対策が必要なのかを、改めて述

べておきたい。

自社が提供するWebシステムに関して、その安全性

を保証し、信頼性を担保することは、利用者から信用を

得ることにつながる。利用者の中には、セキュリティに無頓着な人もいるかもしれないが、大多数の人は、同じ商

品／サービスが同じ条件で提供されるのならば、セキュ

リティ対策がしっかりとしたWebサイトと取り引きしたいと思

うだろう。つまり、企業がより多くのビジネス・チャンスをつ

かもうと思えば、Web上のサービスのセキュリティを高める

ことは必須なのだ。

多くの企業がWebをビジネス・チャネルの1つとして活

用している今日、Webシステムにまつわる事件／事故は、

もはや他人事ではない。堅牢なWebシステムを設計／

運用する技術、セキュリティに関する洞察力は、今後の

アーキテクトに求められる重要な資質だ。より多くの読者

が、この困難な課題と向き合い、安全かつ堅牢なWeb

システムの実現に邁進されることを願う。

利用を検討する機会もあるだろう。

●特権ユーザーの管理

システムの運用／管理を行うということは、言いかえれば特権ユーザーを管理することだと言えるかもしれない。

今日の運用／管理の仕組みは、多くの場合「性善説」

に立っているため、特権ユーザーに悪意がある場合、

たちどころにシステムの脆弱さが露呈する。

このように、本来は不正が発生しないという前提の上

に成り立っているシステム運用／管理作業に対する統

制は、数あるセキュリティ要件の中でも難しい事項であ

る。これに応えるには、運用／管理作業におけるログの

記録と管理を徹底し、運用／管理作業に関する追跡

可能性と監査性を高めることが効果的だ。また、作業

申請書や報告書の提出の徹底、単独保守作業の禁

止など、ITに頼らない施策もある。さらに、特権ユーザ

ーとして監視対象に置いていることを本人に認識させるこ

とも、重要な施策の1つだ。

こうした施策をとることが、間接的にではあるが、彼ら

の無実を証明しやすくすることにつながる。

●脆弱性の監視／アウトソーシング・サービス

Webシステムは、構築フェーズのみならず、運用フェ

ーズにおいても、定期的に脆弱性検査を受けることが望ましい。現在よく実施されている脆弱性検査の方法は、

大別して2つある。

1つは一般的なもので、脆弱性検査のサービスを提

供するベンダーらがツールを使い、ポート・スキャンやリク

エスト送信を行ってシステムの脆弱性や設定ミスなどを

調べるというものだ。

またもう1つは、より専門的な方法である。これは、シス

テムを擬似的にハッキングするというもので、実際に攻撃

側の視点に立ち、手動でパラメータなどを変更しながら

検査を行う。

いずれの方法でも、報告書を作成した後は、適切な

対策の適用を支援するサービスまで提供されることが多

い。この種のサービスは専門性を強く要求されるため、

7/14/2019 IT Vol.21 00.pdf


執

筆

者

紹

介

A u t h o r ' s P r o f i l e


外資系ソフトウェア・ベンダーを経て、アーサ

ー・アンダーセン（現ベリングポイント）に入

社。同社では情報システムの開発から戦略

立案に至るまで幅広くコンサルティング業務

に携わり、豊富な経験の中で培った抜群の

バランス感覚には定評がある。現在、独立コ

ンサルタントとして活躍中。

執筆記事：P.060

荒井岳

電機メーカーのSI部門でシステム設計、プロ

ジェクト・マネジメントを経験した後、日揮情報

ソフトウェア入社。現在は、ビジネス・プロセ

ス・モデリングとデータ・モデリングを主体とし

たコンサルティング業務に従事しながら、

BPMNの普及を目指した研究会／教育／

寄稿などの活動にも注力している。


明庭聡

日本総合研究所で金融系、流通系などのシ

ステム構築に約 20 年携わった後、アーキテ

クタス設立。現在は総務省情報化統括責

任者（CIO）補佐官、稚内北星学園大学東

京サテライト校客員教授などを兼任。技術士

（情報工学部門）。専門分野は、オブジェクト

指向分析／設計、アーキテクチャ設計など。


細川努

1986年に日本IBM入社。公共事業部のS

Eとして顧客への提案活動、およびシステム

構築／運用支援を担当。その後、UNIXサー

バやインターネット基盤の設計／導入を経て、

1990 年代後半よりセキュリティ案件に参画。

2002年よりセキュリティを中心としたインフラ

ストラクチャ・アーキテクトとして活動中。


大西克美

稚内北星学園大学学長を経て、現在は早稲

田大学で客員教授を務める。Java の黎明期

よりエバンジェリストとして活躍し、Javaの普及

に大きく貢献。現在は国内の Javaユーザー

団体「日本Javaユーザー・グループ」の会長を

務める。最近はAndroidのほか、クラウド・コン

ピューティングの研究活動に従事している。


丸山不二夫

1991 年に旧安田火災海上保険（現損害保

険ジャパン）へ入社。1998 年、Web系システ

ムの開発を担当。1999 年より、Web系オンラ

イン基盤の企画／開発／展開を行い、2004

年に全社オンラインのWeb 化を完了。2005

年、損保ジャパン・システムソリューションに出

向し、現在はアーキテクチャ企画に従事。


服部浩憲

7/14/2019 IT Vol.21 00.pdf



豆蔵代表取締役社長。電機メーカーを経

て、1989年にSIerへ移籍。以後、一貫してオ

ブジェクト技術を適用したシステム開発や方法

論の導入などに携わる。2004年に豆蔵に移

籍し、2008 年より現職。技術士（情報処

理）、要求開発アライアンス理事長。最近の

著書は『要求開発』（日経BP刊。共著）など。


山岸耕二

お詫び

都合により、今号の連載『Unied Process

に学ぶ IT アーキテクトの行動指針』は休載と

させていただきます。

日本IBMでSE＆A CoE（センター・オブ・エク

セレンス）のリーダー、およびSE＆A 戦略ボー

ドの議長を務める。現在、金融／ヘルスケ

ア／運輸／通信といった業種の大規模かつ

複雑なプロジェクトに対し、SE＆A のメソドロジ

ーを適用している。


Judy Barkal

1998 年に日本IBM 入社。ITアーキテクト。

主に公共、流通をはじめとする業種の大規

模開発プロジェクトにアーキテクトとして参加

している。


長島礼

1981年に日本IBM 入社。エグゼクティブIT

アーキテクト。IBM Aca demy of Techn

ology会員。長野オリンピックの大会情報シ

ステム（Info' 98）をはじめ、さまざまな業種の

複雑なシステム開発プロジェクトでリード・ア

ーキテクトを担当。IBMのITアーキテクト研修

講師も兼任する。


大嶽隆児

アイデアクラフト代表。SE 業務の経験から

「文章を正確に読み取る読解力」の必要性

を認識し、そのための「読み書き／図解」の

研修プログラムを開発。一般社会人向けに

読解／表現／思考力を磨くための教育事業

を展開中。著書は『90分でわかる SEの思

考術』（日経BP社刊）など。


開米瑞浩

肩書はコンサルタントながら、実質的にはアー

キテクトとしての仕事が中心となっている。シ

ステム構築プロジェクトの立ち上げ時に参画

し、システム・アーキテクチャの確立、現場へ

の浸透を見届け、次の顧客へと渡り歩いてい

く。目下のテーマは、ドメイン駆動開発と親和

性の高いアーキテクチャの構築。


笠原規男

7/14/2019 IT Vol.21 00.pdf


［特集1］

アーキテクチャと性能適正なコストで最大限のパフォーマンスを引き出すための設計／管理手法を考える

［特集2］

ITエンジニア必修！7つのロジカル思考術「顧客が納得する解を導き見える化し、説得して合意を得る」

――真に役立つシステムを作るためのロジカル・シンキング・テクニックはこれだ！！

次号 Vol.22は2009年3月24日発売！

編集長名須川竜太

副編集長伊藤正子

編集浜崎貴生

後藤真里

アート・ディレクション浜本直樹

カバー・デザイン浜本直樹

制作坂内正景

写真小林直樹

営業統括三浦元裕

企画編集濱谷珠枝

広告進行細川亜希

販売推進部森本直貴

伊藤弘子

石川由希子

発行人福田悦朋

次号予告 ※内容は変更になる場合があります。

N e x t

I s s u e

S t a f f

ITアーキテクト Vol.21 00.pdf

Documents

Transcript of ITアーキテクト Vol.21 00.pdf