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

7/22/2019 IT Vol.13 00.pdf

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

I T システムを“ 創る”人のための技術情報誌

3ol.

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

システム統合技術の

今を探る

特集1●その場しのぎの対応はもはや限界！

キャパシティ・プランニング

特集2●最適なインフラ設計のための

複雑化するシステムを安定稼働させるための性能設計手法を学ぶ

情報管理／時間管理の勘所を押さえ、限りあるリソースを無駄なく活用する

アーキテクトの仕事術特集3●効率良く作業するためのノウハウを伝授！

急増する統合案件に備え、アーキテクトが押さえておくべき統合パターン／アーキテクチャ設計パターン

7/22/2019 IT Vol.13 00.pdf


13 V o l .

036

システム統合技術の今を探る急増する統合案件に備え、アーキテクトが押さえておくべき統合パターン／アーキテクチャ設計パターン

●業務指向のアーキテクチャ設計手法

アーキテクチャの発見

●ITアーキテクト必修！業務知識講座

金融業（ノンバンク）規制緩和と競争激化への対応で鍵を握るのは、「基幹システム／外部システムのスムーズな連携、顧客情報の分析と活用、そしてコンタクト・センターの戦略的な活用」

●上流工程を極める！【実践編】

要求開発の今後（前編）

●Unified Processに学ぶ、ITアーキテクトの行動指針

推敲フェーズで試行錯誤を繰り返す

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

コンサルティング・テクニックの王道「仮説検証法」を学ぶ

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

ペアを探して構造を見つけ、抽象概念のラベルを付ける

Bu s i n e s s Mode l i ng

Me thodo logy

Commun ica t i on Techn ique

特集1

078

068

138

058

E v en t Repo r t

●ITアーキテクト・サミット 2007 Summer Report

アーキテクチャ設計技術の現在

Part 1

企業システムの統合を巡る課題変化への対応を妨げる5つの問題点を明らかにする

Part 2

システム統合スタイルの選択代表的な統合スタイルの概要を押さえ、その“使いどころ”を知る

Part 3

統合施策とアーキテクチャ設計パターンシステム統合の課題を解決に導く、具体的な方策を考える

043

038

A r ch i t ec t u r e De s i g n

096

050

019

144

C o n t e n t s

Amazonギフト券、

Wiiが当たる！

読者アンケート実施中！！

詳しくは

18ページをご覧ください

7/22/2019 IT Vol.13 00.pdf


13 V o l .

C o n t e n t s

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

新日鉄ソリューションズ佐藤亘氏

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

猫と人の“関係”を考える

123

030

089

137

150

効率良く作業するためのノウハウを伝授！

アーキテクトの仕事術情報管理／時間管理の勘所を押さえ、限りあるリソースを無駄なく活用する

特集3

090

092

100

最適なインフラ設計のための

キャパシティ・プランニング複雑化するシステムを安定稼働させるための性能設計手法を学ぶ

特集2

●News & Topics

●Books

●Present

●執筆者紹介

Part 1

キャパシティ・プランニング手法の変遷メインフレームから分散型システムへ、インフラの性能分析手法はどう変わってきたのかを知る

Part 2

キャパシティ・プランニングの実践手法現状分析から性能要件の把握、アーキテクチャの決定、評価／チューニングまで、

システムの処理能力を高めるためのポイント

Part 3

性能設計技術のこれからインフラ構成要素間の関係を自動的に把握し、性能をシミュレートする「自動モデリング」のアプローチ

110

102

122

Part 1

情報管理術大量の情報を“使えるかたち”に整理し、管理する方法を身に付ける

Part 2

時間管理術限られた“時間リソース”を活用し、作業効率を上げるために

129

118

7/22/2019 IT Vol.13 00.pdf


0 1ITアーキテクト Vol.13

アーキテク

チャ

設

計技術の

現

在今年8月9日、本誌主催のテクニカル・セミナー

「ITアーキテクト・サミット（ITAサミット）2007 Summer」が、

東京コンファレンスセンター・品川において開催された。

2005年の第1回開催以来、5回目の開催となる同セミナーでは、

「アーキテクチャ設計技術の現在」というテーマの下、

国内の著名エンジニアらが壇上に立ち、

合計10のセッションが実施された。

ここでは、それらのセッションの内容を振り返りつつ、

ITAサミット 2007 Summerの全容をリポートする。

ITArchitectSummit

2007Summer

R e p o r

7/22/2019 IT Vol.13 00.pdf


0 2 0 ITアーキテクト Vol.13

SaaSが変える

企業システムの作り方

今日、IT（情報技術）はますます複雑化し

ているが、それを駆使して、組織／ビジネ

スに適切なアーキテクチャを組み上げるの

がアーキテクトの務めである。そのアーキ

テクト諸氏の情報収集活動を支援するべ

く、「アーキテクチャ設計技術の現在」をテ

ーマに据えて開催されたITAサミット 2007

Summerでは、業界の著名エンジニアらに

より、アーキテクチャ設計にかかわる各種

技術の最新動向や、各技術／関連製品

を使いこなすうえでのポイントなどが示され

た。

初めの基調講演に登壇したのは、長島

哲也氏（日本IBM 公共事業CTO／技術

理事／ITアーキテクト。写真1）だ。『Saa

Sで企業システム開発はどう変わるのか』と

題した講演で長島氏は、現在システム開

発の分野で多くの関心を集めている「Saa

S（Software as a Service）」について、

その特徴や市場動向、企業システムへの

適用法などを解説した。

近年のWeb 2.0の潮流の中で登場し

てきたSaaSは、ソフトウェアを、従来のよ

うにパッケージとしてではなく、その機能を

「サービス」として提供するというものだ。ソ

フトウェアはSaaSプロバイダーが運営する

サーバ上で動作し、それをネットワークを介

して、必要なときに必要なだけ利用する。

これはASPと同じ形態であり、ASPとの違

いが議論になることもあったが、長島氏に

る情報サービスをマッシュアップして内外

に提供するという点で、SaaSのコンセプト

と合致している」（長島氏）。

SaaS のモデルを適用すれば、各自治

体が提供するサービスを他の自治体でも

活用可能になるほか、共同で運用センタ

ーを設けることで、システム運用の効率化

やコストの適正化を図ることができる。こう

したメリットが評価され、今後は自治体での

SaaS導入が加速すると見られる。

SOAによる社内システムとの連携

ところで、企業（や自治体）がSaaSを導

入する際には、多くの場合、各社が独自

に運用する社内システムとの連携が必要

になる。この「社内システムとの連携」をど

う実現するかが、企業にSaaSを導入する

うえでの大きな課題だが、その解決にあた

IT ArchitectSummit

2007Summer R e p o r t

アーキテ

クチャ

設計技

術の

最新潮

流を

押さえる

ITAサミット 2007 Summerでは、

業界を牽引するベンダー各社によるセッションと、

本誌選定の有識者による基調講演および

テクニカル・セッション（ITAセッション）が実施された。

ベンダー各社のセッションについては後続のリポートをご覧いただくとして、

ここでは基調講演とITAセッションの内容を紹介する。

今、アーキテクトは

何に注目すべきか

よれば、「今日では、もはやSaaSの定義

やASPとの違いなどは重要ではないという

雰囲気だ」という。

もっとも、厳密な定義はさておき、SaaS

を含むWeb 2.0全体の潮流にどのようなコ

ンセプトが秘められているのかを押さえてお

く必要はあるだろう。長島氏が挙げたWeb

2.0のコンセプトとは、次のようなものだ。

●必要な機能を、いつでも、だれでも、簡

単に使える。また、それらの機能は、標

準のインフラ上で提供される

●状況に応じて即座にアプリケーションを

作って利用できる。しかも、リッチな使い

勝手を備え、既存のサービスを組み合

わせられる

●ユーザーによるコミュニティ活動により、

一種の集合知が形成される

●ロングテールのビジネス・モデルが中心

となり、自社の力だけでなく、“社会の力”

も利用してシステムを組み上げる

このような流れの中に位置するSaaSの

普及推進に向けて、現在、政府／自治体

も力を入れ始めている。

例えば今年4月、総務省はASPの推進

団体とともに、SaaS/ASP の普及促進に

向けた協議会を発足させた。同協議会で

は、SaaS/ASPの安全性／信頼性確保

に向けた指針の策定や、SaaS/ASP 事

業者の認定制度の検討などを行うという。

また、地方自治体間でのITシステム連携

を推進する全国地域情報化推進協会が

構想する「地域情報プラットフォーム」は、

「各自治体や公共インフラ会社が提供す

7/22/2019 IT Vol.13 00.pdf



にSOA のサービスとSaaSを簡単に組み

合わせられる環境が鍵になる」（長島氏）。

今後は、そうした環境を用いて、SaaSと

SOAの世界をまたいだ企業アプリケーショ

ン開発が行われるようになるだろう。

では、そうした開発スタイルが目指すゴ

ールとは何か。それは、「工場の生産ライ

ンで実践されている『社内で作った部品や

社外から調達した部品を組み合わせて製

品を作る』という開発スタイルを、システム

開発の世界に適用すること」（長島氏）で

ある。このゴールに向けてどのようなアプロ

ーチをとるかが、アーキテクト諸氏の腕の

見せどころになるわけだ。

システム統合技術の現在

今後アーキテクトが挑む課題がSaaS/

SOAだとすれば、一方で、今まさに多くの

アーキテクトが直面している課題がある。

それは「システム統合」だ。企業の合併や

提携の動きが活発化するのに伴い、各社

のビジネス活動を支えるITシステムの統合

が急務の課題となっている。小野沢博文

氏（アクセンチュアプリンシパル。次ペー

ジの写真2）のセッション『システム統合技

術の“今”を探る』では、そのシステム統合

で利用できる代表的な統合パターンが紹

介された。

システム統合は、狭い範囲で見ればシ

ステム・アーキテクチャの話だが、これを成

功させるためには、「システムを取り巻くビ

ジネス／IT環境全体を視野に入れなけれ

ばならない」（小野沢氏）。そこで氏が提示

したのが、ITを「IT戦略の方向性」、「ITア

ーキテクチャ」、「ITマネジメント」という3つ

の階層でとらえる視点だ。システム統合に

臨む際には、この3つの階層のそれぞれに

ついて、あらかじめ方針を明らかにしておか

なければならない。そのうえで、「データ」、

「アプリケーション」、「統合」、「インフラ」

という4 つのアーキテクチャについて課題

を識別し、解決する。例えば、アプリケー

ション／統合アーキテクチャに関する主な

課題としては、次の5つがある。

●システム統合を難しくするアプリケーショ

ン・サイロの解消

●バッチ型統合の短所であるデータ鮮度

の低下の解消

●統合を繰り返した継ぎはぎ状態のシステ

ムの保守／運用コストの削減

●ベンダー固有の技術へのロックインの

回避

●統合技術の陳腐化の回避

小野沢氏は、これらの課題を解消する

ための具体的な統合パターンとして、「媒

体渡し」、「ファイル転送」、「ETL」、「共

有データベース」、「非同期メッセージン

グ」、「同期メッセージング」を挙げ、それぞ

れの特徴や長所／短所、そして使いこな

しのポイントを解説した。

なお、小野沢氏執筆による本号の特集

記事『システム統合技術の今を探る』では、

本セッションの内容をさらに深掘りするかた

ちで、上記の統合パターンやアーキテクチ

ャ設計パターンについて解説している。ぜ

って切り札になるのが「SOA（Service

Oriented Architecture）」である。社内外

のシステムをサービスとしてとらえ、その連

携を実現するSOAのコンセプトは、SaaS

との親和性が高いのだ。

長島氏は、SOAの導入パターンをいくつ

か示したうえで、SaaSを含むWeb 2.0を企

業システムに取り込む際に提供すべきもの

として、次の環境を挙げた。

●SOAのサービスとSaaSを簡単に組み

合わせられる環境

●既存のシステムを簡単にSaaS化できる

ようにする環境

●リッチなユーザー・インタフェース（UI）を

構築することのできる環境と、軽量（Lig

ht-weight）なプログラミング環境

●セキュアなコミュニティ支援環境（社内

ブログや社内SNSなど）

これらの環境を準備することで、社内シ

ステムとSaaSをマッシュアップによって連

携させる、いわゆる「エンタープライズ・マッ

シュアップ」が実現できる。それには、「特

写真 1：IBMで長年 IT アーキテクトを務めてきた長島氏

は、SaaSとSOAを組み合わせた次代のシステ

ム・アーキテクチャの方向性を示した

7/22/2019 IT Vol.13 00.pdf


0 2 2 ITアーキテクト Vol.13

業務効率を左右する大きな要因の1つとな

っている。そうした流れを受けて関心が集

まっている技術が「リッチ・クライアント」だ。

『リッチ・クライアント最新事情』と題した田

中達雄氏（野村総合研究所情報技術

本部情報調査部上級研究員。写真4）

のセッションでは、このリッチ・クライアント

に関する最新動向が紹介された。

田中氏によれば、現在、リッチ・クライ

アントは第二の成長期にあり、「リッチ・ク

ライアント・プラットフォームの覇権を巡る

争い、企業システムへのよりリッチなUIの

適用、そして情報伝達の流れを変えるウィ

ジェットやガジェットの台頭という3つの大き

な動きが見られる」（田中氏）。このうち、

企業システムのUIのリッチ化については、

パッケージ・ソフト任せで使い勝手がばらば

らだった従来のUIから脱却し、各種システ

ムに統一的なUIを適用しようという流れが

加速している。

一方、社外向けに提供するアプリケー

ションについても、UIの重要性が高まって

IT ArchitectSummit

2007Summer R e p o r t

写真2：「システム統合に臨む前に、まず明確なIT戦略を

立てることが重要だ」と指摘する小野沢氏写真 3：進藤氏は、自身の研究や現場への適用経験な

どに基づき、ユーティリティ・コンピューティングの

各種技術について解説した

ひこちらの記事もご覧いただきたい。

迫り来るユーティリティ・

コンピューティングの時代

アーキテクチャ設計技術と言えば、イン

フラ分野の動きも押さえておかなくてはなら

ない。この分野をカバーしたのが、進藤

朋和氏（新日鉄ソリューションズシステム

研究開発センターシステム基盤技術研

究部主務研究員。写真3）によるセッショ

ン『インフラ技術の最新潮流』だ。

ネットワークや各種コンピュータ資源から

成るITインフラは今日、社会活動を支える

重要な基盤の 1つとして機能している。そ

のITインフラに現在求められているのが、

電気やガス、水道などと同様に、「使いた

いときに、使いたいだけ利用でき、料金は

使った分だけ支払う」という利用形態、す

なわち「ユーティリティ・コンピューティング」

の実現だ。進藤氏は、このユーティリティ・

コンピューティングを支える技術を、「プラッ

トフォーム」、「仮想化」、「プロビジョニン

グ」、「ワークロード」、「自動化／自律運

用」の5つに分類し、それぞれの特徴や最

新動向を紹介した。

なお、ユーティリティ・コンピューティング

は、「ITシステムの柔軟性確保」の観点か

ら、SOAとともに語られることが多い。両者

の関係に言及した進藤氏は、「SOAが目

的とする変化への迅速な対応や、SOAの

導入にあたりインフラ面で問題となるサイ

ジングの複雑化などに対応するには、シス

テム・リソースを柔軟に割り当てることが可

能な仮想化技術が重要になるだろう」との

見解を示した。

いずれにせよ、複雑化が進むITインフラ

の設計／管理を簡素化していくには、ユー

ティリティ・コンピューティングの技術をどの

ように取り込んでいくかが鍵を握る。それで

は、それらの技術によって簡素化されたITイ

ンフラの設計に際し、今後アーキテクトが

考慮すべきことは何か。進藤氏によれば、

それは「サービス・レベルの設計」である。IT

インフラの分野でも、アーキテクトの活動領

域はより“上流”にシフトしていきそうだ。

今後のUI設計の鍵は

「顧客価値体験の創出」

続いて、Webアプリケーションの世界に

目を向けてみよう。インターネットが企業の

重要なビジネス・インフラとなった現在、ユ

ーザーに対してWeb上でどれだけ高い利

便性を提供できるかが、ビジネスの成否や

7/22/2019 IT Vol.13 00.pdf



鈴木氏は、現在、業務アプリケーション

のアーキテクチャに求められていることは2

つあると主張する。

「1つは安定していて、長期的に維持／

運用できること。こうした特性を持つアーキ

テクチャを『サスティナブル・アーキテクチ

ャ』と呼ぶ。また、もう1つは『わかりやすさ』

だ。これは、開発／運用に際しての敷居

を下げ、開発／運用者の教育コストを低

減することに貢献する」（鈴木氏）

問題は、この2つの特性を備えたアーキ

テクチャをどう作るかだが、それには、ITシ

ステムにかかわるステークホルダー（利害

関係者）の関心事に応じてアーキテクチャ

をレイヤ化すればよい。具体的には、経営

層や管理者層向けのレイヤとして「概念レ

イヤ」を設け、ユーザー層などに向けて「論

理レイヤ」を作る。また、アーキテクチャや

基盤エンジニア向けには「物理レイヤ」を

設ける。

これらのうち、特に業務アプリケーショ

ン開発で重要になるのが論理レイヤだ。こ

のレイヤは、「ユーザー企業の業務担当者

とITエンジニアがアーキテクチャに関する

コンセンサスをとる部分」（鈴木氏）である。

このレイヤでは、業務処理に合わせて論

理的なコンポーネントを設計し、さらに業務

処理のタイプごとにアーキテクチャを統一

することで、処理のパターン化やコンポー

ネント化などが図れる。それらを踏まえてア

ーキテクトが物理レイヤを設計することで、

サスティナブル・アーキテクチャが実現でき

るわけだ。

なお、本セッションの中で紹介されたア

ーキテクチャ設計手法については、鈴木

氏が本誌連載『業務指向のアーキテクチ

ャ設計手法』で詳しく解説している。氏の

セッションに興味を持たれた方は、こちらの

記事も参照されるとよいだろう。

＊＊＊

以上、ここではITAサミット 2007 Sum

merのもようをリポートした。5回目の開催と

なった今回のサミットも、300名を超える来

場者を得て盛況のうちに幕を閉じることが

できた。ご来場いただいた方々には心から

感謝したい。

次回のITAサミットは、「アーキテクチャ・

ロードマップ」というテーマの下、12月5日

の開催を予定している。企業のビジネス戦

略も踏まえたITシステムの長期的な計画

策定の取り組みについて、経験豊富なエ

ンジニアらを講師に迎えてノウハウを披露

していただく予定だ。ぜひご参加いただき

たい。

いる。インターネット・ビジネスの世界で生

き残っていくためには、顧客により使い勝

手の良い UIを提供することが不可欠だか

らだ。加えて、UIの使い勝手や見栄えなど

の表層的な部分だけでなく、「『感動』や

『発見』など、人間の内面的な部分にまで

踏み込んで、顧客によりよい経験の機会

を提供することが、他社との差別化を図る

うえで大きなポイントになる」（田中氏）とい

う。田中氏はこれを「顧客経験価値」と呼

び、今後 ITエンジニアがこの価値の創出

に貢献していくことの重要性を訴えた。

“業務指向”でアプローチする

アーキテクチャ設計

ITAサミットでは、アーキテクチャ設計手

法にまで踏み込んだセッションも実施され

た。鈴木高弘氏（ビズモ代表取締役／

チーフ・アーキテクト。写真5）のセッション

『“業務指向”で変わる！企業情報システ

ム・アーキテクチャの作り方』がそれである。

写真 4：田中氏のセッションでは、それぞれの顧客に最

適化されたWebサイトを設計するための各種手

法も紹介された

写真5：「サスティナブル・アーキテクチャの実現では、専

門分野の異なるアーキテクトによるチーム作業が

不可欠だ」と指摘した鈴木氏

7/22/2019 IT Vol.13 00.pdf


030 IT アーキテクト Vol.13

News & Topics

アクチュエイトジャパン、BIツールの新版を発売

アクチュエイトジャパンは今年8月、

リポーティング・ツール「Eclipse BIR

T」をベースにしたBI（Business Inte

lligence）ツールの新版「Actuate 9

SP2」の販売を開始した。同製品は、

リポートの構築基盤「 Ac tu at e

BIRT」やWebブラウザ・ベースのリポ

ート作成環境「同BusinessReport

Studio」など6つの製品から成る。新

版では、PDF出力の品質向上が図ら

れたほか、表示データに応じてサイズ

を自動調整するオート・サイズ機能や

レイアウトをサポートするグリッド・ライ

ン機能などが追加された。

ITシステム開発を巡る

最新動向を伝える

サン、OpenJDKコミュニティへ新ライセンスの提供を開始

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

年8月、Java SE 6対応の互換性テ

スト・キット「JCK（Java Compati

bility Kit）」の新ライセンス「OpenJ

DK Community TCK（Technology

Compatibility Kit）License」の提供

を開始した。これにより、開発者は自

身が開発したコードとJava SE 6の

互換性をJCKによってテストでき、そ

れに合格すれば「Java Compatible」の商標とロゴの使用が可能とな

る。同社は、ライセンスの使用条件と

して、「成果物をGPL v2の下に配布

すること」としている。

SAPとアドビ、「SAP ERP」の国内販売体制の強化に向け協業

SAPジャパンとアドビシステムズは

今年 7月、SAPが提供する「SAP

ERP」の国内販売体制の強化に向

けて協業すると発表した。かねてより

両社は、SAPアプリケーションのフロ

ントエンドをPDF形式で実現するため

のソフトウェア「SAP Interactive F

orms by Adobe」を共同で開発／提

供してきた。協業により、両社は同

製品の技術知識を集約した「アドビ・

コンピテンスセンター」を設立。SAP

の営業支援のほか、同社のコンサル

タント／パートナー企業に向け、技術

情報の提供などを行うという。

米国IBM、標準規格にかかわる150以上の技術特許を開放

米国IBMは今年7月、同社が有す

る技術特許の一部を開放すると発表

した。対象となるのは、SOAP やSA

ML（Security Asser tion Markup

Language）、XML Schema、SCA

（Service Component Architec

ture）など、SOA／Webサービス関連

の標準規格を実装するにあたって必

要となる150 以上の技術特許。開

発者やユーザーがそれらの技術を利

用する際、従来は同社とロイヤリティ・

フリーのライセンス契約を結ぶ必要が

あったが、今後はそれが不要となり、

だれでも永続的に利用できるという。

オラクル、「Database 11g」を日本市場へ投入

日本オラクルは今年9月、データベ

ース製品の新版「Oracle Database

11g」の国内出荷を今年10月に開

始すると発表した。新版の特徴は、本

番環境で発生した処理をすべてキャプチャし、テスト環境で再現する「Ora

cle Real Application Testing」や、

待機系のリソースを通常時のバック

アップ取得処理などに利用できる

「Oracle Active Data Guard」とい

ったオプション製品が追加された点。

今後同社は、パートナー各社と共同

でDatabase 11gの技術者育成トレ

ーニングなどを実施していくという。

日本BEA、Web 2.0対応の3製品を出荷へ

日本BEAシステムズは今年7月、

SOA対応製品群「AquaLogic」の新

ラインアップとなるWeb 2.0 対応製

品の出荷を開始した。出荷されたの

は、Webページのオーサリングが可能なWebアプリケーション開発ツール

「BEA AquaLogic Pages 1.0」と、

各種Webリソースのマッシュアップを

実現する「同Ensemble 1.0」、企業

内に分散する情報の検索／分類を

可能にする「同 Pathways 1.0」の3

製品。各製品の無償評価版は、同

社のWebサイト（http://www.beasy

s.co.jp/evaluation/）から入手できる。

厚生労働省、JREの脆弱性について警告

厚生労働省は今年7月、同省の

電子申請／届け出システムに利用し

ているJava 実行環境に、セキュリテ

ィ・ホールを確認したと発表した。該

当するのは、サン・マイクロシステムズが提供するJRE 1.4.2_10。サン

によれば、今回発表された脆弱性は

最新バージョン（1.4.2_15）ですでに

解消済みだという。被害の回避方法、

および脆弱性を解決した申請アプリ

ケーションの入手方法については、

厚生労働省の Webサイト（http://

hanyous.mhlw.go.jp/houdou/2

007/07/）に解説がある。

7/22/2019 IT Vol.13 00.pdf


03IT アーキテクト Vol.13 03

日本HP、「HP Software」の拡販戦略を展開

日本HPは今年 7月、管理ソフトウ

ェア製品群「HP Software」の中小

企業向け拡販のために、ダイレクト販

売支援用 Webサイトおよびコールセ

ンター「HP Software Direct」のサ

ービスを強化すると発表した。具体的

には、同サイト／コールセンターを通

じて、HP Softwareの無料体験トレ

ーニング・コースや自動負荷テスト・ツ

ール「HP LoadRunner software」の評価版メディア（日本語版）などを

提供する。申し込みは、同社の専用

Web ページ（http://www.hp.com/

jp/hpsoftware）で受け付ける。

テクマトリックス、構造分析ツールの販売を開始

テクマトリックスは今年7月、アーキ

テクチャ分析ツール「Lattix」の開発

元である米国ラテックスと総販売代

理店契約を締結し、同ツールの販売

を開始した。Latt ixは、製造業などで

用いられるプロセス分析手法「DSM

（Dependency Structure Matrix）」

をソフトウェアに適用したもの。Java

や.NETなどで実装されたプログラム

の構造を分析し、各構成要素間の依存関係を表形式で表示する。その

ほか、パーティショニングや影響度分

析、メトリクス分析といった機能も備

えている。

F5、Webアクセラレータの新版でSSL通信をサポート

F5ネットワークスジャパンは今年8

月、Webアクセラレータの新版「BIG-

IP WebAccelerator v9.4.2」を発表

した。新版では、非対向型／対向型

の設置を組み合わせて利用することができ、対向型で設置すれば、SSL

通信によるアプリケーションのダウン

ロードやコンテンツ・アクセスの高速

化も可能となる。新版は、スタンドア

ロンで動作する「BIG-IP WebAcc

elerator 4500」としてのほか、同社

のトラフィック管理製品「BIG-IP Loc

al Traffic Manager」上で動作する

モジュールとして提供される。

NTTデータイントラマート、開発／運用環境の新版を発売

NTTデータイントラマートは今年7

月、Webシステム開発／運用基盤の

新版「intra-mart WebPla tform

ver.6.1」を8月に発売すると発表した。

新版では、ERP連携モジュールの追

加やワークフロー用モジュールの強化、

セキュリティ機能の強化が図られた。

また、付属するWebシステム開発用

Eclipseプラグイン「eBuilder」では、

オープンソースのAjax 開発フレームワーク「マスカット」が組み込まれたほか、

JavaScript開発時にビジュアルな環

境で画面レイアウトの定義や単体テス

トを行うことが可能となった。

グレープシティ、パフォーマンス管理製品を発売

グレープシティは今年8月、パフォー

マンス管理ツールの新版「JProbe

7.0J」を9月に発売すると発表した。

同ツールは、Javaプログラムの実行

速度やメモリ使用量、テストの進行状況などをリアルタイムに計測／解析し、

結果を視覚的に表示するというもの。

新版では、JVMのプロファイリング用

標準インタフェースである「JVMTI

（Java Virtual Machine Tool In

terface）」に対応したほか、すべての

計測／解析作業を同一コンソール上

で行えるようになった。価格は1ライセ

ンス当たり38万6,400円から。

九州発のコミュニティRubyビジネス・コモンズ開設へ

Rubyビジネス・コモンズ設立準備

委員会は今年7月、地域密着型の

オープン・コミュニティ「Rubyビジネス・

コモンズ」を設立した。同コミュニティ

の主な活動目的は、プログラミング言語「Ruby」に関する知識／ノウハウ

の共有を通して、参加メンバー間でビ

ジネスの活性化を図ること。九州を本

拠地に開かれたコミュニティを目指し

ており、参加にあたって地域や企業

／団体／個人は問わない。今年度は、

RubyおよびWebアプリケーション・フ

レームワーク「Ruby on Rails」の知

識の普及を中心に活動するという。

日本IBM、SOA対応システムの開発／実行環境を発売

日本IBMは今年7月、SOA対応シ

ステム開発／実行環境「WebSph

ere Business Services Fabric

V6.0.2」の出荷を開始した。同製品

は、業務単位で定義した「ビジネス・

サービス」を動的に組み合わせること

で、システムの短期開発を実現する

というもの。サービスの設計／開発

／テスト環境「Fabric Tools Pack」

とサービスの実行／管理環境「Foun

dation Pack」から成る。また、併せ

て同社は、金融／通信など4 業種に

特化したビジネス・サービスのテンプ

レート集を出荷している。

日本CA、性能管理製品群をリリース

日本CAは今年8月、ネットワーク・

パフォーマンス管理製品群の新版

「CA eHealth r6」の出荷を開始した。

新版では、新たに管理用ユーザー・

インタフェース「OneClick」が導入さ

れたことにより、ユーザーのグループ

化やアカウント管理などが容易に行え

るようになったほか、ポータル機能が

強化され、システム障害とITサービス

の関連性を可視化することが可能と

なった。同社は今後、先行して英語

版の販売が行われているリポーティン

グ・エンジン「Report Center」の日本

語版の提供も予定しているという。

日本BEAシステムズ、BPM関連の2製品を出荷開始

日本BEAシステムズは今年8月、

BPM製品の新版「BEA AquaLogic

BPM 6.0」とBPMツール・スイート

「同BPM Collaboration Editon」の

出荷を開始した。前者は、ビジネス・

ルールの設定がグラフィカルに行える

点が特徴。一方後者は、「BEA Aq

uaLogic BPM Suite」をはじめとす

る3製品から成り、それらを連携させる

ことで複雑なプロセスを効率的に管

理できるという。両製品の無償評価

版は、同社の Webサイト（http:/ /

www.beasys.co.jp/evaluation/）

からダウンロード可能。

7/22/2019 IT Vol.13 00.pdf



米国アドビシステムズ、「ColdFusion 8」を提供開始

米国アドビシステムズは今年7月、

アプリケーション・サーバの新版「Ado

be ColdFusion 8」の提供を開始し

た。新版では、「Adobe Flex」や「同

PDF」など同社が提供する各製品／技術との連携が強化されたほか、

.NETとの連携やWindows Vistaへ

の対応が図られた。ColdFusion 8は、

エンタープライズ版とスタンダード版

の2つのバージョンで提供され、開発

のみに使える開発者エディションは無

償で利用することが可能。ColdFus

ion 8日本語版も含め、国内向けの

出荷時期は9月末を予定している。

CTC、次世代ITインフラのコンセプトを提唱

伊藤忠テクノソリューションズ（CT

C）は今年 7月、次世代ITインフラの

コンセプトとして「Trusted Infrast

ructure」を発表した。同コンセプトは、

内部統制やコンプライアンス、セキュリティ、事業継続性といった現在の

企業が対応を求められている課題に

対して、ITインフラの視点から解決を

図るというもの。同社は今後、同コン

セプトを推進する40人規模の専任組

織を設置し、顧客企業にITインフラを

提案していく。また、ITインフラに関す

る研究を大学や公的機関とも連携し

て進めていくという。

ビジネス・ルール管理ツール

ILOG JRules 6.5アイログ

製品名 ILOG JRules 6.5

稼働環境【対応開発環境】Eclipse

価格 873万円〜

出荷時期 2007年9月8日

発売元アイログ（☎：03-5211-5770）

「ILOG JRules 6.5」は、ビジネス・

ルール管理ツールの新版。新たに、

同ツールが管理するビジネス・ルール

にアクセスするためのWebサービス

「TDS（Transparent Decision Ser

vice）」をプログラミングレスで作成す

る機能が追加されたほか、「セマンティ

ック・クエリ」のサポートにより、ビジネ

ス・ルールの検索機能などが強化され

た。

統合アプリケーション管理ツール

AdventNet ManageEngineApplications Manager 7.4アドベントネット

製品名 AdventNet ManageEngine Applicati

ons Manager 7.4

稼働環境【対応OS】Windows、Linux

【対応Webブラウザ】Internet Explorer

5.5以上、Mozilla Firefox 1.0以上

価格 Professional Edition：28万1,400円〜

／Enterprise Edition：519万5,400円〜

出荷時期出荷済み

発売元アドベントネット（☎：045-444-3880）

「AdventNet ManageEngine

Applications Manager 7.4」は統

合アプリケーション管理ツールの新版。新たにPing 監視や監視グルー

プ・ビューなどの機能が搭載されたほ

か、監視グループ内にサブグループ

を作成できるようになった。

E vent Calendar

LinuxWorld OpenSolutions

Conference 20079月27日（木）〜28日（金）

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

連絡先：LinuxWorld OpenSolutions

Conference 事務局

E-mail：[email protected]. jp

URL：http://www.idg.co.jp/expo/lwe/

CEATEC JAPAN 200710月2日（火）〜6日（土）

会場：幕張メッセ

連絡先：CEATEC JAPAN運営事務局

☎：03-5402-7603 FAX：03-5402-7606

E-mail:[email protected]

URL：http://www.ceatec.com/2007/ja/visitor/

アシストフォーラム200710月11日（木）

会場：ウェスティンホテル東京

連絡先：アシストフォーラム2007事務局

☎：03-5276-5850

E-mail：[email protected]：http://www.ashisuto.co. jp/event/af2007/

Security Solution 200710月24日（水）〜26日（金）

会場：東京ビッグサイト

連絡先：Security Solution 事務局

☎：03-6811-8083 FAX：03-5421-9170

E-mail：[email protected]

URL：http://expo.nikkeibp.co.jp/secu-ex/2007/

SymantecVision200711月2日（金）

会場：ウェスティンホテル東京

連絡先：SymantecVision2007運営事務局

☎：03-3537-2218

E-mail：vision- info2007@e-ent ry.net

URL：http://jp-enterprisesecurity.symantec.com/

product/sv2007/

Embedded Technology 2007／

組込み総合技術展11月14日（水）〜16日（金）

会場：パシフィコ横浜

連絡先：Embedded Technology 2007運営事務局

☎：03-3219-3563 FAX：03-3292-1813

E-mail：[email protected] .jp

URL：http://www.jasa.or.jp/et/

SaaS World 200711月28日（水）〜29日（木）

会場：東京ミッドタウン・ホール

連絡先：SaaS World統括事務局

TEL：03-5800-4830 FAX：03-5800-3973

E-mail：[email protected]：http://www.idg.co.jp/expo/saas/

ITアーキテクト・サミット 2007 Winter12月5日（水）

会場：東京カンファレンスセンター・品川

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

TEL:03-5510-4079 FAX:03-5510-4078

E-mail：[email protected]

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

9月

UMLモデリング・ツール

Enterprise Architect 7.0スパークスシステムズジャパン

製品名 Enterprise Architect 7.0

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

価格ダウンロード版：1万7,325円（1ライセン

ス）〜／パッケージ版：オープン価格

出荷時期出荷済み発売元スパークスシステムズジャパン

（E-mail：[email protected]）

「Enterprise Architect 7.0」は

UML 2.1に対応したUMLモデリン

グ・ツール。新版では、組み込み機

器の設計／開発で多く使われる状態

遷移表とステートマシン図の相互変

換機能が搭載された。また、UMLの

クラス図の内容をC言語に変換して

出力できるほか、アンドゥ／リドゥ機能

も強化されている。

プロジェクト管理ツール

TRICHORD 1.2チェンジビジョン

製品名 TRICHORD 1.2

稼働環境【対応OS】Windows XP

【対応Java環境】J2SE 5.0_10以上

（Java SE 6.0はサポート対象外）

価格 2万1,000円（1ユーザー）／キャンペーン

・パック：10万5,000円（10ユーザー）

出荷時期出荷済み

発売元チェンジビジョン（☎：03-3349-5255）

「TRICHORD 1.2」は、ソフトウェ

アかんばんやバーンダウン・チャート、

ニコニコカレンダーといった機能を搭

載したプロジェクト管理ツール。新版

では、各機能の利便性向上が図られ

たほか、マインドマップとの連携機能、

管理情報のツリー表示機能などが追

加されている。

11月

10月

12月

7/22/2019 IT Vol.13 00.pdf


03IT アーキテクト Vol.13

――SOAを効果的に導入するために、

企業はまず何をするべきか。

SOAの導入にあたっては、まず長期

的なビジョンを描いたリファレンス・アー

キテクチャが必要になる。この中には、

アーキテクチャにかかわる原理／原則

を定めたガイドラインやポリシーなどが含

まれる。よく「SOAの導入には何年もか

かる」などと言われるが、これは何年もたたなければ成果が得られないという意味

ではない。綿密に練ったプランを、段階

を踏んで実践していく必要があるのだ。

そのためには、ロードマップと明確な方

向性が必須となる。

また、ユーザー企業にしかできないこ

とがある。製品ベンダーやSIer は、企

業組織や内部のガバナンスの変更にま

Interv iew

ではタッチできない。これはSOAを導入

する側の企業が主体的に行動するしか

ない部分だ。ただし、ガバナンスにはい

くつかのパターンがあるので、外部から

導入の指針や留意点についてアドバイ

スを受けることは可能だろう。

加えて言えば、コーポレート・リーダー

シップも非常に重要となる。なぜなら、

ビジネスの都合から、「リファレンス・アーキテクチャには反するが、IT戦略の方

向性を変えなければならない」という状

況が少なからず生じるからだ。その際に

は、ビジネス・リーダーが全体の意思決

定をした後、さまざまなレベルでの検討

がなされ、最終的にリファレンス・アーキ

テクチャの軌道修正を行うことになる。

――日本では、IT 部門の発言力が弱く、

それがSOA導入の障害になっていると

いう声も聞かれる。この問題について

どう対処していけばよいか。

確かに現状、多くの企業において、

IT部門は戦略的に利益を生む部門と言

うよりも、コスト・センター的な扱いをされ

ている。実際、業務の70〜75％が既

存システムの保守に終始しているところ

も多い。こうしたIT部門のあり方を変え

ていくためには、ビジネスの変化／要求

にIT 部門が素早く対応して、着実にビ

SOA成功の“鍵”は、

企業ガバナンスの確立とアーキテクトの育成日本BEAシステムズは今年7月、「Moving SOA to Enterprise」をテーマに、

アーキテクトを対象としたカンファレンス「Arch2ArchSummit2007」を

開催した。同社は、早くからSOAへの取り組みを開始し、多くの企業の

SOA導入を支援する中で、さまざまなノウハウを蓄積してきたという。

本誌は、同カンファレンスの基調講演のために来日した

米国BEAシステムズエンタープライズ・アーキテクチャ担当副社長（VP）の

クリフ・ブース氏に、SOA導入に向けた取り組みのポイントを聞いた。

「われわれもリファレンス・アーキテク

チャの作成支援を行っている」と語

るブース氏

米国BEAシステムズエンタープライズ・アーキテクチャ担当VPに聞く

ジネス・バリューを提供するしかない。

――基調講演では、社内におけるアー

キテクトの必要性を強調していた。今

後、求められるアーキテクト像とはどの

ようなものなのか。

1980年代から1990年代の後半にかけて、EA（Enterprise Architecture）グ

ループといった概念が生まれ、アーキテク

ト的な役割を担う存在が現れ始めた。だ

がいつのころからか、彼らの業務は社内

で利用する技術を選定したり、標準を策

定したりすることに特化してしまい、それ

らをどう活用していくかまでは考えなくなっ

ているのが実情だと思う。今後はこうし

た立場から脱却し、アーキテクトがアーキ

テクチャに関するすべての意思決定を行

っていく必要があるだろう。

そこで私が推奨したいのが「SOAア

ーキテクト・オフィス」の設置だ。そこで

は、すべてのアーキテクチャに関する意

思決定をコントロールし、ガバナンスを

行う。プロジェクトごと、部門ごとに段階

的なSOA導入を進めていく中で、その

開始時点からすべての権限を持つのが

このオフィスだ。また、SOAの導入に際

しては、「既存資産をいかにサービス化

していくか」といったことも鍵になるので、そうした部分も併せて管理していくこと

になるだろう。これを実施するには、当

然社内にアーキテクトが必要になる。

企業内にはほかにもアーキテクトのグル

ープがいくつか存在するかもしれないが、

それらのグループでは技術の選定などを

行うだけであり、リファレンス・アーキテ

クチャを管理するのはあくまでもSOAア

ーキテクト・オフィスである。

このオフィスは、2 種類のメンバーで

構成される。アーキテクチャや標準を考

える常任のコア・メンバーと、プロジェク

トごとに適宜加わるメンバーだ。柔軟に

オフィスを形成することで、SOA導入の

意思決定に携わるアーキテクトの育成

にも役立つ。このオフィスを中心にして

問題に対する解決策を練り、システム

のサービス化や統合を進めていけば、

SOAの恩恵が十分に享受できるように

なるはずだ。

7/22/2019 IT Vol.13 00.pdf



システム統合

統

合

パ

タ

ー

ン

／

ア

ー

キ

テ

ク

チ

ャ

設

計

パ

タ

ー

ン

特集 1

今日、企業を取り巻くビジネス環境の変化がますます激しくなる中で、

各社は生き残りをかけ、合併や海外進出などさまざまな戦略を進めている。

当然、ビジネスを裏で支えるITシステムにも、

そうした変化に迅速に対応することが求められる。ただし、その場しのぎの対処を繰り返すだけでは、

アーキテクチャの複雑性が増し、いずれはさらなるビジネス展開を阻む要因ともなりかねない。

ここで必要となるのが、柔軟なサービス連携や

統一的なプラットフォームの構築などによる「システム統合」だ。

本特集では、システム統合においてアーキテクチャ上の課題となる事項を整理したうえで、

それらの課題に対する施策について、

統合パターンやアーキテクチャ設計パターンの活用法も交えて解説する。

小野沢博文 Hirofumi Onozawa

アクセンチュアプリンシパル

7/22/2019 IT Vol.13 00.pdf



技術の今を探る

急

増

す

る

統

合

案

件

に

備

え

、

ア

ー

キ

テ

ク

ト

が

押

さ

え

て

お

くべ

き

7/22/2019 IT Vol.13 00.pdf



システム統合特集 1

重要性を増すシステム統合

変化の激しい今日のビジネス環境において、企業／

組織が競争優位に立つためには、ITシステムの活用が

必須である。言いかえれば、ITシステムには、ビジネス環境の変化に対する柔軟な適応が求められる。特に、企

業の合併／買収（M＆A）、省庁の統廃合、市町村

合併といった組織の統合では、「異なる文化や設計思

想を持ったITシステムの統合」による劇的な変化が伴う

ことになる。そのほかにも、提携企業や取引先、グルー

プ企業などとのシステム連携を要する案件は、確実に増

加している。こうした周囲の動向から見るに、読者がい

つ、システム統合※1の案件を担当することになってもおか

しくはない状況であると言えよう。

このように、システム統合の案件が増える一方で、改

変を繰り返したシステムは複雑性が増し、さらなる変化

に対応しきれなくなるケースが少なくない。実際に、ITシス

テムの複雑さに起因するシステム統合の困難さが、組

織統合の足かせになるケースも発生している。

例えば、旧東京三菱銀行と旧UFJ銀行が、金融庁

からシステム統合のテスト不足を指摘され、当初2005年

10月に予定していた合併を2006年1月に延期したニュ

ースは記憶に新しい。また、近年盛んに行われている自

治体合併だが、およそ3 割の合併市町村でシステム障害が発生していたことがメディアの調査※2で明らかになっ

ている。

こうしたことからわかるように、システム統合は組織の発

展にとって不可欠だが、同時に極めて困難な作業でも

あるのだ。

企

業シ

ス

テ

ム

の

統

合を

巡

る

課

題

変

化

へ

の

対

応

を妨

げ

る

5

つ

の

問

題

点

を

明

ら

かに

す

る

ITシステムをビジネスにおいて有効

活用するうえで、システム統合はも

はや避けて通ることのできない重

要なミッションの1つだ。本パートで

は、システム統合の重要性を再確

認するとともに、今日、多くの企業

システムが抱えているシステム統合

上の課題を明らかにする。

Part 1

※1 本特集では、別々に開発された異なるシステムを連携させる、あるいは

統合する作業のことを「システム統合」と呼ぶ。

※ 2 『4月以降の合併市町村、3 割でシステム障害』（日経コンピュータ

2005年8月8日号／発行：日経BP社）。

7/22/2019 IT Vol.13 00.pdf




システム統合は、IT戦略の一環

システム統合を成功に導くためには、アーキテクチャに

ついて考える前に、まずビジネスとシステムの全体像を見

据え、明確なIT戦略を立てる必要がある。なぜなら、シ

ステム統合とは、単に複数のシステムを合体させることではなく、新組織のIT戦略を具現化することだからだ。

例えば、筆者が所属するアクセンチュアでは、ITを

「IT戦略の方向性」、「ITアーキテクチャ」、「ITマネ

ジメント」という3つの階層で整理することを推奨している。

これと同様に、システム統合においても、この3つの階層

で課題を識別し、あらかじめその答えを明らかにしておか

なければならない（図1）。具体的には、次のような事柄

を明確にしておく必要がある。

●IT戦略の方向性：システム統合の目的／目標や、統

合後の業務、システムの全体像

●ITアーキテクチャ：データやアプリケーション、統合技

術、インフラストラクチャの各領域における、アーキテク

チャ上の課題と方向性

●ITマネジメント：統合に伴うテスト方針や統合プロセ

ス、IT標準や組織上の課題と方向性

システム統合を巡る課題

上述した3つの階層のうち、特にアーキテクトが深くか

かわるITアーキテクチャの階層は、「データ・アーキテク

チャ」、「アプリケーション・アーキテクチャ」、「統合アー

キテクチャ」、「インフラストラクチャ・アーキテクチャ」に

大別することができる。各アーキテクチャに関する主な課

題は、次ページの表1に示すとおりだ。4つのアーキテク

チャのうち、ここではアプリケーション・アーキテクチャと統

合アーキテクチャに関する課題について、その問題点を

整理しておこう。

IT戦略の方向性

ITアーキテクチャ

ITマネジメント

プロセス資源

標準組織

インフラストラクチャ・アーキテクチャ

アプリケーション・アーキテクチャ

データ・アーキテクチャ

統合アーキテクチャ

指標目的

ビジョン

図1：3つの階層におけるシステム統合の課題

経営戦略

IT戦略

ドライブ具現化

【システム統合の重要課題】

●システム統合の目的／目標は？●統合後のシステムの全体像は？……

●データの重複をどう解消するか●継ぎはぎ統合をどう解消するか●アプリケーション・サイロをどう解消するか……

●テスト方針は？●移行プロセスは？●統合後のIT組織は？

7/22/2019 IT Vol.13 00.pdf




企

業

シ

ス

テ

ム

の

統

合

を

巡

る

課

題

Part 1

アプリケーション・サイロの発生

他のシステムとの連携を考慮せずに構築された“孤

立システム”は、その形状から「アプリケーション・サイロ」

と呼ばれる（図2）。アプリケーション・サイロは、画面、ビ

ジネス・ロジック、データのすべてが、システムごとに上か

ら下まで縦割りで作られているため、外部との連携が困

難になる。

例えば、営業部員のスケジュールや顧客訪問記録

を管理する営業支援システムを開発するとしよう。要件に

「他システムと連携する」という項目がないため、スタンド

アロンのWebシステムとして設計し、初期開発時には何

よりも効率性を優先させる。その結果、画面ロジックの至

るところにビジネス・ロジック／データ・アクセス・ロジック

が埋め込まれ、データベースもそのシステム独自のものを

持つことになった――こうした安易なシステム構築を行うと、後から他システムとの連携要件が発生しても、もはや

お手上げだ。せいぜい、ファイルによるデータ・インポー

ト／エクスポート機能を後付けできる程度だろう。

データ鮮度の低下

現在も、多くの企業システムでは、夜間にオンライン・

システムを停止させ、バッチ処理によってデータ集計や

システム間のデータ連携を実施している。例えば、まず

日次バッチで販売データを集計し、その結果を物流在

庫システムや財務会計システムにファイル転送する。次

に、データを受け取った物流在庫システムでは、最新

の在庫量を集計して、やはり日次バッチで不足製品の

生産を生産管理システムに指示するといった具合だ

（図3）。

このように、日次ファイル転送によってシステムからシス

テムにデータをバケツ・リレーした場合、経営指標や在

庫データは数日遅れ、場合によっては1カ月ほども遅れて

しか入手できないケースもある。これが、経営判断の誤り

や過剰在庫の発生を招く原因となりかねないのは言うまでもない。

また、インターネット取り引きの普及や企業のグローバ

ル化により、昨今のシステムには24時間対応が求められ

る。だが、バッチ処理に伴うオンライン・システムの停止

は、そうしたビジネスの要請に応じるにあたって大きな障

害となる。

継ぎはぎ統合によるコストの増大

システム間の連携が必要になる度に、各開発プロジ

図2：アプリケーション・サイロ

画面

ロジック

データ

システムA

画面

ロジック

データ

システムB

画面

ロジック

データ

システムC

表1：各アーキテクチャにおける主な課題

アーキテクチャ

データ・アーキテクチャ

アプリケーション・


統合アーキテクチャ

インフラストラクチャ・


主な課題

●システム間のデータ重複や不整合をいかに解消

するか

●統合が困難なアプリケーション・サイロ（連携

手段を持たない孤立したシステム）をいかに解消

するか

●バッチ型統合によるデータ鮮度の低下をいかに

解消するか

●継ぎはぎ統合による保守／運用コスト増大をいか

に解消するか

●ベンダー固有の統合技術によるロックインをいか

に解消するか

●保守／運用を困難にする統合技術の陳腐化を

いかに回避するか

●多種多様なOS、ハードウェア、運用基盤がある

中で、いかに統合を進めるか

7/22/2019 IT Vol.13 00.pdf




ェクトの裁量でアドホックに統合技術の選定を行ってい

ると、やがて組織内に無数の統合技術が乱立すること

になる。

ある時点では、プロジェクトにとって最適な技術を採

用したつもりでいても、組織としての標準やアーキテクチャ方針、またはそれを徹底するガバナンス体制が整備さ

れていないと、全体の統一性に欠けた継ぎはぎだらけの

システムに陥ってしまうのだ（図4）。その結果、膨大な種

類の技術や製品を保守／運用するためにコストは増大

し、スキルを持った人材の確保も困難になる。また、シス

テムが複雑になるため、予期せぬ障害の温床となること

もあるだろう。

ベンダー固有技術によるロックイン

ベンダー固有の統合技術を採用していたことが原因

で、さまざまな問題に直面した経験のある方は多いだろ

う。例えば、固有の通信プロトコルやデータ・フォーマット

を使用していたために、他システムとの連携にあたって高価なEAI（Enterprise Application Integration）

製品を導入せざるをえなくなったり、プロトコルやフォーマ

ット変換用のカスタム・アダプタを作成するために莫大な

開発コストが発生したりといった具合だ。

そうした統合技術をリプレースしようとした場合、アプリ

ケーションの書き換えまで必要になるケースが少なくない。

それが理由でリプレースに踏み切れず、高価な保守／

図 3：バッチ型統合によるデータ連携の例販売管理システム

データベース

物流在庫システム

データベース

生産管理システム

データベース

人事給与システム

データベースデータベース

経営者

データベース

財務会計システム財務会計システム

日次バッチ週次バッチ

データ・ウェアハウス

図4：継ぎはぎだらけの統合

販売管理システム

データベース


データベース


データベース


データベースデータベースデータベース

財務会計システム財務会計システム

ファイル転送

独自のETL（Extract/Transform/Load）ツール

CORBA

MOM製品

ETL製品A

ETL製品B

TPモニタ


7/22/2019 IT Vol.13 00.pdf




企

業

シ

ス

テ

ム

の

統

合

を

巡

る

課

題

Part 1

コンサルティング費用を払い続けている組織も少なくない

だろう。

さらに、企業の合併時などには、それぞれの組織が

異なるEAI製品を採用していたために、本来システムを

接続するためにあるEAI製品同士の接続に頭を悩まるといった本末転倒の事態に陥ることもある（図5）。

統合技術の陳腐化

どのような技術や製品も、技術の進歩に伴って、いず

れは陳腐化していく宿命にある。できるだけ、1つの技

術／製品を長く使い続けるためには、標準的かつ将来

性のある技術を採用することが第一だが、そうした標準

技術でもいずれは陳腐化する。統合技術の場合、新

旧さまざまであるシステム間の相互運用性を確保するの

がその役割であるため、陳腐化した際の影響範囲は他

の技術よりも甚大だ。

導入から長期間経過した、もしくは未成熟な統合技

術／製品を採用してしまったという場合、新たな統合技

術への切り替えが必要になる。このとき、アプリケーション

と統合技術が密接に結び付いていると、切り替えに伴っ

てアプリケーションの改修や置き換えを余儀なくされるの

で注意されたい。

システム統合に向けたアーキテクトの役割

以上、システム統合でアプリケーション・アーキテクチ

ャ／統合アーキテクチャに関して発生する主な課題について、その問題点を見てきた。冒頭で述べたように、

これらの問題に対してその場しのぎの対応を繰り返せ

ば、アーキテクチャの複雑化が進行し、いずれ身動きが

とれなくなる。

こうした事態を回避するために、アーキテクトは長期

的なアーキテクチャ・ビジョンを描いたうえで、統合技術

の標準化といった全社的な取り組みを行うとともに、個

別のシステム開発案件を通じて、アーキテクチャを“ある

べき姿”へと段階的に近づけていかなければならない。

なお、ここで取り上げた課題を解決し、システム統合

に強いアーキテクチャを段階的に構築していくための具

体的な施策については、Part 3で解説する。

図5：ベンダー固有の統合技術によるロックイン

販売管理システムアダプタ



財務会計システムアダプタ

アダプタ

アダプタ

統合前のA社のシステム

アダプタ

アダプタ

アダプタ

EAI製品X

EAI製品Y

アダプタ



財務会計システム

統合前のB社のシステム

ブローカ

ブローカ

苦労して開発したカスタム・アダプタも、独自技術であるために、他の EAI製品では使用できない

独自技術のため、EAI 製品間の

接続に頭を悩ませる

『CIOは企業統合とどう向き合うべきか』（CIO Maga

zine 2002年11月号／著者：関戸亮司氏、三宅利洋

氏／発行：IDGジャパン）

参考文献

7/22/2019 IT Vol.13 00.pdf




6つの統合スタイル

本パートでは、以下の6つの統合スタイルを取り上げ

る。

①媒体渡し②ファイル転送

③ETL

④共有データベース

⑤非同期メッセージング

⑥同期メッセージング

システム統合における一般的なスタイルとして、グレゴ

ール・ホープ氏らが書籍『Enterprise Integration

Patterns』（発行：アディソン・ウェズレイ）の中で「ファイ

ル転送」、「共有データベース」、「リモート・プロシージ

ャ呼び出し」、「メッセージング」の4つを挙げており、ここ

ではおおむねそれに倣ったが、さらに「媒体渡し」と

「ETL」を追加することで網羅性を高めた※1。

以降では、これらの統合スタイルの概要と、適用にあ

たっての指針を順に説明していこう。

①媒体渡しスタイル

媒体渡しとは、磁気媒体やCD、DVDなど何らかの

データ記録媒体を介してシステム間のデータ連携を実

現する統合スタイルである（次ページの図1）。このスタイルを検討するのは、以下のいずれかの要件がある場合

となる。

●セキュリティ上の理由、あるいは対象システムや連携

先システムの制約などにより、システムのオンライン化が

できない

●「データ連携が年に1回程度しか発生しない」などの

シ

ステ

ム

統合

ス

タイ

ル

の

選

択

代

表

的

な

統

合

スタ

イ

ル

の

概

要

を

押

さ

え

、そ

の〝使

い

ど

こ

ろ

〟を

知

る

システム統合でどのような方式（統

合スタイル）を採用するかは、シス

テムの性能や保守性、データの鮮

度、開発コストなどを決定づける極

めて重要な判断だ。本パートでは、

一般に広く利用されている6つの統

合スタイルの概要を紹介するととも

に、それらを選択する際の指針に

ついて説明する。

Part 2

※1 同書の中で「メッセージング」としているところは「非同期メッセージング」

に、「リモート・プロシージャ呼び出し」は「同期メッセージング」に名称を変更し

た。

7/22/2019 IT Vol.13 00.pdf




シ

ス

テ

ム

統

合

ス

タ

イ

ル

の

選

択

Part 2

理由により、オンライン化による費用対効果が期待で

きない

●すでにオンライン化されているシステム連携が、障

害／災害などで使用不能になった際の影響が甚大

なため、代替手段を用意しておく必要があるまた、媒体渡しスタイルの適用にあたっては、以下の

ようなマイナス面があることも考慮されたい。

●バッチ処理や媒体輸送によるタイムラグが発生するた

め、データの鮮度が低下する可能性がある

●媒体運用に人手が介在するため、そのための運用

業務設計が必要であり、当然ながら運用にあたって

は人件費などが発生する

②ファイル転送スタイル

ファイル転送スタイルでは、連携元システムにおいて連

携データを格納したファイルを作成し、それを連携先シス

テムで読み取ることでデータ連携を実現する（図2）。以

下のいずれかの要件がある場合には、ファイル転送スタ

イルの適用を検討することになる。

●システム間で大量のデータをやり取りする

●連携先システムの処理形態が、バッチ一括処理である

●連携先システムが、ファイル・インタフェースしか持たない

ファイル転送スタイルでは、媒体渡しスタイルで発生し

ていた手作業を排除し、システム間の連携を自動化する

ことができる。しかし、媒体渡しスタイルと同様に、データの鮮度が低下するという問題は避けられない。

③ETLスタイル

ETLスタイルは、連携元のデータベースからデータを

抽出（Extract）／変換（Transform）し、それを連携

先のデータベースに格納（Load）することで、システム間

のデータ連携を実現する統合スタイルである（図3）。もと

もとは、基幹系データベースからデータ・ウェアハウス用

にデータを抽出するために考案された方式だが、それに

限らず、データベース間のデータ連携や、データの同

期をとる手段としても広く利用されている。その適用を検

討するのは、以下のような要件がある場合だ。

●基幹系データベースから、データ・ウェアハウスや情

報系データベースへのデータの抽出／同期が必要

である

図1：媒体渡しスタイル

バッチ・アプリケーション

連携元システム


連携先システム

記録媒体記録媒体運搬

図 2：ファイル転送スタイル


連携元システム


連携先システム

転送

ファイルファイル

7/22/2019 IT Vol.13 00.pdf




●特に複雑なデータ変換、あるいは名寄せや参照整

合性確保といったデータ・クレンジングが必要である

なお、ETLスタイルも、先の統合スタイルと同様、デー

タの鮮度が低下するという問題を抱えている。

④共有データベース・スタイル

その名のとおり、共有データベースを介して複数シス

テム間の連携を実現するのが、共有データベース・スタ

イルだ（図4）。以下のいずれかの要件がある場合に、こ

のスタイルの適用を検討することになる。

●複数システムが同一データの最新の値を参照／更

新する必要がある

●特に高い応答性能が求められる

共有データベース・スタイルは、データベース以外のミ

ドルウェアを必要とせず、アプリケーション開発が比較的

容易なことから、非常に広く利用されている。ただし、以

下のような点には留意されたい。

●多くの場合、パッケージ・アプリケーションは独自スキ

ーマを持つため、共有データベース・スタイルを適用

できない

●組織やシステムの枠を超えた共有データの設計／保守は容易ではない（特に、システムに変更が発生し

た際の影響範囲が大きい）

●現状、地理的に分散したシステム間でのデータベー

ス共有は、システムの性能的に難しい

⑤非同期メッセージング・スタイル

非同期メッセージング・スタイルでは、連携元システム

からメッセージング・システムを介して連携先システムにメ

ッセージを送信することで、システム間の連携を実現する

（図5）。

連携元システムは、メッセージング・システムへのメッセ

図 3：ETLスタイル

アプリケーション

抽出変換ロード

連携元システム連携先システム

ETL

データベース


データベース


図 4：共有データベース・スタイル

アプリケーション更新参照


共有データベース


図 5：非同期メッセージング・スタイル

メッセージメッセージ

連携元システムメッセージング・システム連携先システム

チャネルチャネル


変換／ルーティング

7/22/2019 IT Vol.13 00.pdf




シ

ス

テ

ム

統

合

ス

タ

イ

ル

の

選

択

Part 2

ージ送信が完了すると、その成否にかかわらず、別の処

理を行うことができる。このように、連携元システムと連携

先システムが「非同期」に動作する点が、非同期メッセ

ージング・スタイルと呼ばれるゆえんだ。

非同期メッセージングでは、ファイル転送のようなバッチ一括処理とは違い、イベント発生と同時にメッセージ

を送信できるため、タイムラグを最小限に抑えられる。ま

た、メッセージ送信時に連携先システムが停止していれ

ば、メッセージはメッセージング・システムに蓄積され、連

携先システムが再開された後に送信される。したがっ

て、連携元システムと連携先システムは互いに相手のサ

ービス状況を意識する必要がない。

この統合スタイルを選択肢に入れるのは、以下のい

ずれかの要件がある場合となる。

●連携先システムからの応答が必要なく、連携元システ

ムではメッセージを送信した後、すぐにほかの処理を

実行したい

●複数システムへの同報メッセージの送信が必要

●連携先システムが常に利用可能な状態だとは限らな

い

●メッセージ送達に関する高い信頼性が求められる

●ファイル転送よりも高いリアルタイム性が求められる

なお、非同期メッセージングは媒体渡しやファイル転

送、ETLに比べ、比較的高度な要件を満たす優れた統合スタイルだが、以下のような処理には適さない。

●対話型処理などリアルタイムでの応答が必要な処理

●大量データの転送（イベントが発生するつど、それを1

メッセージとして送信するため）

⑥同期メッセージング・スタイル

同期メッセージング・スタイルは、連携元システムから

連携先システムに要求メッセージを送信し、連携先シス

テムから連携元システムに応答メッセージを返信するか

たちの統合スタイルである（図6）。非同期メッセージングとは異なり、連携元システムでは、メッセージの送信後、

ほかの処理を行わずに応答メッセージが返されるのを待

つ。

このスタイルの利用を検討するのは、以下のいずれか

の要件がある場合だ。

●他システムの機能を呼び出して、その処理結果を受

け取りたい

●対話型処理などで高いリアルタイム性が求められる

また、同期メッセージングは、リアルタイム性を高めると

いう点では優秀だが、適用にあたっては次のような留意

点がある。

●リアルタイムで要求メッセージ／応答メッセージをやり

取りするため、連携するシステムが常に利用可能であ

ることが前提

●要求メッセージの送信から応答メッセージの受信まで

の間、連携元システムでは処理がストップするため、

大量データの転送には適さない

●インタフェース設計を誤ると、システムの性能劣化や

密結合、信頼性の低下を招きやすい

統合スタイルの選択基準

ここまで6つの統合スタイルを簡単に説明してきたが、

図6：同期メッセージング・スタイル


アプリケーションスタブアプリケーションスケルトン

要求メッセージ

応答メッセージ

7/22/2019 IT Vol.13 00.pdf




いずれかのスタイルが他のスタイルよりも絶対的に優れて

いるということはない。統合対象となるシステムは多種多

様であり、統合時の要件も多岐にわたる。加えて、シス

テム統合プロジェクトにおいて、アーキテクトは技術や予

算、スケジュールといったさまざまな制約の中で判断を求められる。そのため、単純なディシジョン・ツリーではすべ

てを表しきれないケースも多く、必ずしもシステムにとって

最適な統合スタイルを選択できるとは限らない。

また、「同期メッセージングは密結合を招く」と短絡的

に結論づけ、解決策として「非同期メッセージングに置

き換えるべきだ」といった主張をよく聞くが、そもそも同期と

非同期とでは機能的にも非機能的にも満たせる要件が

異なるため、単純に置き換えられるものではない。

以下に、筆者の経験に基づき、統合スタイルを決定

する際の考慮点を整理しておこう。

まず、最も重要な点は、システム統合に対する要件を

明らかにすることである。そのために、次のような点をチェ

ックする。

●データ連携なのか、それとも機能連携なのか

●応答が必要か

●リアルタイム性が求められるか

●複数システムへの同報が必要か

●1回の連携でやり取りされるデータ量はどの程度か

●連携の頻度はどのくらいか●データ送達に対する信頼性はどの程度求められるか

●連携対象のシステムに対して、将来的に予測される

変更内容と変更量

これらのうち、「データ連携なのか、それとも機能連携

なのか」というポイントと各統合スタイルの相性は、図7の

ようになる。ご覧のとおり、同期／非同期メッセージング以外の統合スタイルは、データ連携に適している。な

お、同期／非同期メッセージングは、データ連携／機

能連携のいずれにも適用可能だが、データ連携には

非同期メッセージングのほうが、機能連携には同期メッ

セージングのほうがより適していると言える。

同じく、リアルタイム性、データ量、データ送達の信

頼性と統合スタイルの相性は、それぞれ次ページの図8

〜10のとおりだ。

また、こうしたポイントのチェック以外に、統合対象シス

テムの制約を以下のような観点から洗い出すことも不可

欠である。

●バッチ処理かオンライン処理か

●データ・フォーマットは何か

●OSは何か

●利用可能な外部インタフェースは何か

●改修可能か否か

●サービス時間帯の制限はあるのか

●どの程度の可用性があるのか

こうした制約のうち、サービス時間と可用性に関しては、統合スタイルによって大きく依存度が異なるため、注

図7：「データ連携なのか、それとも機能連携なのか」というポイントに対する各統合スタイルの相性

媒体渡し

ファイル転送

ETL


非同期メッセージング

同期メッセージング

機能連携データ連携

7/22/2019 IT Vol.13 00.pdf




シ

ス

テ

ム

統

合

ス

タ

イ

ル

の

選

択

Part 2

意が必要である（図11）。

統合スタイルを決定する際には、このほかにも、利用

可能なネットワークやファイアウォールの有無などの技術

的制約、障害／災害時の影響と代替手段といったコ

ンティンジェンシーを考慮する必要がある。さらに、ROI

（Return On Investment：投資対効果）や予算、ス

ケジュール、組織体制、要員のスキルなど、技術以外

の制約も統合スタイルの決定に影響を与える。アーキテ

クトには多面的な視野が求められることを、改めて痛感

させられるはずだ。

図8：「リアルタイム性が求められるか」というポイントに対する各統合スタイルの相性

媒体渡し

ファイル転送

ETL




低リアルタイム性高

図9：「1 回の連携でやり取りされるデータ量」というポイントに対する各統合スタイルの相性

媒体渡し

ファイル転送

ETL




大 1回の連携でやり取りされるデータ量小

図10：「データ送達に対する信頼性がどのくらい求められるか」というポイントに対する各統合スタイルの相性

媒体渡し

ファイル転送

ETL




低データ送達の信頼性高

図11：サービス時間と可用性に対する、各統合スタイルの依存度

媒体渡し

ファイル転送

ETL




低サービス時間と可用性に対する依存度高

7/22/2019 IT Vol.13 00.pdf


7/22/2019 IT Vol.13 00.pdf




統

合

施

策

と

ア

ー

キ

テ

ク

チ

ャ

設

計

パ

タ

ー

ン

Part 3

統

合施

策

と

ア

ーキ

テ

ク

チ

ャ

設

計パ

タ

ー

ン

シ

ス

テ

ム

統

合

の課

題

を

解

決

に

導

く

、具

体

的

な方

策

を

考

え

る

ここまで、システム統合の現状と課

題を整理するとともに、代表的な統

合スタイルとその採用指針を説明し

てきた。それらを踏まえ、本パートで

は、Part 1で挙げたシステム統合上

の課題に対する施策について、具

体的な統合パターン／アーキテクチ

ャ設計パターンの使い方を交えて

解説する。

Part 3

5つの課題に対する施策

Part 1では、システム統合上の主な課題として、次

の5つを挙げた。

●アプリケーション・サイロの発生●データ鮮度の低下

●継ぎはぎ統合によるコストの増大

●ベンダー固有技術によるロックイン

●統合技術の陳腐化

上記 5つの課題に対する施策は、表1のようになる。

以降では、これらの各施策について、順次説明していこ

う。

連携を前提にしたシステム設計

アプリケーション・サイロに陥ったシステムを分析してみ

ると、ほとんどの場合、「導入当初は、他システムとの連

携要件がなかった」ことが原因となっている。「要件がな

かったから」と連携への備えがないままに作られたシステ

ムが、環境や要件の変化によって連携の必要性が生

じたときに対応できず、アプリケーション・サイロとして認識

されるのだ。

こうした事態に陥らないためには、当面、他システムと

の連携が予定されていないシステムであっても、将来のシステム連携を想定した設計を行う必要がある。以下

表1：システム統合の主な課題と施策

主な課題

アプリケーション・サイロの発生

データ鮮度の低下

継ぎはぎ統合によるコストの

増大

ベンダー固有技術による

ロックイン

統合技術の陳腐化

施策

連携を前提にしたシステム設計

非同期メッセージングによるリアルタイム統

合への移行

統合技術の標準化／統一

統合技術の隠蔽

7/22/2019 IT Vol.13 00.pdf




に、カスタム開発Webシステム、バッチ・システム、パッケ

ージ・ソフトウェアを利用したシステムを例にとり、それぞれ

における設計上の施策を説明する。

カスタム開発Webシステムの設計のポイントカスタム開発Webシステムの場合、画面（プレゼンテ

ーション）ロジックとビジネス・ロジックとを分離して設計す

る。こうした設計手法はティア分割の基本テクニックだ

が、さらにSOAP/HTTPやIIOPなどによる同期メッセー

ジングで、外部からビジネス・ロジックを起動できるように

設計しておくのがポイントだ。これにより、将来、他システ

ムから当該システムの機能を利用する要件が発生した

際、ビジネス・ロジックを修正せずに対応することが可能

になる。

また、将来的にビジネス・ロジックから他システムの機

能を利用できるように、外部サービスを呼び出すための

同期メッセージングAPIを標準で備えたアプリケーショ

ン・サーバ製品を選定することも重要だ。

以上を反映した設計パターンは、図1のようになる。

ご覧のとおり、ビジネス・ロジックは同期メッセージングに

よって外部から起動され、ビジネス・ロジック・コンテナ上

で実行される。

●不用意なロジックの分散を避けること

なお、カスタム開発Webシステムの設計に際しては、

特に留意しなければならない点がある。それは、不用意

なロジックの分散を避けることだ。これには、2つの理由が

ある。

1つ目の理由は、ロジックの分散がバグ修正や機能

追加などの保守を困難にすることにある。将来的な再利用を考慮してロジックを部品化することは重要だが、

ソース・コードの管理単位や配備単位といった無意味

な単位での分散は避けるべきだ。

2つ目の理由は、物理的な分散はシステムの性能と

信頼性を低下させるからである。例えば、画面ロジックと

ビジネス・ロジックを異なるサーバに配置した場合、両サ

ーバ間で通信のオーバーヘッドが発生するばかりでな

く、障害ポイントが増えることにもなる。

なお、図1では、画面ロジックとビジネス・ロジックを論

理的に分割してはいるが、上記の留意点に配慮して、

両者を同一アプリケーション・サーバ上に配置し、ロー

カル呼び出しによって画面ロジックからビジネス・ロジック

を呼び出すようにしている。

バッチ・システム設計のポイント

通常、バッチ・アプリケーションは、ジョブ・スケジュー

ラから起動されることが多い。だが、将来の連携に備え

るのであれば、SOAP/JMS（Java Message Service）

などを使った非同期メッセージングでも起動できるように

図1：連携を前提にしたカスタム開発 We bシステム

Webコンテナビジネス・ロジック・コンテナ

HTTP

ローカル呼び出し

画面ロジック在庫管理サービス

他システム他システム同期メッセージ（SOAP/HTT Pや RMI/IIOP、IIOP など）

によるサービス連携

アプリケーション・サーバ

将来のシステム連携を前提に設計する

7/22/2019 IT Vol.13 00.pdf




統

合

施

策

と

ア

ー

キ

テ

ク

チ

ャ

設

計

パ

タ

ー

ン

Part 3

設計しておきたい。この場合の設計パターンは図2のよ

うになる。

図1と図2の設計パターンで異なるのは、起動方法が

同期メッセージングか非同期メッセージングかという部分

だけであり、いずれもビジネス・ロジックはコンテナ上で実

行するようになっている点がポイントだ。

パッケージ製品を利用する場合

パッケージ製品を利用する場合、当面、他システムと

連携する要件がなくても、同期／非同期メッセージング

といったメッセージング・インタフェースを介して、外部か

らパッケージ製品の機能をサービス部品として利用でき、

その逆も可能な製品を選定しておくことが重要だ。

非同期メッセージングによるリアルタイム統合への移行

データ鮮度の低下を招いていたバッチ型統合からの

脱却の切り札は、非同期メッセージングによるリアルタイ

ム統合への移行である。しかし、これは口で言うほど簡

単な作業ではない。なぜなら、連携手段をファイル転送

から非同期メッセージングに変更するだけでなく、アプリ

ケーションの処理形態自体をバッチ処理からリアルタイム

処理に変更する必要があるからだ。さらに、バッチ型連

携にかかわる多数のアプリケーションの変更を伴うため、

一足飛びにリアルタイム統合に移行するのは難しい。

こうしたことから、通常は非同期メッセージング・ミドル

ウェアとビジネス・ロジック・コンテナを導入し、段階的に

リアルタイム統合に置き換えていくという手法が採用され

るケースが多い。以下に、具体例を挙げて説明しよう。

バッチ型連携からの移行

ここで例にとるのは、ファイル転送によるバッチ型連携

を採用している物流在庫システムと生産管理システムで

ある（図3）。

この物流在庫システムでは、在庫量が一定水準を

下回った商品を洗い出し、それらの商品に対する生産指示レコードを格納した連携ファイルを夜間バッチで出

力する。そして、出力されたファイルは、ファイル転送ソフト

ウェアによって自動的に生産管理システムに転送されると

いう仕組みだ。

移行の第1ステップでは、非同期メッセージング・ミド

ルウェアとビジネス・ロジック・コンテナを導入し、生産管

理システムを非同期メッセージング・スタイルに切り替える。

これにより、新しい生産管理システムは、メッセージ・チャ

ネルから生産指示メッセージを受け取り、リアルタイムで

図2：連携を前提にしたバッチ・システム

オンライン処理からのディレード（遅延）バッチ起動

HTTP

販売日報

集計サービス

他システム

ジョブ・スケジューラ


非同期メッセージ（SOAP/JMSなど）によるサービス連携

ビジネス・ロジック・コンテナ


将来のシステム連携を前提に設計する

チャネル

ジョブ・スケジューラからのジョブ起動

7/22/2019 IT Vol.13 00.pdf




処理を行えるようになる（図4-①）。

このステップでは、物流在庫システム自体には手を着

けず、両者のギャップを非同期メッセージング・ミドルウェ

アのファイル・アダプタで吸収する。つまり、ファイル・アダ

プタが物流在庫システムの出力する連携ファイルを検出し、ファイル中のレコードをメッセージとしてメッセージ・チ

ャネルに送信するわけだ。

一見、これでリアルタイム統合が成立したかのように見

えるが、物流在庫システムでは依然として一括バッチ処

理を行っているので、リアルタイム統合の恩恵は受けら

れない。また、この方式では、ファイルの検出とともに大

量のメッセージが発生することになるため、データ量によ

っては性能的に許容できない可能性もある。

これに続く第2ステップでは、物流在庫システムも非同

期メッセージングによるリアルタイム処理に置き換え、移

行完了となる（図4-②）。

データベース・アダプタの利用

上述の例では、第1ステップでファイル・アダプタを利用したが、それをデータベース・アダプタで代替するとい

うやり方もある。データベース・アダプタでは、生産管理

システム内の生産指示テーブルにトリガーを設定し、生

産指示レコードが追加されるつど、それをメッセージに変

換してメッセージ・チャネルに送出する（55ページの図5）。

この方式では、既存アプリケーションを改修せずにリ

アルタイム連携を実現できる点がメリットとなる。その反

面、物流在庫システムのデータベース・スキーマの詳細

知識が必要となるため、スキーマの変更に対して脆弱に

図 3：ファイル転送によるバッチ型連携を採用しているシステム

物流在庫システム生産管理システムファイル転送ソフトウェア

夜間バッチで生産指示レコードを格納した連携ファイルを出力する

連携ファイルを受け取ってバッチ処理を行う

ファイルファイル転送ソフトウェアファイル

図4：非同期メッセージングによるリアルタイム統合への段階的移行

①ステップ1：メッセージング基盤を導入し、生産管理システムをリアルタイム処理に置き換える（ファイル・アダプタを使用するパターン）

物流在庫システムファイル・アダプタ

夜間バッチで生産指示レコードを格納した連携ファイルを出力する

ファイルを検出し、ファイル中の各レコードをメッセージとして送出

生産指示メッセージを受け取ってリアルタイムで処理

ファイルチャネル


新生産管理

システム

②ステップ2：物流在庫もリアルタイム処理に置き換える

リアルタイムで生産指示メッセージを送信

チャネル


新生産管理システム


新物流在庫システム

7/22/2019 IT Vol.13 00.pdf




統

合

施

策

と

ア

ー

キ

テ

ク

チ

ャ

設

計

パ

タ

ー

ン

Part 3

なる。データベース・アダプタの利用は、あくまでも移行

本編で例示した生産管理システムのようなシステムでは、

重要なメッセージが送信途中で失われたり、逆に重複して送られたりすると、ビジネスに重大な影響を与えてしまう。ここ

では、そうした可能性を低減し、メッセージ送信の信頼性を

向上させるためのパターンを紹介する。

ただし、それらのパターンを用いてメッセージ送信の信頼

性を高めると、ディスク・スペースなどのリソース消費量が増

大したり、性能が低下したりといったトレードオフが生じる。そ

のため、これらのパターンを適用するか否かは、メッセージの

重要度を十分に吟味したうえで決定していただきたい。

Store-and-Forwardパターン

「Store-and-Forwardパターン」は、送信途中のメッセージ

喪失の可能性を低減するための統合パターンである。非同期メッセージングにおけるメッセージ送信をバケツ・リレーに例

えると、万が一、途中でバケツの水がこぼれることがあって

も、再度リレーを再開できるようにするのがこのパターンだ。

単にアプリケーションから受け取ったメッセージを送信する

だけの仕組みでは、処理途中でサーバ障害やネットワーク

障害が発生した場合に、メッセージが失われてしまう可能性

が高い。これを避けるために、Store-and-Forwardパターン

では、受け取ったメッセージをファイルやデータベースなどの

永続ストアにいったん格納してから送信する。格納したメッ

セージは、受信側からのAck（Acknowledgment：確認応答）が返ってきたタイミングで永続ストアから削除する。こうす

ることで、サーバやネットワークで障害が発生した場合でも、

障害回復後に再送でき、メッセージの喪失を避けられるとい

うわけだ（図A）。

Transactional Clientパターン

Store-and-Forwardパターンでは、受信側アプリケーショ

ンが受け取ったメッセージを処理している最中に障害が発生

した場合、それが処理結果をデータベースに格納する前に

発生したのか、それとも後に発生したのかをミドルウェアが知

るすべがない。格納前ならばメッセージを再送しなければなら

ないが、もし格納後であれば重複送信になってしまう。こうした事態を防ぎ、メッセージ送達とアプリケーションの処理の

整合性を確保するのが、「Transactional Clientパターン」

である。

このパターンでは、アプリケーション側の業務データベー

ス更新とメッセージの送受信を単一トランザクションで実行す

る。これにより、業務データベースとメッセージの永続ストア

との間の整合性を確保し、メッセージの重複送信を防止す

るのである（図B）。

非同期メッセージングの信頼性を

向上させるパターン


受信側システム

永続ストア

メッセージのエンドポイント

図A：Store-and-Forwardパターン


送信側システム

永続ストア

メッセージング・システム

永続ストア

チャネルメッセージのエンドポイント

メッセージを格納して送信

図B：Transactional Clientパターン


送信側システム中継システム

永続ストア

チャネルメッセージのエンドポイント

業務データベース更新とメッセージ保存を、同一トランザクションで実行

永続ストア

トランザクション

永続ストア


受信側システム

メッセージのエンドポイント

永続ストア永続ストア

業務データベース更新とメッセージ削除を、同一トランザクションで実行

受信側でのメッセージ保存と中継システムでのメッセージ削除を、同一トランザクションで実行

中継システムでのメッセージ保存と送信側でのメッセージ削除を、同一トランザクションで実行

メッセージのンドポイントンドポイントメッセージの

7/22/2019 IT Vol.13 00.pdf




なる。データベース・アダプタの利用は、あくまでも移行

過程における一時しのぎだと考えたほうがよいだろう。

統合技術の標準化／統一

Part 1で取り上げた「継ぎはぎ統合」や「ベンダー固

有技術によるロックイン」の問題を回避するためには、統

合スタイルの選択方針とスタイルごとの標準的な実現方

法を決定し、組織内で方式を統一するのが有効だ。

しかし、組織内のシステムを一度にすべて標準方式

で置き換えるのは不可能に近い。まさに、“言うは易く、

行うは難し”である。そこで、統合技術の標準化におい

ては、以下のような段階的アプローチを採用することが

多い。

●第1ステップ

組織内の標準方式を策定する。標準方式には、統

合スタイルの選択方針や統合スタイルごとの標準的な

実現方式、標準データ・フォーマットなどが含まれる。

●第2ステップ

システムを選定し、標準を適用する（以降では、組織

内標準を適用したシステム群を「標準ドメイン」と呼ぶ）。

この段階では、組織内の他システムはまだ標準に対応

していないため、それらの非標準システムと連携する際に

は、ドメイン・バインダリに配置されたゲートウェイによって

方式の違いを吸収する（図6）。これにより、標準ドメイン

内に非標準の方式を一切持ち込まないようにする。

●第3ステップ以降

システム更改や新システム導入のタイミングで、標準ド

図5：ステップ1で、データベース・アダプタを利用する場合

データベース・アダプタ

テーブルにトリガーを設定することで変更を検出し、メッセージとして送出

生産指示メッセージを受け取ってリアルタイムで処理

チャネル


新生産管理システム


生産指示テーブル

図6：標準ドメインと外部システムとの連携

非標準方式と標準方式の変換をバウンダリに集約する



標準ドメイン


外部システム

外部システム

外部システム人事給与システム

財務管理システム


バウンダリ（ゲートウェイ）

標準方式（同期／非同期メッセージング実現方式、

ファイル転送実現方式、標準データ・フォーマットなど）

非標準方式

7/22/2019 IT Vol.13 00.pdf




統

合

施

策

と

ア

ー

キ

テ

ク

チ

ャ

設

計

パ

タ

ー

ン

Part 3

メインに参加するシステムを順次増やしていく（最終的に

は、組織内のすべてのシステムが標準ドメインに参加す

るようにする）。

統合技術の隠蔽

「統合技術の陳腐化」の問題を回避するためには、

通信プロトコルやメッセージの物理的表現などの物理イ

ンタフェース、セキュリティやトランザクションといった統合

技術をすべてフレームワークで吸収し、アプリケーション

から隠蔽するのが有効である。そのようにフレームワーク

を設計しておくと、統合技術を変更する際、アプリケーシ

ョンに一切手を加えずに済むのだ。

また、これにより、論理インタフェース（アプリケーション

が直接かかわるメッセージ・フォーマット／パラメータなど）

を物理インタフェースから分離して、性能やサービス品

質に応じた最適な通信プロトコルを選択できるようにな

る。例えば、同一サーバ内ではメモリを介していたロー

カル通信の方法を、通常のリモート通信ではSOAP/

HTTPを、高い応答性能が要求されるリモート通信で

はIIOPを、トランザクショナルなリモート通信ではRMI/

IIOP＋OTS（Object Transaction Service）を使用

するといった具合に使い分けることが可能になる。

こうした統合技術の隠蔽を実現するフレームワークの

具体例が、ここまでの説明でも度登々場したビジネス・ロ

ジック・コンテナである（図7）。ビジネス・ロジック・コンテ

ナは、DI（Dependency Injection）×AOP（Aspect

Oriented Programming）コンテナの機能を備え、ビ

ジネス・ロジックを、統合技術やミドルウェアを一切意識しないPOJO（Plain Old Java Object）として実装可

能にする。さらに、ファサード機能を併せ持ち、ビジネス・

ロジックの論理インタフェースを、1つ以上の物理インタフ

ェースを通じて外部に公開できる点も特筆に値する。

＊＊＊

本特集では、今や企業システムの今後を考えるうえで

避けては通れないシステム統合の課題を明らかにし、そ

れらの課題を解決するための施策を、いくつかの統合

パターンやアーキテクチャ設計パターンも織り交ぜて解

説した。

筆者が見るに、今日システム統合の分野では、

「SOA」や「ESB（Enterprise Service Bus）」といっ

た用語ばかりが“一人歩き”している感がある。それを踏

まえ、本稿では、それらの流行語の背後にある統合スタ

イルや疎結合、同期／非同期メッセージングといった基

本技術／アーキテクチャについて再確認する意味も込

め、丁寧な説明を心掛けた。本特集が、読者のアーキ

テクチャ設計作業の参考になれば幸いだ。

図7：統合技術を隠蔽するフレームワークの例

ビジネス・ロジックの論理インタフェースを1つ以上の物理インタフェースで公開する

ビジネス・ロジックの実装には、統合技術を一切意識させない（POJOとして実装）

ファサード

ビジネス・ロジック・コンテナ（DI×AOPコンテナ）

SOAP/HTTP

RMI/IIOP

IIOP

在庫管理サービス

ビジネス・ロジック（アプリケーション）

7/22/2019 IT Vol.13 00.pdf




システム統合関連プロダクト・ウォッチ

ETLツールが必要とされる理由

昨今、企業の合併や提携の活

発化、社内に散在する情報の有効

活用へのニーズの高まりなどを受け、

システム統合案件がますます増加し

ている。このシステム統合で最も重

要な課題の1つとなるのが、各企業

／システム内のデータをいかにして

“つなげるか”ということだ。とりわけ、

企業の基幹システムには、その企

業の活動成果となる重要なデータ

が大量に蓄積されている。それが1

つのシステムに埋もれたままとなっ

ていては、合併や提携の目的である

“ビジネスの連携”を果たすことはで

きないのである。

豊富な実績を誇るETLツール「DataStage」

こうした背景から近年、活用が進

んでいるのが、ETL（Extract/Tra

nsform/Load）ツールだ。ETLツー

ルは、基幹システムなどからデータを

「抽出（Extract）」して必要な形式に

「変換（Transform）」し、データベ

ースなどに「格納（Load）」する機能

を提供する。このETLツールとして

豊富な実績を持つことで知られるの

が、日立製作所が提供する「DataStage」である。同製品の最大の

特徴であり、また多くの支持を獲得

する理由ともなっているのが、ETL

処理の開発生産性の高さだ。

GUI環境による

データ変換処理作成の効率化

ETLツールによるデータ連携では、

データを抽出し、変換、格納する処

理が要となるが、その処理の開発に

手間がかかっていたのでは、必要に

応じたデータ連携を素早く実現する

ことはできない。DataStageではその

点に配慮し、一連のデータ加工処

理を迅速に開発することが可能なビ

ジュアル開発環境を用意している。

具体的には、GUI画面上でアイコ

ンのドラッグ＆ドロップ操作によってデ

ータ加工処理を定義し、パラメータを

設定するだけで、実際の処理を行う

ジョブを作成できる（画面1）。

また、複雑なデータ加工処理も、

標準で用意された200以上の変換

関数を使うことによってシンプルに設

定でき、生産性を高められる。一度

作成したジョブは再利用できるので、

開発期間をさらに短縮することが可

能だ。

ビジュアルな開発環境は

保守フェーズでも威力を発揮

ビジュアルな開発環境は、システ

ムの保守フェーズでも威力を発揮す

る。

一般に、データ加工処理は複雑

であるため、それを手作りした場合、

保守フェーズでも多く

のコストがかかる。な

ぜなら、システムの拡

張、改変に応じて多くの修正が必要になる

からである。手作りし

たデータ加工処理の

場合、その変更の際

に再度、確認／修正

作業が必要になり、そ

れが保守コストを押し

上げる要因となるのだ。

一方、DataStageの場合、デー

タ変換処理はビジュアル環境で手

軽に作成できるため、速やかに修

正可能だ。システムのライフサイク

ル全体で見た場合に、これが保守

コスト削減につながるのである。

データの信頼性も確保

データの信頼性確保にまで踏み

込んでいる点も、DataStageの大き

な特徴だ。

統合したデータが信頼性の低い

ものであっては、どのような分析を加

えたところで、それは信頼性の低い

結果になってしまう。そこでData

Stageでは、各システムから抽出す

るデータのメタデータを管理する。そ

れにより、各データの属性を把握す

るとともに、あるシステムの変更が

他に及ぼす影響範囲を分析することが可能になる。

なお、DataStageは大規模シス

テムでの採用で多くの実績を持つ

が、近年の市場ニーズを受け、価

格を抑えた中規模システム向けのキ

ャンペーン製品「DataStage Com

mon Edition」が日立製作所から提

供されている。

画面1：DataStageのデータ処理定義画面

今日、システム間のデータ連携／統合などで広く利用されている

ETLツール。その中でも、特に多くの採用実績を持つことで知られるのが、

日立製作所が提供する「DataStage」だ。

E T L ツール

DataStage日立製作所

製品名 DataStage

価格要問い合わせ

提供元日立製作所

ソフトウェア事業部販売企画センタ

（☎03-5471-2592）

URL http://www.hitachi.co.jp/datastage/開発元日本IBM

7/22/2019 IT Vol.13 00.pdf



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

王道とも言えるのが、「仮説検証」である。

これは、超一流の外資系コンサルタントから街中の中小コンサルタントまで、

コンサルタントを名乗る者であれば必ず一度は学び、活用する手法だ。

仮説検証を行うと、優れた報告書を作成できるだけでなく、

作業タスクの過不足がないスケジューリングも可能となる。

まさに“一石二鳥”のコンサルティング・テクニックだと言えよう。

ビジネスの課題解決にITが多用される今日、

アーキテクトが習得したい基本テクニックの1つだ。

荒井岳 Takashi Arai

コンサルタントの

技

を

盗

め！

コンサルティング・

テクニックの王道「

仮説検証

法﹂を学ぶ

第2回

なぜプロジェクトは

失敗に終わるのか？

世の中では、政府や地域、企業、大学などにお

いて、さまざまなプロジェクトが実施されている。しか

し、世間では「『プロジェクト』と銘打った活動の8割

は失敗に終わる」と言われる。システム開発にも「プ

ロジェクト」は付き物であり、多くの場合、それらは改

革／改善の旗印の下にスタートする。だが、実際に

は、システムを稼働させることで精一杯となり、本来

の目的である改革／改善を達成している例は少な

い。こうした失敗プロジェクトには、ある共通の“症

状”が見受けられる。読者が経験したプロジェクトに、

次のような症状は見られなかっただろうか。①現状調査と称してインタビューやアンケート調査を

行うが、そもそも何が目的でそれを聞いているのか、

また聞いてどうするのかがわからない

②検討会や研修、トレーニング、ミーティング、資料

作成などの目的がわからず、意味のない作業を

行っているように感じられる

③収集できる資料や情報をとりあえずすべて集め、

どう料理するかは後で考えるはずが、結局、それ

らの情報は活用されずに終わる

④大ざっぱなスケジュールしかなく、次に行う作業や

タスクの具体的な内容や作業手順が示されな

いため、プロジェクト全体がどこに向かって進んで

いるのかがわからない

⑤時間をかけて作成した資料や分析結果が報告

会で使われず、「プロジェクト・メンバーの理解を

深めた」程度にしか役立たなかった

⑥ユーザーがプロジェクトに対して懐疑的で、非協

力的である

7/22/2019 IT Vol.13 00.pdf



こうした症状に心当たりのあるプロジェクトは、失

敗プロジェクトの典型だ。では、なぜこのような状況

に陥るのだろうか。答えは簡単である。最終的な

「結論」が見えないまま、プロジェクトをスタートさせる

からだ。そのため、底なし沼から抜け出そうと暴れる

のと同じで、何をやってもどんどん深みにはまっていく。

実は、プロジェクトにおいて最も重要なことは、スタートの段階で「結論」を描くことである。今回、テー

マとして取り上げた「仮説検証法」は、あらかじめ

「結論」を「仮説」として決めてから作業を始めるとい

う手法だ。先に挙げた失敗の症状が出ているプロ

ジェクトでは、ぜひこの仮説検証法を試してみてい

ただきたい。作業の目的が明確になるだけでなく、

無駄な作業を減らすことができる。さらに、ユーザー

からの信頼を得て、協力的に接してもらえるようにな

るだろう。

「結論」は“創る”もの

仮説検証法の解説に入る前に、「結論」につい

ての誤解を解いておこう。誤解というのは、多くの人

が、プロジェクトの調査タスクから結論を導き出せる

と考えていることだ。残念ながら、調査から結論を

“発見”できることはまれである。結論は発見するもの

ではなく、“創る”ものだからだ。ただし、「結論を捏

造しろ」と言っているのではない。「最も効果的で実現可能性が高く、顧客が納得するような結論は、

調査だけでは導けない」ということを理解してほしい

のである。ここで、興味深い話を2つ紹介しよう。

1つ目は、以前に新聞に掲載されていた記事で

ある。米国のブッシュ大統領がイラクを「悪の枢軸」

だと宣言し、イラク戦争が勃発したことは読者も覚え

ているだろう。英国のブレア首相（当時）も、「イラク

は大量破壊兵器を開発している」と宣言した。ブレ

ア首相の情報源は、映画『007』などでもおなじみの

SIS（Secret Intelligence Service：秘密情報部）

である。しかし、当時の新聞に掲載されたSISの幹

部の話によると、SISのミッションは、他国のさまざまな

統計や情報を収集してありのままを本国に伝えること

であり、決して何らかの意味づけをしたり、考えを盛

り込んだりはしないという。だが、ありのままの情報は、

往に々して「そうとも言えるし、そうとも言えない」という

内容であるものだ。ご存じのとおり、結局、イラク国内で大量破壊兵

器は発見されず、ブレア首相は判断ミスを認めざる

をえなくなった。ここで重要な点は、単に多くのデータ

を集めても、そこから何かを結論づけるのは難しいと

いうことだ。調査結果から結論を導くのではなく、

“創った結論”を証明するために調査結果を利用す

るのである。

2つ目は、あるデータ・マイニングのセミナーでの話

だ。そのセミナーでは、「米国のスーパーでオムツと

ビールを併売したら、よく売れた」という有名な「オム

ツとビールの法則」を持ち出して、データ・マイニング

によって思わぬ商品の組み合わせが発見されたこと

を紹介していた。これが事実であれば、かなりまれな

ケースだろう。データ・マイニングを使ったとしても、仮

説なしに膨大なデータから何かを発見できることなど

ほとんどない。仮に発見できたとしても、「パンと牛乳」

や「弁当とお茶」など、だれもが知っている単純な組

み合わせがよく売れるといったことくらいだ。商品の売

れ行きは、気候や陳列位置、品ぞろえ、価格、近隣の競合店の状況、時間帯、客層など、さまざまな

要因によって変化する。併売が個別販売よりもよく売

れるかどうかを判断するには、これらの条件も加味し

た特別な分析が必要であり、偶然見つかるようなも

のではない。こういった分析では、まず「オムツとビー

ルを併売するとよく売れるはずだ」という仮説を先に

立て、そのうえでテストを行い、分析をかけてデータに

よって証明することになる。つまり、先に仮説が必要と

なるのだ。

これらの話は、他のビジネスやプロジェクトにおい

前回、「報告書のストーリーボード

（ストーリー展開、シナリオ）は、結論か

ら書き始めることが重要だ」と説明し

た。しかし、報告書を作成するときに

なってから結論を決め、その理由を構

成しようとしてもうまくいかないことが多

い。なぜなら、結論なしで膨大な情報

や資料を集めても、その中に後から決

めた結論の理由となる情報が含まれ

ている保証はないからだ。また、インタ

ビューやアンケートは、質問の仕方に

よって答えが変わることがあり、導きた

い結論を決めずに行った調査結果は

使い物にならないケースが多い。つま

り、「結論から述べるストーリーボード」

を実践するには、仮説検証法でプロ

ジェクトを進めるのが最も効率的／効

果的なのである。

ストーリーボードを結論から始めるために

7/22/2019 IT Vol.13 00.pdf



ても当てはまる。ビジネスに影響を与える変数（要

素）は実に多く、法律や規制、天候、地域特性、

戦略、マーケティング、人材、品質、価格、取引先

の力、競合の戦略など多種多様だ。おまけに、これ

らは常に変化しており、今日の調査結果が明日も当

てはまるという保証はない。このような状況で、当ても

なく調査して結論を導き出そうというのが、いかに無謀なことであるかはわかるだろう。

仮説検証法を学ぶに先立ち、調査や分析によっ

て自動的に結論が導き出せるという誤解は捨て去っ

てほしい。あくまでも結論は“創る”ものであり、調査

や分析はそれを証明するための方法なのである。

指南本の“ウソ”

コンサルタントなどが書いている計画策定や問題

解決の指南本の内容を、うのみにするのは危険で

ある。例えば、図1に示すようなプロジェクトの進行

計画は、事業計画の策定時などによく作られるもの

であり、読者も一度は目にしたことがあるはずだ。しか

し、実際にこのとおりに作業を進めても、うまく結果は

まとまらない。なぜなら、先述したように、ビジネスに影

響を与える変数は非常に多い。また、事実は複雑

怪奇であり、「そうであるとも言えるし、そうでないとも

言える」ような調査結果もある。結論となる仮説がな

いままで、この手順に従って情報を集めても、そこから何かが導き出せることはない。答えを得るには、初

めの段階で結論を仮説として設定し、それに沿って

情報を集めたり、分析したりしなければならないのだ。

では、なぜ世間の指南本は、最初に「仮説の設

定」というタスクが必要であることを書かないのだろう

か。答えは簡単である。いちばん初めに「仮説の設

定」を持ってくると、「その仮説はどこから来るのか」と

いう問いが生じてくるからだ。

また、コンサルティング会社の提案書を見ても、最

初の部分に「仮説の設定」というタスクはない。なぜ

なら、もしプロジェクトのスタート時点で結論があることを明かしてしまうと、結論ありきの“出来レース”である

かのように思われてしまうからである。コンサルティング

の報酬は、作業時間（作業期間）に基づいて請求

するのが一般的だ。そのため、作業期間が長くなれ

ばなるほど報酬額は多くなる。しかし、スタート時にす

でに結論があるとなると、結論を導き出すために長々

と行う調査／分析作業でお金をもらうことができなく

なってしまう。こうした理由から、指南本からもコンサ

ルティングの提案書からも、「仮説の設定」という項

目は削除されているのだ。

なお、「上流工程のコンサルティングは俗人的で

あり、複数メンバーで作業を分担できない」などと言

うプロジェクト・マネジャーには要注意だ。このタイプ

のマネジャーは結論となる仮説が描けず、Power

PointやExcelの上でストーリーを考えながらプロジェ

クトを進めていることが多い。そのため、作業分担が

うまくできず、プロジェクトの進め方も定まらないのだ。

こうしたマネジャーが“失敗プロジェクト”の一因となる

のである。

仮説検証法の流れ

それでは、いよいよ仮説検証法について具体的

図1：一般的なプロジェクトの手順

外部環境の調査

内部環境の調査

機会とリスクの抽出

事業戦略の策定

係数計画の策定

アクション・プランの策定

外部環境：法規制、マーケット動向、顧客ニーズ、競

合の戦略、仕入先の力量など

内部環境：自社の戦略やビジネス・モデル、強み／弱み、

コア・コンピタンスなど

図2：仮説検証法の流れ

①仮説の設定

②調査設計

③調査／分析の実施

④仮説の修正

⑤成果物の完成

7/22/2019 IT Vol.13 00.pdf



図3：仮説設定の例

わが社は、中堅の専門商社である。今日、大手の取引先が中国との直接的な取り引きを加速させており、わが社の存在意義が薄れている。そこで、伝統的な卸売りのビジネス・モデルから脱却し、情報システムを武器にサプライチェーンの一部として独自の立場を確立したい

依頼企業の戦略

わが社は創業以来、情報システムを内製してきたが、ビジネス環境の変化が激しい昨今、最新かつ最適な技術を採用し、システムを効率的に活用できているかどうか、情報システム部の要員数やスキル・レベルが適切かどうかといったことに不安がある。そこで、

今後情報システムを武器にして競争優位を確立するためにも、わが社の情報システムのあり方について検証してほしい

依頼内容

内製をやめて、外部のスペシャリストにアウトソーシングすべきである仮説（結論）

なぜ、そうすべきなのか

プロジェクト・メンバーや経験豊富なマネジャーなど、複数の人間で仮説を検討する

自社のシステムしか触っていないのでは、多くのスキルや知識は習得できないはずだ

内製したシステムではCOBOLを使っており、現在の技術水準からは乖離しているはずだ

情報システム部員の給与水準はIT業界の平均よりも低いため、有能な人材は転職し、使えない人材しか残っていないはずだ

内製したシステムは使い勝手は良いが、メンテナンスが大変なので新しいことに挑戦する余裕がないはずだ

に説明していこう。仮説検証法の一般的な流れは、

図2のようになる。以降では、この流れに沿って解説

を進める。

①仮説の設定

まず、最初に行うタスクが「仮説の設定」だ。ここ

で言う仮説とは、そのプロジェクトの「結論」を仮に

決めたものである。「調査や分析をする前に、結論

を仮決めするのは乱暴だ」と思うかもしれない。しか

し、前述したように、仮説がなければ調査や分析の

範囲が確定できないのだ。

では、少ない情報を基に、どのようにして仮説を

立てればよいのか。これは難しい問題である。率直

に言って、このタスクは論理的な作業ではなく、直

感的に右脳を働かす作業だ。こうした作業があるか

らこそ、コンサルタントには豊富な経験や知識が必要であり、明晰な頭脳が要求されるのだとも言える。

なお、「直感的に」とは言っても、別にやみくもに

設定するのではなく、複数のメンバーにより、考えら

れる限りの課題や問題点を列挙して検討を行う※1。

また、コンサルタントを使い慣れた顧客の場合、あら

かじめ仮説を提示してくるケースもある。いずれにせよ、

可能な限り、効果的で現実味のある仮説（結論）を

立てることが、このタスクの最も重要なポイントだ。

ここで、「立てた仮説が間違っていた場合、プロ

ジェクトが失敗するのではないか」と心配する方もお

られるだろう。実は、この段階で設定する仮説は、

誤っていても問題はない。もちろん、仮説が正しいに

越したことはないのだが、誤っていても後のタスクで

修正できるので、ここであまり神経質になって膨大な

時間を費やす必要はないのだ。むしろ、プロジェクト

に参加するメンバー全員が賛同できる結論を描くこ

とのほうが重要である。なぜなら、この後に登場する

「調査／分析」のタスクはプロジェクトのメンバーが

分担して行うため、彼らが仮説をしっかりと理解し、

納得している必要があるからだ。図3に、架空の会社を顧客に想定した仮説設定

※ 1 外資系の大手コンサルティング会社では、大抵、各専門分野で

豊富な経験を持つマネジャーやパートナー・クラスを集めて討議するとい

う。

多くのコンサルタントは、クライアン

トが“目からウロコ”と賞賛するような結

果を出そうとして張り切る。しかし、ク

ライアントがまったく予想もしていない

奇想天外な結論を出しても、受け入

れられることはない。それでは、とわざ

わざコンサルタントに依頼するまでもな

いような既知の事実を結論にすれば、

今度はお金の無駄だったと言われてし

まう。

仮説に最もふさわしい内容は、「ク

ライアントが予想している結果ではあ

るが、社内でだれも『そうだ』とは言い

切れない（証明されていない）結果」で

ある。さらに言えば、企業内の“聖域”

やだれも口にしないタブーなど、いつ

かだれかが手を付けなければならない

課題を取り上げるのがコツだ。

実際、クライアントから“目からウロ

コ”と評される仮説（結果）とは、「そう

だろうと思っていたが、だれも証明しな

かった」とか、「気づいていたが、口に

する者がいなかった」というような内容

なのである。

仮説立案のヒント

7/22/2019 IT Vol.13 00.pdf



目で構成されるように作るのがコツである。

また、階層の深さについては、プロジェクトの期間

や予算に合わせるかたちで検討することになる。木

構造が深ければ深いほど調査項目は多くなり、浅け

れば少なくなる。つまり、時間的／経済的に余裕の

あるプロジェクトならば木構造を深くして綿密な調査

を行い、逆に短期間／低コストで終わらせるプロジェクトは浅い木構造にする。注意が必要なのは、

プロジェクトの都合に合わせるのは木構造の深さだ

けであって、上位の構造は基本的に変わらないとい

う点だ。

なお、木構造を作る際も、複数のメンバーで課

題を列挙し、親子関係を定義していく。親の項目は

大まかで包括的な内容とし、子になるほど詳細な理

由が並ぶように構成する。ただし、この作業にもある

程度の熟練が必要だ。特に、原因と結果は複雑

に入り組んでいるため、“鶏と卵”のように、「ある課

題の原因が別の課題を引き起こすので、どちらが親

か子か判断できない」といったことがある。そうした場

合は、割り切ってどちらかを親に決めてしまう。報告

会で最も論理的な説明となるよう“創り上げていく”の

である。

図5に、調査設計の例を示す。これは、図3の仮

説を木構造にしたものだ。図5では、まず「アウトソー

シングすべき」という仮説の理由の1つとして「1. 情

報システム部員の知識が浅く、スキルが低いから」と仮定している。そして、1-①〜③では、その仮定の理

由を「給与水準が低い」とか、「教育に限界があ

の例を示す。この会社は、インテリア用品／雑貨を

扱う中堅の専門商社である。経営陣は、今後のビ

ジネス戦略として情報システムを武器にしたいと考え

ており、まずは自社のシステムや、それを開発／管理

する情報システム部の実態を知りたがっている。これ

を踏まえ、結論として「内製をやめて、外部のスペ

シャリストにアウトソーシングすべきである」という仮説を立てて、その理由をいくつか想定している。

②調査設計

続く「調査設計」のタスクは、設定した仮説を検

証するための調査／分析を計画する作業だ。調

査設計では、図4に示すとおり、仮説を頂点に「な

ぜ？」という問いかけを繰り返して木構造、いわゆる

「ロジック・ツリー」を構成する。この木構造では、1つ

の親に対して3、4つの子を配置していくのが一般的

だ。子の数が3、4つなのは、2つでは論拠が弱く、5

つ以上だと消化しきれないからである。

そして、木構造のいちばん下に並ぶ項目すべて

が調査／分析の対象になる。ロジカル・シンキング

の指南本などでは、この木構造を「MECE（Mutu

ally Exclusive Collectively Exhaustive：漏れ

なく、ダブりのない状態）」に構成するよう指導してい

るが、それはあまり現実的ではないだろう。漏れがな

いように細かく仮説を分解したところで、それらをすべ

て調査して証明することなどできない。実際には、最も説得力のある項目3つ程度に対し、3、4階層まで

作ればよい。ここでは、論理的かつ調査可能な項

図4：調査設計で作る木構造

「理由①」の理由Aなぜ？

「理由①」の理由Bなぜ？

「理由①」の理由Cなぜ？

仮説（結論）の「理由①」なぜ？

「理由②」の理由D

なぜ？

「理由②」の理由Eなぜ？

「理由②」の理由Fなぜ？

結論の「理由②」なぜ？

「理由③」の理由Gなぜ？

「理由③」の理由Hなぜ？

「理由③」の理由Iなぜ？

結論の「理由③」なぜ？

仮説（結論）

末端が実際の調査項目

7/22/2019 IT Vol.13 00.pdf



る」といった具合に分解している。

木構造が完成したら、最下位の各項目を調査す

る方法もここで確定する※2。例えば、図5の木構造

の最下位項目を調査／分析する方法の例は図6

のとおりだ。調査方法が確定したら、各項目につい

て、調査担当者や作業終了期限を決める。このよう

に調査設計を行うと、複数のメンバーで作業を分

担し、効率的にプロジェクトを進められる。また、目的不明の情報収集／インタビューなど、無駄な作

業や無意味な調査が一切なくなるはずだ。ここまで

決まれば、後は力作業だけになる。

何事も「段取り8割」と言われるように、仕事の段

取りさえ決めてしまえば、もう8割方は終わったも同然

だ。プロジェクトは、最初の「仮説の設定」と「調査

設計」の両タスクをしっかりと作り上げれば、方向性

やその後の作業内容、分担が明確になり、まず失

※ 2 調査／分析方法の確定は、骨の折れる作業だ。プロジェクトのメ

ンバーと手分けして、インターネットやデータベース・サービスなども駆使しながら利用できそうな公開情報を探すとよい。主な公開情報としては、

省庁やその外郭団体が発行している白書類のほか、継続的に実施され

ている「X XX実態調査」といった各種の調査結果、統計情報がある。

図5：調査設計の例（図3の仮説設定を木構造化）

仮説（結論）内製をやめて、外部のスペシャリストにアウトソーシングすべきである

1. 情報システム部員の知識が浅く、スキルが低いから

1-①IT業界の平均よりも給与水準が低く、有能な人材が辞めてしまうから

1-②そもそも、IT専業でない会社では教育に限界があるから

1-③部内でナレッジの共有や管理／蓄積が行えていないから

2. ハードウェアやソフトウェアが陳腐化しているから

2-①伝統的にCOBOLで内製しており、それを踏襲しているから

2-②内製要員／作業がコスト高を招いており、資金を他に回せないから

2-③複数多種のハード／ソフトを比較検討する環境や要員がないから

3. 業務にとって、効果的なシステム活用ができていないから

3-①他社の成功事例などのノウハウの流用ができないから

3-②ユーザーと内製プログラマーとの間を橋渡しする仕組みがないから

3-③ユーザーのITリテラシーが低いから

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

図6：調査／分析方法の例

テーマ木構造調査方法調査／分析方法とデータ・ソース担当期限

山田 X月X日

山田 X月X日

山田 X月X日

鈴木 X月X日

鈴木 X月X日

「仮説」

1-①

1

2

1-②

1-③

2-①

2-②

2-③

内製をやめて、外部のスペシャリストにアウトソーシングすべきである

情報システム部員の知識が浅く、スキルが低いから

ハードウェアやソフトウェアが陳腐化しているから

IT業界の平均よりも給与水準が低く、有能な人材が辞めてしまうから

情報サービス産業協会『基本統計調査』にあるIT業界のモデル賃金と比較

人事部から年間トレーニング

費用のデータを入手する

人事部から給与データを入手する

経済産業省『情報処理実態調査』にある

アンケート「情報諸経費」の結果から教育費を抜き出して比較

日本情報処理開発協会『コンピュータ利用状況調査』にあるアンケート「ITエンジニアの就業能力自己分析」の結果と比較

そもそも、IT専業でない会社では教

育に限界があるから

すべての情報システム部員に、アンケートによってITスキルの自己分析を行ってもらう

部内でナレッジの共有や管理／蓄積が行えていないから

日本情報処理開発協会『情報化白書』にあるアンケート「現在必要なプログラム言語」の結果と比較

開発言語の現状をヒアリングする

伝統的にCOBOLで内製しており、それを踏襲しているから

経済産業省『情報処理実態調査』にあるアンケート「情報処理要員の概要」と比較

情報システム部の職種別の要員数を人事部に確認する

内製要員／作業がコスト高を招いており、資金を他に回せないから

7/22/2019 IT Vol.13 00.pdf



敗することはない。失敗プロジェクトの多くは、この最

も重要な2つのタスクを十分に行わずに、いきなり調

査に入ってしまっているのである。

③調査／分析の実施

顧客が参加するのは、この「調査／分析の実

施」のタスクからである

※3

。調査設計がしっかりとできていれば、ここでの作業で特に難しい点はない。

調査設計で決めたデータ・ソースと顧客の現状とを

比較するために、アンケートをとったりインタビューを

行ったりするだけである。

ここで、図6の「調査／分析方法とデータ・ソー

ス」の項目を再度ご覧いただきたい。比較分析する

データ・ソースに情報サービス産業協会の『基本

統計調査』や経済産業省の『情報処理実態調

査』、日本情報処理開発協会の『情報化白書』と

いった公開情報を活用している。こうした資料は、

調査結果だけでなく、調査に使用したアンケート・

シートも巻末で公開している。つまり、プロジェクトのメ

ンバーは、独自に調査項目を作るのではなく、公開

されているアンケート・シートから必要な項目を抜き出

し、再構成すればよいのだ。また、図6の1-①、②、

2-②に関しては人事部に依頼し、1-③と2-①につい

ては情報システム部に確認する※4。これらの作業は、

頭脳を使う仕事ではなく、手を動かす作業なので

だれにでもできるだろう。調査／分析対象が明確なので、プロジェクトが右往左往することもないはずだ。

調査／分析の実施には顧客の協力が必要とな

るため、多くの時間を要し、またコンサルティング会

社が最ももうかるタスクだ。しかし、その前段にある調

査設計がきちんと行われていれば、経験の浅いコン

サルタントでも担当できるので、プロジェクトのコストを

安く抑えられる。1つだけこのタスクにおける注意点を

挙げるとすれば、調査の際に仮説が正しいかのよう

な結果を無理に引き出したり、こじつけたりせずに、ありのままをまとめるようにすることだ。

④仮説の修正

調査／分析が終了したら、最初に立てた「仮

説」が正しいかどうかを検証する。先に述べたように、

設定した仮説は間違っていてもかまわない。なぜな

ら、このタスクで仮説を修正するからである。

図3では、「内製をやめて外部のスペシャリストに

アウトソーシングすべきである」というのが結論に当た

る仮説だったが、調査した結果いくつかの点が異

なっていたとする。例えば、図7に示すように1-①〜

③の仮説が誤っており、「情報システム部員の知識

が浅く、スキルが低いから」という仮説が立証できな

かったとしよう。その代わりに、ハード／ソフトへの投

資に関する意思決定を行う経営陣や、システムを

利用するユーザー側に問題のあることが判明したの

であれば、仮説を「ハード／ソフトの両面を刷新する

とともに、経営陣やユーザーのリテラシーを向上し、

システムの効果的活用を推進すべきである」と変更することになる。

それでは、仮説がことごとく間違っていた場合には

どうなるだろうか。図8に、すべての仮説が証明でき

なかったケースを示す。この図によると、情報システ

ム部には高いスキルを持つ優秀な人材が多く所属

している。また、システムには最新技術を利用してお

※ 3 そのため、顧客から見ると、ここからプロジェクトがスタートするよう

に見える。

※4 具体的には、調査対象の部門ごとに依頼内容や質問内容を取り

まとめ、部門別の依頼／質問シートを作成することになる。

仮説検証法は、仮説の理由（また

は課題の原因）を構造化するものであ

り、構造を知ることによってその仮説

を証明（課題を解決）する。そのため、

当初立てた仮説が誤っていても、構

造さえしっかりと作れば後で正しい結

論に修正することができる。

これは、裏を返せば、そもそも構造

がわからないような問題については仮

説検証法は使えないということだ。そ

の場合、科学の実験などで使われる

「不明推測法」を使うことになる。不

明推測法では、実験を繰り返すこと

で、仮説を裏づけながら構造を明らか

にしていく。

例えば、脳のメカニズムを解明する

場合、仮説を立案してもそこに至るま

での構造がわからない。そのため、仮

説検証法のように仮説が反証された

からといって、別の結論を導くことがで

きないわけだ。そこで、実験を繰り返

すことで構造も明らかにするのである。

不明推測法の場合、重要なポイント

となるのは「実験を考案すること」とな

る。

「仮説が誤っていた場合には、調

査を初めからやり直さなければならな

い」といった状況に陥るとすれば、そ

の課題の構造が明らかにできないこと

が原因だ。こうした場合には、不明推

測法を利用すべきである。構造は明

らかなのに再調査が必要になるのは、

調査設計の失敗だと考えればよい。

不明推測法の利用

7/22/2019 IT Vol.13 00.pdf



図7：仮説の修正（部分的な修正）



修正後の仮説（結論）

ハード／ソフト面を刷新するとともに、経営陣やユーザーのリテラシーを高め、システムの効果的活用を推進すべきである












有能な人材が多い

十分な教育を行っている

共有／蓄積は適切である

仮説のとおりだった






なぜ？

なぜ？

調査結果

仮説の修正

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

図8：仮説の修正（全面的な修正）



修正後の仮説（結論）

システムを効果的に活用しており、情報システム部のスキルも極めて高いため、ITの事業化や外販などの新規事業を実施すべきである












有能な人材が多い

十分な教育を行っている

共有／蓄積は適切である

最新言語で内製している

極めて低いコストで内製している

詳細な検証を実施する

成功事例を活用している

システム企画力は高い

リテラシーは極めて高い

なぜ？

なぜ？

調査結果

仮説の修正

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

なぜ？

7/22/2019 IT Vol.13 00.pdf



り、ユーザーのリテラシーも高く、システムを効果的に

活用できている。こういった場合は、「システムを効果

的に活用しており、情報システム部のスキルも極めて

高いため、ITの事業化や外販などの新規事業を

実施すべきである」といった具合に結論を修正する。

ここで、「そもそも誤った仮説の下に集めた調査

結果から、異なる結論を出すのは危険であり、再度仮説の設定からやり直すべきではないか」と考え

る読者もいるだろう。しかし、仮説は誤っていても調

査結果は真実である。つまり、真実である調査結

果を積み上げれば、それは真実の結論と言える。

例えば、図8の例ではすべての仮説が反証され

た。そこで、仮説設定からやり直すとしよう。「システ

ムを効果的に活用しており、情報システム部のスキル

も極めて高いため、ITの事業化や外販などの新規

事業を実施すべきである」という仮説を再設定し、

改めて調査設計するとどうなるだろう。実は、調査

設計の木構造は図8の木構造とまったく同じになる。

なぜなら、「今までは社内部門の1つであった情報

システム部が、その能力を外販するシステム・インテグ

レーターになるためには、スキル・レベルや最新技術

の活用、業務への効果的な活用方法などを知って

いる必要がある」ということになるからだ。これらの項

目は図8ですべて洗い出されており、わざわざ再調

査をする必要はない。

このように、仮説が大幅に誤っていたとしても、再調査を行うのではなく、結論部分を事実に即した

内容に修正すればよい。こうすることで、手戻りがな

く、スケジュールどおりにプロジェクトを進められるの

である。

仮説検証法で最も重要なことは、最初に立てる

仮説の“確からしさ”ではなく、調査設計で作成する

木構造の「構造」である。これさえしっかりと作成し

ておけば、調査結果を基に仮説を修正することが

可能だ。逆に言えば、「一からやり直さなければなら

ない」という事態に陥るのは、この構造を作成する

工程で失敗しているせいである。図8の例で言えば、

情報システム部のスキルだけに固執して、それ以外

を調査しないといった具合だ。このように偏った調査

では、仮説が正しいという結果が出たとしても、ユー

ザー側の問題に触れていないため、情報システム

部はその結果に納得しないだろう。つまり、仮説が立証できても反証されても、どちらの場合でも失敗と

いうことになる。こういった場合にこそ、再調査が必要

となるのだ。

なお、最も重要である「構造の創り方」について

は、後ほどその秘訣を解説する。

⑤成果物の完成

最後の「成果物の完成」タスクでは、④までの

作業内容を報告書にまとめる。ここで重要となるのは、

報告書のストーリーボードである※5。どれだけしっかり

と調査を行っても、ストーリーボードを誤ると悲惨な

結果になってしまうことが多い。とは言え、「結論から

述べる」というやり方は、調査設計で作った木構造

と基本的に同じなので、このタスクで特に苦労するこ

とはないはずだ。

仮説検証法の秘訣

ここまでひととおり、仮説検証法のプロセスを解説してきた。企業の戦略であれ、業務改善であれ、そ

してITシステムの導入であれ、仮説検証法はどのよ

うなプロジェクトにも適用できる。しかし、実際にやっ

てみると簡単ではない。仮説を分解して木構造を作

る部分がこの手法で最も重要なのだが、偏りのない

構造を“創る”のが難しいのである。

そこで最後に、木構造を簡単に作る秘訣を伝授

※5 ストーリーボードの詳細については、前回の記事を参照されたい。

多くのコンサルティング会社では、ト

レードマークを付けた独自のメソトロジー

（方法論）を持っている。実は、このメ

ソトロジーとは仮説検証法で作成する

「構造」を汎用化したものだ。

例えば、あるコンサルティング会社

が「情報システム部を評価するメソトロ

ジーを持っている」という場合、そのメ

ソトロジーとは本編で紹介した図5のよ

うな構造と図 6のようなデータ・ソース、

図 6 の調査を行うためのアンケート・

シートなどをパッケージングしたものだ

と考えてよい。

仮説検証法の場合、重要なのは

仮説の確からしさよりも、それを論証

する「構造」である。きちんとした構造

を作れば、その構造から仮説の誤りも

修正できるからだ。そのため、コンサ

ルティング会社はこの「構造」を重要

なノウハウとして位置づけ、メソトロジー

という名の商品にしているのである。

コンサルティング会社のメソトロジー

7/22/2019 IT Vol.13 00.pdf



しよう。

木構造作成の秘訣

木構造の作成で十分注意してほしいのは、その

構造が偏らないよう、できるだけ包括的なものにすることだ。先に書いたが、この構造さえしっかり作れば、

結果の「仮説」は後から修正できるが、ここで失敗

すると再調査などの手戻りが多く発生してしまう。成

功の秘訣は、仮説を最初に分解する際（第 1階層

への分解時）は、「戦略」や「業務」、「IT」といった

大きなくくりで分解していくことだ。ほとんどのプロジェク

トでは、表1に示す視点から3、4つ選べばよいだろう。

プロジェクトのテーマや規模によっては、表1にある

視点を部門や特定領域に限定して使うとよい。

例えば、前掲の図5の場合、第1階層の最初の

項目にある「情報システム部の知識が浅く、スキルが

低いから」は、表1の「スキル／知識」の視点を組

織に限定して適用している。同じく2つ目の項目にあ

る「ハードウェアやソフトウェアが陳腐化しているから」

は「IT／システム」、3つ目の項目は「業務／主要プ

ロセス」の視点を適用したものだ。

また、第2階層以下については、第1階層で挙げ

た項目を表2の視点で分解するとよい。これらの視

点を利用することにより、効率的に分解できるはずだ。

そして、各項目をバランス良く配置すれば、たとえ結

論となる「仮説」が誤っていたとしても、容易に修正

が行えるだろう。

繰り返しになるが、仮説検証法で最も重要なポイントは、最初に立てる仮説の確からしさではなく、そ

の仮説を分解して証明していく木構造の「構造」で

ある。これを失敗すると、すべて失敗することになると

言ってもよいだろう。表1、2を参考に、仮説が誤って

いても使える木構造を作ることが肝要だ。

＊＊＊

以上、前回と今回の2回にわたり、コンサルタント

が駆使する基本テクニックを紹介した。次回からは、

これまでの内容も応用しつつ、コンサルタントの最大

の“武器”とも言える「ミリオン・チャート」について解

説していく。ミリオン・チャートとは、たった1つで100万

ドル（およそ1億円）を稼ぎ出す優れた図表の総称

で、戦略系コンサルタントがよく使うものだ。顧客をう

ならせるような優秀なコンサルタントは、必ずこのミリオ

ン・チャートを活用している。一流のアーキテクトを目

指す読者には、ぜひこの応用技を盗み取っていた

だきたい。

表1：仮説を最初に分解する際の視点

視点説明

戦略／方針中期的なビジョンや戦略、方針といった業務遂行の上位概念

目標値目標利益やROA（総資本利益率）、RO E（株主資本利益率）など、大目標となる数値や係数

マーケット動向マーケットのトレンドや環境変化、技術動向など

顧客ニーズ顧客満足度、度重なる重要度の高いクレームなど

競合／競争規制緩和や競合相手、新規参入者など

商品／サービス自社または他社の商品やサービス、アフターケアなど

業務／主要プロセス主要な業務プロセスやルール、内部統制など

スキル／知識従業員のスキルや知識、およびその蓄積／伝承など

IT／システムハードウェア／ソフトウェアやネットワーク、アーキテクチャなど

文化／伝統組織に内在する不文律や慣習、意識、カルチャーなど

表2：仮説を第2階層以下に分解するときの視点

視点説明

コスト／価格コストや価格などの財務的な価値基準

スピード／時間早さや所用時間、タイミング（時期、季節）など

品質品質や精度、エラーの少なさ、歩留まりなど

数量要員数や商品数など、力量に影響を与える数量の多少

組織／責任組織の数や機能、役割分担、責任や権限など

業務機能業務プロセス内の各機能や業務固有の機能など

教育トレーニング・プログラムや制度、従業員育成に関する設備など

ノウハウ独自の技術や特許、知識、それを支える仕組みなど

労力／負荷難易度や複雑さ、工数、手間など

ロケーション商圏や立地環境、距離、物流要件など

7/22/2019 IT Vol.13 00.pdf


業

種

／

業

態

に

固

有

の

知

識

が

エ

ン

ジ

ニ

ア

の

価

値

を

高

め

る


今日、コンプライアンスの強化、価値あるサービスの提供、

顧客との良好な関係の構築が求められている金融業の特徴は、

他業種と比べてIT投資額が大きい点だろう。

今回は、金融業の主な特徴や動向を紹介したうえで、

クレジットカード会社、消費者金融会社、信販会社、リース会社を含む

「ノンバンク」の業務について解説する。

杉村まきこ Makiko Sugimura

業務知識

講座

金融業（ノン

バンク）

規制緩和と競争激化への対応で鍵を握るのは、

﹁基幹システム／外部システ

ムのスムーズな連携、顧客情報の分析と活用

、

そしてコンタクト・センター

の戦略的な活用﹂

最終回

金融業界の概要

「金融」とは、お金が余っている人

（資金余剰者）が、お金を必要とする人

（資金不足者）に融通することを言う。こ

の金融にかかわる企業を「金融機関」と

呼ぶ。

製造業がモノを作り、それを流通業

や卸売／小売業が消費者に届ける。こ

の経済活動に必要不可欠なのが「お

金」であり、それがスムーズに流れるよう

直接的／間接的に支えているのが金

融業である。そのため、金融業が他の業種に与える影響は大きい。また、日本

では法律や行政指導による規制が多い

のが、この業種の特徴だと言える。

金融機関の分類

「金融機関」の種類には、銀行や証

券会社、保険会社のほかに、クレジット

カード会社や信販会社などが属するノン

バンクがある（図1）。

銀行には、都市銀行と地方銀行、

信託銀行の3種類があり、それらの預金

総額は500兆円（今年3月末時点）を越

えるとされる。

また、郵便貯金取扱機関とは、いわ

ゆる郵便局のことを指し、その貯金総額

は180兆円（今年7月末時点）を超える。

これが今年10月に民営化され、ゆうちょ

銀行が誕生することは読者もご存じだろ

う。

信用金庫、信用組合などは、個人

／中小企業向けのリテール分野を対象

とする共同組織金融業に分類される。

そして、非預金信用機関（ノンバンク）とは、融資は行うが、銀行のように預金

の受け入れをしない金融機関のことだ。

読者の財布の中にも、クレジットカード

が何枚か入っていることだろう。クレジット

カードを使うと、モノやサービスを購入し

た時点では代金を支払わずに、後日、

一括あるいは分割してカード会社に返

済することになる。このとき、モノ／サービ

スの購入は、カード会社からカードの持

ち主に対して付与された“信用”に基づ

7/22/2019 IT Vol.13 00.pdf



いて行われる。この信用のことを「販売

信用」と呼ぶ。一方、カードでキャッシン

グしたり、ATMで現金を借りたりすること

を「消費者金融」と言う。この場合、カー

ド会社が消費者に対する債権者となり、金銭を貸し付ける。今日、販売信用と

消費者金融を併せた信用供与額は76

兆円（2005年度末時点）を超えていると

いう。

そして、これらのほかに、証券業と保

険業がある。

証券会社は、有価証券の売買や仲

介、取り次ぎなどを行う。近年、インター

ネット上での仲介に特化した、いわゆる

“ネット証券”が登場してきた。ネット証券

は、店舗や営業社員をほとんど持たない

ことで経費を下げ、仲介手数料を格安

に設定して個人投資家の顧客を増やし

ている。

一方、保険業には、終身保険、定

期保険、養老保険などを扱う生命保

険会社と、火災保険や自動車保険など

を扱う損害保険会社とがある。最近は

保険金の不払いが社会問題となっているが、その対策として、顧客管理や支払

い状況管理のためのシステムに投資す

る会社もある。

金融業界の動向

日本国内ではこれまで、強い規制の

下、銀行は銀行業、保険会社は保険

業、証券会社は証券業にそれぞれ従

事するという「専業主義」がとられてきた。

だが、1993 年の金融制度改革により、

業態別子会社での相互参入や金融

持株会社が解禁され、金融システム改

革法で子会社規定の整備などが行わ

れた結果、金融コングロマリット化が進ん

でいる。金融コングロマリットとは、銀行、

証券、保険などの金融業者から構成さ

れたグループのことを指す。

また、2000年ごろから、銀行と大手消

費者金融会社の合弁により、銀行系

消費者金融会社が設立され始めた。こ

の銀行系消費者金融会社を通して、

銀行の従来基準では借り入れが難しかった層への融資が行われるようになっ

ている。

このように、現在、銀行や証券、保

険、クレジットカード、消費者金融などさ

まざまな業態の金融業者が大手ファイナ

ンシャル・グループの下に集まりつつある。

その背景には、グループ内で幅広い金

融商品を一括して取り扱うこと（ワンストッ

プ・ショッピング）により、売上増加やブラ

ンド力の向上、マーケット・パワーの拡大

などを図り、収益を増強しようとのねらい

がある。

こうした企業の合併／提携の背後で

は、当然ながらシステムの統合や連携が

進められる。金融業界でシステム構築を

行うにあたっては、このような動きがあるこ

とを理解しておかなければならない。

さらに、今年 9月30日に金融商品取

引法が施行される。同法は、金融／資

本市場を取り巻く環境の変化に対応し、

利用者を保護するルールの徹底と、利

用者の利便性向上、貯蓄から投資に向けた市場機能の確保、金融／資本

市場の国際化への対応を目指すものだ。

具体的には、「①投資性の高い金融商

品に対する横断的な投資者保護法制

（いわゆる投資サービス法制）の構築」、

「②開示制度の拡充」、「③取引所の

自主規制機能の強化」、「④不公正取

引などへの厳正な対応」という4つの柱

から成る。金融業界にかかわるアーキテ

クトは、ぜひ知っておきたい法律だ。

図1：金融機関の分類（日本標準産業分類を基に作成）

都市銀行、地方銀行、信託銀行など

信用金庫、信用組合、労働金庫、農協、漁協など

日本郵政、中小企業金融公庫、国民金融公庫など

クレジットカード会社、信販会社、消費者金融会社、

リース会社など

証券会社、先物取引会社など

生命保険会社、火災保険会社、海上保険会社など

金融業

銀行業

共同組織金融業

郵便貯金取扱機関／

政府関係金融機関

貸金業、

非預金信用機関（ノンバンク）

証券業、

商品先物取引業

保険業

7/22/2019 IT Vol.13 00.pdf



付けに加えて、コールセンター、Webサイト

（PC向け、携帯電話向け）、無人機と

いった非対面型のチャネルが活用され

る。スーパーなどが即日発行する流通系

のクレジットカードや、TV CMでPRして電話でスピーディに入会受付をする消

費者金融のように、いかに興味を持って

もらい、また逃さず会員になってもらうかが

ポイントとなる。そのため、プロモーション

用のマーケティング関連システムや入会

受付用のコンタクト・センターを充実させ

ている企業が多い。なお、信販業務に

おける与信では、加盟店からショッピン

グ・クレジット（個品割賦）の申し込みが

FAXなどで送付されると、審査部門が

即時審査を行って電話で可否を回答

する。

「入会審査」や「与信業務」では、申

し込みがあった個人に対し、その信用

度合いを評価して、金銭の融資枠の設

定や、クレジットカード利用の承認を行う。

この信用度合いを評価する仕組みは

「スコアリング・システム」と呼ばれる。ノン

バンクが行う無担保のローンやカード融資では、銀行のように不動産などを担保

にとってその評価額に応じた融資を行う

のではなく、個人の属性や借り入れ状

況に応じて融資／クレジットの限度額を

算出する。スコアリングの方法は、クレ

ジットカード会社や信販会社、消費者

金融など業態によって異なるが、貸し倒

れのリスクを最小限に抑えつつ最大限

の収益を確保するうえで、この部分のノウハウが非常に重要となる。

「会員管理」では、利用者である会員

の基本情報管理（登録／変更）、ポイン

ト管理、コンタクト履歴管理などを行う。

クレジットカード会社では、以上の新規

開拓から審査／与信、会員管理までの

業務を「イシュアー（Issuer）業務」と呼

んでいる。イシュアーとは、クレジットカード

を発行して利用者の与信審査を行う会

社のことで、銀行系、流通系、信販系、

消費者金融系などの種類がある。

「回収業務」、「債権管理」とは、融

資した金銭やクレジット代金を回収する

ことだ。通常は、毎月1回、一定額を利

用者の口座から引き落としたり、会社指

定の口座に振り込ませたり、ATMや店

舗、コンビニで入金させたりといった方

法がとられる。

もし、返済が滞った場合には、督促が行われる。口座残高不足や支払い

忘れなどの初期督促は、書面での通知

や電話での連絡となる。そして、未払い

期間が数カ月になると、専門部署による

カウンセリング、督促が行われる。資金

の回収状況は収益に直接影響するた

め、回収率の向上は各社に共通の経

営課題だと言える。

また、前述したように、クレジットカード

会社や信販会社の場合には「加盟店

ノンバンクの基本知識

金融業に関するすべての業務知識を

解説するのは紙数の都合上難しいため、

以降では、さまざまな業態のある金融業の中から、ノンバンクに焦点を当てて解

説していく。現在のノンバンクは、銀行ほ

ど特定ベンダーによる寡占の度合いが高

くないので、さまざまなベンダーのアーキ

テクトがかかわる機会が多いだろう。

ノンバンクにおける業務の流れ

図1にも記したように、ノンバンクには、

クレジットカード会社、信販会社、消費

者金融会社、リース会社が含まれる。

業務プロセスは業態によって異なるが、

会員（顧客）向けに行われる共通の業

務として、「新規開拓」、「入会審査」、

「与信業務」、「回収業務」、「債権管

理」、「会員管理」などがある。また、クレ

ジットカード会社や信販会社の場合は、

ほかに「加盟店管理」や「個品割賦管

理」といった業務が発生する。図2に示

すのは、クレジットカード会社と消費者金融会社における業務の大まかな流れだ。

上記のうち、「新規開拓」とは、新た

に会員になってもらうための一連の業務

を指す。新規開拓には、店舗での受け

開示規制と行為規制

金融商品取引法は、日本版SOX法

として、「内部統制の強化」や「文書

化3点セット」がIT業界でも話題になっ

ているので、多くの方がご存じだろう。

これらは、本編で挙げた4 つ柱の 1つ

「開示制度の拡充（財務報告にかかわ

る内部統制の強化）」への対応と位置

づけられる。上場企業および連結子

会社を中心に、来年 4月以降の事業

年度からの適用に向けて準備が進め

られているところだ。

金融機関に対しては、この開示制

度の拡充に加えて、投資者保護や不

正取引への対応のための「行為規制

（誠実公正義務、書面交付義務、虚

偽情報禁止など）への対応」が求めら

れている。例えば、銀行の窓口などに

おいて、投資信託や外貨預金などの

ような元本割れのリスクがある商品を

販売する場合、十分な説明が義務づ

けられるようになる。そのため、各金融

機関では、販売／勧誘ルールの徹底

を図るために、コンプライアンスの強

化や販売業務の効率化を目的としたリ

スク商品販売支援システムの導入など

が進められている。

7/22/2019 IT Vol.13 00.pdf


業務知識

講座


管理」という業務がある。この業務では、

加盟店の申込受付、審査、契約、取扱

商品の設定、加盟店に支払う手数料

の設定、売上／支払管理などを行う。

加盟店の獲得や取引管理は「アクワ

イアラー（Acquirer）業務」と呼ばれる。

アクワイアラーとは、加盟店との間で契

約を結んで手数料を徴収するカード会

社のことを指す。クレジットカード会社と

加盟店、カード会員（利用者）との間に

おける決済の流れは、図3のようになる。

ノンバンクの主な業務とシステム構築のポイント

続いては、ノンバンクにおける主な業

務の内容と、システム構築時のポイントを

紹介していこう。なお、詳細はそれぞれ

後述するが、ノンバンクの情報システム

構築では、「基幹業務システムと外部シ

ステムとのスムーズな連携」、「マルチチャ

ネルに対応するためのコンタクト・セン

ター」、「データ・ウェアハウスやデータ分

図2：クレジットカード会社／消費者金融会社における業務の流れ

●クレジットカード会社における業務の大まかな流れ

会員向け新規開拓入会審査与信／カード発行売り上げ／

貸し付け請求回収債権管理／

カウンセリング

●消費者金融会社における業務の大まかな流れ

会員向け新規開拓申込受付与信貸し付け初期回収債権管理／

カウンセリング

加盟店向け新規開拓加盟店審査加盟店登録オーソリゼーション伝票回収代金支払い

（手数料回収）

ショッピング／キャッシング

国際ブランド

クレジットカードの中には、「国際ブ

ランド」と呼ばれるカード・ブランドがある。

これは、世界中で利用可能なクレジッ

トカードのインフラを提供するブランド

（会社）のことを指し、VISA、MASTER、

AMEX、JCB、DINERSがある。このう

ち、“2 大ブランド”とも呼ばれるVISAと

MASTERは、自社でカードを発行しな

いブランド・ホルダーだ。

国際ブランドは、イシュアー（カード

の発行会社）やアクワイアラー（加盟

店と契約するカード会社）と契約し、

カードの発行、取り扱い、加盟店開拓

の権利を与えている。

なお、JCBは日本で唯一の国際ブラ

ンドであり、イシュアーとアクワイアラー

の機能も併せ持っている点を特徴とす

る。

析など情報系システムの有効活用」とい

う3つの領域が重要なポイントとなる（次

ページの図4）。

入会審査／与信業務

年々競争が激化する業界の中でサー

ビスを強化していくためには、入会受付

の時間短縮が必須となる。さらに、店舗

や郵便での受け付けに加えて、コールセ

ンターやWeb経由などマルチチャネルへ

の対応も考慮しなければならない。

入会審査業務に関する課題としては、

図3：クレジット決済の流れ

カード会社

②カード・チェック（オーソリゼーション）

③チェックOK

⑤売上代金の請求

⑥売上代金振込（立替払い）

④商品／サービスの提供

①カードの利用 ⑧口座振替、入金

⑦カード利用代金請求

会員

加盟店

7/22/2019 IT Vol.13 00.pdf



申込書などの書類管理が煩雑であるこ

とや、審査そのものに時間がかかること、

審査途中での状況把握が大変であるこ

となどが挙げられる。そこで、FAX OCR

やイメージOCRによるペーパーレス化、

外部の信用情報機関への信用情報照

会の自動化、審査業務のワークフロー

管理などにより、カード発行までの時間

を短縮するとともに、審査途中での問い

合わせ対応を実現するためのシステムが

導入されている。●システム構築時のポイントは「スムー

ズなシステム連携」

入会審査支援にかかわるシステムを

構築する際に留意すべき点は、各種機

能間や基幹システムとの連携方法だ。

OCR機能やワークフロー機能など単独

の機能だけをそろえても意味がなく、一

連の作業をいかにスムーズにつなげられ

るかがポイントとなる。例えば、Web経由

で受け付けた申し込み情報をシステムに

自動的に取り込んだり、入会希望者の

情報やその審査結果を基幹システムに

渡したりといったことだ。要件定義のヒア

リングを実施する際には、一連の業務

内容と利用している既存システムとをきっ

ちりと洗い出し、連携の範囲、実現する

機能を選択していくことが求められる。

カード会員の契約や融資可否に関す

る審査業務は、システムによる自動与信

と、決裁権者与信の双方によって行わ

れる。多くの個人に無担保で融資を行うためには、与信を正確かつ効率的に

行うことが要求される。審査の基準が曖

昧だと、可否を判断するまでに時間がか

かったり、担当者によって審査結果が異

なったりといった事態が生じてしまう。また、

自動審査システムを導入する場合には、

それに伴う審査基準の見直しをどのよう

に進めるかについて、業務要件の検討

が必要となる。

なお、与信基準は「スコアリング・シス

テム」（詳細は後述）と呼ばれ、これは各

社が独自に作成している。一般には、年

齢、職業、家族構成、年収といった個

人属性や他社からの借り入れ、返済状

況が基準に利用される。また、与信は入

会後も継続的に行うが、これを「途上与

信」と呼ぶ。利用状況や返済状況に基

づいて審査を行い、会員の返済能力を

チェックして、融資限度額を随時変更す

るのである。ここでは、転職などによって

給料日が変わった場合に、効果的な回収を行うために支払日を給料日の直後

に変更するといった対応のために、会員

情報管理との連携が必要になる。

スコアリング・システム

入会審査を行うスコアリング・システム

には、大別して2つの種類がある。1つは

主にクレジットカード会社が利用している

「属性ポイント」、もう1つは消費者金融

会社が利用している「属性モデル」だ。

図4：ノンバンクのシステムの全体像

入会受付／審査システム

与信、途上与信システム

回収／債権管理システム

会員（顧客）管理システム

加盟店管理システム

売上管理システム

個品割賦契約管理システム

CD、ATM（店舗、無人機）

CAFIS※

提携カード会社

（VISA、Masterなど）

提携先銀行

情報系システム（データ・ウェアハウス／分析）会計／経理システム

※ NTTデータが提供するオンライン与信サービス。

個人情報信用機関（CIC／JICなど）

コンタクト・セ

ンター・システム

外部連携インタ

フェース・システム

電話

携帯電話

Web

電子メール

ダイレクト・メール

顧客（会員）／加盟店

7/22/2019 IT Vol.13 00.pdf


7/22/2019 IT Vol.13 00.pdf



イル）の整備など、金融機関全般におい

て重要な業務の1つとなっている。

●データ・ウェアハウス／データ・マイ

ニング技術の活用

クレジットカード会社では、名寄せによって統合された顧客データベースを活

用し、さまざまなプロモーション活動を行

う。そのベースとなっているのは、データ・

ウェアハウスやデータ分析システムだ。こ

れらにより、会員の「属性情報」、「購買

情報（商品／利用店舗、地域、時間な

ど）」、「キャンペーン参加情報」といった

データを一元管理するのである。そして、

会員の趣味／嗜好、ライフスタイルを分

析し、ニーズにきめ細かく対応することで、

利用促進を図る。こうした顧客のセグメン

ト化に活用されるのがデータ・マイニング

技術だ。

大手のクレジットカード会社では、分

析結果に基づいた顧客モデルを設定し、

利用明細書に同封する会員誌やプロ

モーション内容をカスタマイズしている。

データ・ウェアハウスやデータ分析システ

ムの構築と言えば分析手法や能力が注目されがちだが、カスタマイズした情報を

いかにして会員誌に同封するか、その

ターゲットがコールセンターやWebサイト

でコンタクトしてきたときにどう対応するか

といったオペレーションまで考慮してシステ

ム設計を行わないと、“絵に描いた餅”と

なってしまうので注意が必要だ。

不正利用対策

昨年、スキミングによるカード偽造や

「なりすまし」によるクレジットカードの不正

利用の被害額がついに100億円を超え、

大きな社会問題となった。この不正利用

を防止するため、近年ではICカード化を

推進したり、売上伝票のカード情報（番号／有効期限）を非表示にしたり、不

正利用検知システムを導入したりといっ

た対策がとられている。

不正利用検知システムでは、クレジッ

トカード利用における不正利用の割合を

スコアリングして不正を検知する。具体

的には、カード会員の属性情報、利用

履歴、そして不正利用の手口をシステム

に蓄積することで、スコアリングの精度を

高める。加盟店からオーソリゼーションの

データ（信用照会情報）が送信されると、

過去の取引情報を基に不正利用確率

のスコアが審査部門に通知され、不正

利用の疑いが高い場合は即座に加盟

店や利用者にコンタクトして不正利用を

防止する。こうした不正検知システムを

構築する際には、入会審査と同様、基

幹系システムとの連携の可否を見極め

たうえで設計に入る必要がある。

債権管理／回収業務

ノンバンクでは、期日管理により、利

用者の返済が期日どおりに行われている

かどうかをチェックする。もし、カード請求

の支払いが滞ったり、融資の返済が遅

れたりした場合には、督促が必要になる。

督促業務は、本人宛に電話をかけて行

う。クレジットや消費者金融などでは、そ

の際に匿名性が求められるので、職場

はもちろん家族であっても「引き落としさ

れなかったので、すぐに返済してほしい

……」といった伝言はできない。ゆえに、

督促対象の本人にいかに直接コンタク

トするかがポイントとなる。初回の延滞者などを対象にした初期

督促であれば、できる限り短時間で多く

の対象にコンタクトするための仕組みが

必要になる。そこで、電話による初期督

促業務を行うコールセンターでは、プリ

ディクティブ・ダイアラー※1など発信作業

効率化のためのシステムを活用している。

ここで注意が必要なのは、すでに入

金を済ませた会員に対し、誤って再督

促をしないことだ。督促対象者のリストは

事前に勘定系データからバッチ処理で

抽出されるが、コールセンターのオペレー

ターが実際に督促電話をかけるのは、

バッチ抽出から一定時間が経過した後

となる。よって、電話をかける前に、対象

者がその後ATMや銀行で入金を済ま

せていないかどうかを確認しなければなら

ない。ここでは、勘定系とのリアルタイム

な連携を実現するのは困難なので、ディレード・オンライン（遅延型オンライン）※2な

どの方式がとられる。

一方、未払い回数や延滞日数の多

※1 コールセンター業務を効率化するための交換機シ

ステム。データベースなどの顧客情報に基づいて自動

的に発信処理を行い、相手につながった電話をオペ

レーターに割り当てる。

※ 2 オンライン処理方式の 1つで、処理データを一定

量蓄積し、必要なタイミングで処理を行う。リアルタイム

処理と比べてシステムの作り込みや処理負荷の面で負

担が少なく、またバッチ処理と比べて処理タイミングをよ

りリアルタイムに近づけられる点に特徴がある。

7/22/2019 IT Vol.13 00.pdf


業務知識

講座


い中長期延滞者の場合、専門スタッフ

によるカウンセリング督促を実施して早期

回収を目指す。回収率向上のためには、

本人コンタクト率の向上に加えて、手元

にお金が入るタイミングで効果的に督促するなど、顧客属性や利用履歴といった

データの分析／活用が求められる。ま

た、優秀な専門スタッフの回収ノウハウ

を標準化して共有するための仕組みも

必要になるだろう。こうした債権管理は、

スタッフの教育も含めて各社が重要課

題ととらえている業務だ（表1）。

債権の回収率は収益に大きく影響す

るが、一方で不当な回収方法による貸

金業法への抵触などのリスクが存在す

る。そこで、法的処理が発生する債権管

理業務は、数カ所の管理センターに集

中化／専門化する企業が多い。

今日のノンバンク業界では、「個人情

報取り扱いの徹底」、「コンプライアンス

強化」への関心が非常に高くなっている。

特に、債権管理部門では個人情報を

集中的に取り扱うため、徹底した対応

が求められる。システム構築にあたっては、この辺りの背景を理解しておく必要

があるだろう。

コンタクト・センターの活用

各種金融機関では、店舗や渉外担

当者による対面での対応に代わり、コー

ルセンターやWebサイト、携帯電話など

非対面型チャネルでの取り引き／コンタ

クトを増加させている。

Webサイトの場合、人手を介さない

分、1件当たりの処理コストが低く、入会

申込受付や会員による取引明細確認と

いった定型的な業務処理に適している。

しかし、双方向のやり取りができないため、

よくある問い合わせと回答例を検索でき

るFAQシステムなどにより、利用者の疑

問に答える必要がある。このFAQの充

実が、電子メールや電話での問い合わ

せ件数の削減に貢献するだけでなく、

顧客満足度の向上にもつながる。

コールセンターでの受信業務としては、

フリーダイヤルによる入会申し込みやさまざまな相談への対応が挙げられる。ここ

では、十分な教育を受けたオペレーター

による丁寧な対応が、申し込みを迷って

いる人の後押しをしたり、利用者の疑問

を速やかに解消したりといったことに結び

付く。また、ゴールドカード保持者のよう

な得意客向けの専門デスクでは、付加

価値の高い対応が求められる。

一方、コールセンターからの発信業

務としては、利用促進や付随サービス

の案内といったプロモーション活動や、

初期延滞者向けの督促活動などが挙

げられる。なかには、中期延滞を専門に

取り扱う集中センターを構築している

ケースもある。

このように、コンタクト・センターで行う

業務では、これまでに解説してきた入会

審査から会員管理、回収業務までのす

べてが対象となる。電話、Webサイト、

電子メール、携帯電話など、各チャネル

の特性を十分に踏まえたマルチチャネル

対応のCRMシステムが、ノンバンクの業務を支えるうえで非常に重要な役割を果

たすことになるのだ（次ページの図6）。

加盟店管理業務

クレジットカード会社のカード加盟店

になる際には、会員の入会審査と同様

に加盟店審査がある。この審査は、取

り扱い商品や業種、開業（開店）後の

営業年数、実店舗の有無などを踏まえ

て行われる。加盟審査が無事に終わる

グレーゾーン金利

最近、「グレーゾーン金利」という言

葉がメディアでもよく取り上げられてい

る。これは、利息制限法によって定められた民事上の上限金利（1 5〜

20％）と、出資法で定められている刑

事上の上限金利（2 9. 2％）の間の金

利を指す。

グレーゾーン金利での融資は一定

の条件を満たす場合にのみ認められて

いるが、無担保ローンの金利はグレー

ゾーン（20％〜29％）の範囲で設定さ

れることが多い。2009 年にこのグレーゾーン金利が撤廃されることになり、ノ

ンバンク各社は前倒しで金利引き下げ

に取り組んでいる。金利引き下げに

よって利ざやが縮小する中で、どのよう

なビジネス・モデルを見いだすかが喫

緊の経営課題だ。

表1：債権管理の区分

初期延滞中長期延滞法的処理／償却

定義 1日〜1カ月（または2カ月）延滞までの会員※

1カ月（または2カ月）を超える延滞の会員

管理方法コールセンターから集中的に電話をかけ、督促する全国エリアを統括する管理部門がカウンセリングを行う ●管理センターでの集中管理

●弁護士／司法書士による任意整理

●民事再生／破産など法的債務整理案件

※ 初期延滞の範囲（延滞期間）は、各ノンバンクによって設定が異なる。

7/22/2019 IT Vol.13 00.pdf



と、加盟店を登録し、店舗に貼るステッ

カーやCAT端末、売上票の手配など

を行う。

なお、CAT端末とは、カード会社に対

して、利用者のカードが盗難カードではないか、購入金額が限度額を超えてい

ないかいった信用照会（オーソリゼーショ

ン）を行うための端末だ。現在は、オーソ

リゼーションから売り上げデータの取り込

み（ギャザリング）までの機能を備えた

POSレジもある※3。

最近では、ECサイトなどオンラインで

カード決済をする利用者も増えており、オ

ンライン・ショップ向けのクレジットカード

決済代行サービスを専門に提供する企

業も登場している。オンライン決済では、

個人情報の漏洩を防止するための暗

号化（SSLの利用）や、非対面取り引き

であるがゆえに起こりやすい「なりすまし」

への対策が必要となる。例えば、VISA

が開発した「3Dセキュア」では、カード

番号と有効期限のほかに、本人専用の

パスワードを入力させることにより、カード

発行会社が利用者を確認／認証する

ことができる。このように、加盟店側での

不正使用対策も重要な経営課題となっ

ている。

加盟店管理業務では、加盟店からの伝票回収、代金支払い、受取手数

料の管理といった処理を行う。加盟店

向けのサービス品質を高めるうえでは、

一連の業務が効率的に遂行できるのは

当たり前であり、充実した加盟店向けサ

ポートや、販売促進支援などの仕組み

を提供していくことが求められる。

加盟店向けのサポート・サービスの

例には、売上明細や振込金額の照会

サービスや、売上品など用度品の手配

をインターネット経由で提供するサービス

などがある。また、販促支援には、あらか

じめ許可を得た会員の中から、性別、

年代、地域、カードの利用状況に応じ

てターゲットを抽出し、加盟店用のダイレ

クト・メールを送付するというものがある。

売上高の高い加盟店を囲い込めるかど

うかは、加盟店が手数料を支払ってでも

カード決済を使いたくなるような仕組みを作り上げられるか否かにかかっている。

加盟店管理にかかわるシステムを設計す

る際には、こうした顧客（加盟店）側の

視点を忘れてはならない。

＊＊＊

以上、最終回となる今回は、金融業界の概要とノンバンクの業務知識につい

て解説した。

金融業では、製造、流通、物流と

いった他の業種に比べて、極めて高度

な安全性が要求される。そのため、従

来は閉じたアーキテクチャの下にシステ

ム開発が行われてきた。だが、本稿で解

説したように、今日では金融ビッグバンに

よって異なる業態との合併／提携が進

み、またインターネットなどマルチチャネル

への対応が急速に迫られている。ここで

鍵となるのが、複数システムとの柔軟か

つスムーズな連携だ。これまで金融機関

のシステムに求められてきた「堅牢性」と、

新たに生まれた「柔軟性」というニーズ

――これら2つのニーズに応えるために、

SOA（Service Oriented Architectu

re）なども活用して情報システムのグラン

ド・デザインをどう見直していくかが、今後の金融業界でシステム構築を担うIT

アーキテクトにとって重要な課題となる。

※ 3 スーパーなどで買い物をした際、カードを通しただ

けで、売上明細とクレジットの売上票がセットになったレ

シートを受け取ることがあるだろう。

図6：ノンバンクのCRMシステム

CTI

Web管理

電子メール管理

モバイル

マルチチャネル統合

CRMシステム

基幹システム

実行系CRM

プロモーション／キャンペーン管理

営業管理（SFA)

基幹システム連携

入会審査

会員管理

与信

加盟店管理

回収／債権管理

売上管理

会計／経理

リポーティング

データ・マイニング

ナレッジ・マネジメント

セキュリティ管理

コンタクト・センター・システム

業務推進部門

電話

携帯電話

Web

電子メール

ダイレクト・メール

店舗／ATM

営業担当

顧客（会員）／加盟店

データ・ウェアハウス分析系CRM

基幹系統合データベース

顧客情報統合

データベース

ナレッジ・ベース

7/22/2019 IT Vol.13 00.pdf



ビジネスの

要求を的確に反映した業務アプリ

ケーションを作るために

今回は、アーキテクチャの具体的な設計方法について説明する。アーキ

テクチャは、分析の過程で発見されるべきものだが、分析の初期段階で

は、仮説に基づいて設計される。分析設計が進むにつれて、アーキテク

チャの全貌が見えてくるのだ。また今回は、アーキテクチャの評価法と改

善法についても解説する。

鈴木高弘 Takahiro Suzuki

ビズモ代表取締役／チーフ・アーキテクト

CRCカードを用いたアーキテクチャの分析手法

今日、アプリケーション設計情報の表記にUMLが広

く使われるようになった。統一的な表記法としてUMLが

普及したのは喜ばしいことだが、筆者は1つ残念に思っていることがある。それは、「クラス図を描いた後に、全

体の流れをシーケンス図で確認する」、あるいは「シーケ

ンス図を基にしてクラス図を描く」といった手順が一般的

だと思われていることだ。筆者の経験から言えば、これら

の手順はいずれも、あまり生産性が高くない。それに、そ

れらの作業を実施する設計者らの協調作業を助けるツ

ールも十分にそろっていない。

システムの設計モデルに関しては、プログラムの開発

に入る前に、ステークホルダー（利害関係者）との間で

承認をとっておく必要がある。ただし、モデルの扱いに

不慣れなマネジャー層が、すべてのモデルを詳細にレビ

ューして承認するのは大変な作業だろう。

そこで今回は、より生産性が高く、複数の設計者が

ダイナミックに協調して設計作業が行える方法を紹介し

よう。これは、複数の設計者によるCRCカードを用いたレ

ビューを中心とするモデリング・セッション※1から成る設計

手法で、モデルの段階的な詳細化を効率良く実施でき

る点を特徴とする。段階的に詳細化することで、ステークホルダー間での調整が円滑に行えるのだ。

CRCカードを使う際のポイント

CRCカードはウォード・カニンガム氏によって考案され

たものであり、「CRC」とは「Class/Responsibility/

Collaborator（クラス／責務／コラボレーター）」の頭

文字を表す。通常は設計の初期段階において、どのよ

うなクラスが必要であり、それらがどのように相互連携す

るのかを決める際に使う。具体的には、CRCカードに以

下を列挙する（図1）。

●クラス名とパッケージ名（必要な場合）

●そのクラスの責務（すべきこと）

●そのクラスが自身の責務を果たすうえで連携（コラボレ

ーション）しなければならない他のクラスの名前

CRCカードは今日、ソフトウェア開発で広く利用されて

いる非常に優れたツールだ。これを用いれば、業務に

精通した者とアーキテクトとが効率的にコミュニケーション

アーキテクチャの発見第 2 回

クラス名：店舗

クラス名：修理依頼

図 1：CRCカードの例

クラス名：修理業者

責務コラボレーション

名前を持つ住所を持つ連絡を待つ備品の調達を行う修理結果を報告する

店舗修理依頼

※1 モデリング・セッションとは、複数の設計者により、モデルを洗練させて

いく作業のことを指す。

7/22/2019 IT Vol.13 00.pdf



れには、主要な業務プロセスを分析し、業務のシナリオ

（ユースケース）を作らなければならない。

そのうえで、そのシナリオを分析するわけだが、最初に

分析するシナリオは、最も単純なものが望ましい。その理

由は、この時点での分析の目的が、主要なオブジェクト

と主要な責務との間の関係を明確にすることにあるからだ（例えば、販売に関するシナリオなら、「顧客が来店し、

在庫のある商品を注文する」といった極めて単純なユー

スケースに対するシナリオ）。単純なシナリオであれば、オ

ブジェクトの洗い出しにも苦労しないはずだ。

単純なシナリオ／最小要素のモデル

シナリオ分析の際には、その問題領域における最小

の要素をモデル化することが重要である。この段階では、

まずモデル化の方針を決める。ここで言うモデル化の方

針とは、「何をオブジェクトとして認識するか」ということだ。

これは、業務によって異なるし、業務が同じでも、会社

が違ったり、事業部が違ったりすれば、やはり異なること

がある。そして、実際に日々行われている業務の中心と

なる概念が、初期のオブジェクトになる（例えば、顧客、

担当者、商品、注文など）。オブジェクトの数は、最小

にするよう心掛けるべきだ。オブジェクトの数が多くなると、

責務の割り当てが曖昧になるおそれがある。

なお、ここで決めた方針は、まだ最終決定ではなく、

あくまでも詳細化のための指針だ。モデルを詳細化していくにつれて、方針の修正が必要になる場合もある。

最小の要素から成るモデルを作ることで、問題領域

を構成する要素の責務を明確に定義できる。ここで割り

当てた責務が、モデル化の方針となる。また、責務ととも

に、モデル内の要素間の関係も明確にする。

することができる。ここではCRCカードを用いたセッション

（CRCカード・セッション）の詳細に関する説明は省くが、

これを実施する際にアーキテクトが考慮すべきポイントをま

とめておこう。

前回の解説の中で、アーキテクトの役割は「業務要件

とシステム・アーキテクチャの適切な関係を明確に定義すること」だと述べた。それを行うにあたり、アーキテクトが業

務精通者と協力して業務要件を整理し、システム・アー

キテクチャの雛型を作る際にCRCカードが役に立つ。

CRCカードを導入する際には、まず業務精通者に対

し、このカードを使って責務を分析／整理することを伝え

たうえで、一緒に作業してもらおう。初めて使う者も、業務

の経験さえあれば、業務や責務の分類にはさほど手間

取らないはずだ。この作業を複数の業務精通者とともに

行うと、かなり白熱した議論が起きることがあるが、その議

論の内容が、アーキテクトにとってはかなり参考になる。

なお、CRCカードを使ったモデリング・セッションの初

期のゴールは、業務要件を主要なオブジェクトに対して

責務として割り当てることだ。その結果出来上がるハイレ

ベルなモデル※2 は、モデルの要素である個々の部分の

詳細化にあたり、全体的な指針として機能する。各部

分を詳細化していく際には、それに合わせてこのモデル

も拡張し、調整しなければならない。

モデリング・セッションの留意点とセッションの流れ

それでは、モデリング・セッションを実施する際の留意

点と、セッションの流れを説明していこう。

ハイレベルなモデルの作成準備

ハイレベルなモデルを作成するためには、まずそのモデ

ルが対象とする最も重要な業務を決める必要がある。そ

※2 ここで言うハイレベルなモデルとは、問題領域全体に対する鳥瞰図的

な視点を与えるモデルを指す。このハイレベルなモデルがアーキテクチャの中

心となり、このモデルのレベルで依存関係や拡張の方針が決定される。

7/22/2019 IT Vol.13 00.pdf



アーキテクチャの

発見

第

2

回

トークスルーによるモデリング・セッション

ハイレベルなモデルを作成するためのアーキテクトによ

る最初のモデリング・セッションは、「トークスルー」と呼ば

れる。トークスルーにおけるレビューの対象はユースケー

スである。業務分析の担当者が分析したユースケース

を検討し、初期のオブジェクト・モデルを作ることが、このセッションの目的である。

この時点のオブジェクト・モデルの役割は、今後のモ

デリングの指針を示すことだ。その指針はクラスとして表

現されるが、クラス図にするのはまだ早い。クラスは、クラ

スの候補としてCRCカードに記述しておく。ここで挙げら

れるクラスの候補は、モデリング・セッションを重ねる度に

洗練されていく。

モデリング・セッションの最も重要な点は、このセッショ

ンにおけるディスカッションを通して、アーキテクト・チーム

の中で問題領域に対してさまざまなレベルの共通認識

が生まれることである。アーキテクチャにおいて重要となる

レイヤリングやコンポーネントの粒度などは、モデリング・セ

ッションで共通認識が得られなければ決めるのが難しく

なる。この種の設計作業には、意見や情報の交換、成

果物のすり合わせが不可欠であり、初期の段階で十

分な情報交換／意識合わせを行うことにより、後続の

作業の効率を高められるのだ。

モデリング・セッションにおいて、最小構成で検討が始

まったモデルは、さまざまな視点（ユースケース）から検討されることで、やがて問題領域全体を表すモデルに成長す

る。このモデルは、問題領域の鳥瞰図として利用できる。

ウォークスルーによるモデリング・セッション

続いては、「ウォークスルー」と呼ばれるモデリング・セ

ッションを実施する。このセッションがアーキテクチャ設計

作業のメインであり、ここでモデルが詳細に分析される。

トークスルーによってある程度安定したモデルが作られ、

アーキテクト・チーム内でモデル要素の分類や粒度につ

いてのコンセンサスがとれているはずなので、ウォークスル

ーでの設計作業は個人ベースの作業となる。

先のトークスルーでは、多くの視点（複数のアーキテク

ト）によるチェックを通して、死角（漏れ）がないようにモデ

リングしてきた。一方、ウォークスルーでは、このモデルを精査して、論理的な整合性を確保することに注力する。

論理的な整合性は、見いだした責務をコンポーネント

に展開していくことによって確保できる。CRCカードにコラ

ボレーションとして記述されたクラスが、実際に期待され

る責務を持っていることを確認するのだ。もし期待する責

務を持っていない場合は漏れがあるということなので、そ

れを追加しなければならない。また、CRCカードに書かれ

た責務が実際に呼び出されることも確認しよう。呼び出

されないようなら、それは不要な責務となる。展開の粒

度や責務の割り当てルールが設計者によって異なると、

たとえ整合性が確保されていても、機能の重複が細部

に残る可能性があるので注意していただきたい。

ウォークスルーの作業は、いくつかに分けて実施し、

設計者間で段階的に意識合わせをしながら差異がな

いようにしていく。その際に代替シナリオまで分析すること

で、ホットスポットやコールドスポットもわかるだろう※3。

ランスルーによるモデリング・セッション

次に、「ランスルー」と呼ばれるモデリング・セッションを行う。これは、ウォークスルーによるクラスの設計作業が

完了した段階でアーキテクト全員によって行う、アーキテ

クチャ検証のためのセッションだ。

このランスルーの段階では、これまでの作業を通して

※3 ここで言うホットスポットとは、業務が追加／変更される可能性のある部

分で、アーキテクチャ上はこれが拡張性を織り込むポイントとなる。例えば、商

品やサービスの内容によって処理が異なる部分は、ホットスポットになる可能

性が高い。それに対して、コールドスポットとは、変更の可能性がない部分を

指す。

7/22/2019 IT Vol.13 00.pdf



詳細化／洗練してきたモデルが書かれたCRCカードを

参加者に配布する。そのカードに書かれたメッセージの

やり取りを、ユースケース・シナリオに従って参加者間で

シミュレートするのだ。その際、メッセージの受け手がいな

かったり、受け手がいてもメッセージが責務として記載さ

れていなかったりした場合、検証作業は失敗となる。ランスルーは、ウォークスルーの分担作業によって詳

細化された責務を設計者全員が理解するのに役立つ。

また、すべてのシナリオがエラーなく実行されたときには、

高い満足感が得られ、チーム全体の志気が向上すると

いう効果もある。

モデリング・セッションの企画／運営でアーキテクトが心掛けるべきこと

ここまで、CRCカードを用いたアーキテクチャの設計手

法について解説してきた。続いては、それに対する補足

として、モデリング・セッションを企画／運営するチーフ・

アーキテクトが心掛けるべきことをいくつか述べてみたい。

問題領域のモデル化戦略――T字型テクニック

問題領域をモデル化する際には、分析漏れがないよ

う、問題領域全体を把握する必要がある。また、問題

領域を表現するときには、特に「広さ」と「深さ」を考慮

する。「広さ」とは業務の広がり、すなわち範囲のことを指し、「深さ」とは、個別の業務を詳細化していったとき

にどれぐらいの階層があり、その階層ごとにどれだけの業

務が含まれているかを指す。

●広さを優先させたモデルの長所と短所

問題領域をモデル化する際に広さを優先させた場

合は、その領域全体を通じて現れる主要なビジネス・オ

ブジェクトをすべて洗い出した汎用的なモデルを作ること

ができる。ただし、このモデルは浅すぎるため、設計者が

詳細設計で利用するシステム・アーキテクチャとして使う

ことはできない（図2）。

●深さを優先させたモデルの長所と短所

一方、広さではなく、深さを優先させた場合には、十

分に詳細なモデルが作られ、それをアーキテクチャとして

使うことができる。ただし、これは単にアーキテクチャの局所解を見つけたに過ぎず、そのアーキテクチャを他の個

所でも使えるという保証があるわけではない（図3）。

●T字型によるハイブリッドなアプローチ

このように、上記いずれのアプローチをとった場合でも

ジレンマが残る。この問題を解決する最良のアプローチ

は、両者を組み合わせた「T字型テクニック」と呼ばれ

るハイブリッド戦略だ（次ページの図4）。

T字型テクニックでは、モデリングのセッションを複数

に分割し、最初のセッションでは問題領域全体を広く、

浅くモデル化する。広く、浅くモデル化する理由は、いく

つかの重要な見通しを得るためだ。その1つは、短期間

に全体像を把握することである。全体像を共有し、その

図2：広さを優先させたモデル

コンセプト

詳細

広さ

ビジネス領域

●長所：問題領域全体がカバーされる●短所：浅すぎて詳細設計では使えない

図3：深さを優先させたモデル

コンセプト

詳細ビジネス領域

●長所：実際のシステム設計に適用できる詳細性を持つ●短所：他の領域にまで通用可能な汎用性は持たない

深さ

7/22/2019 IT Vol.13 00.pdf




発見

第

2

回

中でどの部分が重要なのか、難易度が高いのかといっ

たことを議論しながら、想定されるリスクをプロジェクト・チ

ーム内で共有する。そして、もう1つは問題領域全体を

構成する主要な概念をクラスとして特定し、責務を割り

当てることである。ここで注意が必要なのは、たとえ主要

な概念（クラス）であっても、その呼び方は複数存在する場合があるということだ。

また、これに続くセッションでは、モデルの特定部分を

詳細化していくが、最初のセッションでは、後続のセッシ

ョンで詳細化の対象とする部分も決めておく。もちろん、

詳細化が必要な部分は1つだけとは限らない。

業務分析／業務プロセスの分析担当者との協調

本稿では、業務分析の担当者や業務プロセス分析

の担当者と協調しながら、アーキテクトがアーキテクチャ

設計を行うことを想定している。今日、業務分析や業務プ

ロセス分析の手法にはさまざまなものがあるが、ここでは紙

数の都合上、業務分析／業務プロセス分析からユース

ケース分析に至る手順についての説明は割愛する。その

代わりに、業務分析や業務プロセス分析の担当者が作

成した成果物をアーキテクトが分析する手法を解説する。

●サービスの洗い出しとパターン化一般に、業務アプリケーションは複数のサービスで構

成される。それらのサービスを洗い出す段階では、サー

ビスの実現方法まで決める必要はない。サービスは、

単純なWebアプリケーションとして、あるいはSOA（Ser

vice Oriented Architecture）も使った本格的なWe

bサービスとして実装されるかもしれない。そのどれが、ユ

ーザーにとって最適な選択かを決めるのに必要な情報

が出そろう前に、実装方法に関する議論をしても意味は

ない。このフェーズでは、ユースケースの洗い出しと、洗

い出したユースケースの分析に集中すべきである。

ユースケースを分析してサービスを洗い出したら、それ

らのサービスを分類する。そして、それぞれの分類ごとに

アーキテクチャを設計する。すべてのサービスについてア

ーキテクチャを設計するのではなく、サービスを分類し、

その分類ごとに処理パターンを決めることで、アーキテク

チャ設計やシステム開発の作業が効率化できるわけだ。

なお、実際にやってみるとわかるが、ユースケースを漏

れなく洗い出すのは、かなり難しい作業である。この作

業を円滑に行うには、「状態遷移分析」と「状態遷移マトリクス分析」を使うのが有効だ。それぞれの詳細は、

次のようになる。

●状態遷移分析：各業務には、管理対象となるものが

存在する。あるビジネス・イベントが発生すると、この管

理対象の状態が遷移する。その状態遷移を、状態

遷移図（図5）を使って分析するのが状態遷移分析

だ。これは、業務要件の整合性を検証するのに非常

に有効である。状態遷移分析では、基本シナリオに

図4：T字型テクニック

コンセプト

詳細

広さ

ビジネス領域

①詳細設計に最も適した部分を明らかにするのに利用②深いレベルでの発見はより広域のモデルにフィードバック

●ハイレベル・モデルは個々の部分のモデル化の全体的指針として機能●個々の部分の詳細度が上がるのに合わせて絶えず発展と調整

①

②

深さ

フィード

バック

フィード

バック

7/22/2019 IT Vol.13 00.pdf



基づき、管理対象がとりうる状態をある程度まで洗い

出せる。洗い出した状態ごとに、代替シナリオを検討

しながら例外処理のケースを分析していくと、かなり精

度の高い業務要件の検証が行える

●状態遷移マトリクス分析：状態遷移図に出現する

状態とイベントのすべての組み合わせをマトリクス（次ページの図6）にして検証すると、さらに検証の精度

が高まる。これを状態遷移マトリクス分析と呼ぶ。この

検証作業は、機械的に行える点が特徴だ。「状態」

と「イベント」、「次の状態」についてすべての組み合

わせを検討することで、要件の検討漏れを発見できる

ユースケース分析では、サービスを最小単位まで洗

い出すようにしてほしい。サービスの最小単位とは、ユー

ザーとコンピュータとの間で行われる1つの応答の単位

だ。つまり、ユースケース・シナリオに記述される、ユーザ

ーとコンピュータとの間の1つの“対話”が、サービスの

最小単位となる。この単位をシステム全体で均一化し、

標準化することが、システムの作りやすさや使いやすさに

大きな影響を与える。

また、サービスを提供するための仕組み、つまり業務

アプリケーションの実装単位であるコンポーネントがどのよ

うに構成されるのか、その基準やルールが決まっている

と、システムの開発生産性や保守性を高められる。

アーキテクチャの評価

次に、アーキテクチャの評価について述べてみたい。

設計したアーキテクチャが、わかりやすいかどうか、開

発やテストがやりやすいかどうか、保守しやすいかどうか

を、客観的な指標によって判定できるとよい。この指標

は、次回に解説する「アーキテクチャ管理」や「レビュ

ー」、「検査」での基準ともなるものだ。この基準は、

CRCカードを用いたモデリング・セッションの中で議論し

ながら設定していく。モデリング・セッションの中で議論す

れば、具体的な例を基にして詳細に値を決められるし、

コンセンサスもとりやすいだろう。

ソフトウェア・メトリクスの設定

ソフトウェア・メトリクス（ソフトウェアの品質測定）については、すでに一般的な基準値が示されているが、ア

ーキテクト・チームでは、その値をプロジェクトごとに詳細

に検討し、各プロジェクトで採用する基準値を決めるとよ

い。一般的な指標が当てはまらない場合は、事前に検

討したうえで、メトリクスの対象から除外するクラスも出て

くるだろう。

カプセル化による情報隠蔽

オブジェクト指向の最大の恩恵は、「カプセル化」だ

と言っても過言ではない。このカプセル化によって情報

隠蔽を行う責務の割り当てルールは、「情報エキスパー

ト・パターン」と呼ばれる。情報エキスパートとは、責務を

遂行するために必要な情報を持つクラスのことであり、そ

のクラスに責務を割り当てることで情報隠蔽が行える。

図5：状態遷移図

修理依頼プロセス

202修理依頼変更

111修理依頼書入力

612修理依頼取消

211訪問日時決定入力

311仕入見積書入力

201修理依頼訂正

301訪問日時変更

611修理報告入力

302修理依頼訂正

1初期状態 2修理依頼書入力済み状態

3訪問日時決定済み状態

管理対象：修理依頼案件

2回目対応以降

2回目対応以降

修理手配プロセス

……

7/22/2019 IT Vol.13 00.pdf




発見

第

2

回

簡単な例を挙げると、ビデオ・レンタルの場合なら、

「映画」が料金を計算する責務を持っていれば、「映

画」の種別や種別ごとの料金体系に関する情報を他の

オブジェクトに公開せずに済む。それにより、種別や種別

ごとの料金体系に関する情報を隠蔽したまま、「料金計

算」という責務を実行できるようになるわけだ。

アーキテクチャを評価する際には、オブジェクトごとに

割り当てられた責務が、この情報隠蔽のルールにのっと

っているかどうかを確認する。また、オブジェクトに割り当

てられた責務は、そのオブジェクトの属性か引数を使っ

1初期状態 111修理依頼書入力 2 1

1初期状態 201修理依頼訂正 1

1初期状態 202修理依頼変更 1

1初期状態 211訪問日時決定入力 3 1

1初期状態 301訪問日時変更 1


1初期状態 311仕入見積書入力 4 1


1初期状態 402仕入見積変更 1

1初期状態 411売上見積書入力 1


2修理依頼書入力済み状態 502売上見積変更 1

2修理依頼書入力済み状態 511修理日程入力 1

2修理依頼書入力済み状態 601修理依頼訂正 1

2修理依頼書入力済み状態 611修理報告入力 1

2修理依頼書入力済み状態 612修理依頼取消 1 1

2修理依頼書入力済み状態 711消込依頼イベント 1

3訪問日時決定済み状態 111修理依頼書入力 1

3訪問日時決定済み状態 201修理依頼訂正

3訪問日時決定済み状態 202修理依頼変更 1

3訪問日時決定済み状態 211訪問日時決定入力 1

５売上見積書作成済み状態４０２仕入見積変更 1 1マトリクス積で追加

（意味のあることが判明）

５売上見積書作成済み状態４１１売上見積書入力 1

５売上見積書作成済み状態５０１修理依頼訂正 5 2 1 3 4

５売上見積書作成済み状態５０２売上見積変更 5 1

修理報告結果設定処理

売上見積変更処理

修理日程設定処理

売上見積作成処理

仕入見積訂正処理

仕入見積変更処理

管理対象抹消処理

修理依頼変更処理

仕入見積入力処理

訪問日時変更

訪問日時設定

管理対象／（修理依頼案件）生成

Un u s u al

何もしない

エラー

次状態

イベント

現状態

状態遷移内部発生イベント処理

管理対象削除、ログ保管

処理コメント

図6：状態遷移マトリクス

状態遷移コメント

7/22/2019 IT Vol.13 00.pdf



て処理できなければならない。他のオブジェクトを参照し

て情報を取り出し、取り出した情報に基づいて処理を行

う必要がある場合には、改善が必要である。

リファクタリング的な

アーキテクチャの評価と改善

続いては、アーキテクチャの評価を行うための具体

的な手法を紹介しよう。ここでは、トップダウンで機能展

開を行ってコンポーネントを抽出し、リファクタリング的な

アプローチでアーキテクチャを改善しながら、ドメインに

適合したアーキテクチャを発見する方法を説明する。こ

の作業でアーキテクトが最も注力すべきなのは、拡張性

と保守性の高いアーキテクチャを見つけることだ。そのた

めの手順は、次のようになる。

①初期モデルの作成

②トップダウンによる機能展開と責務の割り当て

③ホットスポットの発見

④コールドスポットの確定

⑤変更に強いインタフェースの設計

以降では、上記の手順に沿った作業の主なポイント

を解説する。分析の対象とするのは、書籍『リファクタリ

ング』の第 1章で登場する最初の例だ。その例とは、ビ

デオ・ショップの領収書印刷プログラムである。このプログラムに対する要求仕様と機能仕様は、図7のようにな

る。

初期モデルの描き方

では、図7を参考にして、まず初期モデルを描いてみよ

う（図8）。この図を描くうえでのポイントは、次のとおりだ。

まず、中心的な役割を演じるオブジェクト（クラス）を図

の中心に置く。この例では「領収書」が中心的な役割

を果たすので、これを中心に置いた。

次に、そのオブジェクトを管理するオブジェクトを上に置

く。また、問題を分析しながら、その周りに順番にオブジ

ェクトを配置していく。属性についてもわかっている限り書

き込み、関連も「Has-a」のものについては書き入れる。

ひととおり書き込んだら、機能仕様の情報が漏れなく

記載されているかどうかを確認しよう。その際、具体的な

例（インスタンス）でモデルを描いてみると、よりわかりやす

い。つまり、オブジェクト図を描くのだ。

初期モデルへの機能の割り当て次に、初期のオブジェクト・モデルに対して機能（責

務）を割り当てる（次ページの図9）。「入力」、「計算」、

「出力」といった機能仕様をトップダウンで機能展開し、

展開した機能を責務として割り当てるとよい。

まず「入力」だが、これは「借りる」というイベントに対

応する入力情報である。「借りる」というイベントは、初期

のモデルではクラス「レンタル」として抽出したので、この

クラスの責務として割り当てる。

図7：ビデオ・ショップの領収書印刷プログラムの要求仕様と機能仕様

【要求仕様】

●ビデオのレンタル料金を計算して印刷するプログラム

●どの映画を何日借りるかを入力する

○複数入力可

●貸出期間と映画の分類によって料金を計算する

●映画の分類

○一般、子供、新作

●ポイント制度あり

○映画の種類によってポイントが異なる

【機能仕様】

●入力仕様

○映画のタイトル・コード（バーコード入力）

—タイトル表示

○貸出期間（日数）

●出力仕様

○ヘッダ

—店名、電話番号、年月日、扱い者、領収書番号

○明細

—タイトル、日数、料金

○フッタ

—合計金額、合計ポイント

図8：初期段階のクラス図

タイトル・コードタイトル名プライス・コード

映画

日数

レンタル

番号

領収書管理

名前

扱い者店名電話番号年月日扱い者領収書番号

ヘッダ

日数料金

明細

合計金額合計ポイント

フッタ

名前電話番号

店

領収書

7/22/2019 IT Vol.13 00.pdf




発見

第

2

回

次に「計算」だが、これに関する責務の割り当てには

かなりの検討が必要だ。ここでは、計算結果が出現す

る個所に「計算」の責務を割り当てる。この割り当ては、

計算ロジックの呼び出し個所を明らかにするうえでも役に

立つ。図9では、「計算」を「料金計算」と「ポイント計

算」の責務に分け、クラス「明細」に割り当てた。なお「料金計算」については、後ほど分析の対象とする。

「出力」については、領収書の出力を「ヘッダ」、

「明細」、「フッタ」に分けてクラスを抽出しているので、

それぞれのクラスに責務として割り当てた。

以上のようにして初期のモデルを完成させたら、以降

では、このモデルをさまざまな視点から評価し、改善して

いくことで、アーキテクチャを完成させていく。

変更可能性への対応

それでは、作成したモデルを分析してみよう。ここで

は、クラス「明細」の「料金計算」を対象とし、作成した

モデルの“変更への対応力”を評価し、改善する。

「料金計算」の処理を詳しく分析すると、この処理は

「映画のプライス・コードの取得」と「プライス・コードごと

の料金計算」に分けられることがわかる。また、この処理

に必要なデータの所属を見ると、プライス・コードはクラス

「映画」に、日数はクラス「レンタル」に所属する。というこ

とは、この処理は、クラス「映画」と「レンタル」のいずれ

かに割り当てたほうがよいということになる。

ここで関連に注目すると、クラス「レンタル」は、関連と

して「映画」を持ち、クラス「レンタル」から「映画」のメソッドを呼び出せるので、この責務は「映画」に割り当てた

ほうがよさそうだ。この場合、クラス「明細」の「日数」は、

引数としてクラス「映画」に渡すことができる。

ところで、クラス「映画」の「プライス・コード」は、追加

されたり変更されたりする可能性が高い属性だが、その

変更の度に既存のプログラムを修正したくはない。これ

は、一般に「OCP（Open Closed Principle）」と呼ば

れる原則であり、「拡張に対しては開いており（Open）、

修正に対しては閉じて（Closed）いなければならない」と

いうものだ。もし、プライス・コードごとの計算をif 文や

case文で実装してしまうと、この処理に変更がある度に

修正することになる。

そこで、継承を使い、Strategyパターンでクラス「映

画」をリファクタリングする。具体的には、クラス「明細」

から「映画」に「料金計算」の処理を移動し、「映画」

図9：機能を割り当てた後のクラス図


映画

日数

タイトル入力貸出期間入力

レンタル

番号

領収書管理

名前

扱い者店名

電話番号年月日扱い者領収書番号

ヘッダ

日数料金

料金計算ポイント計算出力

明細

合計金額合計ポイント

フッタ

名前電話番号

店

領収書

出力

出力

出力

7/22/2019 IT Vol.13 00.pdf



のサブクラスを作るかたちで変更に対応するように設計

する（図10）。

改善されたクラス図を見てみると、変更が局所化され

ていることがわかるだろう。改善前は、新しいプライス・コ

ードが追加されるとクラス「明細」、「映画」を両方修正

する必要があったが、改善後は「映画」のサブクラスを追加するだけでよく、既存のコードを修正する必要はな

い。これでOCPが実現できたことになる。

クラス分割による変更の局所化

今度は、クラス分割による変更の局所化の例をご覧

いただこう。クラス「映画」については、今後いろいろと

変更が生じそうなので、同クラスの属性の変更可能性

を検討してみる。

まず、「タイトル・コード」と「タイトル名」が変更される

可能性はないだろう。一方、「料金計算」は変更され

る可能性がある。「新作」の映画は、いつまでも新作で

あるわけはないから、「新作」から「一般」か「子供」に

状態が遷移し、それに応じて「料金計算」のロジックも

変わるはずだ。そこで、Stateパターンを用いて、クラス

「料金計算」の抽出を行う（図11）。なお、継承は強力

な機能だが、思わぬ副作用を生むので濫用は禁物だ。

図11では、その点にも配慮して改善を行っている。

図11のクラス図から、変更に対してより堅牢なアーキ

テクチャになっていることがわかるだろう。このモデルでは、

クラス「映画」のサブクラスで同クラスの機能を変更する

ことが可能だ。機能拡張する部分だけをクラスとして抽出することにより、機能拡張しない部分との切り分けを明

確にしており、誤った拡張も防ぐことができる。

＊＊＊

以上、今回はアーキテクチャの設計手法と評価／

改善法について解説した。ここで紹介したアプローチは

実績のある有効な手法だが、そのまま読者の状況に適

用できるとは限らない。この手法も参考にしながら、アー

キテクチャを業務要件に対して最適なものにするプロセス

を確立していっていただきたい。

次回は、実装工程以降でのアーキテクチャの管理

方法について解説する。メトリクスやディペンデンシー・ス

トラクチャ・マトリクスを用いて、開発されるコードがアーキ

テクチャに従っているかどうかを確認し、問題点を改善

する方法を紹介したい。

図10：クラス「映画」の改善

●変更前 ●変更後


映画

タイトル・コードタイトル名

料金計算（日数）

映画

日数入力

レンタル

日数料金

料金計算ポイント計算出力

明細

一般


子供


新作


図11：クラス「料金計算」の抽出●変更前 ●変更後


料金計算



映画

一般料金


子供料金


新作料金




映画

一般


子供


新作


7/22/2019 IT Vol.13 00.pdf


08

新刊書籍情報

Books

RUPを

導入するための

実践的

なプラクティス集

『アジャイル開発の6原則と20のベストプラクティス』

著者■パー・クロール、ブルース・マックアイザック

訳者■落合修、ほか

発行■エスアイビー・アクセス

発売■星雲社

価格■4,200円

開発プロセス「RUP（Rational Unied Pr

ocess）」とそのオープンソース版である「Ope

nUP」をプロジェクトに適用するための方法を

解説。最初に6つの基本原則を示した後、そ

れを支える20のプラクティスを紹介している。

各プラクティスの説明では、反復型アプロー

チの実践法やレガシー・システムの活用方法、

デザイン・パターン、コンポーネント開発などに

も言及。システム開発に携わるすべての人に

読んでほしい1冊だ。

『実践ユーザビリティテスティング̶ 「利用品質」を忘れていませんか̶ 』

著者■キャロル・M・バーナム

訳者■黒須正明、牧野祐子

発行■翔泳社

価格■6,090円

ユーザーにとっての利便

性を高めるための「ユーザビ

リティ・テスト」について解説した1冊。ユーザビリティに

関する基本事項やユーザー

から効果的にフィードバック

を得る方法、ユーザビリティ・

テストの計画立案／実行／

分析などの手順について説

明している。

『IT赤字プロジェクトの立て直し・火消し対策』著者■香村求

発行■ソフト・リサーチ・センター

価格■2,415円

「赤字になったプロジェク

トは失敗である」と説く著者

が、そうしたプロジェクトをど

う管理すればよいのかを解

説。赤字プロジェクトが発生

する原因やそれを立て直す

ための方法、プロジェクトを

赤字にしないための具体的

な施策についても取り上げ

ている。

『ビジネスパターンによるモデル駆動設計』著者■パベル・フルービー、ほか

訳者■溝口真理子、依田光江

発行■日経BP社

価格■4,935円

ビジネス活動のパターンを

モデル化した「REA（R es o

urce /Event/Agen t）モデ

ル」によるモデリングやアプ

リケーションの設計方法に

関する解説書。代表的なビ

ジネスの流れを「契約パター

ン」や「責任パターン」など

25 種類に分類し、紹介して

いる。

『PSPガイドブックソフトウェアエンジニア自己改善』著者■ワッツ・S・ハンフリー

訳者■秋山義博、ほか

発行■翔泳社

価格■4,200円

開発者の能力開発プロ

セスを規定した「PS P（Per

sonal Software Proce

ss）」について詳しく説明し

た1冊。PSPのコンセプトと

その導入戦略に始まり、ソフ

トウェアの規模の測定、開

発工数の見積もり、作業計

画の立案、品質管理などに

ついて解説している。

ITアーキテクト Vol.13

『PMO構築事例・実践法プ̶ロジェクト・マネジメント・オフィス̶ 』著者■仲村薫

発行■ソフト・リサーチ・センター

価格■2,835円

「PMO（Project Manag

ement Off ice）」の機能／

役割や活動内容を解説して

いるほか、プロジェクト・マネ

ジャーの育成方法にも触れ

ている。多数掲載された事

例紹介では、さまざまな業種

の企業がどのようにPMOを

活用しているのかを知ること

ができる。

7/22/2019 IT Vol.13 00.pdf


090

佐

藤亘

Wataru Sato

新日鉄ソリューションズ

ITインフラソリューション事業本部

ITア

ーキテクティンググループサブグループリーダー

今日のオープン・システムでは、インフラ設計

が重視されるようになっている。可用性などシステ

ムの非機能要件を満たせるかどうかは、インフラ

が鍵を握るからだ。大規模でクリティカルなシステ

ムを得意とする新日鉄ソリューションズにおいて、

そのインフラ設計を担う“インフラ・アーキテクト”を務めるのが、佐藤亘氏である。

大学院時代、生体情報解析を専攻してい

た佐藤氏は、1994年に新日本製鐵に入社した。

「製鉄所の巨大制御システムにあこがれてい

た」からだという。人の身体と製鉄所システムと

の間に、神秘的とも言える精緻さを持つ点で相

通じるものを感じたのかもしれない。

最初の配属先は、UNIXサーバの技術支援

部隊。ITの基本を勉強するつもりだった。そこ

で、人にとって扱いやすくするためにコンピュータ

処理自体を仮想化するOSの仕組みに魅了さ

れ、インフラの世界にのめり込んでいく。

1990年代半ばと言えば、オープン系が新境

地を開きつつあったころだ。佐藤氏は、1995年

からUNIXを使った高可用性システムの事業立

ち上げに従事し、それを金融機関のトレーディン

グ・システムなどに適用する際、インフラ設計／

構築を担当する。

「『可用性』という言葉すら使われていなかった」（佐藤氏）という当時、金融機関のITシステ

ムをオープンかつクラスタ構成で実現した例は

珍しく、所属部門は市場での評価を高める。そ

して、1990年代後半になると大規模システムにオ

ープン化の波が怒濤のごとく押し寄せ、佐藤氏

の活躍の場も広がった。さらに、2000年前後に

は、性能や可用性に問題のあった通信系キャ

リアのバック・システム全体を刷新するプロジェク

トにも携わる。

この間、アーキテクトとして泥臭い仕事も多くこ

なした。「問題が発生すれば、たとえ夜間だろう

が、設計者は駆けつけないといけない」（佐藤

氏）。インフラが今日ほど重視されていなかった当時、

特に業務系システムにおいて、非機能領域は

“要件どおりにできて当たり前”と見られる傾向が

強く、さほど脚光を浴びることもなかった。それで

も仕事に打ち込めたのは、「先例のないシステム

のインフラを支えている」という内なる思いがあっ

たからだ。現在は、インフラ・アーキテクトとして

大規模案件に参加したり、社内でインフラ設

計／構築の方法論の整備や後進育成に携わ

ったりしている。

佐藤氏にとって、インフラの世界の醍醐味は、

「制約条件が複雑に絡み合う中で、最適なバ

ランスを考えること」にある。インフラの場合、ネット

ワークからミドルウェアまで、各レイヤで“製品とい

う制約”があり、ベンダーの影響力も大きい。そ

の中で、アーキテクトは製品の最適な組み合わ

せを探る。性能と可用性のように、時として相反

する要件を調整し、満たさなければならず、「要

件が少しでも変われば、設計がガラリと変わるこ

ともある」（佐藤氏）。この“最適解探し”こそ、ア

ーキテクトの役目なのだ。

「アプリケーションの世界では、設計／構築

の方法論がほぼ確立されているが、インフラにつ

いてはまだまだ。これを業界を挙げて整備できた

ら」と今後の夢を語る佐藤氏。インフラをさらに極

めるべく、今日も最適解探しに取り組んでいる。

12 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.13

7/22/2019 IT Vol.13 00.pdf



さまざ

まな制約の中で

インフラ設計の

〝最適

解〟を探る

写真：東京フォト工

1967年宮城県生まれ

1994年新日本製鐵入社1995年 UNIXサーバによる高可用性システム

事業の立ち上げに従事

1999年通信系次世代システムの設計／構

築のほか、金融／通信／公共／製

造などの分野でミッション・クリティカル

なシステムを多数手掛ける

2003年新日鉄ソリューションズに移籍

2006年 ITアーキテクトとして、インフラに関す

る社内標準の策定や基盤フレームワ

ークのバージョンアップなどを担う

2007年現在は、非機能要求を中心とする大

規模案件の提案／設計支援をはじ

め、インフラの設計／構築方法論の

社内普及、システム品質管理、ITアー

キテクト育成などを行っている

資格◎第二種情報処理技術者

専攻◎情報工学

趣味◎真空管オーディオ製作

7/22/2019 IT Vol.13 00.pdf


猫と人の

〝関係〟を

考える


迷惑とは知りながら……

筆者は5年ほど前、週に2、3回は会社

に泊まるのが当たり前という生活をしてい

た。「終電で帰って3 時間睡眠で出社す

るより、自宅までの往復 2.5時間分多く

寝たい※ 4

」と考え、なかなか足が自宅に

向かいづらくなっていた。

だが、それでも家に帰ろうとする動機に

なっていたのが、帰り道の途中にある駐

車場辺りに住み着いている、野良猫の

存在だった。電車を降りるとすぐにコンビ

ニエンス・ストアで魚肉ソーセージなどの

餌を買い※5

、野良猫にあげるのが、忙殺

されそうな日々で唯一の楽しみだったの

だ。午前 1時ごろ、筆者がコンビニエン

ス・ストアの白いビニール袋を提げて歩い

ていると、どこからともなく野良猫が現れ

てついてくる※6。餌を道端に置いて、10

mくらい離れたところから見ていると、恐

る恐る近寄って、さっと口にくわえて物陰

に隠れる※7

。たったそれだけのことだが、

ストレスフルな日常の息抜きとして、筆者

には貴重な時間だった。

もちろん、野良猫に餌を与えるのは、

近隣の住民にとっては迷惑な話だ。野

良猫が住み着いた地域の住民は、クル

マを爪で傷つけられたり※8

、糞尿の悪臭

被害に遭ったりする。筆者は後ろめたさ

を感じながらも、人目を避けて猫に餌を与

えていた※9

。

最近は、公園や駐車場などで「野良猫

に餌をあげないで」といった貼り紙を見か

ける頻度が増えた。かつての筆者のよう

な不心得者が増えたのか、あるいは野良

猫の被害に業を煮やす人が増えている

のかもしれない。

地域猫活動

飼い猫でも野良猫でもない、地域の

住民が餌を与えて世話をし、共同で猫を

飼う「地域猫」という考え方が世間に紹

介されてから、すでに7、8年ほどたっただ

ろう※1 0

。横浜市磯子区の『磯子区猫の

飼育ガイドライン』によると、地域猫活動

は以下のように説明されている。

地域の住民、ボランティア、獣医

師、行政が協働で「飼い主のいな

い猫」を、避妊去勢手術の実施や

置きエサの禁止など飼育ガイドライ

ンに沿って管理することで、責任の

所在の明らかな猫（地域猫）へと変

身させ、その結果「飼い主のいない猫」を減らす活動です。

冒頭で述べたように、筆者の自宅付

近でも地域猫活動が始まり、それをきっ

かけとして筆者も地域猫活動について学

んだ。それまでは、地域猫活動というもの

を誤解し※11

、完全に否定的な見解を持

っていたのだが（理由は後述する）、学ん

だことによって部分的には評価するよう

になった。

※1 人が近寄ると逃げるが、以前よりは近づ

けるようになったし、“逃げ足”ものんびりしてい

るように感じる。

※2 数人のグループで活動しており、NPO法

人化に向けて準備中だという。

※3 避妊／去勢手術を済ませた猫は、目印と

して耳にピアスを付けているという。改めて見て

みると、近所に緑やピンクのカラフルなピアス

を付けた猫がかなりいることに気づいた。

※4 第2 回（Vol.3掲載）でも書いたが、筆者

はイスが3つあれば熟睡できる“技術”を身に付

けている。

※5 猫の餌として売っているものではなく、本

来は人間が食べるためのものだ。ビールを片手

に半分を自分で食べ、残りを猫にあげていた。

※6 毎回必ず現れるのが2匹、時々現れるの

が2、3匹いた。筆者は勝手に「ボス」とか「トラ

シ」といった名前を付けて呼んでいた。

※7 「餌付け」にトライしたが、そこは用心深

い野良猫だ。決して、筆者の手から食べ物を

食べようとはしなかった。だが筆者は、尻尾を振

って餌をねだる犬に対して、人間にこびを売ら

ない気高さが猫の良いところだと思っているた

め、足元にじゃれつくような“人間慣れ”した猫は

好きではない。

※8 冬、猫がクルマのボンネットの上で日向

ぼっこをしている光景をよく見かける。夏になれ

ば、クルマの下で日差しを避けている。猫はい

ちばん暖かい場所／いちばん涼しい場所を知

っているとよく言われるが、クルマは猫にとって

快適な住環境の1つになっているようだ。しか

し、クルマのオーナーにしてみれば、ボンネット

によじ登る際に爪を立てられたり、タイヤで爪と

ぎをされたりするのはたまったものではない。

※9 自宅に連れて帰って飼えばよかったのだ

が、彼（彼女）は、捕まえられるほど気を許しては

くれなかった。もっとも、週の半分しか家に帰っ

てこない人に飼い主になられても困っただろう

が。

最近、筆者の自宅周辺にいる野良猫が急におとなしくなった。

「さかり」の騒々しい鳴き声を聞くことが減ったし、

動作も心なしかおっとりしている※1。

不思議に思っていたら、ある日、郵便受けに地域猫活動の開始を

知らせるチラシが入っていた※2。

野良猫たちは、この活動の一環として

避妊／去勢手術をされたためにおとなしくなったのだ※3。

今回は、この地域猫活動を中心に、

「猫と人との関係性」を見ていこう。

笠原規男 Norio kasahara

豆蔵主幹コンサルタント

イラスト：花くまゆうさく

Vol.11

7/22/2019 IT Vol.13 00.pdf



地域猫活動では、猫好きの人と非猫

好き※ 12

の人が、猫を間に向き合う構図

になる（図1）。活動の中心となるのは猫

好きの人間だが、猫好きが文字どおり

“猫かわいがり”した結果、猫の数が増え

すぎたり、糞尿や爪とぎの被害が多くな

ったりすれば、非猫好きから反感を買い、

地域活動として成立しなくなってしまう。そ

うではなく、地域猫活動は、猫好きと非

猫好きがうまく妥協※13

して同じ地域に暮

らすための活動なのだ。

筆者のように気まぐれに餌をやるだけ

の行為と地域猫活動とは、明示的に区

別しなければならない。だれかに餌を与え

られていても、責任の所在が明確になっ

ていない猫は、地域猫ではなく野良猫

だ。

避妊／去勢手術をして地域猫がそれ

以上増えないようにし、置き餌を禁止する

（適宜、地域猫だけに餌を与える）ことに

より、野良猫が増えないようにする。こう

した活動内容を見るに、地域猫活動とは

「猫好きが非猫好きの顔色を伺いつつ、

猫の世話をする行為」だとも言える。

非猫好きの中でも特にヒステリックな

集団※14

は、野良猫は捕らえて殺してしま

えばよいとさえ考えるらしい。しかし、そう

した行為は動物愛護管理法に違反して

いる※ 15

。野良猫を減らす対策は、避

妊／去勢しかないのだ。自分ですべての

野良猫の手術代金を出すのは大きな負

担であり、非現実的なことを思えば、野

良猫の被害を受けている人にとっても地

域猫活動はありがたいものであるはず

だ。

猫の「幸せ」

地域猫活動を評価するためには、その

活動によって、地域猫たちが「幸せ」なの

かどうかを考えなければならない。見た目

から勝手に「目を細めてノドを鳴らしている

から幸せなんだろう」などと考えるのは無

意味だ。

本人（猫）に聞いてみることはできない

ので、何が本当に幸せなのかはわからな

いが、生物としての真理、正義のような

ものはあると筆者は考える。それは、生

物は「DNAの乗り物※16

」であるということ

だ。つまり、すべての生物は遺伝子の

“意思”に従って、自分たちの種の遺伝子

の濃度ができるだけ高くなるように行動す

る※17

ということである。

生物には、「総入れ替えタイプ」と「親

子並存タイプ」の2タイプがある（次ペー

ジの図2）。前者は、昆虫や1年草のよう

に寿命が短く（多くが1 年以下）、子孫

（卵や種）を残すと親は死んでしまう。それ

に対して、比較的寿命が長く、子孫を残

した後も親は生き続けるのが後者であ

る。親はある程度の間隔を空けて複数

回、子孫を残すことができる。

図2-①、②は、どちらのタイプも同時

に生きているのは3個体であるため、遺

※10 1997年に横浜市磯子区の猫好きな

住民たちが始めた運動が、地域猫活動の始ま

りだとされている。

※11 筆者がある客先に常駐していたとき、

昼食はコンビニ弁当を近くの公園で食べるの

が常だった。その公園では、過ごしやすい木陰

にあるベンチの脇が猫の餌場になっていた。

食べ残しの餌は見た目が汚いしにおうので、筆

者は「猫好きが酔狂でやっている地域猫活動

なんて迷惑なものだ」と思っていた。「置き餌の

禁止」というルールに違反しているので、これは

そもそも地域猫活動とは言えないものだったの

だが、当時の筆者を含め、よく知らない人は十

把一絡げに「地域猫活動」だと思うだろう。

※12 自分が飼っている猫以外には愛着を持

たない人も含む。

※13 日常生活において、「妥協」という言葉

は当事者全員が不満足であるかのようなネガテ

ィブな意味で使われることが多い。しかし、意

思決定論の合意形成モデルでは、自分の利益

と相手の利益の調和をうまくとった“落としどこ

ろ”を探る適切な行為とされている。自分の利

益ばかりを考える「無視」、相手の利益ばかりを

優先させる「譲歩」などに比べ、ずっと良い状態

である。ちなみに、相手も自分も期待どおりの

利益を得ることができる「Win-Winモデル」を導

き出す最高の状態は「協働」と呼ぶ。

※14 ヒステリックにならざるをえないほど、野

良猫被害が深刻なのだとも言えるが。

※15 自ら手を下すことはもちろん、野良猫は

保健所に持ち込んで処分するのも違法だ。保

健所が処分を引き受けるのは、正当な理由で

飼えなくなった自己所有の動物のみである。

※16 英国人であるリチャード・ドーキンス博

士の著作『利己的な遺伝子』（発行：紀伊國屋

書店）に登場する有名なフレーズ。

※17 平たく言えば、できるだけ個体数を多く

しようとすること。

勝手

に

ア

ー

キ

テ

クチ

ャ

分析

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：地域猫活動の構図

野良猫がかわいそう

飼ってあげたいが、1人で飼うには負担が大きすぎる

猫好き

野良猫が増えて困っている

駆除したいが、保健所や市役所は対応してくれない

非猫好き

地域猫活動

7/22/2019 IT Vol.13 00.pdf



伝子の濃度は同じである。①のタイプで

遺伝子の濃度を高くするには、一度に数

多くの子孫を残すしかない。一方、②のタ

イプであれば、成体（親）が子孫を残す回

数を増やすという戦略をとることもできる。

猫は当然、②のタイプになる。1回に

出産できる子供の数には限界があるの

で、利己的な遺伝子はできるだけ出産回

数を増やして遺伝子の濃度を高めようと

する。遺伝子の意思に従い、子を産める

状態で長生きすることが生物としての“正

義”なのであり、人間になぞらえるならば、

それを“幸せ”と呼んでもよいだろう。

避妊／去勢の是非

地域猫活動では、猫を避妊／去勢す

ることが大前提となる。避妊／去勢に

は、猫がそれ以上増えないようにするとと

もに、猫被害を軽減する効果がある。避

妊／去勢されると、雌は「さかり」のフェロ

モンを出さなくなる。また、雄は雌の取り

合いをすることがなくなるので、やかましく

鳴くことが少なくなり、においの強い尿で

マーキングすることもなくなる。こうしたこ

とからも、避妊／去勢が非常に効果的

な猫被害対策であることがわかるだろう。

しかし、前節で述べたように、猫にとっ

てみれば避妊／去勢されることは死に次

ぐひどい仕打ちかもしれない。種の保存

という観点で考えれば、猫にとっては、餌

をもらえる代わりにすべての猫が避妊／

去勢されてしまうよりも、たとえ何割かが

餓死してでも繁殖できるほうがずっとまし

なことになる。

ある地域で野良猫の被害が深刻になっ

た場合の対策として、やむにやまれず地

域猫活動で解決するのは仕方がない。し

かし、筆者は、猫好きが野良猫をふびん

に思って世話をしたくなる気持ちを満たす

ために、地域猫のシステムを“利用”してい

るケースが多いように感じている。前科者

の筆者が言うのも何だが、引き取って自

宅で飼うことができないのならば、手を出さ

ずにじっと見守るのが、猫好きがとれる猫

にとって最良の態度だと筆者は考える。

猫の縄張

野良猫を増やさないためには、飼い主

が責任を持って猫を飼い、飼い猫にあげ

た餌を野良猫が食べたり、飼い猫が野

良猫と交配したりしないように管理しなけ

ればならない。また、飼い猫が近隣でマ

ーキングすることによって、人に迷惑をか

けることは、猫に対する風当たりを強くす

る一因となる。

自分の飼い猫によるトラブルを避ける

ためには、猫を室内飼いにするのがいち

ばんだ。とは言え、猫を狭い部屋に閉じ

込めるのは、一見かわいそうに思える。し

かし、猫の生態的にはまったくそんなこと

はない。

猫科の動物は群れを作らない※1 8

。猫

は単独で縄張を持ち、基本的にその中

で暮らしている。縄張の中で、ねぐらとな

るごく狭いエリアを「ハイムテリトリー」と呼

ぶ。ハイムテリトリーは排他的領域で、決

してほかの猫の侵入を許さない。これに

対して、餌場を含む比較的広い（と言っ

※18 ライオンだけは例外である。

図2：生物のタイプ分け

時間1世代

①総入れ替えタイプ

②親子並存タイプ

図3：猫はハンティング・エリアを共有する

猫A

ハイムテリトリー

ハンティング・エリア

猫Ｂ

ハイムテリトリー

ハンティング・エリア

7/22/2019 IT Vol.13 00.pdf



ても、せいぜい半径500m程度の）縄張を

「ハンティング・エリア」と呼ぶ。ハンティ

ング・エリアは、ほかの猫の縄張と重なっ

ている場合もある。

ハンティング・エリアでは自分が生きて

いくために必要な餌を確保できればよく、

広さは問題ではない。室内飼いされてい

る猫の場合、その部屋がハンティング・エ

リアとなる。飼い主が潤沢に餌を与えてく

れるのだから、猫にとって「狭くてかわいそ

う」などということはまったくない※19

。

猫は、1日数回、縄張をパトロールす

る。ほかの動物が縄張に侵入していない

かどうかをチェックし、マーキングによって

領有権を主張するためだ※2 0

。室内飼い

されている猫は、パトロールが楽なのでむ

しろ喜んでいるかもしれない。

猫の集会

公園などに数匹の猫が集まり、目線を

合わせるわけでもなく、すれ違いざまに相

手のにおいをかいだりしているのを見かけ

る。付かず離れずの微妙な距離を保ちつ

つ、威嚇したりけんかしたりすることはな

いが、子猫同士のようにじゃれ合ったりす

るわけでもない。この奇妙な様子が、い

わゆる「猫の集会」である。

猫は、ハンティング・エリアを共有する

ことがある（図3）。都会の猫は、人口（猫

口）密度が高いのでハンティング・エリア

が重なることが多い。共有されるのは、

公園やゴミ集積所などのように餌が潤沢

にあり、複数の猫が食べていける場所

だ。

ハンティング・エリアは排他的なエリア

ではないとは言え、無節操に新しい猫が

やって来れば、1匹当たりの分け前が減っ

てしまう。そのため、猫は自分の縄張で

見知らぬ猫を見かけると追い出そうとす

る。そして、よそ者ではない（旧知の仲で

ある）ことを確認する作業が、猫の集会だ

と言われている※21

。

猫の集会は、共有されたハンティング・

エリアで行われ、公園などの人目に付き

やすい場所であることが多い。民家の縁

の下でこっそりと集会が開かれるようなこ

とはないのである。地域猫の場合は、人

が餌場を決めて定期的に餌を与えるの

で、その餌場がすべての地域猫のハンテ

ィング・エリアに含まれる。だとすれば、そ

の公園が集会所になるのは必然である。

猫と人との望ましい関係

避妊／去勢された猫がおとなしくなる

のは、生殖能力を失って老人（老猫）化し

てしまうからだ※22

。人になつきやすくなる

ので、猫好きは喜ぶかもしれない。しか

し、筆者には、活力をそがれたその様子

が痛し々く感じられてならない。筆者は、

野良猫は野良猫として、たくましく生きて

ほしいと思う。できれば、地域猫にせず

に済むほうがよい。

猫好きは、野良猫が増えて問題化しな

いように、安易に餌を与えるといった行

為は自重してほしい※2 3

。そして、飼い猫

は室内飼いにして、野良猫と交わらない

ようにするべきだ※24

。

09

※19 室内飼いの猫は、頻繁に窓から外を眺

めている。これを見て「きっと外に出たいのだろ

う」と勘違いする人がいるが、猫は自分の縄張

りにほかの動物が侵入していないか監視してい

るだけである。猫は、さかりのときに雄が雌を探

しに行く目的以外には、好んで縄張りの外に出

ようとはしない。

※20 マーキングは目立つほうがよいので、爪

とぎはできるだけ高い位置にしようとするし、ス

プレー（尿によるにおい付け）のにおいも普通

の尿より強い。室内でマーキングされると、飼

い主にはつらいものがあるが、それを理由に避

妊／去勢するというのには筆者は反対だ。猫

好きならきちんとしつけをし、ある程度は我慢す

るべきだ。

※21 自分がその餌場を縄張にしていること

を表明するために、1日1回集まってお互いに点

呼をとっているようなものだ。

※22 道路を悠々と横断している猫がいて、

筆者のクルマが近づいても気づかない。ブレー

キをかけるくらい接近してようやく気づいたようだ

が、慌てた素振りもなく、悠然と引き返していっ

た。よく見ると、耳にピアスをしていたので地域

猫だろう。猫が道路を横断するときは“命懸け

で全力ダッシュ”というイメージがあったので、そ

のおっとりぶりに驚いた。

※23 筆者も今は反省し、野良猫には決して

餌を与えないようにしている。

※24 前述のとおり、室内飼いは猫にとって

かわいそうなことでも何でもない。むしろ、縄張

争いでケガをしたり、野良猫から病気をうつされ

たりすることがないので、ぜひ室内飼いをお勧

めしたい。

勝手に

ア

ー

キ

テ

ク

チ

ャ

分析

猫と

人の〝関係〟を考える

Vol.

猫は群れないから、犬のようにボスを必要としない。

飼い主との関係も、本人（猫）は対等だと認識している。

いつも寝てばかりでのんびりしているが、

すべての行動は自分の判断に基づく。

生きるも死ぬも自分次第。仕事に忙殺されそうだったとき、

筆者は本気で猫になりたいと思ったものだ。

一見お気楽に見える猫の生活がうらやましかったからだが、

すべて自分で責任を取る代わりに

あらゆるしがらみから解放されて自由に生きる、

その潔さにあこがれている部分もあるのかもしれない。

7/22/2019 IT Vol.13 00.pdf


7/22/2019 IT Vol.13 00.pdf


キャパシティ・

最適なインフラ設計のための

特集 2


7/22/2019 IT Vol.13 00.pdf


7/22/2019 IT Vol.13 00.pdf


特集 2

キャパシティ・プランニング最適なインフラ設計のための

ITシステムを取り巻くビジネス環境の変化

それでは今日、ITシステムを取り巻くビジネス環境には、

どのような変化が起きているのだろうか。

その1つとして「グローバル化」が挙げられる。これは、

企業の事業拠点が世界中に分散し、また世界各国の

企業との間でエコシステム（経済圏）が形成されている状況を指す。このグローバル化が進んだことで、24時間

365日ビジネスを継続できるよう、ITシステムにも常時稼

働し続けることが求められるようになっている。

またもう1つ、「ネット・ビジネスの普及」も挙げられる。

ネット・ビジネスでは、いつ商品が購入されるかわからな

い。一般消費者向けの商品なら、ECサイトへのアクセス

は1日のうち夕方にピークを迎えるが、たとえ真夜中で

あっても、アクセスがないとは限らないのだ。加えて、ネッ

ト・ビジネスでは、Webサイトへのアクセス数が急に増加

することがある。最近では、一般消費者向けのサイトで

これに起因するシステム障害が頻発しているが、特に株

取引のような公共性が高いものについては、ITシステム

の障害が社会的な問題を引き起こすこともある。

このように、ITシステムに対するアクセス特性（人数／

時間／場所など）は大きく変化しているのだ。

さらに、近年では、新たに「内部統制の強化」という

課題が登場してきた。内部統制では、ビジネス活動に

付随する脆弱性を調査し、対処することが求められる。

これに対しては、「BCP（Business Continuity Plan：事業継続性計画）」や「DRP（Disaster Recovery

Plan：災害対策計画）」を策定するだけでなく、それ以

前にシステムの稼働率に関する要件と、その稼働率を

維持するための対策を明示しなければならない。それに

あたっても、キャパシティ・プランニングが不可欠となる。

システム・インフラの複雑化

一方、システム・インフラが複雑化したことは、予想外

の障害を引き起こす大きな要因となっている。

初期のコンピュータは、CPUとメモリ、そしてバスを経

由して外部接続されたディスクから成る単純な構成

だったため、CPU使用率やメモリ使用量、ディスク負荷

率、待ち行列などの簡単な指標を基に性能を予測する

ことができた。しかし、現在の複雑化したITインフラでは、

これらの指標だけで性能を予測するのは困難だ。以下

に、サーバ／ストレージ／ネットワークのそれぞれにおいてどのような複雑化が進んでいるのかを説明する。

まず、サーバに関しては、複数のCPU／メモリが搭載

されたボードをさらに組み合わせてSMP（Symmetric

Multiprocessing：対称型マルチプロセッシング）構成

としたものが登場してきている。そうした複数（場合によっ

ては数十）のCPUで構成されるサーバ・マシンでは、バ

スの競合によってどのような影響が生じるのかを把握し

づらく、正確な性能予測を行うのは難しい。またCPUも、

クロックの高速化ではなくマルチコア化によって性能の

向上を図るようになっており、高価な大規模サーバ以

外のサーバも同様の問題を抱えつつある。

さらに、複雑化を助長する要因としては、最近、注目

を集めている仮想化技術が挙げられる。仮想化技術

を用いることで、複数の仮想OS環境を単一のサーバ

上に構築することが可能だ。しかし、CPUやバス、I/O

装置を物理的に共有するため、1つの仮想OS 環境の

負荷が増大したときに、個別のサーバで運用する場合

とは比較にならないほど大きな影響を他の仮想OS環境

に与えるおそれがある。一方、ここ数年で急速に普及した集合ストレージは、

複数のサーバとの通信や搭載された多くのストレージを

制御するために、いくつものコントローラを備えており、そ

れらが共有のキャッシュをコントロールするという仕組みに

なっている。この仕組みは、1つの大きなコンピュータ・シ

ステムと言っても過言ではなかろう。こうした大規模なスト

レージ環境では、オンライン・トランザクションのように

キャッシュ・ヒット率の高い処理では問題がなくても、高

負荷のバッチ処理やバックアップ処理、システム障害

時のリカバリー処理などによって急激に性能が低下する


7/22/2019 IT Vol.13 00.pdf


キャパシティ・プランニング手法の変遷

ことがある。

ネットワークの分野では早くから仮想化が普及してお

り、今日では物理的な配線から論理構造を正確に把

握するのはほぼ不可能になっている。また、ネットワーク

の高速化により、建物の内部などの構内環境で性能

上の問題が発生することは少なくなったが、インターネッ

トなどの外部ネットワークを経由する場合は正確に性能

を予測するのは難しく、その点でまだ問題を抱えている。以上のようなシステム・インフラの複雑化が、キャパシ

ティ・プランニングをますます難しいものにしている（図1）。

従来は、CPU／ディスク／ネットワークの高速化によっ

て助けられていた面もあったが、それらのインフラが複雑

化したことで、性能の予測が困難になっているのだ。

キャパシティ・プランニングの

ライフサイクル管理が重要

複雑化するシステム・インフラと変化する性能要件に

対応するためには、システム導入時にハードウェア／ソフ

トウェアの構成を十分検討したうえで、“変化に強い

アーキテクチャ”を設計することが重要になる。

しかし、昨今はビジネス環境の変化の度合いが激し

く、導入当初の性能要件の見込みが数年、もしくは数

カ月で変わることも珍しくない。したがって、今日のキャパシ

ティ・プランニングでは、システム導入時のアーキテクチャ

設計だけでなく、日の々運用の中で、負荷状況の変化

の観察からシステム構成の見直しまでを含めたライフサイクル管理を行うことが重要となる。つまり、キャパシティ・

プランニングを「統制」することが求められているのだ。

キャパシティ・プランニング手法の

移り変わり

ここまでに説明した背景の下、現在は各インフラ層に

おける仮想化技術や、Part 3で紹介する学習エンジン

をベースにしたシステム特性の自動モデリング技術など

が注目を集めている。これらは、人間の理解の限界を

図1：複雑化したITシステム

コントローラコントローラコントローラコントローラ

コントローラコントローラコントローラコントローラ

CPU

ファイバ・チャネル

大規模なコンピュータ・アーキテクチャの例※

※ 仮想化技術により論理構成はさらに複雑になる。

チャネルチャネルチャネルチャネル

チャネルチャネルチャネルチャネル

キャッシュ・メモリ

メモリ

I/O装置

ディスク

初期のコンピュータ・アーキテクチャ

CPU

メモリ

I/O装置

ディスク


7/22/2019 IT Vol.13 00.pdf


特集 2


超えた「複雑系」としてのシステムに対する、キャパシ

ティ・プランニングの“アシスト・ツール”だと言えよう。今後

どのようなアシスト・ツールが生み出され、インフラ構築に

適用されるのかを考えるためにも、以降では、これまで

実践されてきたキャパシティ・プランニングの手法を振り

返ってみたい。

メインフレームの

キャパシティ・プランニング

まずはメインフレーム時代を見てみる。メインフレーム

の強みは、厳密なリソース制御機能を搭載していること

にある。長年の実践で鍛え上げられたこの機能は、近

年登場してきたWindowsやLinuxなどが及ばない領

域の1つだ。これについて、オンライン・トランザクション処

理（OLTP：On-Line Transaction Processing）を例

にとって説明する。

OLTPでは、専用端末と専用線の間において、ピー

ク変動やスパイク（トラフィックの急増）が起きる可能性

がある。それらの変化に対応するために、メインフレーム

には、バッチ処理の実行中にCPU使用率が100％に達

した状態でも、重要なトランザクションが発生したときに

は優先的に処理するための工夫が随所に施されている。

また、メインフレームの時代には、1つのOS環境でオン

ライン処理とバッチ処理が同時に行われるのが常であった（図2）。そうした状況でトランザクションが生じた場合

には、バッチ・タスクの優先度を下げ、強制的にリソー

スを摂取し、オンライン処理を優先的に処理していたの

である。

ピークを基準にしたキャパシティ・プランニング

顧客の業務特性やシステム特性によっていくつかの

考え方はあるが、OLTPにおける代表的なキャパシティ・

プランニングの方法論は「ピーク日」を基準にしたもので

あった。この方法では、トランザクション数を分析する必

要があるが、その基となる業務量は蓄積された稼働

データからある程度の傾向を予測できる。

しかし、いくら傾向が予測できると言っても、ミクロな数

値まで予測するのは困難だ。例えば、年間の業務量を

12で割ったものが月間の業務量になるわけではないし、

その数値を20日で割ったものが日次の平均業務量にな

るわけでもない。そして、季節変動や年末年始、ゴール

デンウィーク、盆暮れといったイベント、月末／月初、週

末、さらには曜日や天気などによっても業務量は変動

する。

ただし、こうしたミクロな変動ばかりに注目していると、

結局、秒間の最大トラフィックを基準にすることになり、過剰なキャパシティ・プランニングになってしまうので注意

が必要だ。

簡単な例を示そう。1時間で36万件のトランザクション

を処理する場合、単純に36万件を1時間（3,600秒）で

割り、100件／秒で処理できるキャパシティがあればよい

かというと、そうはいかない。なぜなら、36万件のトランザ

クションがそれぞれ等しい間隔でシステムに到着すること

はなく、実際にはランダムに届くからである。つまり、1秒

間に10件のときもあれば500件のときもあるのだ（次ペー

ジの図3）。では、1秒間に到着する最大件数が500件

図2：厳密なリソース制御

業務タスク（オンライン）業務タスク（バッチ）

ワーキング・セット

CPU メモリ

リソース制御／優先制御

I/O


7/22/2019 IT Vol.13 00.pdf



図3：トランザクション処理の考え方

100件／秒

時間10分

100件／秒

時間1分

100件／秒のキャパシティでは処理できない

700件／秒が到着する場合もありうる

だから500件／秒のキャパシティが必要かというと、それ

も違う。もしかしたら、1秒間に700件のトランザクションが

到着するかもしれない。業務量のベースとなるビジネス

環境は日々、変化している。何が起きるかわからないの

だから、余裕を持ったキャパシティが必要だ。

このピーク日を基準にしたキャパシティ・プランニングで

は、いくつか重要なポイントがある。それらのポイントを、1

秒間に200件のトランザクションを処理するシステムを例

にとって以下にまとめてみた。

①まず、1秒間に100件のトランザクションが到着した場合に、平均CPU使用率が50％の状態で目標スルー

プットの100件／秒が達成でき、なおかつ目標TAT

（Turn Around Time）を満たすこと

②次に、1秒間に200件のトランザクションが到着し、さら

にCPU使用率が100％の場合でも、目標TATを達

成できること

③そして、最も重要な点は、1秒間に400件のトランザク

ションが発生し、CPU使用率が100％でメモリ空間に

空きがなく、I/Oも飽和しているような緊急事態が発

生した場合でも、平均TATが多少延びつつも目標

スループットの200件／秒で正しく処理できること

このように、メインフレームでは、業務量をベースにし

てCPU／メモリの使用率（あるいはゆとり）を見積もり、こ

れらの増設時期やディスク／チャネルの拡張時期を予

測してきた。つまり、“山あり谷あり”の処理の揺らぎをリ

ソース制御で抑え込み、平準化して処理できることが、

メインフレーム時代のキャパシティ・プランニングのよりどこ

ろだったのである（図4）。

分散型システムのキャパシティ・プランニング

メインフレーム時代に続くのは、オープン環境による分

散型システムの時代だ。

筆者の場合、1995 年から基幹業務の領域で分散

型システムの構築に取り組み始めた。そこですぐに感じ

たのは、キャパシティ・プランニングの難しさである。今と

なっては当然のことだが、分散型システムにはメインフ

レームに備わる厳密なリソース制御機能がなかったの

だ。


7/22/2019 IT Vol.13 00.pdf


特集 2


図4：処理の揺らぎを平準化

キャパシティの限界

200件／秒

時間

CPU使用率100％

時間

正常TAT

TAT回復TAT遅延

限界を超えた部分と後続の処理は、TATの遅延を伴いつつも正常に処理され、システム全体は回復して元に戻る

そのころは、まだメインフレームが利用されていたような

領域（大規模な基幹システム）へ分散型システムを導入

した例はほとんどなく、事例の蓄積やノウハウなどは非常

に少なかった。当時のUNIXサーバは、ハイエンドのモ

デルでも、現在のブレード1枚程度の性能しかなく、メイ

ンフレームから分散型システムへとシステムを再構築すると、数十台から数百台のサーバが必要になった。それ

ら多数のサーバ群を協調して動作させつつサービスを

提供する大規模な分散システムの場合、全体を1つにく

くってキャパシティ・プランニングを行うのは困難である。

リソース管理の難しさ

難しさの原因は、個々のサーバにあった。厳密なリ

ソース管理機能が存在せず、CPUリソースは公平かつ

緩やかに配分され、メモリは早い者勝ち、空きメモリがし

きい値を超えたところでpageoutデーモンが動き出し、

利用頻度が低いメモリ・ページを検出しては強制的に

解放する（フリー・リストに戻す）。

また、CPUリソースが逼迫し、空きメモリが少なくなっ

た状況では、ページ・スチールを行うpageoutデーモン

と、動作のために必要なメモリ領域を確保しようとする

業務アプリケーションとの間でスラッシング

※1

が発生してしまい、ページ・リプレースだけでは処理が追いつかない。

こうしたケースでは、プロセスの非活性化（スワップアウ

ト）が行われるものの、スラッシングは収まらず、CPU使用

率が100％に達したままとなる。その結果、業務アプリ

ケーションの動作に悪影響を及ぼすことがあった。

分散型システムはこうした仕組みであるため、たとえ

平均 CPU使用率を60％程度に想定してシステムの性

能を調整したとしても、システムの処理の揺らぎを抑え込

※1 OSが仮想メモリへのI/OでCPUリソースを消費してしまい、外部からの

I/Oを受けられなくなる状態。


7/22/2019 IT Vol.13 00.pdf



んで平準化するには、さらなる工夫が必要になる。まして

や、Webサイトのように不特定多数のエンドユーザーを

相手にするシステムではなおさらだ。

分散型システムにおける性能分析

一方、分散型システムの構築が開始されてから10余年が経過した今日、なかには最先端のサーバに更

改されたシステムも存在する。それら最新のシステムの性

能を更改前と比較してみると、10倍程度の差が見られ

るケースもある。このようにハードウェア技術が進歩した

おかげで、現在は必要なサーバ台数がかなり減ってい

る。とは言え、ITシステムに要求される性能／機能はよ

り高くなっており、キャパシティ・プランニングの重要性に

変わりはない。

そこで以降では、キャパシティ・プランニングの基礎

データとして非常に重要である「性能」に焦点を当て、

実際にシステム・インフラの構築で用いられている分析

手法を紹介する。

この性能分析におけるポイントは、システムの挙動／

振る舞いを中心にして、その全体像を「マクロに把握す

ること」と、特定の処理に着目して「ミクロに分析するこ

と」の2つだ。

「マクロな把握」では、特別なコマンドは必要ない。

OSに付属するコマンド（ps、sar、top、vmstatなどのプロ

セス／システム管理コマンドや、truss/tuscなどのシステム・コール・トレース・コマンド）があれば十分だ。

ただし、アプリケーションの記述言語がJavaである場

合は注意してほしい。これらのコマンドによってプロセス・

レベルでの振る舞いがマクロに理解できても、JVMの世

界では何が起きているのかわからないからだ。プロセス

空間を独自に管理しているJVMに対しては、なるべく専

用のツールを使ってモニタリングすべきである。特に、各

種ヒープの増減を把握する際には、そうしたツールが必

須になる。

また、「ミクロな分析」では、プロセス・レベルやスレッ

ド・レベルで性能情報を収集する。例えば、1つのトラン

ザクションを処理する過程で発生したシステム・コール

の種別や発行回数、それらの平均TATやCPU時間

などの情報を詳細に取れれば取れるほど、分析精度は

向上する。

分散型システムでは、1つのトランザクション処理が複数のサーバを渡り歩くケースがほとんどであり、複数

サーバにまたがって観測する必要がある。また、さまざま

なミドルウェアの上に実装された基幹系の業務アプリ

ケーションであれば、たとえ1台のサーバであっても、1つ

の業務トランザクション処理を完了させるために複数プ

ロセスが協調して動作することが多い。

こうした分散型システムの特徴に対処するには、シス

テム・コール／割り込み処理の発生時／完了時、コン

テキスト・スイッチ（プロセス切り替え）といった部分で、プ

ロセスIDやシステム・コール番号、割り込み種別、タイム

スタンプなどを収集し、時系列に並べればよい。それによ

り、CPUの動きを“見える化”することができるのだ。

性能分析ツールを使った

トランザクション処理の解析

今日、CPUの動作を可視化するためのツールは多く

存在する。そうしたツールの特徴について、NECの性能

分析ツール「mevalet」を例にとって説明しよう。

画面1は、アプリケーション・サーバ（Linux＋Apache、JBoss）とデータベース・サーバ（Linux＋Postgre

SQL）で構築されたWebシステムのアプリケーション・

サーバに対してmevaletを適用し、トランザクション処理

の情報を収集した結果だ。

このグラフでは、縦軸がスレッドID、横軸が時間を表

す。スレッド4551、4683、4678はApacheのプロセスに、

スレッド4604、4602、4593はJBossのプロセスにそれぞ

れプーリングされており、スレッド4593はトランザクション

処理のタイムアウト制御を担う。そして、いくつか存在す

るすきまが、データベース・サーバにSQL文を投げて応


7/22/2019 IT Vol.13 00.pdf


特集 2


画面1：mevaletで収集したアプリケーション・サーバのトランザクション処理情報

Apache Txn#1

Txn#2

Txn#3

JBoss

答を待っている時間であり、その間CPUは解放されるこ

とになる。その他の色付きの部分はCPU処理が走って

いることを示しており、左下の凡例にあるように、緑色が

ユーザー空間、青色がカーネル空間、赤色がページ・

フォルトで、黄色が割り込みなどの処理を示す。

では、このグラフを基に、システム内でトランザクション

がどのような動きをしているのか見ていこう。

まず、トランザクションTxn#1が到着すると、それを

Apacheプロセスのスレッド4678が受け取ってJBossを

呼び出す。JBossプロセスでは、スレッド4602がその呼び

出しの延長で動き出し、スレッド4593を起動する。そして

いくつかの処理を経て、Txn#1は呼び出し元であるス

レッド4678に戻る。Txn#1の処理が終了した後、2つ目のトランザクショ

ンであるTxn#2が到着する。Txn#1を処理したときとは

異なり、それをスレッド4683が受け取ってJBossを呼び出

している。するとJBossでは、Txn#1の場合と同じくスレッ

ド4602が動き出し、同様の処理を開始する。

続いて、Txn#2の処理が完了する前に、3番目のトラ

ンザクションであるTxn#3が到着しているが、これはス

レッド4551が受け取ってJBossを呼び出し、スレッド

4604が処理を開始する。このTxn#3のケースでは、タ

イムアウト制御を行うスレッド4593は起動されない。こうし

て、Txn#2とTxn#3は並列に処理され、それぞれのプ

ロセスを完了する。

以上のようなプロセス実行の情報を収集するとともに、

データべース・サーバ側にもmevaletのようなツールを適

用し、PostgreSQLの動作情報を収集すれば、1つのト

ランザクション処理の全貌を“見える化”することができる。

この例のように、単発処理の軌跡をトレースしたものを

「シングル・プロファイル」と呼ぶ。これは、キャパシティ・

プランニングの基礎データやシミュレーション・ツールの

入力として使われる非常に重要な情報なので、できるだ

けキャパシティ・プランニングの初期段階で収集すること

が望ましい。

＊＊＊

以上、本パートでは、キャパシティ・プランニングの重

要性が増した理由と、これまで実践されてきたキャパシ

ティ・プランニングの手法について説明した。分散型シ

ステムの項で取り上げた例からもわかるように、今日の

キャパシティ・プランニングでは、システムの振る舞いに関

する情報を綿密に収集したうえで、それを厳密に分析す

ることが必要となる。次パートでは、分散型システムの代

表的な処理形態を例にとり、キャパシティ・プランニング

の具体的な実践手法を解説しよう。


7/22/2019 IT Vol.13 00.pdf


プ2でヒアリングした要件を満たすために必要なシス

テム構成（ハードウェア／ネットワーク構成）を検討

／決定する

●ステップ4 評価／チューニング：ステップ3で決定したアーキテクチャについて、それが適正なものかどう

かを評価し、必要があれば見直しを行う

特に、ステップ4でアーキテクチャを評価するためには、

事前準備としてシステム・モデルの特性を十分に理解し

ておくことが重要だ。以下に代表的なシステム・モデル

を挙げるので、参考にしてほしい。

●3階層システム：プレゼンテーション層／ファンクション

層／データ層で構成され、Webシステムなどに用いら

れる（図1）

●バッチ・システム：メインフレームの時代から引き続き

さまざまな形態のシステムが存在する今日、キャパシティ・プランニングは

従来と比較にならないほど難しくなっている。

しかも、この困難な作業にあたる際の指針となるような標準的なガイドラインも存在しない。

だが、ビジネスでITシステムが果たす役割が増し、

キャパシティ・プランニングの重要性が叫ばれている今こそ、

その手順を体系的に示すことが必要であろう。

そこで本パートでは、代表的なキャパシティ・プランニングの手法を解説する。

Part 2

キャパシティ・プランニングの実践手法現状分析から性能要件の把握、アーキテクチャの決定、評価／チューニングまで、

システムの処理能力を高めるためのポイント

上坂利文 Toshifumi Uesaka

NEC 第一システムソフトウェア事業部シニアマネージャ

インフラ設計の標準化

キャパシティ・プランニングでは、初めに各サーバの

役割とサービス・レベル（応答時間／処理量）を把握し、システムに要求されるパフォーマンスを満たすためのアー

キテクチャを設計する。そのうえで、その評価／見直し

の作業を継続的に行っていくことになる。その流れを、い

くつかのステップに分けて整理すると、次のようになる。

●ステップ1 現状分析：システム構成（システム・モデ

ル）やハードウェアの性能情報を収集する

●ステップ2 性能要件の把握：ユーザー／運用部門

などにヒアリングし、システムに求められる要件（サービ

ス・レベル）を正確に把握する

●ステップ3 システム・アーキテクチャの決定：ステッ


7/22/2019 IT Vol.13 00.pdf


特集 2


図2：バッチ・システムのモデル

ジョブ実行サーバ

ジョブ管理マネジャGUI

ジョブ管理マネジャ

図1：3階層システムのモデル

クライアント

（Webサーバ）

（APサーバ）

（DBサーバ）

プレゼンテーション層

ファンクション層

データ層

インターネット

図3：ハブ型システムのモデル

業務アプリケーション

EAI

ERP

基幹業務

SCM

利用されている一括処理向けのシステム・モデル。こ

のモデルの特徴は、昼間のオンライン業務に影響を

与えないよう、夜間／休日などシステムの空き時間に

バッチ処理を完結する点（図2）

●ハブ型システム：企業間のシステム連携やサプライ

チェーンによく利用される。また、EAI（EnterpriseAppl ication Integration）やBPM（Business

Process Management）のシステムにも使われること

が多い（図3）

これらのモデルの特性も踏まえ、机上での見積もり／

評価を繰り返すわけだが、その際にはアーキテクト個人

の勘／経験に頼ることも多い。だが本来は、個人のス

キルに強く依存した属人的な設計手法は極力排除し、

標準化された手法でインフラ設計に臨むことが望ましい。

3階層システムのキャパシティ・プランニング

ここからは、今日の代表的なシステム・モデルである3

階層システムを例にとり、キャパシティ・プランニングの手

順を説明していく。

3 階層システムでは、Webブラウザからのリクエスト

（HTMLファイルの送信要求やサーバへの処理要求な

ど）を、Webサーバ、アプリケーション・サーバ（以下、

APサーバ）、データベース・サーバ（以下、DBサーバ）の各層で役割分担して処理する。このシステム・モデル

は、各層で分散処理することによって効率化が図れるも

のの、いずれかの層の処理がエラーになると、システム

全体で障害が発生したり、パフォーマンスの低下が起き

たりするリスクをはらんでいる。

例えば、データ処理が不要なHTMLファイルの送

信要求が頻発したときにはWebサーバの処理量が超

過し、また複雑なデータ処理を伴う要求が多ければ、

DBサーバで処理量の超過が発生する。3階層システム

にはこのような懸念があるため、この点を考慮してキャパ


7/22/2019 IT Vol.13 00.pdf


キャパシティ・プランニングの実践手法


シティ・プランニングを行わなければならない。以下に、3

階層システムのキャパシティ・プランニングで留意すべき

点を挙げておく。

①Webサーバ／APサーバ／DBサーバの各層につ

いて、それぞれの性能を把握する

②システムの性能要件（処理要求数の傾向やその最大値、許容されるレスポンス時間など）を把握する

③適切なシステム構成（各層のサーバ台数や各サー

バに搭載するCPU／メモリ／ディスク、すべての現用

系クラスタによる負荷分散、システム・リソースの分散

など）を検討し、採用するアーキテクチャを決定する

④③で決定したアーキテクチャに、「静的積算」や「シ

ミュレーション」、「プロトタイピング」などの手法（それ

ぞれ後述する）を適用し、テスト・トランザクションを発

生させて結果を評価する。また、必要に応じてパラ

メータの変更やハードウェアの追加といった見直し

作業（チューニング）も行う

次章からは、上記の留意点も踏まえ、前述した4つの

ステップに沿ってキャパシティ・プランニングの具体的な

手順を解説していく。

ステップ1 現状分析

キャパシティ・プランニングの第一歩は、すでに稼働し

ているシステムの現状をしっかりと把握することだ。それには、まずシステム・モデルに応じた処理の仕組みを理解

することから始める。次に、そのシステムの特性を踏まえ、

継続して管理すべき性能情報を検討し、さらにシステム

に固有の環境／状況まで把握する必要がある。

3階層システムにおける処理特性

3階層システムでは、サーバ側の処理を各層に分散

するため、想定される処理要求数に対して各層のパ

フォーマンスが十分かどうかを分析することがポイントにな

る。その際には、各層のシステム・アーキテクチャが異な

る点にも注意する。

まず、WebサーバとAPサーバだが、これらは処理要

求に対して同時並行で処理する点が特徴だ。処理要

求数が各サーバの処理能力を上回るケースが想定さ

れる場合は、サーバの台数を増やすことによってパ

フォーマンスを上げ、対応可能な処置要求数を増加させるのが一般的な対策である。このサーバ台数の増加

による拡張形態を「スケールアウト」と呼ぶ。

一方、DBサーバは少し事情が異なる。近年のデー

タベース分野では、複数のサーバによる並列処理技

術が発達しているが、データの同一性を確保するため

には、複数の処理要求に対しても1つのデータベースに

アクセスさせなければならない。それによるデータ処理数

の増加に対応するには、サーバ内のシステム・リソース

（CPU／メモリ／ディスク）を増強する、あるいはより高

性能なサーバに置き換えるといった対策が考えられる。

このように、サーバ単体のパフォーマンスを向上させるこ

とを「スケールアップ」と言う。

上記のような各層の特性に応じた拡張形態を理解

するとともに、実行される処理が、どの層にどの程度の

負担をかけるのかもあらかじめ把握しておかなけばならな

い。

例えば、APサーバでは、プログラムの開発言語に

Javaが用いられることが多い。Javaではメモリ管理が自

動的に行われ、開発者へのプログラミング負担を軽減しているが、自動であるがゆえに、ガーベジ・コレクション

（利用していないメモリ空間を整理する機能）によって

予期せぬプログラムの実行遅延が生じる。そのため、

ハードウェアの増強に比例したパフォーマンスの向上が

得られないことがある。また、まれなケースではあるが、

ネットワークの輻輳やネットワーク帯域の奪い合いよる伝

送遅延が起きることもある。

現行システムの現状分析

各層の処理特性を把握したら、次に実際に稼働中

7/22/2019 IT Vol.13 00.pdf


特集 2



のシステムを対象にして現状分析を行う。その際には、

各層の役割が異なる点に注意して、必要な性能情報

を収集する。

●Webサーバ

Webサーバは、プレゼンテーション層として、リクエス

トの受け付け／HTMLファイルの生成／応答といった役割を担う。Webブラウザからの処理要求はHTTPリ

クエストとして送られるが、それにはスタティック（静的）コ

ンテンツの要求と、ダイナミック（動的）コンテンツの要求

の2種類がある。前者に対しては、あらかじめ用意され

た静的なHTMLファイルを送り返し、後者に対しては、

APサーバ／DBサーバからそのときの条件に応じて得

た情報をHTMLファイルにして返す。ダイナミック・コンテ

ンツへの対応では、特定のAPサーバにアクセスが集中

しないよう、ネットワーク上にロード・バランサ（負荷分散

装置）を配置するとよい。また、スタティック／ダイナミック

のいずれでも、各HTTPリクエストごとにCPU／メモリが

消費される。場合によっては、Cookieの情報取得など

でディスク・アクセスが発生する。

●APサーバ

APサーバで注意すべき点は3つある。

まず1つ目は、前述したJavaのメモリ管理（ガーベジ・

コレクション）だ。フルガーベジ・コレクションが実行され

ると、秒単位で処理が停止することがある。2つ目は、プ

ログラム構造の問題だ。プログラムがステートフルな（状

態を持っている）場合、同時並行で処理することができ

ない。メソッド（関数）内部には状態を持たせないステートレスなプログラミングを心掛けることが、並列処理の効

率化につながるのである。そして3つ目は、ハードウェア

における基本的な問題、つまりCPUやメモリなどのリソー

ス不足だ。

なお、APサーバ上でプログラムの実行中にエラーが

発生したときには、まず呼び出されたメソッドの単位で処

理時間を計測し、問題の早期発見に注力する。このこ

とは、システム・リソースの浪費を抑えるうえでも重要だ。

プログラムの実行時間を測定するためのものとしては、

Part 1で紹介したmevaletや、ワイリー・テクノロジーの

「Introscope」といったツールがすでに市販されている

ので、それらを積極的に活用したいところだ。

●DBサーバ

DBサーバのポイントも3点挙げられる。1つはSQL文

の実行時間である。特に全文検索や複雑な条件によ

バッチ・システム／ハブ型システムの現状分析

本編では3階層システムを例にとった

が、ここでは、その他の代表的なシステ

ム・モデルであるバッチ・システムとハブ

型システムの処理特性と現状分析の手

法を簡単に述べておこう。3階層システ

ムと同じく、これらのシステムでも各シス

テム環境に分けて性能情報を把握する

ことが大切になる。また、OSレベルとア

プリケーション・レベルで情報を収集し、

業務量に依存する項目を押さえておくこ

とも重要だ。

バッチ・システムの現状分析

バッチ・システムはジョブ管理ツール

で制御されており、処理を特定の時間

帯に集中して行う。その特徴としては、

分散型／集中型、専用サーバ／他

サーバ併用など、さまざまなシステム形

態がある点が挙げられる。そのため、各

システムの特性に応じて検討していくこ

とが重要だ。具体的には、「想定した時

間内に処理が完了するか」、「他のシス

テムに影響を与えないか」といったポイン

トがある。前者の場合、エラーが発生し

た際に再び処理を行うのならばその時間

も考慮する必要があるし、後者では、オ

ンライン処理の時間帯と重複するときは

事前に十分なシステム・リソースを確保

しておくといったことが考えられる。

なお、バッチ・システムでは、実行す

る個々のバッチ処理の特性を見極める

必要がある。本編で後述するシステム

固有の環境とも密接に絡んでくるからだ。

ハブ型システムの現状分析

ハブ型システムでは、すべての処理

がハブとなるサーバ（群）を必ず経由する。

そのため、各処理が求めるシステム要

件の違いにより、キャパシティ・プランニ

ングの手法も異なってくる。

例えば、厳密なリアルタイム性が要求

されるシステムには、同時処理が可能な

ハードウェア技術を採用すべきだ。特に

企業間をつなぐシステムの場合、サプラ

イチェーンを安定稼働させるためには、あ

らかじめSLA（Service Level Agreeme

nt：サービス品質規約）を定めたうえで

キャパシティ・プランニングを行わなけれ

ばならない。また、ある程度の遅延が許

される自社内のシステムについては、想

定される処理要求を一時的に蓄積する

ためのシステム・リソースを確保しておき

たい。

ハブ型システムでは、処理を中継する

EAIやBPI（Business Process Integra

tion）などのツールごとにパフォーマンス

を収集しておきたい。

7/22/2019 IT Vol.13 00.pdf




る検索／更新など、実行に多くの時間がかかるものに

は注意したい。また、2つ目はデータベースの設定内容

だ。例えば、ロールバックに必要なログ書き込みやキャッ

シュ・サイズなどの設定である。そして3つ目は、APサー

バと同じく、リソース不足の問題だ。

これらのポイントに対しては、データベースのパフォーマンスを監視することが非常に重要になるが、そのため

には、各データベース製品に固有のノウハウが必要だ。

最近では、NECの「WebSAM Application Naviga

tor」などのような特定のデータベースに特化した性能

監視ツールが販売されているので、それらを利用すれ

ば、パフォーマンスの監視が容易になるだろう。

システム固有の環境を理解する

システムの現状を把握するためには、各システムに固

有の環境も調査しなければならない。

3階層システムやハブ型システムでは、要求がある度

に処理が行われる。この処理要求が均等なタイミングで

発生するのはごくまれであり、通常はランダムに発生し、

またピークを迎える時間帯にも特性がある。このピークを

把握するには、さまざまな時間帯を考慮して調査しなけ

ればならない。

例えば、ECサイトの場合、1日のうちで多くの処理要

求が集中する時間帯もあれば、週末／月末／ボーナ

ス月といった異なる時間単位でピークが発生することもある。処理要求にはこのような特性があるため、その推移

は日／週／月／年などの異なる単位で調べる必要があ

るわけだ。

さらに、多くの処理要求を誘発するようなイベントが

（意図的か否かにかかわらず）、突如として発生するか

もしれない。例えば、ECサイトではキャンペーンの実施

期間、オンラインの株取引サイトならば特定企業に対す

る報道などによって処理要求が急増する。このような偶

発的な増加に対して、ピークに合わせたキャパシティ・

プランニングだけで対応するのは難しい。3階層システム

やハブ型システムでは、こうしたさまざまなリスクを想定し

てキャパシティ・プランニングを行うことが重要になる。

また、バッチ・システムの場合、イベントの実行日時が

あらかじめ特定されているが、その具体的な処理内容

やデータ量まで考慮してパフォーマンスを確保すべきで

ある。

ステップ2 性能要件の把握

次のステップでは、システムで実現すべき機能を性能

面で担保していく。各システムごとの特性を把握したうえ

で、その要件を決定していくことになるが、処理量のピー

クを見極めることが重要である点はこれまでに述べたとお

りだ。

ここでは、「想定される処理件数」と「処理に要する

時間」の2つを要件として定める。この2つの要件はAN

D条件になっており、どちらも満たすことが前提である。

また、信頼性（データの保証）や稼働率、拡張性な

ども検討しなければならない。このうち拡張性は、企業

の成長やビジネス環境の変化などにより、将来、処理

件数が増加したときの備えとして重要な意味を持つ。な

お、当然スケールアップによる拡張には限界があるので、

その対象であるサーバの仕様には注意したい。

図4に示すのは、3階層システムにおける性能要件の

一例だ。図のように、平均リクエスト数だけでなく、ピーク時間帯や将来計画まで盛り込むことが重要になる。

ステップ3 システム・アーキテクチャの

決定

性能要件が確定した後は、いよいよシステム特性に

合わせてアーキテクチャを検討／決定する。そのために

は、まずリクエスト1件当たりに必要なシステム・リソース、

または実行可能な処理件数をサーバ単位で見積もら

なければならない。

7/22/2019 IT Vol.13 00.pdf


特集 2


図4：3階層システムにおける性能要件の事例

＜前提条件＞●Webブラウザからの処理要求に対して3秒以内のレスポンスであること（ただし、処理要求時のネットワーク通信における時間は考慮しない）●1件当たりのリクエストは、以下のフローを想定

ログイン（認証）トップ画面閲覧商品閲覧＃1 商品閲覧＃2 カート確認購入確認ログアウト

＜現状分析＞●1日平均リクエスト数は、1万リクエスト／時間

●1日のピーク時のリクエスト数は、2万リクエスト／時間●月末のリクエスト数は通常の1.5倍●期末のリクエスト数は通常の2倍

＜将来計画＞●3 年後に最大1．5倍までリクエスト数が増加する見込み

月末と期末を考慮すると、最大6万リクエスト／時間が想定される

今後、9万リクエスト／時間まで増加する可能性あり

図5：1リクエスト当たりのシーケンス

●1CPU当たりの処理件数／秒

●1処理にかかる時間（1CPU当たり）

処理時間処理内容

2.4秒

0.7秒

2.4秒

2.4秒

1.5秒

2.4秒

2.4秒

0.7秒

ログイン（認証）

トップ画面閲覧

商品閲覧#1

商品閲覧#2

カート確認

購入

確認

ログアウト

0.1秒

100件

Webサーバ

0.1秒

50件

APサーバ

0.2秒

50件

●1リクエスト当たりの処理件数（1C PU当たり）

●処理リクエスト数／秒（1CPU当たり） 7リクエスト／秒

14件

4リクエスト／秒

11件


5件

DBサーバ

ネットワーク0.3秒




3階層システムにおける見積もりの例

図5は、各層におけるリクエスト1 件当たりの処理フ

ローを示したものだ。ここでは、この図に示した性能要

件に基づく見積もりの例を紹介する。なお、3階層システ

ムでは、見積もりを各層に細分化して行う必要があるこ

とに注意されたい。

このシステムでは、CGIなどによるプログラム処理のない

リクエスト（トップ画面の表示など）に対しては、Webサー

バのみの処理で応答が返される。一方、プログラム処

理が必要なリクエストに対してはAPサーバが返信し、

データベースの参照／更新を伴うリクエストについては

DBサーバが処理／返信する。

ここで重要なのが、各層のサーバに搭載されたCPU

の性能である「1処理当たりの実行時間」と「実行可能

な処理件数」だ。前者とネットワークのデータ伝送時間

を足して累積した時間がリクエストに対する応答時間と

7/22/2019 IT Vol.13 00.pdf



図6：3階層システムの見積もり例

現状分析

性能要件の分析結果

システム固有の処理特性

月末と期末を考慮すると、最大6万リクエスト／時間が想定される

将来計画

今後、9万リクエスト／時間（25リクエスト／秒）まで増加する可能性あり

●1CPU当たりの処理件数／秒

●1処理にかかる時間（1CPU当たり）

●1リクエスト当たりの処理件数（1CPU当たり）

25÷7≒4（CPU） 25÷4≒7（CPU） 25÷10≒3（CPU）

Webサーバ（2CPU）×3台 APサーバ（2CPU）×5台 DBサーバ（4CPU）×1台

Webサーバ

100件

0.1秒

14件


Webサーバ

50件

0.1秒

11件


Webサーバ

50件

0.2秒

5件

10リクエスト／秒●処理リクエスト数／秒（1CPU当たり）

必要なCPU数を算出すると

さらに1.5倍の性能を見込み、必要なサーバ台数を算出すると


なり、後者を1リクエスト当たりの処理件数で割ったもの

が、1CPUが対応できるリクエスト数となる。ここから算出

した数値と、想定した将来のリクエスト数を併せて分析

することにより、各サーバが確保すべき性能が明らかに

なるわけだ。それに応じて各層にキャパシティを割り当て、

必要なシステム構成（アーキテクチャ）を決定する。図5の要件に対する見積もりの例は、図6のようになる。

各層の特性を考慮した結果、Webサーバ／APサーバ

にはそれぞれ2CPUのサーバを複数台並べ、DBサー

バには高性能な4CPUのサーバを1 台配置するという

構成になっている。

なお、システム構成を決定するうえでは、並列分散

処理（アプリケーションのアーキテクチャも含む）を採用

することも考えられる。例えば、この例では、データベース

については1 台の高性能なサーバで集中して処理する

ことを想定している。だが、今日のDBMSの中には、複

数台のサーバによる並列分散処理が可能な製品もあ

る。信頼性が求められるシステムでは、この並列分散処

理の採用も検討し、少しでもシステム・ダウンの可能性

を減らすようにしたいところだ。信頼性を確保するために

は、このほかに、サーバをクラスタ構成にする、1台余分

に配置（N＋1構成）するといった方法もある（図7）。

一般に、システム要件を定義する際には、性能と信

頼性の要件が相反することが多い。性能を求めると信

頼性が弱まり、信頼性を求めると十分な性能を得られないことがしばしばある。例えば、システム障害に備え、

APサーバに「プログラムの状態情報をディスクに書き込

む」という機能を実装した結果、ディスク・アクセスによっ

て処理に多大な時間がかかったり、処理可能な要求

の件数が減少したりする。このように、性能と信頼性のト

レードオフには十分配慮しなければならない。

また、上で行った見積もりは性能要件を満たすことを前提にしたものだが、予算や投資対効果（ROI：Retu

rn On Investment）といった側面での検討も必要だ。

予算に対し、必要となる設備投資があまりに大きいよう

だと、システム要件そのものから見直さなければならない

という事態にもなる。

ステップ4 評価／チューニング

以上のような検討を経て決定したアーキテクチャには、

その設計過程で机上の計算が多く含まれている。よっ

て、それが実際に使えるものかどうかを検証／評価しな

ければならない。ただし、実際の利用環境（本番環境）

を完全に再現して検証するのは難しいので、その代替と

して、「静的積算」、「シミュレーション」、「プロトタイピン

グ」という3つの評価手法が利用されている。

静的積算

静的積算は、アーキテクチャを検討する際、まず最

初に実施する手法だ。これは、1リクエスト当たりの処理に必要なシステム・リソースや、各サーバが処理可能な

7/22/2019 IT Vol.13 00.pdf


特集 2


図7：3階層システムにおける見積もり例（冗長構成の場合）

信頼性を追求し、待機系を1台余分に設置

待機系

待機系

待機系

Webサーバ（2CPU）：3台＋1台

APサーバ（2CPU）：5台＋1台

DBサーバ（4CPU）：1台＋1台

冗長構成にするために「N＋1（待機系）」構成にすると


アーキテクチャが刷新されて過去のデータを適用できな

い場合などである。

例えば、3階層システムでは、Webサーバ/APサー

バ/DBサーバそれぞれについて、1台での評価環境を

構築し、1リクエスト当たりの応答時間や処理可能な最

大件数を実測／評価する。そして、性能要件に照らし

合わせ、本番システムに必要なシステム構成（サーバ台

数／CPU数／メモリ容量／ディスク容量）の見直しを

図るといったことが行われる。

＊＊＊

以上が、3階層システムに関するキャパシティ・プランニングの手順である。システムを安定して稼働させるため

には、ここで説明したような手順でシステムの性能要件

を明確にしてアーキテクチャ設計を行うとともに、稼働後

のシステムに対して継続的に性能検証を実施し、必要

に応じて改修を加えていくことが必要になる。それには当

然、拡張の容易なアーキテクチャ設計を心掛けることが

重要であるのは言うまでもない。

次のパートでは、ますます難しくなるキャパシティ・プラ

ンニングの作業を効率化するにはどのような技術／手

法が必要になるのかを考えてみたい。

件数を算出したうえで、性能要件に照らし合わせて、

必要なサーバ台数／CPU数／メモリ容量／ディスク

容量を試算するというものである。この手法では、同じよ

うな性能要件を持つシステムの稼働例を調べてみること

も重要だ。

シミュレーション

次のシミュレーションは、統計的な手法である。サー

バの台数を増やしたときに、処理量／処理時間がどの

ように変動するのかを、過去の傾向から分析／予測す

る。処理要求の到着タイミングの分布予測には、待ち

行列解析の手法を用いることもできる。また、今日では、

評価項目や条件を定めたシステム・モデルを定義し、そ

の性能をコンピュータ上で計算／予測するといったこと

も行われている。

なお、静的積算とシミュレーションは、いずれも実測

値から計算するわけではなく、あくまでも結果の予測に

限った手法であることに注意されたい。比較的、リクエ

スト数が少ない場合は予測どおりに推移しても、負荷が

高くなるにつれて予測がずれ、意図しないパフォーマン

ス低下が起きる可能性がある。そのため、性能評価に

あたっては、次のプロトタイピングも併せて実施すること

が望ましい。

プロトタイピング本番と同じシステム環境を用意して評価できればそれ

に越したことはないが、ユーザー数や処理量の多いシス

テムではそれが難しい。しかし、少しでも本番に近いシス

テム環境で評価することは、静的積算やシミュレーション

を行うよりも効果的だ。そこで実施されるのがプロトタイピ

ングである。本番のシステム環境を部分的に構築し、シ

ステムの稼働状況を予測するのだ。この手法では、負

荷発生ツールなどを使ってテスト・トランザクションを発生

させる。プロトタイピングがよく適用されるケースは、新し

いシステムで統計データが蓄積されていない場合や、

7/22/2019 IT Vol.13 00.pdf



今後のキャパシティ・プランニングに

求められる技術

Part 2で説明したように、キャパシティ・プランニング

では、性能要件の把握やシステム・アーキテクチャの決

定、評価／チューニングといった作業を実施する。これらの作業には、業務／システムに関する知識／ノウハウ

が不可欠なため、これまでは専門家の勘や経験に頼っ

て行われてきた。

しかし、近年のITシステムは、統廃合やサービスの

追加／削除／更新などが頻繁に行われ、その構成は

日々変化しており、人手で管理できる範囲を超えつつあ

る。例えば、データセンター全体のシステム特性を分析

する場合、数百から数千のサーバ／ネットワーク／スト

レージの性能データの中から、業務量に連動したデー

タを抽出しなればならない。この作業を人手で行うとした

ら気が遠くなるだろう。

こうした状況において、キャパシティ・プランニングを効

率良く行うには、その作業を支援してくれる新たな技術

／手法が不可欠だ。まず、現状分析のサポートとして、

業務量に連動して変化するシステム特性を自動的に抽

出する技術が求められる。さらに、評価／チューニング作業の支援として、将来必要になるシステム・リソースを

予測するような技術も必要だろう。以降では、今後の

キャパシティ・プランニングに求められるであろう、それら

の技術／手法について述べてみたい。

“動的”な現状分析

キャパシティ・プランニングを行う際、機器のスペック

表にあるような“静的”な情報しかない状況では、効果

的な改善計画を立てるのは難しい。「計画的に増強し

ここまで述べてきたように、システム・インフラを的確に設計するのは、年々難しくなってきている。

こうした状況の中で待ち望まれているのは、キャパシティ・プランニングを支援する新たな技術／手法の登場だ。

本パートでは、これからのキャパシティ・プランニングに求められる要件を明らかにしたうえで、

それに対応した手法として現在、

筆者らが研究を進めている「自動モデリング」を取り上げ、その概要を紹介してみたい。

Part 3

性能設計技術のこれからインフラ構成要素間の関係を自動的に把握し、

性能をシミュレートする「自動モデリング」のアプローチ

上坂利文 Toshifumi Uesaka

NEC 第一システムソフトウェア事業部シニアマネージャ

7/22/2019 IT Vol.13 00.pdf


特集 2



ていたはずなのに、思いもよらないところがボトルネックに

なってしまった」という話をよく耳にするが、これを防ぐに

は、実際に動いているシステムの“動的”な状態を考慮

して、現状分析を行うことが重要だ。その動的な状態

は、ITシステムを構成する各要素を監視し、これらの性

能情報を収集することによって把握できる。現状を適切に分析するためには、システム全体から

網羅的に性能情報を収集するのが望ましいが、これは

統合運用管理ソフトを導入することで比較的、容易に

行える。

こうした性能情報を用いた分析手法には、以下のよ

うなものがある。

●トレンド分析：過去の履歴からシステム・リソースが

利用される傾向（増減／周期性）を把握し、将来

の需要量を予測する

●シミュレーション：システム・モデルを用いて、負荷が

変化した場合の詳細な挙動をトレースする

●モデリング：待ち行列理論や信号処理技術などの

数学的手法を用いて、ITシステムの状態／挙動を

モデル化する

システム・リソースの需要はトレンド分析のみで予測で

きるが、ボトルネックの解析を行うためには、シミュレー

ション／モデリングの実施が不可欠だ。そのシミュレー

ションの予測精度は、どれくらいの範囲の要素を考慮

／網羅しているかに依存するのが一般的である。ただし、手作業でモデル化する場合は、要素の数が多くな

るにつれて作業量が多くなるため、コスト面から範囲を

限定せざるをえない。

システム特性の「自動モデリング」

今後、キャパシティ・プランニングをより効果的に行っ

ていくためには、システム特性の抽出を自動化し、安定

した精度で体系的にモデル化することのできる技術が

必要になるだろう。現在、筆者らはそれらの技術に関し

て研究開発を進めているが、ここではその技術のことを

「自動モデリング」と呼ぶことにする。この技術を用いれ

ば、勘や経験に頼る従来の分析とは異なり、関係する

要素を網羅的に扱い、なおかつ実際の挙動を正確に

反映した精度の高いシミュレーションを行えるはずだ。

なお、自動モデリングにはさまざまなアプローチが考えられるが、ここでは性能情報に着目した方法を紹介しよ

う。

自動モデリングによる関係性の把握

一般に、システムへの入力と各構成要素の処理にか

かる負荷の間には、何らかの相関関係がある。3階層シ

ステムであれば、Webサーバに送られる単位時間当た

りのHTTPリクエスト数と、そのWebサーバのCPU使

用率は密接にかかわっている。こうした各性能情報間

の関係性はシステム全体に及び、例えば1時間当たり

のSQLクエリ数は、DBサーバのCPU使用率やメモリ

使用量に影響を及ぼす。その関係をたどっていくと、シ

ステムへの最初の入力であるHTTPリクエスト数ともつ

ながるというわけだ。

経験を積んだアーキテクトならば、このような関係性

は頭に入っているかもしれない。だが、システムが複雑化

し、その利用形態が刻と々変化する今日において、人間

の能力だけですべてを把握するのは、もはや不可能だ

と言える。自動モデリングでは、この関係性をシステム全体から自動的に抽出するため、属人的な方法とは異な

り、毎回同じやり方で安定した精度を確保できる（次

ページの図1）。

抽出された関係性はシステムの利用状態を正確に

反映しており、それが可視化されることで、各要素の相

関関係は想定どおりか、特に注意すべきポイントはどこか

といった情報が得られるようになる。1つのサーバが複数

の業務に関係していたり、業務の利用率に時間的な偏

りがあったりすると、アーキテクチャ設計の際に想定して

いた構成要素とは違うところに負荷がかかることがある。

7/22/2019 IT Vol.13 00.pdf


7/22/2019 IT Vol.13 00.pdf


特集 2


図2：ボトルネック解析

APサーバ

リクエスト数が増加すると、APサーバとDBサーバのどちらがボトルネックになるか？

抽出された各構成要素間

の関係性から解析

CPU使用率

リクエスト数／秒

今は低負荷だが、急激に増加する！

推定値

実測値

100％

0％

飽和する

DBサーバ

CPU使用率

リクエスト数／秒

推定値

実測値

100％

0％

飽和しない

リクエスト数が増加すると、APサーバがボトルネックに


づくモデルを生成し、そのモデルを用いて負荷をシミュ

レートすれば、システム構成やその利用形態が変わって

も、どこがボトルネックになるのかを適切に把握できるのだ。

自動モデリングの可能性

自動モデリングには、このほかにもさまざまな可能性が

ある。

例えば、これを有効に利用することで、従来、人間の

能力の限界から切り捨てていた情報まで分析対象として扱えるようになるかもしれない。通常、「要素間の関係

をどう表現するか」、「各関係性の強度をどう評価する

か」といったことは、モデリングで採用したアルゴリズムに

よって異なる。しかし、データの意味を解釈しない（どれ

も同じ数値の並びとして扱う）タイプのモデリング手法で

あれば、対象がサーバやネットワーク機器の性能で

あっても、あるいはアーキテクチャが異なるメインフレーム

とレガシー・システムであっても、さらに極端な話、在庫

数や売上額といったITシステム以外の要素であっても、

それらの間の関係性を抽出できるだろう。

ビジネス環境が刻と々変化する今日、その状況に合

わせて継続的にシステムを改善していくことが重要であ

る。これまではシステム内に閉じた局所的な事象のみを

基にキャパシティ・プランニングを行っていたが、自動モ

デリングをうまく活用すれば、今後はより広い視点で事

象をとらえ、プロアクティブな（先を見越した）対策をとれ

るようになるだろう。

＊＊＊

以上、本パートでは、今後キャパシティ・プランニングを効率的に実施していくうえで重要になるシステムの可

視化手法として自動モデリングを取り上げ、それを用い

た分析作業の概要を示した。自動モデリングはまだ実

用化に至っているものではないが、近い将来、この手法

を実装したツールが登場してくることだろう。また、たとえ

この手法を使わない場合でも、精度の高いキャパシティ・

プランニングを実践するにはどのような手法が有効かを

模索し続けることは、アーキテクトに課せられた重要な

務めである。日々の情報収集に努めるとともに、IT以外

の分野にも常に関心の目を向けておきたいものだ。

7/22/2019 IT Vol.13 00.pdf



効

率

良

く

作

業

す

る

た

め

の

ノ

ウ

ハウ

を

伝

授

!

ア

ー

キ

テ

クト

の

仕

事

術

開発の現場において、アーキテクトには実に多く

の役割をこなすことが求められる。アーキテクトの

仕事をこなしつつ、1 人のエンジニアとしても作業

に加わるのはよくあることだ。プロジェクトの規模

が小さければ、プロジェクト・マネジャー的な役割

を兼ねたり、コンサルティングに近いことまで行っ

たりするケースも少なくない。結果的に、アーキテ

クトは多忙を極め、日々、目の前の仕事に追われ

ることになる。そこで本特集では、アーキテクトが

少しでも効率良く作業を進め、より高い成果を上

げるためのポイントとして「情報の整理」と「時間

の管理」に焦点を絞り、そのノウハウを紹介する。

情報管理／時間管

理の勘所を押さえ、限りあるリソースを無駄なく活用する

［

特

集

3

］

7/22/2019 IT Vol.13 00.pdf



現状把握のための情報整理

巷にあふれる情報は、その性質によってさまざまな形態

をとるが、アーキテクトが手にする情報は、主に計画書や

雑誌のコピーといった紙媒体のものと、Word 文書や

Excelの表のような磁気媒体のものとに大別できる。ここで

はまず、実体化されているためにイメージしやすい紙媒体を前提に情報の整理方法を説明し、続いて磁気媒体の

中にある情報の整理法について解説しよう。

不要な情報／重複した情報の除去

初めに、雑然とした自分の机の上をイメージしてみてほ

しい。「何はともあれ整理をしよう」という場合、必要なもの

と不要なものを分けることから始めるはずだ。例えば、マン

ションの広告や古い雑誌は捨てるだろう。同じ議事録を

たまたま2 部受け取った場合も、1部は捨てるはずだ。この

ような取捨選択をすることで、自分にとって必要な情報の

みが残ることになる。

当たり前だが、まずはこうした作業を面倒がらずに行わ

ないと、情報の整理は始まらない。「情報の整理は重要

な作業だが、それには相応の時間がかかる」ということを

心してほしい。

検索キーの設定

「情報を整理せよ」などと言われると、何だか難しいこと

のように思われるかもしれないが、情報の整理とは、つま

「次回の検索を容易にするための準備」である。キーワー

ドは「検索」だ。であるとすれば、検索に使う「検索キー」

を何にするかがポイントになる。検索キーは情報を見つけ出すための入り口であり、こ

れを目印にして情報整理を行っておけばよいのだが、ベス

トなキーは人によって異なる。そのため、一概には言えない

が、候補としては「①テーマ（目的）」、「②時間（タイミン

グ）」、「③作業」、「④人（ステークホルダー：利害関係

者）」、「⑤技術（規格）」などが挙げられる。実際には、こ

れらのうちのいくつかを組み合わせて検索キーにするケー

スが多いはずだ。

アーキテクトにとって最も検索キーにしやすいのは、プロ

ジェクト計画書の大項目だろう。なぜなら、アーキテクトの

仕事は、プロジェクト計画書に沿って進められるものであ

その大項目は、メンバーとの日常会話にも頻出するくらいな

じみ深いものだからだ。例えば、本社と全支店の社内

LANを再構築するプロジェクトに携わる場合、次のような

プロジェクト計画書の流れに従って検索キーを設定すると

アーキテクトの仕事では、膨大な量の情報が必要となる。技術関連の情報は

もちろん、ITとビジネスとのかかわりが密接になっている昨今、業務知識や経

営用語といった情報の収集も不可欠だ。ただし、いかなる情報も収集するだ

けでは意味がない。集めた情報は、適切に分類したり、加工したりしておくこ

とで初めて、必要なときに役立つ“ツール”となるのである。本パートでは、大

量の情報を使えるかたちに処理／整理し、管理する方法を紹介しよう。

金子則彦 Norihiko Kaneko

コスモコンサルティング代表取締役

大量の情報を“使えるかたち”に整理し、

管理する方法を身に付ける

情報整理術Part 1

7/22/2019 IT Vol.13 00.pdf



［

特

集

3

］

よい。

①プロジェクトの背景／目的

②スケジュール／予算

③WBS（Work Breakdown Structure）

④本社／各支社ネットワーク構成図

⑤検討すべき技術

⑥制約条件／リスク

⑦問題点一覧と解決策⑧議事録

⑨教訓（Lessons Learned）

プロジェクトのプロセス設計などと同様、情報整理にお

いても、計画や将来の見通しが重要なポイントになる。そ

れらをうまくできるようになるには、経験を積むしかない。検

索キーの設定1つをとっても、失敗を重ねながら少しずつ

進歩していくものだと考えていただきたい。

整理とは「階層化」すること検索キーが決まったら、後は目の前にある情報をその

キーに従って分類するだけである。ただし、まだ問題はあ

る。それは分類後の情報量の差だ。例えば、前節で挙

げた「⑤検討すべき技術」に分類された情報量が、他の

情報量の4倍あったとしたら、それは多すぎる。そうした場

合は、図1のように内訳を作るとよい。

結局のところ、情報整理とは、「情報の階層化」であ

る。情報を階層化しておくことで、検索時間の短縮を図る

のだ。階層化する際は、最下層にある情報量が均等に

なるように、階層構造を決めていく（図2）。

整理／検索にかかる時間の

バランスをとる

こうした情報整理の作業は、だれしも手短に済ませた

いだろう。しかし、時間をかけてしっかりと整理しておいた

ほうが、検索は素早く行える。情報の整理具合と、検索

に要する時間の関係をグラフに表したのが図3だ。A点の

項目については、ほとんど整理していないので検索に手間取る。逆に、B点の項目は十分に整理してあるが、検

索頻度が少なければ無駄な整理に時間をかけたことに

なってしまう。

理想的なバランスは、整理時間と検索時間の合計値

が極小化するポイント（C点）である。ほどよく整理されてお

り、検索時間も比較的短くなる。いわゆる“程々”の折り合

いがつく地点だ。

とは言え、これはあくまでもイメージであり、実際にこれら

の時間を克明に記録し、最適解を見つけ出そうというの

は非現実的な話だ。その記録に余分な時間がかかること

になる。ある程度は経験から憶測もできるが、最後は直感

日々飛び交う情報には、口頭でやり取り

されるものも多い。その内容は、「ちょっと○

○をやっておいて」という軽い依頼から、「×

×支社の建物のパイプ・スペースはいっぱ

いだから、LANケーブルの追加は無理だよ」

といった重要な情報までさまざまだ。口頭

で得た情報は、忙殺されているうちに忘れ

てしまう危険性が高いため、できるだけ電子

メールで文書化してもらうようにしたい。相

手にメール送信を頼むのが難しければ、覚

え書きとして自分で自分にメールを出しても

よい。メールならば、毎日チェックするからだ。

また、会議などで入手した資料には、入

手元や日付、時刻、枚数などを最初の

ページに記入し、ファイルにとじておく。

口頭情報の記録／入手資料の整理

図1：項目の内訳

5.検討すべき技術

5-①IEEE802.11n

5-②PLC（Power Line Communication）

5-③10GBASE-R

5-④検疫VLAN

図2：情報の階層化

部分

部分

部分

部分

部分

部分

部分

部分

部分

部分

部分

部分

全体

最下層の情報量が、大体同じになるようにする

部分部分部分部分

図3:情報の整理具合と、検索に要する時間の関係

部分

整理の完璧さ

A

C

検索時間整理時間合計時間

B

整理不足整理しすぎ

7/22/2019 IT Vol.13 00.pdf



効

率

良

く

作

業

す

る

た

め

の

ノ

ウ

ハ

ウ

を

伝

授

!

ア

ー

キ

テク

ト

の

仕

事

術

に頼らざるをえず、ここに情報整理の難しさがある※1。

なお、検索時間を考える際には、「検索準備時間」が

あることを覚えておいてほしい。例えば、検索したい情報

が遠隔地の倉庫にある場合、検索以前に情報を宅配

便などで送付してもらう必要がある。また、検索したい情

報が会社の机の中にあるとしても、仕事を中断して帰宅し

て翌日に再開するならば、手仕舞い時間／再開準備時

間が発生する※2。ささいなことのようだが、意外と時間をと

られる部分なので注意されたい。

紙媒体情報の整理

紙媒体に記された情報の整理は、机の上で行うのが

基本である。検索キーごとに分類しながら、書類を積み

重ねていく。分類が完了したら、そのまま仕事を開始しても

よいが、いったん所定の位置に格納してみるとよい。所定

の位置とは、キャビネットや本棚のような、ふだん紙媒体

の情報をしまっている場所である。

筆者は、「リングファイル」に紙をとじ込み、それを本棚に格納している。このファイルが便利なのは、ファイルの中

ほどにある書類をワンタッチで取り出すといった、いわゆる

“ランダム・アクセス”が可能な点だ。検索キーごとに分類

した紙媒体情報は、各キーの1ページ目にカラー・コピー

用紙などを使って仕切りとし、さらにインデックス・シールを

はる。原始的だと思われるかもしれないが、これが最も簡

単で効果的な方法なのだ※3。

人によっては、情報を格納したファイルが何冊も出来上

がるかもしれないが、まずは冊数を気にせずに作ってみよう。

多くなりすぎた場合は、その中から厳選して頻繁に利用す

る1冊を決める。これにより、会議にも1 冊のファイルを持っ

ていけば事足りるようになる。

後は、付箋を貼ったり、書き込みをしたりして、随時情

報を補完していけばよい。なお、プロジェクトの途中で計

画変更が発生し、検索キーに該当する項目が変わってし

まった場合は、迷わずファイルも再編成しよう。

磁気媒体情報の整理

磁気媒体情報の整理方法は、基本的に紙媒体情

報の場合と同じである。検索キーとなる項目をフォルダとし

て作成し、そこにファイルを格納していくイメージだ。検索

ツールの利用を前提にすれば、気楽に分類できるだろう

（検索ツールについては後述する）。ただし、フォルダや

ファイルの名前は、意識的にキーワードを入れて長めにし

ておく。これは、検索時のヒット率を上げるためだ。

問題解決のための

情報整理

続いて、解決すべき問題に立ち向かっていくうえでの情

報整理の方法について考えてみよう。アーキテクトは、採

用候補となる技術に関するさまざまな情報の中からポイン

を押さえ、実現可能なことと不可能なことを見極めねばな

らない。そのうえで、可能なことについては、それを実行す

る際の条件（予算や期間など）を的確かつ迅速に判定す

ることが求められる。ここでは、限られた時間の中で、効率

良く情報を検索／処理する方法を紹介しよう。

検討すべき材料の絞り込み

「解決すべき問題は何か」をはっきりさせずに、ただ漠

然と考えを巡らしていても、時間が刻と々過ぎていくだけだ

※1 ただし、大抵の人は情報整理にかける時間が少なく、図3の左半分に位

置する。

※2 製造業における「段取り工数」や「切り替え時間」などに当たる。

※3 筆者の場合、この作業をすることで頭の中が整理され、スッキリとした気

持ちになるためやっているところもある。

プロジェクト全体や、チームごとの情報

整理を行う際には、「情報共有」の考え方

が必要になる。そのため、検索キーとなる

項目名は、プロジェクトに関係するメンバー

全員で協議して決めなければならない。そ

して、ファイルの管理は担当者を決めて行

うようにしたい。理想的なイメージは、小さ

なプロジェクト専用の“図書館”を作り上げる

ことだ。

また、この場合、磁気媒体情報の管理

には何らかの構成管理ソフトによるバージ

ン管理が必要になる。情報共有ツールとし

て、電子掲示板やブログなどが必要となる

ケースもあるだろう。状況に応じ、使いやす

いツールを探すとよい。

プロジェクト全体の情報整理

7/22/2019 IT Vol.13 00.pdf



［

特

集

3

］


これでは、いくら時間があっても足りない。問題点を一覧に

してみる方法もあるが、単に個条書きにするだけでは、か

えって問題の核心部分が不明確になりやすい。そこで、

筆者が実践しているのが次の方法だ。

1つのプロジェクトが終わったら、完了報告書を作成す

るだろう。この完了報告書を、プロジェクト初期の段階か

ら書き始めておく。「いずれは作成しなければならないのだ

から」という理由もあるが、「プロジェクトを成功させるための要件」を明確にする方法としても有効なのだ。

例えば、「全支店にPLCを導入したことで、LANケー

ブルがなくなった。PLCを導入できたのは、○○の要件を

整備したからだ」といった内容を、先に書いてしまう。こう

すれば、PLCを導入するためには「○○」の部分を明確

にしなければならなくなる。

また、「本当に全支店にPLCを導入できるのか」という

疑問もわいてくるので、「その辺りにポイントがあるな」と思

い至る。このように、解決すべき課題（仮説）を完了報告

書に設定しながら、必要な情報を明確にしていくのである。

成功するためのイメージ作りの一環だと思えばよい。

検索ツールの利用

考えるべきことが明確になったら、まずは手持ちの資料

から解決の糸口を探す。ファイルに整理した紙媒体情報

や、PCの中に保存した磁気媒体情報から探索すればよ

い。漠然と「こんな情報あったかな」といった程度の記憶

しかなければ、磁気媒体情報を検索したほうが早いだろう。ただし、すでに検索キーが頭の中に浮かんでいれば、

紙媒体情報を検索するほうが素早く欲しい情報にたどり

着ける。こうした意味では、磁気媒体情報も印刷してファ

イルにとじておくとよいと言える。

磁気媒体情報を検索する際には、OSに付属する検索

機能を使うのが手軽で便利だ。しかし、その場合、Word

やExcelファイル内の字句まで探索しようとすると非常に時

間がかかる。やはり、専用の検索ツールを利用したほうが

効率が良い。商用製品のほか、フリーウェアの全文検索

ツールにも「Googleデスクトップ」（http://desktop.goo

gle.com/ja/）や「探三郎」（http://www.geocities.jp

/koutarou_y1926/）などさまざまなものがあるので、自分

の使い勝手の良いものを探すとよいだろう。検索の結果、手持ちの資料に欲しい情報がなければ、

大抵、GoogleやYahoo!などのサーチ・エンジンを使って

調べることになる。ただし、サーチ・エンジンにはそれぞれ

得意／不得意分野があるため、できれば用途に応じて

複数のサーチ・エンジンを使い分けたい。筆者は、複数

のサーチ・エンジンを効率良く調べてくれる「Copernic」

（http://www.copernic.co.jp/）というツールを利用して

いる。同ツールは、入力したキーワードを複数のサーチ・

エンジンに渡し、その結果を検索頻度の高い順に並べて

表示してくれるというものだ（図4）。

また、複数の図書館から横断的に文献の情報を調べ

たい場合は、「本の検索」（http://softwares.jukusei.

com/BooksSearch/）というフリーの検索ツールが便利

である。

“わからないこと”の明確化

さまざまな情報を検索しているうちに頭の中がゴチャゴ

チャしてきて、「自分が何をわかっているのか／わかっていないのか」が把握できなくなることがあるだろう。そうした場

合、わかっていることを個条書きにしてみるとよい。さらに、

わからないことを書き出して、「今いちばんわからないことは

何なのか」を見極める。これが明確になっていないと、調

べることも、だれかに質問することもできない。当たり前のよ

うに感じられるかもしれないが、技術者向けWebサイトの

掲示板などでは、こうした整理もできていないまま質問を投

げかけている人をよく見かける。

筆者は、わからないことを明確にしたい場合、図を描くこ

とにしている。ごく単純なことなので説明するのも気恥ずか

しいが、単純すぎてこの便利さに気づいてない方もいるか

もしれないので、あえて紹介しよう。

まず、A4版以上の白紙の中央に、わからないことや疑

問に思っていることを書いて四角で囲む。次に、その疑問

に関することで思いついた内容ならば何でも、ためらわず

図4：Copernicの仕組み

Copernic

結果表示キーワード入力

Google Yahoo! Fresh eye

7/22/2019 IT Vol.13 00.pdf



効

率

良

く

作

業

す

る

た

め

の

ノ

ウ

ハ

ウ

を

伝

授

!

ア

ー

キ

テク

ト

の

仕

事

術

に書いて丸で囲み、線でつなぐ（図 5）。他人が見たら関

連性がないように見えることでも、思いつきをすべて書くこと

がポイントだ。自分さえわかればよいので、丁寧に書く必要

もない。何も思いつかずに「困ったな」と思ったら、それも書

く。その次に「なぜ困っているのか」と考えたなら、「なぜ

困っている？」と書く。いわば、思考の口述筆記※4 のような

ものだ。これを繰り返すうちに、わからないことが明確になっ

たり、「わからないことがわからないのは、何がネックとなっているのか」がわかったりするのである。

類似情報の比較

わからないことが明確になったら、再度、情報の収集

／整理を行う。調べるべきテーマは決まっているので、それ

をキーワードにして検索ツールを活用すればよいだろう。

このとき、情報源は2つ以上用意する。これには、情報

の信頼性をチェックする目的もあるが、「2つ以上の情報

を比較検討してより深く考えるため」というところが大きい。

人間は、何かを考える際、2つ以上の情報を比較して思

考する。通常は、1つの情報を見て、自分の頭の中にある

情報と比較するのだが、よくわからないことについて考えよう

としている場合は、自分の頭の中のどの情報と比較してよ

いのかわからず、混乱してしまう。そこで、2つ以上の情報

源からの情報を用意するわけだ。

具体的に考えてみよう。テーマが同じ書籍を2冊買っ

てきたとする。これで、2つの情報源を入手したことになる。

両者の情報は、図6のようなマトリクスに分類できる。

例えば、同じトピックについて同じ結論が書いてあれば、それはAの領域に分類されるが、これはその分野における

常識だと考えてよいだろう。違うトピックについて同じ結論

が出るとは考えにくいので、情報がCの領域に分類される

ことはあまりない。Dの領域に分類される情報には、著者

の個性が出ている。いちばんのポイントは、「同じトピックで

違う結論が出ている」Bの領域にある。これは、結論に

“幅”があるということを意味しており、ほかの見解もありうる

のだと考えられる。そこで、このトピックについて自分なりの

仮説を立て、それを専門家にぶつける。これにより、最終

的な結論を導き出すのである。

「デルファイ法」の利用

専門家に質問しても要領を得ず、結論が得られない

場合は、「デルファイ法」を使ってさらに情報整理をすると

よい。

デルファイ法では、ある問題に対する見解を、進行役

が質問書を使って専門家に尋ねる。専門家は、これに

回答する。進行役は、専門家から得た回答を他の専門家に配布し、それに対する見解を得る。この作業を数回

繰り返すことで、最終的な見解をまとめるのである。

ポイントは、複数の専門家の意見を相互に開示させな

がら、結論を収束させていく部分にある。実践する際は

自らが進行役になり、自分の意見を質問書にして回付を

繰り返せばよい。

今後に備える

情報整理最後に、「今は必要ないが、今後のために収集してお

く」といった類の情報の整理方法について考えてみよう。

図5：“わからないこと”を整理して明確にする

802.11nの製品の互換性は？

ドラフト版と正式版

MIMOは1つ？ Intel用のノートPC用チップ

バッファローWZR-G144 N/P

ほとんど違いなし

ドラフト版準拠？

図6：情報のマトリクス

トピック

同じ違う

結論

同じ

違う

A

B

C

D

※4 今はやりの「マインドマップ」に似ているかもしれないが、筆者は特にマイ

ドマップを意識して実践しているわけではない。

7/22/2019 IT Vol.13 00.pdf



［

特

集

3

］


アーキテクトは、その立場上、重要な新技術や法律の

改正点といったIT／ビジネスのトレンドに敏感にならざるを

えない。以降では、トレンドを正しくとらえるために必要な

“方向感”を形成するための指針について説明する。

情報の陳腐化

情報が陳腐化するスピードは、日増しに速くなっている。今日得た情報が半年後に有効であるという保証はない。

そのため、「今後のための情報」をスクラップ・ブックなど

の紙媒体で蓄積しておくのは無意味になっている。

筆者自身、2000年以前にはスクラップブックを作成して

いたが、情報の更新が頻繁になるにつれて再整理にか

かる時間が膨大となり、やめてしまった。時系列に紙媒体

情報を蓄積するだけの方法もあるが、半年以上前の情

報になると記憶が薄れ、いつごろの情報だったかを思い

出せなくなってしまう。

現実的にできる方法としては、Excelなどにテーマや情

報源、日付といったデータを入力しておき、必要なときに

検索ツールで検索することだろう。「Webサイト上の情報

の場合、サイトが移動／更新されてしまうかもしれず、UR

Lを残しておくだけでは心配だ」というのであれば、Webサ

イト上のデータをそのままPCに格納するようなツールを利用

すればよい。こちらも、検索ツールと同様、さまざまなフリー

ウェアが存在する。

ただし、RFIDの普及が進み、紙媒体情報にRFIDタ

グを付けて管理することが容易にできるようになれば、再び

スクラップブックなどを使った情報整理が有用になるかもし

れない。筆者は、RFIDを利用して、図 7のような紙媒体

情報の整理／検索の流れが実現されることを夢見ている。

トレンドの探求

「今後のための情報」だとは言え、Excelなどにデータ

を記録する手間を考えると、やみくもに収集するわけにはい

かない。したがって、集める情報のテーマを選定する必要

がある。

まずは、社内のトレンドに注目する。経営計画や社長

の年頭所感など、会社の方向性を示すものは情報収集

のテーマにふさわしい。例えば、日本版SOX法や内部統

制といったテーマならば、どこの企業でも今、少なからず

注目しているトレンドだろう。

次に、社外に目を向け、世間一般のトレンドを概観す

る※5。世間一般のトレンドとは、雑誌やWebサイトなどでよ

く見かけるテーマのことである。定量的にとらえたいのであ

れば、IT系の製品展示会などで、出展している企業数

の多いテーマや、展示面積の広いテーマを探すとよい。で

きれば、実際に展示会に足を運んで各テーマへの人の集

まり具合を見ると、トレンドの判断に大いに役に立つ。なお、展示会で配布されたパンフレットなどの資料は、そのまま

袋に入れておけばよい。必要になったときに、その袋から

探せば十分に間に合う。

＊＊＊

以上、本パートでは、アーキテクトを取り巻く膨大な量

の情報を使えるかたちに整理／管理する方法を紹介した。

情報の管理方法については、人によってやりやすい／や

りにくい手法があり、一概に「これが最適解だ」と言うこと

はできない。だが、どのような方法をとるにせよ、漫然と整

理するのではなく、何らかの方針を持って行うことが肝要

である。本稿の内容が、読者が情報管理を考える際の

一助となれば幸いだ。

※5 世間一般のトレンドは、やがて社内のトレンドになることも多い。

図7：筆者が夢見る、RFIDによる情報の整理／検索

格納場所に行き、携帯端末を使って必要な紙媒体情報を探す

携帯端末に、特定したRFIDタグをコピーする

Excel上でキーワード検索することにより、RFIDタグを特定する

ExcelにキーワードとRFIDタグを入力する

RFIDタグが付いた紙媒体情報は、本棚や倉庫に無造作に格納する

紙媒体情報にRFIDタグを付ける

7/22/2019 IT Vol.13 00.pdf



効

率

良

く

作

業

す

る

た

め

の

ノ

ウ

ハ

ウ

を

伝

授

!

ア

ー

キ

テク

ト

の

仕

事

術

時間管理の重要性

アーキテクチャ設計に取り組みつつ、一方で開発標

準の策定に追われ、さらにはさまざまなステークホルダーと

のコミュニケーションをこなすアーキテクトの毎日は、どうして

も多忙になりがちだ。時間の有効活用は、すべてのアー

キテクトに共通の課題だと言っても過言ではないだろう。

この課題を解決するために有効な方法が「時間管

理」だ。時間管理とは、自分がやるべきタスクを忘れないように管理することであると同時に、それを適切なタイミング

で完了させられるように事前に計画を立てることでもある。

もっとも、それだけなら、すでに読者もプロジェクト単位の計

画立案や進捗管理の一環として実践しているだろう。し

かし、自分が手がける仕事の進捗管理をするだけでは、

時間管理を実践しているとは言えない。

時間管理において注目すべきは、自分自身が持つ“時

間リソース”である。自分が行うべきタスクや、こなすべき予

定をスケジュールに落とし込むだけでなく、その結果として、

自分の時間リソース（自分が使える時間）が不足しないよ

うに調整することが時間管理の目的なのだ。「仕事に追

われてストレスを感じる」とか、「納期間際にはいつもバタ

バタしてしまう」といった問題は、多くの場合、時間リソー

スの管理ができていないことに起因する。

このように、時間管理はプロジェクトごとの進捗管理な

どとはやや次元の異なるものである。たとえ個の々プロジェ

クトにおいて最善のスケジューリングを行ったとしても、自分

の時間リソースが管理できていなければ意味がない。アー

キテクトにとって、自分の時間を管理することは非常に重

要なスキルであり、決して軽んじてはならないのである。

時間管理の実情

時間管理は、自分のスケジュールを破綻させないために不可欠であり、時間をより有効に使うという意味でも重

要な作業である。今、その必要性は改めて認識されつつ

あり、時間の活用法に言及した書籍や雑誌記事なども

数多く出ている。

その一方で、時間管理を実践している人はいまだに驚

くほど少ない。例えば、筆者がビジネスマンを対象にして

行った時間管理に関するアンケートでは、「時間管理が

あまりできていない」、「全然できていない」という回答が全

体の7割を超え、「うまくできている」と答えた人はわずか

7％にすぎなかった（次ページの図 1）。時間管理の意識

は高まりつつあるにもかかわらず、実際に行っている人は

非常に少ないというわけだ。

時間管理の不備が招く問題

時間管理ができていないと、さまざまな問題が起こる

プロジェクトの遂行中、突然の会議や顧客からの呼び出し、問い合わせの電

話／メール対応などといった細かな用事が次々と入ってしまい、なかなか本来

の仕事が片付かないのはよくあることだ。アーキテクトには、そうした環境の中

でも忙殺されずに効率良く作業をこなし、さらに“＋α”の成果を上げることが

求められる。そこで本パートでは、多忙なアーキテクトが限られた時間を有効

に使うためのノウハウについて解説する。

水口和彦 Kazuhiko Mizuguchi

ビズアーク時間管理術研究所代表

限られた“時間リソース”を活用し、

作業効率を上げるために

時間管理術Part 2

7/22/2019 IT Vol.13 00.pdf



［

特

集

3

］

わかりやすい例としては、ダブル・ブッキングが挙げられる。

これは、先のスケジュールをきちんと把握していないために、

先約のある時間枠に新しい約束を入れてしまうために起き

るトラブルだ。ただし、ダブル・ブッキングを回避するのは

難しいことではない。アポイントメントに関する情報を1カ所に

まとめ、新しい約束をするときは必ずそれを参照するように

するだけだ。こうしたスケジュール管理はごく一般的なもの

であり、実践している人も多いだろう。

しかし、スケジュールを破綻させてしまう人の中には、無

意識的にダブル・ブッキングに似た行動をとっているケー

スがある。例えば、何らかのプロジェクトにアサインされた

場合、大抵の人はまず自分の担当タスクを確認し、割り

当てられたリード・タイム（実施期間）とタスクの内容を見て、

自分にできるかどうかを判断するだろう。ここで平行して別

の作業を依頼された場合、同じ要領で実現の可否を考

え、判断する。だが、1つ1つを考えたときは十分可能だと判断した作業量が、複数重なったために許容量を超え、

予定どおりこなせなくなるというのはよくあることだ。

きちんと計画したつもりでも、予定外の作業が重なれば、

時間リソースは不足する。そうした状況が続けば、いずれ

スケジュールが破綻するのは当然のことである。だがその

場合、スケジュールが破綻した原因は、運悪く作業が重

なったことにではなく、危機的状況に気づかなかったこと、

つまり問題に気づかずに対応が遅れたことにあるのだ。

作業が重なり、自分の時間リソースが不足することがあらかじめ予測できれば、支障の少ないタスクをカットしたり、

ほかの人に任せたりすることで、スケジュールの破綻を回

避できる。しかし、時間管理をおろそかにしているとリソース

不足に気づくのが遅れ、必ず対応が後手に回ってしまう

のである。

時間管理が定着しない理由

筆者は、日ごろ時間管理に関するセミナーや研修を実

施している。その参加者の声に耳を傾けてみると、これま

で時間管理が身に付かなかった人は、おおむね次の2つ

のタイプに分けられる。

1つは、「時間管理をやったほうがよいとは思うが、なか

なか踏み出せない」というタイプだ。このタイプの人は、「時

間管理には手間がかかる」とか、「予定外の仕事が発生

することが多いので、計画は立てるだけ無駄だ」といった

先入観を抱いていることが多い。確かに、世間で時間管

理手法として紹介されているものの中には手間がかかるも

のもある。だが本来、時間管理は手間をかけずに実践することが可能であり、高度なスキルも特に必要ないもの

時間管理と聞くと、「何時から何時まで

の間に、このタスクをやる」といった学生の

時間割のような計画を立てることだと考え

る人も多い。しかし、時間ごとにタスクを割

り振っていく方法では、タスクの実行時間

が予定とずれたり、予定外の仕事が発生し

たりすると、計画を立て直すはめになり、手間がかかるのでお勧めできない。

タスク管理と時間リソースの管理を両立

させるためには、タスクと時間とをもう少し

緩やかに連携させる必要がある。タスク管

理には、「To Doリスト」と呼ばれるリストを使

う方法があるが、To Doリストでは、各タスク

が自分の時間リソースに与える影響を直感

的に把握するのが難しい（図A）。そこで、To

Doリストではただタスクを並べるのではなく、

その実行日を決めて、日付別に分けておくとよい（図 B）。実行日ごとに分けることで、各

タスクが自分の時間リソースに与えるイン

パクトを実感できるようになるのである。

「時間割」は作るな

図1：ビジネスマン100人へのアンケート｢あなたは時間管理をうまくできていると

思いますか？｣という質問に対する回答

42％

21％

7％

30％

まあまあできている

できている

あまりできていない

全然できていない

図A：一般的なTo Doリスト

・C社の提案内容を課長に報告する

・C社のプレゼンテーション内容の確定

・B社用の資料作成

・○○のコーディングを完了させる

・C社用のプレゼンテーション資料を作成

・C社用提案資料をチェック／修正指示を出す

・××の進捗状況を確認

・D社△△氏にメールを出す

・C社用プレゼンテーションの最終確認

・C社用の提案書最終確認

・A社○×氏に電話をする

図B：タスクを日付ごとにまとめる

10/15

Mon

□C社の提案内容を課長に報告する□C社のプレゼンテーション内容の確定□B社用の資料作成

10/16

Tue

□○○のコーディングを完了させる□C社用のプレゼンテーション資料を作成□C社用提案資料をチェック／修正指示を出す

10/17

Wed

□××の進捗状況を確認□D社△△氏にメールを出す

10/18

Thu

□C社用プレゼンテーションの最終確認

10/19

Fri

□C社用の提案書最終確認□A社○×氏に電話をする

7/22/2019 IT Vol.13 00.pdf



効

率

良

く

作

業

す

る

た

め

の

ノ

ウ

ハ

ウ

を

伝

授

!

ア

ー

キ

テク

ト

の

仕

事

術

だ。

また、予定外の仕事が発生することが多ければ、確か

にスケジュールを頻繁に変更することになる。しかし、だか

らと言って時間管理が不要なわけではない。むしろ予定

外の仕事が発生しやすい人ほど、タスクを整理して時間

リソースを管理していなければ、混乱を招く危険性が高

いのである。

もう1つのタイプは、「過去に時間管理を実践してみたが、継続できなかった」というタイプである。このタイプの人

は、時間管理がうまくいかない原因は、自分の能力不足

にあると考えてしまいがちだ。だが、実際には実践した時

間管理の手法自体に問題があるケースがほとんどである。

例えば、よく紹介されている手法に、「タスクに優先順位

を付け、それに従って実行する」というものがあるが、この

手法には大きな“落とし穴”があるのだ。

順位付けの“落とし穴”

優先順位に従ってタスクを実行する場合、より重要な、

もしくは緊急のタスクから先に処理することになる。この「重

要なものや緊急のものから先に実行する」という考え方自

体は、もちろん間違いではない。また、忙しい日は重要性

／緊急性の低いタスクを先送りするというのも、一見合理

的に見える。ただし、このやり方では、多忙な日々が続くと

先送りされたタスクがたまっていくため、どこかで必ずスケ

ジュールの破綻を招くことになるのだ。

優先順位を付けてタスクを処理していると、先送りした

タスクがたまって初めて、スケジュール破綻の危険性に気づく。個人の時間リソースは、言うまでもなく有限であり、

残業時間を含めた自分の時間リソースを超えた仕事をす

ることはできない。そういう意味で「できない仕事」には、で

きるだけ早く、何らかの手を打つ方法があるのだが、優先

順位を付ける方法では、その判断を確実に遅らせてしまう

のである※1。

時間管理の実践

それでは、手間や時間をできるだけかけずに、効果的

に時間管理を行うにはどうすればよいのだろうか。

時間管理ができないと感じている人、やったことがない

人でも、すでに何らかの時間管理は必ず頭の中で行って

いる。例えば、納期に間に合うように仕事を進めようと考え

ていれば、その仕事の納期から逆算していつまでに何を

やればよいかを考えるだろう。また、もっと小さな規模で言

えば、出勤時に「今日は何と何の作業をやるべきか」と考

え、それをその日1日の時間リソースにどう割り振るかを考えることもあるはずだ。いわゆる「段取り」である。こうした段

取りを系統立てて行うことが時間管理なのだ。

だが、段取りを頭の中だけで行っていると、全体像が

把握しきれず、タスクが重なったときに混乱したり、忘れて

しまったりといった問題が起きる。逆に言えば、頭の中でな

く頭の外で、ツールなどを使って一元管理すれば、時間

管理は難しいことではない。

時間管理は情報整理の一種

「頭の中でイメージしている段取りや、その日やるべきタ

スクを書き出して整理する」という意味では、「時間管理

は情報整理の一種だ」と言える。そして、時間管理を実

行しにくい、継続できないと感じる原因の多くは、情報を

整理するツールの使い勝手の悪さにある。必要な情報を

シンプルにまとめられれば、本来、時間管理に手間はかか

らない。

時間管理に必要な情報時間管理を実践するために必要な情報は、表 1に示

すとおりだ。まず必要となるのが、アポイントメントとタスクに

関する情報である。一般的に、アポイントメントとは面会の

約束などを指すが、ここでは「時間が指定されている仕

事」はすべてアポイントメントに含める。例えば、会議や打

ち合わせの約束、そのための移動時間についても、時間

を決めて行動する必要があるため、アポイントメントと見な

※1 破綻の前兆に気づくのが遅ければ遅いほど、対処は難しくなる。例えば

仕事を断ったり、ほかの人に頼んだりするにしても、締め切りの直前では断りに

いし、頼みにくい。

表1：情報管理を実践するために必要な情報

情報の種類説明例

アポイントメント実行時間が指定されている仕事会議や打ち合わせ、移動時間など

タスク実行時間が指定されていない仕事コーディングやメンバーへの指示出し、連絡など

アクティビティ複数のタスクが組み合わさった仕事プロジェクト提案書の作成など

その他人／組織の動静やイベントなどの情報上司の出張予定など

7/22/2019 IT Vol.13 00.pdf



［

特

集

3

］

す。一方、タスクとは「時間が指定されていない仕事」の

こととし、アポイントメントに含まれない仕事はすべてタスクと

して扱う。

「スケジュール管理」と「時間管理」の違いは、前者は

アポイントメントのみを管理するのに対し、後者はアポイント

メントとタスクの両方を管理する点にあると言える。時間指

定の有無という違いはあるが、どちらも時間リソースを消費

するため、時間管理の観点から言えばこれらを両方とも管理しなければならない。

このほかにも、整理しておくべき情報がある。これを筆

者は、「アクティビティ」と呼んでいる。アクティビティをひと言

で説明すると、「大きなタスク」である。実行に2日以上か

かるような大掛かりな作業だと考えていただけばよいだろう。

例えば、「提案書を作成する」という作業を完了させる

には、顧客にヒアリングしたり、関連する技術を調査したり

といったさまざまな行動が必要となる。そのため、どの程度

の時間リソースが必要なのかも想像しにくい。そこで、まず

はアクティビティとしてとらえて日程を考え、次にそのアクティ

ビティを達成するために必要な作業を具体的なタスクとし

て並べていくという2段構えの整理が必要になる。

さらにもう1つ、整理しておいたほうがよい情報がある。

それは、自分が業務上関係する人／組織に関する予定

やイベントの情報などだ。仕事の段取りは、自分の都合

だけを考えればよいというものではない。例えば、上司の

承認や決済をもらわなければならないタスクと、上司の出

張とが重なれば、結果的にタスクの実行タイミングが遅

れてしまう。また、プロジェクト・メンバーに仕事を頼みた

い日と、そのメンバーの休暇とが重なってしまえば、やはり

タスクの実行が遅れることになる。こうした事態を回避す

るために、周囲の人や組織の情報をできる限りツール上

に集約させておけば、より効率的な計画を立てられるよ

うになる。

時間情報の整理方法

時間管理に必要な情報は、1カ所に集約させる。情報

が分散していると、ちょっとした変更がある度にあちこちを

参照しなければならず、手間がかかるだけでなく、ミスも生

じやすい。そこで、情報を一元管理するためのフォーマット

として筆者が提唱しているのが、FITT（Flow & Inform

ation/Task/Time）フォーマットだ（図 2）。図2のように、

アポイントメントは開始時間だけでなく、所要時間も線など

で明示するとよい。これにより、各アポイントメントで使用す

る時間リソースの量がイメージしやすくなるだけでなく、空い

ている時間を視覚化することもできる。

また、タスクは日付別の欄に記入しておく。このとき、タ

スクは各タスクの終了期限ではなく、そのタスクの実行予

定日に記入することに注意されたい。終了期限日に記入

していると、それをずらさなければならないときには、スケ

ジュールの破綻は免れなくなっているからだ。

アクティビティや人、イベントの情報は、タスク／アポイン

トメントとは欄を分ける。これは、実際に時間リソースを使


図2：FITT（Flow & Information/Task/Time）フォーマット

10/15

Mon

8

13

12

11

10

9

8

13

12

11

10

9

8

13

12

11

10

9

□C社の提案内容を課長に報告する□C社のプレゼンテーション内容の確

定□B社用の資料作成□○○のコーディングを完了させる

10/16

Tue

□C社用のプレゼンテーション資料を作成

□C社用提案資料をチェック／修正指示を出す

□××の進歩状況を確認

10/17

Wed

□D社△△氏にメールを出す

C社向けプレゼンテーション準備

○×報告会議

○○君休み

10：25△△ミーティング

9：55

9：30

課内ミーティング（B社案件）

11：00

11：30

移動

B社打ち合わせ

移動

「Flow & Information」

アクティビティの流れや、ほかの人の予定などを記入する

「Time」

アポイントメントを記入する。でき

れば、タスクの実行時間も記入しておく

「Task」

自分のタスクを記入する。終わったものにはチェックを入れる

7/22/2019 IT Vol.13 00.pdf



効

率

良

く

作

業

す

る

た

め

の

ノ

ウ

ハ

ウ

を

伝

授

!

ア

ー

キ

テク

ト

の

仕

事

術

用するタスク／アポイントメントの情報と、段取りを決める

過程で必要なアクティビティなどの情報を分けることで、管

理をしやすくするためだ。

横の視点／縦の視点

図2のようなかたちにまとめられた予定表は、横方向に

見ると仕事の流れを把握できる。このように、「どのタスクを

いつ実行するのか」をチェックするのが「横の視点」であ

る。一方、「縦の視点」で見た場合、日ごとのアポイントメ

ント／タスクを確認することができる。その日1日で予定され

ているアポイントメント／タスクを確認し、こなせるかどうかを判断するのがこの縦の視点である（図3）。

横の視点（仕事の流れ／段取り）と縦の視点（その日

にやるべきすべての仕事）は、ふだんからだれもが頭の中

で漠然と考えていることを具体化したものにすぎない。しか

し、頭の中では、2つの視点を同時に成立させて考えるの

が難しいため、こうした視覚化が時間管理を成功させる

近道となるのである。

なお、視覚化には、Outlookのようなスケジュール管理

ソフトなどを使用してもよいが、時間管理の秘訣はスケ

ジュールを「すぐに見られる」、「すぐに書き込める」ようにし

ておくことである。この点については、次節で説明しよう。

時間管理の秘訣

時間リソースの利用計画は、ツールへの情報追加を繰

り返すことによって作成する。このとき、新しいタスクやアポイ

ントメントが発生したら、その情報をすぐに書き留め、スケ

ジュールを常に最新の状態に保つよう心掛ける。後でまと

めて書こうとしたり、別の用紙にメモしておいたりというのは

あまりお勧めできない。書くのを忘れたり、メモを失くした

する可能性があるうえ、「後でまとめること」を覚えておくこと

自体、余分な負担になってしまうからだ。

そこで、意外に便利なのが紙（手帳）である。アナログ

だと思われるかもしれないが、これが実に効率が良いのだ

手帳を常に開いた状態にしておけば、1つのタスクやアポイ

ントメントを記入する時間は1分とかからない。これなら、タスクが発生する度に記入することもさして負担にならない

はずだ。

タスク／アポイントメントを1つずつ追加していくことにより

スケジュールの全体像が少しずつ作られていく。計画は

一度に立てようとするとそれ自体が負担になり、時間もとら

れるが、そのつど書き込んでいくスタイルであれば無理な

実行することができるはずだ※2。

なお、タスクやアポイントメントを記述する際に、注意す

べき点が1つある。それは、前述の「縦の視点」によって

予定を追加する日の時間リソースが足りるかどうかを確認

することだ。もし、新しいタスクを追加することで、その日の

時間リソースが不足しそうなのであれば、「この日にそのタ

※2 作業を行う際には、いつでもツールを見られる状態にしておくことも重要で

ある。これにより、次に何をやるべきか、未完了のタスクが残っていないかとい

たチェックも短時間で済む。

図3：横の視点と縦の視点

10/15

Mon

8

13

12

11

10

9

8

13

12

11

10

9

8

13

12

11

10

9

□C社の提案内容を課長に報告する□C社のプレゼンテーション内容の確定□B社用の資料作成□○○のコーディングを完了させる

10/16

Tue

□C社用のプレゼンテーション資料を作成□C社用提案資料をチェック／修正指示を出す□××の進歩状況を確認

10/17

Wed

□D社△△氏にメールを出す

C社向けプレゼンテーション準備

○×報告会議

○○君休み

10：25△△ミーティング

9：55

9：30

課内ミーティング（B社案件）

11：00

11：30

移動

B社打ち合わせ

移動

「横の視点」で仕事の流れと段取りを考える

「縦の視点」で1日の時間リソースが足りるかどうかを確認する

7/22/2019 IT Vol.13 00.pdf



［

特

集

3

］

スクはやらない」と判断するか、すでに当日予定されている

タスクを別の日にずらすといった対策をとる必要がある。当

たり前のことのようだが、こうした調整を怠ったために、時

間リソースが足りなくなってから慌てるハメになるケースは少

なくない。

管理しやすいスケジュールを作るコツ

前述のように、時間リソースの不足に注意しながら、タ

スク／アポイントメントを追加することでスケジュールは出来

上がる。ただし、予定には変更が付き物であり、それにうま

く対処できるかどうかが、時間管理のスキルの問われるとこ

ろだ。

以下に、管理しやすいスケジュールを作るためのポイント

を説明しよう。

●スケジュールは1週間単位で考える

スケジュールは、1週間程度を1つの単位として整理する

とよい。一般的な手帳や時間管理ツールには、1日ごとの

予定を管理するスタイルのものもあるが、それだと自分の時

間リソースの全体の流れがつかみにくくなり、ちょっとタスク

の実行日を変更するのにも手間がかかってしまう。

●空白の時間を作る

1日のうちにこなす業務の中には、タスクやアポイントメント

として意識的に管理している仕事以外に、スケジューリン

グするまでもないような小さな作業もあるはずだ。だが、そう

した小さな作業も、実行するのに多少の時間は要する。

これらの作業をタスクやアポイントメントの合間に片付けるためには、時間リソースの配分にある程度の余裕を持た

せておくことが必要である。

どの程度の余裕を持たせるかは、業務の内容などに

よって異なるため一概には言えない。ただし、アポイントメン

ト／タスクの実行に要した時間の記録をとることで、どのく

らいの予定を入れると、どのくらい時間リソースに余裕が残

るかを把握できるようになるので、それを基に調整するとよ

いだろう。

●情報を1カ所にまとめる

実行できなかったタスク、予定どおりの実行が難しくなり

そうなタスクは、「日程をずらす」とか、「ほかの人に頼む」、

「実行自体を取りやめる」といった判断をしなければならな

い。先述のように、スケジュールに関する情報が1カ所にま

とめてあれば、こうした場合にも判断に必要な情報をすぐ

に確認できるはずだ。

“こま切れ時間”の活用

1日の時間の中には、ちょっとした移動時間や、急な

キャンセルで発生した空き時間といった“こま切れ時間”が

あるはずだ。ただでさえ多忙なアーキテクトとしては、このこ

ま切れ時間を無視することはできない。

電車を待つ時間や、乗車中の時間などを有効に使う

には、日ごろからある程度の仕事道具を持ち歩くことが必要である。適当なものがなければ、新しい知識を習得する

ために読書をしてもよい。

また、会議の直前や、アポイントメントの直前などに、半

端な時間が空くことがあるだろう。だが、そうした不意の事

態に備えた仕事をわざわざ事前に用意しておくことには、

あまり意味がない。突然時間が空いた場合は、そのときに

できそうな仕事を少しでも進めるようにしたほうが効率が良

いはずだ。

ここで、ポイントが1つある。どんな仕事でも、いったん作

業を中断すると、再開するときには「どこまでやったか」、

「次はどこから始めればよいか」といった進捗状況を簡単

に忘れてしまい、それを思い出すのに多少の時間がかか

る。特に、こま切れ時間で仕事をしようというときに、この進

捗確認に時間がかかると実際の仕事がほとんど進められ

なくなってしまう。これを回避する方法は、各仕事の進捗

状況をこまめにメモしておき、それを参照すればすぐにわか

るようにしておくことである。

進捗状況のメモをとることは、不意に仕事が中断され

てしまうことが多い人にも有用なテクニックだ。「メモをとる」と言うと一見面倒なことように思えるが、わずかな手間を惜

しまなければ、作業の再開にかかる時間をかなり短縮でき

るはずだ※3。

チームの時間力を高める

複数のメンバーを束ねるような立場のアーキテクトが持

つ悩みの1つとして、「チーム全体の時間管理」が挙げら

れる。例えば、チーム・メンバーがそれぞれ複数の仕事を

抱えているような場合、なかには破綻寸前のスケジューリ

ングを行っているメンバーもいるだろう。だが、多忙を極め

るメンバーに、時間管理のメリットを理解／実践してもらう

※3 ただし、中断されないようにする工夫も必要である。例えば、電話による

連絡が必要な場合、先方からかかってくるのを待つのではなく、自分から電話し

てしまえば、自分の仕事が突然中断されることはない。同様に、上司への連絡

や報告なども、尋ねられる前に済ませてしまうに限る。


7/22/2019 IT Vol.13 00.pdf



効

率

良

く

作

業

す

る

た

め

の

ノ

ウ

ハ

ウ

を

伝

授

!

ア

ー

キ

テク

ト

の

仕

事

術

のはなかなか難しい。特に、「時間管理は手間がかか

る」などという思い込みがあればなおさらである。

チーム内に時間管理の意識を浸透させるには、時間

管理が仕事の能率向上に役立つことを強調するよりも、

仕事をうまく整理することで、仕事に追われるストレスの軽

減につながることを説くのが近道かもしれない。

また、時間管理に慣れていない人の場合、前掲の図2

のようなフォーマットを使用することには少なからず抵抗を

感じるかもしれない。これは大抵、「細かく記入しなければ

ならない」というプレッシャーを感じてしまうことに起因する。

そこで、心理的な抵抗感を軽減するために、週ごとのタス

ク欄だけを記入するように促すのも1つの手だ。

メンバーの時間管理能力を育てるために

時間管理の世界では、基本的に自分のことは自分で

管理するしかなく、自分で考えなければ意味がない。読

者が、ほかのメンバーのためにスケジュールを作って渡したとしても、それが忠実に実行されることは皆無だろう。予

定外のタスクが発生したりする中で、スケジュールをうまく

運用するためには、日ごろから自分の時間リソースについ

て考えるクセを付けることが必要なのである。

例えば、何らかのタスクをメンバーに任せる場合、その

メンバー自身にタスクの実行日を決めさせることが重要だ。

初めのうちは、メンバーが決めたタスク実行日をチェックし

たり、時間リソースが不足しそうな部分を指摘したりする必

要がある。また、進捗状況を確認する際には、最初に決

めたスケジュールを基本に、進み具合について本人にも

考えさせることが大切だ。タスクの実行にかかる時間は、

必ずしも見積もりどおりにいくとは限らない。だが、計画と実

績とを比較する機会を多く持つほど、見積もりの精度は上

がっていく。そこで、例えば週に1度、短い時間でかまわな

いので、そうした確認をする機会を設けるとよい。

「間に合うか」とは聞かない

メンバーに割り振ったタスクの進捗状況を確認するた

めに、「あの仕事の状況はどうだ？」とか、「納期に間に合

いそうか？」といった質問をすることは、あまり意味がない

ほとんどのメンバーは、多少の遅れについてはなかなか報

告しないものである※4。そのため、致命的な遅れが出始め

てからようやく報告することになる。しかし、そうなってしまっ

てからでは対応が難しいのは言うまでもない。

スケジュールの遅れを早い時点で把握することは、その

タスクを任されたメンバーのためでもある。そこで、「間に合

うか？」と聞くのではなく、「予定どおりにスタートできたか？」

という質問を投げかける。前者の質問には、「これからが

んばれば間に合うはず」という希望的観測の入った返事

をすることができるが、後者の質問の場合、「始められたか

どうか」という過去の実績について問われているので、事

実を答えるしかない（図 4）。そのため、より正確に状況を

把握できるのである。

＊＊＊

以上、本パートでは、多忙なアーキテクトが限られた時

間リソースを有効に使うためのノウハウについて解説した

時間管理において、特に難しいテクニックは必要ないとい

うことがおわかりいただけただろうか。

「時間を活用する」というのは、決して仕事を詰め込む

ことではない。「何を」を「いつ」やるべきかを把握すること

そのために効率の良い段取りをすることで、仕事の生産

性は大きく向上する。そしてそれは、ちょっとした習慣の積

み重ねと、ツールの利用で実現できることなのである。本

稿の内容を参考に、読者もぜひ、時間管理に挑戦して

みてほしい。

※4 メンバーの立場に立って考えてみれば、「作業の遅れ」はとても報告しづ

いことはわかるだろう。

図4：タスクの進捗状況を確認する方法

実際の状況

本人の希望的観測

時間

納期

「間に合うか？」という質問では、希望的観測によって「間に合う」という返事が返ってくる可能性が高い

「予定どおりにスタートできたか？」という質問により、遅れの危険性を察知しやすくなる

当初の予定

7/22/2019 IT Vol.13 00.pdf


13

P resent

■応募方法巻末のとじ込みアンケート・ハガキに、

第1希望／第2希望のプレゼント番号をご記入のうえ、お送りください。

■応募締め切り

2007年10月24日（水）消印有効

1名様1製品の当選とさせていただきます。

なお、当選者は本誌Vol.14（2007年11月24日発売）で発表いたします。

3

トラベル・ゲーム・セットを1名

様に。チェス、チェッカー、ソリテ

ィア、バックギャモンという代表

的な4つのゲームをまとめてい

ます。駒とボードはマグネット式。

ふたを閉めるとコンパクトに収

納でき、旅のお供に最適です。

『アジャイル開発の6原則と

20のベストプラクティス』■提供：エスアイビー・アクセス

■1名様

4

89ページで紹介している書

籍『アジャイル開発の6原則と

20のベストプラクティス』を1

名様に。開発プロジェクトを効

率良く進めるための20のプラ

クティスについて詳しく解説し

ています。

5

89 ページで紹介している書

籍『実践ユーザビリティテステ

ィング—「利用品質」を忘れて

ませんか—』を1名様に。今日、

その重要性が指摘されるユー

ザビリティを高めるための方法

について説明しています。

『PSPガイドブック

ソフトウェアエンジニア自己改善』■提供：翔泳社

■1名様

6

89ページで紹介している書

籍『PSPガイドブックソフトウェ

アエンジニア自己改善』を1名

様に。工数見積もりや品質管

理など、システム開発に欠かせ

ない知識を体系的にまとめて

います。

ワイヤレス・マウス■提供：IDGジャパン

■1名様

2

デジタル・カメラ■提供：IDGジャパン

■1名様

1

IT アーキテクト Vol.13

■Vol .12 プレゼント当選者発表 ※敬称略

●ニンテンドーDS Lite：榊原博（愛知県）

●地球儀：松井竜（神奈川県）

●多機能オフィス・ツール：関上清（群馬県）

●書籍『コンピュータアーキテクチャのエッセンス』：本林健志（富山県）

●書籍『Ajaxデザインパターン』：上原和彦（東京都）

●書籍『JavaからRubyへ』：根津芳香（神奈川県）

デジタル・カメラ（ペンタック

ス「Optio M40」）を1名様に。

動くものに自動的にピントを合

わせ続ける自動追尾AF機能

が目玉。肌をより明るく撮影で

きる「美肌モード」も搭載してい

ます。

書籍

書籍

『実践ユーザビリティテスティング

—「利用品質」を忘れてませんか—』■提供：翔泳社

■1名様

書籍

トラベル・ゲーム・セット■提供：IDGジャパン

■1名様

ワイヤレス・マウス（ロジクー

ル「MX 620 Cordles s La

se r Mou se 」）を1名様に。1

万行をわずか7秒間でスクロー

ルできる点が特徴。対応OSは

Window s XP/Vista、Mac

OS X。

7/22/2019 IT Vol.13 00.pdf



要求開発手法を現場で生かすた

めのノウハウを知る

要求開発は本来、情報システムの開発に携わるアーキテクトやエンジニアが実践するものだ。

しかし、その考え方や方法論は、人間系の業務にも応用することができる。

要求開発は今後、システム開発の枠を飛び越え、

そうした一般のビジネス・シーンにまで広がっていくだろう。

そこで、今回と次回の2回にわたり、

要求開発をシステム開発以外の領域に適用するためのポイントを解説したい。まず今回は、実際のビジネス・シーンではどのようなかたちで

“要求のやり取り”が行われているのかを、事例を基に説明する。

安井昌男 Masao Yasui

豆蔵 IT戦略支援事業部執行役員／事業部長

要求開発の今後

（前編）

山岸耕二 Koji Yamagishi

豆蔵代表取締役副社長

第6回実践編

要求開発の本質

今回からは、要求開発がこの先どういう方向

に向かうのかを探っていくが、その話に入る前に、まず要求開発のそもそもの考え方、つまり「本

質」について確認しておきたい。

要求開発とは、業務という（情報システムから

見ると1段上位の）複雑なシステムを設計する中

で、その下位となるサブシステム、すなわち情報

システムの要求仕様を規定する行為である。

情報システムは自動車に例えればエンジンの

ようなものだ。仕様に従って規定の情報をイン

プットすると、一定の処理を行い、所定のアウト

プットを極めて機械的に出力する。

この無機質なメカニズムにビジネス的な意味

を与えているのは、情報システムの上位に位置

する業務である。情報システムは、業務という、よ

り上位のシステムにつなぎ込まれることによって、

初めてその動作が価値を生み出す。

この関係は、エンジンをいきなり路面に転がし

ても何も起こらないのと同じだ。車台に適切に組

み込まれ、運転者と相応のやり取りをし、さらに自動車自体が道路など交通システムの体系内

に置かれた結果、最終的に価値ある動作を生

み出すようになる。上位の設計を抜きにして、い

きなりエンジンの仕様だけを決めても、とんでもなく

オーバースペックになったり、逆に非力すぎたりと

いったことが起きてしまうのである。

それと同様に、上位のシステムである業務が

十分に設計されないままサブシステムの仕様を

決めても、結果として業務に適合しないシステム

となり、「失敗システム」の烙印を押されることに

なる。実際、業務の設計を怠ったまま、情報シ

ステムだけのスコープでシステムを設計して失敗

するプロジェクトが、今日も後を絶たない。

7/22/2019 IT Vol.13 00.pdf



上位システムを最適化するには

要求開発を貫くテーマは、上位システムの目

的に整合するよう、いかに下位システムの仕様

を論理的に決定していくかということだ（図1）。上位システムを役割（責務）に注目して分割し

ていくと、独立性が高く、冗長度の少ない適切

なサブシステムの構成が得られる。この考え方は、

システム設計におけるオブジェクト指向のモ

ジュール分割と同じだ。上位システムを役割ごと

に適切に分割するには、まず業務をシステムとと

らえてモデル化する必要がある。

「業務を情報システムのモデルにする」と言っ

ても、別に大げさに考える必要はない。ビジネス

の目的を達成するために業務として提供する

サービス（ビジネス・ユースケース）を抽出し、そ

のサービスを効率良く実現するメカニズムを、

「静的モデル（概念モデル）」と「動的モデル

（業務フロー）」を用いて表現すればよいのだ。

要求開発の方法論は、もともと情報システム

の開発をターゲットにした要求開発、すなわち

「システム企画」と呼ばれる領域で適用されるこ

とを意図したものだ。しかし、上位システムを効

率化するために、下位のサブシステムの仕様を決定するという考え方自体は、普遍的な問題

解決手法としてさまさまな領域に適用できる。ビ

ジネス領域では人間が複雑に絡むため、どうし

てもコミュニケーションを中心にしたアプローチを

取りがちだ。そこに情報システムの開発で当たり

前に利用されているエンジニアリングの手法を持

ち込むことで、物事を合理的に決定でき、さらに

は関係者間の合意も形成しやすくなるのである。

要求開発はどこへ向かうのか

「要求」とは、そもそも人間の脳内で形成され

る、曖昧で明確なかたちがないものだ。この性

質は、いつの時代になっても変わらない。では、

そうした特性を持つ要求を扱うものとして、要求

開発は今後、どういう方向に向かって発展／

変化していくのだろうか。

本来、要求開発はソフトウェア開発の、いわ

ゆる「上流工程」のための方法論である。した

がって、ソフトウェアの開発に携わるアーキテクト

やエンジニアが対象だ。しかし、要求開発を本

当に必要としているのは、これらの人だ々けなの

だろうか。例えば、ソフトウェアを最終的に利用

するビジネス・パーソンはどうだろう。ビジネス・モ

デリングを主体とした要求開発は、日々、実際の

ビジネスに携わっているビジネス・パーソンにこそ、

本当に有益で必要となるものではないだろうか。

そこで本稿では、要求開発が将来、ソフトウェア開発だけにとどまらず、一般のビジネス・

パーソンにまで拡大していくと想定してみた。

要求開発では、「開発」の名を冠することから

も察せられるとおり、“なにがしか”を開発すること

になる。一般のビジネス・パーソンは、R＆D部門

図1：上位システムとの整合性

業務改善

（例：部品調達業務の迅速化）

上位

下位

上位

下位

情報システム

（例：Web部品発注システム）

この領域でも、同様に上位システムが存在しているので、整合性が必要

システム開発の要求開発と同様の手法や考え方が利用できる

「上位のシステム」の目的に整合するように、「下位のシステム」の仕様を論理的に導いていく

要求開発とは…

経営戦略

（例：迅速かつ高品質な製品を提供することによる差別化）

ビジネス・モデリング

●静的モデル●動的モデル

7/22/2019 IT Vol.13 00.pdf




第6回

でもない限り、「開発」という言葉にはあまりなじみ

がないだろう。しかし、要求開発方法論「Ope

nthology」がその主旨の1つとする「合意形成」

は、さまざまなビジネス・シーンで必要になるものだ。また、「無から有を創る」という意味では、「企

画」と呼ばれる職域が限りなく要求開発に近い。

このように、要求開発は今後、単にシステム

開発だけにとどまらず、一般のビジネス・シーンに

まで及んでいく可能性を秘めている。これまでも、

「ITとビジネスの融合」は、さまざまな立場から、

さまざまな言葉で唱えられてきた。要求開発は、

情報システムの領域を飛び越え、ビジネス活動

そのものとなりうるのである。

実際の企業組織における

要求とは

個人企業を例外にすれば、どんな企業にも、

必ず部門や部署などの「組織」が存在する。ま

た、それらの組織が何を責務としているのかという

「職掌」も決まっている。

一般に、「組織」を「企画する」という行為は、

組織改編などでもない限り滅多に行われるものではない。だが、部門／部署の単位ではなく、

プロジェクト・チームや各種委員会の結成といっ

た類の組織編成を行う機会はいろいろとあるの

ではないだろうか。

そこで以下に、ある企業が「環境保護推進

委員会」という組織を企画した例を紹介しよう。

なお、かなりデフォルメしている部分があることを

ご了承いただきたい。

組織を企画したA社の事例

消費財メーカーであるA社は、従来より環境

問題への取り組みを重要な経営課題として掲

げてきた。しかし、組織として積極的に活動する

ところまでは至っておらず、社内的にも今ひとつ

盛り上がりに欠けていた。

ある日、A社のライバル企業で環境関連の問

題が発覚する。さほど大きな問題ではなかったものの、工場のある地域では地元紙に取り上げら

れ、工場長のインタビューが報じられた。そのイ

ンタビューで、工場長と広報部門の間の「見解

の相違」が表面化してしまい、問題そのものより

も、むしろ環境に対する企業の姿勢や体質が

問われる事態となる。

一方、A社では、たまたま経営陣が交代する

ことになった。単なる時期的な偶然ではあった

が、A社の新経営陣は同業他社での問題を受

けてか、新しい自社の象徴として、全社一丸と

なった環境問題に取り組むことを決議した。その

決議の内容は以下のようなものだ。

環境問題に対する取り組みの決議

環境に対する取り組みを一層充実させる。

そして、取引先をはじめとして広く社外に

アピールし、当社が「環境先進企業」であ

ることを、より広く社会に知ってもらう

新経営陣は早速、社内に「環境保護推進委員会」を組織するよう指示した。経営企画部

を通じてこの指示を受けたのは、生産部門の

安全環境を担当する「安全環境部」である。

しかし、安全環境部は大いに戸惑ってしまっ

た。実は、A社は環境関連の標準規格である

「ISO 14001」を、安全環境部主体の働きかけ

によってすでに取得していたのだ。つまり、「環境

保全指針」も「環境保全マニュアル」も「社内

審査員制度」も、すべて整っていたわけである。

それにもかかわらず、また新たに環境保護推

進委員会なるものを組織するというのは、「今ま

でやってきたことはまったくの無駄」と言われてい

るに等しいではないか。安全環境部のメンバー

7/22/2019 IT Vol.13 00.pdf



の中には、そのように憤慨する者もいた。

実際のところ、安全環境部にしてみれば、苦

労して取得したISO 14001であり、毎年きちんと

サーベイランス（審査）は受けている。「今度の社長は、生産畑出身じゃないからな（何もわかっ

ちゃいない）」などという声さえ聞こえてくる始末だ。

安全環境部長は、そのような部員の反応を

理解できないわけではなかったが、同時に「あ

れほど力を注いで取り組んだISOに、経営陣が

無関心だったはずはないのに……」と解せない

気持ちもあった。そして、前述の「環境問題に

対する取り組みの決議」の中に「社外にアピー

ルし」という言葉があったことから、「社内だけで

なく、社外にもアピールするような施策を打ち出

せというわけか……」と推察した。社外へのア

ピールとなれば、本来は広報部や経営企画部

の仕事だが、「まぁ、互いに協力してやれというこ

とだろう」と漠然と考えていたのだ。

ところがある日、経営企画部長が安全環境

部長のところに来て、こうこぼしたのであった。

「実は先日、環境保護推進委員会の件で

大目玉を喰らいましてねぇ」

何でも、新経営陣に「環境問題への取り組みを企業の“姿勢”として位置づけようとしている

ときに、全社の要である経営企画部が、安全

環境部へ仕事を丸投げするようなことでいいの

か」と叱咤されたらしい。

A社の場合、経営陣が参画するような委員

会の事務局は、基本的に経営企画部が担当

する。ただし、生産性向上や営業推進といった

委員会活動の主なテーマに関しては、製造技

術部や営業部のようにそれぞれ主管となるべき

部署が存在する。そのため、経営企画部は他

の経営議決事項や会議のスケジュール調整だ

けを行い、実質の事務局は各主管部署に担当

してもらうのが通例であった。そこで、今回につ

いても、これまでと同様に、安全環境部と合同

で事務局を担当することを新経営陣に報告しに

行ったところ、突然「君らは、一体何のために

存在するのだ」と叱責されたのだという。「どうしましょうかねぇ……」

経営企画部長は困り果てた顔で、そうつぶ

やいた。「とにかく一緒に考えましょう」と安全環

境部長はその場を収めたものの、新経営陣の

思惑がどこにあるのか、さっぱりわからなくなって

しまった（次ページの図2）。

要求を明確に把握することの

重要性

さて、もし読者が、経営企画部長や安全環

境部長の立場であったならば、どうするだろうか。

改めて説明するまでもないが、両部長の抱え

込んだ問題は「新経営陣の要求」を明確に把

握できていないことに起因している。読者の中に

は、「何が要求かなんて、聞きに行けばいいじゃ

ないか」と思った方もいるだろう。実はそのとおり、

単に聞きに行けばよいだけなのである。

ただし、部門／部署の代表者たる部長ともあろう者が、徒手空拳で「何となく意味がわから

ないのですが……」とか「どうやればよいかわか

らないのですが……」と雁首をそろえて来たら、

新経営陣は何と言うだろうか。新経営陣にして

みれば、「環境保護推進委員会の設置」は、

前述の「環境問題に対する取り組みの決議」

に基づいて出した指示だ。経営側の指示として

は、十分に具体的なのである。彼らの立場では

「環境保護推進委員会は、具体的に何をやる

のか」と問われたら、「それを考えるのが君らの

仕事だろう」と言いたくなるかもしれない。

両部長をはじめとする従業員は、新経営陣と

同じ会社の中にいる身として、決議に至った背

実践編

7/22/2019 IT Vol.13 00.pdf




第6回

景や状況をまったく知らないわけではない。疑問

点や問題点について、仮説を立てたり、推察し

たりして、具体的な質問や意見のかたちで持っ

て行かなければ、それこそ「君らは何のためにい

るのか」と言われかねないのだ。与えられた指示

に対して、自分なりの見解も持たずに“手ぶら”

で行くのは、あまりにも間抜けである。

ここで、新経営陣からの要求を、彼らが

「言ったこと」を中心にして整理してみよう（図3）。

この図も参考にして考えるに、新経営陣の「環

境先進企業となる」や「環境保護推進委員会を設置する」という要求に対する答えは、「A社

が環境先進企業となるために、環境保護推進

委員会は何をどうすればよいのか」という具体策

である。

言いかえれば、環境先進企業になるための

プランであり、それを主体となって策定する組織

が環境保護推進委員会だ。経営企画部長が

叱責を受けたのは、「ちゃんと自分の（プランの

策定という）役割を果たせ」という、環境問題へ

の取り組みとはまた別の「要求」なのである。つ

まり、環境先進企業となり、それを社外にアピー

ルすることが、経営レベルでの目的となるはずだ。

ただし、「環境先進企業」とは、あまりにも漠

然とした要求である。この大前提から明らかにし

ていかないと、環境保護推進委員会の活動内

容も決まらないかもしれない。

上位組織が求めるレベル

現場の人間からすると、「環境先進企業」と

いう要求は非常に曖昧で、何を求めているのか

図2：安全環境部長の悩み

経営戦略

「環境先進企業」となり、社内外へアピールする

上位

下位

業務改善

「環境保護促進委員会」を組織する

でもISO 14001は取得しているし……

単なる広報戦略の話なら、委員会などではなく、広報部門の仕事だろうし……

安全環境部長

他者の環境問題

新経営陣の決議

一体、「何をやれば」いいのだろう？

経営企画部長は「どうしましょうか」って言ってくるし……

図3：新経営陣から「言われたこと」

同業他社の環境事故

「何をする」委員会であればよいのか？

新経営陣への交代

ISO 14001の取得／維持

事件など外的事項

経営陣の意向／要求

社内の行動

とりあえず環境重視の経営

名実ともに「環境先進企業」となり、社外へもアピール

決議

?総合企画部への「丸投げ」批判

「環境保護促進委員会」の設置

7/22/2019 IT Vol.13 00.pdf



実践編

わかりにくい。「もう少し具体的な指示をくれ」と

文句の1つも言いたくなるところだ。

一方、新経営陣からすれば、「環境先進企

業になる」というのは、経営レベルに即した実にシンプルで明快な要求である（しかも、「環境保

護推進委員会」という“具体的な”手段まで提

示している）。企業のすべての面をカバーしなけ

ればならない経営陣の「指示」としては、この程

度の曖昧さ、抽象度にならざるをえないだろう。

そして特に、特定の職掌を持つ部門／部署

が多く存在する大企業では、経営陣からの指

示を、各専門の部門／部署が具体策に落とし

込んでいくのが普通である。

すなわち、企業全体としての上位目的を果た

すためには、まずサブシステムである各部署が

果たすべき役割（下位の目的）を明らかにしたう

えで、さらに部署レベルで具体的な施策に展開

し、全社の活動が円滑に実行されるようにするこ

とが求められるのである。

要求開発と企画

抽象度の高い上位の要求から、具体的な下位の要求を導き出す「要求開発」は、企業

においては不断の業務である。この要求開発

は、従来からある「企画」という業務とほぼイ

コールで結ぶことができるだろう。

経営陣が、企業の企画活動に期待するの

は、「事務局」や「各部署への仕事の丸投げ」

ではなく、まさに大きな方向性や方針（当然、こ

れは「漠然とした要求」になってしまう）に基づき、

より詳細化した「要求」を「開発」することである。

言いかえれば、「方針から具体策へ」という“ブ

リッジ”を期待されるのだ。経営企画部長が叱

責を受けた原因も、「要求を開発する」という姿

勢が見えなかったことと無関係ではないだろう。

また、実際の現場では、「漠然としているかも

しれないが、実はシンプルな」経営陣の要求が、

妙に深読みされてしまうことがある。今回の例で

も、安全環境部の面は々ISO 14001との関係で、いろいろな疑念が浮かんでしまった。

「特定の問題」や「特定の領域」に関しては、

指示を行う経営陣よりも、現場のほうが圧倒的

に情報を持っているケースが多い。しかし一方で、

「特定の問題」や「特定の領域」以外について

はよく知らない場合もある。そこで、まずは指示の

主旨やそれが出された背景を把握するために、

手もとにある情報を整理することが重要になる。

「前提を整理する」ということ

「何がわからないのか」と「何がわかっている

のか」。この「何」は、「企画」を行う際に最も重

要な「前提」だ。前提を整理することは、ロジカ

ルな行為である「要求の開発」には欠かせない。

この関係上、「企画の品質」は、「事前の整

理」に依存するものなのだ。

これは、アプリケーションを企画する際も同様

である。アプリケーションを、情報システムという枠

組みだけでなく、人間系の活動まで含めて上位のシステムから考えることの重要性は、本連

載でも述べてきた。情報システムも企業を構成

する1つの組織ととらえれば、情報システムを企画

することと組織を企画することは同義なのである。

今回は、実際の企業組織を例にとり、要求

に対する現場と経営陣双方の考え方の違いを

述べた。要求開発において、経営陣は重要な

ステークホルダー（利害関係者）になることが多

い。しかし、経営陣が具体的な実現方法まで

指示してくれると思うのは、過剰な期待である。

次回は、安全環境部長や経営企画部長が

どのようにして「企画」を進めたのかについて、ビ

ジネス・モデリングの実践例を基に解説する。

7/22/2019 IT Vol.13 00.pdf



行動指針I T アーキテクトの

Unified Process

に学ぶ

“ゼロ・リスク”のプロジェクトを目指す

まずは改めて強調しておこう。ITアーキテクトは“リスク・

ドリブン”で行動せよ。これは、プロジェクトのすべての期

間で意識すべき基本的な指針である。

この基本指針に基づき、方向づけフェーズでは「リスクを識別し、開発プロジェクトが成功する確信を得る」

ために行動してきた。それに続く推敲フェーズでは、「リス

クが最小化された環境を整えること」が目標になる。「多

分、成功するだろう」といったあやふやな予測で済ませ

るのではなく、プロジェクトとして「実際に成功させる」た

めにITアーキテクトが最も注力すべき期間、それが「推

敲フェーズ（Elaboration Phase）」だ。

推敲フェーズで目指す「リスクの最小化」とは、リスク

の発生確率を限りなくゼロに近づけつつ、そのすべてに

対する対処策が事前に準備されている状態を言う。こ

れとは逆に、「不確定要素こそがイノベーションの源泉で

ある」という考え方もあるが、開発プロジェクトは“アート”

ではない。ITアーキテクトが推敲フェーズで目指すべき

は、究極的には「ゼロ・リスク・プロジェクト」、つまり作成

フェーズ以降のことは何も心配する必要がないプロジェク

トである。

それでは、推敲フェーズの詳細な説明に入る前に、

UPを用いた開発プロジェクトの全体像について、少し

おさらいしておこう。

UPの開発プロジェクトとは

UPの開発プロジェクトは、「方向づけ（Inception）」、

「推敲（Elaboration）」、「作成（Construction）」、

「移行（Transition）」という4つのフェーズから成る。そ

れぞれのフェーズには達成すべき「目標」があり、終了

条件として「マイルストーン」が設定される。プロジェクトを

4つのフェーズに分割し、目標設定を行うこの手法のこと

を「4フェーズ・アプローチ」と呼ぶ

※1

。例えば、方向づけフェーズでは「収集」や「調査／

検証」が主な作業となるが、続く推敲フェーズでは、

「仕様化」や「アーキテクチャの設計／実装」など、より

多くのリソースを消費する作業を実施する。

方向づけフェーズから推敲フェーズへ

方向づけフェーズを終了し、推敲フェーズに移るため

には、方向づけフェーズに設定された以下のマイルスト

ーンが達成されている必要がある。

●開発範囲の定義とコスト／スケジュールの見積もりに

ついて、ステークホルダー（利害関係者）の同意を得

ているか

●獲得した要求が適正であり、またそれらの要求につい

て、共通の理解があるという同意が得られているか

●要求の優先順位／リスク／開発プロセスが適切であ

るという同意を得ているか

●すべてのリスクが識別され、さらに各リスクごとに、その

影響を軽減するための戦略が存在するか●初期のアーキテクチャ案（アーキテクチャ候補）が完

成しているか

※1 4フェーズ・アプローチの詳細については、本連載の第 1回（Vol.7 掲

載）をご覧いただきたい。

7/22/2019 IT Vol.13 00.pdf


7/22/2019 IT Vol.13 00.pdf



推敲フェーズで

試行錯誤を繰り返す

vol.

07

つの成果物を提供しなけらばならない。

●開発チームに向けて「アーキテクチャ実装」をリリース

する

●アーキテクチャとともに、「アーキテクチャ説明書」をリ

リースする

●作成フェーズと移行フェーズを計画を精緻に立てら

れるような基礎情報を提供する

簡単に言えば、推敲フェーズの終了時点で、「これ

（アーキテクチャ実装）を利用し、これ（アーキテクチャ説

明書）に従って作れば、確実にシステムを構築／リリー

スできます。そのための計画立案には、これ（計画の基

礎情報）を使ってください」と提示できればよい。

図1は、ITアーキテクトが推敲フェーズで行う作業を

簡単にまとめたものだ。この一連のワークフローが、推敲

フェーズにおけるITアーキテクトの基本行動となる。以

降では、このワークフローの各ステップごとに、ITアーキテ

クトに求められる役割／活動を説明していこう。

ステップ1 主要な要求を識別する

推敲フェーズにおけるITアーキテクトの行動は、まず

「核となる要求（シード・ユースケース）」を識別するところ

から始まる。「核となる要求」とは、すでに定義されている

機能要求（ユースケース）のうち、以下の条件に当ては

まるものを指す。

●システムの典型的な振る舞いを持つ

●システムの存在価値を示す

●特殊な動作が求められる

●他システムとの連携が必要

●変更した場合の影響範囲が大きい

●信頼性／性能／セキュリティと深く関連する

●想定している実現手段（技術）では、実装が難しいと

予想される

これらの条件によって識別された要求が「核となる要

求」とされ、ITアーキテクトは優先してその実現可能性

を検証する。システムの規模や複雑さによってその数は

異なるが、平均的には全機能要求の10％から20％程

度が目安となる。

そして、この「核となる要求」の中から1つの要求を抽

出し、その「処理フロー」に目を向ける。この一連の処理

を次のステップ2で実装するのだ。

ステップ2 要求を実装してみる

対象となる処理フローを抽出したら、まずは軽く実装し

てみよう。アーキテクチャとしての美しさや整合性は後で

気にすればよい。最優先するのは、「想定している実現

手段で、要求を満足できるか」を確認することだ。この時点では、あくまでも「仮実装」であり、「本実装」は作

成フェーズで開発者が行う。そのため、ここではあえて

“実装してみる”としている。

ステップ2への入力は、「処理フロー」、「非機能要

求」、「実現手段（採用技術）」の3つになる。このステッ

プの作業を円滑に進めるには、いろいろと悩みすぎたり、

深入りしすぎたりしないよう注意したい。不確定要素に

対処するのが推敲フェーズの目的なので、予定外の事

象が発生するのは当たり前と考え、計画的に対処しな

ければならない。例えば、以下の手順を踏めば、手を

止めることなく進められるだろう。

①最初に、機能テストのレベルのテスト・シナリオを書く

表1：推敲フェーズの目的とマイルストーン

目的マイルストーン

●機能要求を明確化し、要求の大部分を把握する

●重要な要求が実装された、堅牢なアーキテクチャの基盤

を確立する

●プロジェクトで重要なすべてのリスクを指摘する

●識別されたリスクのほとんどすべてに対処する

●プロジェクト計画書の精度を高める

●システム（製品）の開発構想と要求が安定しているかどうか

●アーキテクチャが安定しているかどうか

●テストと評価によって、導入する主要なアプローチの有効性が証明されているかどうか

●実行可能なプロトタイプのテストと評価により、主要な技術的リスクが確実に解決されていることを証

明できるかどうか

●致命的なリスクと重大なリスクが軽減されているかどうか

●現在のアーキテクチャで計画を実行してシステムを完成させれば、開発構想を達成できるとすべての

ステークホルダーが同意しているかどうか

7/22/2019 IT Vol.13 00.pdf


14IT アーキテクト Vol.13行動指針

I T アーキテクトの

Unified Process

に学ぶ

②「処理フロー」だけに注目し、「実現手段」で実装す

る。要求を実現するために、新たなサブシステムやフ

レームワークが必要な部分を見つけたら、推敲フェー

ズの計画に「サブシステムの作成」を追加しつつ、該

当部分はスタブで対処しておく

③一連のフローが動作するところまで実装したら、機能テスト・シナリオを用いて問題がないことを確認する

④動作が確認できたら、「非機能要求」から該当する

要求を追加実装する。特に初期の段階では、エラ

ー・ハンドリングやセキュリティ、ロギングなどの実装に

試行錯誤しなければならないことが多い。そうした作

業が予定に入っていなければ、計画に追加し、別タ

スクとして実装する

⑤再び機能テスト・シナリオで検証し、問題が発生しな

いことを確認する

なお、1つの機能のすべての処理を、最初から順番

に実装する必要はない。処理によっては、いくつかの処

理ブロックに分割できるはずだ。例えば、「ユーザーが

入力した検索条件から、該当する取り引きを一覧表示

する」という処理が記述されている場合、最初は「検索

画面を表示する」ことだけに集中してもかまわない。

また、不慣れな技術を扱うときには、特に気をつけて

ほしい。背伸びをして、1つの要求を実装するのに何週

間もかけてはならない。長くとも1週間以内に一連のワークフローが完了するように計画する。

ただし、一部の処理ブロックだけを実装する“つまみ

食い”は禁止だ。要求に含まれる一連の処理がすべて

動作して、初めて1つの機能の実現可能性が検証され

る。「（この処理ブロックは実装しなくても）大丈夫だろう」

と残した部分が、リスクの発生源になるケースは多い。

こうして非機能要求まで実装したら、一応はこのステッ

プの目的を果たしたことになるが、この段階ではまだ“汚

い”実装である場合がほとんどだ。

ステップ3 実装コストを見積もる

このステップの開始時点では、要求を満たす機能は実装

図1：推敲フェーズにおけるワークフロー

機能要求

非機能要求

採用する技術

核となる要求（シード・ユースケース）

［ステップ1］主要な要求を識別する

［ステップ2］要求を実装してみる

［ステップ4］複雑さを低減する

［ステップ3］実装コストを見積もる

［ステップ5］行動を可視化する

処理フロー

ドメイン・オブジェクト／レイヤ／共通部品

仮実装された要求

開発コストとリスクの基礎値

要求を実装するための行動

実装環境を提供するための

行動

作成フェーズの計画の基礎値になる「アーキテクチャ説明書」の構成要素になる

「アーキテクチャ実装」の構成要素になる

リスクとコストは許容範囲内か

許容できない

問題なし

「実装環境」として構築

環境を使って再度実装

次の要求へ

7/22/2019 IT Vol.13 00.pdf



推敲フェーズで

試行錯誤を繰り返す

vol.

07

しているが、あくまでも“単独の機能”として動作することを確

認したにすぎない。「システム全体の一貫性」や「変更可能

性」、「再利用可能性」、そして「開発者にとっての作りやす

さ」などに関しては、まだ確認できていない状態だ。

ステップ3では、「開発者にとっての実装コストを見積も

る」とともに、実装を整理して、開発者が“作りやすい”環境に改善することでリスクの削減を目指す。

それには、まず実装の基になった「文章の処理フロー」

と、実装された「コードの処理フロー」を見比べてみる。

ほとんどの場合、コードの処理フローのほうが長く、理解

しづらいだろう。理想は、双方が同じ長さである状態だ。

では、コードが長くなる原因は何か。それは、前処理や

後処理、計算、データの詰め替えなど、処理フローの中

で行うべきではない処理を含んでいるためである。

また、よく見比べてみると“ムラ”があることも見えてくるは

ずだ。フレームワークやミドルウェアがうまく要求に適合し

ている部分はシンプルな構成だが、スクラッチで実装し

た部分は複雑になっているだろう。そうした部分に慌て

て手を入れる前に、まずは担当の開発者がそれぞれの

機能を実装するのに、どのくらいの工数が必要になるか

を見積もってほしい。この見積もりの対象には、エラーが

混入する可能性がある部分と、それに対処するための

工数も含める。それらの工数をどれだけ削減できるかが、

ITアーキテクトの腕の見せどころである。

推敲フェーズの中盤が過ぎるころには、最初から理想的なかたちの実装ができることもあるだろう。逆に、い

つまでもこのステップで停滞しているようだと、プロジェクト

の重大なリスクとなる。

ステップ4 複雑さを低減する

方向づけフェーズでは、実現手段を検証するととも

に、各技術間の接続方法や、レイヤ構成／スクラッチ

開発が必要な部分などを検討したはずだ。ステップ4で

は、その「システムの構造」を実装レベルで実現し、開

発者の実装コストを最小化するのが目的となる。

複雑さを低減するための代表的な手段には以下のも

のがあり、これらの手段を通じて実装された環境が「アー

キテクチャ実装」となる（下の括弧内に、その手段が複雑

さの低減にどのくらい効果を発揮するのかを示した）。

●ドメイン固有の概念を共有して、業務的な複雑さを

隠蔽する（効果：大）

●抽象化レイヤでラッピングし、呼び出し手続きを簡素

化する（効果：中）●リファクタリングによって、処理フローを簡素化する（効

果：中）

●基本的な手続きを共通部品化して、処理ステップを

削減する（効果：小）

以上の手段を用いることで、前述した「システム全体

の一貫性」や「変更可能性」、「再利用可能性」、そし

て「開発者にとっての作りやすさ」が実現される。

なお、この際にITアーキテクトが忘れがちなのが、

「開発者の視点」である。取りうる最適な手段は、実装

を担当する開発者の経験やスキル・レベルによって左右

される。ITアーキテクトが「こんなにわかりやすい構成はな

い」と思ったとしても、開発者が理解できず、“使えない”

環境であれば、これは不適切なアーキテクチャなのだ。

あくまでも、開発者が“作りやすい”環境を目指すのがス

テップ4の目標である。独り善がりなアーキテクチャを設

計しないために、この目標を常に意識しておこう。

また、コードに手を入れたら、準備しておいた機能テス

トを再度実行するのを忘れないようにしたい。そのために

は、回帰テストを行う習慣を身に付けるのが良策だ。もちろん、テストの自動化も有効である。

ステップ5 行動を可視化する

技術者心理としては、要求と「システムの構造」がバ

ランス良く実装できたなら、「よし！」という達成感を得るとと

もに、早速次の要求に取りかかりたくなるはずだ。しかし、

その前に、ITアーキテクトとしての大切な仕事がある。そ

れが「可視化」だ。具体的には、開発者が要求を実

装する際に困らないよう、また迷わないように、以下の観

点でドキュメントを書き残しておく必要がある。

●どの要求が対象なのか（対象となる要求）

●どのような指針に基づくのか（設計ガイドライン）

7/22/2019 IT Vol.13 00.pdf


14IT アーキテクト Vol.13行動指針

I T アーキテクトの

Unified Process

に学ぶ

●どう実装するのか（実装ガイドライン）

●上記3つの観点での前提や制約、注意事項

●処理フローを実装したコード（サンプル・コード）

●利用したテスト・シナリオ（テスト・ケース）

もし、好ましい手順を見つけたら、それも書き記しておこ

う。上に挙げたもの以外にも、「開発者に同じ試行錯誤を繰り返させてはならない」という点を念頭に置くことで、

必要となるドキュメントが見えてくるはずだ。

また、開発者の視点とともに、アーキテクトの視点によ

る可視化も並行して行う。このときは、「開発者が実装

するための環境を提供する」という心構えで書き残してお

く。少なくとも、以下の3つの観点は網羅しておきたい。

●システム全体はどのような構造なのか（アーキテクチャ

の構造）

●どう使うのか（アーキテクチャのインタフェース、利用サ

ンプル）

●どのような指針に従うべきなのか（各種の規約／指

針）

一般に、仕様書や設計書など、ここに挙げたもの以

外のドキュメントも必要になる。それらのドキュメントについ

ては、各プロジェクトの開発プロセスに従って用意する。

ただし、ITアーキテクトが先行して作成したドキュメント

は、後に続く開発者にとって非常に有用な「手本」にな

ることを忘れないでほしい。

推敲フェーズとイテレーション

すでにお気づきかもしれないが、推敲フェーズにおけ

るワークフローは「反復型」で実行される。イテレーション

（反復）の単位は「要求」、もしくは「処理ブロック」だ。

作業計画は、このイテレーションを1つの単位として立案

する。もちろん、「リスクの高い要求」から優先的に計画

することが重要である。

たとえウォーターフォール型のプロジェクトであったとして

も、推敲フェーズでのITアーキテクトの行動は「リスク・ド

リブン」の「反復型」で進めたい。ウォーターフォール型の

場合、推敲フェーズに該当するのは要件定義の期間

だ。要件定義は従来どおりに行えばよいが、その裏で、IT

アーキテクトは反復型でリスクに対処するようにしてほしい。

推敲フェーズの4原則

今回のまとめとして、推敲フェーズで忘れてはならない4原則を以下に記しておく。少なくとも、これらの原則を

忘れなければ、どのようなプロジェクトであっても大きく道

をそれることはないはずだ。

●原則1：要求に注目してアーキテクチャを構築すべし

ITアーキテクトは、システムの骨格となるアーキテクチ

ャの実装まで行う。要求フェーズの目的が、「要求を実

装する」ことである点を忘れてはならない。

●原則2：開発者の視点で実装すべし

開発者は、アーキテクチャのインタフェースを知ってい

ても、そのアーキテクチャ自体がどう実装されたかまでは

わからない。ITアーキテクトが知っていることのすべてを

開発者が理解する必要はないし、すべて理解しなけれ

ば使えないようなものはアーキテクチャとは呼ばない。

●原則3：作業プロセスを可視化すべし

要求とアーキテクチャを実装するために試行錯誤す

る中で、きっと効率の良い実装方法を見いだすことがで

きるだろう。また、実装する際に注意すべき部分や、特

殊な実装方法が求められる場合も出てくるはずだ。それ

らすべてを書き残し、可視化しておく。ITアーキテクトが歩んできた試行錯誤の道を、再び開発者に通らせては

ならない。

●原則4：とにかく手を動かすべし

机上で想像するだけでは、結局は時間の無駄にな

る。かたちあるものを作り、壊し、試行錯誤し、そして書き

残すことだ。これが、推敲フェーズにおけるITアーキテク

トの考えを後に続く開発者に伝える唯一の手段であり、

使命でもあるのだ。

『UMLによる統一ソフトウェア開発プロセス』（著

者：イヴァー・ヤコブソン氏、ほか／発行：翔泳社／

発行年：2000年）

参考文献

7/22/2019 IT Vol.13 00.pdf


執

筆

者

紹

介

A u t h o r ' s P r o f i l e


ITコーディネーター、中小企業診断士。現

在、SIer において大企業向けのI T企画立

案、情報システム構築に従事する傍ら、

NPO法人「ITコーディネータ京都」にて、地

域の中堅／中小企業に対してIT 経営の推

進を支援している。

執筆記事：P.068

杉村まきこ

外資系データベース・ベンダーを経て、アー

サーアンダーセン（現ベリングポイント）にてIT

から業務改善、戦略立案まで幅広いコンサ

ルティングを展開。豊富な実績と知識を有し、

バランス感の高いコンサルティングには定評

がある。現在は大手エンターテインメント会社

で物販部門、飲食部門の部門長を兼務。


荒井岳

アクセンチュアにおいて、ITアーキテクトとし

て開発プロジェクトに参加すると同時に、

SOAプログラムを推進。同社入社以前は、

アイオナ・テクノロジーズ、TCSI、日本 DEC

にて技術コンサルタント／ITアーキテクトとし

て活躍。著書は『Webサービス実践プログラ

ミング』（翔泳社刊）など多数。


小野沢博文

NEC入社以来、現在に至るまで、システム

運用管理製品の開発に従事。メインフレー

ムの中央集中管理からオープン系の2 階層

システム、Webの3階層システム、そして現在

はビジネス・グリッド環境など、時代とともに

変化するシステム環境にフィットしたシステム

運用管理製品の開発に努めている。

執筆記事：P.110、118

上坂利文

ビズアーク時間管理術研究所代表（http://

www.biza rk.co.j p/）。一部上場の製造業

にて、設計／生産技術／品質管理のエンジ

ニアとして勤務した経歴を持つ、異色の“時

間管理術”専門コンサルタント。著書に『超カ

ンタン！時間管理術』、『宝くじを買う人は仕事

ができない』がある。


水口和彦

コスモコンサルティング代表取締役。中央ク

ーパース・アンド・ライブランド・コンサルティ

ングなどを経て現職。さまざまなITプロジェクト

のコンサルタントとして活躍中。IT技術者を

育成する「示現塾（じげんじゅく）」を主催。

『プロジェクトマネージャ完全教本』ほか、著

書多数。


金子則彦

汎用機のテクニカルSEから始まり、プロジェ

クト・マネジャーとしてシステム開発全般を経

験した後、インフラを中心とするシステム構

築部隊を率いた経験を持つ。NECのプラット

フォーム戦略の検討を経て、現在はシステム

基盤のコンサルテーションに従事している。


小池和雄

NEC Certied Professional 上席システム

ズアーキテクト。1985 年にNEC 入社。UN

IX 系OSの開発を経て、オープン系大規模

分散システムの開発プロジェクトに参画。以

来、業種非依存のシステム・アーキテクトとし

て提案書作成やアーキテクチャ検討、重要

システムの障害解析までを手広く担当する。


東健二

7/22/2019 IT Vol.13 00.pdf



お知らせ

都合により、今号の連載『アーキテクチャ技

術最前線』は休載とさせていただきます。

電機メーカーを経て、1989 年にSIerへ移籍。

以後、一貫してオブジェクト技術を適用したシ

ステム開発や方法論の導入など、ビジネス創

出に携わる。2004年に豆蔵代表取締役副

社長に就任。技術士（情報処理）、要求開発

アライアンス理事長。最近の著書は『要求開

発』（日経BP刊。共著）など。


山岸耕二

アイデアクラフト代表。SE 業務の経験から

「文章を正確に読み取る読解力」の必要性

を認識し、そのための「読み書き／図解」の

研修プログラムを開発。一般社会人向けに

読解／表現／思考力を磨くための教育事業

を展開中。著書は『90分でわかる SEの思

考術』（日経BP刊）など。


開米瑞浩

常に最適なアーキテクチャを追求し続けるア

ーキテクト。B2Cサービス構築が最も得意。

「どうすればエンジニアがプライドを持って、快

適に開発ができるのか」が技術者としてのテ

ーマ。一昨年からトライアスロンを始め、昨期

はロング・ディスタンス（Swim 3.8km、Bike

180km、Run 42.2km）完走を果たす。


笠原規男

ソフトウェアプロセスエンジニアリング（SPEI）

代表。日本DEC、日本HPで金融機関向け

の開発プロジェクトに携わり、日本ラショナ

ル・ソフトウェアでは開発プロセス（RUP）の

導入コンサルティングを担当。2003 年に独

立し、SPEIを設立、プロセス・エンジニアリン

グ、プロジェクト・メンタリング、教育に従事。


岡大勝

オブジェクト指向技術のスペシャリストとして、

この分野では日本の草分け的存在。豆蔵な

どの設立に参加した後、2005 年にビズモを

設立。現在はビジネス・モデリングをベースと

した、完成度の高いソフトウェア・エンジニア

リングを実現するためのアーキテクチャ設計

に取り組んでいる。


鈴木高弘

1982 年、国内最大手の建設会社に入社。

建設作業所勤務を経て、情報システム部門

でシステム開発や企画を担当し、オブジェクト

指向に基づく開発プロセスの導入や実践に

努める。2006年6月、豆蔵に転職。著書は、

『戦略的要求開発のススメ』（翔泳社刊）、

『仕事のとれるSE」（日経BP刊）など。


安井昌男

7/22/2019 IT Vol.13 00.pdf


［特集1］

いま再び問う、

ITアーキテクトとは何か必要とされる理由、果たすべき役割、そしてスキル要件を再確認する

［特集2］

EA導入の現実解を探る自社の組織／ ITシステムの実情を踏まえた全体最適化への取り組み方

次号 Vol.14は2007年11月24日発売！

編集長名須川竜太

編集伊藤正子

浜崎貴生

後藤真里

アート・ディレクション浜本直樹

カバー・デザイン浜本直樹

制作坂内正景

写真東京フォト工芸

営業統括三浦元裕

広告営業部中林滋

佐藤友朗

新井次郎

丹野毅也

香取健二

濱谷珠枝

千葉由紀美

インターネット・メディア部本間彰

佐藤達夫

岡城真紀枝

細川亜希

販売推進部森本直貴

伊藤弘子

張替薫

石川由希子

発行人玉井節朗

次号予告 ※内容は変更になる場合があります。

N e x t

I s s u e

S t a f f

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

Documents

Transcript of ITアーキテクト Vol.13 00.pdf