V o l .

24

システム開発のアジリティ向上はビジネスの要請
Vol.

アジャイル開発の真価 /クラウド時代のITインフラ・ガバナンス/BIの現在、過去、未来/システムアーキテクト試験

定価:1,680円(税込)

ITシステムを
〝創る〟
人のための
技術情報誌

24
www.itarchitect.jp

特集2

クラウド時代の
ITインフラ・
ガバナンス

アジャイル開発の
真価
特集1

最大の価値は「
『要求=状況』
の変化に対応できること」。
“変わること”
を前提にした開発手法の意義、
導入のポイント、
ベスト
・プラクティス

特集3

BIの

現在、
過去、
未来
特 別 企 画 4 連 発!

情報処理技術者試験「システムアーキテクト」

Google App Engine for Java

本体:1,600円

アーキテクトの
“抽象化力”
マルチパラダイム言語「Scala」

雑誌61503-95
Ⓒ株式会社アイ・ディ・ジー・ジャパン 2009 Printed in Japan
発行/発売:株式会社アイ・ディ・ジー・ジャパン
発行人:福田 悦朋
〒113-0033 東京都文京区本郷3-4-6
Ⓗ2010年2月 ☎ 03-5800-2661
(販売推進部)

DIC68

016

特集1
システム開発のアジリティ向上はビジネスの要請

アジャイル開発の真価
最大の価値は「『要求=状況』
の変化に対応できること」。
“変わること”
を前提にした開発手法の意義、導入のポイント、ベスト・プラクティス

080

特集2
インフラ構築/運用を“あるべき姿”へと近づける

クラウド時代の
ITインフラ・ガバナンス
鍵は「標準化」

「体制の確立」
――プライベート・クラウド構築を通した自社インフラの最適化

096

特集3

BIの現在、過去、未来

Contents

登場の背景と今日までの変遷、関連技術/製品の動向を踏まえて
考える、今後のBIシステム――クラウド時代に、何がどう変わるのか

Architecture Design

058

●サービス指向で挑むシステム統合

既存システムを分析し、業務との対応関係を把握する
Communication Technique

052

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

経営のアジリティを高める、組織とITのあり方
074

24
Vo l .

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

“統合パッケージ”ばかりでは問題解決の発想は生まれない

目次.indd 1

09/07/12 18:17

028

特別企画1
いよいよアーキテクトの国家資格試験がスタート!

情報処理技術者試験
「システムアーキテクト」のすべて
試験導入の背景からITSS/ETSS/UISSとの関係、試験概要、
そして出題予測/試験対策まで

041

特別企画2
グーグルのクラウドがPythonに続いてJavaに対応

Google App Engine for Java

ついに企業システム開発技術の本命をサポート。果たしてどこまで使えるのか?
Webアプリケーション環境としての実力を吟味する

106

特別企画3
アーキテクトの必須能力

“抽象化力”を磨け!
「全体を見ながら部分も注視し、共通部分を見いだして範囲を決め、概念化する」
――“抽象化”
という行為の本質と、
その能力の高め方

116

Contents

特別企画4
クラウド時代に現れた“現代版 Java”

マルチパラダイム言語「Scala」
関数型言語とオブジェクト指向言語の特性を併せ持つScala。
登場の背景、メリット、そして並列プログラム/クラウド・アプリ/
DSLでの使いどころを知る

068

●トップ・アーキテクトの履歴書
NTTドコモ

070

斎藤 剛

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

スポーツは体に良いのか、悪いのか
014
067
079
127

目次.indd 1

24
Vo l .

●News & Topics
●Books
●Present
●執筆者紹介

09/07/12 18:17

米国グーグル、
「Google Chrome OS」
を発表
 米国グーグルは今年7月、同社の
公式ブログで「 Google Chrome
OS」
を発表した。ネットブックなどでの
利用を想定した軽量なOSで、
「Linux
カーネル上で動作する新しいウィンド
ウ・システム内でGoogle Chromeが
動く」
(グーグル談)
というシンプルなア
ーキテクチャに基づく
(Chromeは同
社が提供するWebブラウザ)。今年
後半にソース・コードを公開し、来年
後半には一般向けにリリースする。な
お、Chrome OSの開発には、HPや
レノボ、
インテル、
エイサー、
アドビ シス
テムズなどが協力している。

国内大手SIerらが
非機能要件のグレードを策定

MS、
「Windows 7」
日本語版の
発売日を決定

 NTT データや富士通、NECなど
国内大手 SIerらが参加する
「システ
ム基盤の発注者要求を見える化する
非機能要求グレード検討会」
は今年
5 月、システム開発における非機能
要求の検討を支援するためのツール
群「非機能要求グレード」
を同検討会
のWebサイトで公開した。これはITシ
ステムの発注者と受注者との間で明
確に取り決めるのが難しい非機能要
求を、重要な項目から段階的に詳細
化していくためのもので、グレード表
や非機能要求の項目一覧、樹系図
など4つのドキュメントから成る。

 マイクロソフトは今年 7月、同社の
次期 OS「Windows 7」の日本語版
の一般向け発売日を今秋 10月22日
に決定したと発表した。Windows 7
では、処理性能が向上するのに加え
て、タスクバーなどの細かなUIが変更
される。また、Windows XP向けアプ
リケーションを仮想化環境上で起動
できる
「XP MODE」
が用意される。
提供されるエディションは、すべての
機能を含む「Ultimate」、ビジネス・
ユーザー向けの「Professional」、一
般向けの「Home Premium」、低ス
ペックPC向けの「Starter」の4種類。

News & Top i cs
ITシステム開発を巡る
最新動向を伝える

014

news.indd 14

クラウド環境の標準化に向け、
新団体が発足
 今年6月、政府系システムのクラウ
ド・コンピューティング環境の標準化
を目指す団体「OGC
(Open Govern
ment Cloud consortium)」
が発足
した。同団体は、e-Japan 構想の下、
2004 年に政府系システムの標準化
を目的として結成されたOSC
(Open
Standard Consortium)
を前身に、
新たなメンバーを加えて結成されたも
ので、アクセンチュアなど19 社が参
画。クラウド環境の共通基盤構築に
向け、API やガバナンス機能の整備、
仮想データセンターの実現、高度 IT
人材の育成などを行うという。

IDC Japan、IT投資に関する
CIOの意識調査の結果を発表

日本IBM、WebSphereの
企業内クラウド向け製品を発表

新日鉄ソリューションズ、
クラウド検証センターを開設

 IDC Japanは今年7月、国内企業
1,992社のCIOを対象に4月に実施
したIT投資に関する意識調査の結果
を発表した。それによれば、今年度の
IT予算について、
「 削減する」
と回答
した企業が全体の34.6%を占め、
「増加する」の14.1%を上回った。た
だし、
全体の25%程度の企業が、
イン
フラの全社最適化やサーバ/ストレ
ージの統合など、
システムの抜本的な
見直しに着手していると答えており、

うした運用/保守コストの低減を図る
取り組みについては、今後も投資が
続くと同社では見ている。

 日本IBMは今年6月、ハイパーバイ
ザー上で動作するアプリケーション・
サーバ「IBM WebSphere Applicat
ion Server Hypervisor Edition
V1.0」
と、同製品の管理用アプライ
アンス
「同 CloudBurst Appliance
V1.0」
を発表した。Hypervisor Edit
ionは、ハイパーバイザーとしてVMW
are に対応。CloudBurst Applian
ce の管理画面でHypervisor Editi
on のイメージとアプリケーションを組
み合わせて構成情報を定義し、それを
トポロジー構成を指定したうえでハイ
パーバイザー上に配備して実行する。

 新日鉄ソリューションズは今年 7月、
企業向けクラウド・コンピューティング
の検証センター
「NS Cloud Compe
tence Center」
を横浜に開設した。
同センターでは、企業内にクラウド環
境を構築するための技術を開発/検
証するとともに、クラウドの導入を検
討する顧客企業と共同で
「既存シス
テムのクラウド環境への移行/統
合」、
「外部サービス連携システムの
構築」
などに関する技術検証を行う。
クラウド環境の構築/検証は、イン
テルや日本オラクル、日本 IBM、楽
天など11社と共同で実施する。

IT アーキテクト Vol.24

09/07/12 19:00

CA、アプリ性能管理製品群の
新版を発売

日立製作所、JP1の新版で
仮想化環境への対応を強化

 日本 CAは今年 5月、アプリケーシ
ョン性能管理製品群「CA Wily App
lication Performance Manageme
nt」の新版を発売した。新版では、サ
ーバ側のトランザクションを監視する
「同Introscope 8.1」のSOA対応機
能が強化され、サービス間の依存関
係を視覚化したり、サービス実行時
の性能情報をリアルタイムに確認した
りできるようになった。なお同月、同
社はこれまで提供してきたITサービス・
マネジメント系のツール類を統合/整
理した製品群「CA Service Manag
ement」
も発表している。

 日立製作所は今年6月、統合シス
テム運用管理ソフトウェア群の新版
「JP1 Version 9」
を発表した。新版
の特徴は、監視対象マシンにエージェ
ントを導入せずにシステムの監視が
行える
「JP1/Performance Manag
ement - Remote Monitor」
が追加
された点。
これにより、
仮想化によって
サーバを集約した前後での状況把握
や、大規模な仮想化環境の監視など
での作業の手間が軽減される。
また、
仮想化ソフトから物理サーバと仮想マ
シンの構成情報を自動取得すること
が可能になった。

CTCと日本オラクル、日本HP、
インメモリ・データで協業強化

HP、スケールアウト構成向けの
新サーバ・シリーズを発表

  伊 藤 忠テクノソリューションズ
(CTC)
と日本オラクル、
日本HPは今
年5月、
インメモリ・データ・グリッド分野
における協業を強化すると発表した。
3社は、今日多くのITシステムが直面
しているアクセス数の急激な増加、大
量トランザクション処理などの問題へ
の対処策として、
オラクルのインメモ
リ・データ・グリッド製品「Oracle Coh
erence」
とHPのブレード・サーバ「HP
BladeSystem」
を組み合わせたスケ
ールアウト型のシステムを提供する。
両製品を組み合わせた動作検証は
CTCの検証センターで行った。

 日本HPは今年6月、スケールアウト
構成に適したラックマウント型サーバ・
シリーズとして、1,000ノード以上の環
境に向けた
「HP ProLiant SL6000
Scalable System」
と、数十〜数百ノ
ードの環境に向けた「HP ProLiant
DL1000マルチノード サーバー」
を発表
した。前者は、主にクラウド・サービス
の提供者やSaaS 事業者などへの提
供を想定したもので、用途に応じて3タ
イプが提供される。一方、後者はノード
の集積率を高めたサーバで、1台の筐
体に2ノードまたは4ノードを内蔵するこ
とができる。

ソース・コード解析ツール

システム開発/実行基盤

テクマトリックス

野村総合研究所

Understand 2.0 日本語版

製品名
稼働環境


価格


出荷時期
発売元

Understand 2.0 日本語版
【対応 OS】Windows 2000 以降、
Linux
【対応言語】C/C++/C#、Java
Engineer Edition:10 万 2,900 円/
Pro Edition:20 万 7,900 / Analyst
Edition:52 万 2,900 円
出荷済み
(☎ 03-5792-8600)
テクマトリックス

 「Understand 2.0 日本語版」
は、
C/C++/C#、Javaに対応したソー
ス・コード解析ツール。
プログラムの複
雑度を分析/数値化する
「メトリクス
分析機能」や、過去の分析結果との
差分を比較する
「スナップショット機
能」などを備える。GUIなどが日本語
化されている。

ObjectWorks+ R1.5

製品名
稼働環境
価格
出荷時期
発売元

ObjectWorks+ R1.5
要問い合わせ
要問い合わせ
出荷済み
野村総合研究所(☎ 03-6267-9100)

 「 ObjectWorks + R1.5 」は、
Java EE 5に準拠したシステム開発
/実行基盤。新版では、アプリケー
ション・サーバを起動せずに画面や業
務ロジックをテストできる機能や、ソー
ス・コードと開発標準の整合性をチェ
ックする機能、ESB 上の Webサービ
スにシームレスに接続する機能など
が追加された。

E vent C a l e n d a r
8月
e-Learning WORLD 2009

8月5日
(水)〜 7日
(金)
会場:東京ビッグサイト
連絡先:シー・エヌ・ティ
☎:03-5297-8855 FAX:03-5294-0909
E-mail:info2009@elw.jp
URL:http://www.elw.jp/

JavaWorld DAY 2009

8月6日
(木)
会場:THE GRAND HALL(品川)
連絡先:JavaWorld DAY 事務局
☎:03-5510-4079 FAX:03-5510-4078
URL:http://www.idg.co.jp/expo/jwday/2009/

Tech・Ed Japan 2009

8月26日
(水)〜 28日
(金)
会場:パシフィコ横浜
連絡先:マイクロソフト コンファレンス登録事務局
☎:0120-410-693
E-mail:techedjp@microsoft.com
URL:http://www.microsoft.com/japan/teched/2009/

9月
エンタープライズ・リスク・マネジメント2009
9月2日
(水)〜 4日
(金)
会場:東京ビッグサイト
URL:http://expo.nikkeibp.co.jp/erm/2009/

Modeling Forum 2009

9月18日
(金)
会場:東京ミッドタウン・ホール
連絡先:Modeling Forum 統括事務局
☎:03-5800-4831 FAX:03-5800-3973
E-mail:mdl@idg.co.jp
URL:http://www.idg.co.jp/expo/mdl/2009/

東京ゲームショウ2009
9月24日
(木)〜 27日
(日)
会場:幕張メッセ
URL:http://tgs.cesa.or.jp/

10月
CEATEC JAPAN 2009

10月6日
(火)〜 10日
(土)
会場:幕張メッセ
連絡先:CEATEC JAPAN 運営事務局
☎:03-5402-7603 FAX:03-5402-7606
URL:http://www.ceatec.com/2009/pre/ja/

11月
デジタルマーケティングNEXT 2009
11月11日
(水)〜 13日
(金)
会場:東京ビッグサイト
連絡先:デジタルマーケティングNEXT 事務局
☎:03-3434-1988 FAX:03-3434-8076
URL:http://www.jma.or.jp/Digi-Ma/outline/

Embedded Technology 2009

11月18日
(水)〜 20日
(金)
会場:パシフィコ横浜
連絡先:Embedded Technology 運営事務局
☎:03-3219-3563 FAX:03-3219-3628
E-mail:etinfo@jasa.or.jp
URL:http://www.jasa.or.jp/et/

IT アーキテクト Vol.24

news.indd 15

015

09/07/12 19:00

最大の価値は﹁﹃ 要求=状況 ﹄
の変化に対応できること﹂。
〝変わること〟を前提にした開発手法の意義、
導入のポイント、ベスト・プラクティス
ウォーターフォール型開発に潜む問題点を克服する開発手法として、
多くの期待を集め続けている
「アジャイル開発」。
その最大の特徴は、実際に動くソフトウェアをユーザーと繰り返しチェックして、
ソフトウェアに対する要求そのものの精度を高めていくことにある。
それにより、
“望まれないシステム”が作られるのを防ぐのだ。
しかし、そうした大きな利点があるのにもかかわらず、
国内ではアジャイル開発の導入を躊躇する企業が少なくない。
「厳格なルールや計画性のない開発手法」
といった誤解が多いことが、その一因だろう。
無論、そこで言われる
“厳格さ”
とは「要求が変化しない」
ことを前提としたものであり、
これはアジャイル開発の「要求は変化する」
という前提とは正反対のものだ。
その誤った前提を基にしていたのでは、アジャイル開発の価値を正しく評価することはできず、
間違った導入の仕方をしてしまうおそれもある。
本特集では、今日のビジネス環境やウォーターフォール型開発との違いを踏まえて、
アジャイル開発の価値を再確認する。
また併せて、実際にアジャイル開発に取り組む企業の声を紹介してみたい。

宗 雅彦

Masahiko Soh

サイクス 代表取締役

016

IT アーキテクト Vol.24

toku01.indd 16

09/07/12 18:48

特集 1

システム開発の

アジリティ向上は

ビジネスの要請

IT アーキテクト Vol.24

toku01.indd 17

017

09/07/12 18:48

いまだ根強い
アジャイル開発への誤解

 アジャイル・カンパニーが注目されたのは、当時、企
業を取り巻く環境が大きく変化していたためだ。そして今
日、その変化のスピードは、ますます速くなってきている。

 アジャイル開発が国内に紹介されて久しい。この開

例えば、今年4月から6月にかけて、米国の大手自動車

発手法には多くの利点があるが、現状では広く普及す

メーカーであるクライスラーとゼネラルモーターズが立て

るまでには至っていない。それは、なぜだろうか。

続けに破綻した。この例からもわかるように、現在の経

 筆者がさまざまな開発現場で見聞きしたところでは、

済環境は、かつて米国経済の屋台骨を支えた企業で

アジャイル開発に対して「ドキュメントをほとんど書かず、

も先が読めないほど不確実性に満ちているのだ。

場当たり的に対処する開発者向けの手法」
という印象
を抱いている方が、とりわけマネジメント層に多いように感

「予測、仮説立案、検証」のサイクル

じる。そのため、アジャイル開発の導入が進まないのかも

 先に、アジャイル・カンパニーとは俊敏な企業のことだ

しれない。

と述べたが、
「アジャイルである」
というのは、単に速く動

 しかし、本当のアジャイル開発とは、そのようなアプロー

けることだけを指すわけではない。速く動けることは必要

チではない。上記のような誤解を受けているのは、アジャイ

だが、それだけでは十分ではないのである。将来起きる

ル開発への理解が不足しており、
「アジャイル開発がもた

変化が明らかになってから動き始めたのでは、どんなに

らす価値」が十分に認識されていないことが原因ではな

速く動いたとしても後追いにすぎないからだ。

いだろうか。アジャイル開発の最大の価値は、開発途中

 ここで言う
「環境の変化」には、さまざまな事象が含ま

のソフトウェアを繰り返しユーザーと確認し、要求を正しい

れるが、その中でも市場の変化、つまり顧客ニーズの変

ものへと適宜改善していくことにある。この価値を理解する

化に最も目を向けるべきである。重要なのは、そうした将

ために、まず今日のビジネス環境の特徴と、アジャイル開

来のニーズの変化を予測し、今、顧客が期待している

発が基盤とするコンセプトを確認していこう。

製品/サービスに関する仮説を立て、変化が起きる前に
動き出すことだ。そうすれば、顧客の真の期待を満たしつ

アジャイル・カンパニーと
今日の経済環境

つ、自社の利益を高められる可能性が高まるだろう。
 ただし、当然のことながら、顧客ニーズの変化を正確
に予測するのは容易ではない。さらに昨今では、変化の

 一昔前の話になるが、1990 年代の前半、限界を露

スピードが増しており、顧客が真に望んでいる製品/サ

呈しつつあった「BPR(Business Process Reengine

ービスを、企画の段階で完璧に計画するのはほぼ不可

ering)」に代わって、
「アジャイル・カンパニー」
と呼ばれ

能だ。そのため、
「計画は途中で変わるもの」
と覚悟した

る経営コンセプトが注目を集めたことがある。このアジャイ

うえで、
「変化を予測し、仮説を立て、それを検証する」

ル・カンパニーとは、経済環境が変化する中で市場機

というサイクルを可能な限り短い期間で実行し続けるとい

会を素早く見つけ、製品を迅速かつ効率的に市場に

うアプローチが必要になってくる。

送り出すことのできる
「俊敏な企業」のことを指す。後述

018

するが、この経営コンセプトをソフトウェア開発の分野に

アジャイル・カンパニーとアジャイル開発

適用したものがアジャイル開発なのである。

 以上のことから、今日におけるアジャイル・カンパニーと

IT アーキテクト Vol.24

toku01.indd 18

09/07/12 18:48

は、次のように定義できるだろう。
高価値の製品/サービスを迅速かつ持続的に
顧客に提供することを最大の目的として、要求の
変化が激しい今日の状況に対応するために、
「予測、仮説立案、検証」のサイクルを繰り返し
行う
「俊敏な企業」
 先述したように、このアジャイル・カンパニーの概念をソ

し、変化というリスクを積極的に受け入れることで、ユー
ザーにとっての価値を最大化したソフトウェアを作るため
のアプローチなのだ。今日の市場動向など経営環境の
変化の激しさを考えれば、今こそ必要とされる開発手法
だと言えるだろう。

米国と日本の普及状況の違い
 それでは現状、アジャイル開発はどの程度受け入れら

のことは、アジャイル開発の
“原典”
にも見て取れる。

れているのだろうか。まずは先行する米国の状況を確認

 2001年に米国ユタ州において、Kent Beck氏やMa

してみよう。

rtin Fowler氏といった17名の著名な開発者が結集し、

 図1に示すのは、米国Dr.Dobb's Journal誌の調査

『アジャイル開発マニフェスト』
(http://www.agileman

で明らかになった、アジャイル開発を経験したことのある

ifesto.org/)
をまとめた。このマニフェストは、アジャイル

米国企業の割合だ。ご覧のとおり、69%の企業が「アジ

開発を初めて定義した文書として知られ、アジャイル開

ャイル開発の導入経験がある」
と回答している。メディア

発の「価値」

「原則」が記されている。このうち、原則

が度々報じているように、日本国内で行われる開発プロ

は12カ条から成るが、その最初の2カ条を次に抜粋して

ジェクトでは極めて高い割合でウォーターフォール型開

みよう
(オリジナルは英文であり、以下はその拙訳)。

発が採用されるが
(筆者の経験では100%に近い)、こ

●開発の初期からソフトウェアを継続的に引き渡
し、ユーザーの満足度を高めることを最優先す

●要求の変更は、開発の終盤であっても受け入
れる。アジャイル開発は、こうした変化を味方

特集 1

フトウェア開発に適用したのがアジャイル開発である。こ

の状況と比べると、米国企業の69%という割合は驚くべ
き値である※1。
※ 1 ソフトウェアの品質に関する技術情報サイト
「SearchSoftwareQuali
ty.com」の調査リポート
『2008 Agile Trends survey』
(http://searchsoft
warequality.techtarget.com/news/article/0,289142,sid92_gci
1318992,00/)
でも、46%の企業がアジャイル開発を導入しているという結
果が出ている
(ウォーターフォール型開発を採用する企業は44%)

にすることで、ユーザーの競争力を引き上げる
 これらの原則から、アジャイル開発マニフェストが次の

図1:アジャイル開発を実践したことのある米国企業の割合(出典:Dr.Dobb's
   Journal 2008 Agile Adoption Survey / URL:http://www.ambys
   oft.com/surveys/agileFebruary2008.html)

ようなアジャイル・カンパニーのコンセプトを継承しているこ
とがわかるだろう。
●顧客にとっての価値(顧客価値)
を最も重視する
●顧客価値を最大化するために、変化(要求の変更)
を積極的に受け入れる

経験なし
(31%)
経験あり
(69%)

●できる限り早く、継続的に製品(ソフトウェア)
をリリース
する
 つまり、アジャイル開発は、要求の不確実性を前提と

IT アーキテクト Vol.24

toku01.indd 19

019

09/07/12 18:48

 こうした日本と米国の現状を、ある技術が市場にどの

 このように、普及が進む米国では、同一拠点型の場

程度受け入れられているのかを示す「テクノロジー・ライ

合でも分散拠点型の場合でも、多くのプロジェクトがア

フサイクル」にマッピングしたのが図2である。この図の揺

ジャイル開発によって一定の成果を得ているのだ。

籃期と成長期の間にある
「キャズム」
とは、対象の技術
が成長期に移行していくために超えなければならない断
層を意味する。このキャズムを超えることができず、揺籃
期にとどまったまま消滅していく技術もあれば、キャズムを

ウォーターフォール型開発が
衰退する理由

超えて大きな成長カーブに乗っていく技術もある。

 米国ではアジャイル開発が主流となりつつある一方

 米国の場合、アジャイル開発はすでに成長期を経過

で、従来のウォーターフォール型開発を採用する企業

し、成熟期に入ったと言える。しかし、日本では、いまだ

は少なくなってきている。それは、なぜだろうか。ここでは、

キャズムを超えられず、揺籃期にある状態だ。また、米

ウォーターフォール型開発が前提とする条件を確認した

国においては、アジャイル開発に主流が移りつつある中

うえで、その条件と、今日におけるソフトウェア開発との適

で、ウォーターフォール型開発プロセスが成熟期から衰

合性について考察する。

退期へと向かいつつある
(日本では成長期から成熟期
に位置するだろう)。

ウォーターフォール型開発の前提条件
 まず、ウォーターフォール型開発の前提条件を説明

調査結果から見たアジャイル開発の効能
 このように、米国ではすでに多くの企業がアジャイル開
発を取り入れており、アジャイル開発に関する調査結果

図2:テクノロジー・ライフサイクルで比較したアジャイル開発の普及状況
米国

も多数存在する。ここで、それらの調査結果を基に、アジ
ャイル開発の効果を紹介しよう。
 まず、図 3に示すのは、先のDr.Dobb's Journal 誌
の調査で判明した、アジャイル開発を採用したプロジェ
クトの成功率である。一般的な開発プロジェクトの成功
率は30%程度だと言われるが、図 3ではどの条件でもそ
の値を超えており、アジャイル開発を採用した場合の成
功率の高さが読み取れる。特に、通常は成功率が低
下するオフショア/アウトソーシングのプロジェクトでも、高
い成功率を収めている点は注目に値する。
 次に、図4と図5を見てみよう。これらはそれぞれ、アジャ
イル開発を採用したプロジェクトにおいて、生産性と成果
物の品質がどの程度かを示したグラフだ。
「極めて高い」

「いくらか高い」
を合わせると、生産性は81%、成果物
の品質は77%と、互いに高い評価を受けている。

020

日本

成長期

成熟期

衰退期

揺籃期
キャズム
図3:アジャイル開発を採用したプロジェクトの成功率
(出典:Dr.Dobb's Journal 2008 Agile Adoption Survey)
すべての行程で
採用したプロジェクト

77.5%

開発チームが同一拠点に
集まっていたプロジェクト

82.7%

開発チームが分散していた
プロジェクト

71.7%

オフショア/アウトソーシングを
利用したプロジェクト

59.5%
0

20

40

60

80

100

プロジェクトの成功率(%)

IT アーキテクト Vol.24

toku01.indd 20

09/07/12 18:48

するにあたり、プロジェクトが達成すべき目標(プロジェク
ト・スコープ)
を簡略化したモデルを紹介しておこう。
 一般に、プロジェクト・スコープは「QSCD(Quality:
品質/Scope:機能スコープ/Cost:コスト/Delivery
Date:納期)」によって表すことができる
(図 6)。この
QSCDのうち、図中に青い罫線で示した「Q+S」は、プ

●開発プロセス全体をシーケンシャルな工程の並びに
分解できる
●次の工程に移行する前に、現在の工程を完了するこ
とができる
●最初にすべての要求を仕様化し、次のアーキテクチ
ャ設計に渡すことができる
 この中で特に注目してほしいのは、3つ目の前提条件

ト・スコープ)
となる。言いかえると、プロジェクト・スコープ

だ。ここには「最初にすべての要求を仕様化」
とあるが、

とは、プロダクト・スコープと、
「C+D」で表されるプロジェ

実際のソフトウェア開発では要求の追加/変更が頻繁

クトの制約条件を合わせたものである。

に発生する。その追加/変更に対して、ウォーターフォー

 このプロジェクト・スコープを満たすうえで、ウォーター

ル型開発では、コスト
(C)
や納期
(D)
の部分にバッファを

フォール型開発は次のような前提条件を持つ。

持たせるとともに※ 2、バッファを超過しないよう、要求の追

特集 1

ロジェクトの成果物であるソフトウェアのスコープ
(プロダク

加/変更を抑制する方向でコントロールするのである。
図4:アジャイル開発の生産性
(出典:Dr.Dobb's Journal 2008 Agile Adoption Survey)
きわめて低い
2%
いくらか低い
4%

変わらない
13%

とても高い
22%

もはや前提条件は破綻
 しかし今日、企業を取り巻くビジネス環境は変化が激
しくなり、顧客(ユーザー)
のニーズは変わりやすい状況
にある。こうした中で、バッファを正確に見積もるのは至
難の業だ。
 また、
「ユーザーにとって価値の高いソフトウェアを提

いくらか高い
59%

図5:アジャイル開発における成果物の品質
(出典:Dr.Dobb's Journal 2008 Agile Adoption Survey)
きわめて低い
3%
いくらか低い
6%

変わらない
14%

※ 2 ウォーターフォール型開発では、少なくとも、そうしたプラクティスを実施
することが推奨されている。しかし、筆者の経験上、現実にはリスク要因を考
慮していない
(バッファを持たせていない)
プロジェクトが多いようだ。

図6:プロジェクト・スコープとプロダクト・スコープ
プロジェクト・スコープ
プロダクト・スコープ
Q
品質

とても高い
29%
C
コスト

D
納期

いくらか高い
48%
S
機能スコープ

IT アーキテクト Vol.24

toku01.indd 21

021

09/07/12 18:48

供する」
という観点で考えたとき、それを実現するのに必

われていく。また、作成済みの成果物を手直しするの

要な要求(ユーザーが最も実装してほしいと思う要求)

で、工数が膨らむ

を、最初の要求定義の段階ですべて定義できるという

●単体テストに入ると、蓄積された欠陥が一挙に顕在

保証は何もない。これは、
「ダイナミックに変化し続ける

化する。全力でリワークに注力するが、期限が迫って

要求を後追いで必死になって追いかけていけば、どうに

いるため、時には修正が完了しないまま、結合テストに

かなる」
という話ではない。要求定義が完了し、アーキテ

突入せざるをえない。しかし、ソフトウェア全体の一貫

クチャ設計から実装、テストへと移行していく中で、ユー

性はすでに失われており、欠陥の嵐に翻弄されること

ザーにとって価値のある要求をいつ発見できるかは、だ

になる

れにもわからないのだ。

 こうした問題が生じる本質的な原因は、ウォーターフ

 このように、要求定義のプロセスが不確実性を内包

ォール型開発の前提条件が「最初に正しい要求を確

する場合、ウォーターフォール型開発の前提条件はこと

定し、最後に厳しく検査する」
という、大昔の製造業の

ごとく崩れてしまう。要求定義ですべての要求を確定す

製造ラインの考え方を基にしているためだ。つまり、要求

ることはできず、そのため「次の工程(アーキテクチャ設

定義からテストまでの
“距離”
が長いのである。最終工程

計)
に移行する前に、最初の工程(要求定義)
を完了

であるテストに入って初めて、ソフトウェアに潜む膨大な

することができる」
という前提も成り立たなくなる。この結

数の欠陥に気づき、それらのリワークに追われることにな

果、次のような問題が起きるだろう
(図7)。

るのだ。

●すべての要求を確定できないまま、期限が到来して
要求定義を完了せざるをえない。そのため、とりあえず

要求の不確定性原理

曖昧な要求仕様を作成し、次のアーキテクチャ設計

 ウォーターフォール型開発が今日のソフトウェア開発

に移行する

に適合しにくい原因を、もう1つ説明しよう。それは、
「要

●アーキテクチャ設計から実装へと工程を進める中で、

求の不確定性原理」に関する問題である。

要求の追加/変更に対応するために、要求仕様や

 この原理は、
「ソフトウェアを新しく作る場合、ユーザ

設計書、ソース・コード、テスト・ケースなどを修正し続

ーは、それを使い始めるまで要求を認知できない」
という

けることになる。そして、頻繁に成果物に手を入れるこ

ものである。つまり、ユーザーは自身の要求を、それが具

とで、修正ミスが増え、それらが欠陥として蓄積されて

現化されたソフトウェアを使ってみるまでは、本質的に理

いくとともに、ソフトウェア全体の一貫性が少しずつ失

解できないということである※3。
 要求の不確定性原理は、ウォーターフォール型開発の

図7:ウォーターフォール型開発の問題点
最初に正しい要求を
すべて用意する
要求定義

アーキテクチャ
設計

最後に厳しく検査する
(欠陥が一挙に検出される)
実装

テスト

すべての要求を大きなバッチとして並行に処理する

「最初にすべての要求を仕様化し、次のアーキテクチャ
設計に渡すことができる」
という前提条件とは相反する。
すなわち、ウォーターフォール型開発における
「最後に厳し
く検査した後で、ユーザーにソフトウェアを届ける」
というコ

要求の
“在庫”

一挙に検出された欠陥のリワークに追われる

022

※3 要求の不確定性原理については、書籍『パーソナルソフトウェアプロセ
ス技法』
(著者:Watts S. Humphrey/発行:共立出版/発行年:1999年)
で詳しく解説されている。興味のある方は、こちらの書籍をご覧いただきたい。

IT アーキテクト Vol.24

toku01.indd 22

09/07/12 18:48

クに追われる」、あるいは「使ってみて初めて不要な要求
だったことが判明する」
といった問題を引き起こす可能性
があるのだ。通常は、上流工程でレビューやプロトタイピ
ングを行うことでこれらの問題を避けるのだが、不確実性
をはらむ環境下において、それは難しい。

アジャイル開発の特徴

ターフォール型開発ではその変化に適応するのが困難
であることを述べてきた。それでは、アジャイル開発は、ど
のようにして要求の変化に対応するのだろうか。続いて
は、アジャイル開発の特徴を説明していこう。

アジャイル開発の4つの特性
 一般に、アジャイル開発とは、要求定義から設計、
実装、テストというプロセスを短期間で繰り返しながら進
めていく開発手法のことを指す。見積もり手法の「COC
OMO」などを考案したBarry Boehm氏の著書『アジャ
イルと規律』
(発行:日経BP社/発行年:2004年)
では、
「アジャイルな開発方法論」
と認められるためには、次の
4つの特性を備えていなければならないとされている。
●インクリメンタル:ソフトウェア全体をいくつかの部分
に分割し、それぞれを個別に開発したうえで、少しず
つ全体に統合していくこと。分割した個々の部分のこ
とを
「インクリメント」
と呼ぶ
●イテレーティブ:ソフトウェア全体、あるいは各インクリメ
ントの開発を反復して行いながら、ソフトウェアの機
能/品質を洗練していくこと。最初は中核部分だけ、
もしくは全体を
“薄く”作り、ユーザーに見せてフィード
バックを反映させながら少しずつ肉付けしていくといっ

高仁氏
(同社代表取締役)
と言えば、かつて
KDDIでCIOを務めた知る人ぞ知る人物だ。
その繁野氏が、最近はアジャイル開発の信
奉者だと聞いて驚く方がいるかもしれない。
KDDI 時代のプロジェクトではウォーターフォ
ール型が主だったが、情報システム総研で
扱う案件ではアジャイル開発を駆使している
という。
 アジャイル開発に対する繁野氏の評価は、
「スピード感も開発コストも、ウォーターフォー
ル型開発とはまったく違う。格段に早く、安く
ソフトウェアを作れる」
と極めて高い。なかで
も、
「要求の変化に迅速に対応できること」
が最大の利点である。
 「今日の業務システム開発では、要求が
頻繁に変わっていく。その変化に素早く追随
し、顧客が本当に望んでいるソフトウェアを
実現できることが、アジャイル開発のメリット

特集 1

り、ユーザーの要求が頻繁に変化すること、そしてウォー

元 CIO が今日の情報システム部門に求める〝覚悟〟

 ここまで、今日のビジネス環境が不確実性に満ちてお

﹁もはやアジャイル開発の導入は不可避。
時代の変化に適応するために、
ユーザー企業も腹を決めろ﹂

ンセプトは、先に述べた「欠陥が一挙に検出され、
リワー

 現在、情報システム総研を率いる繁野

だ」
(繁野氏)
 繁野氏の下でアジャイル開発プロジェクト
の実践を支援する原田 騎郎氏
(情報システ
ム総研 シニアコンサルタント)
も、その意見
に同調する。氏が最近かかわった受発注シ
ステムの再構築プロジェクトでは、実際にア
ジャイル開発を採用し、複数回のイテレーシ
ョンの中で顧客に何度か実装を確認してもら
いながら、予定よりも早くシステムを完成させ
た。新システムの出来栄えに満足した業務
部門では、旧システムからの移行を前倒しし
ようとの声が上がっているという。
 このように、
“開発期間”

“コスト”
、そして
“要求への対応度”
など多くの面で、アジャイ
ル開発はユーザー企業に大きなメリットをもた
らす。
「もはや、アジャイル開発を導入しない
理由はない」
(繁野氏)
のだ。しかし、現実に
はいまだ多くの企業がアジャイル開発の導
入に二の足を踏んでいる。その理由を繁野
氏は、
「新たな開発プロセスの導入は、組織
にとっても、また個々の技術者や、特にマネ
ジャーにとって、大きなリスクとなるからだろ
う」
と推測する。だが、
“変化すること”
がもは
や当たり前となった現在のビジネス環境に適
応しようと思えば、アジャイル開発の導入は
不可避である。ユーザー企業には今、自らリ
スクをとる覚悟が求められている。その先に、
IT活用の新たな地平が広がっているのだ。

たイメージになる。1 回の反復のことを
「イテレーション」
情報システム総研の繁野氏
(右)
と原田氏。同社で
は、アジャイル開発方
法論「Scrum」
をベー
スにした開発プロセス
を用いている

IT アーキテクト Vol.24

toku01.indd 23

023

09/07/12 18:48

と呼ぶ
●自己組織化:仕事を進めるうえで最善のやり方を、開
発チームが自ら判断すること

てる
②イテレーションの完了時に、その時点のソフトウェアをリ
リースする
(イテレーション・リリース)

●創発:開発プロセスや設計/開発の原則、各作業

③イテレーション・リリースの後に、ユーザーがソフトウェ

の手順などを、プロジェクトの最初の段階で詳細まで

アを確認する。そのフィードバックを基にして、必要が

すべて決めてから始めるのではなく、途中段階で状

あれば実装済みの機能を修正したり、コードをリファ

況に応じて最善と思われるやり方を決めていくこと

クタリングしたりする

 これらのうち、イテレーティブについては、前出のアジャイ
ル開発マニフェストにも、
「2∼3週間から2∼3カ月というで

④次のイテレーションに進む。そして、イテレーションの回
数だけ②∼④を繰り返す

きるだけ短い期間ごとに、実際に動作するソフトウェアをユ

 なお、イテレーションを進めるうえで、アジャイル開発で

ーザーに引き渡す」
といった具合に、同じような原則が記

は次のようなプラクティスを採用することが推奨されてい

されている。つまり、アジャイル開発では、イテレーティブな

る。

サイクルを繰り返しながら、ユーザーにソフトウェアを届け

●イテレーションの実施中に、ストーリーの追加/変更

続けることになる。さらに、同マニフェストには、
「動いている

を行わない
(このプラクティスを「要求のタイムボックス

ソフトウェアこそ、進捗を計るうえで最も重要な尺度である」

管理」
と呼ぶ)

という原則もある。ユーザーにとって最も価値のあるソフトウ

●あるイテレーションにおいて、予定していたプロダクト・

ェアそのものを届けていくことが、プロジェクトの進捗を計る

スコープを達成できないことが明らかになった場合、そ

ための最大の基準になるというわけだ。

のイテレーションの期日は変更せずに、プロダクト・スコ
ープを縮小して対応する

要求の表現形式と実装の方法

●フィードバックの際に要求の追加/変更があれば、

 アジャイル開発における要求の表現形式と実装の方

次のイテレーションの開始時に各イテレーションに割り

法は、従来のウォーターフォール型開発とは異なる。

当てるストーリーを再検討する

 ほとんどのアジャイル開発方法論では、要求は「ストー

 これらのプラクティスには、以下のような効果がある。

リー」
というかたちで表す。これは、後から調整が効くよう

●イテレーション・リリースを継続して行うことにより、ソフト

形式にはこだわらずに表現したもので、例えば「注文処

ウェアが要求を正しく満たしているかどうかを、短いサ

理の担当者は、顧客が選んだ書籍に対する請求書を

イクルで頻繁に検証することができる

発行することができる」
といった具合に簡易に記述する。
アジャイル開発では、このストーリーに優先順位を付け、

●実装する要求をイテレーションごとに再計画するため、
変化する要求にダイナミックに適応できる

重要なものから順番に開発していく。

 これらの効果からもわかるように、アジャイル開発は、

 図 8に示すのは、アジャイル開発の標準的なプロセス

今日の開発プロジェクトが直面している
「要求の不確定

だ。この一連のプロセスでは、主に次のようなことが行わ

性原理」

「要求のダイナミックな変化」
という課題に適

れる。
①取り決めたイテレーション期間(一般には2∼4 週間)
に実装可能なストーリーを、各イテレーションに割り当

図8:アジャイル開発の標準的なプロセス
フィード
フィード
イテレーションA
イテレーションB
イテレーションC
バック
バック
いくつかの
いくつかの
いくつかの
ストーリーを
ストーリーを
ストーリーを
実装する
実装する
実装する

インクリメンタルな開発

024

顧客への
リリース

IT アーキテクト Vol.24

toku01.indd 24

09/07/12 18:48

応したプラクティスを備えているのだ。

フローは、テストの面での効果も大きい。
 先述のとおり、ウォーターフォール型開発のテスト工程

イテレーションによる開発生産性の向上

では、最後にすべての欠陥を検出することによって大量

 加えて、アジャイル開発の短いイテレーション期間に

の手戻りを一挙に生み出す。だが、アジャイル開発のよ
うに各イテレーションでテストを実施すれば、1 回のテスト
で発生する手戻りの量はイテレーションの回数だけ平準

 待ち行列理論によると、バッチ
(処理すべき対象)

化されて少なくなる。

サイズを小さくすれば、待ち行列(キュー)
にある作業対

 さらに、アジャイル開発では、
「実装に変更を加えた

象物の処理待ち時間が短くなる。すなわち、作業対象

ら、すぐにテストを行う」
ことを重視している。これを実現す

物を分割して処理するように変えるだけで、作業効率が

るため、
「テスト駆動型開発※ 6」や「継続的インテグレー

大きく向上することになるのだ。

ション※ 7」
といったテストの自動化に関するプラクティスが

 では、まずウォーターフォール型開発の場合を検討し

存在する。もちろん、開発プロセスをいくつかのイテレーシ

てみよう。この手法には前述したように「最初にすべての

ョンに区切るだけで、まとめて一度にテストするよりも手戻

要求を仕様化し、次のアーキテクチャ設計に渡すことが

りを少なくできるが、これらのプラクティスを実施すれば、さ

できる」
という前提条件がある。言いかえると、プロジェクト

らなる効率化が期待できるだろう。

特集 1

は、開発生産性を高める効果もある。これについて、待
ち行列モデルを使って考えてみよう。

で生じる最大規模の
“要求バッチ”
が次工程に流され、
それらをすべて並行して処理するのが前提になっていると
いうことだ。つまり、各工程間では、そのプロジェクトにおけ
る最大規模の作業対象物が、処理を待つ
“在庫※4”
とな

アジャイルは大規模開発に
適応できるのか

るのである。

 以上の特性を備えるアジャイル開発は、今日の経済

 一方、アジャイル開発では、各イテレーションで処理す

環境に適応した開発手法であると言える。しかしもちろ

る要求バッチの数は、ウォーターフォール型開発におけ

ん、どのようなプロジェクトにも適用できる万能なアプロー

る要求バッチの数をイテレーションの数で割った値とな

チだというわけではない。

る。そのため、イテレーションの期間が短ければ短いほ

 例えば、企業におけるソフトウェア開発には大規模な

ど、各イテレーションで処理する要求バッチの数は減り、

ものが少なくないが、アジャイル開発は、そうした大規模

在庫は極小化されていく。

なプロジェクトへの適用が困難だと言われることがある。

 なお、それぞれの開発手法が持つこうした特性は、ウ

確かに、アジャイル開発方法論の1つである
「XP(Extr

ォーターフォール型開発が昔の製造業の生産ラインを、
アジャイル開発が在庫ゼロを標榜するトヨタ自動車の「ジ
ャスト・イン・タイム生産方式」を基にしていることに起因
する※5。

テストにおける手戻りの改善
 さらに、短いイテレーションを繰り返すアジャイル開発の

※4 ここでは、
「次工程で処理すべき要件仕様」
という意味で使っている。
※5 なかでも、
「リーン・ソフトウェア開発」
というアジャイル開発方法論は、

ヨタの生産方式全般を参考にしていると言われる。
※ 6 プログラムよりも先にテスト・ケースを書く開発スタイル。このプラクティ
スを効率良く実施するために、テストを自動的に実行するツールも作られてい
る。
※ 7 ソース・コードのビルド/テストを頻繁に行うこと。変更が生じる度に行
うことが推奨されている。

IT アーキテクト Vol.24

toku01.indd 25

025

09/07/12 18:48

eme Programming)」は、20 名が開発メンバー数の

トにおける総合的なリスクとなる。なお、総合的なリスクが

絶対的な上限だとされ、小規模なプロジェクト向けだと

最小になる部分は「スイート・スポット」
という。

言われている。

 図10からは、プロジェクトの規模が大きくなればなるほ

 では、アジャイル開発を大規模なプロジェクトに適用

ど、計画策定に多くの工数を割かなければ、総合的な

するのは不可能なのだろうか。以下、このテーマについ

リスクは低下しないことがわかる。工数を割り当てすぎると

て考えてみよう。

後工程が圧迫されるが、それでも大規模なプロジェクト

 図9に、前出のDr.Dobb's Journal誌の調査による、

では計画策定が重要なのだ。

アジャイル開発を導入したプロジェクトにおける開発チー

 大規模プロジェクトの場合、ウォーターフォール型開

ムの要員数を示す。この図からわかるように、いくつかの

発と同じように、プロジェクトの初期段階で要求定義や

組織では、ある程度規模が大きいプロジェクトにアジャイ

アーキテクチャ設計をしっかりと行ってソフトウェア全体を

ル開発を適用して成功を収めている。よって、アジャイル

俯瞰することが必要になる。ただし、その後の実装/テス

開発が必ずしも大規模プロジェクトに向かないというわけ

トでは、要求の変更への対応のしやすさ、開発生産性

ではないのだ。

の高さといった特徴を備えるアジャイル型開発が求めら

 ただし、大規模開発には、比較的規模が小さいプロ

れる場面が少なくない。したがって、双方の開発手法を

ジェクトにはない、特別な側面がある。それは、開発の

融合したアプローチが有効だと言える。

初期段階における計画策定(ここで言う計画とは、要

 このように、プロジェクトの規模により、初期の要求定

求定義やアーキテクチャ設計のことを指す)
が重要だと

義やアーキテクチャ設計の重要性は変わる。これが、シ

いうことだ。

ンプルな設計を重視するXPが小規模なプロジェクト向

 図 10に示すのは、プロジェクトの規模とリスク
(プロジェ

けだとされるゆえんであり、ウォーターフォール型開発と同

クトが失敗する確率)
の関係である。この図の横軸は、

じく初期段階でソフトウェア全体の要求定義やアーキテ

計画策定にかける工数の割合を表している。実線のカー

クチャ設計をある程度まで行う
「FDD(Feature Driv

ブは、プロジェクトの規模に対して一定の割合で計画策

en Development:フィーチャ駆動型開発)」が大規模

定に工数を割けば、リスクが減少すること意味する。一

プロジェクトに適応できると言われる理由だ。

方、点線のカーブは、計画策定に工数をかけすぎると後
工程が圧迫されるため、逆にリスクが大きくなることを示
す。この実線と破線のリスクを合計したものが、プロジェク

図10:プロジェクトの規模とリスクの関係
(出典:
『アジャイルと規律』/著者:Barry W. Boehm、
ほか/発行:
日経BP社/発行年:2004年)

大規模開発の場合
中規模開発の場合
小規模開発の場合

図9:アジャイル開発を採用したプロジェクトの要員数
(出典:Dr.Dobb's Journal 2008 Agile Adoption Survey)
6
5

101∼200人

1
6

51∼100人

8

16

中規模開発の
スイート・スポット

24
29

21∼50人

66

11∼20人

小規模開発の
スイート・スポット

84

6∼10人

30

60

90

プロジェクトの数

120

150

計画にかける工数の割合

0

114

95

142

126

1∼5人

026

大規模開発の
スイート・スポット

成功したプロジェクト
試行レベルのプロジェクト
(成否問わず)
リスク

200人以上

※ この図の実線が示す値は、見積もり手法の
「COCOMO II」
を使って算出
  している。

IT アーキテクト Vol.24

toku01.indd 26

09/07/12 18:49

 前節でも触れたが、アジャイル開発とウォーターフォー
ル型開発には、それぞれに向き/不向きがある。
「アジャ
イル開発 vs. ウォーターフォール型開発」
というステレオタ
イプな比較は意味を持たないのだ。
 ウォーターフォール型開発が向くのは、最終的な要
求が早い段階から高い精度で予測できるプロジェクトで

ソフトウェア開発では、そうしたプロジェクトはめっきり減っ
てしまった。むしろ現在のソフトウェア開発では、冒頭に
述べたように、要求の追加/変更が頻繁に発生する。
そうした意味では、
「ウォーターフォール型開発は、今日
の開発手法としてふさわしくない」
と言えるかもしれない。
 しかし、ウォーターフォール型開発には、大規模なソフ
トウェア開発に適応するという特徴がある。
「慣れ親しん
でいるから」
という理由だけでこの開発手法に固執する
のは避けるべきだが、アジャイル開発と融合させれば、
大規模開発に適用可能で、なおかつアジャイル開発の
メリットも併せ持った開発プロセスを作り出せるかもしれな
い。今、必要なのは、そうした開発プロセスを一刻も早く
確立し、プロジェクトの成功率を高め、顧客が真に求め
るシステムを実現することであろう。

アジャイル開発の価値を
再確認するための5冊

●『アジャイルソフトウェアマネジメント』
(著
者:David J. Anderson/発行:日刊工
業新聞社/発行年:2006年)
●『初めてのアジャイル開発』
(著者:Craig
Larman、ほか/発行:日経 BP 社/発行
年:2004年)
●『アジャイルと規律』
( 著者:Barry Boe
hm、ほか/発行:日経 BP 社/発行年:
2004年)

積極的に取り組んでいるところもある。その
1社が、三菱UFJフィナンシャル・グループの
子会社である三菱UFJインフォメーションテク
ノロジー
(旧 UFJIS)
だ。同社では、昨年から
アジャイル開発の導入に取り組んできた。そ
の中でアーキテクトとして中心的な役割を果
たしている同社 ITプロデュース部部長の千
貫 素成氏は、アジャイル開発を導入する際
のポイントを次のように説明する。
 「まず、予算の立て方をアジャイル開発に
合わせる必要がある。ウォーターフォール型
開発に即した現行の契約体系や予算フロー
を変えなくては始まらない」
 加えて、さらに重要なのが、
「業務部門の
協力を取り付け、適切な要求が生み出せる
体制を整備すること」
(千貫氏)
だという。実

特集 1

まり要求の追加/変更が少ないということだが、昨今の

ユーザー企業のアーキテクトが説く、
アジャイル導入の秘訣

ある。最終的な要求が早期に確定できるというのは、つ

﹁業務部門の協力を得やすいよう、
わかりやすくメリットを示し、
導入の負担を軽減せよ﹂

国内の開発現場に適した
アジャイル・プロセスを

 現状、国内でアジャイル開発はあまり普及
していないが、なかにはユーザー企業として

は同社では以前、これが原因でアジャイル
開発の導入に失敗している。予算の立て方
は変えたものの、業務部門の協力を十分に
得られなかったのである。
 アジャイル開発の特徴の 1 つである
「イテ
レーションごとの受け入れテスト」
は、日々の
業務に追われる業務担当者にとって負担が
大きく、単にお願いするだけで協力を引き出
すのは困難だ。そこで同社では、アジャイル
開発のコスト・メリットを説くことにより、業務
部門の合意を得た。また、業務担当者にか
かる負担を減らすために、業務コンサルタント
を雇って受け入れテストに参画してもらい、
第三者の立場で問題点をチェックさせたとい
う。
「業務部門に対し、メリットをわかりやすく
提示するとともに、導入の負担を極力軽減
する」̶̶これが、千貫氏がつかんだアジャ
イル導入の秘訣だ。

三菱UFJインフォメーションテ
クノロジーの千貫氏。同
社では、グループ企業
のシステム構築を担う
とともに、自社開発の
ITソリューションの外
販も行っている。写
真右は、そうしたソリ
ューションの 1 つであ
るペーパーレス会議シ
ステム
「トルネードディス
プレイ」

●『パーソナルソフトウェアプロセス技法』
(著者:Watts S. Humphrey/発行:共
立出版/発行年:1999年)
●『アジャイルな見積りと計画づくり』
(著者:
Mike Cohn/発行:毎日コミュニケーショ
ンズ/発行年:2009年)

IT アーキテクト Vol.24

toku01.indd 27

027

09/07/12 18:49

いよいよアーキテクトの
国家資格試験がスタート!

線幅:0.05mm
間隔:0.5mm
-30 度

K100% オーバープリント

特別企画1

情報処理技術者試験

のすべて

試験導入の背景からITSS/ETSS/UISSとの関係、試験概要、そして出題予測/試験対策まで

創設から40 年を迎える情報処理技術者試験が、今年度
(2009 年
度)
から大きく変わった。その一環として、1994 年から続いてきた
「アプリケーションエンジニア試験」を衣替えするかたちで、10月よ

「システムアーキテクト試験」が実施される。本企画では、情報処
理技術者試験制度が改定された背景とITスキル標準
(ITSS)
など
との関係を説明したうえで、新試験制度の体系、アプリケーション
エンジニア試験とシステムアーキテクト試験の相違点、そしてシステ
ムアーキテクト試験の出題予測や試験対策などについて解説する。

松原 敬二

Keiji Matsubara

IT教育コンサルタント

028

IT アーキテクト Vol.24

024_tokubetu_1.indd 28

09/07/12 18:58

の通商産業省(現経済産業省)
が試験を創設したことに始まる。

2008年度までの


情報処理技術者試験制度の沿革

この年、上級プログラマーを対象にした「第一種情報処理技

 すでにご存じのとおり、IT 技術者の国家試験である情報処

理技術者試験」が実施されたのだ。初年度は通商産業省告

理技術者試験が、今年度から大きく変更された。その新制度

示に基づく試験であったが、翌 1970 年には「情報処理振興事

を理解するための前提知識として、まず1969 年の試験創設か

業協会等に関する法律」が制定され、試験実施に法律上の

ら2008 年度に至るまでの試験制度の沿革を簡単に説明しよう

根拠が与えられている。

術者試験」
と、初級プログラマーを対象にした「第二種情報処

 その後、システム・エンジニアを対象とする
「特種情報処理技

(図1)。

術者試験」が1971年に、システム監査人を対象とする
「情報処

1969年から1994年春まで

理システム監査技術者試験」が1986年に、さらにネットワーク技

 情報処理技術者試験の歴史は、40 年前の1969 年、当時

術者を対象とする
「オンライン情報処理技術者試験」が1988年

図1:情報処理技術者試験の試験区分の沿革
1969年

1971年

1986年

1988年

1994年

1996年

初級システムアドミニストレータ試験

2001年

2006年

2009年

初級システムアドミニストレータ試験
ITパスポート試験

第二種情報処理技術者試験

第二種情報処理技術者試験

基本情報技術者試験

基本情報技術者試験

第一種情報処理技術者試験

第一種情報処理技術者試験

ソフトウェア開発技術者試験

応用情報技術者試験

アプリケーションエンジニア試験

アプリケーションエンジニア試験

システムアーキテクト試験

システムアナリスト試験

システムアナリスト試験

プロダクションエンジニア試験
特種情報処理技術者試験

上級システム
アドミニストレータ試験
プロジェクトマネージャ試験

オンライン情報処理
技術者試験

上級システム
アドミニストレータ試験
プロジェクトマネージャ試験

プロジェクトマネージャ試験

システム運用管理エンジニア試験

テクニカルエンジニア
(システム管理)試験

ITサービスマネージャ試験

ネットワークスペシャリスト試験

テクニカルエンジニア
(ネットワーク)試験

ネットワークスペシャリスト
試験

データベーススペシャリスト試験
マイコン応用システム
エンジニア試験

テクニカルエンジニア
(データベース)
試験
テクニカルエンジニア
(エンベデッドシステム)試験
テクニカルエンジニア
(情報セキュリティ)試験
情報セキュリティ
アドミニストレータ試験

情報処理
システム監査技術者試験

ITストラテジスト試験

システム監査技術者試験

システム監査技術者試験

データベーススペシャリスト
試験
エンベデッドシステム
スペシャリスト試験

情報セキュリティ
スペシャリスト試験

システム監査技術者試験

IT アーキテクト Vol.24

024_tokubetu_1.indd 29

029

09/07/12 18:58

m

線幅:0.05mm
間隔:0.5mm
-30 度

ープリント

mm

m

ーバープリント

K100% オーバープリント

特別企画1

情報処理技術者試験「          」のすべて

に追加されて5 試験区分となり、その体系が1994 年春まで続い

Technology Skill Standards)」、そして2006年策定の「情報

た。

システムユーザースキル標準(UISS:Users' Information
Systems Skill Standards)」である。

1994年秋から2000年まで

 これら4つのスキル標準は、コンセプトや策定に至った経緯を

 試験制度の創設から25年を経た1994年、情報技術の進展

異にしている。その結果、いずれも経済産業省が所管して策定

と情報化人材の多様化などを背景に、試験創設以来の大規

されたにもかかわらず、IT人材のレベル評価方法など内容に不

模な試験制度改定が行われる。情報化人材像を細分化して

整合があるとの指摘が出ていた。用語 1 つを取ってみても、

定義し、各人材像が習得すべきスキルを
「標準カリキュラム」
とし

ITSSにおける
「ITアーキテクト」に相当する職種は、ETSSでは

て策定したうえで、それに準拠した出題で試験を実施する方式

「システムアーキテクト」、UISSでは「ISアーキテクト」
と呼称され

となったのだ。

るなど、少なからず不整合や不統一があった。

 試験区分も細分化され、一気に11 試験区分に増加した。

 このような背景から、情報処理技術者試験とITSS/ETSS/

「特種」が廃止され、その流れをくむ「アプリケーションエンジニ

UISSとの間で、職種の呼称やレベル評価方法、用語などにつ

ア試験」がこの年に創設されている。また、1996 年には「マイコ

いての整合性確保を望む声が上がるようになる※ 2。その解決の

ン応用システムエンジニア試験」

「上級システムアドミニストレー

ため、昨年度、新たに「共通キャリア・スキルフレームワーク」が

タ試験」の2 試験区分が追加され、全 13 試験区分の体系と

策定され、これがITSS、ETSS、UISSの共通参照モデルに位

なった。

置づけられた。同時に、共通キャリア・スキルフレームワークと情
報処理技術者試験との対応関係も明確化され、今年度からこ

2001年から2008年まで

れに準拠して試験を実施することとされたのである。

 そして2000 年、情報化人材に求められるスキルが備わってい
るかどうかを判定する指標として、
「情報処理技術者スキル標

キャリアとレベル

準」が公表される。同標準は、情報処理技術者試験の出題

 共通キャリア・スキルフレームワークでは、IT 人材について、

範囲をより詳細に説明する役割も担うものとされ、2005 年までに

「キャリア」
と呼ばれる3つの人材類型と6つの人材像を定義して

15 種類の情報処理技術者スキル標準

いる
(表1)。

※1

が策定された。併せ

て、一部の試験区分の改廃と名称変更も行われ、試験創設

 また図2に示すように、各IT人材に必要とされる能力と果たす

から30 年間以上続いた「第一種」、
「第二種」の名称がなくな

べき役割(貢献)
の程度により、1から7まで7 段階の「レベル」

り、それぞれ「ソフトウェア開発技術者試験」、
「基本情報技術

定めており、レベル4以上を
「高度IT人材」
と呼ぶ。

者試験」
となったのである。

 このように、共通キャリア・スキルフレームワークでは、キャリアと
レベルという2つの軸を用いて、3つの人材類型と6つの人材像、

2009年度からの

情報処理技術者試験制度

 2000 年に情報処理技術者スキル標準を発表する一方で、
経済産業省と情報処理推進機構(IPA)
はIT 人材に関する3
つのスキル標準を相次いで策定してきた。2002年策定の「ITス
キル標準(ITSS:Skill Standards for IT Professionals)」、
2005 年策定の「組み込みスキル標準(ETSS:Embedded

030

レベル1~7までの7段階のレベルにより、IT人材像を定義してい
るのである。

※1 午前試験に共通対応する
「IT共通知識体系」
と、14試験区分の午後試験にそれ
ぞれ対応するスキル標準 14 種類から成る。なお、午前試験とは、試験当日の午前中に
行われる多肢選択式試験を、午後試験とは午後に実施される多肢選択式/記述式/
論述式試験
(試験により、そのうちの1つまたは2つが行われる)
を指す。

線幅:0.05mm

※ 2 2007 年 7月に公表された経済産業省 構造審議会報告書 人材育成ワーキング
間隔:0.5mm
グループ報告書『高度IT人材の育成をめざして』
(http://www.soumu.go.jp/main_sos
-30 度
iki/joho_tsusin/policyreports/chousa/ict_ikusei/pdf/070919_2_si1-7.pdf)
より。

K100% オーバープリント

IT アーキテクト Vol.24

024_tokubetu_1.indd 30

09/07/12 18:58

表1:共通キャリア・スキルフレームワークにおけるキャリア定義および試験での対応
人材類型
(キャリア)
人材像

人材像の役割

試験での対応
●マーケット・ストラテジスト:企業、事業、製品およびサービス市場の動向を分析/
予測し、事業戦略、販売戦略などのビジネス戦略を企画立案するとともに、それを
企業の経営方針と照らし合わせ、課題解決のためのソリューションを提案する

基本戦略系人材

ITを活用したビジネス価値の増
大をリードする

ストラテジスト

●ビジネスモデル・ストラテジスト:企業の経営戦略に基づきITを活用するための戦略
を提案/策定したり、製品を提案したりするとともに、それに伴う経営上のリスクや
投資対効果を明確にし、経営層に対して説明を行う
●業務プロセス・ストラテジスト:特定業務プロセスの最適化を実施する
●組み込み製品ストラテジスト:特定の製品戦略の構築段階からITによる機能実現、
保守、廃棄までの戦略を策定する
●個別プロセスにおける制御系エンジニア:高度なIT関連スキルを用いて、プロセス
を制御するための設計、構築、運用を行う

ソリューション系人

クリエーション系人

その他

システムアーキテクト

ビジネス戦略に対して最適なシス
テムをデザインする。

IT 戦略を受け、ソリューションを構成する、または組み込み製品開発に必要となる要 対応
件を定義し、それを実現するためのアーキテクチャを設計する。

プロジェクトマネージャ

与えられた制約条件
(品質、コス
ト、納期など)の下で、信頼性
の高いシステム構築を統括する

システム開発プロジェクトの責任者としてプロジェクト計画を作成し、必要となる要員
や資源を確保して、予算、納期、要求品質について責任を負いながらプロジェクトを
遂行する

テクニカルスペシャリスト

データベースやネットワークなど
の技術ドメインを実装する

設計されたアーキテクチャの中で、求められるシステムのアプリケーションを設計/構
築したり、ネットワークやデータベース、セキュリティなどの固有技術を活用して最適な
システム基盤の構築を行ったりする

サービスマネージャ

継続的に高い信頼性を確保しつ
つ、システムを維持する

構築されたシステムおよび製品について、安定稼働を確保し、障害発生時には被害
の最小化を図るなど、安全性と信頼性の高いサービスの提供を行うほか、構築された
システムおよび製品について、求められている機能要件、非機能要件、信頼性、安
定性に関する品質確認を行う

クリエータ

新たな要素技術の創造などによ
り、社会/経済にイノベーション
をもたらす

新たなプログラミング言語や要素技術
(OSなど)
を開発する。また、新たなビジネス・
モデルの開発や、独創性/将来性の高いソリューションの提案などを行う

(記述なし)

ITSS のエデュケーション※が該
当する

企業などのIT人材の教育、研修などを行い、IT人材の育成を実施する

不対応

出典:
『共通キャリア・スキルフレームワーク 第一版』
(http://www.ipa.go.jp/jinzai/itss/csfv1/csfv1_081021.pdf)
を基に作成
※ エデュケーションはITSSで規定されているものであり、共通キャリア・スキルフレームワークの定義には含まれないが、本表では参考までに
「その他」
として記した。

図2:共通キャリア・スキルフレームワークにおける人材のレベル定義および試験での対応
レベル

定義

高度

レベル7

高度な知識/スキルを有する、世界に通用するハイエンド・プレーヤー。業界全体から見
ても先進的なサービスの開拓や事業改革、市場化などをリードした経験と実績を有し、世
界レベルでも広く認知される

レベル6

高度な知識/スキルを有する国内のハイエンド・プレーヤ−。社内だけでなく、業界にお
いてもプロフェッショナルとしての経験と実績を有し、社内外で広く認知される

レベル5

高度な知識/スキルを有する企業内のハイエンド・プレーヤー。
プロフェッショナルとして
豊富な経験と実績を有し、社内をリードできる

レベル4

高度な知識/スキルを有し、
プロフェッショナルとして業務を遂行でき、経験や実績に基
づいて作業指示が行える。
また、
プロフェッショナルとして求められる経験を形式知化し、 高度試験(9種類の試験の総称)
後進の育成に応用できる

レベル3

応用的知識/スキルを有し、要求された作業について、
すべて独力で遂行できる

応用情報技術者試験

レベル2

基本的知識/スキルを有し、一定程度の難易度または要求された作業について、
その
一部を独力で遂行できる

基本情報技術者試験

レベル1

情報技術に携わる者に必要な最低限の基礎的知識を有し、要求された作業について、
指導を受けて遂行できる

ITパスポート試験

スーパーハイ

人材

I
T

ハイ

ミドル

エントリ

試験での対応

不対応

出典:
『共通キャリア・スキルフレームワーク 第一版』
を基に作成

IT アーキテクト Vol.24

024_tokubetu_1.indd 31

031

09/07/12 18:58

m

線幅:0.05mm
間隔:0.5mm
-30 度

ープリント

K100% オーバープリント

特別企画1

情報処理技術者試験「          」のすべて

試験区分設計の考え方

図3:キャリアおよびレベルと試験区分の対応

ア・スキルフレームワークで定義されたキャリアとレベルを判定す

レベル

評価を必要とし、もはやペーパー・テストで判定できる性質のも

基本情報技術者試験

のではないためだと考えられる。

レベル1

ITパスポート試験

システム監査技術者試験

応用情報技術者試験

レベル2

I
T

サービスマネージャ試

レベル3

レベル5 以上のスキル判定が実務経験と実績に基づく社会的

情 報セキュリティスペシャ
リスト試験

エンベデッドシステムスペシ
ャリスト試験

とされており、レベル5~7は試験による判定の対象外だ。これは、

データベーススペシャリスト
試験

 また、レベルについては、レベル1~4までがスキル判定の対象

高度試験

ネットワークスペシャリスト
試験

レベル4

プロジェクトマネージャ試

判定の対象とされている。これは、クリエーション系人材には試

ストラテジスト試験

I
T

システムアーキテクト試験

リューション系人材(2つの人材類型と5つの人材像)
がスキル
験によるスキル判定がなじまないためであろう。

サービスマネ
ージャ

 具体的に言うと、キャリアについては、基本戦略系人材とソ

テクニカルス
ペシャリスト

れる。

ソリューション系人材
プロジェクト
マネージャ

技術者試験が対応しているのは、一部のキャリアとレベルに限ら

キャリア

システムアー
キテクト

人材像

るためのツールに位置づけられている。ただし現状、情報処理

基 本 戦 略 ストラテジス
系人材

人材類型

 以上のことから、新たな情報処理技術者試験は、共通キャリ

 こうして、情報処理技術者試験によるスキル判定の対象とさ
れるキャリアを横軸に、レベルを縦軸にとり、その組み合わせに
よって試験区分を設けたものが、今年度からの試験区分となる
(図3)。まず、レベル1~3には、人材像を問わず共通の基本的

 まず、組み込みシステム開発の重要性の高まりを受け、組み
込みシステムの知識/技能を幅広く出題することだ。

な知識が必要であるとの観点から、レベルごとに共通の試験を

 また、旧試験制度ではベンダー側人材(情報システム開発

設けている。また、高度IT人材であるレベル4については、キャリ

/運用側)
とユーザー側人材(情報システム利用側)
の試験

アに応じて細分化した9種類の試験を設け、これを
「高度試験」

区分に大別されていたが、新試験制度ではその区別をなくすこ

と総称している。

ととした
(図 4)。基本情報技術者試験については試験名称の

 こうした試験区分を設計するにあたり、共通キャリア・スキルフ

変更はないが、試験範囲がベンダー側だけでなくユーザー側に

レームワークの観点のほかに考慮されたことがある。

も拡張されたことに留意する必要がある。また、高度試験でベン

図4:ベンダー側試験とユーザー側試験の一体化
旧試験

mm

新試験

ベンダー系

ユーザー系

ベンダー系/ユーザー系

システムアナリスト試験

上級システムアドミニストレータ試験

ITストラテジスト試験

テクニカルエンジニア
(情報セキュリティ)
試験

情報セキュリティアドミニストレータ試験

情報セキュリティスペシャリスト試験

ソフトウェア開発技術者試験

(なし)

応用情報技術者試験

基本情報技術者試験

(なし)

基本情報技術者試験

(なし)

初級システムアドミニストレータ試験

ITパスポート試験

m

ーバープリント

線幅:0.05mm
間隔:0.5mm
-30 度
K100% オーバープリント

032

IT アーキテクト Vol.24

024_tokubetu_1.indd 32

09/07/12 18:58

ダー側とユーザー側に分かれていた4つの試験区分は、2つの

旧試験制度のアプリケーションエンジニア試験(以下、AE 試

試験区分に統合された。

験)
が廃止され、システムアーキテクト試験(以下、SA 試験)

 なお、情報セキュリティスペシャリスト試験とシステム監査技術

新設される。

者試験は便宜上、それぞれテクニカルスペシャリストとサービスマ

システムアーキテクトの人材像

ネージャの人材像に対応するものとされている。

 先述したように、共通キャリア・スキルフレームワークは、ITSS、

アプリケーションエンジニア試験から
システムアーキテクト試験へ

 さて、いよいよ本題に入ろう。今回の試験制度改定により、

ETSS、UISSに共通の参照モデルとして策定された。つまり、
共通キャリア・スキルフレームワークにおける
「システムアーキテク
ト」
こそが、ITSSのITアーキテクト、ETSSのシステムアーキテクト、
UISSのISアーキテクトの共通の参照モデルなのである
(表2に、

表2:各スキル標準におけるアーキテクトの呼称と人材像
呼称(スキル標準)

人材像

システムアーキテクト
(共通キャリ
ビジネス戦略に対して最適なシステムをデザインする
ア・スキルフレームワーク)

ITアーキテクト
(ITSS)

システムアーキテクト
(ETSS)

ビジネスおよび IT 上の課題を分析し、ソリューションを構
成する情報システム化要件として再構成する。ハードウェ
ア、ソフトウェア関連技術
(アプリケーション関連技術、メ
ソドロジー)
を活用し、顧客のビジネス戦略を実現するた
めに情報システム全体の品質(整合性、一貫性など)

保ったITアーキテクチャを設計する。設計したアーキテク
チャが課題に対するソリューションを構成することを確認
するとともに、後続の開発、導入が可能であることを確認
する。また、ソリューションを構成するために情報システム
が満たすべき基準を明らかにする。さらに、実現性に対す
る技術リスクについて事前に影響を評価する。
IT 投資の局面においては、戦略的情報化企画
(課題整
理と分析
[ビジネスおよびIT]
、ソリューション設計
[構造と
パターン]

を主な活動領域として、以下を実施する。
 ・ソリューションの枠組み策定
 ・ソリューションアーキテクチャの設計
当該職種は、右の専門分野に区分される

専門分野
IT 戦略を受け、ソリューションを構成する、または組み込み製品開発に必要となる要件を定義
し、それを実現するためのアーキテクチャを設計する
●アプリケーションアーキテクチャ
ビジネスおよび IT 上の課題を分析し、機能要件として再構成する。機能属性、仕様を明らか
にし、アプリケーション・アーキテクチャ
(アプリケーション・コンポーネント構造、論理データ構
造など)
を設計する。設計したアーキテクチャがビジネスおよびIT上の課題に対するソリューショ
ンを構成することを確認するとともに、後続の開発、導入が可能であることを確認する
●インテグレーションアーキテクチャ
全体最適の観点から異種あるいは複数の情報システム間の統合および連携要求を分析し、
統合および連携要件として再構成する。統合および連携仕様を明らかにし、インテグレーショ
ン・アーキテクチャ
(フレームワーク構造とインターオペラビリティ)
を設計する。設計したアーキ
テクチャが統合および連携要求を満たすことを確認するとともに、後続の開発、導入が可能
であることを確認する
●インフラストラクチャアーキテクチャ
ビジネスおよびI
T上の課題を分析し、システム基盤要件として再構成する。システム属性、仕
様を明らかにし、インフラストラクチャ・アーキテクチャ
(システム・マネジメント、セキュリティ、ネ
ットワーク、プラットフォームなど)
を設計する。設計したアーキテクチャがビジネスおよび IT 上の
課題に対するソリューションを構成することを確認するとともに、後続の開発、導入が可能であ
ることを確認する

●組み込みアプリケーション開発
システムの利用/開発などの要件を満たすシステム構造
プラットフォームを使い、開発対象システムのアプリケーションを開発する技術者
ならびに開発プロセスを設計する技術者。当該職種は、
●組み込みプラットフォーム開発
右の専門分野に区分される
開発対象システムなどに搭載されるプラットフォームを作る技術者
●IT戦略策定
 ・対象領域のビジネスおよび環境の分析
 ・IT戦略の策定
 ・全体計画の策定

ISアーキテクト
(UISS)

【ミッション】
ビジネス環境の変化や情報技術の進展に企業として継
●IT基盤構築/維持/管理
続的に対応するために、IT 戦略を策定し、その構築と評
 ・IT基盤の構築
価、維持/管理を行う
 ・標準体系の策定
 ・標準作成
【活動内容】
 ・品質統制
(ガバナンス)
企業活動において、IT戦略策定/評価、IT基盤構築/
 ・標準の維持/管理
維持/管理を主な活動領域として、右のことを実施する
●IT戦略評価
 ・IT戦略の評価
また、IS戦略策定/評価を支援する

出典:各スキル標準を基に作成

IT アーキテクト Vol.24

024_tokubetu_1.indd 33

033

09/07/12 18:58

m

線幅:0.05mm
間隔:0.5mm
-30 度

ープリント

mm

m

ーバープリント

K100% オーバープリント

特別企画1

情報処理技術者試験「          」のすべて

各スキル標準におけるアーキテクトの呼称と人材像をまとめた)。

 まず試験の実施形式だが、SA 試験は4つの時間帯に分け

SA試験は、この人材像を念頭に置いて実施されることになる。

て1日で実施される
(表 4に、各時間帯の試験の出題形式と試
験時間を示す)。それぞれの時間帯で実施される試験の内容

AE試験の対象者像との違い

は、以下に説明するとおりだ。

 では、従来のAE試験との関係はどうであろうか。
 2007 年 12月にIPAが公表した
『情報処理技術者試験 新

午前Ⅰ試験

試験制度の手引』
では、AE試験とSA試験の対応関係に関し

 午前Ⅰ試験は、同日に実施される他の高度試験※ 3との共通

て、
「現行のアプリケーションエンジニア試験に比べて、システム

問題となる。四肢択一の問題が 30 問出題され、試験時間は

アーキテクト試験では全体最適の観点からの情報システムの構

50 分、各試験区分に共通して求められる技術レベル3の問題

造設計および対象とする情報システムのシステム方式設計分野

が、テクノロジ系、マネジメント系、ストラテジ系から幅広く出題さ

を明確化して重視する。選択問題として組み込みシステムの

れる。

アーキテクチャ設計を追加する」
といった旨が記されている。

 出題範囲は9つの大分類、23の中分類から成る。36ページ

 ここで、より詳しく見るために、両試験の対象者像を比較して

の図 5に示すのは、試験区分別にまとめた午前試験の出題分

みよう
(表3)。

野の一覧だ。以下に、午前Ⅰ試験の出題例を示す。

 表中のAE 試験の対象者像のところに「プロジェクト計画に
基づいて…」
とあるように、アプリケーションエンジニアは、プロ
ジェクトマネージャの下で情報システム開発プロジェクトの一連の
プロセスを担当する者という位置付けにある。
 これに対し、SA試験の対象者像のところには、
「ITストラテジ
ストによる提案を受けて…」
とある。これは、システムアーキテクト
が単にプロジェクトマネージャの配下で働くのではなく、企業の
情報システム戦略を実現するために、より高いレベルで活躍する
のを期待されていることを示している。
 このように、SA試験はAE試験の後継ではあるものの、システ
ムアーキテクトが担当する専門分野は多岐にわたるものとなり、
対象者像がかなり異なることに留意する必要がある。
 ただし、情報処理技術者試験の過去の制度改定では、旧
試験との互換性や継続性が考慮されてきたことも事実だ。それ

共通フレーム2007 によれば、要件定義プロセスで行う
べき作業はどれか。
ア 新しい業務のあり方や運用をまとめた上で、業務上
実現すべき要件を定義する。
イ 企業で将来的に必要となる最上位の業務機能と組
織モデルを検討する。
ウ システム化機能の整理とネットワーク構成などのシス
テム方式を策定する。
エ システムが提供する信頼性、性能、セキュリティなど
のサービスレベルを定義する。
(正解:ア)
出典:2009年度春期 高度午前Ⅰ 問25

を踏まえると、出題内容の急激な変化があるとは考えにくい。当
面はSA 試験でも、AE 試験と同様にアプリケーション設計を中

午前Ⅱ試験

心とした出題になる可能性が高いと考えられる。

 午前Ⅱ試験では、四肢択一の問題が25 問出題され、全問
を40分で解答する。問題の形式は午前Ⅰ
と同じで、高度試験そ

システムアーキテクト試験の
実施形式

 それでは以降、SA試験に関する詳細を述べていこう。

034

れぞれの専門に特化した、技術レベル3または4の問題が出題
される。

線幅:0.05mm
間隔:0.5mm

※ 3 ITストラテジスト試験、ネットワークスペシャリスト試験、情報セキュリティスペシャリ
-30 度
スト試験、ITサービスマネージャ試験。

K100% オーバープリント

IT アーキテクト Vol.24

024_tokubetu_1.indd 34

09/07/12 18:58

表3:AE試験とSA試験の対象者像の比較

アプリケーションエンジニア(AE)試験

システムアーキテクト
(SA)試験

対象者像

情報システム開発プロジェクトにおいて、プロジェク
高度IT人材として確立した専門分野を持ち、ITストラテジストによる提案を受けて、情報システムまたは組み込みシス
ト計画に基づいて、業務要件の分析からシステム
テムの開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計して、情報システムについては
設計、プログラム開発、テストまでの一連のプロセス
開発を主導する者
を担当する者

業務と役割

【情報システム】
情報システム戦略を具体化するための情報システムの構造の設計や、開発に必要となる要件の定義、システム方
情報システム開発プロジェクトにおいて、業務要件
式の設計および情報システムを開発する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。
を分析し、システムとして実現する業務に従事し、
①情報システム戦略を具体化するために、全体最適の観点から、対象とする情報システムの構造を設計する
次の役割を果たす。
②全体システム化計画および個別システム化構想/計画を具体化するために、対象とする情報システムの開発に
①利用者側の業務要件を分析し、要求仕様をまと
必要となる要件を分析、整理して取りまとめる
める
③対象とする情報システムの要件を実現する最適なシステム方式を設計する
②要求仕様に基づいて、新規開発/パッケージ導
④要件および設計されたシステム方式に基づいて、要求された品質を満足するソフトウェアの設計/開発、テスト、
入などのシステム実現方法、システム構成、シス
運用および保守についての検討を行い、対象とする情報システムを開発する。なお、ネットワーク、データベースな
テム移行/運用などについて検討し、システム
どの固有技術については、必要に応じて専門家の支援を受ける
設計を行う
⑤対象とする情報システムおよびその効果を評価する
③プログラム開発要員を指導して、プログラム開発
を実施させる
【組み込みシステム】
④総合テストを計画し、実施する。また、システム移
組み込みシステムの要件を調査/分析して機能仕様を決定し、ハードウェアとソフトウェアの要求仕様を取りまとめ
行および運用テストを支援する
る業務に従事して、次の役割を主導的に果たすとともに、下位者を指導する。
⑤個別のハードウェア技術、ソフトウェア技術、ネッ
①組み込みシステムの企画/開発計画に基づき、対象とする組み込みシステムの機能要件、技術的要件、環境
トワーク構成、データベース構成、システム運用
条件、品質要件を調査/分析し、機能仕様を決定する
などについては、必要に応じて専門家の支援を
②機能仕様を実現するハードウェアとソフトウェアへの機能分担を検討して、最適なシステム・アーキテクチャを設計
受ける
し、ハードウェアとソフトウェアの要求仕様を取りまとめる
③汎用的なモジュールの導入の妥当性や開発されたソフトウェア資産の再利用の可能性について方針を策定する
システムアーキテクトの業務と役割を円滑に遂行するために、次の知識/実践能力が要求される。

情報システム開発の中核技術者として業務要件を
【情報システム】
分析し、システムとして実現するため、次の幅広い
①情報システム戦略を正しく理解し、業務モデル/情報システムの全体体系を検討できる
知識/経験/実践能力が要求される。
②各種業務プロセスについての専門知識とシステムに関する知識を有し、双方を活用して、適切なシステムを提案
①経理、生産管理などの業務知識を持ち、利用者
できる
側の業務要件を分析して、要求仕様書を作成で
③企業のビジネス活動を抽象化
(モデル化)
して、情報技術を適用できるかたちに再構成できる
きる
④業種ごとのベスト・プラクティスや主要企業の業務プロセスの状況、同一業種の多くのユーザー企業における業
②新規開発、パッケージ導入などのシステム実現
務プロセスの状況、業種ごとの専門知識、業界固有の慣行などに関する知見を持つ
方法を評価/選択できる
⑤情報システムの実現方式、開発手法、ソフトウェア・パッケージなどの汎用的なシステムに関する知見を持ち、適
③ハードウェア、ソフトウェア、ネットワーク、データベ
切な選択と適用ができる
ースなど情報技術に関する全般的な知識を持ち、
⑥ OS、データベース、ネットワークなどにかかわる基本的な要素技術に関する知見を持ち、その技術リスクと影響を
期待する技術水
必要に応じて特定分野の情報技術の専門家か
勘案して、適切な情報システムを構築/保守できる

ら支援を受け、要求仕様に合った情報システム
⑦情報システムのシステム運用、業務運用、投資効果および業務効果について、適切な評価基準を設定し、分
を設計できる
析/評価できる
④要求仕様書に基づき、標準的な記法によって外
⑧多数の企業への展開を念頭に置いて、ソフトウェアやシステム・サービスの汎用化を検討できる
部設計書/内部設計書を作成できる
⑤プログラム開発、単体/結合テストに際し、プロ
【組み込みシステム】
グラム開発要員を指導できる
①対象とする組み込みシステムが用いられる環境条件や安全性などの品質要件を吟味し、実現すべき機能仕様を
⑥総合テストの計画と管理が行え、またシステム移
決定できる
行および運用テストで利用者側の要員を支援で
②対象とする組み込みシステムの機能仕様に基づき、ハードウェアとソフトウェアの適切な組み合わせを設計し、そ
きる
れぞれの要求仕様としてまとめることができる
⑦計画された品質/工程の実行管理ができる
③リアルタイムOS に関する深い知識と汎用的なモジュールに対する知識を有し、ソフトウェア資産の再利用可能性
の検討や、適切な活用ができる
出典:試験センターWebサイトの公表資料を基に作成

表4:SA試験の出題形式と試験時間

午前Ⅰ

午前Ⅱ

午後Ⅰ

試験時間

50分
(9時30分~10時20分)

40分
(10時50分~11時30分)

90分
(12時30分~14時)

午後Ⅱ
120分
(14時30分~16時30分)

出題形式

多肢選択式

多肢選択式

記述式

論述式
(小論文)

出題数と解答数

30問出題、30問解答

25問出題、25問解答

4問出題、2問解答

3問出題、1問解答

IT アーキテクト Vol.24

024_tokubetu_1.indd 35

035

09/07/12 18:58

m

線幅:0.05mm
間隔:0.5mm
-30 度

ープリント

情報処理技術者試験「          」のすべて

ストラテジ

8
9

○3

◎4
◎4
◎4
○3
◎4
◎4
○3

○3
○3

○3
○3

○3
○3

◎4
○3
◎4
◎4

○3
○3
○3
◎4
○3

◎4
◎4
○3
○3

○3
◎4

○3
○3
◎4
○3

◎4
○3
○3
○3

○3
○3
◎4
○3

春秋

○3
○3

○3
◎4
◎4
○3
○3
○3
○3

○3
○3
○3

◎4
◎4
○3

○3

○3

システム監査技術者試験

7

○2

ITサービスマネージャ試験

5
マネジメント

6

○1

情報セキュリティスペシャリスト
試験

4

エンベデッドシステムスペシャリ
スト試験

3

データベーススペシャリスト試験

テクノロジ


2
2
0
1
2
1
1
1
1
2
2
○3 1
1
3
1
1
2
1
1
1
1
1
1

午前Ⅱ
(専門知識)
ネットワークスペシャリスト試験

2

春秋 春秋 春秋

プロジェクトマネージャ試験

1

共通キャリア・スキルフレームワーク
大分類
中分類
1 基礎理論
基礎理論
2 アルゴリズムとプログラミング
3 コンピュータ構成要素
4 システム構成要素
コンピュータシステム
5 ソフトウェア
6 ハードウェア
7 ヒューマンインタフェース
8 マルチメディア
技術要素
9 データベース
10 ネットワーク
11 セキュリティ
12 システム開発技術
開発技術
13 ソフトウェア開発管理技術
プロジェクトマネジメント
14 プロジェクトマネジメント
15 サービスマネジメント
サービスマネジメント
16 システム監査
17 システム戦略
システム戦略
18 システム企画
19 経営戦略マネジメント
経営戦略
20 技術戦略マネジメント
21 ビジネスインダストリ
22 企業活動
企業と法務
23 法務

システムアーキテクト試験

分野

高度試験
ITストラテジスト試験

出題分野

午前Ⅰ
︵共通知識︶

試験区分

応用情報技術者試験
︵午前︶

図5:試験区分別にまとめた午前試験の出題分野

基本情報技術者試験
︵午前︶

m

特別企画1

ITパスポート試験

mm

K100% オーバープリント

○3
○3
○3
○3

○3
◎4

○3

○3

○3
◎4

出典:
『情報処理技術者試験 新試験制度の手引』
(http://www.jitec.ipa.go.jp/1_00topic/topic_20070907_public_comment_(1).pdf)
※ ○は出題範囲であることを、
◎は出題範囲のうちの重点分野であることを表す。
また○や◎の後の数字は技術レベルを表し、4が最も高度で、上位は下位を包含する。
※ *欄の数字は、
2009年度春期試験の高度共通午前Ⅰ試験での出題数(筆者調査による)。

表5:AE試験とSA試験の午前試験の出題分野の比較
大分類

AE試験

1 基礎理論

×     (○)

2 コンピュータシステム

視されていた「プロジェクトマネジメント」、
「経営戦略」、
「企業

3 技術要素

4 開発技術

と法務」の各大分類はSA 試験では専門分野とされておらず、

5 プロジェクトマネジメント

◎     (○)

午前Ⅱ試験では出題されない。表 5に、AE 試験とSA 試験の
午前試験の出題分野の比較を示す。

テクノロジ系

マネジメント系

SA試験

 SA 試験の場合、9つの中分類が出題範囲とされており、そ

分野

6 サービスマネジメント

○     (○)

7 システム戦略

ストラテジ系

8 経営戦略

◎     (○)

9 企業と法務

◎     (○)

のうち2つの中分類が技術レベル4の出題となる。AE試験で重

出典:
『情報処理技術者試験 新試験制度の手引』
※ ×は出題範囲外、○は出題範囲、◎は出題分野のうち重点分野、
(○)
は午前Ⅰ試
験のみの出題範囲であることを示す。

午後Ⅰ試験
 午後Ⅰ試験では、記述式の問題(大問)
が4 問出題され、

線幅:0.05mm

の中から任意の2問を選択して90分で解答する。間隔:0.5mm

-30 度
 1つの大問は5ページ前後で、対象となるシステムの説明文

ーバープリント

K100% オーバープリント

036

IT アーキテクト Vol.24

024_tokubetu_1.indd 36

09/07/12 18:58

図6:午後Ⅱ試験の問題例

表6:午前Ⅰ試験の免除条件
免除条件

複数の個別システムを連携させたシステムの構築について

 近年、
企業統合や業務連携の実現などのために、
複数の個別システムを連携させることがある。例えば、EAI
(Enterprise Application Integration)
ツールを利用したアプリケーション統合システムや、
サプライチェーン
マネジメントシステムなどが挙げられる。
このようなシステムの構築では、業務を円滑に遂行できるようにする、

プライチェーン全体で在庫を把握できるようにするなどの、
ビジネスのねらいを達成することが重要である。
 システムアーキテクトは、
ビジネスのねらいを達成するために、連携対象となる個別システムの業務面、機能
面、情報技術面の違いや共通性を考慮し、
システム全体の構造を設計しなければならない。
その際、
システム
全体での整合性、経済性、拡張性などの全体最適の観点から、連携のための機能分担や、個別システム間の
連携方式などについて検討する。
例えば、
次のような項目について検討をすることが重要である。
●業務の実行サイクルや手順、
コードの異なる業務間の整合性の維持
●システム全体での経済性の実現
●汎用的な情報技術の採用による拡張性の確保
 あなたの経験と考えに基づいて、
設問ア∼ウに従って論述せよ。
設問ア

あなたが携わった、複数の個別システムを連携させたシステムの構築について、
その背景となっ
たビジネスのねらいと、
システムの概要を800字以内で述べよ。

設問イ

設問アで述べたシステムの構築において、
あなたは全体最適の観点からどのように検討を行い、
どのようなシステム全体の構造を設計したか。800字以上1,600字以内で、具体的に述べよ。

設問ウ

設問アで述べたシステムの構築によって、
ビジネスのねらいが達成できると考えた理由を、想定さ
れたリスクや考慮点とともに、
600字以上1,200字以内で、具体的に述べよ。

免除対象の試験と期間

2009 年度以降の応用情報技術者試験に
合格する
2009 年度以降の高度試験のいずれかに
合格する
(午前Ⅰ免除で受験して合格した場
合を含む)
2009 年度以降の高度試験を午前Ⅰから受
験して、午前Ⅰで基準点
(60 点以上)
をとる
(最終的に不合格だった場合を含む)

当該条件を満たしてから
2年以内に実施される高
度試験

2008 年度のソフトウェア開発技術者試験、
2009 年度実施の高度
システムアナリスト試験、プロジェクトマネー
試験のみ(試験制度改
ジャ試験、アプリケーションエンジニア試験
定の移行措置)
のいずれかに合格した

出典:
『新試験制度サンプル問題』
問14(2008年4月 IPA公表)

図表、3~5 問程度の設問から成る
(設問の中に複数の小問

でシステムの構築や設計で工夫した点を、設問ウではさらに考

が設けられる場合もある)。設問の解答形式には、数値を答える

慮すべき点などを問われる。

もの、用語を答えるもの、指定された文字数(10~50 字程度)

 論述する文字数は、設問アが800 字以内、設問イが800 字

の文章で答えるものなどがある。

以上、1,600字以内、設問ウが600字以上、1,200字以内。設
問アの最低文字数は明示されていないが、筆者の経験では

午後Ⅱ試験

600~700 文字以上書くことが望ましい。解答用紙は原稿用紙

 午後Ⅱ試験では、論述式(小論文)
の問題が 3 問出され、

で、400字詰め
(25文字×16行)
の9ページとなる。

任意の1問を選択して120分で解答する。1つの問題は1ページ
線幅:0.05mm

で、論述テーマの背景説明と3つの設問ア、イ、ウから成る
(図

午前Ⅰ試験の免除制度

間隔:0.5mm

6に、午後Ⅱ試験の問題の例を示す)。設問の形式はパターン

 午前Ⅰ試験は、表 6に示すような条件を満たし、応募時(願

-30 度

化しており、設問アで論述対象とするシステムの概要を、設問イ

書提出時)
に申請することにより、免除を受けることができる。この

K100% オーバープリント

午前Ⅰ試験免除のメリット
2 年間の免除資格が得られる。高度試験を継

 午前Ⅰ試験の免除を受けることのメリットは、

間は5 時間)
拘束される。それに対して、午前Ⅱ

言うまでもなく、午前Ⅰ試験が基準点
(60 点)

試験からの受験なら、拘束時間は5 時間 40 分

続的に受験して免除資格を維持するという手も

で済む。こ
満たないために不合格となるリスクがなくなるこ (そのうち、解答時間は4時間10分)

あるだろう。2010 年度以降は年を追うごとに午

とである。もっとも、SA 試験を受験するような方

の差は小さいようで、意外と大きい。

前Ⅰ免除者の比率が高まると予想されるので、む

にとって、実はこれは大したメリットではない。な

 特に、最後の午後Ⅱ試験は、頭脳と手を酷

しろ免除でないと明確に不利になるかもしれない。

ぜなら、きちんと学習していれば、午前Ⅰ試験で

使する論文試験だ。朝からの疲れがたまってくる

 なお、2009 年度春期に実施された高度試

60点を取るのは決して難しくないからだ。

と、論文のアイデアが浮かばず、文字を書くス

験5区分の午前Ⅰ試験では、基準点以上を得た

 午前Ⅰ試験免除の本当のメリットは、1日を通

ピードも遅くなり、実力を発揮できなくなるおそれ

者が 3 万 1,751 名で、受験者数に対する割合

した疲労を少なくできることにある。まず、自宅を

がある。できるだけ疲れのない状態で午後の試

は約 80%に達した。これに応用情報技術者試

出る時刻が80分遅くて済む。午前Ⅰ試験から受

験に臨むことが望ましいのだ。

験の合格者9,549名を加えると、4万名以上が

験すると、試験会場で7 時間
(そのうち、解答時

 午前Ⅰ試験は、一度基準点
(60 点)
を取れば、 今後2年間の免除資格を得たことになる。

IT アーキテクト Vol.24

024_tokubetu_1.indd 37

037

09/07/12 18:58

m

線幅:0.05mm
間隔:0.5mm
-30 度

ープリント

mm

m

K100% オーバープリント

特別企画1

情報処理技術者試験「          」のすべて

免除制度は、新試験制度のすべての高度試験に共通だ。免
除者は午前Ⅱ試験からの受験となる
(免除が認められたら、午
前Ⅰ試験は受験できない)。

2009年度春期試験に基づく
出題予測と対策方法

 最後に、今年 4月に実施された2009 年度春期試験の内容

システムアーキテクト試験の
採点方法と合格基準

 続いて、SA試験の採点方法と合格基準を説明する。

を基に、10月のSA 試験の出題内容を予測し、併せて試験に
向けた学習方法を紹介する。

午前Ⅰ、Ⅱ試験の出題予測と学習方法
 まずは午前Ⅰ、Ⅱ試験の出題予測と学習方法だ。

採点方法

●出題予測

 午前Ⅰ、午前Ⅱ、午後Ⅰの各試験は、100 点満点として、素点

 4月に新試験制度の下で初回試験が実施され、高度試験

方式で採点する。素点方式とは、問題ごとに配点が決められて

に共通の午前Ⅰ試験も初めて行われた。この午前Ⅰ試験の30問

おり、正解した問題の配点を単純に合計する方法のことだ。

の中分類ごとの出題数を、前掲の図5の*欄に示した。23の中

 なお、午後Ⅱ試験では、論述の内容を評価ランクの高い順

分類のうち、
「コンピュータ構成要素」を除く22の中分類から1

にA、B、C、Dの4段階で評価する
(表7に各ランクの評価内容

~3問ずつ出題されている。23の中分類に対して問題数が30し

を示す)。

かないことから、広く薄く出題されたかたちだ。この傾向は、10月
の秋期試験でも同様だと予想される。

合格基準

 一方、春期試験では、SA 試験の午前Ⅱ試験は実施されて

 合格基準は、午前Ⅰ、午前Ⅱ、午後Ⅰの各試験ですべて基

いないが、他の高度試験の午前Ⅱ試験の出題傾向はどうだっ

準点(60点)以上をとり、なおかつ午後Ⅱ試験の評価ランクがA

たのだろうか。筆者が分析したところでは、図 5で技術レベル4

であることだ。午前Ⅰ試験の免除者は、午前Ⅰ試験が基準点を

(◎4)
とされる中分類からの出題は、25問中の13~15問であっ
た。例えば、システム監査技術者試験の午前Ⅱでは、中分類

満たしているものと見なされる。
 午前Ⅰ試験が基準点に満たないときは、午前Ⅱ、午後Ⅰ、午後

「システム監査」、
「法務」からの出題が13 問である。残り12 問

Ⅱを採点せずに不合格となる。また、午前Ⅱ試験が基準点に満

はその他の中分類からの出題であり、内容的にもレベル的にも

たないときは、午後Ⅰ、午後Ⅱを採点せずに不合格となる。そして、

午前Ⅰ試験と同等であった。このことから、SA 試験でも、図 5で

午後Ⅰ試験が基準点に満たないときは、午後Ⅱを採点せずに不

技術レベル4とした中分類「システム開発技術」

「システム企

合格となる。

画」からの出題が15問程度になると予想できる。

 なお、自分の試験の成績は、合格発表日以降に試験セン

●学習方法

ターのWebサイ
トで確認することができる。

 午前Ⅰ
と午前Ⅱの両試験で求められる知識は共通であり、過
去問題の再出題や類題が多い。よって、高度試験午前対策
の過去問題集を使って学習するのが効率的だ。一般的な知
識を広く学習してから過去問題に取り組もうとすると、あまり出題

表7:午後Ⅱの評価ランク
評価ランク

内容

合否

されない知識まで学ぶことになり、試験対策としては効率が悪い。

A

合格水準にある

合格

B

合格水準まであと一歩である

 なお、中分類ごとに出題のウェイ
トと難易度に差が付け
られて
線幅:0.05mm

C

内容が不十分である

D

出題の要求から著しく逸脱している

ーバープリント

不合格

おり、学習重点度と予想出題数をまとめると表 8の間隔:0.5mm
ようになる。こ
-30 度
れを踏まえ、まず重点度「高」

「中」の中分類を重点的に学習

K100% オーバープリント

038

IT アーキテクト Vol.24

024_tokubetu_1.indd 38

09/07/12 18:58

表8:システムアーキテクト試験の午前試験の学習重点度

学習重点度

予想出題数

午前Ⅰ
2

10

18

験やシステム監査技術者試験を見ると、1 問当たりの分量(問

中分類

題文の長さや解答の記述量)
は2008 年度以前の試験と大差

15

12.システム開発技術/18.システム企画

なかった。

10

3.コンピュータ構成要素/4.システム構成
要素/9. データベース/10.ネットワーク/
11.セキュリティ/13.ソフトウェア開発管理
技術/17.システム戦略

1. 基礎理論/2. アルゴリズムとプログラミン
グ/5.ソフトウェア/6. ハードウェア/7.ヒュ
ーマンインタフェース/8. マルチメディア/
14.プロジェクトマネジメント/15.サービスマネ
ジメント/16.システム監査/19.経営戦略マ
ネジメント/20.技術戦略マネジメント/21.ビ
ジネスインダストリ/22.企業活動/23.法務

午前Ⅱ

●学習方法
 午後Ⅰ試験の基本的な対策は、過去問題を解いて学習し、
問題のパターンに慣れてしまうことである。情報システムのアプリ
ケーション開発の業務経験があれば、問題の内容は理解しや
すいだろう。
 AE 試験では、解答時間が足りなくなることも多かったため、
部分点も狙い、とにかく素早く解いて解答欄を埋める必要が
あった。それに対し、SA試験では1問当たりの解答時間が延び
たので、正確さを追求して解答することが求められる。また、合

する。日常業務などを通じて十分な知識があるのなら、知識の

格基準が60 点の絶対評価に変更されたので、他の受験者と

確認を行うためにさらっと過去問題を解く程度でもよいだろう。ま

の競争を意識する必要もなくなった。

た、重点度「低」の中分類については、不得意なところやなじ

 なお、過去問題に取り組むときは、短時間で精神を集中して

みのないところを学習するとよい。過去問題集には数百問が収

解くことが重要である。自宅や電車の中でゆっくりと参考書を読

録されているが、このように中分類を絞れば、短時間で効率良

むとわかった気になるが、実際に短時間で問題文を読解して解

く学習できる。

答を書くのは意外と難しいものだ。
「1人でやっても集中しづらい」
という方は、勤務先などの受験者同士で集まり、退社後などに

午後Ⅰ試験の出題予測と学習方法

時間を計って解くなどするとよい。

 次に、午後Ⅰ試験の出題予測と学習方法を解説する。
●出題予測

午後Ⅱ試験の出題予測と学習方法

 前述したとおり、システムアーキテクトの担当業務は幅広いが、

 最後に、午後Ⅱ試験の出題予測と学習方法を述べる。

AE 試験からの継続性を考えると、出題傾向の急激な変更は

●出題予測

考えにくい。すなわち、SA試験においても、情報システムのアプリ

 SA 試験では組み込みシステム設計が出題範囲となったので、

ケーション設計の出題が中心になると考えられる。また、SA試験

情報システム設計から2問、組み込みシステム設計から1問が出

の対象者像で示されているように
(前掲の表3参照)、組み込み

題される可能性が高い。このうち1問を選択して論述する。

システム設計も出題範囲となる。となると、4 問のうち、情報システ

 AE 試験とSA 試験を比べると、設問ごとに論述すべき内容と

ム設計から3問、組み込みシステム設計から1問の出題となる可

文字数が変更されている
(次ページの表9)。

能性が高い。

 AE 試験では、設問イと設問ウを何文字で書き分けるかは受

 AE 試験の午後Ⅰは90 分で4 問から3 問を選択して解答する

験者に任されていた。論述のメインは設問イであり、設問ウは付

形式であり 、時間的にタイトであった。一方、SA 試験では、

け足し程度でも十分に合格できたのだ。つまり、時計を見ながら

※4

90分で2問を選択して解答すればよい。
「1問当たりの分量が増
えるのではないか?」
との疑問に対して、試験センターでは「午後
Ⅰの問題文や設問数は、従来と大きく変わらない」
と回答してい
る※ 5。実際、春期試験で実施されたプロジェクトマネージャ試

※4 問1と問2が必須問題、問3と問4が選択問題でいずれかを解答するという方式。
選択問題は必須問題より分量が多めで、配点も高く設定されていた。
※ 5 『情報処理技術者試験 新試験制度全国説明会 主な質問と回答』
( http://
www.jitec.ipa.go.jp/1_00topic/topic_20080422_shitsugi.pdf)
より。

IT アーキテクト Vol.24

024_tokubetu_1.indd 39

039

09/07/12 18:58

m

ープリント

特別企画1

情報処理技術者試験「          」のすべて

表9:AE試験とSA試験の午後Ⅱ試験の論述形式比較

プリケーションエンジニア

(AE)
試験

論述文字数

論述内容の例

論述文字数

論述内容の例

設問ア

800字以内

(通常600字~800字程度)
論述対象とするシステムの概要

800字以内

(通常600字~800字程度)
論述対象とするシステムの概要

システムアーキテクト
(SA)
試験

800 字以上、

システムの 設 計
設問イ
システム構築や設計上の工夫
システムの設計上の工夫
(通常1,400字~2,400字程度)
1,600字以内
上の工 夫( 通 常
1,600字~3,200
600 字以上、

設問ウ
システムの拡張やセキュリティなど、考慮すべき事項
工夫に対する評価と改善
(通常200字~800字程度)
字程度)
1,200字以内

設問イをひたすら論述し、残りの15 分くらいで設問ウに移れば、

表すように、設問に沿って15 個くらいの小見出しを考える。それ

最後まで書ききることができたのである。

ができたら、小見出しごとに100~200 字程度の論述をする。こ

 ところが SA 試験では、設問イと設問ウで文字数の指定が

れで改行のため空白になるマス目も含めれば、3,000 字程度の

別々になり、設問ウでもまとまった分量の論述が求められる。つま

論文が書ける。この作業に慣れれば、やがてPCを使わなくてもス

り、設問イと設問ウを適切に書き分ける必要があり、設問イから

トーリーが作れ、長い論文も手書きできるようになるだろう。

設問ウに移るタイミングの測り方も難しくなる。もし設問ウに移るの

 なお、背景説明を無視して自身の業務経験そのままに論文

が遅れると、時間切れになるからだ。合計の文字数は減ってい

を書いても、評価は低い。業務経験と完全に一致する問題が

るが、AE試験よりも難しくなったと考えて注意したほうがよい。

出ることはまれなので、問題文の要求に沿うよう、業務経験を基

●学習方法

にストーリーをアレンジすることも必要である。

 設問で指示されている論述文字数を合計すると、最低2,200

 また、作成した論文は他人に批評してもらうと、自分では気づ

字~最大3,600字となる。受験者の多くは、PCで長文を書くこと

きにくい改善点が見えてくる。これには通信教育を利用する方法

はあっても、手書きでこれほどの文字数を書く機会はほとんどな

のほか、職場の上司や同僚に意見を出してもらう方法などが考

いだろう。そのため、手書きの練習が必要になるが、いきなり長

えられる。

文を手書きしようとしても挫折してしまうかもしれない。

*  *  *

 午後Ⅱ試験の問題文の構成は、先に図 6で示したように、
ページの上半分が背景説明、下半分が設問だ。背景説明は

 以上、本企画では、10月に実施されるSA試験導入の背景

単に
“御託”
を並べたものではなく、設問とリンクしており、設問

から、試験の概要、そして試験対策までを解説した。本誌読者

で論述すべきポイントやヒントが示されている。その内容を読み取

の中には、この試験を心待ちにしていた方もおられるだろう。これ

り、PC上でストーリーを組み立てる練習をするとよい。PCならば、

まで情報処理技術者試験を受けたことのない方も、スキル判定

隔:0.5mm

文字の挿入や削除、入れ替えが簡単であり、
“思考支援ツー

のツールとして、この機会に一度試験を受けてみてはいかがだろ

0度

ル”
として役立つからだ。具体的には、論文のストーリー構成を

うか。

幅:0.05mm

100% オーバープリント

SA試験の実施要項

mm

m

 SA試験は例年、10月の第3日曜日に実施さ

の 20 時である。詳しくは、情報処理技術者試

れる。2009 年度は10月18日
(日)
の実施だ。

験センターの Web サイト
(http://www.jitec.

願書の提出は、郵送またはインターネット経由で

ipa.go.jp/)
を参照されたい。

行う。受け付けは7月13日
(月)
から始まっており、  なお、2008 年度の AE 試験の実施結果は、

ーバープリント

040

締め切りは郵送の場合が8月10日
(月。消印有

応募者1万1,318名、受験者7,327名、合格

効)
、インターネット経由の場合は8月19日
(水)

者825名、合格率は11.3%であった。

IT アーキテクト Vol.24

024_tokubetu_1.indd 40

09/07/12 18:58

o gGl o
eogle
pp App
gin
Ee
ngine
or for
a v aJ a v a
特別企画2

グーグルのクラウドが

Pythonに続いてJavaに対応

ついに企業システム開発技術の本命をサポート。
果たしてどこまで使えるのか?

Webアプリケーション環境としての実力を吟味する

今年 4 月、米国グーグルは同社のクラウド・
コンピューティング・サービス「Google App
Engine」の開発言語としてJavaをサポートし
た。昨年 4月のプレビュー版公開から1 年を経
て、ようやく今日の企業システム開発におけ
る中核言語がサポートされたかたちとなる。こ
れまでJavaでWebアプリケーション開発を行
ってきた企業の中には早速、同サービスの利
用を検討し始めたところもあるだろう。では果
たして、Google App EngineのJavaサポー
トは、オンプレミスの Javaを代替できるような
レベルに達しているのだろうか。本企画では、
Google App Engine の Java 対応の概要、
使い方、制約などについて、オンプレミスの環
境とも比較しながら解説する。

野上 忍

Shinobu Nogami

野村総合研究所 情報技術本部 先端技術開発部

IT アーキテクト Vol.24

google.indd 41

041

09/07/12 14:58

Google App Engineの
登場

Goog
Ap
Engi
fo
Jav

thonのみであった。Webアプリケーシ

(JVM)
の上でさまざまな開発言語
(の

ョン開発の世界でスクリプト言語の利

インタープリタ)
が動作するようになっ

用が進んでいるとは言え、PHP や

ており、Javaをサポートするということ

 Google App Engine(以下、

Perl、Rubyほどにはメジャーになって

は、それらの言語で書かれたプログラ

GAE。http://code.google.com/

いないPythonのみのサポートから始ま

ムも動作するということを意味する。

intl/ja/appengine/)
は、昨年 4月に

ったことは、多くの開発者を失望させ

実際、Java のほかに、JRuby、Java

開催されたグーグルの開発者コミュニ

た。それでも一部には、非常に魅力

Script
(Rhino)
、ScalaなどをGAEJ

ティ向けイベント
「Google Campfire

的なグーグルのインフラ基盤を利用す

の上で動作させた事例が明らかにな

One」
で初めて発表された。それまで

べく新たにPythonを学び、GAEを使

っており、それらの言語もGAEJ 上で

も、グーグルが提供する各種サービス

ったPythonベースのWebアプリケー

のWebアプリケーション開発に使える

は、例えばGoogle AJAX APIなどの

ションを作る開発者が出るほど、GAE

ようになる。

かたちでWebアプリケーションから利

登場のインパクトは大きかったのだ。

 なお、GAEJが発表された当初は、

用することができた。しかし、それらは

Python のときと同じく、利用登録が

GoogleマップやGoogle検索などグー

待望のJavaサポートの発表

可能なのは1万人までという制限があ

グルが提供する特定のサービスを、各

 GAEを発表した際、グーグルは
「サ

った。しかし、今年5月に開催されたカ

自のWebアプリケーションからWebサ

ポートする
“最初”
の言語はPythonだ

ンファレンス
「Google I/O」
において、

ービスとして呼び出して利用している

が、今後サポートする開発言語を追

その制限が撤廃され、だれでも登録し

にすぎないものである。

加していく」
という旨も公表していたの

て利用できるようになったと発表され

 それに対して、GAE の場合は、グ

で、次にサポートされる開発言語は何

ている。

ーグル自身が利用している膨大な数

で、それはいつかといったことに関して

のサーバ群はもとより、グーグルの各

さまざまな憶測と噂が流れた。そして、

種サービスのインフラ基盤となってい

ついに今年4月、昨年にGAEが発表

る分散ファイルシステム
「GFS
(Goog

されたのと同じGoogle Campfire

 それでは、GAEJ にはアマゾンなど

GAEJの特徴とメリット

le File System)

や、分散データベ

One において、GAE の Java 版(以

が提供する他のクラウド・サービスと

ース
「BigTable」
を使ったWebアプリ

下、GAEJ)
が発表されたのだ。

比べ、どのような特徴、メリットがある

ケーションを開発し、それをグーグルが

 GAE のサポート言語としてPython

のだろうか。

提供するホスティング環境で運用でき

に次いでJavaが加えられたことには、

るということから、Webアプリケーショ

大きな意味がある。まず、Javaは今

PaaSとして提供されるGAEJ

ン開発者の注目を集めた。つまり、

日の企業システム開発における中核

 クラウド・サービスは一般に、提供

GAEはグーグルが提供する汎用のク

言語の1つであり、それをサポートする

されるサービス・レイヤのレベルに応じ

ラウド・コンピューティング・サービスと

ということは、GAEが企業のWebアプ

て、図1に示すように
「IaaS
(Infrastru

して登場したのである。

リケーション・プラットフォームの候補

cture as a Service)
」、
「PaaS
(Pla

 しかし、1 つ残念なことに、開発言

に挙がりやすくなるということを意味す

tform as a Service)
」、
「SaaS
(So

語として最初にサポートされたのはPy

る。また、今日では Java 仮想マシン

ftware as a Service)」の 3 つに大

図1:クラウド・コンピューティングのサービスの種類とGAEの位置づけ
クラウド・サービスの範囲

代表的なサービス

グーグルのサービス

サービス/
アプリケーション

SaaS

Salesforce.com

Google Apps、
Googleマップ

ミドルウェア

PaaS

Windows Azure、
Force.com

Google App Engine

IaaS

Amazon EC2、
Amazon S3

OS
ハードウェア

042

google.indd 42

特別企画2

IT アーキテクト Vol.24

09/07/12 14:58

ogle
pp
gine
or
ava
別できる。

●GAEJのソフトウェア・スタック

たインフラの
“構築”
だけでなく、構築

 このうちIaaSは、ユーザーのアプリ

 4 月から提供が始まった GAEJ が

後の本番稼働時における障害や性

ケーションを動作させるインフラを、ハ

PaaSとして提供するソフトウェア・ス

能の監視、システムの保守といった

ードウェアからOSのレベルまで提供す

タックの概略は、図2のようになる。ご

“運用/管理”
も自前で行う必要があ

るというサービスであり、その代表例と

覧のとおり、JavaによるWebアプリケ

る。それに対して、GAEJを使うと、ア

してアマゾンの「Amazon EC2
(Elas

ーションの実行環境として、OS から

プリケーションやサービスの稼働に必

tic Computing Cloud)」や「Amaz

Java SE のランタイム
(JVM)
、Java

要となるそれらの作業を、すべてPaa

on S3
(Simple Storage Service)

EE 環境の一部までが提供される。こ

S の提供者であるグーグルに任せるこ

などを挙げることができる。なお 、

れらのソフトウェア・スタックの詳細に

とができる。これが、GAEJを使うこと

IaaSは、サーバやストレージ、ネットワ

ついては後ほど説明する。

の最大のメリットであろう。

ークなど、主にハードウェア・レイヤを

●GAEJがPasSとして提供されるこ

サービスとして提供することから、
「H

高いスケーラビリティ/可用性
を持つインフラ上で稼働

とのメリット

aaS
(Hardware as a Service)」

 ここで、GAEJを使うことのメリットを

呼ばれることもある。

考えてみたい。

 GAEJが提供するインフラ周りのサ

 一方 SaaSは、最上位のレイヤに

 最近では、クラウド・コンピューティ

ービスは、実はそれだけではない。こ

当たるアプリケーションをサービスとし

ングとの対比から、企業が自前で運

れについて整理するために、まず今日

て提供するというものだ。代表例とし

用する基盤で動作するシステムのこと

の一般的な多階層Webシステムのア

ては、CRMアプリケーションを提供す


「オンプレミス
(On-premise)」
と呼

ーキテクチャを考えてみよう。

るセールスフォース・ドットコムの「Sal

ぶ。オンプレミスの場合、当然 GAEJ

●一般的な多階層Webシステムの

esforce.com」
が挙げられる。

が提供するPaaSに相当する部分は、

アーキテクチャ

 そして、IaaSとSaaSの中間に当た

各社が自ら構築して運用することにな

 オンプレミスでWebシステムを構築

り、OS に加えてミドルウェアのレイヤ

る。つまり、サーバやストレージなどの

する場合、想定されるトランザクション

までサービスとして提供するのが Pa

ハードウェアの調達から、OSやミドル

量の変化や発生しうるシステム障害

aSであり、GAEJ はこれに分類され

ウェアのインストール/設定までといっ

を考慮して、今日では図 3 に示すよう

る。PaaSの場合、個別のアプリケー

ションはクラウド・サービスの利用者が

図 2:GAEJのソフトウェア・スタック

開発するが、アプリケーションのプラッ

トフォームとなるアプリケーション・サー
バやデータベースなどのミドルウェア、

サービス/アプリケーション
Java EE
(サーブレット・コンテナなど)

そしてミドルウェア上で動作する開発

Java SE
(JVM)

言語とセットになったWebアプリケー

OS

ション・フレームワークまでがクラウド・
サービス事業者によって提供されるこ

とになる。

スケール
アウト基盤

GAEJが提供する
サービスの範囲

ハードウェア
(サーバ、
ストレージ、
ネットワーク)

図3:一般的な多階層Webシステムのアーキテクチャ
Web層

ビジネス・
ロジック層

ロード・バランサ
データベース

ネットワーク

IT アーキテクト Vol.24

google.indd 43

043

09/07/12 14:58

Goog
Ap
Engi
fo
Jav

なスケールアウト構成のアーキテクチ

る。つまり、GAEJを使えば、アプリケ

ラウドの本来の特性であるオンデマン

ャをとるのが一般的である。これは、

ーションの開発者やユーザーは、スケ

ドによる計算リソースの割り当てを実

システムをWeb層とビジネス・ロジック

ーラビリティや高可用性を確保する仕

現し、動的にスケールアウトさせてい

層、データベース層に多階層化したう

組みを意識する必要がなくなるのだ。

るのだ。後述するが、GAEJではアプ

えで、Web 層の前面にロード・バラン

 それではGAEJは、スケーラビリティ

リケーションをステートレスに開発させ

サを配置し、リクエストを水平に負荷

や高可用性をどのようにして確保して

るので、それによってアプリケーション

分散して処理するというアーキテクチ

いるのだろうか。図 4 に示すのは、今

が異なるサーバ上に移動した場合で

ャだ。それにより、システム全体のス

年6月にグーグルが横浜で開催した開

も状態を引き継ぐ必要がなくなり、負

ケーラビリティや可用性を確保するの

発者向けイベント
「Google Develop

荷分散とフェールオーバが簡単にな

である。

er Day 2009」のセッションで解説さ

る。そうして、クラウドならではのスケ

 ただし近年、システムの大規模化や

れたGAEJのアーキテクチャの概略で

ーラビリティや高可用性を実現してい

トラフィックの増大に伴い、このアー

ある。ご覧のとおり、全体としてはロー

るのである。

キテクチャでもデータベースがボトルネ

ド・バランサで水平負荷分散を行うス

 加えてもう1つ、GAEJは多階層W

ックになることが目立つようになってき

ケールアウト構成になっている。クラ

ebシステムのボトルネックになりがち

ている。

イアントからのリクエストは、いちばん

なデータベース層に対しても、スケー

●GAEJのアーキテクチャ

近いグーグルのデータセンターにルー

ラビリティを高めるための機能を提供

 IaaSを利用する場合、上述したよ

ティングされ、App Engineフロントエ

している。GAEJ のデータ・ストアは、

うなシステム全体のスケーラビリティ

ンドに送られる。すると、後 述する

グーグルのインフラ構成要素の1つで

や高可用性を確保するためのアーキ

GAEJ の設定ファイル
(appengine-

ある分散データベースBigTableの上

テクチャは、提供されるIaaS の環境

web.xml)
で要素 staticに指定された

に構築されており、アプリケーション

や機能に合わせて利用者側で設計

静的コンテンツは、App Engineフロ

のデータをそこに保存するようにして、

し、構築しなければならない。これで

ントエンドによって処理され、動的なコ

スケーラビリティを高めることを可能に

は、オンプレミスによるシステム構築と

ンテンツへのリクエストはアプリケーシ

しているのだ。

大きく変わらない作業となってしまう。

ョン・サーバに転送して処理される。

 以上のように、GAEJはグーグルが

  一 方 、P a a S として提 供される

 さらに特徴的な機能として、GAEJ

これまで自社のサービス運用で使って

GAEJ の場合、高いスケーラビリティ

はリクエストを複数のサーバに分散さ

きた大規模かつスケーラブルなインフ

と可用性を持つグーグルのスケーラブ

せられるだけでなく、
トラフィック要求

ラ基盤を、一般の開発者が簡単に利

ルなインフラの上で、Webアプリケー

に応じて自動的にサーバを起動/停

用できるように解放したものである。

ション環境がサービスとして提供され

止できるようになっている。つまり、ク

そのため、多くの Webアプリケーショ

特別企画2

ン開発者の注目を集めているのだ。
図4:GAEJのアーキテクチャ

GAEJが提供する機能
リクエスト

 それでは、GAEJ の機能について
ロード・バランサ

App Engine
フロントエンド

App Engine
フロントエンド

App Engine
フロントエンド

アプリケーション・
サーバ

アプリケーション・
サーバ

アプリケーション・
サーバ

アプリケーション・サーバ
APIレイヤ
アプリケーション

アプリケーション

アプリケーション

その他のグーグルのインフラ
●BigTable
●Google Accounts
●Memcache
●Image操作

出展:
『Google App Engine: Now Serving Java』
(http://dl.google.com/io/2009/pres/W_1230_Ap
pEngine-NowServingJava.pdf)

044

google.indd 44

IT アーキテクト Vol.24

09/07/12 14:58

ogle
pp
gine
or
ava
詳しく述べていこう。

永続化プログラム
「DataNucleus」

 実際、Java サポートが発表された

ベースに実装されたJDO
(Java Data

今年のGoogle Campfire Oneのセ

サポートするJava環境と
サービス

Objects)API、および JPA(Java

ッションの中では、GAEJ 向けに開発

Persistence API)
を介して利用し、

した簡単なWeb アプリケーションを、

 GAEJがサポートするJava の実行

複数のアプリケーション・インスタンス

データ・ソースの設定を変更するだけ

環境は、Java SE 6のJREだ。また、

からアクセスできるキー/バリュー

でそのままIBM WebSphere 上で動

Java EE 環境はJava EE 仕様に完

(Key-Value)
型のキャッシング機能は

作させるというデモが披露されている。

全に準拠しているわけではなく、Java

JCache APIを介して利用する。さら

Servlet API 2.5 仕様と互換性のあ

に、Web アプリケーションから電子メ

るサーブレット・コンテナとして提供さ

ールを送信する際にはJavaMail API

クラウド環境に
特有の制限事項も

れる。そのため、GAEJ上のWebアプ

を使い、インターネット上のリソース

 先述したように、GAEJでは、ユー

リケーションは、JavaによるWebアプ

(Web サービスやその他のデータ)

ザーからのリクエストを複数のサーバ

リケーションの標準的なディレクトリ構

アクセスする場合には、URLコネクシ

に分散させたり、
トラフィック要求の増

成に従って開発し、画面はJSP
(Jav

ョンAPIを用いてURLフェッチ機能を

減に合わせてサーバを適宜起動/停

aServer Pages)
で作ることができる。

使える。

止したりできるようになっている。ま

このJava Servlet API 2.5互換のサ

 加えて、Javaの標準APIとは別に、

た、1 つのサーバの上で複数の Web

ーブレット・コンテナは、現状ではオー

独自の API
(パッケージcom.google.

アプリケーションを同時に動作させる

プンソースの「Jetty」

「Jasper」
をベ

appengine.api.*)
となるが、各サービ

こともある。こうした特徴を持つクラウ

ースにして実装されているが、Jettyに

スには低レベル APIが用意されてお

ド環境では、次のような点を考慮して

備わる独自の拡張機能はサポートして

り、それらを追加アダプタの実装に使

アプリケーションを動作させなければな

いない。今後の機能追加などによっ

ったり、アプリケーションから直接使っ

らない。

てベースとなる実装が変わる可能性

たりできる※1。

●クラスタ環境におけるJVM の自動

もあるので、独自機能などの内部的

 このように、Javaの標準APIを強く

なAPIは使わないことが強く推奨され

意識して機能が提供されている背景

ている。

には、次のような意図があるという。

 加えてGAEJでは、表 1に示すよう

●これまでに蓄積されたJava による

に、グーグルが提供するインフラ機能

Webアプリケーション開発のノウハ

起動/停止
●複数アプリケーション起動時にお
ける個々のアプリケーションの保護
●サービス品質の維持
 これらを実現するために、GAEJで

のサービスを、Javaの標準APIを通し

ウを有効に活用できるようにする

はJVM 上での処理に制限がかけられ

て使えるようになっている。例えば、

● 既 存の W e b アプリケーションを

ており、利用できるJava APIが一部

Webアプリケーションにグーグルのア

GAEJ上に容易に移行したり、ある

制限されたサンドボックス環境が提供

カウントを統合してユーザー認証を行

いはGAEJ 向けに開発したWebア

される。具体的には、GAEJ 上で動

い、それを各アプリケーションのアカウ

プリケーションを他のJava EE環境

ントとして使用できる。また、データ・ス

に容易に移行したりできるようにす

トア機能は、オープンソースのデータ

※1 これらのAPIの詳細については、GAEJのド
キュメントの
『Java Service APIs』
(http://code.
google.com/intl/ja/appengine/docs/java/
apis.html)
を参照されたい。

表1:Javaの標準APIを介して提供されるサービス

サービスの種類

Javaの標準API

サービスの実現基盤となるグーグルのインフラ機能

アカウント認証

Java Servet API

Google Accounts

データ・ストア

、JPA
(Java Persistance API)
JDO
(Java Data Objects)

BigTable

キャッシング

JCache
(javax.cache)

Memcache

メール

Java Mail
(javax.mail)

Gmailゲートウェイ

URLフェッチ

URLコネクション

キャッシングHTTPプロキシ

IT アーキテクト Vol.24

google.indd 45

045

09/07/12 14:58

Goog
Ap
Engi
fo
Jav

作するWebアプリケーションに対して

mming)
フレームワーク:AspectJ、

であり、親子関係にあるEntityをまと

は、次のような制限が課される。

Spring AOP

めて
「Entity Group」
と呼び、Entity

●HTTPリクエストに対しては30秒以

● Web アプリケーション・フレームワ

Group の単位でトランザクションを管

内にレスポンスを返す
(30 秒以上

ーク:Google Web Toolkit、Blaz

理できる。親子関係にあるEntity の

たつと自動的にプロセスが終了し、

eDS
(Flex)
、Grails

キーには、そのEntityが所属するEnti

ユーザーにはエラーが返される)

 通常の Web アプリケーションを開

ty Group の最上位の Entity( Root

●長時間のバックグラウンド・プロセ

発するうえで、サンドボックス環境の

Entity)
までのパスが含まれる。

API 利用制限はさほど問題にならない

 こうしたモデルをRDBのモデルと対

だろう。

比させると、RDB のテーブルに相当

スは実行できない
●サーバ側からのプッシュはできない

するものとしてKindがあり、その中で

 提供されるJava 実行環境のサンド

Entityはレコードに、キーは主キーに、

が制限される。つまり、アプリケーショ

キー/バリュー型の
データ・ストア機能

ンは、インターネット上の他のコンピュ

 これまで、通常のWebアプリケーシ

Groupはパーティションに相当すると

ボックスでは、表2に示す機能の利用

P r o p e r t y はフィールドに、E n t i t y

ータへの直接アクセスや、ファイルシ

ョンではリレーショナル・データ・モデ

考えられる
(図 5)

「分割されたソート

ステムへの直接書き込み、ネイティ

ルに基づくRDBMSがデータ・ストアと

済みの配列」
という表現は、Entity

ブ・コードによるJVM以外への直接ア

して使われてきた。一方、前述のよう

Group によってパーティション分割さ

クセスが禁止されるわけだ
(表中にあ

に、GAEJ のデータ・ストアでは、グー

れ、キーによってソートされた状態で

るように、利用が制限される機能につ

グルが開発した分散データベースの

保持されていることに由来する。

いては代替手段が示されている)
。な

BigTableをインフラとして利用してい

●データ保持の柔軟性

お、利用可能なAPIは、
『JRE Class

る。BigTableは、スケールアウト構成

 上記のようなデータ・モデルを持つ

White List』
(http://code.google.

を念頭に置いて設計された、いわゆる

GAEJ のデータ・ストアの特徴の 1 つ

com/intl/ja/appengine/docs/

キー/バリュー型のデータベースであ

は、データの保存が容易に行える点

java/jrewhitelist.html)
にリストアッ

り、グーグルはこれを
「分割されたソー

だ。具体的には、次のようなことが可

プされている。

ト済みの配列」
だと説明している。ここ

能となっている。

 もっとも、一部の機能の利用が制

で、一般の RDBとの違いをご理解い

●同一のKindに属するEntityに異な

限されると言っても、それらの制限事

ただくために、GAEJ のデータ・ストア

る数のPropertyを持たせること
(Va

項は注意深く設計されているので、

のモデルを簡単に説明しておこう。

riable Properties)

●同一のKindに属する2つのEntity

以下に挙げる主要なJavaフレームワ

 GAEJのデータ・ストアは、
「Entity」

ークが GAEJでも他の環境と互換性

と呼ばれる構造をデータの保持単位と

で、それぞれ同じ名前の Property

を保ったまま動作している。

しており、各 Entityはユニークなキー

に対して異なる型の値を持たせたり

● DI(Dependency Injection)
フレ

を持つ。Entityは、1つ以上の「Prop

(Heterogeneous Property Typ

ームワーク:Guice、Spring Fram

erty」
を持つことができる。Propertyと

es)
、異なる数の値を持たせたりす

ework

は、名前と値のペアである。Entity間

ること
(Multi-Value Properties)

には親子関係を持たせることが可能

 このように、GAEJのデータ・ストア

●AOP(Aspect Oriented Progra

表2:GAEJのJava実行環境で利用が制限される機能
制限されるもの

利用可能な代替手段

スレッド

(予定)
Async APIを提供

直接的なネットワーク接続

URLコネクション

ファイルシステムへの直接書き込み メモリ、Memcache、データ・ストア
Java 2D

ソフトウェア・レンダリングによるImages APIを提供

ネイティブ・コード

Pure Javaライブラリ

046

google.indd 46

特別企画2

IT アーキテクト Vol.24

09/07/12 14:58

ogle
pp
gine
or
ava

はスケールアウトを前提に設計されて

EJ の特徴を見ていこう。なお、ここで

リケーション開発と同様にEclipseを

おり、RDBであれば正規化すべきデ

はGAEJにおけるWebアプリケーショ

用いて開発作業が行えるようになって

ータも、非正規化したまま保持しやす

ン開発の特色を紹介することに重点

いる。ここでは、Eclipseを使った開

いデータ・モデルになっている。そのト

を置き、開発手順の詳細な解説は割

発の流れを紹介しよう。

レードオフとして、クエリやトランザクシ

愛する。それについては、GAEJ のド

ョンの使用に関して、RDBとの相違

キュメント
『スタート ガイド: Java』
(htt

や制限がある。先述したように、GA

p://code.google.com/intl/ja/app

Google Plugin for Eclipseの
導入

EJ のデータ・ストアにアクセスするた

engine/docs/java/gettingstart

 Google Plugin for Eclipseは、

めのAPIとして、Javaの標準APIであ

ed/)
を参照されたい。

通常の Eclipseプラグインと同様、
Eclipse のアップデート・マネジャを利

るJDOとJPAが用意されているが、デ
ータ・アクセスに関してもスケールアウ

アプリケーションの開発環境

用して簡単にインストールできる。そ

トを考慮したWeb アプリケーションを

 まず、GAEJにおけるアプリケーショ

の際、Google App Engine SDK

開発したければ、従来の Web アプリ

ンの開発には、最低限、次のものが

for Javaや「Google Web Toolkit

ケーションのデータ設 計を見 直し、

必要となる。

SDK」
といったGAEJ 用のライブラリ

GAEJ のデータ・ストアの特性を生か

● Java SE 6 SDK、または Java

も同時にインストールすることが可能

SE 5 SDK
(Java SE 6を推奨)

すような工夫が必要になるだろう。

● Google App Engine SDK for

GAEJにおける
Webアプリ開発の流れ

Java
(GAEJ用のライブラリ)

だ。Google Web Toolkit SDKは、
JavaでAjaxによるフロントエンドを作
ると、それを基にしてクロスコンパイラ

●GAEのアカウント

によってJavaScriptを生成してくれる

 このほかに、Eclipse 3.3/3.4 用

ツールである。これを使えば、複雑な

 ここまでの説明により、GAEJ の概

のプラグインである
「Google Plugin

JavaScriptを自ら書く必要がなくなり、

要がご理解いただけたことと思う。続

for Eclipse」
(http://code.google.

しかもクロスコンパイラにより、開発者

いて以降では、GAEJにおけるアプリ

com/intl/ja/eclipse/)
が提供され

が普通にコーディングするよりも読み

ケーション開発の流れを通して、GA

ており、Javaによる通常の Webアプ

込みや実行が高速なJavaScriptを
生成できることが多い。もちろん、Go

図5:RDBとGAEJのデータ・ストアのデータ・モデル

ogle Web Toolkit SDKを使わずに

●RDBのデータ・モデル

アプリケーションを作ることも可能だ。

テーブル

主キー

フィールド

フィールド フィールド

レコード

レコード

レコード

アプリケーションの開発
 開発するWeb アプリケーションの
Eclipseプロジェクトは、Google App
Engine用の新規Webアプリケーショ

ン・プロジェクト作成ウィザードを用い
て簡単に作成できる。このウィザード

※ 各レコードは同一構造。
●GAEJのデータ・モデル

Property

Entity

Row名

名前=値

名前=値

Entity

Row名

名前=値

名前=値

Entity

Row名

名前=値

名前=値

Entity
Group

Entity
Group

Property

キー

Kind

IT アーキテクト Vol.24

google.indd 47

047

09/07/12 14:58

Goog
Ap
Engi
fo
Jav

により、開発に必要となるライブラリ

で、サンドボックス環境は提供されな

GAEJ 上で動作させるには、開発した

がプロジェクトに設定され、アプリケー

い。そのため、GAEJ 上で使えない

アプリケーションを配備する必要があ

ションの雛型としてそのまま動作させら

APIを使っていないかどうかのチェック

る。配備の際には、GAEのアカウント

れるスケルトン・コードもWAR 形式の

を、アプリケーションのコンパイル時に

が必要になる。これをお持ちでない方

ディレクトリ構造で生成される。

行うためのツールが提供されている。

は、グーグルのアカウントでGAEの管
理コンソール
(http://appengine.go

 また、Google App Engine SDK
for Javaのアプリケーションに固有の

アプリケーションの配備/実行

o g l e . c o m / )にログインし、そこで

ファイルである「appengine-web.

 ローカル 環 境ではなく、実 際に

GAE のアカウントを取得していただき

xml」
も作られる
(リスト1)
。この設定
ファイルにより、GAEJ 上でのアプリ
ケーションの動作を指定できる。例え

画面1:アプリケーションのローカル実行

ば、静的コンテンツや SSL、セッショ
ンの使用の有無などを設定すること
が可能だ。
 Google App Engine SDKには、
クラウド上のGAEJ 環境をエミュレート
する開発用サーバ
(DevAppServer)
も同梱されている。これを使えば、作
成したアプリケーションをローカルな開
発環境で簡単に実行/デバッグする
ことができる
(画面 1)。なお、この開
発用サーバは、クラウド環境とは異な
りEclipseと同じ環境で動作するの
リスト1:appengine-web.xmlファイルの内容

画面2:GAEの管理コンソール

<appengine-web-app>
<application>application-id
</application>
<version>1</version>
<static-files>
<include path="/**.png"/>
<exclude path="/data/**.png"/>
</static-files>
<resource-files>
<include path="/**.xml"/>
<exclude path="/feeds/**.xml"/>
</resource-files>
<system-properties>
<property name="max-length"
value="140"/>
</system-properties>
<ssl-enabled>true</ssl-enabled>
<sessions-enabled>true
</sessions-enabled>
</appengine-web-app>

画面3:Eclipse上からのアプリケーションの配備

048

google.indd 48

特別企画2

IT アーキテクト Vol.24

09/07/12 14:58

ogle
pp
gine
or
ava

たい
(その際には、国内キャリアの電

るappspot.comドメインのサブドメイン

の配備が行える
(画面 3)
。配備が完

子メール対応携帯電話が必要にな

名になるので、全世界でユニークでな

了したら、その時点からアプリケーショ

る)

ければならない。

ンは GAE 上で実行可能な状態にな

 GAEのアカウントを取得して管理コ

 GAEでアプリケーションIDを登録し

る。バージョンを指定するのは、GAE

ンソール
(画面 2)
にログインしたら、ま

たら、Eclipse 側でもアプリケーション

上では複数バージョンを同時に実行

ずアプリケーション ID(Application

ID やバージョンを設定して appeng

できる仕組みになっているからだ。

Identifier)
を登録する。アプリケーシ

ine-web.xmlに反映すれば、Eclipse

 なお、配備したアプリケーションの

ョンIDは、アプリケーションを公開す

のメニューから簡単にアプリケーション

稼働状況は、管理コンソールのダッシ

画面4:ダッシュボードによるアプリケーションの稼働状況の確認

画面5:システム・ステータスによるシステム全体の状況の確認

ュボード
(Dashboard)
で常時確認す
ることができる
(画面 4)。システム全
体の状況は、システム・ステータス
(ht
tp://code.google.com/status/ap
pengine)
で確認する
(画面5)

 以上が、GAEJにおけるアプリケー
ション開発の大まかな流れだ。従来
のWebアプリケーション開発と何ら変
わらない環境/手順で開発が行える
ことがおわかりいただけただろうか。

料金体系と
今後の機能拡張予定
 最後に、GAE の料金体系と今後
の機能拡張予定に触れておこう。

従量制の課金体系
 GAEの利用料金は、クラウド・サー
ビスの大きな特徴の1つでもある従量
課金となる。GAEの場合、一定の範
囲までは無料で利用できる1日当たり
のクォータ
(割当量)
が決められてお
り、無料の範囲を超えた分について
課金される仕組みとなっている。課金
部分については、各リソースに対して

IT アーキテクト Vol.24

google.indd 49

049

09/07/12 14:58

Goog
Ap
Engi
fo
Jav

1日の利用限度額となるバジェット
(予

て制限の詳細については、GAE のド

われている。さまざまなリクエストが寄せ

算)
を設定し、バジェットの範囲内で

キュメントの
『クォータ』
(http://code.

られているようだが、現時点で予定さ

利用を継続できる体系となる
(表 3、

google.com/intl/ja/appengine/

れている機能拡張は次のとおりだ。

画面6、7)

docs/quotas.html)
を参照されたい。

●タスク・キュー

●フルテキスト・サーチ

 また、各ユーザーのアプリケーション
が互いの性能に悪影響を及ぼし合うこ

さまざまな機能拡張/改善を予定

●メール受信

とのないよう、リソースの使用やデー

 現時点で提供されているGAEJは、

●XMPP
(インスタント・メッセージング
機能)

タ・ストアAPIなど各APIの呼び出しに

「Early Look
(早期公開版)

とされる

ついて、日ごとや単位時間当たりのク

ものであり、利用者からフィードバック

●巨大ファイル・ストリーム

ォータが設定されている。この割り当

を受けながら、機能の改善と追加が行

●データ・ストアへのインポート/エク

特別企画2

スポート・ツール
表3:GAEの無料利用クォータと課金単位/料金

 これらの追 加が進めば、今日の

使用リソース

1日当たりの無料利用クォータ

追加費用(USドル)

CPU

6.5CPU時間

0.1ドル/CPU時間

Webアプリケーションで実現されてい

リクエスト
1GB
(合計して)
レスポンス

0.1ドル/GB
0.12ドル/GB

データ・ストレージ

1GB

メール送信

2,000通
(一般ユーザー)
0.0001ドル/メール
、5,000通
(管理ユーザー)

画面6:クォータの確認

0.005ドル/GB

る機能の多くに対応できるようになる
だろう。

*  *  *

 以上、本企画では、GAEJ の概要

や開発手順などの解説を通して、そ
の特徴を紹介した。ご覧いただいたよ
うに、GAEはPaaSとして十分な機能

を備えており、すでに GAE 上で本格

的なサービスの提供を開始していると
ころもある。開発言語としてJavaをサ
ポートしたことで、この勢いがさらに増

すことは明らかだ。従量課金という料

金体系も、評価や採用のしやすさに

つながり、システムのスモール・スター
トを容易にする。今後、読者の組織

でも、GAEJをWebアプリケーション
の開発/運用環境として利用する機

会があるかもしれない。それに備え、
一度GAEJ上でのWebアプリケーショ
ン開発を体験しておくとよいだろう。
画面7:バジェットと課金

050

google.indd 50

IT アーキテクト Vol.24

09/07/12 14:58

コン サル タ ン ト の 技 を 盗 め !

「100年に1度」
と言われる不況の中を企業が生き残っていくには、
市場の変化に迅速に対応し、いち早く商品/サービスを
投入できる柔軟な組織でなければならない。
また、それを支えるITにも相応の仕組みが必要だ。
今回は、これからの時代を見据えた組織のあり方と、
その組織にふさわしいITのあり方について考えてみたい。

荒井 岳

Takashi Arai

日立コンサルティング


12

経営のアジリティを高める、組織と
のあり方

I
T

はやり言葉を廃し、
ビジネスとITを密に結び付けろ!
 今、IT 業界では、クラウド・コンピューティングや
SaaS( Software as a Service)
がはやり言葉と
なっている。あちこちでこれらの言葉を聞くが、どうも
言葉だけが1人歩きしているような感がある。
 その原因の1つは、IT 部門がこれらの技術の有
用性を経営陣やユーザー部門に説明できていない
からだろう。それどころか、ITエンジニアでさえ十分に
メリットを理解していないケースもある。深刻な不況
が続く今の時代において、はやり言葉だけを並べ立
てても、予算は獲得できない。
 ここ数年、経営学の書籍やビジネス誌などにおい
て、
「経営のアジリティ
(Agility)」
とか「アジャイル
(Agile)」
とかいった言葉をよく目にするようになった。
アジリティ
(アジャイル)
は「俊敏性」
と訳され、企業
が市場やニーズの変化にいかに迅速に対応できる
かという能力を評するのに使われる。変化に応じて
素早く行動するには、組織の柔軟性を高めておく
必要がある。逆に言えば、組織の柔軟性が高けれ
ば、おのずと俊敏に動けるようになるということだ。
 ただし、柔軟な組織を編成しても、ITシステムが
それに追従できなければ足を引っ張ってしまう。そこ
で、組織の動きにITを追随させやすくするためのア
プローチの1つとして、クラウド・コンピューティングや
SaaSの活用への関心が高まっているわけだ。実際、
多くのSIerがクラウドやSaaSを用いたビジネスの展
開を検討しているが、
「そもそも何のために導入する
のか」、
「それによって自社はどのような価値を得られ
るのか」
といったことを明確に描けなければ、それは
はやり言葉に踊らされているにすぎず、何を導入して

052

IT アーキテクト Vol.24

問題解決テクニック.indd 52

09/07/12 17:47

抱える課題を考察してみよう。

も失敗するのは目に見えている。
 今回は、IT 用語や技術に疎い経営陣やユー
ザー部門に、クラウドやSaaSの重要性を理解しても

伝統的な組織が抱える課題

らい、ビジネス課題とITを結び付けた解決策に対す
る合意を得るために、その背景となる「あるべき組

 現在、多くの企業が採用している組織構造は、

織」
をきちんと理解することから始めたい。

軍隊や近代の鉄道事業がモデルになっている。そ
れらの事業などでは、現場のささいなミスが致命的

「業績が自動的に上がる」
という妄想

な大惨事を招くことがある。例えば、作戦の指示が

あり方」が課題に挙がる。業務効率の低さや部署

だ。こうしたミスをなくすには、組織を構成する大勢

連携の悪さ、内部の摩擦/衝突などの原因が組

の人間を確実に統制できる仕組みが必要になる。そ

織構造にあると転嫁するのだ。そして、組織再編を

こで、責任と権限を指揮官/ボスに集中させ、ヒエ

行うものの、期待した効果が得られない――そんな

ラルキーの構造によって機能別に編成した組織を

ケースが多々見受けられる。ひどいときには、組織の

統率するという現在の組織に通じるモデルが出来

名称と責任者の顔が変わっただけで現場は何も変

上がってきたのである※1。

わらず、以前と同じ作業を漫然と繰り返しているよう

機能しなくなった指令塔

なことさえある。
 組織構成をいじっただけで、単純に効果が上が

 現在、多くの組織が抱える課題を端的に表して

あるPeter Ferdinand Drucker 氏は、
「『業績を

いるのが、図1に示す調査結果だ。これは、営業組

自動的に上げる組織があるに違いない』
という妄想

織の管理職と営業担当者に対して、
「事業の不確

は捨てろ」
と説いている。組織の構造とは、目的を

実性」についてヒアリングした結果である。不確実

達成するための「手段」でしかない。組織編制で鍵

性とは、経営学において「何が起こるかわからないこ

となるのは、
「組織のメンバーがその能力を十分に

と、どう対処したらよいのかわからないこと」
を言う。例

発揮し、成果を達成しやすい風通しの良い環境を

えば、顧客のニーズがどのように変化し、自社はどの

いかにして作り出すか」
ということなのである。

ように対応していくべきかといったことや、競争相手に

 それでは、組織再編を成功させるにはどうしたらよ
いのか。それを明らかにするために、現代の組織が

I
T

のあり方

るようなことはない。経営学者であり、社会学者でも

12

経営のアジリティを高める、組織と

切り替えミスによって列車が衝突したりといった具合

現場の兵士に届かずに大敗を喫したり、ポイントの

善プロジェクトでは、必ずと言ってよいほど「組織の

 経営改革や業務改善など、さまざまな改革/改

※1 このような組織構造は、上意下達には適しているが、現場の人間
が判断して臨機応変に対応するには不向きだとされている。

図1:営業組織における不確実性の調査結果
(出典:
『機動営業力』
[著者:田村 正紀/発行:日本経済新聞社/発行年:1999年])
(回答率)
35%
情報の欠乏により、確実
性に大きなギャップが発
生している

「事業の不確実性に関する質問への回答率」

30%
25%
20%
15%
10%
5%
0%

管理職
営業担当者
まったく不確実

やや不確実

どちらでもない

やや確実

まったく確実

IT アーキテクト Vol.24

問題解決テクニック.indd 53

053

09/07/12 17:48

図2:調査結果の例
①優秀な企業

③最悪な状態

②危機的な状態

管理職

管理職

回答率

回答率

回答率

担当者

担当者

管理職

担当者

不確実

確実

不確実

確実

不確実

確実

打ち勝つためにはどのように戦っていけばよいのかと

場合、管理職の指示に従って動けばよいという単

いったことなどがその一例だ。

純な話ではないはずだ。最も現場の情報を知ってい

 調査結果によると、管理職は30%以上が「まった

るはずの担当者が何をすべきか理解できていないの

く不確実」
と答え、
「やや不確実」だとしている人を

は、非常に危機的な状態である。こうした現象が起

加えると半数以上がビジネスの次の展開を予測でき

きる企業は、ワンマン経営で、管理職は経営陣の

ないと考えていることがわかる。ところが、営業担当

指示どおりに動くだけのイエスマンばかりというケース

者は「まったく確実」、
もしくは「やや確実」
と考えてい

が多い。孫子の兵法で言えば、
「敵を知らずして己

る人が半数以上を占める。つまり、管理職と現場の

を知れば、一勝一敗す」
という状態だ。勝った数だ

担当者とで、完全に逆の結果が生じているのだ。

け負ける、つまり儲けナシのトントン経営だろう。

 この原因は、管理職の過去の経験や、それに基

 さらに、管理職と担当者の半数以上が「やや不

づく勘が今の時代に通用しなくなったことと、目まぐる

確実」、
「まったく不確実」
と答えた場合、組織が

しく変化するビジネス環境で、情報の欠乏や陳腐

破綻しているだけでなく、事業継続自体が危機的

化が頻発していることにある。これにより、司令塔であ

である最悪な状態だ
(図2-③)。孫子の兵法で言う

るべき管理職が、その役割を果たせなくなっているの

ところの「敵を知らず己も知らざれば、戦うごとに必

だ。前述のとおり現在、多くの企業の組織構造は

ず危うし」である。

司令塔が配下を統制し、意図どおりに活動させるこ

054

とを前提としている。その司令塔が機能しないのであ

成果を上げる柔軟な組織

れば、もはや古典的な組織構造は制度として成り

 それでは、今の時代に適した組織とはどのような

立たない。

組織なのだろうか。図 3は、営業組織の編成法別

 このような調査を読者の組織でも実施してみると、

に売上高成長率を調査した結果である。チャート

組織の課題が見えてくるはずだ。

の横軸は顧客タイプ別に組織を決めているか否か、

 調査の結果、図2-①のように管理職と営業担当

縦軸は商品タイプ別に組織を決めているか否かを

者の多くが「やや確実」、または「まったく確実」
と答

分類しており、それぞれが交差するマス目の売上高

えた場合、かなり優秀な企業だと言える。前回紹介

成長率が調査されている。

した戦略論「孫子の兵法」で言うならば、
「敵を知

 調査結果によると、売上成長率 8%という高い成

り、己を知れば、百戦して危うからず」
というのがこの

果を上げている組織では、商品タイプ別ではなく、

状態だ。ただし残念ながら、そのような優良な企業

顧客タイプ別にゆるやかなテリトリーを決めている。

はごく一部である。

次に成果を上げている組織は、商品タイプ別のテリ

 一方、図 2- ②のように管理職が「やや確実」、

トリーを決めないか、ある程度決めるにとどめ、顧客

「まったく確実」
と答え、担当者が「やや不確実」、

タイプはある程度、もしくは明確に決めている。逆に、

「まったく不確実」
と答えたとしたらどうだろうか。この

成果を上げていない組織は、顧客タイプをまったく

IT アーキテクト Vol.24

問題解決テクニック.indd 54

09/07/12 17:48

図3:営業組織の編成法と売上高成長率の調査結果(出典:
『機動営業力』)
顧客タイプ別組織編成

商品タイプ別組織編成

決めていない

決めていない

ある程度決めている

決めている

3.8%

8%

6%

最も売上高成長率が高い
ある程度
決めている

2.5%

6%

6.2%
次に売上高成長率が高い

決めている

2%

5.5%

2%
※ 数値は年間売上高成長率。

がプロジェクト・リーダーになる。例えば、Eビジネス

 これらの結果から考えられるのは、
「顧客タイプ別

が注目されているのならばその知識/経験を持つ

に専門性が必要になるため、ある程度の範囲を決

人間がリーダーとなり、内部統制が注目されている

めることは必要だが、顧客ニーズは多様化/複雑

のならばそれに詳しい人がリーダーを務めるといった

化するため、さまざまな製品/サービスを組み合わ

具合だ。伝統的な統制をつかさどる管理職を廃し、

せて提案できる体制が望ましい」
ということだ。

目的指向のリーダーを臨機応変に配置してプロ

 こうした組織編制をSIerの組織に当てはめると、

ジェクトを進める、フラットな組織編成のあり方だと言

産業(製造/流通)、金融、公共のように業種別

える。

にある程度顧客タイプを決めるか、または特定企業

プロジェクト型組織によるアメーバ経営

り扱う商品/サービスは限定せず、さまざまな業務

 組織のあり方を、時代の変遷と併せて鳥瞰する

システムやソフトウェア/ハードウェア、ネットワーク

と、図 4のようになる。それぞれの時代に応じて組織

……と幅広く対応できるようにしておく。つまり、個別

のあり方は変貌し、現在ではプロジェクト型の柔軟

ニーズに応じられる
「プロジェクト型組織」
として運営

な組織が望まれている。

するのである。

 プロジェクト型組織の典型的な経営モデルが、

I
T

のあり方

ごとに営業担当者を配置することになる。その際、取

12

経営のアジリティを高める、組織と

組織だ。

 プロジェクト型組織では、状況に応じて最適な人

決めない組織と、商品タイプを明確に決めてしまう

図4:組織形態の変貌
組織の複雑性

プロジェクト型組織
事業型組織
機能型組織
家族主義型組織

現代
組織の特徴

戦後復興期

1960∼1970年代

1980∼1990年代

2000年以降

●家長を中心とするカルチャーに
よる統率
●個人のモラルを中心に組織を運

●明確な機能分化がなく下働きは
何でもやる

●経営の近代化と生産性向上
●人員の増加に応じた組織階層
の深化
●効率を追求した機能別組織
●高度成長を支える大量生産(規
模の成長)

●顧客指向、
マーケット指向
●事業別に組織を編成
●多角化による事業部/子会社
の乱立
●組織の肥大化
●オープン化によるIT活用

●激変するビジネス環境と成熟し
たマーケット
●環境の変化に迅速に対応する
フラット型組織
●迅速に意思決定するための権
限委譲

IT アーキテクト Vol.24

問題解決テクニック.indd 55

055

09/07/12 17:48

バ経営とは、組織を細分化することで無駄なく自由

変化に柔軟に対応するための
アーキテクチャ

度の高い経営を行うというもので、社員は管理/統

 従来のように、事業部や工場、支社、子会社ご

制されるのではなく、自律自走で事業に取り組む。こ

とにバラバラのシステムが導入されていたのでは、組

のモデルでは、各組織が小集団/部門採算制を

織/業務の変化に応じた処理/機能の変更、各

とっており、若手リーダーが成果を見据え、それにか

種マスタ・データの定義や権限定義の変更、システ

かる費用や時間、利益などを管理する。
これによって、

ム間のインタフェースの改修などをそれぞれのシステ

やる気を醸成し、社員1人1人の経営意識を高める

ムで行わなければならず、それには膨大な労力/コ

京セラに代表される
「アメーバ経営」である。アメー

効果が得られるという。アメーバは、温度や湿度、

ストを要する。それを避けるには、事業部や子会社な

酸素などの環境が整えばどんどん自己増殖するが、

どの組織を柔軟に追加したり、既存のシステム機能

アメーバ経営もこれと同様に、制度や管理などの仕

をサービスに見立て、それらを組み合わせて
(再利

事環境を整えれば、上が管理せずとも優秀な社員

用して)新たな業務に対応したり、携帯電話や

が育つとされている。そして、これがビジネスの変化

PDAなどのデバイスを柔軟に追加/削除したりする

に合わせて迅速に形を変えられる組織へとつながる

ことのできる図 5のようなアーキテクチャ
(構造)
が必

のだ。

要となる。

 ただし、ここでも
「業績を自動的に上げる組織は

 特に業務システムに対しては、SOA(Service

ない」
ということには注意していただきたい。過去にア

Oriented Architecture)
などの技術を活用し、

メーバ経営を導入して社内が大混乱したり、余計

サービスを組み合わせてシステムを作ることで、業務

な作業が増えたり、社員の士気が低下したりといっ

の変更や新たなニーズに迅速に対応できるようにな

たケースもある。それらの企業の共通点は、単に組

ることが期待される。また、クラウド・コンピューティン

織編制や管理制度をアメーバ経営に変更しただけ

グを活用し、そうした仕組みをグループ企業内で共

で、なぜそれを実施するのか、
それによって何を達成

有するようにすれば、TCO(Total Cost of Owner

したいのか、社員にとって何が良くなるのかといった

ship)
の削減にもつながるだろう。

具体的なビジョン/目的が示されていなかったことに
ある。
アメーバ経営の鍵は、自律して取り組むことの

グローバル化やM&Aへの対応

意義を社員に十分に理解/浸透させることだ。権

 国内においてグローバル化やM&Aが一般化し

限委譲を伴う経営モデルであるため、社員のモラル

たことにより、今では多くの企業で図 5のようなアーキ

やモチベーションが高くないとうまく機能しないのであ

テクチャが強く求められている。過去に、製造業で

る。

は中国を生産基地として内包化する動きが進めら

 また、ITの対応も落とし穴となりうる。組織や業務

れていたが、現在では製品の販売マーケットと目さ

がアメーバのように柔軟に変化すると、それを支える

れており、流通業や小売業までもが参入を目論んで

業務システムも追従しなければならない。組織変更

いる。また、いわゆる
“リーマン・ショック”
が一瞬にし

の度に膨大なメンテナンス・コストが発生するような

て全世界を駆け巡ったことからもわかるように、今や

硬直化したシステムでは、こうした柔軟な経営モデ

グローバル化を抜きにしてビジネスは語れない。

ルに対応できないだろう。

 海外の子会社や海外企業との合弁会社を作っ
た場合、国内本社と密接な連携が必要となる。図

これからの組織とITのあり方

5のようなアーキテクチャを作り上げておけば、連携

 ビジネス環境の変化に臨機応変に対応していく

スなどを組み合わせて迅速に事業を立ち上げられる

ためには、組織だけでなく、ITのあり方も変わらなけ

だろう。

ればならない。以下、プロジェクト型組織を前提とし

 時間をかけずに大きな変化を起こすための手法と

て、これからのITシステムのあり方を考察してみたい。

して、今や多くの企業がM&Aを実施している。だ

する会社を追加し、必要な業務やサービス、デバイ

056

IT アーキテクト Vol.24

問題解決テクニック.indd 56

09/07/12 17:48

が、M&A 成立後の統合作業がスムーズに進まず

アーキテクチャを刷新するにはインフラから根本的に

に失敗する例が後を絶たず、成功率は3 割程度だ

再構築する必要があり、これはコストのかかる長期

と言われる。また、その際に行われるITシステムの統

的な取り組みとなる。ITの世界では、従来からツギ

合には、さまざまな
“問題の種”
が潜んでいる。

ハギ状態にあるシステムを統合する「EAI( Enter

 例えば、小売業を営むある企業が、競合する企

prise Application Integration)」の必要性が叫

業を買収したとしよう。この場合、当然それぞれの企

ばれていたが、いよいよ本腰を入れて取り組むべきと

業内にある購買管理や在庫管理、販売管理、財

きが来たのである。

務会計、人事給与といったシステムを統合すること

 ただし、企業がこれに単独で対応するには、膨

てグループ企業や同業他社と相乗りしたり、系列

になる。それぞれの企業のシステムを構築していたベ

会社で共用するといった工夫が必要だ。ユーザー

ンダーは、生き残りをかけて争い始めるはずだ。複

企業に対してそれらのサービスを提供するSIerは、

雑な事情が絡み合うため、
まとまる話もまとまらなくなる。

まず部分的な機能やアプリケーションに絞ってサー

 こうした場合にも、図5のようなアーキテクチャが作

ビスを開始することになるだろうが、同時に将来的に

られていれば、買収した企業を組み入れやすいだろ

確立するアーキテクチャを見据え、中長期的なロー

う。

ドマップとマイルストーンを確定する必要がある。その
うえで、
「どこへ向かって進むのか」、
「そのためには
いつまでに何をするのか」、
「それによってどのようなメ

 さて、図5のアーキテクチャは理想的で美しいが、

リットが享受できるのか」
といった点を経営陣やユー

現実にはそう簡単に実現できるものではない。なぜな

ザー部門が理解できる言葉でしっかりと伝えなけれ

ら現状、多くの企業システムは事業部門や子会社

ばならない。単にクラウドやSaaSといったはやり言葉

ごとの事情で異なるベンダー/仕様のものが個別

をベンダーの受け売りで使っているだけでは、経営

に導入されており、
“ツギハギ”
になっているからだ。

陣やユーザー部門の心には届かないのだ。

I
T

のあり方

まずはインフラ整備からスタート

12

経営のアジリティを高める、組織と

クオフィス部門などが重複すれば、人員削減の対象

大なコスト/労力がかかるだろう。それを緩和するに
は、クラウド・コンピューティングやSaaSなどを利用し

になる。取引先や物流拠点、提供する商品/サー
ビスなどについても見直しが入るだろう。加えて、バッ

図5:柔軟なアーキテクチャ
本社

倉庫

工場

組織/会社

経理

業務

アプリケーション

データ

サービス

製造

サービス

調達

サービス

新子会社の追加

サービス

新サービスの追加

デバイス

新デバイスの追加
インフラストラクチャ

IT アーキテクト Vol.24

問題解決テクニック.indd 57

057

09/07/12 17:48

既存システムの延命と
コスト削減の両立

 筆者は近年、SOA(Service Oriented Architec
ture)
の考え方をベースにしてさまざまな企業システムの設
計に携わってきたが、最近では市況の冷え込みから
「コス
トの削減」を要請されることが多くなっている。このコスト削

既存システムをフルに生かし、最小の投資で最大の効果を得る!

減で常に課題になるのが、
「IT全体の中で、最も多くのコ
ストを要しているのはどこか」を探ることだ。一般に、ITコス
トの6 割以上は既存システムの維持に割かれていると言わ
れる。その割合は企業によってさまざまだが、6 割というしき
い値を超えると、
「システム全体の見直し」
という舵が切ら
れることが多い。ただし、その場合でも、
「既存システムを
廃棄して全面的に作り替える」
といった対応はとられない
のが昨今の風潮である。今日求められているのは、
「既存
システムを生かしつつ、その維持コストを削減する」
という
難題を解決することなのだ。

第2回

既存システムを分析し、
業務との対応関係を把握する
前回は、システム統合に用いられるパターンを説明したうえで、
サービス指向に基づく統合手法の概要を紹介した。
この手法には、既存システムを生かすことで、
運用コストの削減を図れるというメリットがある。
ただし、この種のシステム統合でアーキテクチャを適切に設計するには、
業務と既存システムとの対応関係などに関して、
事前に多くの情報を集めなければならない。
第2回となる今回は、そうした情報を調査する
「既存システム分析」の作業について解説する。

岩崎 浩文

Hirofumi Iwasaki

豆蔵 シニアコンサルタント

058

IT アーキテクト Vol.24

システム統合.indd 58

09/07/12 17:58

 この課題に対する方策の1つに、SOAのアプローチに

業務とシステムの対応関係

基づいて既存システムを統合することが挙げられる。前

 既存システム分析を行う最大の理由は、
「業務とシステ

回は、主にこの方策の概要と有効性を述べたが、今回

ムの対応関係」を知っておくためだ。この情報が、スー

は既存システムを業務の視点で再整理し、システム全

パーシステム※1を設計する際には不可欠となる。

体の将来像を描くための土台を作る作業について説明

 情報技術(IT)
が発達した現在、業務とITは切っても

する。

切り離せない関係になっている。たとえ独自開発したシステ
ムやパッケージ製品など、それなりの規模のシステムを使っ

既存システムの分析

ていない場合でも、業務の中では、電子メールで営業活
動を行っていたり、ワープロ・ソフトで企画書を作成してい

 既存システムを統合するには、当然ながら、まず既存シ

たりと、目立たないが何らかのかたちでITが活用されてい

ステム自体を分析する必要がある
(以降では、この作業を

る。こうした「どの業務で、どのようにITが利用されている

「既存システム分析」
と呼ぶ)。ただし、一口に既存システ

のか」
といったことを知れば、個別システムの枠を超えた課

ムと言っても、その形態はさまざまだ。企業が独自に作った

題が浮かび上がってくる。例えば、出荷業務で3つのシス

カスタム・アプリケーションもあれば、パッケージ・アプリケー

テムが交互に使われていると判明した場合、それらを統合

ションも存在する。また、それらの中間として、既製品に修

し、1つのシステムで業務を完結させられるようにすべきであ

正を加えたものもあるだろう。このように、多様なシステムが

る。

分析の対象となる。

 また、こうした情報は、スーパーシステムを設計するとき

 また、各システムの保守の状態にもばらつきがある。仕

だけでなく、
「全体最適化」
と呼ばれる活動でも必要にな

様書(または、それに相当する資料)
をきちんと管理してい

る。この全体最適化とは、個別システムではなく、業務/

るケースもあれば、
「コードを直接見ろ」
と言わんばかりの

システム全体の観点から
「不要なシステムはないか」、
「シ

文書しかないケースもある。最悪の場合、現在動いている

ステム全体のアーキテクチャは適切かどうか」
といった事項

バイナリ・コード以外には、
ドキュメントはおろかソース・コー

を判断する作業のことを指す。これらの判断を正しく行うた

ドも含めて何も残っておらず、設計した当事者すらいないこ

めには、当然、業務/システムの対応関係を把握してお

ともあるのだ。詳細な仕様書があれば、既存システム分析

かなければならない。

は少ない工数で済ませられるが、仕様書が部分的に欠落
していたり、まったく残っていなかったり、あるいは残ってい

既存システム分析を行うべき局面

ても仕様書にリリース後の改修内容が反映されていな

 以上のことを踏まえると、既存システム分析を実施すべ

かったりするときは、工数が大きく膨らんでしまう。これまでに

き局面は、スーパーシステムの設計工程よりも、もっと前に

システムの現状を把握してこなかったツケを、ここで一気に

なることがわかる。では具体的に、どの段階だろうか。

精算することになるのだ。たとえ分析範囲を絞って工数を

 次ページの図 1 に示すのは、情報処理推進機構

抑えたとしても、ある程度の期間/コストがかかるのは覚悟

(IPA)
の「共通フレーム2007」の開発ライフサイクル
(主ラ

しなければならない。今後、同じ轍を踏まないようにするた

イフサイクル・プロセス)
を、本連載の内容に合わせて一

めには、プロジェクトが完了したら最終成果物として詳細

部改編したものだ。図を見ればわかるように、この開発ライ

な仕様書を残し、保守し続けていくことを肝に銘じておく必
要がある。

※ 1 複数の個別システムを総合し、1 つの仮想的なシステムと見なしたものの
こと。

IT アーキテクト Vol.24

システム統合.indd 59

059

09/07/12 17:58

第2回

既存システムを分 析し、業 務との対 応 関 係を把 握する

図1: 共通フレーム2007の開発ライフサイクル
(一部改編)
企画プロセス

運用プロセス
システム企画

既存システム
分析

全体最適化

業務移行/
運用/評価

システム構想
/計画

今回説明する範囲

要件定義プロセス

システム移行/
運用/評価

ビジネス要件定義

開発プロセス
システム要件定義
既存システム
分析

システム機能
要件定義
システム非機能
要件定義

システム
方式設計

システム適格性
確認テスト

ソフトウェア
要件定義

ソフトウェア適格性
確認テスト
ソフトウェア
開発/テスト

フサイクルには、要件定義プロセスや開発プロセスの前工

企画プロセスにおける分析作業

程として企画プロセスが存在する。企画プロセスとは、いわ

060

ゆる
「IT 戦略」の一部分に当たり、全体最適化を実施し、

 それでは、企画プロセスでの既存システム分析について

システム全体の構想/計画を練る
(システム構想/計

説明していこう。なお、先述したように、既存システム分析

画)工程である。業務/システムの対応関係は、そうした

は本来、企画プロセスの最初に実施すべきものだ。しかし、

作業を行う前に明らかにしておくべきだ。したがって、既存

本連載で例に用いているReDAプロジェクトは、もともと販

システム分析は、企画プロセスの最初の段階で実施するこ

売システムの全面刷新/新規開発を目的に開始されたも

とになる。

のである。プロジェクトの途中でシステム統合を採用するこ

 また、既存システム分析は、開発プロセス内のシステム

とになったわけだが、その時点で、すでに企画プロセスと要

要件定義の中で、
もう一度さらに詳細なレベルで実施しな

件定義プロセスは完了しており、既存システム分析は行っ

ければならない。この開発プロセス時の既存システム分析

ていなかった。そのため、システム要件定義の前に、この

に関しては後述する。

分析作業を割り込ませるというかたちをとっていることに留

 なお、企画プロセス時の既存システム分析については、

意されたい。

後フェーズのシステム要件定義にも密接にかかわるため、

 さて、企業内の業務は、1つのシステムだけで完結する

以降で詳しく説明していく。ただし、全体最適化やシステ

ことは少なく、複数のシステムをかわるがわる使って回してい

ム構想/計画といった企画プロセスでの他の作業は、本

るケースがほとんどだ。そこで、まず各業務で利用されてい

連載の対象範囲から外れるので、深く言及しないことをあ

るシステムを把握するために、企業全体の業務の連鎖(バ

らかじめお断りしておく。

リュー・チェーン)
を割り出す。

IT アーキテクト Vol.24

システム統合.indd 60

09/07/12 17:58

図2: 業務機能構造図
バリュー・
チェーン
PDC
サイクル

商品企画

市場リサーチ
計画
(Plan)

調達

調達先リサーチ

販売

配送

共通サービス

販売計画

配送チャネル計画

中期計画

配送チャネル構築

年次計画

マーケティング
特売企画
イベント企画

実行
(Do)

新商品企画

製造会社からの調達

営業活動

出荷指示

人事管理

サンプル試作

在庫管理

見積もり

ピッキング梱包

経理

市場評価測定

受注

配送指示

アカウント管理

特売実施

請求

出庫

在庫管理

イベント実施

カスタマー・サポート

情報システム管理

顧客管理
監視
(Check)

予実管理

予実管理

予実管理

予実管理

監査

Go/Not Go判断

 割り出したバリュー・チェーンは、
「業務機能構造図」

財務管理

図3:業務機能ツリー
営業活動予定を立てる

に記述する。これは、バリュー・チェーンを横軸に、PDC

営業活動

(Plan/Do/Check)
サイクルを縦軸にして、商品企画や

顧客情報を処理する

ているのかを表現したものだ。この図が、今後の分析作

見積もり依頼を受ける
与信を確認する

業を進めていくうえでの開始地点となる。図 2に示すのが、

見積もり

ReDAプロジェクトにおける業務機能構造図である。

受注

受注内容を修正する
請求

請求書を検索する
電話に応対する
封書に応対する

カスタマー・サポート

顧客情報を確認する
応対履歴を確認する
応対内容を記録する

める
(次ページの表 1)。この表を記述するうえで重要なの

応対内容の統計をとる

は、業務機能構造図に示した業務機能のうち、各既存
システムがどれを担うのかを明らかにすることだ。これにより、

請求書を出す
入金を確認する

 また、業務機能ツリーを描くのと並行して、システム統
システムが担う業務機能などを「既存システム一覧」にまと

納期を回答する
受注する
受注内容を検索する

機能ツリーにおける最小単位の業務機能が、スーパーシ

合の対象となる既存システムの概要やアーキテクチャ、各

見積もりを提示する

顧客情報を確認する

販売業務の実行(Do)

現した業務機能を、より細かく整理したものである。業務
ステムの中で連携するサービスの候補となる。

見積書を作成する
見積書を検索する
見積書を修正する

 続いて、この業務機能構造図を基に、業務をさらに分
だ。このツリーは、業務機能構造図で最小単位として表

電話に応対する
営業報告を行う

販売といった各業務機能がどのような作業で構成され

解していく。その成果物が、図3に示す「業務機能ツリー」

営業に回る

各部門へフィードバックする
顧客管理

顧客情報を検索する
顧客情報を修正する
顧客情報を削除する
顧客情報を登録する

※ 紙幅の都合上、
この図では販売業務の実行(Do)
に関する業務機能のみを
示しているが、本来は対象となるすべての業務(ReDAプロジェクトの場合、商品企
画から共通サービスまで)
を分析/記述する。

IT アーキテクト Vol.24

システム統合.indd 61

061

09/07/12 17:58

第2回

既存システムを分 析し、業 務との対 応 関 係を把 握する

業務機能とシステム機能(システムの責務)
の対応関係や

ていた業務機能を補う目的から、パッケージ製品を使って

各システムの存在意義を理解し、システム・ダウン時の影

構築されたシステムだ。2001 年にリリースされた。ただし、

響範囲などを把握できるようになる。

パッケージ製品を独自に拡張して作り込んだため、ベース
となるパッケージ部分をバージョンアップすると動作に問題

ReDAプロジェクトで

統合対象となるシステムの概要

が生じる。よって、最新版へのアップグレードは断念してお
り、現在使用しているJava 実行環境のサポート期限が

 前掲の図2、図3、および表1に示した情報は、ReDA

迫っていることが直近の課題となっている。

プロジェクトで既存システム分析を行った結果である。この

 3つ目の「Neo ReDA SALES」は、2005年にリリース

うち、表 1の内容から、ReDAプロジェクトが対象とする販

された比較的新しい独立型のシステムだ。販売計画に関

売業務で使われている既存システムは3つだということがわ

する機能を中心にいくつかの機能を実装しているが、新シ

かる。ここで、それらのシステムの概要を説明しておこう。

ステムを構築するまでの暫定システムという位置づけにある。

 1つ目の「ReDA SALES」は、1992年にリリースされた

サポート・プロで直面した問題を避けるためにパッケージ

システムだ。当時はスタンダードだったメインフレームで構

製品は採用せず、カスタム・アプリケーションとして構築され

築されている。リリースから十数年が経過しており、すでに

た。開発コストを抑えたため、ReDA SALESとは夜間バッ

技術者が不足気味で情報も失われつつある。ここ数年は、

チで同期をとるときだけ連携するようになっている。ただし、

簡単な修正であっても多くの時間/コストを要することが

これによって業務が遅延しがちになっており、より迅速かつ

問題視されてきた。ReDAプロジェクトは、もともとReDA

シームレスな連携/統合が経営課題として挙がっている

SALESのハードウェア保守期限切れを契機に始まった

状況だ。

が、紆余曲折の末、現在はこのシステムと他システムを統

 このように、どれも理想的なシステムとは言えず、それぞれ

合し、それら既存システムの活用法を探ることが目的になっ

のシステムは多くの問題点を抱えている。運用部隊が手厚

ている。

く支援することで日々の業務をこなせているというのが実情

 2つ目の「サポート・プロ」は、ReDA SALESに不足し

だ。

表1:既存システム一覧

システム名

システム
概略

リリース年

種別

クライアント側の
アーキテクチャ

ョン・サー
アプリケーシ
バ側のアーキテクチャ

データベース

担当業務機能

●営業活動

●見積もり
カスタム・ ●Windows 2000
●アプリケーション・

業務支援
1992年
●商用メインフレーム
●受注
ReDA SALES
アプリケー
● 3270 端末エミュレー
サーバに同居
システム
(逐次改修)
●COBOL言語
●請求

ション

●ISAMファイル
●顧客管理

●予実管理

●商用UNIXサーバ

サポート
2001年
パ ッケ ー
●Windows 2000
●商用Java EEアプリケ
●商用UNIXサーバ
●顧客管理
業務
(数度バージョ
ジ・アプリ
● Internet Explorer
ーション・サーバ
●商用データベース・ ●カスタマー・
サポート・プロ
システム
ンアップ済み)
ケーション
5.5専用
● J2EE 1.3 仕様アプリ
サーバ
サポート

ケーション

●商用Windowsサーバ

●Windows 2000 Ser
販売計画
カスタム・ ●Windows 2000
●商用UNIXサーバ
●販売計画

Neo ReDA
ver
支援
2005年
アプリケー
● .NET Framework
●商用データベース・ ●営業活動
SALES
●IIS

システム
ション
1.1
サーバ
●顧客管理
●.NET Framework 1.1

仕様アプリ
ケー



062

IT アーキテクト Vol.24

システム統合.indd 62

09/07/12 17:58

非機能要件の調査

に分類した副特性も規定している
(図 4)。それらに関する

 既存システム分析で調べるのは、業務の面だけではな

説明は割愛するが、興味のある方は日本工業標準調査

い。非機能要件も調査する必要がある。非機能要件とは、

会のWebサイ

(http://www.jisc.go.jp/)
をご覧いただ

簡単に言えば、対象の業務を処理するために実装する

きたい。

機能以外の要件のことだ。例えば、ISO/IEC 9126-1

 分析後の全体最適化を行ううえでは、上記6つの特性

(JIS X 0129-1)
では、非機能要件として次の6つの品質

のうち、特に使用性と効率性、保守性、移植性の4つが

特性が挙げられている。

重要になる。使用性はユーザーの投資判断に直接的な

●機能性:業務の処理に必要な機能を提供する能力

影響を及ぼし、効率性は業務の実行スピードに与えるイ

(業務との適合性や処理結果の精度、他システムとの

ンパクトが大きい。保守性や移植性は、システムの存在可
能時間(寿命)
を左右することになるだろう。

連携のしやすさ、セキュリティなど)
●信頼性:故障や障害の発生も踏まえて、事前に決めら

 また、こうした特性に加えて、非機能要件を調査する際

れた達成水準(MTBF[Mean Time Between

には、システムを構成する各技術要素を今後どれくらいの

Failure:平均故障間隔]やMTTR[Mean Time

期間、製造元がサポートし続けるのかも確認すべきだ。例

To Repair:平均復旧時間]
など)
を維持する能力

えば、システムのプラットフォームを構成するハードウェア製

●使用性:ユーザーの使い勝手に関する能力(ユー

品やOSなどのベンダー・サポートが切れるということは、そ
のシステムが死を宣告されるのとほぼ同義である
(ベン

ザー・インタフェースや操作性、見た目など)
●効率性:ソフトウェア/ハードウェアや時間といった資源

ダーの力を借りずに保守し続けるという道もあるが)。この

の量が少なくても、適切な性能を発揮する能力
(システ

場合、OSのバージョンアップや同種のハードウェアへの

ムの応答時間など)

移植、あるいは他のプラットフォームへの移行といった対応

●保守性:修正のしやすさに関する能力
(障害原因の追

をとることになるが、いずれにせよソフトウェアを修正する必
要が出てくる。近年では、アプリケーション・サーバやデー

及のやりやすさや、テストの容易性など)
●移植性:ある環境から他の環境に移すための能力
(ここ

タベース・サーバなどのミドルウェア、その上で利用するライ

で言う環境には、プラットフォームからデータセンター、

ブラリなどのサポート切れが問題になりやすい。また、コン

組織までが含まれる)

パイラなどを含む開発環境にも注意すべきである。開発環

 なお、ISO/IEC 9126-1では、これらの品質特性をさら

境のサポート切れは、それを使って作成したソフトウェアが

図4: 外部および内部品質のための品質モデル
(出典:ISO/IEC 9126-1[JIS X 0129-1])
外部/内部品質

品質特性

機能性

信頼性

使用性

効率性

保守性

移植性

副特性

●合目的性
●正確性
●相互運用性
●セキュリティ
●機能性標準適合性

●成熟性
●障害許容性
●回復性
●信頼性標準適合性

●理解性
●習得性
●運用性
●魅力性
●使用性標準適合性

●時間効率性
●資源効率性
●効率性標準適合性

●解析性
●変更性
●安定性
●試験性
●保守性標準適合性

●環境適応性
●設置性
●共存性
●置換性
●移植性標準適合性

IT アーキテクト Vol.24

システム統合.indd 63

063

09/07/12 17:58

第2回

既存システムを分 析し、業 務との対 応 関 係を把 握する

正常に動作するという裏づけがなくなることを意味するから

適化を行う。この作業では、ここまでの調査/分析で得

だ。安定した動作が求められる企業システムにおいて、そ

た情報を基に、システムのあるべき姿を描くことになる。全

のような事態は避けるべきだろう。もしシステムの構成要素

体最適化を実施した後は、システム構想/計画を経て、

にサポート切れが迫っているようであれば、それによってど

要件定義プロセスへと進んでいく。この要件定義プロセス

のような問題が起こるのか、その問題が顕在化するとどうい

については、本誌 Vol.15~21 掲載の連載記事『上流工

う制約が生じるのかを確認しておく必要がある。

程を極める
! 事例編』
で詳しく解説されている。関心のあ

 以上を踏まえて、ReDAプロジェクトでは、3つのシステ

る方はそちらの記事をお読みいただきたい。

ムについて非機能要件を調査した。その結果を表 2にまと
めた。

システム要件定義における分析作業

システム構成技術の動向調査

 さて、ここからは、本連載のハイライトともなるシステム要

 既存システム分析では、先に述べた業務/システムの

件定義の説明に入る。システム要件定義では、企画プロ

対応関係や非機能要件のほかに、既存システムで使わ

セスと要件定義プロセスの結果を踏まえて、スーパーシステ

れている技術と、その動向も調べる必要がある。古くから

ムの設計を行うことが目的になる。

運用されているシステムの場合、今日の一般的なソフトウェ

 単体システムの新規開発ならば話は別だが、既存シス

ア/ハードウェア技術とは異なるものが使われていることが

テムの修正がほとんどであるシステム統合の場合、システム

多いからだ。この調査を行うときには、
「これからも使い続け

全体をどう再構成するかがシステム要件定義での検討の

ることができるのかどうか」
という観点から、対象技術の現

中心になる。この検討にあたっては、企画プロセスで調べ

状をよく見極めることが重要になる。

たときよりも詳細な既存システムの情報が必要だ。そのた

 例えば、過去に広く用いられていた技術ならば、現在で

め、ここでの既存システム分析は、対象システムの適用業

も使われ続けているケースが多く、多数のベンダーが技術

務や実装技術に精通したITエンジニアを集めて進めてい

サポートを行っているはずであり、その価格を合い見積もり

くことになるだろう。

などで調整することも可能だろう。また、その技術に関する
知見を持ったエンジニアが、社内に在籍していることも考え
られる。今後も使い続けていくための手段は豊富にある。

トレーサビリティの確保と
“開発時の情報分断”

 一方、あまり一般的ではなかった技術の場合、今と

 システム要件定義における既存システム分析では、企

なっては数少ないベンダーが細々と続けている技術サポー

画プロセス時よりもさらに深いレベルで業務機能と既存シス

トだけしか、使い続ける手段がないというケースがほとんど

テムを対応づけていくが、ここで重要になるのが「トレーサビ

だ。こうなると、ベンダー側の言い値でサポート価格が決ま

リティ」の観点だ。業務の構造をどれだけ正確に分析でき

りやすく、運用コストは膨らみがちになる。また、技術者の

たとしても、その成果とひも付けずに、つまりトレーサビリティ

確保という面でも苦労することになるだろう。

を無視してしまうと、業務に適合しないシステムとなるからだ。
その結果、投資は無駄になり、プロジェクトは失敗したと見

既存システム分析完了後の流れ

064

なされるだろう。

 既存システム分析を実施し、業務の構造や業務/シス

 こうした
“開発時の情報分断”
の問題を避け、業務から

テムの対応関係を可視化したら、前述したように全体最

システムの機能要件を的確に導き出すためには、企画プ

IT アーキテクト Vol.24

システム統合.indd 64

09/07/12 17:58

表2:3つの既存システムの非機能要件
非機能要件
非機能要件
(小項目)
(大項目)

ReDA SALES

サポート・プロ

Neo ReDA SALES

保存する情報の種類を増やすことが
ReDA SALESで足りない機能を補う
業務の変更により、業務内容との齟

合目的性
望まれているが、項目の数が足りない
ように作られており、問題はない
齬が発生している
という問題が発生している
エラーが発生すると、まれにデータの
特定の処理を実行すると、まれにデー

正確性
特になし
不整合が起きる
タの不整合が起きる

機能性

Webサービスに対応した3階層構成に
クライアント・アプリケーション以外と
相互運用性
特になし
なっている
の連携は考慮されていない

標準適格性
J2SE 1.4.2とJ2EE 1.3
.NET Framework 1.1
COBOL
(方言あり)

セキュリティ

独自仕様。IDとパスワードで認証

独自仕様。IDとパスワードで認証

Active Directory連動型認証

機能性標準適合性

特になし

特になし

特になし

エラー時はログを出力して処理を中止
エラー時はロールバック処理が行われ
エラー時はロールバック処理が行われ
成熟性
する



障害許容性
(MTBF)
1年間
(8,765時間)

信頼性

1年間
(8,765時間)

1年間
(8,765時間)

回復性
(MTTR)
3時間

3時間

3時間

信頼性標準適合性
特になし

特になし

特になし

ダム端末のエミュレータで動作している
Webアプリケーションであり、操作は難
リッチ・クライアントのため、操作はわか
理解性
ため、操作がわかりづらい
しくない
りやすい


キーボード操作が必須のため、習得に
習得性
内容さえ理解できていれば習得は早い
内容さえ理解できていれば習得は早い
時間がかかる


キーボード処理とマウス操作の両方に
使用性
キーボード操作のため、熟練者は高速
Webブラウザ上の操作のため、熟練
運用性
対応しているため、熟練者は高速に、

に処理できる
者でも操作に時間がかかる
初心者でも問題なく操作できる


黒背景に白文字という単純な画面の
見た目がよくなるよう、商用製品をベー
Windows の標準にのっとって普通に
魅力性
ため、見た目はよくない
スにカスタマイズされている
デザインされている

使用性標準適格性
特になし

HTML 4.01

特になし

時間効率性
原則として平均10秒以内の応答時間

原則として平均10秒以内の応答時間

原則として平均10秒以内の応答時間

資源効率性
未定
未定
効率性

未定

効率性標準適合性
特になし
特になし

特になし

パッケージ製品のためにブラック・ボッ
. N E T に不慣れな開発者が作ったた
コードの品質も含め、決して良い状態
解析性
クスの部分が多く、解析可能な範囲

め、あまり良くない
ではない
に制限がある
度重なる拡張により、修正がしにくい
パッケージ製品のため、変更可能な個

変更性
まだ余裕あり
保守性
部分が多い
所は限定的

特になし

特になし

試験性
特になし
特になし

安定性
特になし

特になし

保守性標準適合性
特になし

特になし

特になし

ハードウェアを拡張する以外の手段は
クラスタ構成に対応。また、ユーザー
ハードウェアを拡張する以外の手段は

環境適応性
が個別にトップ・ページを持てる
ない
ない
設置性
データセンターに相当する施設が必須
データセンターに相当する施設が必須
データセンターに相当する施設が必須


Java EEに準拠しており、同一ハード

IISの機能により、他システムと並行稼
ウェア上で他システムと並行稼働させ
ハードウェアの仮想化に対応できる可
共存性
働させることができる
るのは可能かもしれないが、サポート
能性がある
移植性

の対象外

.NET Framework 1.1の仕様に準拠
同一プラットフォーム以外で動作させる
J2EE 1.3準拠だが、特定のプラットフ
置換性
したプラットフォーム上であれば動作す

のは不可能
ォームにしか対応していない

移植性標準適合性

特になし

特になし

特になし

IT アーキテクト Vol.24

システム統合.indd 65

065

09/07/12 17:58

第2回

既存システムを分 析し、業 務との対 応 関 係を把 握する

ロセスの成果物(IT 戦略)
や業務構造から機能要件へと

能を整理していく。その際には、システム間で重複している

つなげていく、つまり
“トップダウン型のアプローチ”
で分析

業務機能を把握することが重要になる。

を進めていく必要がある。フルスクラッチの新規システム開

 図 5に示すのは、ReDAプロジェクトで対象となるシステ

発であれば、このトップダウン型のアプローチによってトレー

ムが、それぞれどの業務機能を担当しているのかを視覚

サビリティを確保し、さしたる滞りもなく既存システム分析を

的にまとめたものだ
(図5は便宜上、業務機能構造図のレ

終わらせて開発作業に入っていけるはずだ。

ベルで記述しているが、この段階では本来、業務機能ツ

 ただし、システム統合では、そうはいかない。それぞれの

リーのレベルで対応づけを把握する)。この図からは、3つ

既存システムは、現状のシステム構成という大きな制約を

のシステムが受け持つ業務機能が部分的に重複している

持っており、これが分析を進めるうえでの足かせとなるのだ。

ことがわかる。特に顧客管理については、それぞれのシステ

特にReDAプロジェクトのように、複数のシステムによる複

ムが独立しているためでもあるが、ほぼ同じ機能を各シス

合的な制約(コストの縛りや、変更が不可能なパッケージ・

テムが持ってしまっている。また、営業活動も、ReDA SA

アプリケーションの採用など)
が絡むと、現場の開発者は

LESとNeo ReDA SALESが該当する機能を備えている。

「制約を守るだけで精一杯なのに、わざわざトップダウン

このように、各システムが担当する業務機能が重複してい

型で分析していく必要があるのか」
と煩わしく感じるかもし

る場合、それらの業務機能が扱う情報(データ)
の同期を

れない。現場からすれば、
「既存システムの詳細な実装を

とらなければならないが、その同期処理は3つのシステムとも

知らずに分析した結果など、実際に使えるわけがない」、

に夜間バッチで行っている。

「机上の空論は役に立たない」、
「システムにはシステムの

 こうした重複部分は、業務機能ツリーで整理した業務

都合がある」
といった印象を抱きかねないのだ。
もし、こうし

機能のレベルで見たら、さらに多く見つかるかもしれない。

て彼/彼女らにトップダウン型のアプローチをとるのが無

それらの重複部分を把握することも、既存システム分析で

駄だと思われてしまうと、企画プロセスで得た情報が
“参

は必要になる。次回は、業務機能ツリーのレベルで業務

考程度”
という位置づけに格下げされ、無視されていくこと

機能と既存システムをマッピングしつつ、具体的なシステム

になる。こうなると、もちろんトレーサビリティは確保できない。

要件を割り出していく。

最悪の場合、本来の業務とはかけ離れた既存システムが
リリースされ、やがて「システムに合わせるために業務をゆ

図5: 各業務機能と担当システム

がめる」
という本末転倒の事態に陥るおそれすらある。
見積もり

営業活動

業務機能ツリーとシステムの対応づけ
 筆者らの場合、上述したトレーサビリティを確保するた
めに、
「サービス指向の観点から業務機能と既存システム

販売計画
受注

を対応づける」
という方式をとっている。具体的には、業
務機能ツリーを用いて最小単位の業務機能を導出し、そ

顧客管理
予実管理

れらと既存システムとを対応づけるのだ。この最小単位の

カスタマー・
サポート

業務機能が、スーパーシステムにおけるサービスとなるわけ

サポート・プロ

である。
 対応づけを行った後は、各システムが受け持つ業務機

066

Neo ReDA SALES

ReDA SALES

IT アーキテクト Vol.24

システム統合.indd 66

09/07/12 17:58

B o oks

『クラウドコンピューティング
̶̶技術動向と企業戦略』
著者■森 洋一
発行■オーム社
価格■1,680円

新刊書籍情報

 ここ1、2 年で急速に脚光
を浴びるようになったクラウ
ド・コンピューティングの現状
を解説した1 冊。クラウドが
登場した背景や現行のサー
ビス、仮想化/グリッド・コン
ピューティングといった関連
技術などを紹介したうえで、
ベンダー各社の動向/戦略
を説明している。

『OpenMP並列プログラミング』
著者■菅原 清文
発行■カットシステム
価格■4,410円

『デザイニング・ウェブナビゲーション』
著者■James Kalbach
訳者■長谷川 敦士、ほか
発行■オライリー・ジャパン
価格■4,200円

『ITエンジニアの
ロジカル・シンキング・テクニック』
著者■林 浩一
発行■IDGジャパン
価格■2,300円

 本誌Vol.2〜11に掲載した連載『マジカル・
ロジカル・シンキング』
に大幅な加筆/修正を
加え、システム開発の上流工程で活動するIT

 Webサイトのユーザー・ナ
ビゲーションについて解説し
た1冊。3部から成り、第1部
ではナビゲーションの種類
を、第2部ではWebサイトの
設計手法などを説明し、第
3 部では特殊なナビゲーショ
ンのパターンを紹介してい
る。全編フルカラーで、参
考画像を豊富に掲載。

『プログラマーのジレンマ 夢と現実の狭間』
著者■Scott Rosenberg
訳者■伊豆 原弓
発行■日経BP社
価格■2,310円

 Lotus 1-2-3の開発者や初
期Mac OSの開発者など、実
績のあるプログラマーが大勢
集まって挑んだOSSプロジェク

「チャンドラー」
が迷走していく
過程を追った長編ノンフィクシ
ョン。達人プログラマーから成
るチームが、ソフト開発につき
ものの
“当たり前”
の問題に振
り回される様を描いている。

エンジニアのためのロジカル・シンキング体系と
してまとめ上げた1 冊。
「相手がどう解釈する
か」
という視点を特に重視しながら、顧客が抱
える課題を整理して改善案をまとめ、それを見
える化して提案し、合意を得るまでの中で有効
な7 つのロジカル・シンキング・テクニックを紹
介している。

上流工程を制するには、
﹁相手の解釈﹂に着目せよ

 プログラムを容易に並列
化するための API「 Open
MP」の入門書。初めにプロ
グラムの並列化が必要にな
った技術背景を説明したうえ
で、OpenMP の特徴や API
の使い方、並列化にあたっ
ての活用例、関連する並列
化支援ツールなどを詳細に
解説している。

『実践ソフトウェア要求ハンドブック』
著者■Ellen Gottesdiener
訳者■オージス総研
発行■翔泳社
価格■2,940円

 ビジネス要求からシステム
要求を正しく導き出すために
行う
「要求開発」について、
その実践に必要な知識を網
羅。要求開発の意義/特
徴を説いたうえで、実行プロ
セスを詳しく解説。併せて、
各工程で利用できる手法や
ツール、モデルを多数紹介
している。

ITアーキテクト Vol.24

book.indd 67

067

09/07/12 17:59

斎藤 剛

Vol.

23

Tsuyoshi Saito

 いよいよ激動期に入った日本の携帯電話業

働間近になっても目標品質に達せず、ここでも

界。王者NTTドコモは今年5月、ついにグーグ

修羅場を味わった」
(斎藤氏)
が、迷うことがあ

ルのモバイルOS「Android」の搭載端末を発

れば、プロジェクトの目的/背景に立ち戻って

表した。従来とは異なる水平統合モデルの上

論理的に判断していった。目標品質を無事に

で、どんなサービスを展開していくのかと注目を

確保することができ、この経験を通じて、氏は

集める同社。そのサービス基盤の開発企画を


“どうあるべきか”
の大原則を見失わず、常にそ

担う斎藤 剛氏は、多忙な毎日を送っている。

こから考えていくことが大切だ」
と実感する。

 大学院で電気通信を学び、
1992 年に旧国

 その後は、シングル・サインオン環境の構築や

際電信電話(現KDDI)
へ入社した。それから2

携帯端末管理システムの開発など、大規模プロ

年間、交換機ソフトウェアの開発を担当した後、

ジェクトを次々に主導していく。なかでも特に注目

「グローバルな場で仕事がしたい」
との思いが叶

に値するのが、今年からサービス提供を始めた

い、スイスのジュネーブで国際電気通信連合の

「ビジネスmoperaコマンドダイレクト」の基盤部

標準化部会に参加する。自社や国を代表し、

分をSOA(Service Oriented Architecture)

会議で丁々発止しながら落としどころを探ってい

で構築したプロジェクトだ。このサービスは、顧

く日々は、斎藤氏にとって初めての
“修羅場”
とな

客企業のシステムとドコモのサービス基盤をオー

ったが、ここでコミュニケーションの機微を学ぶこ

プンAPIで連携させ、端末を遠隔制御するとい

とができたという。こうした経験が評価され、
1996

うもの。
「新しい技術を使いながら、効率的なサ

NTTドコモ サービスプラットフォーム部
サービスプラットフォーム開発企画担当 担当課長

年に帰国すると、再び担当した交換機ソフトウェ

ービス基盤を作り上げる」
という自身の役割を十

アの開発で中心的な役割を任される。
「交換

分に果たしたプロジェクトだと言える。
SOAの適

機族」
としての将来は、ほぼ約束されていた。

用例としても珍しく、
ドコモがSOAに本格的に取

 ところが、対戦オンライン・ゲームのネットワーク

り組み始める嚆矢となった。

構築に携わったのを機に、
「ユーザーの存在を

 斎藤氏は現在、サービス基盤全般の開発

より身近に感じられるデータ通信の世界」に徐々

企画を担当する。その中には当然、
Android 端

に惹かれていく。また、2000 年前後の当時は、

末用のものも含まれており、昨今の携帯電話業

「横を見たら、
iモードが華々しく花開いていた」

界の変化に伴って転機が訪れたドコモにおいて

(斎藤氏)
という時期。交換機からデータ通信、

重要な役割を担っている。氏は自身の立場につ

固定電話からモバイルへの転身を決意した斎

いて、
「交換機族から転身し、またiモード・サー

藤氏は、
2001年にドコモへの転職を果たす。

ビスの保守などドコモの本流も歩いてこなかった

 同社で初の大仕事となったのが、リモート・ア

自分は、社内で
“火星人”
のような存在だ」
と自

クセス・システムの開発だ。構想段階ではビジネ

嘲するが、現在のような激動期には、氏のように

ス企画から技術選定までを行い、プロジェクトが

変化を積極的に受け入れられる人材こそが求め

始まるとマネジャーとして開発を引っ張った。
「稼

られるのかもしない。

坂口 正憲

Masanori Sakaguchi

KOYO代表

P e r s o n a l

068

履歴書.indd 68

H i s t o r y

o f

T o p

A r c h i t e c t

IT アーキテクト Vol.24

09/07/12 17:41

進んで変化を求め、
激動の時代を
乗り切る

1967年
1992年

1994年
1999年

2001年

2004年

2007年

2009年

東京都生まれ
旧国際電信電話
(現 KDDI)
に入社。
国際中継交換機向けソフトウェアの
開発/保守に従事する
スイスのジュネーブで、国際電気通信
連合の国際標準化活動に参加
対戦オンライン・ゲームのネットワーク
やBSデジタル双方向通信システムな
どの構築を担当する
NTTドコモに入社。音楽配信システ
ムや企業向けリモート・アクセス・シス
テムなどの開発に携わる
Web 向けシングル・サインオン環境の
システム基盤や認証連携基盤の構築
を担う
グループ企業向け携帯端末管理シス
テムの追加開発で、
SOAの導入を企
画/推進する
現在は、自社を取り巻く状況の変化
に対応すべく、サービス基盤全般の
開発企画を担当する

趣味◎読書、ピアノの演奏、自宅菜園での野菜作り

IT アーキテクト Vol.03写真:小林
0 6直樹
9

履歴書.indd 69

09/07/12 17:41

身近になったマラソン

ン大会の中でも別格である※6。筆者の周

ルマラソンに挑むなどというのは無謀であ

りでも、東京マラソンに出てみようかとラ

るが、
「適度な負荷で日常的にスポーツ

 まだ今年で3回目の開催である東京マ

ンニングを始める人が多い。制限時間が

をすることは、健康に良い」
というのは定

ラソンだが、マスコミの取り上げ方が大き

7 時間と長いため、少しトレーニングすれ

説である。しかし、上述のような医師の

いため、習慣的にランニングをしていない

ば容易に完走できる

発言もあるので、忙しい ITエンジニアが

“一般人”
からの注目度も高い大会となっ

※7

ので、タレントなど

が完走する姿に触発され、自分にもでき

無理して時間を作ってでも体を動かしたほ

ている。その一例をご紹介しよう。

ると考える人が多いのだろう。第 1 回の

うがよいのかどうか、スポーツと健康の関

 筆者の元同僚(当然、IT 業界の人間

東京マラソンが開催された2007 年以降、

係を確認しておこう。

である)
のランナーは、筆者と同じく今年

東京の街中でランナーを見かける頻度は

 表 1に示すのは、中年ランナーと運動

明らかに増えた。オフィス・ワーカー・ラン

習慣のない一般人の血中脂質とリポた

1月に開催された勝田全国マラソン

※1

エントリーしていた。だが、参画中のプロ

ナーのメッカである皇居周回コース※ 8 は、 んぱく質の濃度を調査した結果である。

ジェクトがとても忙しく、連日終電帰り、休

曜日/時間帯によっては混雑がひどく、 ランナーは、
トレーニング量に応じて3 つ
思うように走れないことがあるほどだ。

のグループに分けてある。グループⅢは

 そんな中、TV 番組で、ある医師が「忙

走行距離 100km/週ということで、市

彼はほぼ徹夜明けの状態で大会に臨ん

しいビジネスマンは、昼休みに無理して

民ランナーとしてはほぼ上限のトレーニン

でいた 。それが、1カ月半後の東京マラ

排気ガスまみれになって走るより、休養し

「VO2max」
とは、
グ量だ※ 10。ちなみに、

ソンでは、忙しい状況は変わっていない

たほうが健康のためだ」
といったコメントを

酸素をどれだけ取り込むことができるかを

のに、プロジェクト・メンバーがいろいろと

していた。これは健康指向ランナーに冷

表す指標で、数値が高いほど心肺能力

気を遣ってくれて、大会前日の土曜日ま

や水を浴びせる発言だとも言える 。

※4

※9

で休むことができ、さらに皆で応援に行く
とまで言われたという※5。

スポーツは健康に悪い?

 このように、周囲の理解/注目度にお
いて、東京マラソンは数ある市民マラソ

 十分なトレーニングもせず、いきなりフ

今年3月に開催された「東京マラソン2009」において、タレントの
松村 邦洋氏が倒れ、一時心肺停止状態になったというニュースは、
昨今のランニング・ブームで急増したにわかランナーの身をすくませた。
元来、マラソンはスポーツの中でも危険度の高いものである。
大したトレーニングもせずにレース当日の興奮状態に飲まれ、
自己の限界を超えた走りをすれば、身体に異常を来すのは当然だ。
だからと言って、
「下手に運動なんかしないほうが健康のためだ」

日ごろの運動不足の言い訳にされても釈然としない。
今回は、スポーツの危険性や健康への影響を
統計的なデータを基に検証してみたい。

笠原 規男

Norio kasahara

豆蔵 主幹コンサルタント

Vol.22

スポーツは体に
良いのか、
悪いのか

日も出勤という日々だった 。大会当日だ
け休みをとる※ 3 のにも苦労するありさまで、

※2

イラスト:花くまゆうさく

※ 4 睡眠不足でフルマラソンを走るの ※ 6 筆者は2007 年に開催された第 1 ※ 7 一般に、人間が歩く早さは時速
は非常に危険だ。読者は絶対にマネしな 回大会に参加したが、普段ほとんど話をし 5km 弱だとされているが、それより少し速
いでほしい。彼は自分の体調を冷静に判 ないような同僚も含め、何人もの人から い時速 6km 強の早歩きでも制限時間内
断できる分別があるから、筆者も出場を強 「東京マラソンに出たんですって、すごい に完走することができる。胸を張って完
と話しかけられて驚いた。同じ年に “走”
く止めはしなかった。ただし、不調を感じた ですね」
したと言うには、
5時間以内を目指して
らすぐにリタイヤするように何度も念を押し トライアスロンの大会「アイアンマン・ジャ ほしいものだ。
にも出場し、完走したのだが、こちら
“勇気”
を持たないランナ パン」
※ 2 申し込み時点では、大会前に忙殺 た。リタイヤする
に関してはまったく何の反応もなかった。
状態に陥ることは予測できなかったという。 ーは、とても危険である。
スイム 3 . 8 k m 、自転 車 1 8 0 k m 、ラン ※ 8 皇居の周りを周回するコースは、1
42.195kmとトライアスロンのほうが過酷 周 5km 弱と手ごろな距離で、近くにオフィ
※ 3 日曜日なのだから、
「休みをとる」
と ※ 5 応援は丁重にお断りしたとのことだ で、ラン・パートだけでもフルマラソンの距 ス街が多いこともあり、昼休みや就業後
離を走っているのに、その認知度の低さ にランニングする人がとても多い。ロッカ
った。
いうのも変だが。
を少し残念に思ったものである。
ー兼シャワー・ルーム代わりに周辺の銭湯

※ 1 茨城県ひたちなか市で毎年開催さ
れるマラソン大会。今年で57 回目を迎え
た歴史ある大会で、毎回 1 万人以上のラ
ンナーが参加する。

070

勝手に.indd 70

IT アーキテクト Vol.24

09/07/12 15:50

が高いことになる。

つの調査結果を基に考察しているだけな

況は、農業/水産業の生産性が向上し、

 総コレステロールとLDL-コレステロール

ので、これだけで結論を出すのは早計で

食料が豊富に生産されるようになったこ

(悪玉コレステロール)
には、グループ間

ある。とは言え、少なくともこの範囲では

こ100年程度のことだろう。

での有意な差はない。HDL-コレステロー

「スポーツが健康に良いとは言えない」

 人類は、長い年月をかけて食糧不足


(善玉コレステロール)
は、運動習慣の

いうことになる。もちろん、
「スポーツは健

への耐性を得たが、食糧飽和に対する

ないやや太り気味の人に比べて、やせ

康に有害である」
という結論にもならない。

耐性はない。そのため、血糖値が高い

気味の人やランナーは有意に高い。また、 ただし、過度の負荷がかかる運動は、生

状態が続くと簡単に糖尿病になってしま

トリグリセリド
(中性脂肪)
は、運動習慣の

活習慣病のリスク軽減にはならず、むし

うなど、肥満を要因とする病気は非常に

ないやや太り気味の人に比べて、やせ

ろ心肺停止といった突然死のリスクが高

多いのである。

気味の人やランナーは有意に低い。

くなるので、やめたほうがよいと言えるだろ

 太っている人が生活習慣病のリスクを

 ここから読み取れるのは、運動習慣の

う。

軽減したければ、運動しなくても、ダイエッ

ないやや太り気味の人は、生活習慣病
になるリスクが高いということである。一

ト※11して減量すればよいことになる。しか

結局、健康に悪いのは肥満

方、運動習慣のないやせ気味の人とラ

し、食事制限だけでやせるのは難しい。
ビタミンやミネラルといった体に必要な栄
養素の摂取量は減らさず、摂取カロリー

り、生活習慣病になるリスクと運動量に

っているのは健康に悪い
(生活習慣病に

だけを落とすのはさらに困難だ。減量する

は関係がないということだ。

なるリスクが高い)
ということがわかった。 ための手段としては、やはり運動が有効

 ここでは、生活習慣病になるリスクを1

 歴史的に、人間をはじめとする多くの

なのである。事実、表 1でもランナーの

生物にとって、生命を脅かす最大の要因

BMI ※ 12 値は、標準値である22より低い

Analyzing

勝手に

 運動しているかどうかにかかわらず、太

は飢餓である。これをしのぐべく、生物は

結果となっている。恐らく、
トレーニング量

進化の過程で十分な食料がない中でも

が増えるほどBMI値が低くなることが推測

生き延びる耐性を獲得してきた。一般人

される※ 13。直接的に健康に結び付かな

が少なくない割合で肥満であるという状

いとしても、運動することで肥満が解消さ

the
architecture
freely

アーキテクチャ分析

ンナーとの間に、有意な差はない。つま

を利用する人が多く、洗い場は空いてい
るのにロッカーは満杯という珍現象も起き
ている。

表1:中年一般男性とランナーの血中脂質/リポたんぱくプロフィール
(出典:樋口 満
『成人病・生活習慣病の予防のための身体活動の有用性と限界』

トレーニング VO2
max
BMI
人数
距離

(㎏ /㎡) (㎞/週) (ml/
㎏ /分) (㎎ /dl)

コレステロール
LDL(㎎ /dl)

HDL(㎎ /dl)

トリグリ
セリド

一般人
やや太り気味
やせ気味

12
12

24.5
20.5

̶
̶

39
44

205±23
196±33

133±27
119±22

46±8
63±13

131±37
69±22

ランナー
グループⅠ
グループⅡ
グループⅢ

12
22
14

22
21
20

30
60
100

56
58
62

203±24
200±25
206±30

111±18
110±24
114±27

76±15
76±13
77±11

79±26
70±17
75±33

※ 10 フルマラソンで3 時間を切るラン というのは間違った用法だ。
ナー
(「サブスリー」
と呼ばれ、羨望のまな
ざしを向けられる)
はわずか3%程度しかい
ないが、サブスリーを獲得するためのトレー ※12 「Body Mass Index」の略。体重
ニング量の目安は月間 300kmと言われて (kg)
÷身長(m)2 で求められる。標準体
いる。ちなみに、実業団ランナー・クラス 重の人のBMI値は22である。
では、月間1,000kmを超えるという。

※ 9 筆者は競技スポーツとしてランニン
グやトライアスロンを楽しんでいる。健康
増進のためではないので、大会が近くな
れば「健康に良い」
というレベルを超えて
“追い込み系”
の負荷の高いトレーニングを ※11 第8回
(ITアーキテクト Vol.10に
することがある。そのため、健康志向ラン 掲載)
でも述べたが、ダイエットとは本来
ナーには非同調的なのだが、この医師の 「食事制限」
という意味である。したがっ
発言は面白くない。
て、運動してやせようとすることをダイエット

※ 13 有意差はないので、あくまでも推
測である。

IT アーキテクト Vol.24

勝手に.indd 71

071

09/07/12 15:50

れ、間接的には健康増進に寄与するこ

減量)
には、スポーツよりもウォーキング

スポーツによる肥満解消効果が健康な

とになる。

が良いということになる。

生活に貢献する度合いは高いはずだ。

 表 3は突然死以外のもの含め、40 歳

突然死の危険性

∼44 歳の日本人の死因のうち上位 5 つ

危険なスポーツ

を挙げたものだ※16。スポーツは突然死の
 生活習慣病の予防という長い目で見

リスクが高いが、スポーツによる減量効

 もちろん、だれもスポーツで死にたくは

た健康への影響(効果)
は以上のとおり

果で生活習慣病を抑制できれば、3 位の

ない。危険なスポーツは何かを知りたくな

だが、今度は逆に、スポーツをしている

心疾患と5 位の脳血管疾患による死者

るのが人情だろう。表4に、スポーツ種目

最中に突然死するリスクがどの程度なの

は減少するだろう。また、スポーツによっ

別の危険率を示す。これは、1984 年か

かを見てみよう。

て仲間ができ、励ましたり、助言してくれ

ら1988 年の5 年間にスポーツ中に急死

 表 2は、東京都監察医務院が調査し

たり、金銭面/労働面のサポートをしてく

し、警察に届け出のあった事例を集計し

た、健康だと思われていた40 歳∼59 歳

れたりすれば、
2位の自殺をいくらか減らす

たものだ※18。こちらも、筆者の属する40

の 216 人の死因の集計である。危険率

ことも期待できるはずだ※17。

歳∼59歳のデータだけを抜粋してみた。

とは、
「1時間当該作業をしたときに、1億

 スポーツ中の心停止による突然死も

 登山は、心停止のような疾患によるも

人当たり何人の死者が出るか」
という確

恐らく、
「心疾患」に分類されるので、ス

のだけでなく、滑落などによる外傷に起

率だ

ポーツが原因の死亡事故と、スポーツに

因する死亡もあるので、危険度が高いの

 睡眠中の死亡者が最多であるが、1日

よる死亡リスクの軽減効果を数値で比較

は納得がいく。スキーも同様だ。それ以

のおよそ4分の1は寝ているのだから、絶

することはできない。しかし、スポーツ中

外のスポーツは、動きが激しく、心拍数

対数が多くなるのは当然だろう。ただし、 に倒れて亡くなったという話はあまり聞か

が上がりやすいものほど危険度が高い傾

※14

危険率は高くない

※ 15

。また、スポーツは

 「危険なスポーツ」
と言われるとボクシ

日本人全員が 1 時間スポーツをすると、4

く話である。ごくまれに突然死が発生する

ングなどの格闘技が思い浮かぶが、競技

人強が亡くなる計算だ。健康のため
(の

ものの、その危険性に比べればはるかに、 人口が少ないためだろうか、筆者が探し

表2:日常生活における突然死の危険率
(出典:村山
正博氏『心臓性急死の実態と機序』)

表3:死因別死亡数/死亡率
(出典:厚生労働省『平
成18年 人口動態統計月報年計』)

死亡者数

危険率

睡眠

71

0.8

食事

表4:スポーツ種目別の突然死の危険率
(出典:村山
正博氏『心臓性急死の実態と機序』)

死亡者数

死亡率

種目

死亡者数

危険率

悪性新生物

2,834

36.2

ゴルフ

41

6.5

2

自殺

2,238

28.6

ランニング

33

11.3

飲酒

7

心疾患

1,204

15.4

登山

11

20.5

排便

5

不慮の事故

808

10.3

水泳

14

6.8

家事/支度

5

脳血管疾患

803

10.3

テニス

8

3.4

入浴

10

スキー

12

21.0

談話

3

野球

10

13.0

性行為

4

卓球

6

8.0

精神活動

2

剣道

6

28.7

スポーツ

7

作業労働

26

歩行/階段昇降

6

乗車

8

その他

36

不詳

11

休息/休憩

13

2.4
1.6

4.1
0.6

0.2

※16 「悪性新生物」
とは、体内からエイ
リアンでも出てきそうな響きだが、これは癌
のことである。

勝手に.indd 72

向にあるようだ※19。

歩行/階段昇降の約 7 倍危険だとある。 ど生活習慣病による死亡は非常によく聞

※ 14 危険率が空欄の項目は、一般人
がその作業をどの程度の時間行うのかに
ついての統計データがないために、算出
できないものと思われる。
※ 15 睡眠よりも歩行/階段昇降のほ
うが危険率が低いというのは意外だが。

072

ないのに対し、くも膜下出血や脳梗塞な

※ 17 筆者のトライアスロン仲間で、42 を見つけることができなかった。
歳で癌になってしまった人がいる。彼は現
在も闘病生活を送っているが、チーム・メ
イトが引きも切らさずお見舞いに行ってい ※ 19 ランニングが中程度の危険という
る。彼が自殺を考えることはないと思うが、 のは妥当だと感じる。
スポーツで知り合った仲間が心の支えとな
って困難に立ち向かっているという例の 1
つだ。
※ 18 20 年以上前の古い統計で恐縮
だが、筆者の調べた限りでは、これより新
しいスポーツ種目別の危険率を示す資料

IT アーキテクト Vol.24

09/07/12 15:50

みに、財団法人スポーツ安全協会の「ス

取りとめたが、やはりスポーツ大会で死

かけて米国で行われた複数のマラソン大

ポーツ安全保険」の加入区分 ※ 20 では、

亡者が出ることはある。筆者がこれまで

会のデータを集計しており、参加者は延

に参加した大会でも、2006 年に開催さ

べ 329 万 2,268 人、レースの開催は

れた
「佐渡国際トライアスロン」
では、スイ

750日、約 1,400 万時間となっている。

●山岳登攀

ムのスタート直後に心停止で亡くなった

大会中の突然死は26 人
(参加者 10 万

●アメリカン・フットボール

方がいた※ 22。筆者のトライアスロン仲間

人当たり0.8人)
いたが、マラソン大会開

●リュージュ

である医師 ※ 23 は、マラソン大会に参加

催に伴う周辺道路の閉鎖によって、計

●ボブスレー

中、近くで倒れた選手がいたために競技

算上46件の自動車事故死が避けられた

●スケルトン

を中止し、必死で心臓マッサージを行っ

ことになるという。ランナー26人の命と引

●スカイ・ダイビング

たが、蘇生は叶わなかったという。

き換えに、交通事故者が46人以上減少

●航空機(グライダー、および飛行船を

 日常行う適度な負荷のスポーツは健

したということだ。相対的に、死亡事故

「危険度の高いスポーツ活動」
として以
下のスポーツが挙げられている

※21

除く)
の操縦

康増進に役立ち、社会保障の負担とい

のリスクを35%減少させたことになる。

●超軽量動力機の搭乗

う側面からも社会に貢献するかもしれな

 マラソン競技中の突然死の危険性は、

●ハングライダーの搭乗

いが、
「ともすれば限界を超えて死亡事

自動車で交通事故死する危険性の約

●ジャイロ・プレーン搭乗

故が起こりかねない競技大会など、開催

55%という計算なので、休日の過ごし方

●その他、これらに類するスポーツ活動

すべきではない」
という意見もある

として、クルマで買い物に出かけるよりは、

日常生活とスポーツ、
どっちが危険?
 前書きで触れた松村氏の場合は、
AED
(Automated External Defibrillator:自

※ 24

。し

かし、国外のデータではあるが、カナダの

マラソン大会に参加するほうが安全だと

トロント大学の調査結果(http://www.

いうことだ。

bmj.com/cgi/content/abstract/3

 スポーツにはそれなりのリスクもあるが、

35/7633/1275)
では、マラソン大会

日常生活に比べて特別、危険度が高い

の開催は交通事故を抑制し、死亡率を

というわけではない。読者諸氏も心配せ

低減すると報告されている。

ず、スポーツを楽しんでいただきたい。

Vol.22

スポーツは体に良いのか、悪いのか

 この報告では1975 年から2004 年に

アーキテクチャ分析

動体外式除細動機)
のおかげで一命を

勝手に

た限り、危険度のデータはなかった。ちな

今回は、スポーツの肉体的影響/身体的な危険度に注目したが、
スポーツはそのほか、
「楽しい」、
「スッキリする」、
「ストレス解消になる」
といったように、精神面でも大きな効果をもたらす。
特に、大会などで自己ベストを更新したときの高揚感/充実感は
ほかに代え難いものだ。球技のような対戦型スポーツをする人も、
ライバルに勝ったときの喜びは同様であろう。
筆者は、たとえスポーツが健康に有害だったとしてもやり続けるだろう。
ここ3週間ほど、仕事が忙しくて満足に走っていないし、
プールにも一度も行っていないので、精神衛生上の臨界点が近い。
明日は睡眠時間を削ってでも、早朝ランニングに行こうと思う。

※ 20 同じ掛け金でも、危険度が高い
スポーツの「加入区分」は支払われる保
険料が少なくなる。

る。いずれも、スイム
(3 種目実施されるう
ち、最初の種目)
での事故だ。

※ 23 直腸/肛門専門の名外科医で
※ 21 極めて競技人口が少ないと思わ ある。
れる、雪上のスポーツや飛行系のスポー
ツが多く挙げられているのが特徴的だ。
過去に、多くの保険料を支払った実績が ※ 24 地方自治体が主催する大会では
あるのだろうか。
特に反対の声が大きい。しょせん、物好
きな人間の遊びであり、死亡事故など起
こして迷惑をかけるなということなのだろう。
※ 22 国内のトライアスロン28 年の歴
史の中で、5 件の死亡事故が発生してい
IT アーキテクト Vol.24

勝手に.indd 73

073

09/07/12 15:50

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

l

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

開米 瑞浩

モデリングによる
情報分析の勘どころをつかむ

アイデアクラフト代表

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

f

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Mizuhiro Kaimai

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Vol.23

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

“統合パッケージ”ばかりでは
問題解決の発想は生まれない

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Q

 次のような状況において、
あなたはどうやって自分の胸囲を測ればよいか?
精度は±2cm程度でよいので、
手元にメジャーがない状況で胸囲を測る手段を考えよ。

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

が所属する
。用件は、2 人






電話が
の元に友人から
 あるとき、K 氏
る話だった。
ニフォームを作




れたかい?」


スポーツ
測っておいてく






の件だ
「ユニフォーム
友人:
んだから。
!」
ギリのサイズな


「あ、忘れてた


K氏:


るか
の分は特注にな
「困るよ、お前
友人:
えてよ」
今すぐ測って教

すぐ測るよ」
は何1つ見当た
「オッケー、今
るための道具」

K氏:





屋に
屋に
なお、K 氏の部
のの、K氏の部
いのだろうか。
 とは言ったも






る。
はどうやって胸
はあるものとす
ない。さて、K 氏
続ができるPC







品や、イ
は一般的な日用

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

074

IT アーキテクト Vol.24

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

頭の体操.indd 74

09/07/12 13:04

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

A

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

 今回の出題は、連載タイ

自身で新規事業を企画するタイプで、そ

「近くのお店に走る」
とか、
「隣の住人に

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

トルどおりの
“アタマの体操”

れまでに新しいビジネスをいくつも成功さ

借りる」
とかいったように、メジャーそのも

に寄せたものであり、ITには

せていた。そのうちの1つでは、筆者自身

のを調達するタイプの解答は除外する。

あまり関係がない。まず、こ

もスタッフとして働いていたことがあり、彼

あくまでも、手持ちの道具を組み合わせ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

の「有り合わせの道具で何とかする精神
の題材を選んだ理由を説明
て胸囲を測る方法を考えていただきたい。
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

が大切だ」
という言葉には説得力があっ

しておこう。

 図 1は、
「胸囲を測る」
という目的の達

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

 出題文に出てくるK氏というのは、何を

た。

成に必要になるものの機能を細かく分解

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

隠そう筆者のことである。実はこの話、

 しかし、ここでわざわざそんな言葉が出

(分析)
した結果である。このように分解

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

してあるが、
ほぼ実話だ。実際
する
「一定の長さの単位」
が「規則正
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■多少脚色
■ ■ ■ ■ ■ ■
■ ■ ■ ■ ■ ■ ■
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ てきたのは、
■ ■ ■ ■ ■ ■ ■ ■実は彼は
■ ■ ■ ■ ■「有り合わせの道
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
■ ■と、
■ ■
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

には「今すぐ教えて」
とは言われなかった

具で何とかするのは、意外と難しい」
と考

しく連結」
されており、
「柔軟に曲がる」

が、時間をかけるようなことでもないので

えていたということだ。ITに限らず、
「アー

のがあれば、
「胸囲を測る」
という目的に

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

キテクト」
とは
「仕組みを構想する人」
であ
有り合わせの道具で胸囲を測ってその場
使えることがわかる。言うまでもなく、メジ
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

で返事をした。すると友人は、筆者にこう

る。既存のものも活用しながら新しい仕

ャーはこの 3 つの機能をまとめてパッケー

言ったのである。

組みを考え、それがうまく働くように設計

ジ化したものだ。しかし、何も単体で3 つ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

 「そうそう、有り合わせの道具で何とか

するのがアーキテクトの役割だ。その活

の機能を持たなくても、それらの機能を持

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

しちゃう精神が大事だよ。新しい仕事を

動の中では、
「有り合わせの道具を組み

つ物を何らかの手段で連携させれば目的

始めるときは特にそうだね。起業家はそう

合わせて、新しい道具を作って使う」
とい

を達成できる。

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

でなきゃいけない」

う状況が頻繁に発生する。今回の出題

 実際に筆者はどうしたかと言うと、裁縫

 友人はもともとSIerでプロジェクト・マネ

は、そうした状況を身近な題材で設問化

用の糸を胸囲に巻いてから、それをA4

ジャーを務めたことのある人物で、当時は

したものなのだ。

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

(210mm×297mm)の紙の長辺(約

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

ベンチャー企業の支援に携わっていた。

30cm)
に合わせて何往復かさせた。糸

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

ちょうどそのころ、筆者は独立して今の事

目的を機能に分解する発想

は、柔軟に曲がるものである。糸がなけ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

業を始めようとしていたので、そんな言葉
れば、電源コードなど、代用できる物はい
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

が出てきたのだ。

 それでは、答えを考えてみよう。なお、

くらでもあるだろう。また、A4の紙のような

 ベンチャー企業の支援と言っても、さま

出題の意図は
「有り合わせの道具を組み

規格品は、長さの単位の基準になる。

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

ざまなやり方があるが、彼の場合は自分
合わせて使う」
というところにあるので、 A4 の紙でなくても、すでにサイズがわか
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

図1:胸囲を測るために必要な機能

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

目的

そのために必要な機能

機能の統合パッケージ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

一定の長さの単位が

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

胸囲を測ること

規則正しく
繰り返し連結されていて

メジャー

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

柔軟に曲がる物

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

「目的」
に対して
「使用可能な統合パッケージ」
だけを覚えようとしていると、
新企画の構想や問題解決はできない。
したがって、
「目的」
を必要な
「機能

に分解してからそれを統合するという視野/視点を持っておきたい。

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

IT アーキテクト Vol.24

075

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

頭の体操.indd 75

09/07/12 13:04

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

っている物があればそれを使えばよい。

この問題にかかわるものだったりする。も

ていない。これでは、例えば「メジャーが

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

「A4 の紙はあるが、サイズがわからない」

ちろん、これは大変良くない傾向だ。答え

ない」
というように統合パッケージに当た

という場合は、インターネットで調べれば

というのは自分で見つけるべきものであっ

るものがなくなった途端、手も足も出なく

よいだけだ。

て、教えてもらうものではない。

なる。要するに、
トラブルに極端に弱くな

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

 いずれにしても難しい話ではないので、
 ところが、筆者が「読解力/図解力」 ってしまうわけだ。
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

おそらくこの問題は簡単だっただろう。だ

に関する企業研修を行っていると、受講

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

が、これが現実のビジネスの話になると、

生からは、
「読み取った内容が正しいかど

結局は受験勉強の
弊害なのか?

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

有り合わせの道具を組み合わせて問題を

うかを判断する基準を教えてください」

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

こ■とのでき
か、
う■すれば良い文書を書ける』
とい
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 解決する
■ ■ ■ ■ ■ ■
■ ■ ■ ■ ない人が多いのだ。
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
■ 「
■ 『こ
■ ■ ■
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

う正しいプロセスを教えてください」
などと

 先に、正解を教えてもらいたがる
“正解

いう質問が頻繁に寄せられる。いずれも

教えて君”
の存在は、最近の企業の人

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

正解を教えてもらいたがる
人々

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

材育成における共通の悩みだと書いた
特徴的なのは、
「正しさ」の基準を自分で
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

決めようとしていないところだ。

が、本当に最近だけのことなのかと言う

 筆者がそうした質問にざっくばらんに答

と、実はそうとも言い切れない。実際、筆

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

 つい最近、研修内容についての打ち

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

合わせをするために、筆者がある企業を

えるとすれば、
「正しいかどうかなんて自分

者がこの問題に最初に気づいたのは中

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

訪問したときのことである。人事部の人

で決めるしかないよ。いいじゃないか、や

学/高校時代、今から25年以上も前の

から、
「最近入ってくる新卒の学生は、や

ってみてダメなら直せばよいのだから」

ことだ。同級生と学校祭の準備をしてい

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

たらと正解ばかりを求める傾向が強くて

言うだろう。しかし、それでは納得しない

るときに、ちょっとしたトラブルですぐに思

……」
という悩みを聞いた。読者の中に

人が案外多いのだ。

考停止を起こす人がいて、不思議に思

も、同じように感じている方がおられるだ

 そんな
“正解教えて君”
たちが知りたが

ったのである。これはあくまでも筆者の体

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

ろう。試しに、Webで
「正解を求める」
とい

るのは、図1で言うと
「統合パッケージ」

験の1つなので、当時の社会の傾向とし

う言葉を検索してみると、同様の悩みを

あり、
「機能」の部分にはあまり興味を示

てどうだったのかまではわからないが、少

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

“正解教えて君”
が存在し
訴える声が多数見つかる。これは、人材
さない。
「こういうときにはこうすればよい」 なからずそうした
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

育成にかかわる者にとっては共通の問題

という、目的に対する特定の解法を
「覚え

ていたことは確かだ。

意識だと言ってよい。実際、筆者のとこ

て使おう」
とする傾向が強く、
「なぜ、それ

 さらにそれが、
「最近、増えているので

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

はないか」
と思われる理由はいくつかある。
ろに寄せられる質問の 3 分の 1くらいは、 で解決できるのか?」
と考える習慣を持っ
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

図2:目的/機能展開ワークの実施例

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

目的

そのために必要な機能

機能の
統合パッケージ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

音声を機械的振動に変える

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

マイク

音声を電気信号に変える

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

機械的振動を電気的振動
(電気信号)
に変える

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

電気信号を長距離搬送する

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

遠方と会話する

電気信号を遠方まで伝える

コード、
アンプ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

減衰した電気信号を増幅する

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

電気信号を機械的振動に変える

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

電気信号を音声に変える

スピーカ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

機械的振動を音声に変える

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

076

IT アーキテクト Vol.24

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

頭の体操.indd 76

09/07/12 13:04

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

先述したような企業の人事担当者から聞

目的/機能展開ワークを
してみよう

い。

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

く新入社員の評価はその1つだが、もう1

 また、この目的/機能展開ワークを実

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

つ、受験勉強テクニックの傾向などから

施する際には、
「目的」

「機能」の部分

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

も見てとれる。以前、筆者は学校教育の

を自分の言葉で書くようにするとよい。図

 現代ではさまざまな分野で
「統合パッケ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

問題に興味を持ち、
「算数」に関して少
3は、通信のOSI 7階層モデルを5階層
ージ」
が充実しており、それらの多くは機
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

し調べてみた。すると、
「こういう問題が

にまとめ、さらに「機能」の表現を自分の

能を自覚しなくても使えてしまう
(問題が

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

出たらこういう解法」
というノリの「よく出

言葉で言いかえて専門用語を減らした例

解決できてしまう)
。そのため、
「機能を分

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

題されるパターンの問題を簡単に解く方

だ。すでに自分が知っている
(と思ってい

解して自覚できない」
という人が増えてい

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

る)
知識で
改めて自分の言葉で書こ
それが問題であるな
らば、
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■法」
■ ■ を指導する形式の指導法が相当に
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ る。
■ ■ ■
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
■ ■ ■ 機能を自覚
■ ■ ■ ■ ■ ■ ■ ■ ■ ■
■ ■
■ ■ ■ も、
■ ■ ■
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■う
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

広まっていることがわかった。詳細は割

できるよう訓練すればよいのだ。これを筆

とすると意外に迷いが出てくるものだ。言

愛するが、それらの解法と、実際に指導

者は、
「目的/機能展開ワーク」
と呼ん

いかえるには、その対象をよく知っている

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

している様子を見たとき、筆者は「ああ、 でいる。
必要がある。したがって、言いかえがうま
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

こりゃ統合パッケージだな」
と思ったので

 例として、
「遠方と会話する」
という目

くできなければ、
「ああ、ここはよくわかっ

ある。

的を展開し、機能に分解したのが図 2で

ていなかったんだな」
と気づけるわけだ。

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

 特定の目的
(問題)
を簡単に達成できる

 筆者は、2日間程度の企業研修を行う

ある。図2では、機能を2階層に分け、ツ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

(解ける)
統合パッケージは、一見便利そ

リー上に細分化しているが、必ずしもこの

際には、目的/展開ワークに似た練習

うに見えるが、その背景にある機能の 1

とおりになる必要はない。重要なのは、

問題を取り入れることが多いのだが、受

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

つ 1 つを理解していないと、少しでもパタ

このような展開図を自分で書くことである。

講生にはおおむね好評である。普段は

ーンが崩れた途端に応用不能になってし

先生が書いてくれたお手本を丸写しして

人に説明するのが苦手だというコミュニ

まう。こうした指導法がはびこると、
「答え

暗記しても、何の意味もないのだ。

ケーション下手な人でも、いったんこのよ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

は出せても問題の意味を理解していな

 出来上がった図を眺めていると簡単そ

うな展開をしておくと楽に話ができるよう

い」
という子どもが増える。そして、そうい

うに見えても、実際にやってみると、知識

になる。それは、書いている間に複雑な

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

う子どもは「自分では問題の意味を理解
問題についての理解が進むからにほかな
や表現力の不足によって「書けないとこ
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

していない」
がゆえに、
「正しい答えの出

ろ」
が出てくるものである。そうした部分を

らない。社内の勉強会などでも簡単に取

し方を教えてくれ」
と求めるようになるので

自覚することが、問題についての理解を

り組める問題なので、ぜひ試してみてい

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

はないだろうか。
ただきたい。
深めることにもつながるのは言うまでもな
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

図3:
「目的」

「機能」の部分は自分の言葉で書く

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

目的と機能の表現は、教科書どおりに書き写すのではなく、
自分の言葉で言いかえる

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

目的

そのために必要な機能

機能の統合パッケージ

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

通信相手と電気的に接続する

物理層

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

中継係にデータを届ける

データ・リンク層

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

コンピュータ同士で
通信する

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

通信相手にデータを届ける

ネットワーク層

〝統合パッケージ〟ばかりでは
問題解決の発想は生まれない

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Vol.23

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

データの正確さを保つ

トランスポート層

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

データを正しく解釈する

セッション層、
プレゼンテーション層、
アプリケーション層

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

IT アーキテクト Vol.24

077

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

頭の体操.indd 77

09/07/12 13:04

iPod Shuffle
■提供:IDGジャパン
■2名様

1
 容量が4GBに増えたデジタ
ル・ミュージック・プレーヤ
「iPod Shuffle」の新モデルを
2 名様に。今聞いている曲の
名前やアーティスト名を音声
で教えてくれる新機能「Voice
Over」
を搭載しています。

ワイヤレス・マウス
■提供:IDGジャパン
■1名様

2
 ワイヤレス・マウス
「SCOPE
NODE」
(エレコム)
を1 名様
に。繊細な操作感を実現する
ため、1600dpi の高精度セン
サーを搭載。一度に長い距離
をスクロールできる口径27mm
のホイールを備えています。

家庭用プラネタリウム
■提供:IDGジャパン
■1名様

■応募方法
巻末のとじ込みアンケート・ハガキに、
第1希望/第2希望のプレゼント番号をご記入のうえ、お送りください。
■応募締め切り
2009年8月24日
(月)
消印有効
1名様1製品の当選とさせていただきます。
なお、当選者は本誌Vol.25
(2009年9月25日発売)
で発表いたします。

P resent

3
 幅約9cm、高さ11cmの家
庭用プラネタリウム「 BATH
PLANETARIUM」
を1名様に。
天文研究家の監修の下、
オリ
オン座を中心とする本格的な
星空を再現。防水仕様なので、
浴室でも楽しめます。

書籍

『ITエンジニアの
ロジカル・シンキング・テクニック』

■提供:IDGジャパン
■3名様

4
■Vol.23プレゼント当選者発表 ※敬称略
●デジタル・ペン
「MVPen」
:齊藤 武
(岩手県)
●デジタル名刺ガジェット
「Poken」
:川端 小百合
(東京都)
、望月 隆史
(長野県)
●ソーラー・バッテリー充電器:野池 拓郎
(三重県)
、佐々木 崇
(神奈川県)
●書籍『企業情報システムアーキテクチャ』
:野尻 伸一
(千葉県)
●書籍『キャパシティプランニング』
:松井 淳
(京都府)
、宮木 芳尚
(愛知県)
●書籍『Webサービス時代の経営情報技術』
:吉田 克彦
(京都市)

書籍

『クラウドコンピューティング
——技術動向と企業戦略』

■提供:オーム社
■1名様

5
 67 ページで紹介した書籍
『クラウドコンピューティング—
—技術動向と企業戦略』
を1
名様に。クラウド・コンピューテ
ィングの関連技術や、サービス
を展開するベンダー各社の動
向などを解説しています。

 67ページで紹介した書籍
『ITエンジニアのロジカル・シン
キング・テクニック』
を3 名 様
に。従来のロジカル・シンキン
グにITの知恵を取り入れた、7
つの思考テクニックを紹介して
います。

書籍

『プログラマーのジレンマ 夢と現実の狭間』

■提供:日経BP
■1名様

6
 67ページで紹介した書籍
『プログラマーのジレンマ 夢と
現実の狭間 』
を1名様に。著
名な開発者を多数集めて発足
したOSSプロジェクトが混迷し
ていく様子を、
さまざまなエピソ
ードとともに紹介しています。

IT アーキテクト Vol.24

Present.indd 79

079

09/07/12 18:19

インフラ構


を“
ある
べき
姿


へと近づける

特集 2

鍵は﹁標準化﹂と﹁体制の確立﹂

︱︱プライベート・クラウド構築を通した

自社インフラの最適化

080

IT アーキテクト Vol.24

023_toku2.indd 80

09/07/12 17:57

クラウド・コンピューティングは、今やIT業界全体を巻き込んで巨大なブームと化した感がある。
もっとも、企業の中には、セキュリティやサービス品質などを考慮し、
社外にあるクラウドの利用は時期尚早だと考えているところも多いだろう。
そこで最近、注目を集めているのが、企業が自社内に保持するITインフラのクラウド化、
すなわち
「プライベート・クラウド」の構築だ。
今日では、その実現に必要となる各種基盤技術の成熟も進んでいる。
ただし、それらの技術さえ導入すれば、プライベート・クラウド環境を即座に利用できるわけではない。
クラウド環境として実現するには、基盤の共通化や運用プロセス/体制の最適化など、
ガバナンス面での施策も必要となるのだ。
本特集では、プライベート・クラウドの構築に際して生じる活動や主な課題などの解説を通して、
クラウド時代におけるITインフラ・ガバナンスのあり方を提示してみたい。

小池 和雄

Kazuo Koike

NEC ITプラットフォームソリューション事業部 システムズアーキテクト

富 光弘

Mitsuhiro Tomi

NECシステムテクノロジー IT基盤事業部 ITコーディネータ

IT アーキテクト Vol.24

023_toku2.indd 81

081

09/07/12 17:57

プライベート・クラウド登場の背景

高さがネックとなり、すべての企業に広く導入されるまでに
は至らなかった。

 IT 業界では昨今、クラウド・コンピューティングが多くの

 その状況を打破したのが、ご存じオープン化だ。オープ

注目を集めている。
「 A m a z o n E C 2 」、
「 同 S 3 」、

ン化により、構築コストが下がったITシステムは一般企業に
も身近なものとなり、企業内のコンピュータの数は飛躍的

「Google App Engine」、
「Windows Azure」など、す
でにさまざまな関連サービスが提供されており、メディアでも

に増えていく。それに伴い、企業システムは多数のコン

日々話題となっている。今や一大ブームと化した感もあるが、

ピュータが協調動作する分散処理の形態へと進化して

そうした中で登場してきたのが、企業の内部にクラウド環

いった。つまり、企業システムにおける処理形態は、
「集中

境を構築する
「プライベート・クラウド」
という概念だ。本稿

化から分散化へ」
という流れで発展してきたのである。

ではまず、このプライベート・クラウドという概念が登場した

 今日では、このようなオープン化や分散化に加え、イン

背景を、企業システムの処理形態の変遷をたどりながら

ターネットの登場によるWeb化により、システムの処理形態

探ってみたい。なお、大まかな流れを図1に示すので、この

は多様化しており、その管理に要するコストが増大しつつあ

図も参照しつつ読み進めてほしい。

る。特にハードウェアについては、価格低下が進んで購入
が容易になったことで、企業が多くの機器を抱えるように
なっており、それによる管理コストの肥大化が問題となって

企業システムの処理形態は
「集中化から分散化へ」

いる。

 企業がコンピュータを使い始めた当初は、ユーザーが
利用する各端末から中央の汎用機にアクセスする集中処

クラウドにより、分散から
「持たざるコンピューティング」へ

理の形態をとるシステムがほとんどだった。その後、コン
ピュータは徐々に高速化/大型化していったが、価格の

 こうした中で新しく登場してきたのが、クラウド・コンピュー

図1:コンピュータ利用形態の変化
コスト

集中化
サービス
OS/アプリケーション
分散化
サービス
サービス
サービス
OS/アプリ OS/アプリ OS/アプリ
ケーション
ケーション
ケーション
サービス化

管理コスト

機器コスト

汎用機時代

管理コスト
管理コスト
機器コスト

機器コスト

オープン化

クラウド

時間

特集 2

082

IT アーキテクト Vol.24

023_toku2.indd 82

09/07/12 17:57

ティングという処理形態だ。現状、これについて公式かつ

われている技術の1つだ。クラウド・コンピューティングは、ビ

厳密な定義付けがなされているわけではないが、本稿で

ジネス・グリッドのようにかけ声だけで終わることなく、広く普

は次のように位置づけてみたい。

及していくことだろう。

ユーザーが、その実体を意識することなく、情報処
理サービスやアプリケーション・サービスを受けるこ
とのできるコンピュータ・システム

プライベート・クラウドという概念の登場
 今日、さまざまなクラウド・サービスの提供が始まっている
が、セキュリティや可用性を考えると、それらはまだ企業シス

 つまり、
「集中化から分散化へ」
という流れから発想を

テムで使うのに十分なレベルには達していない。

変え、ユーザーが個別に強力なコンピューティング資源を

 そうした中で浮上してきた概念が「プライベート
・クラウド」

持つのをやめるという方向性である。

である。プライベート・クラウドとは、企業が自社内/グルー

 なお、ここ数年で話題になったIT 関連のキーワードとし

プ企業間に文字どおり
“プライベート”
なクラウド環境を構

て、クラウドのほかに仮想化技術とグリッド・コンピューティ

築し、そこから自社/グループ内に向けてコンピューティン

ングがある。これら3つの技術は相互に関連しつつも、クラ

グ資源を提供するというものだ。これに対し、Amazon

ウドとそれ以外とでは切り口がかなり異なる。

EC2など、クラウド事業者が不特定多数の企業/個人に

 例えば、仮想化技術は純粋なシステム構築技術であり、

向けて提供するクラウド・サービスは「パブリック・クラウド」

グリッド・コンピューティングは多数のコンピュータをつない

と呼ばれる。

で有機的に利用するシステム、あるいはその処理形態のこ

 プライベート・クラウドという考え方が出てきた理由は、現

とだ。これらの技術は、IT 側の視点から生まれたものであ

状のパブリック・クラウドでは満たせない信頼性やセキュリ

る。それに対して、クラウドについてはユーザーの視点から

ティ、サービス品質の要求を満たすには、外部に対して閉

議論されることが多い。ユーザーがクラウドに寄せる期待
感としては、次のようなものがある。
●Webを通じて、いつでもどこでも、すぐにサービスを使える
(迅速な環境構築)

図2:プライベート・クラウドとは
柔軟性

●コンピューティング・リソースの上限を感じることがない
(高
い拡張性)

コスト・メリット

●自前で構築するよりも、初期投資を抑えられる
(低コス

クラウド・コンピューティング
(パ
ブリック・クラウド)
への期待感
●Webを通じて、
いつでもどこでも、
すぐ
にサービスを使える
(迅速な環境構築)
●コンピューティング・リソースの上限を
感じることがない
(高い拡張性)
●自前で構築するよりも、初期投資を抑
えられる
(低コスト)

ト)
 そして実際、これらの期待は、今日提供されている多く

信頼性

のクラウド・サービスですでに満たされている。仮想化技術
も、上記の期待に応えるべくクラウド・サービスの実現で使

セキュリティ

【企業システムとしての要件】
●高い信頼性が求められる
●セキュリティの確保が必要

プライベート・
クラウド

IT アーキテクト Vol.24

023_toku2.indd 83

083

09/07/12 17:57

じた環境にする必要があるからだろう
(前ページの図 2)。

 これらの要件に対して、その実現に必要となる技術や活

また、企業が抱える既存のインフラ環境を、クラウドの技術

動を関連づけて整理すると、図3のようになる。

を用いて改善し、柔軟性を高め、構築/運用にかかるコ

 図中に示したように、クラウド環境の実現には、仮想化

ストを削減しようとの狙いもある。

技術が必須となる。この技術により、1つのハードウェア上
で複数のOSを稼働させることが可能となり、リソースの利

プライベート・クラウドの
要件と構成要素

用効率が高まる。また、ライブ・マイグレーション※1の実施や、
仮想化ソフトの設定のみによる環境設定の変更が可能に
なり、インフラ環境の急激な変更に対応しやすくなる。

 プライベート・クラウドという概念が登場してきた背景を

 さらに、仮想化技術を使えば、複数のハードウェア・リ

理解したところで、次にプライベート・クラウドに求められる

ソースを仮想的に統合することができる。いわゆる
「リソース

要件や、その実現で鍵になる技術/活動について考えて

のプール化」だ
(図 4)。これを実施することで、システムに

みたい。

割り当てるリソースを柔軟に変更できるようになる。それに
よってハードウェアの台数を減らせれば、コスト削減にもつ

プライベート・クラウドの要件と、
それを実現する技術

ながるだろう。

 プライベート・クラウドの実現では、インフラ環境を構築

いのが、運用にかかるコストだ。このコストを下げる鍵は、各

することと、その環境の運用の仕方を決めることが中心的

システムの運用作業を統合したうえで、その手順を標準化

な取り組みとなる。その際に特に重視すべき要件が、先に

することである。また可能なら、各手順の遂行を極力自動

ユーザーの期待感として挙げた次の3つだ。

化する。

●迅速な環境構築

 なお、インフラが仮想化されることによって必要になる

●高い拡張性

 加えて、企業が抱えるインフラ周りのコストで無視できな

※ 1 あるサーバ上で実行中の仮想マシンと、その上で動作するOSより上層の
環境を、システムを停止させることなく別のサーバ上に移すこと。

●低コスト

図3:クラウド・コンピューティングの要件と対応する技術/取り組み
要件

対応する技術/取り組み
仮想化技術

迅速な環境構築

ライブ・マイグレーション

高い拡張性

ソフトウェアによる環境設定
リソース利用の効率化
ハードウェアの効率化

低コスト

リソースのプール化
個別運用の統合
運用手順の標準化

運用の効率化

特集 2

084

IT アーキテクト Vol.24

023_toku2.indd 84

09/07/12 17:57

図4:リソースのプール化

リソースを柔軟に割り当てられるようになる
プール化したリソース

アプリケーション
余剰
余剰リソースはプールに返却

余剰
追加
必要なときにすぐに追加

追加

ツールがある。1 つは仮想化の導入によって
“目で見る管

全体を把握するための「統合運用管理ツール」だ
(これら

理”
がますます難しくなるインフラの構成管理をサポートする

の詳細は後述する)。

「構成管理ツール※ 2」、もう1つは統合されたインフラ環境

プライベート・クラウドのアーキテクチャ

※2 ソース・コードのバージョン管理などを行うツールも構成管理ツールと呼ばれ
るが、ここではインフラの構成管理を行うツールを指してこの名称を用いる。

 図5に示すのは、上述の要件や技術/取り組みを踏ま

図5:プライベート・クラウドのアーキテクチャの例(ベース・アーキテクチャ)
統合運用管理ツール

アプリケーション

アプリケーション

アプリケーション

OS

OS

仮想マシン

仮想マシン

仮想マシン

仮想マシン管理

サーバ

サーバ
ネットワーク

インターネット

ストレージ

統合管理ビュー

OS

アプリケーション管理

サーバ管理
ネットワーク管理

ストレージ

ストレージ管理

システム管理
(構成管理ツール)

構成管理
データベース

IT アーキテクト Vol.24

023_toku2.indd 85

085

09/07/12 17:57

えて描いた、プライベート・クラウドのアーキテクチャの例だ。

討する必要がある。また、1つの管理パターンでインフラ利

これは、クラウド環境の大まかな構成を示した
“ベース・

用のバリエーションをすべてカバーできるわけではないので、

アーキテクチャ”
であり、実際には、これを基にして、サービ

まずはいくつかの代表的なパターンに絞り込み、さらにそれ

ス・レベルごとに具体的な
“実装アーキテクチャ”
を作ること

を標準化していくといったかたちで推進する。こうした取り

になる。ベース・アーキテクチャは、実装アーキテクチャを

組みは、次のような流れで進めるのがよいだろう。

検討する際の礎となるものだ。実装アーキテクチャの導き

●サービス・レベル標準の策定

出し方については、後ほどプライベート・クラウドの構築ス

 初めに、インフラの設計/構築において基となるユー

テップを説明する中で述べる。

ザー要件、つまりサービス・レベルを標準化する。
●構成標準の策定
 次に、サービス・レベル標準に従って、サービス・レベル

ガバナンス確保のための
標準化作業

ごとのインフラ構成を検討/策定する。クラウド環境を構築

 プライベート・クラウドの実現では、さまざまな取り組み

した後は、そこで動作するシステムのハードウェアは管理組

が必要になるが、特にガバナンス確保の観点からは「標

織が一括して調達することになるだろう。よって、製品その

準化」の活動が重要だ。具体的にどのような標準化活

ものを決めるのではなく、一括調達を意識してサーバやスト

動が生じるのか、その概要と取り組みのポイントを書いて

レージなどの種類を決めたり、要求仕様を明確化したりと

おこう。

いった程度にとどめ、製品の差し替えがあっても構成標準

 クラウド環境は、それを構築しさえすれば、自動的に効

を修正せずに済むようにしておきたい。

果が得られるというものではない。例えば、仮想化による

●調達標準の策定

サーバ統合でハードウェアの台数が減っても、管理対象と

 ここでは、RFP(Request For Proposal:提案依頼

なるOSの数が変わらなければ(増える可能性すらある)、

書)
の標準フォーマットや製品の評価基準を決めるが、併

単純には管理コストは下がらない。また、リソースをプール

せて製品を選択/決定する際のプロセスも標準化してお

化したとしても、インフラ構成のパターンが多いと、パターン

く。また、コンピューティング・リソースのモニタリング方法や

ごとに予備のコンピューティング・リソースが必要となるため、

適正な調達ロットについても、標準を検討すべきだろう。

仮想化によってサーバ台数を減らした効果が薄れてしま

●構築標準の策定

う。

 続いて、インフラの構築作業を標準化する。これについ

 そこで重要になるのが標準化だ。一例を挙げると、各シ

ては、すでに「構築手順書」などとしてドキュメント・ベース

ステムのOS環境を標準化すれば、管理パターンが絞られ、

で標準を定めている企業もあるだろう。ただし、ここで言う

運用の効率化を図れるといった具合である。

標準化とは、それよりももっと踏み込んだものだ。具体的に

 なお、標準化は、やみくもに進めても意味がない。何を

は、構成標準が策定済みで、インフラ構成がパターン化

標準化するかを、インフラ構築のライフサイクルに沿って検

されていることも踏まえて、さらにインフラ構築作業そのものの

特集 2

086

IT アーキテクト Vol.24

023_toku2.indd 86

09/07/12 17:57

自動化まで検討する。その際には、いわゆるプロビジョニン

らの作業を大きくステップ分けすると、以下のようになるだろ

グ・ツールの活用などを考えるとよい。また、インフラ構築後

う。

に生じる変更に備え、構築標準は構成変更の手順書とし

①インフラの現状調査

ても使えるようにしておきたい。なお、システム移行時の作業

②課題の整理と要件の明確化

も、ここで標準化しておく。

③アーキテクチャの策定

●運用標準の策定

④移行計画の立案

 最後に、運用作業を標準化する。運用コストは、企業

 以降、各ステップの概要と実施する活動を見ていこう。

のIT 予算において大きな割合を占めており、コスト削減の
観点からも、標準化によって運用を効率化することは非常
に重要だ。
 運用コストを削減するには、例えばシステムごとの運用を

ステップ①

インフラの現状調査

統合し、個別に実施していた作業を集約化するという方

 最初に行うのは、社内のインフラの現状を調査すること

法が考えられる。また、インフラ構成の標準化により、作業

だ。オープン化の進展によってシステムを部門ごとに導入す

そのものを簡素化できることもあるだろう。標準化の対象と

ることが増えたため、今ではシステム部門が自社内のハー

なる作業としては、バッチ処理などの日常管理やバックアッ

ドウェアの台数さえ把握していないケースが少なくない。ま

プ、リカバリーを含む障害対応、各種の設定変更などが

ずは、それらの台数をはじめ、機器ごとのスペックや稼働

挙げられる。なお、ここでもツールによる作業の自動化を検

情報(負荷状況)、購入コスト、リース時期など、インフラに

討すべきだ。

関するさまざまな情報を集めよう。
 また、インフラだけでなく、各システムの運用の仕方も調

プライベート・クラウド構築の
初期ステップ

レベルごとの運用作業の実施レベル
(例えば、バックアッ

 続いては、プライベート・クラウドの構築で特にかなめと

用状況などだ。ただし、クラウド環境では運用のあり方が

なる初期段階の作業の大まかな流れと、その中で実施す

従来と大きく変わるので、単に現状を確認するだけでなく、

る活動について説明する。

クラウド環境への移行も踏まえて、現状の運用手順/体

 プライベート・クラウドの構築は、長期的かつ広範な取

制のままで柔軟性や効率性といったクラウド環境での要件

り組みとなる。その初期段階では、まず現状のインフラを調

を満たせるかどうかも確認しておく。

査し、プライベート・クラウドによって何を解決するのか、課

 さらに、プライベート・クラウドで重要なテーマとなる標

題を明確にしなければならない。また、運用の見直しや体

準化を意識して、現状の各システムのインフラ構成を整

制の整備といったガバナンス面の作業も必要になる。それ

理し、サービス・レベル標準や構成標準の検討を開始す

べる必要がある。このときに調査すべきなのは、サービス・
プ方式や障害対応手順など)、運用体制、ツールの適

IT アーキテクト Vol.24

023_toku2.indd 87

087

09/07/12 17:57

まえて取りまとめる必要がある。

るとよい。
 そのほか、必須ではないが、コストの分析も重要になる。
経営層からプライベート・クラウドの構築について承認を得
るためには、コストに関する説明が不可欠だからだ。この
分析では、現状のコスト構造を整理してメスを入れるべき

ステップ③

アーキテクチャの策定

部分を明らかにしたり、実施を予定しているコスト削減プラ

 要件が決まったら、いよいよクラウド環境のアーキテク

ンの効果を予測したりといったことを行う。

チャを設計することになる。ここでは、まず仮想化技術の
位置づけや、サーバ/ストレージ間の対応関係などを整
理したうえで、先に触れたベース・アーキテクチャを策定

ステップ②

課題の整理と要件の明確化

する。

 インフラの現状調査が完了したら、クラウド環境に対す

キテクチャへと落とし込むには、システムに求められる要件、

る要件を固める。この要件を検討するにあたっては、まず

つまりサービス・レベルを知る必要がある。このサービス・レ

自社が抱えている課題を整理する必要がある。もちろん、

ベルは、企業によって特殊な条件になることもあるが、筆者

 ベース・アーキテクチャを、具体的なシステムの実装アー

①の作業の中でもある程度の課題は見えてくるが、プライ

らの経験では、目標復旧時間を基準にすると次の5 つに

ベート・クラウドは企業のビジネス活動の基盤となるものでも

集約できるケースが多い。

あり、現状の延長線上だけで考えるものではない。経営者

●レベル5:原則無停止(数十秒で復旧)

や企画部門、開発部門、運用部門など、ITシステムにか

●レベル4:20∼30分で復旧

かわるさまざまなステークホルダー
(利害関係者)
の意見を

●レベル3:2∼3時間で復旧

ヒアリングし、将来的な構想も含めて課題を浮かび上がら

●レベル2:1日で復旧

せる必要があるのだ。また、いくつかの課題が判明したとき

●レベル1:1週間で復旧

でも、それらの裏に潜む共通項を見つけるために、さらに

 このように、あらかじめ代表的なサービス・レベルに絞り、

原因分析を繰り返す。

それらのレベルに応じたインフラ構成を標準化/パターン

 課題を整理した後は、それを要件に焼き直すことになる。

化しておくとよい。この標準化/パターン化したインフラ構

ただし、クラウド環境に対する要件は課題だけから導かれ

成が、先述した構成標準となる。このようにすれば、アプリ

るものではない。プライベート・クラウドを実現するには、当

ケーションのサービス・レベルが決まれば、ある程度の構成

然ながら、サーバの仮想化やリソースのプール化などに取

を容易に導き出せるようになる。一例として、上記のサービ

り組む必要があり、これらも重要な要件になる。また、企業

ス・レベルに従って策定したアーキテクチャ・パターンを図

の方向性やアプリケーションの開発計画が変われば、新

6に示す。

たな要件が出てくることもありうる。要件は、こうしたことも踏

 なお以降、この目指すべきアーキテクチャのことを「To

特集 2

088

IT アーキテクト Vol.24

023_toku2.indd 88

09/07/12 17:57

図6:サービス・レベルごとのアーキテクチャ・パターンの例

目標復旧時間
(サービス・レベル)

レベル5の
アーキテクチャ・
パターン

レベル4の
アーキテクチャ・
パターン

レベル3の
アーキテクチャ・
パターン

レベル2の
アーキテクチャ・
パターン

レベル1の
アーキテクチャ・
パターン

原則無停止

20∼30分

2∼3時間

1日

1週間

サーバ

フロントエンド

ブレード・サーバ
(非仮想化)

バックエンド

大型機

ブレード・サーバ
(仮想化)
ブレード・サーバ
(非仮想化)

ブレード・サーバ
(仮想化)

ブート方式

SAN Boot※1

内蔵ディスク

災害対策

災害対策要

災害対策不要

バックアップ方式

筐体内2世代※2

筐体内1世代

テープのみ

※1 サーバの内蔵ディスクではなく、
外部のSANストレージのディスクからブートする機能。
※2 2世代のバックアップを取得し、
サーバ内部に保存すること。

Beモデル」
と呼ぶ。

画を作りやすくなるだろう。
 To Beモデルに基づいて調達/構築した場合のコスト

ステップ④

移行計画の立案

を算出したら、移行計画の前提となる条件を整理する。こ
の条件としては、例えば「予算が不足しており、すべてのシ
ステムをクラウド環境上に一気に移行することはできない」

 To Beモデルを策定したら、次はその具現化に向けた

いったものから、ハードウェアのリース契約期間やOSのサ

ステップを明確にするために、移行計画を作成する。ただ

ポート終了時期、アプリケーションの改修計画などまでが考

し、その前に予算を確保しておく必要があるので、To Be

えられる。

モデルに基づいて調達/構築した場合のコストを見積もる。

 こうした条件を整理したうえで、移行計画を立案する。

このコストには、ハードウェア/ソフトウェアの購入費用のほ

移行を始める前に実施すべきことは山のようにある。プライ

かに、クラウド環境を構築するための費用や各システムの

ベート・クラウドを実現するための新しい技術の評価、運

移行費用を含める。これらのコストをこの段階で算出する

用方式の変更への対応、インフラの調達方法が変わるこ

のは難しいが、現状の運用コストをどの程度まで削減すべ

とについての開発部門との調整、共通基盤を運用するた

きかという目標を明らかにできれば、現実味のあるコスト計

めの各種作業などだ。これらは、移行までに実施する作業

IT アーキテクト Vol.24

023_toku2.indd 89

089

09/07/12 17:57

項目として、この段階で計画に組み込んでおく。

が生じる。

 移行計画の出来は、プライベート・クラウド導入の成否

 これまで、各システムは個別に管理されていたため、運

を決める重要な要因の1つだ。作成にあたっては、その点

用作業の負担が比較的小さく、システム環境の変更(環

を十分考慮していただきたい。

境変更)
も人手で行うケースが多かった。しかし、仮想化
技術によって1つのサーバ上で複数の環境を稼働させる

プライベート・クラウド構築で
鍵となる活動

と、ハードウェアとシステムの関係は「1対多」
となり、個々の

 以上の4ステップがプライベート・クラウド構築の初期で

ツールを使って環境変更を行うのが有効だ
(図 7)。構成

実施する重要な工程となるが、それらの中で行う活動のほ

管理ツールを使えば、環境変更の結果を構成情報に自

かにも、鍵となる取り組みがいくつかある。以下に、そのうち

動的に反映し、常に最新の構成情報を確認できる。

の主なものを3つ紹介しよう。

 また、プライベート・クラウドでは、従来システムごとに行っ

システム環境を把握しにくくなる。
 この問題に対処するには、人手に任せずに構成管理

ていた運用作業が統合されるため、それを人手で管理す

運用プロセス/体制の見直し

るのは非常に困難になる。よって、システム全体のサーバ

 プライベート・クラウドの実現では、仮想化技術の導入

やネットワーク、ジョブなどを一元的に管理できる統合運

が不可欠である。ただし、仮想化技術を適用すると、従

用ツールの利用も検討すべきだろう。

来は可能だった
“目で見る管理”
ができなくなるという問題

 そのほかの運用作業も、極力ツールによって自動化する

図7:構成管理のイメージ
ハードウェアとOS/アプリケーション間の関係が固定

→人手による管理が可能

ハードウェアとOS/サービスの関係が目で追えない

→ツールによる管理が必要

課題①:OS/アプリケーショ
ンの環境が動的に変化する
サービスA
OS/アプリ
ケーション

サービスB
OS/アプリ
ケーション

サービスC
OS/アプリ
ケーション

サービスA
OS/アプリ
ケーション

サービスB
OS/アプリ
ケーション

課題②:目視で
確認できない

サービスB
OS/アプリ
ケーション

サービスC
OS/アプリ
ケーション

課題③:台数が多くなる
と全体を管理しきれない

解決案:構成管理ツールを導入することで
動的な変化に対応した管理が可能になる

特集 2

090

IT アーキテクト Vol.24

023_toku2.indd 90

09/07/12 17:57

のが望ましいが、少なくとも現時点では、すべての作業を

用をサポートするツールの活用が鍵となる。そうした

自動化するのは不可能だ。人手による作業も一部で必要

ツールの評価は重要だ。特に運用自動化ツールにつ

になるが、それらも極力、定型化/パターン化するよう標

いては挙動や使い勝手などを、統合運用管理ツール

準化したうえで、明文化しておこう。

に関しては、インフラを統合監視する際の視認性や障
害発生時の追跡性(原因特定のしやすさ)
などを確

技術評価

認しておく。ツールの操作性も十分に評価しておいたほ

 実際にクラウド環境を構築/運用できるのかどうかにつ

うがよい

いての技術的な評価を行うことも重要だ。技術評価は、

 なお、すべて同一ベンダーの製品でまかなうときは、その

次のような観点で行う。

ベンダーに上記の観点による事前評価や障害時の対応

●新技術の評価:新しい技術の実用性を評価する。新

を依頼することができる。しかし、マルチベンダーでインフラ

技術の例としては、仮想化技術が挙げられる。この技

を構成するときには、事前の技術評価や障害対応はユー

術はすでに一般化しつつあるが、負荷を限界までかけ

ザー側の責任となる。その場合でも、例えば「接続性評

たときの挙動や、確実なバックアップ/リカバリー方式、

価の実施などを発注条件とする」
といった予防措置の導

さまざまなパラメータを組み合わせたときの性能など、ま

入を検討してもよいだろう。

だ明らかになっていない点も多い
●組み合わせ評価:複数のソフトウェア/ハードウェアを

長期的/継続的な計画の改善

組み合わせた際の挙動を評価する。例えば、ブレード・

 プライベート・クラウドに関する取り組みは、クラウド環境

サーバのシャーシはLANスイッチやFCスイッチを内蔵し

を構築したら終わりというわけではない。クラウド環境を構

ていることが多いが、クラウド環境内でブレード・サーバ

築した後は、そこに既存のシステムを段階的に移行していく

を使うときには、これらと外部スイッチ、ストレージ、仮想マ

ことになる。この移行には、ハードウェアのリース契約やアプ

シンを組み合わせた場合の動作保証が必要になる。こ

リケーション開発計画などを考慮すると3∼5年程度はかか

うした組み合わせでは、負荷がある範囲内に収まってい

るだろう。この期間内で、プライベート・クラウドの関連技

るときには問題が起きにくいが、負荷が限界値を超えたと

術の変化なども見越して、当初の計画を継続的に見直し

きには予期せぬ問題が起きる可能性があり、しかも問

ながら移行を進めていくべきだ。

題が生じた後で、それはベンダーの保証対象外だと判
明するかもしれない。
“転ばぬ先の杖”
として、事前に調
査/評価しておくべきだろう
●統合運用の評価:クラウド環境全体の運用に関する

プライベート・クラウドの
実現に向けた課題

技術的な問題を評価する。何度か述べたように、クラ

 ここまで、プライベート・クラウドの構築初期の手順や鍵

ウド環境ではインフラ運用が統合されるので、統合運

となる取り組みを紹介してきたが、現実には、プライベート・

IT アーキテクト Vol.24

023_toku2.indd 91

091

09/07/12 17:57

クラウド環境を構築し、使いこなしているような企業はまだほ

の技術が取り込まれている。このタグ VLAN は、IEEE

とんどない。一般の企業がクラウド環境を構築/運用して

802.1Qに準拠しており、仮想マシンの中に仮想的なスイッ

いけるようになるには、技術面や体制面などで多くの課題

チを実装するかたちで実現されている。すでに標準に対応

がある。以下に、それらの課題について述べる。

しているため、ネットワーク機器との接続に支障を来すこと
はない。

技術面の課題

 ただし、タグVLANを導入すると、サーバとネットワーク

 プライベート・クラウドの実現にまつわる技術上の課題に

の境目が曖昧になる。そのため、インフラを保守する担当

はさまざまなものが考えられるが、ここでは代表的な「仮想

者には、サーバ/ネットワーク双方の知見が必要になるの

化技術の適用に伴う課題」

「性能にかかわる課題」に

だ。特に大規模なシステムでは、両分野の分業が進んで

絞って説明する。

いることもあり、そうした知見を持つ技術者はあまり多くない。

●仮想化技術の適用に伴う課題

構築したクラウド環境を効率良く保守していくには、幅広

 仮想化技術には、プライベート・クラウドを実現するうえ

い知識を備えた技術者を確保することが重要になる。

で不可欠なサーバ仮想化のほかにも、I/O 仮想化やスト

●性能にかかわる課題

レージ仮想化、ネットワーク仮想化など、さまざまな種類が

 かつては、特に大規模システムにおいて、CPUやネット

ある。

ワークのリソース不足による性能問題が多く発生していた。

 サーバ仮想化は、完全に成熟したわけではないが、こ

しかし、最近ではハードウェア技術の高速化/大容量化

こ数年で当たり前のように使われる技術となってきた。一方、

に伴い、そうした事態はあまり起こらなくなっており、性能問

その他の仮想化技術については、まだ決定打となるような

題はアプリケーションに起因するものが増えている。

製品は存在せず、関連製品の多くは限られた機能しか

 しかし、インフラを統合すると、再びハードウェア・リソース

提供していない。

の使用率が上がり、インフラがボトルネックになることが懸念

 とは言え、将来的には、クラウド環境の各階層で仮想

される。プライベート・クラウドのように大規模に仮想化され

化が進み、柔軟なインフラが実現されるのが理想である。

た環境では、特にインフラに起因する性能問題が起きる可

サーバ仮想化以外の仮想化技術を取り入れていくことも、

能性が高いので、設計当初からキャパシティには十分配

将来構想としては検討していかなければならない。ただし、

慮すべきだ。

個々の仮想化技術には、それぞれに注意すべき点がある。
 ネットワーク仮想化を例にとって説明しよう。ネットワーク

体制面の課題

仮想化は、オープン環境におけるサーバ仮想化よりも古く

 プライベート・クラウド環境の下では、仮想化技術によっ

から存在する技術だ。意識されることは少ないが、サーバ

て個々のシステムのハードウェア環境とOSより上層の環境

仮想化(仮想マシン)の中には「タグ VLAN(Virtual

が切り離され、ハードウェアとアプリケーションの独立性が

Local Area Network)」
と呼ばれるネットワーク仮想化

高くなる。通常、ハードウェア環境はアプリケーション開発と

特集 2

092

IT アーキテクト Vol.24

023_toku2.indd 92

09/07/12 17:57

タイミングを合わせて構築されるが、クラウド環境下では共

調達をアプリケーション開発とは切り離して行うことが求め

通インフラとして独立に用意されることになるのだ
(図 8)。こ

られる。共通基盤部門は、システムの負荷状況やアプリ

うなると、インフラを構築する体制も、従来のように個々のシ

ケーションの開発計画をにらみながら、個別にハードウェア

ステムごとに担当を決めるのではなく、一括して受け持つ基

を調達していくことになるのだ。クラウド環境を効果的に構

盤部門(共通基盤部門)
が必要になってくる。

築/運用していくには、この共通基盤部門の新設(すで

 大企業の中には、すでに共通基盤部門を設置している

に存在している場合は、そのミッションの再定義)
が必要に

ところも多いが、そうした場合でも、部門システムなどは別管

なるだろう。

理になっており、自社内のすべてのインフラを共通基盤部

 共通基盤部門が担う役割を大別すると、インフラの企

門が管理しているというケースはほとんどない。しかし、クラウ

画、構築、運用の3つになる。もし、この責務ごとにチーム

ド環境を構築した場合は、効率化の観点から、全システ

を編成したとすれば、各チームの仕事は次のようになるだ

ムのインフラの管理を1つの組織に集約し、ハードウェアの

ろう。

図8:アプリケーションとインフラのライフサイクルが切り離される
従来のシステム
企画

アプリケーション
インフラ

設計

構築

運用

調達

構築

運用

評価

クラウド環境内のシステム
アプリケーション
企画

設計

構築

運用

評価

企画

設計

構築

運用

評価

企画

設計

構築

運用

評価

インフラ
企画

調達

構築

運用

評価

IT アーキテクト Vol.24

023_toku2.indd 93

093

09/07/12 17:57

●企画チーム:インフラに関する計画の立案が主業務とな

サービス・レベルに関する課題

るが、インフラ周りのすべてのコストをこのチームにまとめ

 共通基盤部門を設立すると、ハードウェアの調達は従

て管理させるために、ソフトウェア/ハードウェアを一括

来のようにアプリケーション開発の一部としてではなく、それ

して調達する機能も持たせるとよい。また、システムの負

とは切り離して行われることになる。そのため、これまでのよう

荷状況や標準の順守状況、アプリケーション開発計

な「ハードウェア・コストをアプリケーションごとに個別に見積

画の状況はインフラ企画にも影響を及ぼすので、企画

もって決める」
という方法がとれなくなるので、システムの利

チームには、それらの情報を流し、インフラ企画に反映

用部門がハードウェア・コストをどれだけ負担するのかを取

させる

り決めておく必要がある。この取り決めの結果が、サービ

●構築チーム:全システムのインフラ構築を担う。インフラ

ス・レベル標準に基づく
「サービス・メニュー」
となる。

全体のガバナンスという観点で見ると、このように1つの

 従来は各アプリケーションの要件に沿って個別に規定

チームで一括してインフラ構築を行うことのメリットは大き

してきたサービス・レベルだが、プライベート・クラウド導入

後もそのやり方を続けると、運用が煩雑になり、コストも増

●運用チーム:インフラ全体の運用を担当する。従来から

加する。それを避けるには、前述したように、サービス・レベ

インフラ運用を共通化している企業では、アプリケーショ

ルと、それに応じたインフラ構成をいくつかのパターンに標

ン運用とインフラ運用が部分的に一体化しているところ

準化し、アプリケーション側ではそれらのパターン
(サービ

がある。だが、クラウド環境下では、インフラ運用とアプリ

ス・メニュー)
の中から使用するものを選ぶというかたちに変

ケーション運用は切り離し、それぞれを担当する組織は

更する。標準化に際しては、バックアップ方式や運用方

別々にしなければならない。その際には、相互の役割分

法など、アプリケーションに依存する部分もパターン化し、

担を規定するとともに、障害発生時の連携手順なども

選択が可能なようにしておくべきだ。

明確化しておく
 こうして、共通基盤部門がインフラを一括して調達/構
築/管理するようになると、これまではアプリケーションの要
件ありきで進めていたインフラの企画/構築は、この部門

やがては
パブリック・クラウドへ

が主体となって
“あるべきインフラの姿”
を常に描きながら実

 本稿ではプライベート・クラウドに焦点を絞って解説して

施していくことになる。これまでインフラ担当者に求められるス

きたが、プライベート・クラウド活用の先にあるのは、企業

キルは技術的なものが多かったが、この共通基盤部門に

/組織に閉じずにコンピューティング資源を共有できるパブ

は「企画力」、そして各アプリケーション部門との調整を主

リック・クラウドの活用だ
(図 9)。前述のように、現状のパ

体的に行える
「調整力」が不可欠になる。共通基盤部門

ブリック・クラウドはセキュリティや可用性に関して問題を抱

のミッションを定義するのと併せて、メンバーに必要なスキル

えている。だが、これらの問題は、いずれ時間がたてば解

を見直すことも重要だ。

決されるだろう。各社は、プライベート・クラウドの構築に

特集 2

094

IT アーキテクト Vol.24

023_toku2.indd 94

09/07/12 17:57

よってITインフラの標準化を進める一方で、自社のコア・コ

た。

ンピタンスとなる領域を見定め、その領域以外の部分につ

 クラウド環境を構築する際には、従来アプリケーション

いては徐々に外部のサービスを活用していくことを検討すべ

開発の一部としてインフラを構築していたときよりも、担当者

きである。プライベート・クラウドの構築は、そうした長期的

に幅広い技術知識やステークホルダーとの調整力、そして

なビジョンの中に位置づけることで、その意義が明らかにな

何よりも将来を見通すビジョンが求められる。これは、まさし

るだろう。

くアーキテクトが担うべき仕事だ。アーキテクト諸氏には、ぜ
ひプライベート・クラウドの構築という活動を通じて自社のイ

*  *  *

ンフラ構築/運用のプロセス/体制を見直し、長期的な

 以上、本特集では、プライベート・クラウドの構築にあ

ビジョンの下にインフラを
“あるべき姿”
へと近づけていってい

たっての検討事項や作業手順、留意事項などを解説し

ただきたい。

図9:やがてはパブリック・クラウドへ
サービス品質

規模の拡大

将来の
プライベート・
クラウド

現状の
プライベート・
クラウド

業界規模

グループ企業規模

部門単位

将来の
パブリック・
クラウド

信頼性/
セキュリティの向上

現状の
パブリック・
クラウド
部門単位
対象規模

IT アーキテクト Vol.24

023_toku2.indd 95

095

09/07/12 17:57

BI の変遷
登場/発展の背景を知り、
BI システムへの理解を深める

代にかけてのクライアント/サーバ(C/S)型アーキテク
チャの普及だ。
 それまでのシステム・アーキテクチャでは、メインフレー
ムはもちろんのこと、システムの部門別導入を可能にした

 BI(Business Intelligence)
の概念が登場したの

ミニコンピュータも含め、アプリケーションの実行からユー

は、1989年のことだ。1980年代と言えば、メインフレーム

ザー・インタフェース
(UI)
の制御、データの管理までを

の全盛期であり、パーソナル・コンピュータ
(PC)
やミニコ

すべてサーバ
(当時の言葉で言うと
「ホスト」)
で処理し

ンピュータ、ワークステーションといった部門/個人を意

ていた。クライアントはコンピュータではなく、あくまでも端末

識したコンピュータは、ようやく発達が始まろうかというこ

(ターミナル)
であり、PCもサーバに接続して使用する場

ろである。当時、米国ガートナーのアナリストであったHo

合は端末のエミュレータとしての役割しか果たしていな

ward Dresner 氏は、
「企業内に蓄積されたデータを

かった
(図1)。

検索/集計/分析することで、ホワイ
トカラーの生産性
を上げる」
という考え方をBIと名付けて提唱した。これは

図1:従来のシステム・アーキテクチャ

具体的なシステム・アーキテクチャを指すのではなく、そ

●データの管理
●アプリケーションの実行
●UIの制御

れまでIT部門に100%依存していたデータ処理の業務
を、データの利用者であるエンドユーザーが自ら手掛け

端末

ることで、生産性の向上や意思決定の迅速化を目指そ
うという極めてビジネス的な観点に立った提言であった。
 このような提言が市場に受け入れられた背景には、
当時、システム・アーキテクチャが大きく変化しつつあっ
たことがある。その変化とは、1980年代後半から1990年

端末

汎用機、
ミニコンピュータなど

端末エミュレータを搭載したPC

端末エミュレータを搭載したPC

B I の 現 在、
特 集 3

Business
Intelligence

登 場 の 背 景 と 今 日 ま で の 変 遷 、 関 連 技 術 / 製 品 の 動 向 を 踏 ま え て 考  

096

    え

IT アーキテクト Vol.24

toku-03.indd 96

09/07/12 19:52

考  

 だがC/S 型アーキテクチャの普及が進み、Windows

接続し、データの管理をサーバで、アプリケーションの実

3.1が発売された1992 年ごろには、PCの性能が飛躍的

行とUIの制御をクライアントPCで行うというC/S型アーキ

に向上する。その結果、文書やスプレッドシートの作成が

テクチャが確立されたのである
(図2-①)

中心だったPCの用途は、アプリケーション開発や業務ア

 C/S型アーキテクチャを使ったシステムは、Dresner氏

プリケーションの実行にまで一気に拡大したのである。

が提唱したBIの概念、すなわちデータ処理業務をエンド

 また、時期を同じくして、RDB 製品の充実や RISC

ユーザー自らの手で行うというビジネス界のトレンド※ 1とうま

(Reduced Instruction Set Computer)
チップを搭載

く合致した。必然的に、最初のBIシステムの普及は、こ

した高速かつ安価なUNIXサーバの登場、高速 LAN

のC/S型アーキテクチャの浸透とともに進んだのである。

(Local Area Network)
の普及も進んだ。結果として、
少数のデータベース・サーバと多数のPCをLAN経由で

※1 当時、このトレンドは
「EUC
(End User Computing)
」、もしくは
「EUD
(End User Development)

などと呼ばれた。

図2:C/S型アーキテクチャとC/S型のBIアーキテクチャ
①C/S型アーキテクチャ
●データの管理

LAN

②C/S型のBIアーキテクチャ
●アプリケーションの実行
●UIの制御

●データの管理

LAN

●アプリケーションの実行
●UIの制御
Q&Rツール

Windows OSを
搭載したPC
RDBを搭載した
UNIXサーバ

Q&Rツール
Windows OSを
搭載したPC

DWH
Q&Rツール

RDBを搭載した
UNIXサーバ

過 去、 未 来

    え る 、 今 後 の B I シ ス テ ム —— ク ラ ウ ド 時 代 に 、 何 が ど う 変 わ る の か
経済情勢や社会状況、市場ニーズなど、今日、企業を取り巻くビジネス環境は目まぐるしく変化している。そうした状況
を把握しつつ、業務上の意思決定を適切に行えるようにするための技術としてより一層、重要性が高まっているのが「BI
(Business Intelligence)」だ。今年 3月にガートナー ジャパンが発表したCIO に対するアンケート調査の結果でも、BI は
「優先的に導入したい技術」
としてグローバルで1 位、国内で2 位にランクインしており、大きな期待を集めていることがうか
がえる※。おそらく各社のアーキテクトには、今後 BI に関する知識/スキルがより強く求められるようになるだろう。また、近
年登場したクラウド・コンピューティングにより、企業システムのアーキテクチャに変化が生じようとしており、それが BIシステ
ムに与える影響も無視できない。本特集では、アーキテクトのBIに対する理解を深めることを目的に、BIが登場した背景や
これまでの変遷、関連技術の動向などを解説したうえで、さらにクラウド時代のBIシステムのあり方を考察してみたい。
※ ガートナー ジャパンが実施した2009年の課題に関するEXP CIOサーベイの結果発表
(http://www.gartner.co.jp/exp/pr20090318-01_full.html)
より。

平井 明夫

Akio Hirai

アイエイエフコンサルティング マーケティング部 マーケティングディレクター

IT アーキテクト Vol.24

toku-03.indd 97

097

09/07/12 19:52

C/S型のBIアーキテクチャ
 それでは、C/S 型アーキテクチャの下で普及した初
期のBIシステムは、どのような構成だったのだろうか。
 この時代の標準的なBIシステムは、DWH(Data W

図3:スター・スキーマ

ファクト・テーブル

期間テーブル

顧客テーブル

時間キー

顧客キー

売上テーブル

顧客コード

時間キー

顧客名

arehouse)
とQ&R(Query & Reporting)
ツールから

四半期

顧客キー

住所

成る
(図 2- ②)。DWHとは、業務システムから抽出した

半期

部署キー

データを時系列でRDBに蓄積したもので、その多くはU

売上数量
売上金額

NIXサーバを使用していた。エンドユーザーは、DWH

部署テーブル

に対してQ&Rツールを使ってアクセスすることで、RDB
やSQLの知識がなくてもデータの検索とリポート作成を

部署キー
部署コード

ディメンション・テーブル

部署名

行えるというのが、このシステムの最大のメリットだった。
 Q&Rツールの登場により、それまでの「リポートは情報

術から成るアーキテクチャを中心に発展したが、エンド

システム部門に依頼して出力してもらうもの」
という常識が

ユーザーへの普及という点では、一部のパワー・ユー

覆され、情報処理の業務プロセスは革命的に変化した。

ザー、すなわち自らデータを検索し、リポートを作成する

 また、Q&Rツールの普及は、DWHの導入促進にも

意欲と必要性を持つユーザーに利用が限定されてい

つながった。DWHの特徴は、そのスキーマ
(データベー

た。これは、当時のBIの概念がエンドユーザーのデー

ス構造)
に見られる。標準的なDWHでは、データを時

タ処理に対する積極性を前提としていたことを考えれ

系列に格納し、高速な検索を行うのに適した「スター・

ば、当然の結果だったのかもしれない。

スキーマ」
と呼ばれるデータベース構造を持つ。スター・

 しかし、パワー・ユーザー以外の層にも、BIに対する

スキーマは、
「ファクト・テーブル」
と呼ばれるインデックス

潜在的なニーズは存在していた。この時代にそれが掘り

と数値カラムによって構成されるテーブルの周りを、属性

起こされなかった理由の1つは、C/S 型アーキテクチャ

データで構成される複数の「ディメンション・テーブル」

の性能的な限界(同時に利用可能なユーザー数が少

が星型に取り囲むかたちで表現される
(図 3)。このスタ

ない)
にあると筆者は見ている。

ー・スキーマには、次のような利点がある。
●顧客名や部署名といった属性データによる検索は、
ディメンション・テーブルのみの全件走査で処理できる
ため、検索スピードが速い
●ファクト・テーブルと複数のディメンション・テーブルとの
間のデータの重複を最小限に抑えられる

098

ITアーキテクチャの変化に伴う
BIアーキテクチャの変化
 C/S 型アーキテクチャが全盛期を迎えたのは、1990
年代後半のことだ。このころ、ITの世界はインターネット

● DWH 内固有のキーで結合しているため、業務システ

の普及という大きな変革を迎えていた。それに伴い、企

ム側で変更された属性データへの対応が容易である

業システムでは、Webブラウザやアプリケーション・サー

 こうした特性を持つスター・スキーマを用いたDWHの

バなどを取り入れたイントラネットの導入が始まり、
「企業

性能を向上させるために、RDB側ではパーティションやサ

内のすべてのユーザーが全アプリケーションを利用でき

マリ・テーブルといった領域の機能強化が図られた。

るようにする」
というビジネス課題の解決が、企業内シス

 C/S 型アーキテクチャ時代のBIは、以上のような技

テムのITアーキテクチャに求められるようになった。

IT アーキテクト Vol.24

toku-03.indd 98

09/07/12 19:52

 また、C/S 型アーキテクチャで構築された企業システ

3層型のBIアーキテクチャ

ムのメンテナンス性が問題視されるようになったのも、この

 C/S 型アーキテクチャから3 層型アーキテクチャへの

時期である。C/S 型アーキテクチャの下に導入されたク

移行に伴い、アプリケーションの実行をアプリケーション・

ライアントPCの多くは、経年によるハードウェアのリプレー

サーバが、UIの制御をWebブラウザが担うようになった

スやソフトウェアのバージョンアップに直面し、メンテナンス

のはすでに述べたとおりだ。C/S 型のBIアーキテクチャ

に要する金銭的/人的コストが増大したのだ。これによ

において隆盛を誇ったQ&Rツールも、この変化に大き

り、C/S型アーキテクチャの優位性は大きく揺らいだ。

な影響を受けた。SQL 文の組み立てからリポートの表

 そこに登場したのが、いわゆる3層型アーキテクチャで

示/印刷のための書式の設定、保存に至るまで、処

ある。C/S 型アーキテクチャにおいて、クライアントPCの

理の大部分がアプリケーション・サーバ上で実行され、

役割だったアプリケーションの実行とUIの制御は、3 層

UI制御だけがクライアントPC上のWebブラウザ上で行

型アーキテクチャではそれぞれアプリケーション・サーバ

われるようになったのである
(図4-②)。

とWebブラウザが担う
(図4-①)。これにより、クライアント

 変化はこれにとどまらなかった。C/S型から3層型への

PC 上でメンテナンスの必要なソフトウェアは、理論上、

移行が生じたのは、
「大勢のユーザーをサポートする」

OS 以外ではWebブラウザのみとなり、メンテナンスの手

という課題を解決する必要があったからだ。その関係か

間を軽減することが可能になったのである。

ら、Q&Rツールには次の2つの機能が追加された。

 一方、C/S 型アーキテクチャにおいて、データ管理

●Webリポーティング機能

の役割を担ってきたRDBの位置づけは、3 層型アーキ

●ダッシュボード機能

テクチャにおいても不変だった。しかし、C/S 型アーキテ

 Webリポーティング機能とは、パワー・ユーザーが作

クチャから3 層型アーキテクチャへの移行に伴い、イント

成したリポートをWebブラウザ経由で多数の一般ユー

ラネットおよびアプリケーション・サーバ経由でデータベ

ザーが閲覧できるようにする機能である。ここで言う一般

ースに接続するユーザーの数は飛躍的に増大した。そ

※ 2 このときに強化された機能の 1 つが「コネクション・プーリング」
である。
同機能では、あらかじめ一定数のセッションを確保しておくことで、大量の接続
要求があったときでも、セッションの確立/切断に伴う負荷を軽減し、性能の
低下を防ぐ。

のため、RDBにおいては、大勢のユーザーをサポート
するための機能強化が必須となる※2。
図4:3層型アーキテクチャと3層型のBIアーキテクチャ
①3層型アーキテクチャ
●データの管理

RDBを搭載した
サーバ
●アプリケーションの実行

LAN

②3層型のBIアーキテクチャ
●データの管理

●UIの制御

Webブラウザを
搭載したPC
Webブラウザを
搭載したPC

DWH
●アプリケーションの実行

LAN

●UIの制御

Webブラウザを
搭載したPC
Webブラウザを
搭載したPC
Webブラウザを
搭載したPC

Webブラウザを
搭載したPC
Q&Rツール

アプリケーション・
サーバを搭載したサーバ

特 集 3

B I の 現 在 、 過 去、 未 来
Business
Intelligence

IT アーキテクト Vol.24

toku-03.indd 99

099

09/07/12 19:52

ユーザーとは、日々の業務において検索/分析された

の中でRDBに追加された機能のうち、特に代表的なも

結果のみを受け取って活用するユーザーのことだ。C/

のが「パーティション」

「サマリ・テーブル」の2つだ。以

S 型のBIアーキテクチャの時代には、一般ユーザーは

下、それぞれについて説明しよう。

パワー・ユーザーが作成したリポートを紙に出力した状
態で受け取っており、BIシステムの直接的なユーザー

パーティション機能

ではなかった。しかし、3 層型アーキテクチャの下では、

 スター・スキーマにおいてレコード数が最も増加するの

Webブラウザを使用して直接 BIシステムにアクセスし、

が、中心となるファクト・テーブルである。ファクト・テーブ

作成済みのリポートを閲覧するようになったのだ。

ルのレコード数が増大すると、検索性能が低下する。そ

 一方、ダッシュボード機能とは、パワー・ユーザーが

こで、ファクト・テーブルを任意の数の区画(パーティショ

作成した複数のリポートを単一のWebブラウザ上でグラ

ン)
に分割し、特定の区画だけを検索対象とすることで

フィカルに表示するというものである。経営層がリポートの

性能低下を防ぐ仕組みがパーティション機能である。

内容を理解しやすいようにするために、グラフ表示だけ

 パーティション機能にはいろいろな実現方法がある

でなく、シグナルやゲージといった形式が追加された。

が、DWHでよく用いられるのは、ファクト・テーブルの年

 こうして、C/S型BIアーキテクチャの時代にはパワー・

月日カラムに対して、一定期間ごとにパーティションを設

ユーザーだけだったユーザー層に一般ユーザーやリポ

定する
「レンジ・パーティション」だ。例えば、2005 年 1月

ート開発者、経営層が追加され、Q&Rツールの機能

から2009年12月までの5年(60カ月)分のレコードを持つ

は極めて複雑になった。ソフトウェア・ベンダーの多くは、

ファクト・テーブルで、
「2009年7月」
を含むレコードに対

これらの機能をまとめて「BIスイート製品」
として販売し、

して検索を行うとする。このとき、1カ月単位でパーティショ

用途に応じて単体での購入も可能にすることで、複雑な

ンを設定しておけば、検索時間は理論上60分の1に短

ユーザー・ニーズに対応してきたのである 。

縮されることになる。

BI の関連技術と、
その最新動向

サマリ・テーブル機能

※3

どういった技術が使われ、
どのような製品があるのか

 DWHにおいてRDBに要求されるクエリには、集計を
伴うものが多い。この集計速度の向上をもたらすのが、
サマリ・テーブル機能である。
 サマリ・テーブルの作成も、一般的なアプリケーション
開発ではよく行われる。例えば、月単位の販売実績の

 ここまで、BIが登場した背景と、現在のBIアーキテク

レコードを持つファクト・テーブルに関して、四半期ごと

チャに至るまでの変遷を解説してきた。続いては、BIに

や年度ごとに集計したテーブルを作成するようにプログラ

関連した技術の概要と、その最新動向を説明しよう。

ミングしておくのである
(図 5)。ただし、サマリ・テーブル
にアクセスするには、検索プログラムで明示的にサマリ・

パーティションとサマリ・テーブル
 BIの発展とともにRDBがDWHに用いられるようにな
り、RDBではDWH用の機能の強化が図られてきた。そ

100

※ 3 現在販売されている主なBIスイート製品としては、オラクルの「BIEE
(Oracle Business Intelligence Suite Enterprise Edition Plus)
」、SAP
の「SAP Business Objects Enterprise XI」、IBMの「IBM Cognos 8 Bu
siness Intelligence」、マイクロソフトの「Microsoft SQL Server 2008」

どがある。

IT アーキテクト Vol.24

toku-03.indd 100

09/07/12 19:52

テーブルを指定しなければならない。こうした制限は、プ

うち、テーブルの全件走査や結合といった大量のデータ

ログラムの複雑性を増し、保守性にも影響を与える。

を扱うものは、アプライアンスを構成するストレージ側で実

 これに対して、RDBに実装されたサマリ・テーブル機

行する。これにより、ストレージとRDBとの間でやり取りす

能では、サマリ・テーブルの作成/更新はRDBによっ

るデータの量を減らし、DWHの性能低下を防ぐのだ。

て管理されるため、検索要求時にサマリ・テーブルを指

 もう1つの形態は、特定のハードウェアを組み合わせ

定する必要がない。これは、サマリ・テーブル機能が検

るだけでなく、RDB自体の機能もDWH 用に限定してし

索内容を識別し、適切なサマリ・テーブルを使用するよ

まうというものである。代表的なアプライアンス製品として

う自動的に検索内容を再構成するためである 。

は、ネティーザの「Netezza Performance Server」が

 なお、本稿執筆時点
(2009年7月)
で、パーティション機

挙げられる。

能/サマリ機能が搭載されている主なRDB 製品には、

 Netezza Performance Serverは、専用のブレー

IBMの「IBM DB2」、オラクルの「Oracle Database」、マ

ド・サーバと専用の RDBから成る。これらはいずれも、

イクロソフトの「Microsoft SQL Server」
などがある。

DWH 以外での利用は考慮していない。その代わり、ハ

※4

ードウェアとソフトウェアを徹底的に一体化させてDWH

アプライアンスによる性能の向上

用の機能/性能の最適化を図り、低価格で提供して
いる。

 前節で紹介したパーティション機能とサマリ・テーブル

OLAPと多次元データベース

機能は、汎用的なRDB製品でDWH向けに機能強化
を図った例である。それに対し、用途をDWHに限定し
て、さらに大きな性能向上を図る手段として用いられるの

 先述のとおり、BIシステムの初期ユーザーはパワー・

がアプライアンスだ 。これには、2つの形態がある。

ユーザーが主だった。ただし、それらのユーザーの中に

 1つは、汎用的なRDBを特定のハードウェアと組み

は、さらに高度なデータ分析を必要とするユーザー層が

合わせ、あらかじめDWH向けにチューニングしたかたち

存在しており、彼らのニーズを満たすために
「OLAP
(On

で提供するという形態だ。代表的なアプライアンス製品と

Line Analytical Processing)

と呼ばれるデータ処理

しては、オラクルの「Oracle Exadata(エクサデータ)」

方式を実装した多次元データベースが登場した。

などが挙げられる。

 OLAPでは、3次元以上の多次元データベースの中

 DWHの性能を低下させる主な要因の1つは、RDB

から2 次元のクロス集計表のかたちでデータを取り出し、

とストレージの間で行われるデータ転送量の増大であ

分析処理を行う。ここで、次ページの図 6をご覧いただ

る。Exadataでは、通常RDBで実行される検索処理の

きたい。

※5

 図 6- ①のサイコロ状の部分が、
「期間」、
「製品」、
図5:サマリ・テーブル機能

ファクト・テーブル 集計

「地域」
という3 次元から成る多次元データベースを表

サマリ・テーブル
四半期

集計

年度

本部

集計

事業部

す。各次元はそれぞれ階層を持っており、図 6- ①には3
つの次元(ディメンション)
と階層を組み合わせて集計し



集計

※4 これを
「クエリ・リライト」
と呼ぶ。

特 集 3

※ 5 ハードウェアとソフトウェアを一体化して特定用途向けに機能/性能を
最適化したもの。アプライアンス製品は比較的、低価格で提供される。

B I の 現 在 、 過 去、 未 来
Business
Intelligence

IT アーキテクト Vol.24

toku-03.indd 101

101

09/07/12 19:52

図 6:OLAPと多次元データベース
地域

製品

①販売金額

期間

③期間ディメンションの
「年」
階層から

「月」
階層にドリルダウンした表
全製品 2002年1月 ……

2002年12月

東日本 18

……

36

西日本 10

……

20

海外

……

16

8

ドリルダウン
④製品ディメンションに沿ってスライスして
 製品 Aだけを対象としたデータに絞り込んだ表

②サイコロの手前の面を2 次元でとらえた表
全製品 2000 年 2001 年 2002 年
東日本 120

240

360

西日本 50

100

海外

40

10

スライシング

製品 A

2000 年 2001 年 2002 年

東日本 80

150

200

200

西日本 20

40

100

160

海外

10

100

ダイシング

0

⑤地域ディメンションと製品ディメンションを
 ダイシングによって入れ替えた表
全地域 2000 年 2001 年 2002 年
製品 A

100

200

製品 B

40

100

250

80

170

製品 C 40

300

た販売金額の数値が入る。このサイコロの手前の面を2

企画、マーケティングといった業務で利用される。これら

次元の表として見ると、縦軸が地域で横軸が期間とな

の業務に携わるユーザーはExcelになじみが深いため、

り、表の中には地域と期間を組み合わせて集計した全

多次元データベースを操作するソフトウェアはExcelのア

製品の販売金額が含まれていることになる
(図6-②)。

ドインとして提供されていることが多い。

 このように、多次元データベースでは集計値を2次元

 本稿執筆時点において、国内で販売/サポートされて

の表単位で扱い、さらに1つの表に対して次の3つの操

いる主な多次元データベース製品には、IBMの「IBM

作を行って特定の表を取り出す。

Cognos TM1」やオラクルの「Oracle Essbase」、マイクロ

●ドリルダウン:ディメンションの階層に沿ってデータを

ソフトのMicrosoft SQL Serverなどがある。

掘り下げる操作。図 6- ③では、期間ディメンションの
「年」階層から
「月」階層にドリルダウンしている※6
●スライシング:多次元データベースの奥行きに当たる
次元に切れ目を入れて
(スライスして)、対象データを

コマーシャルOSSによる
BIスイートの提供

絞り込む操作。図6-④では、製品ディメンションに沿っ

 OSS(Open Source Software)
は、近年のIT、お

てスライスして製品 Aだけを対象としたデータに絞り込

よびITアーキテクチャを語るうえで無視することのできない

んでいる

トレンドの1つだ。そのOSSにおけるBI関連の動きにも触

●ダイシング:多次元データベースをサイコロ
(ダイス)

れておこう。

見立て、それを転がす
(ダイシングする)
ことで手前に見

 OSSを使う最大のメリットは、だれでも最新のプロダク

える面を変える操作。図 6- ⑤では、地域ディメンションと

トを無償で入手できるということだろう。ただし、最近では

製品ディメンションをダイシングによって入れ替えている
 OLAPと多次元データベースは、主に財務や経営

102

※6 逆に、より上位の階層に戻る操作を
「ドリルアップ」
と呼ぶ。

IT アーキテクト Vol.24

toku-03.indd 102

09/07/12 19:52

有償にする代わりに商用製品と同等の技術サポートを

タ・マイニング専用のソフトウェアとして提供されてきた。だ

提供する
「コマーシャルOSS」が登場し、1つのマーケット

が近年、BIシステムの背後にあるDWHをデータ・マイニ

を形成している。

ングのソース・データとして共有するケースが増えているこ

 コマーシャルOSSは、有償とは言え一般の商用製品

とから、DWH(RDB)
にデータ・マイニング・アルゴリズム

に比べればはるかに安く入手でき、サポートも受けられる

の実行エンジンを搭載して提供するケースが増えている。

という点をメリットとしている。OSや一部のアプリケーション

 本稿執筆時点では、主なRDB 統合型のデータ・マ

など、汎用性が高く、市場の広い技術分野で少しずつ

イニング製品として、Oracle DatabaseやMicrosoft

シェアを広げてきた。その観点からすると、BIは用途が

SQL Serverなどが提供されている。

限定的で市場が狭いため、これまでコマーシャルOSS
の対象としてはあまり注目されてこなかった。
 しかし今日、大企業におけるBIユーザーが増大し、
中堅以下の企業におけるBIのニーズが増えたことによ
り、コマーシャルOSSの世界でも商用製品と遜色のない

これからの BI

クラウドの登場は、
BI システムにどう影響するのか

BIスイートが登場し始めている。本稿執筆時点における

 ここまでに述べたように、ITアーキテクチャの変化に伴

主なコマーシャルOSSのBIスイートには、米国Pentaho

い、BIシステムのアーキテクチャも変わってきた。それを踏

の「Pentaho Open BI Suite」、Jaspersoftの「Jasp

まえて考えると、今後 BIシステムのアーキテクチャに最も

ersoft BI Suite Professional」などがある。

影響を与える可能性があるのはクラウド・コンピューティ
ングだ。以降、クラウド・コンピューティングがBIシステム

データ・マイニングとBIの関係

のアーキテクチャに与えるであろう影響を考察する。

 データ・マイニングは、医療分野において患者の属

3種類のクラウド・コンピューティング

性データから病気の原因を発見したり、工場において
部品の故障データから不良の原因を発見したりといっ

 クラウド・コンピューティングという言葉がIT 系のメディ

た具合に、さまざまな分野で利用されている。そのうちの

アに登場するようになってからすでに2年あまりが経過して

いくつかは、BIとも密接な関係を持つ分野だ。例えば、

おり、最近では一般メディアでも取り上げられるようになっ

小売業の分野では、データ・マイニングを「バスケット分

ている。しかし、その実体についてはまだ不明瞭さを感じ

析」に利用している。バスケット分析とは、
「バスケット
(顧

ている方が多いだろう。そこで、まずはクラウド・コンピュ

客の買い物カゴ)
の中に、どんな組み合わせで商品が

ーティング自体について簡単に整理しておこう。

入っているか」、言いかえれば「ある商品を購入する際

 クラウド・コンピューティングのアーキテクチャは、仮想

に、どのような商品と一緒に購入する確率が高いのか」

化技術と分散データ処理技術の進歩によって実現さ

を分析する手法である※7。

れたものだ。それにより、アマゾンやグーグル、セールスフ

 データ・マイニングにおいて、データの関連性や傾向
を見つけ出す手法はアルゴリズムと呼ばれるが、バスケッ

※ 7 この分析結果を基に商品の陳列方法を工夫することで、ある商品を買
う顧客に、別の商品を
“ついでに”
買ってもらえる確率を高められる。

ト分析では「アソシエーション・ルール 」
というアルゴリズ
※8

※ 8 ある事象が発生した際、同時に別の事象が発生する確率を計算する
アルゴリズム。

ムを使う。このアルゴリズムの実行エンジンは従来、デー

特 集 3

B I の 現 在 、 過 去、 未 来
Business
Intelligence

IT アーキテクト Vol.24

toku-03.indd 103

103

09/07/12 19:52

ォース・ドットコムといったサービス・ベンダーが、以前で

上でBIシステムを構築したいというニーズの高まりに応じ

は考えられなかったようなスケーラビリティを持つ大規模シ

て、IaaS対応が適宜進むだろう。

ステムを構築/運用することが可能になった。やがて、こ
れらの企業は、自社が保有する大規模システムの一部
をサービスとして提供し始めたのである。

PaaSとBIの歩み寄り

 現時点でのクラウド・コンピューティングは、提供され

 グーグルが提供する「GAE(Google App Engi

るITリソースの形式によって「IaaS(Infrastructure as

ne)」やセールスフォースの「Force.com」に代表される

a Service)」、
「PaaS(Platform as a Service)」、

PaaSは、アプリケーションの開発/運用環境を提供す

「SaaS(Software as a Service)」の3つに分類される

るものだ。ただし、GAEやForce.comを使ってBIシステ

(表1)。この3種類のクラウド・コンピューティングがBIに

ムを構築する際、現状では大きな障壁が存在する。そ

与える影響を考えてみよう。

れは、対応データベースがRDBではないということだ。
 これらのPaaS環境は、BI機能を含まない大規模なア

IaaS上でのBIシステム構築

プリケーションを開発/運用するための基盤として生ま

 アマゾンの「Amazon EC2(Elastic Compute Clo

処理に特化したキー/バリュー
(Key/Value)型デー

ud)」や「Amazon S3(Simple Storage Service)」

タベースとなっている。昨年マイクロソフトが発表した

に代表されるIaaSは、仮想的なサーバ/ストレージを

PaaS 環境の「Windows Azure」
も、使用するデータ

提供するというものだ。ユーザー企業が、このIaaSで提

ベースは「SQL Data Services」
と呼ばれるキー/バリ

供される仮想サーバ上にRDBやBIスイートを導入して

ュー型データベースであった
(後述するが、現在は仕

BIシステムを構築することは理論上、難しい話ではない。

様がRDBに変更されている)。

 ただし現状、すべてのRDBやBIスイートがIaaS環境

 キー/バリュー型データベースでは、RDBにおけるテ

での動作を保証したり、サポートを提供したりしているわ

ーブルの概 念はなく、データは「キー」と「バリュー

けではない。代表的なIaaS 環境であるAmazon EC2

(値)」から成る
「Property」
として格納される。例えば、

ですら、その上での動作が保証されているのは大手ベン

Windows AzureのSQL Data Servicesは、あらかじ

ダーが提供するRDB製品のみである。

め「Authority」、
「Container」、
「Entity」
という3つ

 こうした中、Pentahoが今年 2月、Amazon EC2 上

の層から成るオブジェクト階層を持っており、最下層の

で動作する
「Pentaho BI Suite」のサポートを表明し

Entityが複数のPropertyを持つ
(図7)。RDBの前提

た。これにより、例えば、Amazon EC2、Oracle Data

となるジョイン
(Join)
やビュー
(View)
といった概念は基

base、Pentaho BI Suiteといった組み合わせで手軽

本的に存在しないため、スター・スキーマのようなデータ

にBIシステムを構築できるようになるわけだ。今後、IaaS

ベース構造を持つのが難しい。こうしたことから、GAE

れ、発展した。そのため、使用するデータベースは分散

表1:3種類のクラウド・コンピューティング

104

種類

特徴

IaaS
(Infrastructure as a Service)

仮想的なサーバ/ストレージをサービスとして提供する

Amazon EC2、Amazon S3

(Platform as a Service)
PaaS

アプリケーション開発環境をサービスとして提供する

Google App Engine、Force.com、Windows Azure

SaaS
(Software as a Service)

アプリケーションをサービスとして提供する

Salesforce.com

IT アーキテクト Vol.24

toku-03.indd 104

09/07/12 19:52

図7:キー/バリュー型データベースの構造

Authority
Container

Property
(キー/バリュー)

Entity

……

……

Property(キー/バリュー)

……

Container

Entity

やForce.comはDWHの構築には適さないと言えよう。

米国LucidEraが提供する
「LucidEra」では、Salesfo

 だが、これらのPaaS 環境が広く利用され始めるのは

rce.comのデータを前提に、データのヒストリカルな蓄積

時間の問題であり、将来的にはDWHの構築が可能に

やOLAP分析、外部データとの連携といったBI機能を

なるよう機能強化されていく可能性が高い。実際、最

提供している。

近更新された Windows Azure の仕様では、SQL

 先に、Force.comのようなPaaS 環境は、キー/バリ

Data ServicesがSQL Server 2008に相当するRDB

ュー型データベースを使用しているがゆえに、DWHの

の仕様に変更されている。

構築には適さないと述べた。これはつまり、Force.com

 また、IaaS上にあらかじめRDBやBIスイートを導入し

上に構築されたSalesforce.comについても、そのアプリ

た環境を、BI用途専用のPaaSとして提供するベンダー

ケーションが持つデータをDWHに蓄積してBIによる分

も現れ始めた。そのうちの1 社が、米国 Vertica Syste

析やリポートの作成を行うのは難しいということだ。Luci

msである。同社は昨年5月、
もともとDWH専用のRDB

dEraの場合、独自のDWH環境とBIアプリケーションを

として提供していた「Vertica Analytic Database」

IaaS上に構築し、それをSaaSとして提供することで、Sal

Amazon EC2 上に導入した状態で提供するサービス

esforce.comの弱点を補強しているのである。

を発表している。

*  *  *

 以上のように、今後はPaaSとBIも歩み寄っていくこと
が予想される。

 以上、本特集では、BIが登場した背景と現在まで
の変遷、関連技術とその最新動向を整理したうえで、

SaaSによるBI機能の提供

今後の展望を述べた。

 Salesforce.comに代表されるSaaSは、アプリケーショ

れる技術であるため、それがBIに与える影響はまだはっき

ンをサービスとして提供するものだ。BIシステムは、基本

りしていない。だが、C/S 型アーキテクチャから3 層型ア

的には開発環境であり、形式の定まったリポートを作成

ーキテクチャへの移行に伴ってBIアーキテクチャが変化

したり、ダッシュボードを表示したりといった機能をアプリ

したように、クラウドの普及もBIアーキテクチャを変化さ

ケーションとして提供するわけではない。そのため、BIシス

せるだろう。折しも、BIに対するニーズが急速に高まりつ

テムとSaaSの間に何らかの関連があるとは考えにくい。

つある。ここ10 年ほど平穏であったBIの世界に大変動

 しかし、小規模な企業が、OSSと同等、もしくはそれ

が起きようとしている今こそ、BIへの取り組みを改めて考

以上のコスト・メリットのあるSaaSをBIシステムに利用した

えるときではないだろうか。本特集の内容が、その一助と

いと考えるのは自然な流れだ。この流れを受け、例えば

なれば幸いだ。

 クラウド・コンピューティングは、これから普及が見込ま

特 集 3

B I の 現 在 、 過 去、 未 来
Business
Intelligence

IT アーキテクト Vol.24

toku-03.indd 105

105

09/07/12 19:52

特別 企 画

“抽象化力”
を磨け
3

アーキテクトの必須能力

﹁全体を見ながら部分も注視し、共通部分を見いだして範囲を決め、概念化する﹂

︱︱"抽象化"という行為の本質と、その能力の高め方

106

アーキテクトが行う活動の中では、しばしば「複雑
な事象を抽象化して理解/整理する」
という行為
が必要になる。この“抽象化”の能力は、要求分
析/定義やシステム設計などの作業を遂行するう
えでの基礎ともなる、アーキテクトの必須能力の
1つだ。抽象化力は、日々のシステム開発作業の
中で自然と培われる部分もあるだろうが、アーキ
テクトたるもの、できれば意識的にこの能力を高
め、磨き上げていきたいところである。本企画で
は、抽象化という行為の本質を明らかにしたうえ
で、それがシステム開発の中で生かされる局面、
そして抽象化力の高め方などを紹介する。

開米 瑞浩

Mizuhiro Kaimai

アイデアクラフト代表

IT アーキテクト Vol.24

024_tokubetu_3.indd 106

09/07/12 16:36

「抽象的=わかりにくい」ではない
 本企画のテーマは「抽象化力」だが、その話に入る前に、
まずは次の一文をご覧いただきたい。
「後藤さんの説明って、いつも抽象的でわかりにくいん
だよね。もっと具体的に話してほしいなあ」
 日々の業務や生活の中で、一度や二度はこんな台詞を口
にしたり、耳にしたりしたことがあるのではないだろうか。このひ
のはわかりにくく、具体的なものはわかりやすい」
という認識が
一体何が描いてあるのかがさっぱりわからないような絵のことを
認識は今この瞬間にきれいさっぱりと忘れ去っていただきたい。
「抽象的=わかりにくい」などということはないからだ。それどころ
か、複雑なものを抽象化することで、むしろわかりやすくなるの
である。
 複雑な事象を抽象化する力、すなわち抽象化力は、要求

も、それを思いつかないみたいで、巨大なmain 関数を
作ったりしてますよ」
内海氏:
「そうか、共通の性質に注目して名前を付ける
ことができないんだな」
南雲氏:
「不思議なのは、ロジックを追いかけられるだ
けの論理性は持っているから、プログラム自体はちゃん
と動くものを書けるんですよ。そういうのを見ていると、
よくこういう複雑なロジックを考えられるなあと逆に感心
するんですが、仕事じゃ使えませんからね」
内海氏:
「目の前の1行1行を必死に追いかけてるのか
な? で、1つ1つのロジックはわかるけど、視野を広げて
それを抽象化することができないんだね」
筆者:
「そうですね。だから、見出しを付けるトレーニン
グが必要なんです」

分析/定義やシステム設計などの作業を遂行するうえで不

 以上は、某大企業で新入社員を対象にした研修につい

可欠であり、それらを主な責務とするアーキテクトには必須の

て打ち合わせした際の1シーンだ。内海さんと南雲さんは、人

能力だ。当たり前すぎて、普段使っているときには意識してい

材開発部門のマネジャーである。実はこの会話の中に、抽

ないかもしれないこの能力を、意識的に鍛えようというのが本

象化について考えるうえで重要なヒントがいくつか含まれている。

企画の主旨である。

それらについて、順に説明していこう。

「抽象化する」
とはどういうことなのか
 それでは、
「抽象化する」
とは、より具体的にはどういうことな
のだろうか。次の会話をご覧いただきたい。
筆者:
「要するに、この研修では文章で書かれた情報
を分割して、そこに適切な見出しを付けられるように
なってほしいんですよ」
内海氏:
「ああ、いますね。見出しを付けるのが下手な
人って。新入社員に日報を書かせると、区切りもなくだ
らだらと長文を書いてきたりしますからね」
南雲氏:
「そういう人にC言語でプログラムを書かせると、
極端な話、サブルーチンを作れないんですよね」

ヒント①

範囲を決める
 抽象化を理解するためのヒントその①は、
「範囲を決める」
ということである。南雲氏は、
「サブルーチン化できない」
という
症状を嘆いていたが、サブルーチン化するためには、
「この5
行をサブルーチン化する」
というように対象範囲を定めなけれ
ばならない。できる人はごく当たり前にやってしまうことなのだが、
この段階でつまづいてしまう人もわずかながら存在する。
 南雲氏が言っているのは、オブジェクト指向のクラス設計と
いうような高尚な事例ではなく、巨大とは言えmain 関数だけ
で作れるような短い手続き型プログラムの話だが、要は程度
の問題だ。情報量が増えると、それに伴って「範囲を決める」

IT アーキテクト Vol.24

024_tokubetu_3.indd 107

3

“抽象化力”
を磨け

「抽象絵画」
と呼ぶことの影響なのかもしれない。だが、その

の5 行とこっちの5 行はほぼ同じ処理だから、サブルー
チン化すれば簡単になるぞ』
と思うじゃないですか。で

アーキテクトの必須能力

横行しているようだ。これはもしかしたら、パッと見ただけでは

南雲氏:
「いるんですよ、本当に。普通なら、
『あっち

特別企画

と言に端的に現れているのだが、世間一般には「抽象的なも

内海氏:
「そこまでひどい人いるかなあ?」

107

09/07/12 16:36

ことの難しさは格段に増す。しかし、範囲を決めないことには

 目の前にあるものだけを必死に見ているだけでは、ほかの

抽象化はできない。抽象化できないということは、モデリングが

部分との共通性にはなかなか気づけない。広い視野を持った

できないということを意味する。ITエンジニアにとって、それは

うえで一部に注目するからこそ、共通性に気づくことができ、そ

致命的な事態だろう。

れを範囲として切り出せるのである。
 この視野というのは、なかなか自覚しにくいものであり、何が
重要なのかわかりづらいかもしれない。だが、これは筆者がこ

ヒント②

共通の性質を探す

こ数年「情報の読解力/図解力」について考え続け、企業

 では、範囲を決めるにはどうすればよいのだろうか。その基

 例えば、20 行ぐらいの文章を提示し、
「内容をわかりやすく

本は、内海氏が言うように、
「共通の性質に注目する」
ことで

図解せよ」
という課題を出したとする。図解するには、共通性

ある。
「あっちの5行とこっちの5行はほぼ同じ処理だ」
といった

を探して範囲を決めるという作業が必要になるのだが、これが

共通性は、範囲を決める有力な手掛かりとなる。

うまくできない人がいる。そういう人たちの「文章を読むときの意

研修を行っている中で強く問題を感じている部分だ。

 「なんだそれだけのことか、当たり前じゃないか」
と思われる

識の動き」を諸々の状況から推測すると、書かれていることの

かもしれないが、
「理屈は簡単、実践は難しい」のが抽象化

1 行 1 行を必死に読み取ろうとする
“顕微鏡的な視野”
になっ

の作業だ。例えば、
「ほぼ同じ」
と言ってもまったく同じである

ていると考えられるのだ。

ケースは少ない。プログラムであれば、指定したパラメータに

 顕微鏡は、狭い範囲を詳しく見るのには向いているが、全

よって処理の一部が異なるというのはよくあることだ。そういった

体像を見るのには向かない。1ミリ四方の視野しかない顕微

違いのある部分も含めて、大局的な視点で共通性を認識で

鏡で何かの写真を見ても、そこに写っているのが犬なのか猫

きて初めて、それを
「範囲」
として決められるのである。

なのかを判断することさえ難しいだろう。細かな情報を切り捨
て、全体を見たときに初めてわかることもあるのだ。そして、筆
者の経験上、自覚の有無は別として、視野を広げることが苦

ヒント③

視野を広げつつ、一部に注目する

手な人も確実に存在する。

 内海氏の発言にはもう1つ、ヒントがある。それは、
「視野を

マクロ、ミクロ、共通、範囲

広げる」
というものだ。

 ここまでの説明をいったんまとめておこう
(図 1)。抽象化に
必要なキーワードとしては、
「マクロ」、
「ミクロ」、
「共通」、

図1:マクロ、ミクロ、共通、範囲

「範囲」の4つが挙げられる。

多くの情報の中から抽象概念を見つけ出すために必要なキーワードとして、

クロ、
ミクロ、
共通、
範囲の4つがある。

ロ)
を注視し、その視点を少しずつずらしていく中で「共通」す

AXP
SH60J

全体
(マクロ)
を見る視野の広さを維持しつつ、

UH1
OSPKLU
PQQC
CIC
SPY1
MCIWSD
PQQR
16FF
MK50
AAM

108

 全体(マクロ)
を見る視野の広さを維持しつつ、部分(ミク

部分(ミクロ)
を注視し、
その視点を少しずつずら

る部分を見い出して「範囲」を確定する。そして、確定した範
囲の共通性を概念化することが抽象化だというわけだ。

していく中で
細部の違いにこだわらず、共通する部分を見い

「概念」には名前が必要

だして
「PQQx(xは可変)」
という範囲を1つの意味が
あるものとして確定し、
概念化する

 続いて、共通性を概念化することについて考えてみよう。
 イチゴ、リンゴ、ナシ、サクラという4 種類の植物をご存じだ
ろう。この4つは、いずれも同じ植物分類に属している。読者

IT アーキテクト Vol.24

024_tokubetu_3.indd 108

09/07/12 16:36

がその「共通の植物分類」に名前を付けるとしたら、何と付け
るだろうか
(図 2)。4 種類に共通する性質を考え、自分なりに
名前を付けてみていただきたい。

図2:概念には名前が必要
イチゴ、
リンゴ、
ナシ、
サクラはいずれもある共通の植物分類に属している。

し、
その
「共通の植物分類」
に名前を付けるとしたら、
どのような名前が良いだ
ろうか。4種に共通する性質を考えて、
自分なりの名前を付けてみよう

 この問題は、相当に難しいはずだ。筆者が回答者だった

どんな名前が
適切だろうか?

ら、イチゴ、リンゴ、ナシ、サクラの共通点など思いつかないの

○○科

で名前も考えつかない。思考が硬直して、お手上げになって
しまう。
イチゴ

 じゃあ、名前を付けずに放っておこう、というわけにもいかな

リンゴ

ナシ

サクラ

い。人間は「名前の付いていない概念は、概念として認識で
て考えることはもちろん、その概念を覚えることもできない。
「名前を付ける」
ということなのだ。範囲を決めて名前を付ける

ない
●名前の覚えやすさ、わかりやすさの基準は、前提条件に
よって変わる

 それでは、もう一度先ほどの問題を見てみよう。イチゴ、リン

名前を付けることの意味

ゴ、ナシ、サクラの植物分類は「バラ科」である。どれをとっても

 ここで、名前を付けることに関連して、筆者の経験を紹介し

「バラ」のイメージは浮かばないが、いずれも本当にバラ科に

よう。

属している。

 今から15年以上前の1992年から1995年のこと、当時はま

 今、読者が「イチゴとリンゴとナシとサクラはバラ科の植物」

だインターネットが普及しておらず、代わりに一部のPC ユー

と100 回暗唱して覚えたとする。そのうえで、1 年後に「バラ科

ザーの間では「パソコン通信」が使われていた。インフラが何

に属する植物をバラと名の付くもの以外で4 種類挙げてくださ

であれ、人が集えばそこには情報交換のニーズが生まれる。

い」
と問われたら、答えられる自信はあるだろうか。この問題を

パソコン通信の場でも、
「教えてください/教えます」
というコ

作った筆者でさえ、あまり自信はない。もともと植物に詳しい方

ミュニケーションが広がっていたのだ。

以外は、似たようなものだろう。これは、
「バラ科」
という名前

 筆者も、だれかに質問したり、質問に答えたりといったことを

が一般人には覚えやすくないからである。しかし、植物に関す

頻繁にやっていたが、答えるときに気をつけていたのが、情報

る勉強をしている人にとっては少々事情が違ってくる。

に「名前を付ける」
ということである。どんなに複雑な情報でも、

 生物は、進化の過程で枝分かれして多様化してきたが、

「範囲を決めて、適切な名前を付ける」
ことを意識すると、非

枝同士の位置関係が近いものはやはり似ている部分が多い。

常に伝わりやすくなるケースが多かったのだ。

それらのうち、イチゴやリンゴが属するグループの代表種が「バ

 そうした中で、筆者は「名前を付けるというのは、自分で

ラ」である。
「バラ科」
という名前を使えば、そうした関係性が

情報に意味づけをすること」だと理解した。ここで特に重要な

わかるわけだ。したがって、例えば「生物の進化系統樹を勉

のは、
「自分で」
というところである。他人に正しい答えを教え

強したいとき」
という前提条件があれば、バラ科という名前は

てもらうことに意味はない。自分自身で情報に「意味」を見い

わかりやすく、覚えやすい適切な名前だということになる。

だし、それを「名前」で表現することが大事なのだ。このよう

 以上をまとめると、概念化において重要なポイントは次の3

な意識/習慣を持っていなければ、抽象化はできない。そ

つだと考えられる。

れはすなわち、
「他人にわかりやすく説明できない」
ことであり、

●概念には名前を付けなければならない

IT エンジニアならば「モデリング、設計ができない」
ことを意

●名前は覚えやすく、意味がわかりやすいものでなければなら

味する。

IT アーキテクト Vol.24

024_tokubetu_3.indd 109

“抽象化力”
を磨け

と、新しい概念を作ることができる。範囲を決めるのは、名前
を付けるための準備のようなものだ。

3

アーキテクトの必須能力

 こうしたことからわかるように、実は「概念化する」
というのは、

特別企画

きない」生き物なのである。概念に名前がないと、それを使っ

109

09/07/12 16:36

調べて、考えろ!

自分で調べることの効果

 筆者の本業は、読解力や図解力を強化するための教育

りでは、
「自分の知識の限界」を超えられない。
「甘酸っぱい

研修業務である。受講生のほとんどはITエンジニアであり、

果物科」はだれでも思いつく名前であり、新しい情報を人に

研修では、上で紹介したような「共通性を探して範囲を決め、

伝える効果はないだろう。そこで、新しい手掛かりを自分で調

名前を付ける」
といった練習問題を出している。そうした企業

べる
「リサーチ型」
も重要になってくる。

研修の場で、先ほどのバラ科の問題を出した場合、受講生

 出題文にある植物の情報を調べると、例えば「どれも花び

の反応としては次の3種類が考えられる。

らが5 枚である」
ということに気づくかもしれない※ 1。サクラの花

①自分の思いつく範囲で、適当な名前を付けてしまう
(コジツ

びらが5 枚なのは有名だが、イチゴ、リンゴ、ナシも同様だとい

ケ型)
②出題文に登場する植物に関する情報を調べに行く
(リサー
チ型)
③講師が「考え方」や「判断基準」
を解説してくれるのを待つ
(オシエテ型)

 コジツケの精神が必要だとは言っても、いつもコジツケばか

うのはあまり知られていない。調べることによってそれに気づけ
ば、
「5枚花弁科」
といった名前を思いつける可能性があるの
だ。
 この名前を付けると、一見何の関係もなさそうな4種類の植
物に「花びらが 5 枚である」
という共通点があることがわかり、

 これらのうち、最も望ましいのは①と②の考え方を併せ持つ

見た人に「ひょっとして、この4つは近い種類なのか?」
と思わせ

ことだ。わからないことを調べるリサーチ型が望ましいということ

る効果がある※ 2。これは、
「甘酸っぱい果物科」にはなかった

に、異を唱える方は少ないだろう。しかし、コジツケ型を良しと

もので、リサーチ型ならではの成果だと言ってよいだろう。

するのには抵抗のある方がおられるかもしれない。以下、それ

 繰り返すが、重要なのはコジツケ型とリサーチ型を共存さ

ぞれの考え方がなぜ必要なのかを説明しよう。

せることだ。コジツケだけでは自分の知識の限界を超えられな
いし、リサーチだけでは他人の知識の限界を超えられない。

考えることの重要性

両者をほどよく共存させたときに、新しい発想が生まれ、最適

 コジツケ型の人からは、
「甘酸っぱい果物科」
といった、植

解を導き出せる確率が高くなるのである。

物学者が聞いたら失笑しそうな名前が出てくる可能性がある。
しかし、学者には笑われたとしても、1 年後に「甘酸っぱい果

“オシエテ君”ではダメ

物科にはどんな果物があったっけ?」
と聞かれたら、
「バラ科」

 問題を前にしたとき、いちばんいけないのは、だれかから正

よりは思い出しやすそうだ。

しい答えを教わろうとすることである。
「オシエテ型」の
“オシエテ

 コジツケという言葉には、
「合理性のない勝手な理屈をつ

君”
は、何かにつけて正解を教えてもらおうとする。リサーチ型

ける」
というイメージがあるので、やってはいけない行為だと思

の人は、手掛かりは探しても最後は自分で判断するのに対し

いがちだが、コジツケが必要なときは確実にある。コジツケと言

て、オシエテ君は「はい、こういうパターンの問題が出たときは、

われようが何だろうが、自分が見いだした共通性を短い名前

これこれこういう手順で考えますよ。この解法、覚えておくよう

で表現するという姿勢が、抽象化力の向上には欠かせない


!」
といった具合に明快で確定された「正しいやり方」
を講師

のだ。

が教えてくれると思っている。企業研修をしていると、毎回、受

 そもそも、抽象化が必要なときというのは、ある程度情報量

講生の1割程度はこういうタイプがいるものだ。
もし、読者の周

が増えて煩雑になってきたにもかかわらず、それを単純化する

りにオシエテ型の部下や後輩がいたら、
「現実には、だれも答

ためのフレームワークがないときである。フレームワークがないと
きには、だれかが用意してくれるのを待つのではなく、自分で
考えよう。それには、
「コジツケであっても、あえてやる」
という精
神が必要なのだ。

110

※1 ここから、すぐに
「バラ科」
という
“正解”
にたどり着くかもしれないが、ここでは
「自
分で名前を考える」
ために
「バラ科」
は候補から外すことにする。
※ 2 現在主流のバラの園芸種は八重咲きだが、野生種の花びらは5 枚であり、こ
れはバラ科の植物の特徴の1つである。

IT アーキテクト Vol.24

024_tokubetu_3.indd 110

09/07/12 16:36

えを持っていない問題に取り組む機会が年を追うごとに増える
のだから、自分で考えなければいけないんだよ」
と諭してあげ
てほしい※3。

理屈は単純だが、実践は難しい
 ここまでに、抽象化力のベースとなる思考スタイルについて
説明した。理屈はどれも単純なものなので、
「なんだ、そんなこ
とならだれだって普通にやっていることだろう」
と思われても不

藤原氏:
「営業 2 課の案件管理ボードなのですが、営
業 1 課の鈴木さんも見られるようにしておいてほしいん
ですよ」
三上氏:
「了解しました」
藤原氏:
「そうそう、もう1 つあった。佐藤さんも2 課の
ボードを見られるようにしておいてください」
三上氏:
「佐藤さんも営業1課の人ですよね。了解しま
した。ところで、それは
『……
(質問)
……』
ですか?」

的に限界まで追求してほしいのだ。これが実践できていないの

●この会社には、営業1課と2課がある

が、抽象化力が伸びない大きな原因なのである。

●営業 2 課は、社内のグループウェアを「案件管理」のため
に使っており、その中には「案件管理ボード」
と呼ばれるメ
ニューがある

筋力があればだれでも1回はできるはずだ。しかし、それを100
回続けてできるようになるには、長期間のトレーニングを積まな
ければならない。
 抽象化力も、これと同じ種類の力なのである。理屈が難し

●営業2課の案件管理ボードは、基本的には2課のメンバー
しか見られない
●しかし、営業1課の鈴木さんと佐藤さんだけは見られるように
しようとしている

いのなら、それを理解すれば使えるようになるだろうし、理解す

 さて、担当SEである三上氏は、依頼主である藤原氏に何

るには教え方のうまい先生に教わるのが最も効果的だ。
「難

か質問をしたようだ。もし読者が三上氏ならば、どんな質問を

解な手法を駆使する能力」は、良い先生に教わるとあっという

するだろうか。この先を読み進める前に、少し考えてみていた

間に伸びることも珍しくない。だが、抽象化に「難解な手法」

だきたい。

は不要だ。抽象化力はある種の「思考の筋力」であり、長期
間の地道なトレーニングによってしか向上しないと考えてほしい。

ごく当たり前の質問

 腕立て伏せを100回できるようになるには、とにかく継続的に

 こうした依頼を受け、いちばんやってはいけないのは「了解し

そのための筋力トレーニングをすることだ。抽象化力も、それと

ました。それでは早速やります」
と何も聞かずに作業を始めてし

同じ。正しいやり方を教えてくれる良い先生を探すのではなく、

まうことだ。ここで生きる抽象化のキーワードは、
「共通性」

まず実践し、それを継続することが重要なのである。

「意味づけ」である。特に、今回の「1 課の人間である2 人の

“抽象化力”
を磨け

 筆者は、この話をよく筋力トレーニングに例えて説明してい
る。
「腕立て伏せ」は技術的には難しくないので、最低限の

3

アーキテクトの必須能力

 以上の会話から、次のような情報が読み取れる。

特別企画

思議はない。だが、その単純なことを、とことん執念深く、徹底

人間に2 課の情報を見せたい」のようにはっきりと目立つ共通

抽象化の実践
 それでは、日々の業務のどのような場面で、抽象化を実践
できるのだろうか。ここからは、ケース・スタディを基に抽象化の
実践例を見ていこう。
 以下に示すのは、あるシステムについて要望を出している
ユーザー部門の藤原氏と担当SE三上氏の会話である。
※ 3 もっとも、オシエテ君になる原因は初等教育からの環境にあるケースが多いの
で、大人になってから言って聞かせても変わることはあまり期待できないのだが。

性が出てきたときは、必ずその意味を問わなければならない。
したがって、作業に入る前に、少なくとも次のような質問が必
要だろう。
三上氏:
「ところで、それは何のためですか? 鈴木さん
と佐藤さんに対して特別に閲覧を許可したいのはなぜ
でしょうか」
 こう聞けば、何かしら答えが返ってくるはずである。それは例
えば、次のような回答かもしれない。

IT アーキテクト Vol.24

024_tokubetu_3.indd 111

111

09/07/12 16:36

「特設方式」
と呼ぶ。

藤原氏:
「実はこれから、彼ら2 人で営業部門全体を
バックアップするスペシャル・チームを作る予定なんです。
だから、1課/2課の情報を両方とも閲覧できる権限を

 いずれの方式でも、両氏の「営業 1 課所属」
という属性を
変更する必要はない。特設方式の場合は新しい権限セットを
定義するので、例えば「営業2課の案件管理は見られるが予

与えたいんですよ。正規のチーム発足はまだ先なんで

定表は見られない」
といった制御が可能なのに対して、両属

すが、対応できるところから始めておきたいんです」

方式の場合はそれができない。その代わり、両属方式の場合

 これはSEにとってはごく当たり前の質問であり、読者も日常

は新たに権限セットを作る手間がかからない。

的にやっているはずである。つまり、共通性を発見したらその

 現実に、両方式のどちらを選択するべきかを判断するには、

意味を問うことが「抽象化」の根幹であり、それは特別な作

ほかにも情報が必要だが、それは本記事の範囲ではない。こ

業ではなく、どこででも発生しうるものなのである 。

こで覚えておいてほしいのは、次のポイントだ。

※4

抽象概念は設計に反映される。したがって、抽象化力

抽象概念は、設計に反映される

は設計力の大きな柱である。

 藤原氏からの回答によって新しい手掛かりを手にした三上
氏は、依頼を実現する方法をいくつか考えた。そのうちの2つ

 この例で言えば、
「スペシャル・チーム」は、その実体がな

を図3に示す。

い段階では1つの抽象概念であり、その概念を持っていなけ

 1つは、鈴木氏/佐藤氏をグループウェアのアクセス権管

れば新しい権限セットを定義するという案は出てこないだろう。

理体系上、営業 2 課にも所属させるという方法である。これを

少しの違いが大違い

「両属方式」
と呼ぶことにする。
 もう1つは、
「スペシャル・チーム」
という新しいアクセス権限

 もし、藤原氏の回答が次のようなものだったらどうだろうか。

セットを作り、2 人をそちらに所属させるという方法だ。これを
※ 4 言いかえれば、抽象化ができなければ SE の仕事はほぼできないということでも
ある。

藤原氏:
「実は、彼ら2人には1課からも2課からもいろ
いろな相談が持ち込まれてくるんですよ。なので、この

図3:依頼を実現する2つの方法
現在、営業1課に所属する鈴木氏、佐藤氏に対して、営業2課の案件管理表へのアクセス権を与える方法には次の2つが考えられる。1つは、
両氏を営業2課にも所属させる
「両属方式」
であり、
もう1つは
「スペシャル・チーム」
というアクセス権限セットを新設し、
そこに所属させる
「特設方
式」
である。
グループウェア機能

アクセス権限セット

営業1課予定表

営業1課所属

個人

田中
営業1課案件管理
近藤
営業2課予定表

営業2課所属
鈴木

営業2課案件管理

スペシャル・チーム
佐藤

etc
両属方式:

112

特設方式:

IT アーキテクト Vol.24

024_tokubetu_3.indd 112

09/07/12 16:36

際彼らには、営業の前面に出るよりもバックアップに
専念してもらおうと思っているんです。それには、両方

図4:抽象概念は、具体的な情報を引き出す手段
抽象概念を使って質問すると、具体的な情報を引き出しやすくなる。
したがっ
て、抽象化力はヒアリングの成否を大きく左右すると言える。

の課の情報を見られるようにしておくと便利なんです」
抽象概念

スペシャル・チーム

 この回答では、
「スペシャル・チーム」
という表現は出てこな

具体的な情報

い。そのため、
「スペシャル・チーム」を使った特設方式の案
は思い浮かびにくいだろう。
 しかし、藤原氏の説明がどちらであったとしても、鈴木氏と
佐藤氏が組織の中で果たす役割はほぼ同じだ。それにもか

相談が
持ち込まれる

バックアップに
専念させたい

部署自体を独立
させる案がある

どうかによって、設計の選択肢が変わってしまうのでは困る。

すでに聞いていた情報

特別企画

かわらず、
「スペシャル・チーム」
という表現を相手が使ったか
新たに聞き出せた情報

アーキテクトの必須能力

3

 これを避けるには、藤原氏の回答を基に2 人の共通性を
抽象化し、それが正しいかどうかを確認する質問を投げかける

三上氏:
「お2 人は、営業部の知恵袋みたいな方なん
ですね。それでバックアップに専念されるとは、何だか
スペシャル・チームという感じですね」
藤原氏:
「そうそう、まさにスペシャル・チームなんですよ。
実際、そういう部署として独立させるという案もあります。
正式にはまだどうなるかわかりませんが、役割としてはそ
うイメージしていただいて結構です」

る」
という情報を引き出したのはその一例だ。
 抽象概念は、一般にいくつかの具体的な情報の集約(要
約、まとめ)
である。つまり、ある抽象概念Xに対して具体的な
情報 a、b、c……があるとき、a、b、c……以下のすべてをま
とめたものがXであるという関係を持つ。
 ところが、SEが「どんな要望がありますか?」
という御用聞き
的なヒアリングしかしていないと、要求や、要求の背景にある
事情のすべてを漏れなく聞き取るのは難しい。答える側も、そ
のときに気づいたことしか答えられないので、
“気づきの限界”

 「スペシャル・チーム」
という抽象概念を三上氏の側からぶ

があるわけだ。

つけた結果、
「まさしくそのとおり」
という反応が得られた。これ

 具体的な情報がいくつか集まったとき、そこから推測できる

で三上氏は、藤原氏の最初の回答だけではわからなかった

抽象概念をうまく使うと、この
“気づきの限界”
を超えられる。

重要な情報を聞き出せたことになる。これにより、設計の選択

三上氏が、
「スペシャル・チーム」
という抽象概念で「部署自

肢は広がり、選択肢から適切なものを選ぶ際の判断もしやす

体、独立させる案もある」
という情報を引き出したように、人の

くなって良いことづくめだ。

脳には「具体的な情報をまとめた抽象概念を得ると、今度は

 こうした
“良いことづくめ”
を引き出す質問をするには、
「具体

その抽象概念に当てはまる具体的な情報を探しやすくなる」

的な情報の中から共通性を見つけ、それを抽象化し、名前

いう性質があるのだ。

“抽象化力”
を磨け

ようにする
(以下参照)。

を付けて概念化する」
という作業が不可欠なのである。

抽象概念を使って
具体的な情報を引き出す

抽象化力を強化するための
6つのポイント
 ここまでに説明した内容から、抽象化力を高めるうえで重要

 ここで、図4をご覧いただきたい。抽象概念を使って質問す

なポイントは、次の6つにまとめられる。

ると、具体的な情報を引き出しやすい。三上氏が「スペシャ

●マクロ的視野を持つ:全体の文脈を忘れて、細部にのめ

ル・チーム」
という抽象概念で「部署自体、独立させる案もあ

り込んではいけない

IT アーキテクト Vol.24

024_tokubetu_3.indd 113

113

09/07/12 16:36

●ミクロへの集中は意識的に行う:ぼんやりと全体を眺める
のではなく、1つ1つの文の意味をしっかりと確認することも
必要である
●共通性を探す:異なる場所に共通のものが出てきたら、そ
れは抽象概念として切り出す候補となる
●範囲を決める:抽象概念を切り出すには、まず範囲を確定
しなければならない
●意味づけを行う:切り出した抽象概念について、自分で意

図5:座標軸を範囲決定の手掛かりにする
甘みと酸味は果物の味の2本柱である。
そこで、甘みと酸味の強弱を果物の
種類別に順序付けて見ると、以下のようになる。
メロン

サクランボ

モモ

イチゴ

バナナ

ナシ

グレープフルーツ

スイカ

リンゴ

ミカン
オレンジ

味を考える
●名前を付ける:抽象概念に対し、意味を反映した名前を
付ける

甘み中心

酸味中心
何らかの座標軸を使って順序付けをすると、
範囲決定の手掛かりが見えてくることがある。

 さらに補足として、以下に4つのポイントを挙げておこう。
●座標軸を考える
 範囲を決めると言っても、それが難しいケースもある。そんなと

 例えば、システム開発の世界には、○○メソドロジーと名付

きは、複数の情報を1つ、ないしは2つの座標軸に当てはめて

けられた方法論が多数存在しており、それぞれが開発作業

順序付けると、範囲を決めやすくなることがある。

のプロセスや成果物を詳細に規定している。だが、それらのメ

 例えば、図5は果物を
「甘み中心 Vs. 酸味中心」の座標

ソドロジーにより、現場で起きるすべての事象に対応できるわけ

軸で整理した例である。このように、何らかの基準で順序付

ではない。
“標準”
では対応できない例外は、必ず発生する

けすると、それを手掛かりにして範囲を決められることがある。

のだ。そうしたときでも定型フォーマットの適用に固執しているよ

 何を座標軸にとればよいのか、見当がつかない場合には、

うでは、いつまでたっても抽象化力は向上しないだろう。

まず時間軸が使えないかどうかを考えてみるとよいだろう。特に、

●人に説明する練習を積む

ビジネス・シーンにおける抽象化を考えるときには、時間軸が

 筆者の抽象化力が大きく向上したのは、パソコン通信でた

有力な手掛かりになることが多い。

くさんの人の質問に答えていたころである。
「自分が理解して

●関連する業務知識は地道に勉強せよ

いる内容を他人に説明するには、抽象概念が非常に役に立

 先のケース・スタディで、三上氏は「スペシャル・チーム」

つ」
というのは、それこそ他人に説明する経験を積まないと実感

いう表現で藤原氏から情報を引き出したが、それができたの

としてわからないものだ。ありとあらゆる機会をとらえて、人に説

は三上氏に「スペシャル・チーム」
という言葉を使えるだけのボ

明する練習を積んでほしい。それは、抽象化力を鍛えるだけで

キャブラリがあったからだ。ボキャブラリが乏しいと、抽象概念

なく、仕事を円滑に進めるのに役立つコミュニケーション力を

をうまく表せる言葉を見つけられない。言葉を知らないことは絶

高めることにもつながるはずだ。

対的な壁となるので、特に業務に関連する知識は地道に勉
強して身に付けるべきである。

114

*  *  *

●定型フォーマットに頼りすぎるな

 冒頭でも述べたように、複雑な情報から共通性を見いだし、

 ここで言う定型フォーマットとは、組織内で用いられている何

概念化して名前を付ける抽象化力は、アーキテクトにとって

らかの手順や考え方などのことを指す。おそらく、読者の会社

必須の能力である。対象が複雑になればなるほど抽象化は

にも、さまざまな定型フォーマットがあることだろう。確かに、作

難しくなるが、それによって得られる効果も大きい。抽象化力を

業を標準化したり、管理しやすくしたりするために定型フォー

鍛えるチャンスは、日々の業務の至るところに転がっている。本

マットは欠かせない。しかし、それに頼りすぎると、抽象概念をと

稿で紹介したポイントを意識しながら継続的に実践を重ね、そ

ことん考える機会を逸することになる。

の力をさらに高めていただきたい。

IT アーキテクト Vol.24

024_tokubetu_3.indd 114

09/07/12 16:36

マルチ

パラダイ
言語
特別企画4

現れた





クラ
!?
va”
a
J



Scala
関数型言語とオブジェクト指向言語の特性を併せ持つScala。
登 場 の 背 景 、メ リ ッ ト 、そ し て 並 列 プ ロ グ ラ ム / ク ラ ウ ド ・ ア プ リ /
DSLでの使いどころを知る
読者は「Scala」という言語をご存じだろう
か。これは、関数型言語とオブジェクト指向
言語の特徴を併せ持つ、マルチパラダイム
の言語だ。近年の CPU のマルチコア化の
進展やクラウド・コンピューティング環境にお
ける大量データ処理への対応などから並列
処理に適したプログラミング言語の必要性
が高まっており、なかでも注目されているの
が Scalaである。現在、企業システム開発
で広く使われているJava の上で動作するこ
とから、これを“次世代プログラミング言語
の本命”と見る向きもあるようだ。本企画で
は、Scalaが注目を集める理由や Scala の
特徴、メリット、現状の課題などを説明した
うえで、今日のシステム開発におけるScala
の使いどころを紹介する。

浅海 智晴

Tomoharu Asami

匠Labフェロー/edge2.cc/日本Javaユーザグループ 副会長

116

Scala.indd 116

IT アーキテクト Vol.24

09/07/12 20:17

Scalaとは
どのような言語か

グ言語については、Odersky 教授ら

レスに使えるといった特徴もあり、プロ

によるScala の解説書『Programmi

グラミング言語としての直系の先祖は

ng in Scala』
(発行:Artima)
で詳し

Java だと考えられる。こうしたことか

特徴とメリット、
そして現状の課題を知る

く解説されている。ポイントを図 1に簡

ら、Scalaは
“現代版Java”
などと呼ば

単にまとめたので、まずはこの図に沿

れるのである。

ってScalaの特徴を説明しよう。

関数型言語としての機能

 スイス連邦工科大学ローザンヌ校
いる開発チームによって開発されてい

オブジェクト指向言語
としての側面

目を移してみよう。Scalaでは、ML、

るScalaは、オブジェクト指向言語と関

 Scala の文法は、オブジェクト指向

SML、Ocaml、F#、Haskellなどの

数型言語※ 1 の特徴を併せ持ったマル

言語であるJavaおよびC#から派生し

関数型言語からさまざまな要素を取り

チパラダイムの言語だ。純粋なオブジ

たものだ 。Java/C#と同様に静的

込んでいる。これにより、
「不変オブジ

ェクト指向言語であると同時に、本格

型付言語としての性質を持ち、プログ

ェクトの List」や「クロージャ」、
「高階

的な関数型演算が可能な関数型言

ラムの安全性/保守性は高い。ま

関数」、
「遅延評価」、
「モナド」
といっ

語でもあり、非常に高度なレベルで双

た、自明な個所では明示的な型の宣

た関数型言語の機能がすべて利用

方の性質が統合されている。

言を省略できる型推論機構を備えて

可能になっている。

(EPFL)
のMartin Odersky教授が率

※2

 Scalaでは、
「小さな問題の解決か

おり、静的型付言語としてのチェック

ら大規模システムの開発まで、同一

機能を維持しつつも、プログラミング

の概念/プログラミング言語で記述

の煩雑さやコードの冗長さを解消でき

する」
ことを目指しており、
「Scalable

るようになっている※3。

Language
(拡張性のある言語)

とい

 なお、ScalaはJVM 上で動作し、

う言葉を名前の由来としている。Sca

Javaとの間での相互呼び出しが可能

laの機能と、ルーツとなるプログラミン

だ。Javaのクラス・ライブラリをシーム

 次に、関数型言語としての機能に

※1 数学的な形式言語である
「ラムダ計算」
をベ
ースにした言語のこと。数学のバックボーンを持つ
プログラミング言語の総称だと考えればよいだろう。
※2 JavaやC#にはC/C++が大きな影響を与え
ているので、間接的にはC/C++もScala の文法
に影響を与えていると言えるだろう。
※3 型推論機構は、C#ではC# 3.0からサポー
トされているが、Javaではまだサポートされていな
い。

図1:Scalaのルーツとなった言語と、
それらの言語から受け継いだ特徴
C

C++

統一オブジェクト・
モデル

Ocaml

Ruby

オブジェクト指向

ML
SML

Smalltalk

Java

Algol

C#

Simula
普遍ネスティング

関数型

F#

Beta
gbeta

Haskell
Ruby

統一アクセス

Effiel

アクタ基盤
並列ライブラリ

Erlang

Python
Pizza
Nice
Multi-Java

オブジェクト指向&
関数型

Scala

Smalltalk
Iswin

Ocaml
F#
PLT-Scheme

Abstract Type

trait

スケーラビリティ

Lisp
C++

Extractor

IT アーキテクト Vol.24

Scala.indd 117

117

09/07/12 20:17

オブジェクト指向と
関数型の融合

セス
(Uniform Access)」の機能は、

 先に、
「Scalaは純粋なオブジェク

Effielから取り入れられた。

体化する型を抽象クラスで宣言できる
「抽象型
(Abstract Type)
」、mix-in

●アクタ基盤並列ライブラリ

に使用できる
「トレイツ
(Trait)」、パタ

ト指向言語であると同時に、本格的

 Scalaには、マルチスレッド・プログ

ーン・マッチングでマッチした値を取り

な関数型演算が可能な関数型言語

ラミング
(並列プログラミング)
におい

出すためのオブジェクトである
「エクス

でもある」
と述べた。言いかえると、オ

て、複数のスレッド間でデータや制御

トラクタ
(Extractor)」
を挙げている。

ブジェクト指向言語が主軸であり、関

を受け渡す際の並列処理メカニズム

これらの機能にもヒントになった既存

数型言語は十分な実用性を持ってそ

として「アクタ基 盤 並 列ライブラリ

言語があるのかもしれないが、実用性

(Actor-based Concurrency Libra

まで含めて考えると、Scalaがパイオ

 オブジェクト指向言語と関数型言

ry)」
が備わっている。このメカニズム

ニア的な存在だと言ってよいだろう。

語の融合の仕方には、さまざまなアプ

は、関数型言語であるErlangから取

 Scalaでは、既存言語を集大成す

ローチが考えられる。Scalaでは、融

り入れられた。

るだけでなく新しい試みも多く取り入れ

合にあたってSmalltalk、Python、Pi

●スケーラビリティの実現

られており、それらがうまく成功している

zza、Nice、Multi-Java、Ocaml、

 その名前が「Scalable Langua

というのが筆者の受ける印象である。

F#、PLT-Schemeといった言語を参

ge」に由来することからもわかるよう

考にしている。

に、Scalaではスケーラビリティ
(Scal

こに組み込まれているということだ。

ability:拡張性)
を重要視している。

Scalaのメリットを表す
4つのキーワード

その他の拡張機能

オブジェクト指向言語と関数型言語を

 Scalaでは、オブジェクト指向言語

組み合わせ、さらに他の言語からさま

 『Programming in Scala』
では、

をベースに関数型言語の機能を組み

ざまなアイデアを取り込んで、高度な

Scalaのメリットを表すキーワードとして

込み、さらに拡張も施されている。以

スケーラビリティの実現を図っている。

「互換性(Compatibility)」、
「簡明

下に、その拡張機能を見ていこう。

 例えば、中置記法の演算子を関数

(Concise)」、
「ハイレベル
(High-

●統一オブジェクト・モデル

として扱ったり、関数リテラルをパラメ

level)」、
「静的型付け
(Static Typi

 「統一オブジェクト・モデル
(Uniform

ータとして扱ったりするアイデアはSm

ng)
」の4つが挙げられている。それぞ

Object Model)

とは、データをすべて

alltalkとIswinから、DSL
(Domain

れについて、簡単に説明しておこう。

オブジェクトで扱う機能だ。Javaでは、

Specific Language)
を構築するため

●互換性

intやfloatといった基本的な型はクラス

の柔軟性の高い文法はSmalltalk/

 先述のように、ScalaはJVM上で動


(オブジェクト)
ではなく、データ型とし

Lispから、演算子のテンプレートやオ

作し、Javaとの相互呼び出しが可能

て扱う※ 4。そのため、データ型を
“特別

ーバーローディングについてはC++か

である。つまり、Javaが持つ膨大な資

扱い”
するためのコードを書く必要があ

らといった具合だ。

産を受け継ぐことができるのだ。これ

るのだが、Scalaではデータをすべてオ

 Scalaが実現するスケーラビリティ

が、今日の実用言語として大きなメリッ

ブジェクトとして扱い、そうしたコードを

のうち、特に重要なのは、型だけでな

トであることは言うまでもないだろう。

書く手間を軽減している※5。

く、制御構造を追加できるという点だ。

●簡明

●普遍ネスティング

型の追加はオブジェクト指向言語の

 Scalaでは、簡明にプログラミング

 「普遍ネスティング
(Universal Ne

技術によるものだが、制御構造の追

sting)」
とは、パッケージやクラス、関

加は高階関数や遅延評価といった関

数などをネストして定義する機能であ

数型言語の技術によるものである。

る。これは、Algolや Simula、Beta、

118

Scala.indd 118

gbetaといったプログラミング言語から

新しい機能への取り組み

取り入れられた。

 ここまでに紹介したもののほかに

●統一アクセス

も、Scala にはさまざまな機能が用意

 Scalaでは、メソッドやフィールドに

されている※6。
『Programming in Sc

アクセスするためのインタフェースを統

ala』
では、それらのうち革新的な機能

一することができる。この「統一アク

の例として、子孫の具象クラスで具

※ 4 その意味で、Javaは純粋なオブジェクト指
向言語ではなく、手続き型とオブジェクト指向のハ
イブリッド言語だと言える。
※ 5 同様にしてデータをオブジェクトとして扱って
いる言語には、SmalltalkやRubyなどがある。
※ 6 例えば、パターン・マッチング処理に適した
クラスである
「ケース・クラス
(Case Class)

や条
件が満たされた場合に自動的にオブジェクトの変
換処理を行う
「暗黙変換(Implicit Conversi
on)」、関数のパラメータを暗黙に定義する
「暗黙
パラメータ
(Implicit Parameter)」、BNF
(Back
us Naur Form)
の記述からパーサを生成するパー
サ・ジェネレータ機能「パーサ・コンビネータ
(Parser
Combinator)

など。

IT アーキテクト Vol.24

09/07/12 20:17

特別企画4

マルチパラダイム言語

できるようさまざまな工夫が凝らされて

やNetBeansなどのIDEを用いるのが

いる。先に紹介した型推論機構も、

定石となっている。ご存じのとおり、

Scala
ハードウェア性能の
向上による可能性の広がり

簡明さを実現する機能の1つだ。その

現在の IDEはテキスト・エディタの範

ほかにも、セミコロンや括弧などの省

疇を超え、高度な入力補完機能やリ

 プログラミング言語の仕様は、ハー

略が一部で可能となっている。

ファクタリング機能など、文法を解釈

ドウェアの性能に大きな影響を受け

●ハイレベル

しながら動作する機能を備える。Sca

る。いくら便利なプログラミング言語を

 ここで言うハイレベルとは、抽象度

laにもEclipseやNetBeans用のプラ

作っても、実行時に十分な性能が得

の高いレベルで処理を記述できること

グインが提供されているのだが、サポ

られなければ
“絵に描いた餅”
になって

を意味する。Scalaでは、関数リテラ

ート・レベルはまだ低い。

しまうからだ。そのため、プログラミン

ルや遅延評価といった関数型言語の

 そのほか、参考図書が少ない、プ

グ言語仕様には、その登場時期のハ

機能により、ハイレベルなプログラミ

ログラマー人口が少ないといった点

ードウェアの性能が許す範囲で機能

ングを可能にしている。

は、Scalaが知られるようになってから

が盛り込まれる。

●静的型付け

まだ日が浅いことを考えると、やむをえ

 例えば、C 言語が広く使われるよう

 Scalaでは、静的型付けによって

ないだろう。プログラミング言語そのも

になったのは1980年代半ばからだが、

型の妥当性検証や、安全なリファク

のの開発体制が大学の研究室に依

当時のハードウェア性能に合わせて、

タリングが可能なほか、静的な型宣言

存しているという点は、筆者自身は不

マクロ・アセンブラ的な機能が構造化

が仕様を明確にしている。

現状のScalaの課題

安を感じていないのだが、リスクの 1

プログラミングの文法で実現されてい

つであることは確かなので一応挙げて

た。それから10年ほどがたち、Javaが

みた。

登場したのが1995年のことだ。

 こうして挙げてみると、やはりScala

 当時、C 言語とオブジェクト指向言

 ここまでお読みいただき、Scalaが

普及の最大のネックとなりそうな要因

語の中間に位置する言語としてC++

非常に優れたプログラミング言語であ

は、言語仕様の複雑さである。使い

が存在したが、性能的に問題はない

ることがおわかりいただけただろう。た

始めるにはある程度のスキルが必要

ものの、オブジェクト指向言語として

だし、そんなScalaにも問題がないわ

なため、ハードルが高いのだ。それ以

は使いにくい面があった。そこに、ガ

けではない。主な問題点としては、次

外の問題に関しては、どれもプログラ

ーベジ・コレクタを実装した本格的な

のようなことが挙げられる。

ミング言語の登場初期には必ず見ら

オブジェクト指向言語としてJavaが登

●言語仕様が複雑である

れる現象であり、普及が進めば自然と

場したわけである※7。

● IDE(Integrated Development

解決されるものである。

Environment:統合開発環境)

サポートが弱い
●参考図書が少ない
●プログラマー人口が少ない

 Javaは動的にメソッドを検索しなが
ら動作するうえ、ガーベジ・コレクタも

なぜ今、
Scalaなのか

“重たい”
仕組みである。そのため、C
言語のような手続き型言語と比較す
ると、実行速度はかなり遅く、メモリの

必要とされる
時代背景を探る

ス/オブジェクトによるカプセル化や

 これらのうち、最大の問題は言語仕

 2003 年に登場したScalaは、比

ミング、ポリモーフィズムといった機能

様が複雑だということだろう。仕様を解

較的新しい言語に分類される。とは

により、プログラミングの生産性が非

説した
『Programming in Scala』
は、

言え、登場からはすでに6 年が経過し

常に高いというメリットを持つ。

●プログラミング言語そのものの開発
体制が大学の研究室に依存して
いる

消 費 量も多い。だが 一 方で、クラ
情報隠蔽、継承による差分プログラ

本文が 700 ページ弱というボリューム

ている。それがなぜ、今になって注目

  一 長 一 短に見えた J a v a だが 、

だ。Scalaは、複数のプログラミング言

を集めているのだろうか。これは、時

1995年以降のハードウェア性能を持

語の機能を備えているので、どうしても

代のニーズが Scala に追いついてき

ってすれば、実行時の動作が遅いと

言語仕様が複雑になってしまうのだ。

たからにほかならないと筆者は考える。

 また、ScalaのベースでもあるJava

ここでは、Scalaが注目されるに至っ

の場合、プログラミングにはEclipse

た時代背景を見ていこう。

※ 7 Javaは、業務アプリケーションの世界で初
めて実用化された、本格的なオブジェクト指向言
語である。

IT アーキテクト Vol.24

Scala.indd 119

119

09/07/12 20:17

いうのはささいな問題であり、プログラ

と言える。しかし、当時のニーズに合

の効果は限定的なものだった。Java

ミングの生産性向上というメリットのほ

わせて考案された言語設計では、そ

では、バージョン間の互換性の問題も

うがはるかに大きかった。つまり、ハー

の後のハードウェアの進化とWebプラ

あり、プログラミング言語の進化に素

ドウェア性能の向上が Java の普及を

ットフォームの台頭に完全に対応して

早く追随していくのが困難なのである。

可能にしたのである。

いくのは難しかった。

 こうした流れから、静的型付け/コ

 Javaが登場した1995 年から20

 この間隙を突いて著しい普及を見

ンパイラ方式を持ち、なおかつ冗長性

09 年までの 14 年間で、ハードウェア

せたのが、RubyやPython、JavaSc

を排除した簡潔な文法やテキスト指

の性能が大幅に向上したことは言うま

ript、PHPといったスクリプト言語であ

向によるスクリプト言語の使いやすさ

でもない。これにより、実用言語にも

る。その特徴は、実行時の性能には

を備えたプログラミング言語に対する

新しいパラダイムの導入が可能になろ

あまりこだわらず、プログラムの開発

潜在的なニーズが徐々に高まってい

うとしている。そのパラダイムこそが関

効率を重視しているという点だ※ 8。ま

ったのだと考えられる。それに応えた

数型言語なのだ。

た、インタープリタ方式によって実現

言語の 1 つが Scalaだというわけだ。

 関数型言語は、手続き型言語やオ

される効率的な開発サイクルも注目

最近では、Twitter のメッセージ・キュ

ブジェクト指向言語に比べて実行速

に値する。一般に、JavaでWebアプ

ーを実装する言語が RubyからScala

度が遅いという難点はあるものの、プ

リケーションを開発/実行する場合、

に変更されたのが記憶に新しい。

ログラムを簡潔に記述することができ、

「コーディング→コンパイル→配備

Webプラットフォームの
プログラミング言語

部品の再利用度も高いため開発効率

→ Webサーバの再起動→実行」
とい

が良い。その有用性は、関数型言語

うステップを踏むことになる。これがイ

の元祖であるLispが現在も使い続けら

ンタープリタ方式ならば「コーディング

れていることからもうかがえる。また、ア

→実行」の2ステップで済むのだ。

 Webプラットフォームの特徴の1つ

カデミックな世界では、MLやOCaml、

 スクリプト言語ではインタープリタ方

は、
「テキスト指向である」
という点だ。

Haskellといった関数型言語が開発さ

式をとることが多く、開発効率が非常

HTTP のようなプロトコルもテキスト・

れ、高い評価を受けている。

に高い。その反面、実行時の性能は

ベースだし、Webページを記述する際

 そして今、ハードウェア性能の向上

Javaとは比較にならないほど遅いの

の文書フォーマットであるHTMLなども

によって、業務アプリケーション開発

だが、それでもWeb アプリケーション

テキストだ。そのため、Web アプリケ

における関数型言語の利用が現実味

やツール開発の分野では十分実用に

ーションには高いテキスト処理能力が

を帯びつつある。そうした流れを受け、

堪えるレベルだ。これは、Javaが登場

求められており、スクリプト言語はまさ

純粋なオブジェクト指向言語であると

したときと同じく、ハードウェアの進化

に打ってつけの存在だった。

同時に関数型言語の機能を併せ持つ

によってスクリプト言語の性能が許容

 また、テキストと並んでWebプラット

マルチパラダイム言語 Scalaもまた、

範囲になったということである。

フォームを支える重要な技術に XML

注目を浴び始めたというわけだ
(図2)

 とは言え、スクリプト言語の動的型
付け/インタープリタ方式には多くの

スクリプト言語の普及に
よる新たなニーズの高まり

け/コンパイラ方式が重用されている

 Java が登場した 1995 年とは、

えば、大勢の開発者が参加する大規

Web時代の
“キラー・アプリケーション”

模なシステムの構築は、スクリプト言

となったNetscape Navigatorのベー

語には荷が重い。

タ版がリリースされた翌 年である。

 そうした事情を受け、Java の開発

Java自身、Webブラウザ上で動作す

効率を高めるべく、2004 年に発表さ

るJavaアプレットを売りにデビューした

れたJava SE 5.0では、EoD
(Ease

問題があり、Java の持つ静的型付
分野に導入するのは難しいだろう。例

120

Scala.indd 120

後、サーブレットが広まったという歴史

of Development:開発の簡易化)

があり、そうした意味ではWeb 時代を

いうビジョンの下、スクリプト言語系の

代表するプログラミング言語の 1 つだ

文法がいくつか取り入れられたが、そ

※ 8 動的型付け、クロージャなどのメカニズムに
よってプログラムの冗長性を排除し、テキスト処理
やコレクション操作を簡単に行えるように文法/ク
ラス・ライブラリが整備されている。

図2:ハードウェア性能の向上による業務アプリ開発言語の変化
1985
1995
2009

ハードウェア性能の向上

C

Java

オブジェクト指向
クラス/オブジェクト
継承

Scala?

関数型
高階関数
遅延評価

IT アーキテクト Vol.24

09/07/12 20:17

特別企画4

マルチパラダイム言語

Scala

があるが、スクリプト言語ではXML の

フォーム独立モデル
(PIM:Platform

える。これが登場する以前、CPU 性

処理に対する配慮が薄いのが一般

Independent Model)

というソフトウ

能の向上とは、すなわちクロック数の

的だ。XMLの処理に関しては、
「ライ

ェアの設計モデルを基にして、プログ

向上を指していた。プログラムを変更

ブラリを使えばAPI経由で行える」
とい

ラムなどの成果物を自動生成するとい

することなく、クロック数の向上により

った程度のサポートで済まされている

う技術だ。開発効率の大幅な向上が

自動的にプログラムの動作性能が向

ことが多い。そのため、スクリプト言語

期待できるものの、まだ本格的な実

上したのである。

で Web アプリケーションを作る場合

用化には至っていない。

 残念ながら、マルチコア CPU の登

は、XMLではなく、JSON のようなテ

 実用化を妨げている要因の 1 つと

場は、CPU 性能の向上がそのままア

キスト形式の文書フォーマットが好ま

なっているのが、モデル記述言語とし

プリケーションの動作性能の向上とな

れる傾向にある。

てUMLを採用したことではないかと筆

っていた時代の終焉を意味する。マ

 だが現在、Web ページの記述に

者は考えている。UML のような汎用

ルチコアCPU 上では、マルチスレッド

は、HTML の代わりにXML ベースの

言語を使うと、
「モデルの記述が冗長

を駆使した並列プログラムでないと、

XHTMLが広く用いられつつある。H

になる」、
「目的とするモデルを記述し

コア数の増加に応じた性能向上は見

TMLの次期バージョンであるHTML5

きれない」
といった問題が生じるのだ。

込めないのだ。

では、その傾向が加速することになる

また、UML のようなグラフィカル言語

 こうしたことから、並列プログラミン

だろう。さらに、Webアプリケーション

は編集効率が悪いという問題もある。

グは今後、従来のように制御系など特

で本格的なデータ交換を行う際、標

 これを解決するものとして注目され

定分野だけのものではなくなり、業務

準的に使われるプロトコルはWebサー

ているのがテキストDSLである。DSL

アプリケーションであっても動作性能

ビス系のSOAPとREST系のAtomP

とは、ある特定領域のモデル記述に

が重要な局面では必須の技術になる

ubだが、これらはいずれもデータ形式

特化した言語のことだ。対象を絞るこ

と予想される。だとすると、効率良く、

にXMLを用いる。

とで、十分かつ簡潔にモデルを記述で

高い信頼性の下に並列プログラミング

 こうしたことから、今後、本格的な

きるようになるのである。その DSL の

を行える仕組みと、その仕組みを実現

Webアプリケーションを開発するための

表現形式としてテキストを用いたもの

するプログラミング言語が必要になる。

プログラミング言語は、テキスト指向に

がテキスト D S L だ。テキスト D S

加えて、XML指向の文法も備えている

Lを用いることで、グラフィカル言語特

クラウド・コンピューティング

ことが求められるようになると見られる。

有の編集効率の悪さを回避できる。

 最近、クラウド・コンピューティング

 ただし、DSLを使う場合、通常は

と呼ばれる技術が脚光を浴びている。

DSLの文法や処理系を利用者が自ら

まだ新しい技術分野であるため、明確

開発しなければならない。これが現

な定義は確立されていないが、本稿で

 Scala が注目を集める理由として

在、DSL 普及のネックとなっている。

は「パブリックなインターネット空間上

は、次世代技術との親和性の高さも

DSL の文法の定義や処理系を簡単

に、事実上無尽蔵に用意されたCPU

挙げられる。以下に、そうした技術の

に開 発できる技 術が 登 場すれば、

やストレージなどのリソースを安価に利

代表例として、DSL、マルチコア CP

DSLを使ったモデル駆動開発が一気

用できる環境」
のことを
「クラウド環境」

U、クラウド・コンピューティングの3つ

に普及する可能性がある。

と呼び、クラウド環境上のリソースを

マルチコアCPU

アプリケーション」
と呼ぶことにする。

 CPU のクロック数向上のアプロー

 クラウド・コンピューティングの特性

チに限界が見えてきている中、次なる

の1つは、Webプラットフォームだとい

次世代技術へのアプローチ

活用するアプリケーションを
「クラウド・

を取り上げる
(それらとScala の関係
については、以降の章で述べる)

DSL
 ソフトウェア開発の世界で10 年ほ

性能向上策として期待されているの

うことだ。したがって、Webアプリケー

ど前から話題になっている開発手法

がマルチコアCPUである※9。

ション開発に適したプログラミング言

に、OMG
(Object Management Gr

 マルチコア C P U とは、単 一 の

oup)
が提唱する
「モデル駆動開発

CPU 筐体の中に複数の CPUコアを

(Model Driven Development)

同梱したプロセッサであり、アプリケー

ある。これは、抽象度の高い「プラット

ションからはマルチプロセッサとして扱

※ 9 マルチコア CPUとアプリケーション開発の
かかわりについては、ITアーキテクト Vol.23 の特
集 1『マルチコア時代のアプリケーション開発』

解説されているので、興味のある方は併せてお読
みいただきたい。

IT アーキテクト Vol.24

Scala.indd 121

121

09/07/12 20:17

語はクラウド・アプリケーション開発に

け入れられるかどうかわからない初期

めると、次のようになる。

おいても有効だと言える。

の段階から大規模なアプリケーション

●ハードウェアの進化により、スクリプ

 クラウド・アプリケーションの重要な

を開発するのは難しい。そのため、ク

ト言語や関数型言語による業務ア

特性は
「スケーラビリティ」
(アプリケー

ラウド・アプリケーションを実装するプ

プリケーション開発の道が開けた

ションを改造することなく、システム・リ

ログラミング言語には、初期段階の

● Web 技術の発達により、テキスト

ソースの増強によってシステム規模を

小規模な開発ではスクリプト言語並

指向かつ XML 指向のプログラミン

増大させられる能力)
である。

みの手軽さでアプリケーションを開発

グ言語が必要になった

 従来の Webアプリケーションでは、

でき、利用者の数が爆発的に増えて

● DSL、マルチコア CPU、クラウド・

動作環境となるハードウェアを事前に

も対応可能な並列分散処理のメカニ

コンピューティングといった新しい

準備する必要があったため、
(将来の

ズムが求められることになる。

技術が登場し、それらに対応できる
プログラミング言語が必要になった

増設の可能性も含めて)準備できる
ハードウェア規模の制約の中でアプリ
ケーションのアーキテクチャを決定し
ていた。つまり、ハードウェアの制約
を超えた高度なアーキテクチャを用い
ても活用できないため、自然とスケー

Scalaの
価値

 こうした時代の流れ/ニーズの変
化から、Scalaが注目され始めたとい
うわけだ。Scala の能力を知るには、

時代のニーズに、
Scalaはどう応えるのか

図 5に示すように、ScalaとJava、ス
クリプト言語、関数型言語の関係に
着目するとわかりやすい。以下に、各

ラビリティに対する考慮は小さくなる。
 一方、クラウド・アプリケーションの
場合、事実上ハードウェアの規模に
関する制約はないので、利用者数が
激増するというビジネス・チャンスが訪
れた場合、システム・リソースの増強
によって容易にシステム規模を拡大
することができる。ただし、チャンスを

図3:スケールアップとスケールアウトによるスケーラビリティの確保
プレゼンテーション

なければならない。つまり、アプリケー
ション・アーキテクチャも初期の段階
からスケーラビリティを意識したもので
あることが必要なわけだ。この時、注

汎用機

サーバ
スケールアップ

スケールアウト
クライアント

クライアント/サーバ

Webアプリケーション

スケールアウト
クライアント

サーバ

クライアント

スケールアップ
サーバ
サーバ

図 4:クラウド・アプリケーションの構成例
マスタ・データなど、
更新頻度が低いデ
ータは分散ストレー
ジで配置して直接
参照する

やハードディスク容量の増強によるス

スケールアップ

スケールアウト

クラウド・アプリケーション クライアント

分散
ストレージ

ケールアップではなく、CPU数やハー
ドウェア装置を追加するスケールアウ

サーバ
スケールアップ

スケールアウト

意しなければならないのはCPU 能力

トによるスケーラビリティの確保が前

データベース

アプリケーション
スケールアップ

逃がさないためには、アプリケーション
も簡単に拡張可能な構造になってい

言語からさまざまな機能を取り入れた

 ここまでに説明した時代背景をまと

結 果を直 接 知り
たい場合には、手
続き呼び 出しで
同期型の連携を
行う。
この形式の
連携を行うとスケ
ーラビリティが低
くなる

クラウド・アプリケーション
プレゼンテーション

サービス

サービス利用の主
力はメッセージであ
る。
この 形 式 の 連
携を行うと、
スケー
ルアウトによってス
ケーラビリティを確
保できる

サービス

提になるということである
(図3)

 このスケーラビリティに対するアプ
ローチの違いが、通常の Webアプリ

メッセージ・キュー

サービス

REST

ケーションとクラウド・アプリケーション
の本質的な相違点だ。このような特
性を前提にすると、クラウド・アプリケ
ーションは図4のような構成になると考
えられる。
 とは言え、サービスが利用者に受

122

Scala.indd 122

サービス

バックエンド
のサービス
群も、
メッセ
ージによって
連携する

メッセージ・キュー

サービス
データベースにア
クセスするスコープ
は、
サービスに閉じ
ておくとよい

同期通信
データベース

メッセージ送信
メッセージ配信

IT アーキテクト Vol.24

09/07/12 20:17

特別企画4

マルチパラダイム言語

Scala

Scalaが、時代のニーズにどう応えよ

 スクリプト言語の実行性能を低下さ

これらの問題はハードウェアの性能向

うとしているのかを説明しよう。

せる原因となっている動的型付けやメ

上によって解消されつつあることは先

タオブジェクトは取り入れていないが、

述したとおりだ。

古さを排除した“現代版Java”

それらが担う役割を関数型言語によっ

 一方、長所としては、
「開発効率が

 Scalaには、Java の多くの機能が

て実現しているのが Scalaのすごいと

高い 」、
「 言 語の拡 張 性がある」、
「並列プログラミングが可能である」

受け継がれている。先に説明したよう

ころだ。

に、JVM 上で動作することに加え、

 例えば、スクリプト言語は、動的型

いった点が挙げられる。

余分な手続きをすることなくJavaクラ

付けによってプログラムの冗長性を

 開発効率の高さは、関数型言語

スとの相互呼び出しが可能となってお

排除している。Scalaでは、動的型付

の特徴であるクロージャや高階関数、

り、膨大なJavaの資産を活用できる。

けではなく、関数型言語の型推論機

遅延評価といったメカニズムによって

 ただし、Scalaではやや古めかしさの

構を取り入れることで、性能を低下さ

生まれる再利用可能な部品の豊富さ

あるJavaの文法との互換性について

せずにプログラムの冗長性を排除す

によるところが大きい。

はこだわらず、新たに洗練された文法

ることに成功している。また、スクリプ

 また、言語の拡張性が高く、各機

を用意している。オブジェクト指向言語

ト言語が動的型付けとメタオブジェクト

能を拡張しやすくするための文法上

として、
“現代版 Java”
だと考えて利用

のメカニズムによって内部 DSL ※ 10を

の工夫も施されている。

するだけでも、十分有用だと言えよう。

実現しているのに対し、Scalaでは、

 そして並列プログラミングだが、これ

あらゆる手段で
スクリプト言語の機能を実現

関数型言語の遅延評価機能や暗黙

は一般に、ごく限られたエキスパートで

変換といった機能を取り入れることで

なければ十分な成果を上げられないほ

内部DSLを実現している。

ど難易度が高い。特に、排他制御時
の同期のズレによって発生するオブジ

 Scalaは、スクリプト言語から、その
プログラミングの手軽さを実現してい

関数型言語

ェクトの状態の不整合や、デッドロック

る統一オブジェクト・モデルやクロージ

 関数型言語は、実行時の動作性

などの問題を防ぐには、非常に高度な

ャといった機能を取り入れている。

能とメモリ消費量に難があるものの、

プログラミング技術が必要になる。し
かし、これに関数型言語を用いると、
副作用のない関数評価によるプログ

図5:ScalaとJava、
スクリプト言語、
関数型言語の関係
Java

Scala

スクリプト言語

ラムの実行が可能になる。
「副作用
がない」
というのは、
「リソースの状態

C文法

コンパイラ

インタープリタ

コンパイラ

インタープリタ

動的型付け

が変更されない」
ということだ。つまり、

静的型付け

静的型付け

排他制御が一切不要になるのであ

オブジェクト指向

型推論

JVM
クラス・ライブラリ

オブジェクト指向

統一オブジェクト・モデル
テキスト指向
使いやすいコレクション
クロージャ

業界標準API

JVM
クラス・ライブラリ

メタオブジェクト

業界標準API

関数型言語
高階関数
遅延評価

高階関数
遅延評価

不変オブジェクト
パターン・マッチング
モナド
アクタ

抽象型
トレイツ
エクストラクタ
ケース・クラス
暗黙変換
XMLリテラル
パーサ・コンビネータ

問題は完全に回避できる。ただし、関
数の評価によるプログラムの実行に

統一オブジェクト・モデル
テキスト指向
使いやすいコレクション
クロージャ

不変オブジェクト
パターン・マッチング
モナド
アクタ

る。したがって、排他制御にまつわる

型推論

は、膨大なデータの複写処理が発生
するために動作速度が遅く、メモリも
大量に消費するという問題がある。こ
の問題は、ハードウェア性能の向上
によって解決されることが期待される。
 もちろん、
「副作用のない関数評
価」
では解決することができない、どう
してもスレッド間で競合するリソースも
存在する。そのようなリソースを操作
※ 10 DSL の文法をホスト言語に埋め込むかた
ちで実現するスタイル。これに対して、一から文法
を作ったものを外部DSLと呼ぶ。

IT アーキテクト Vol.24

Scala.indd 123

123

09/07/12 20:17

する方式には、共有メモリ方式とメッ

●アプリケーション・フレームワーク

に、Scalaは最適だと考えられる。高

セージ・パッシング方式の 2 種類があ

●制御システム

いスキルを持つエンジニアが Scalaで

る。前者は、スレッド間でメモリを共有

●クラウド・アプリケーション

フレームワークとコンポーネントを作り、

し、排他制御によって同期を取りなが

●DSL

一般のエンジニアがJavaで業務アプ

らメモリの参照/更新を行うため、上

 以下、順に説明していこう。

リケーションを開発するという分業体

述した排他制御の問題が発生してし

制を組むのが有効だろう。

まう。一方、メッセージ・パッシング方

アプリケーション・フレームワーク

式は排他制御を伴わない
(図 6)。そ

 アプリケーション・フレームワークと

制御システム

の計算モデルとして知られるのが「ア

は、WebシステムやGUIといった特定

 組み込み系やファクトリ・オートメー

クタ・システム」
であり、それをサポート

の分野のアプリケーションの骨組み

ションなどの分野で開発される制御シ

する関数型言語として有名なのが Erl

を、再利用可能なソフトウェア部品に

ステムは、非同期に発生するイベント

angである。

したものである。フレームワークに加え

を起点に動作する。

 Erlangは、副作用の発生しない関

て、フレームワークに特化したコンポ

 制御システムでは、複雑で高度な

数型言語の処理能力とアクタ・システ

ーネントもソフトウェア部品として用意

並列プログラミングが必要だ。そして

ムの組み合わせが並列プログラミング

するのが一般的だ。

前述したように、並列プログラミング

に有効であり、動作性能も実用に足

 実際にアプリケーションを開発する

の世界では、関数型言語が注目され

ることを実証した言語だと言える。一

際には、フレームワークとコンポーネン

ている。すでにErlangが高い評価を

方、Scalaでは、不変オブジェクトを使

トによってベースになる部分を作り、

得ているが、Java の資産を生かすこ

うことで副作用の発生しない関数型

後はアプリケーションごとに必要な処

とができ、Webアプリケーションやクラ

計算が可能となっており、さらにErla

理を新規に開発するという流れにな

ウド・アプリケーションとの柔軟な連携

ngのアクタ・システムにならったアクタ

る。これにより、圧倒的に開発量を

が可能なScalaも有力な選択肢の 1

基盤並列ライブラリを提供している。

削減できるのはもちろん、スキルの高

つとして考えられる。

いエンジニアが開発難易度の高い処

Scalaによる業務
アプリケーション
開発

理を部品化しておけば、スキルの低い

クラウド・アプリケーション

エンジニアでも高機能なアプリケーシ

 クラウド・アプリケーションは、Web

ョンを構築できるというわけだ。

アプリケーションとしての性質を備え

 この開発スタイルを成功させるため

つつ、
「急激な規模拡大への対応」

今、Scalaの利用が
有効な分野を考える

の鍵は、高度な再利用性を持ったア

というクラウド・コンピューティング特

プリケーション・フレームワークとコン

有の要件にも応えられる構造になっ

ポーネントをいかにタイムリーに用意で

ていなければならない。

 筆者が考えるScalaの最大の長所

きるかという点にある。そうした要件

 Webアプリケーションを記述するプ

は、
「プログラムの開発効率が高い」
という点だ。オブジェクト指向言語と
関数型言語のメカニズムを活用する
ことで、ソフトウェアを部品化できる範

図 6:共有メモリ方式とメッセージ・パッシング方式
●共有メモリ方式
スレッド

●メッセージ・パッシング方式
メモリ

スレッド

囲が広がっているのである。
 しかし、前述したように Scala にも
問題は残っている。それらが解決され

メモリ

ないうちは、業務アプリケーション開
発の主力言語となるのは難しいだろ
う。当面は、
「Scalaならでは」
という
分野に絞って利用するのが得策であ
る。該当する分野として、次のような
ものが考えられる。

124

Scala.indd 124

スレッド

複数のスレッド
がメモリを共有
するので、競合
が発生する

スレッド

1つのスレッ
ドがメモリを
占 有 するの
で、競合が発
生しない

スレッド

メッセージ・
ボックス

メッセージ・
ボックス
メッセージ・ボ
ックスを介した
メッセージ交換
によって非 同
期処理を実現
する

スレッド

メモリ

IT アーキテクト Vol.24

09/07/12 20:17

特別企画4

マルチパラダイム言語

ログラミング言語には、スクリプト言語

modeler/)
を紹介しよう。

並みの手軽さでアプリケーションを構

 SimpleModelerでは、まずScala

築でき、テキストやXMLを効率良く処

をホスト言語とする内部 DSL により、

理する能力が求められる。すでに説明

(SimpleModelerが定める)
オブジェク

したとおり、Scalaはそうした能力を十

ト・モデルを記述する
(リスト1 にその

分に備えている。

例を示す)
。これをSimpleModelerで

 また、システム規模の拡大に際して

コンパイルすると、UML のクラス図や

は、アプリケーション・ロジックに手を

ステートチャート図のほか、Google

入れることなく、クラス・ライブラリなど

App Engine for Python、同Javaで

の機能拡張で対応できれば理想的で

利用するCRUD
(Create/Read/Up

ある。それには、プログラミング言語

date/Delete)
アプリケーションといっ

側に柔軟な言語拡張機能が必要だ。

た成果物を自動生成する仕組みにな

これはまさに、スケーラビリティを重視

っている
(図7)

リスト1:Scalaをホスト言語とする内部DSLによる
オブジェクト・モデルの記述
(DER商品.scala)
package com.yorozu_store
import org.simplemodeling.dsl._
import org.simplemodeling.dsl.datatype._
import org.simplemodeling.dsl.domain._
import org.simplemodeling.dsl.domain.
values._
// DomainResource を extends することで
// ドメイン・モデルのリソースであることを宣言
case class DER 商品 extends DomainResource {
term = " 商品 " // 用語として「商品」を定義
caption = " 商品 " // キャプションとして「商品」を定義
brief = <t></t> // 摘要を定義(この例では空欄)
description = <text></text> // 説明を定義(こ
の例では空欄)
// DER 商品の IDとして属性名「商品 ID」、
// 属性型「DVI 商品 Id」を定義
id(" 商品 Id", DVI 商品 Id())
// DER 商品の属性として属性名「商品 Name」、
// 属性型「DVN 商品 Name」を定義
attribute(" 商品 Name", DVN 商品 Name())
// DER 商品の関連として関連名「製品」、関連型「DER 製品」、
// 多重度「1 以上」を定義
association(" 製品 ", DER 製品 (), OneMore)
}

するScalaの得意とするところである。

*  *  *

そのほか、もちろん並列プログラミング
も必要だが、並列プログラミングにお

Scala

 以上、本企画では、昨今注目を集

今後普及が予想される技術分野に

けるScala の有用性については前節

めるプログラミング言語 Scalaについ

最適なプログラミング言語であること

で述べたとおりだ。

て、その登場背景や特徴、使用するメ

に改めて気付かされた。

 このように、クラウド・アプリケーシ

リット、具体的な用途などを紹介した。

 本稿ではScala の文法まで紹介す

ョンの要 件をつぶさに見ていくと、

 筆者は昨年の 7月からScalaを使

ることはしなかったが、それを見たら、こ

Scalaがいかにクラウド向きのプログ

い始めたが、その開発効率の高さに

こまでに説明した特性の数々が、実に

ラミング言語であるかがわかる。

すっかり魅了されてしまった※ 11。この

エレガントに実現されていることに驚か

メリットを、ぜひ本誌読者にも伝えたい

れるはずだ。本稿をきっかけにして、ぜ

DSL

と考え、執筆の機会をいただいたわけ

ひ読者もScala の世界に足を踏み入

 DSL によるモデル駆動開発では、

だが 、記 事 を 書くに あたって S

れてみていただきたい。

DSLの文法定義とその処理系、DSL

cala のことを改めて調べ直してみて、

によって定義されたモデルの処理系

オブジェクト指向言語、関数型言語、

の開発がポイントになる。

スクリプト言語の長所がバランス良く

 Scalaは、内部DSLのホスト言語と

取り入れられており、さらにマルチコ

して優れた特 性を持つだけでなく、

アCPU、クラウド・コンピューティング、

BNF
(Backus Naur Form)
の記述か

DSL によるモデル駆動開発といった

※ 11 ちなみに、筆者の言語遍歴を書いておく
と、マイコン時代の BASIC、機械語から始まって、
大学時代はC 言語でLispインタープリタを開発、
仕事では C 言語と機械語でUNIX OSを開発、
Lispでツール開発を経験した後、Javaと出会い、
オープンソース開発に取り組んだ。そして、現在の
主力言語はもちろんScalaだ。JavaとLispの
“いい
とこ取り”
のプログラミングは快適である。

らパーサを生成するパーサ・ジェネレー
タ機能によって外部 DSLの作成も比

図7:SimpleModelerの構造

較的容易に行えるようになっている。
 また、DSL 処理の実装言語として
も非常に使いやすい。ケース・クラス
やパターン・マッチングといった機能に
より、テキスト/XML の処理を手軽
に記述することができるのだ。

CSV

した例として、筆者が開発したモデル・

クラス図

SimpleModelリポジトリ
(Maven project)
Scala DSL

import
Mindmap
(Xmind)

ステート
マシン図

java

gae
verify

testset

検証結果

テスト・
セット

Excel
(モデル)
企画中

html

grails
import

コンパイラ「SimpleModeler」
( ht
tp://code.google.com/p/simple

import

convert

 ここで、Scalaを内部 DSLのホスト
言語/DSL 処理の実装言語に利用

Web仕様書

project

gaeo

Java
プログラム
Grails
プログラム
Google App
Engineプログラム
Google App
Engine Oilプログラム

IT アーキテクト Vol.24

Scala.indd 125

125

09/07/12 20:17

執 筆 者

紹 介
Author's Profile

宗 雅彦

小池 和雄

富 光弘

平井 明夫

サイクス代表取締役社長。コンピュータ・メー
カーで UNIX 系 OS の開発に従事した後、
2000 年にサイクスを設立。情報システム/
組み込み系ソフト開発における技術支援や、
マネジメント・システムの構築支援などのコン
サルティング活動に取り組む。講演や翻訳、
執筆などの活動も活発に行っている。

NEC システムズアーキテクト。汎用機のテ
クニカルSEから始まり、プロジェクト・マネジャ
ーとしてシステム開発全般を経験した後、イ
ンフラを中心とするシステム構築部隊を率い
た経験を持つ。NEC のプラットフォーム戦略
の検討を経て、現在はシステム基盤のコンサ
ルテーションに従事している。

NECシステムテクノロジー ITコーディネー
タ。汎用機のテクニカル SEとしてキャリアを
スタートさせ、システム開発全般を経験した
後、ITインフラ構築部隊のリーダーとしてさま
ざまなプロジェクトを推進。現在はシステム基
盤のコンサルテーションに従事している。

日本 DEC
(現 HP)
、コグノス、オラクルを経
て現職。ソフトウェア製品の開発、マーケテ
ィング、導入コンサルティングに従事。特に、
データ・ウェアハウス、BI、OLAPを得意分野
とする。現在は、
BI技術の啓蒙のため、雑誌
やWebサイトの記事執筆に積極的に取り組
んでいる。

執筆記事:P.016

執筆記事:P.080

執筆記事:P.080

執筆記事:P.096

松原 敬二

野上 忍

開米 瑞浩

浅海 智晴

メーカー系ソフトウェア会社、インターネット・サ
ービス会社での勤務を経て、
2008 年にIT 教
育コンサルタントとして独立。情報処理技術
者試験の15試験区分に合格し、完全制覇ま
でプロジェクトマネージャ試験を残すのみ。著
書は
『情報処理教科書システムアーキテクト』
(翔泳社刊)
など。

1994 年に野村総合研究所入社。主に分散
システム技術を担当。JavaベースのWeb 3階
層ソリューションの設計/開発に従事。現在
は情報技術本部 先端技術開発部 上級テク
ニカルエンジニアとしてクラウド・コンピューティ
ング技術の評価/導入に取り組んでいる。

アイデアクラフト代表。SE 業務の経験から
「文章を正確に読み取る読解力」の必要性
を認識し、そのための「読み書き/図解」の
研修プログラムを開発。一般社会人向けに
読解/表現/思考力を磨くための教育事業
を展開中。著書は
『90 分でわかる SE の思
考術』
(日経BP社刊)
など。

執筆記事:P.028

執筆記事:P.041

執筆記事:P.074、106

荒井 岳

岩崎 浩文

笠原 規男

ソフトウェア・ベンダー、監査法人系コンサル
ティング会社、独立コンサルタントを経て現
職。情報システムの開発から戦略立案に至
るまで幅広くコンサルティング業務に携わり、
豊富な経験の中で培った抜群のバランス感
覚には定評がある。

豆蔵でSOA担当のITアーキテクトとして、大
規模企業システムの再構築プロジェクトの支
援活動や、分散型開発プロセスの策定など
に取り組む。雑誌/Web サイトを中心に著
作多数。趣味はレトロ・マイコンと銀塩写真。
ブログは
『武者返し.com』
(http://www.mu
shagaeshi.com/)

肩書はコンサルタントながら、実質的にはアー
キテクトとしての仕事が中心となっている。シ
ステム構築プロジェクトの立ち上げ時に参画
し、システム・アーキテクチャの確立、現場へ
の浸透を見届け、次の顧客へと渡り歩いてい
く。目下のテーマは、
ドメイン駆動開発と親和
性の高いアーキテクチャの構築。

執筆記事:P.052

執筆記事:P.058

執筆記事:P.070

2007 年度まで稚内北星学園大学 東京サ
テライト校で教授を務めた後、
2009年2月に
モデル駆動開発とクラウドの研究プロジェクト
「edge2.cc」
を設立。同年5月には匠Labに
参画し、フェローに就任。代表作はXML 文
書処理システム
「XML SmartDoc」、XML/
Javaスキーマ・コンパイラ
「Relaxer」
など。
執筆記事:P.116

お 詫 び
本誌Vol.23
(2009年5月25日発売)
の特別
企画 4『複合イベント処理「CEP」』の表 1
(140 ページ掲載)
において、
「日立製作所」

「StreamBase Studio/StreamBase Se
rver」の国内販売元としておりますが、これは
誤りです。同社は
「uCosminexus Stream
Data Platform」の国内販売元となります。
ここにお詫びするとともに訂正いたします。

IT アーキテクト Vol.24

執筆者紹介.indd 127

127

09/07/12 18:17