itアーキテクト 育成ハンドブック · 3 1. itアーキテクトとは 1-1. it...
TRANSCRIPT
IT アーキテクト
育成ハンドブック
IT スキル標準 プロフェッショナル・コミュニティ
IT アーキテクト委員会 2004/07/07
Ver 1.0
1
CONTENTS
はじめに ................................................................................................................... 2
1. IT アーキテクトとは......................................................................................... 3
1-1. IT アーキテクトとはどのような職種か...................................................................3
1-2. IT アーキテクトはなぜ重要か .................................................................................3
1-3. IT アーキテクトの活動 ............................................................................................4
2. IT アーキテクトを目指す方への提言............................................................... 5
2-1. IT アーキテクトが備えるべきスキル ......................................................................5
2-2. IT アーキテクトが備えるべきスキルを身につけるためには？..............................7
2-3. IT アーキテクトに求められる能力や行動様式........................................................9
3. IT アーキテクトを育成する立場の方への提言...............................................11
3-1. IT アーキテクト育成体系の策定............................................................................ 11
3-2. IT アーキテクト育成サイクル ............................................................................... 12
3-3. 効率的 IT アーキテクトの育成手法 ....................................................................... 13
3-4. IT アーキテクト育成事例の紹介............................................................................ 14
4. 各社 IT アーキテクトへのインタビュー .........................................................16
5. プロフェッショナル・コミュニティ IT アーキテクト委員会の紹介.............31
6. ＜付録＞ IT アーキテクト委員の心に残った一冊..........................................37
2
はじめに
独立行政法人 情報処理推進機構（IPA）・IT スキル標準センターでは、プロフェッショナルによる情報交
換や議論の場を通して後進人材の育成に貢献するための「プロフェッショナル・コミュニティ」を創設し、そ
の一環として、2003 年 11 月より「IT アーキテクト委員会」が活動を開始しました（プロフェッショナル・コ
ミュニティと IT アーキテクト委員会については、本書の第 5 章を参照のこと）。
本書は、IT アーキテクト委員会の 2003 年度下期の活動の成果に基づき、「2003 年度版の IT 育成ハンドブッ
ク」として、次の方を対象に、2004 年 6 月に整理したものです。
// 本書の対象の方 //
既に IT サービス産業に従事していられる方の中で、これから IT アーキテクトを目指そうと
されている方
IT サービス産業を営む企業・組織の中で、これから IT アーキテクトの育成を担当される方
なお、IT アーキテクト委員会の 2004 年度以降の活動の成果により、本書は、必要に応じて随時改版してい
く予定ですのでご了承下さい。
3
1. IT アーキテクトとは
1-1. ITアーキテクトとはどのような職種か
IT アーキテクトとは、IT アーキテクチャを作成しその成果物と効果に責任を持つ専門職を指します。
具体的には、コンサルタントからのビジネス領域での経営戦略や実現するビジネスプロセスの検討結果を入
力として IT アーキテクチャを設計し、成果物として IT アーキテクチャの設計内容を出力します。
図 1-1 IT アーキテクトは何を行うのか
図 1-1 で示すように、IT アーキテクトの活動はビジネス計画・戦略と IT システムの開発を結ぶ中間に位置
しています。これは IT アーキテクトのスキルとして、IT 技術のみならずビジネスプロセスなど広範な領域を
網羅することが必要であることを示しています。
同時に IT アーキテクトは成果物に対して以下の 3 点について責任を持ちます。
アーキテクチャの品質（機能性/信頼性/使用性/効率性/保守性/移植性）
経営戦略、戦略的情報企画で要求されている成果・効果
当該プロジェクトで要求される成果・効果
設計に際してはデータベース、ネットワーク、プラットフォーム、システムマネジメント、セキュリティ、
分散コンピューティングなどの各 IT スペシャリストの専門スキルをまとめながら、全体としてビジネスの要求
に的確に応える整合性のとれた IT アーキテクチャを構築しなければなりません。
1-2. ITアーキテクトはなぜ重要か
システムの環境はマルチベンダ化が進み、多種多様なハードウェア、ソフトウェアやネットワークなどから
構成されるシステムは複雑化してきています。これはすなわちシステム全体の整合性や一貫性を保つことが困
難になってきていることを意味します。
またビジネスの環境そのものも変化がますます激しくなってきており、これに対する即応性（リアルタイム
ビジネスの実現）が求められています。このためアーキテクチャを様々な角度やその構成要素（たとえばビジ
ネスアーキテクチャ、データアーキテクチャ、アプリケーションアーキテクチャなどの観点）から堅牢かつ柔
軟なものとして設計していく必要が生じています。これを行うのが IT アーキテクトです。
IT アーキテクトは、複雑化する既存システムおよび新たに開発するシステムについて、業務プロセスから実
装 IT 技術まで互いに関連する整合性のとれたアーキテクチャとしていく役割を担う職種であるといえます。
ITアーキテクト
の活動
ビジネス戦略
ビジネスプロセス
検討結果
ITアーキテクチャ
（開発へ）
4
1-3. ITアーキテクトの活動
IT 投資の局面（時間軸）に対する IT アーキテクトの活動領域は「戦略情報化企画」と「開発」です。
システムの
運用と管理
システムの
運用と管理
運用計画 /運用管理
の策定
オペレーション
ハードウェア
ソフトウェア
の保守
ハードウェア
ソフトウェア
の保守
ハードウェア
ソフトウェア
の導入
導入計画
の策定
カスタマ
サービス
ｱﾌﾟﾘｹｰｼｮﾝ
ｺﾝﾎﾟﾈﾝﾄ
の保守
ｱﾌﾟﾘｹｰｼｮﾝ
ｺﾝﾎﾟﾈﾝﾄ
の運用
ｱﾌﾟﾘｹｰｼｮﾝ
ｺﾝﾎﾟﾈﾝﾄ
の開発
ｱﾌﾟﾘｹｰｼｮﾝ
ｺﾝﾎﾟﾈﾝﾄ
の設計
ｱﾌﾟﾘｹｰｼｮﾝ
開発計画の策定
アプリケーション
スペシャリスト
システムの
保守
システムの
運用
システムの
導入構築
システム・コン
ポネントの
設計
システム構築
計画の策定IT
スペシャリスト
プロジェクトの
管理 /統制
プロジェクトの
管理 /統制
プロジェクトの
管理 /統制
プロジェクトの
管理 /統制
プロジェクトの
管理 /統制
プロジェクト基
本計画の策定プロジェクト
マネジメント
ソリューションの構築
コンポネントの
設計ソリューション
アーキテクチャーの設計
ソリューションの枠組み策定
ＩＴ
アーキテクト
ソリューションの設計
ソリューション策定のための
助言
ビジネス戦略策定の助言
目標 /ビジョン
の提言コンサルタント
ビジネス課題
ｿﾘｭｰｼｮﾝ提案
ビジネス
戦略の確認
目標 /ビジョン
の確認セールス
ソリューション
保守
（ｼｽﾃﾑ /業務）
ソリューション
運用
（ｼｽﾃﾑ /業務）
ソリューション
構築
（開発 /実装）
コンポネント
設計
(ｼｽﾃﾑ/業務）
ソリューション
設計
(構造 /ﾊﾟﾀｰﾝ)
課題
整理／分析
（ビジネス /ＩＴ）
ビジネス
戦略策定
経営目標／
ビジョン策定
運用・保守開発戦略的情報化企画経営戦略策定ＩＴ投資の局面
と活動領域
職種
ＩＴ投資の局面と活動領域の関係
主たる活動局面 従たる活動局面
（出典: IT スキル標準・IT サービスプロフェッショナル育成の基盤構築に向けて バージョン 1.1）
図 1-2 IT 投資の局面と各職種の活動領域
「戦略情報化企画」では、経営戦略策定局面で定義されたビジネス戦略・ビジネス課題に対して、これを実
現・解決するためのソリューションアーキテクチャを決定します。IT アーキテクトはコンサルタントやセール
スと協働しソリューションアーキテクチャ決定の主導的な領域を担います。すなわち、アーキテクチャデザイ
ンへの入力情報となるビジネス要件を整理する領域はコンサルタント・セールスが担当し、主となるソリュー
ションアーキテクチャをデザインする領域は IT アーキテクトが担当します。
IT アーキテクトは 5 つの専門分野（アプリケーション/データサービス/ネットワーク/セキュリティ/シス
テムマネジメント）のスキルを駆使し、個別の専門要素にとらわれない全体最適化されたアーキテクチャを導
き出します1。
これは単体のソリューションアーキテクチャ2のみで行われる場合もあれば、他システムを含む業務システム
群全体としての最適化を目的とするエンタープライズアーキテクチャとして実施される場合もあります。
「開発」では、戦略情報化企画局面で定義されたソリューションアーキテクチャに基づき、これを実現する
ための設計・実装作業を行います。IT アーキテクトは 4 つの職種（プロジェクトマネジメント/IT スペシャリ
スト/アプリケーションスペシャリスト/カスタマサービス）と協働し、各専門分野毎に行う作業（設計・実装）
に対して、アーキテクチャ全体との整合性を管理する領域を担当します。
1 アーキテクチャの分野分けという観点からは、エンタープライズアーキテクチャ（EA）における「ビジネス・アーキテクチャ」「デー
タ・アーキテクチャ」「アプリケーション・アーキテクチャ」「テクノロジー・アーキテクチャ」という考え方もあるが、IT スキル標
準においては、より技術的な観点で細分化した分野に分類した。 2 本文における用語『ソリューションアーキテクチャ』は、エンタープライズアーキテクチャ（EA）との比較を前提としたものであり、
複数業務ドメインをまたがる最適化をめざす EA に対し、個々の業務ドメインのソリューションを提供するためのアーキテクチャを指す
ものとしている。
5
2. IT アーキテクトを目指す方への提言
2-1. ITアーキテクトが備えるべきスキル
IT アーキテクトは、技術的スキルに加えて以下のような広範なスキルが求められます。多数のスペシャリス
トを始めとして、たえずアーキテクチャ作成とアプリケーション開発に携わるステークホルダの活動を全体ア
ーキテクチャ設計という観点でまとめる役割を担うため、コミュニケーションやリーダーシップなど多くのパ
ーソナルスキルも必要となります。また、パーソナルスキルも含め、アーキテクト活動に必要なスキルは全て
の分野のアーキテクトに共通なものと、専門分野毎に特有のものとがあります。それらを図示したのが図 2-1
です。
図 2-1 IT アーキテクトの保有すべきスキル構成
(1) IT アーキテクトが備えるべきスキル（全専門分野共通スキル）
全専門分野で共通となるスキルには、アーキテクチャ設計に関するもののみならずプロジェクトマネジメン
トやコンサルティングなどのスキルも含まれます。これはアーキテクトも、プロフェッショナルとしてプロジ
ェクト遂行能力が必要であることと、アーキテクチャを導き出すための分析や推敲の能力が必要なことを意味
しています。IT スキル標準では全専門分野共通スキルを、表 2-1 のように定義しています。
表 2-1 IT アーキテクトが備えるべきスキル（全専門分野共通）
スキルカテゴリー 職種共通スキル項目
アーキテクチャ構築 ソリューションアーキテクチャ構築、代替ソリューション分析、要件定義
デザイン モデリングテクニックの活用と実践、ＩＴ標準の適用、再利用テクニックの活用と実
践、技術的検証、データモデリングの適用、プロセスモデリングの適用
全専門分野共通
分野毎 分野毎 分野毎 分野毎
パーソナルスキルなど
6
テクニカル プラットフォームや要素技術の比較、システム運用技術の検証、技術的問題の解決
メソドロジー メソドロジー選択と適用
コンサルティング コンサルティングテクニックの活用と実践
プロジェクトマネジメント プロジェクト計画策定と実施、変更管理
インダストリー 業界ビジネス・技術・競合動向に関する提言、インダストリーアプリケーションに関す
る助言
リーダーシップ チームリード、技術的指針の提示、リーダーシップスタイルの適用
コミュニケーション 効果的かつ効率的な文書力および会話力の活用、良好な顧客関係の維持
ネゴシエーション 指針の提供、成功要件の提供
これらのスキルの獲得には、独学（自学自習）や研修受講だけでは十分とはいえません。通常は実践や経験
を通じて身につけていきます。
(2) IT アーキテクトが備えるべきスキル（専門分野毎スキル）
一方、専門分野毎のスキルについては、広範な技術分野のスキルを身につけた上で IT アーキテクトの役割を
果たせるに越したことはありませんが、昨今の複雑なシステムの構築において一人の IT アーキテクトがすべて
の技術分野をカバーすることが益々難しくなってきました。そこで、得意とする専門領域を中心に IT アーキテ
クトが活動できるように IT スキル標準では IT アーキテクトの専門分野毎のスキルを、技術面から表 2-2 のよ
うに定義しています。もちろん、IT アーキテクトとしてさまざまな領域で活躍したいのであれば、専門分野の
深さと幅を実務経験にもとづいて拡げていくことが望ましいといえます。
表 2-2 IT アーキテクトが備えるべきスキル（専門分野毎）
専門分野 専門分野固有スキル項目
アプリケーション機能 機能配置、アプリケーションの選択、要件確認と調整、アプリケーション開発メ
ソドロジー活用、設計とコードインスペクションの実施
データ構成要素 データ共用と再利用の実施、データ配置、キャパシティ計画策定、ストレージ
管理計画策定、データモデリング技術活用
ネットワーク 既存ネットワーク検証および環境の検証、トポロジー選択実施、ネットワーク
戦略構築、ネットワーク標準策定
セキュリティ セキュリティメカニズム設計、オペレーショナルセキュリティ定義の実施、セキ
ュリティソリューション検定、セキュリティプロトコルの把握
システムマネジメント 必要キャパシティ検証、問題管理、変更管理、回復管理、セキュリティソリュー
ション設計
7
2-2. ITアーキテクトが備えるべきスキルを身につけるためには？
IT アーキテクトは IT スキル標準でもレベル 4 以上のプロフェッショナルとして定義されています。これは、
そのプロフェッションの特徴として、専門分野に関する奥深いスキル、他の技術面およびパーソナルスキルな
どに関する広範なスキルを、それも、ある程度の年月にわたる実践や経験にもとづいたスキルとして身につい
ている必要があるからです。したがって、漫然と取り組み始めるのではなく、IT アーキテクトを目指した研修
体系のカリキュラムに即して研修を受講したり、次の方法を組み合わせてスキルを身に付けていくようにしま
しょう。
独学（自学自習）：
市販本、雑誌、テレビ、ラジオ、PC などによる視聴覚教材による机上の学習を意味し、時間的
な拘束を比較的に受けずに自身のペースで学習を進めることができます。適時・適切なガイドを
受けることにより研修効果を高めることが可能です。
ディスタンス・ラーニング：
独学の研修として組立てられるコースと講師によるリアルタイムのガイドを加えて実施される
コースがありますが、いずれの場合も衛星放送やインターネットなどの通信媒体を通じて提供さ
れます。独学のコースとして提供される場合は、自由な時間に何時でも受講可能な場合と、同一
カリキュラムが頻繁に提供されることにより、都合に合わせて受講が可能な場合があります。い
ずれの場合も、質疑応答をメールなどにより実施することにより、研修効果を高めることが可能
です。講師によるリアルタイムのガイドを加えて実施される場合は、時間の拘束は加わりますが、
質疑応答もリアルタイムで実施されるために研修効果を高めることが可能です。特に最近では、
Web コラボレーション技術の進歩により教室で受講する場合と同等、またはそれ以上の研修効果
が期待できるようになってきました。
教室における集合研修：
専門の講師により提供される研修コースでもっとも一般的な研修形態です。独学やディスタン
ス・ラーニングに比べて、臨場感を持って受講できるほか、比較的に同じような立場の受講生間
のコミュニケーションやディスカッションにより研修効果を高めることが可能です。
ワークショップ：
実際の場面を想定したケース・スタディにもとづいて、通常は複数の受講生でチームを組んで
課題に取り組みます。研修効果を高めるためには、課題とその状況設定を正しく理解すること、
解決方法の発見に集中すること、解決策はひとつとは限らないことを理解し、他のメンバーの意
見にも耳を傾けること、自分の主張が正しいと思ったときには説得を試みること、結論に至るま
での一連の過程に正当性を与えられること（Traceability）、結論の論拠を明確に主張できること
（Accountability）、どのようなヒート・ディスカッション（白熱した議論）を展開しても相手の
メンバーとの間にしこりを残さないこと、などがあげられます。現実の場面においては、限られ
た時間の中で重要な決断を下す必要に迫られます。そのような状況で意味のある決断を下すため
8
には、あらかじめケース・スタディを効果的に実施することは有効です。
OJT（On the job training）：
上述の研修コースで身につけた知識を、プロジェクトなどの実際の場面で実践を通じて定着を
図ります。プロジェクトを構成するさまざまな役割の方々との仕事を通じて、これらの知識を応
用してみましょう。各種の標準や制約に従う必要がある場合など、学んだこととの間のギャップ
に悩むこともあるかもしれませんが、その場合も、“何故そのようにしなければいけないのか？”、
または“このようにしたらもっと効果的なのに”といった自分なりの分析を加えておくことによ
り、判断基準を研ぎ澄ましたり、バランス感覚を養うことができます。
メンタリングとコーチング：
メンタリングは、実は古くはトロイの時代から受け継がれて来た将来有望な若者を育成するの
ための伝統あるキャリア育成プログラムです。メンターという言葉は、古くギリシャ時代から「後
継者の指導者、理解者、支援者」という意味で使われています。メンターの由来は、トロイ戦争
後のオデッセウス王の流浪を歌ったホメロスの叙事詩である「オデッセイア」の登場人物「メン
トール（Mentor）」の名前に由来します。メントールはオデッセウス王の盟友であり、王子であ
るテレコマスの教育係として任命されました。そして王が流浪の旅から戻るまでに王子を次の王
たるにふさわしく育て上げました。王子の指導者、理解者そして良き支援者としての役割を持っ
たメントールにちなみ、以後、後継者の指導者や支援者をメンターと呼ぶようになりました（本
多勝嗣「メンタリングの技術」より）。
メンターは必要な人脈を内外に構築し、必要に応じてそれを動員することが求められ、専門分
野で成功者としての尊敬と信頼を勝ち得る必要があります。また、メンターは、自分の専門性を
明確にして、成功実績を積み上げることが求められます。これによって数ある役割モデルも明確
化し、人に手本を示すことができるようになります。
一方、コーチングとは、会話や人間としてのありかたを通じて、対象者が本人の望む目標に向
かって、本人の満足のいく方法で進むことを促進する環境を生み出す技術です（ヒューマンバリ
ュー編「コーチングの技術」より）。コーチは相手の潜在的可能性を見出し、いかに育成するか
の視点から支援します。これはメンターも同じですが、コーチは専門知識、指導的役割や役割モ
デルを自分自身で示すことよりも、むしろ、プロセス管理と全体の調整に重点を置き、コーチン
グスキルによりそれを補うことが重視されます。したがって、コーチ自身が知識・経験を持たな
い領域でも、効果的な質問などにより、相手の可能性を引き出し、成果を高めることができます。
このように、メンタリングやコーチングを受けるタイミングや方法については、上司や先輩、
または専門能力を持った方と相談することが必要になります。長期にわたる自身のキャリア・プ
ランの中での位置づけを考えてみるようにしましょう。
コミュニティ活動：
ある程度の経験や実績を踏まえて、中堅のプロフェッショナルとして活躍できるようになって
くると、その立場に応じた役割や責任が求められてきます。つまり、より高度で複雑な課題の解
決に取り組む必要が生じてきます。このような課題の解決には、単なる知識の積み重ねだけでな
9
く、先人や他のプロフェッショナルの知恵を有効に活用することが求められます。そのためには、
自社内のプロフェッショナル・コミュニティや、社外の同業種、または、場合によっては、異業
種のコミュニティの活動を通じて、そのような知識や知恵を得るとともに、人格の面でも視野の
面でも幅の広さを身につけるようにすることが考えられます。代表的なものとしては、IT 業界内
のフォーラムや研究会、また、日本情報処理学会などの国内の学会や欧米の学会があります。そ
れらのコミュニティに所属して情報収集・発信に努めることは、自己実現のためだけでなく IT 業
界を含めた社会への貢献にもなります。
2-3. ITアーキテクトに求められる能力や行動様式
IT アーキテクトは、次のような能力や行動様式が求められます。漫然とスキルの習得を図るのではなく、日
頃から心掛けておくようにしましょう。
抽象化能力（枝葉末節を削ぎ落とし本質を捉える）
本質的な問題を把握し、何を解決することが目的に沿っているかを明らかにすることに加え
て、分析に先立って複雑で曖昧な状況を極力単純なモデルに置き換える能力を言います。複雑
な状況のまま問題を解きはじめるのではなく、いったん必要十分なレベルまで単純化した上で
問題解決に取り組み始め、徐々に具体化していくことが重要です。
決断力（技術的に優れていても決断ができなければ）
IT アーキテクトは、プロジェクトのさまざまな局面で、アーキテクチャ上または技術上の決
断を求められます。通常は、決断に必要な情報が全て手元にあるわけではありません。技術的
に最善のものを採用するのが当然の局面でも、他の要因で、次善の技術の採用を決断すること
も想定されます。
説明能力（決断の理由を明確にして説明責任を果たそうとする）
また、決断の正当性を裏付ける分析や経緯を明らかにする（Traceability）も必要です。そ
の時点の決断が間違った判断であって、後続の局面でそれが明らかになったとしても、何故、
そのような決断をしたかの理由が明らか（Accountability）であれば、補正がしやすくなりま
すし、新たなプロジェクトにおいてもそれが経験となって活きてきます。
視野の広さ（好奇心を常に持ち続ける）
判断を求められたり、決断を下す場合には、さまざまな情報や要素を総合的に分析している
場合が多いと思います。確かに、直感に頼らざるを得ない場合もあるかもしれません。その場
合も、その視野が広ければ、バランスのとれた判断ができる可能性は高くなります。IT アーキ
テクトとして、さまざまな分野で活躍するためには、実務経験にもとづいて、知識や能力の深
さと幅を拡げていくことが求められますので、年齢に関わらず、積極的に視野を広げる努力が
必要です。
10
多様な価値観の受容・認識（さまざまな物の見方を認識）
一面的なものの見方の危険性はよく言われることです。たとえ新入社員の発言であっても、
とりあげて評価を加えることにより、最善の判断に繋がる可能性があることを受け入れるくら
いの柔軟性が必要だと言えるでしょう。
問題予見力（現在は顕在化していないが将来問題になる点の把握能力）
“過去の経験からすると、これは問題になりそうだ”と思ったことは、実際に問題になる場
合が多いと言えます。それは、直感として受け止められる場合が多いのですが、過去の経験か
ら総合的に判断した結果であることも多いのです。
技術的なバランス感覚（設計課題と解決の価値を明確にする）
技術的に見て最善と思われるシステムが、実際に使う人から見ると、使い勝手の悪いという
例は数多くあります。IT アーキテクトは、誰のためのシステムを構築しようとしているのか、
常々、立ち返ってみる必要があります。また、プロジェクト推進上で技術的に重要な問題にリ
ソース、時間などが割り振られるようにプロジェクトマネージャに進言し、全体のバランスを
とるように努めることもあります。
知的体力と粘り強さ（設計方針を貫く姿勢・態度）
IT アーキテクトには、要求聴取、抽象化、説明などの一連の作業を、気分に左右されず、ま
た注意力を落とさずに継続し、さまざまな問題や反対意見に対して基本方針を貫く粘り強い姿
勢や態度が求められます。これは、多様な価値観の受容・認識と相反するように見えますが、
立場上、強い利害関係を持つ立場にある人などから、アーキテクチャの一貫性を崩すことを求
めるような意見が出された場合などは、非常に重要な態度であると言えます。このような場合、
合理的理由がある場合は、そういった意見を受け入れる勇気と柔軟性が求められますが、それ
が禍根を残すことが明白な場合は、信念をもって設計方針を貫くように説得する姿勢が必要に
なります。
11
3. IT アーキテクトを育成する立場の方への提言
企業のビジネス領域・形態により、必要とされる IT アーキテクトの人材像は多種多様です。また、IT アー
キテクトに必要なスキルは促成できるものでないため、実務経験の評価を伴った体系的なスキルの習得を基礎
から着実に行っていく必要があります。このため、IT アーキテクトの育成にあたっては、経営戦略やそれに沿
った人材育成戦略に基づき、IT アーキテクトに至るまでのキャリアパスも含めた、長期的かつ計画的な人材育
成体系の策定が必要となります。
3-1. ITアーキテクト育成体系の策定
(1) キャリアおよびキャリアパスの策定
各企業のビジネスを最適に遂行するため、IT アーキテクトを含めた IT 人材の職種と役割およびその階層
と、必要なスキルを定義した人材育成計画（企業として必要とすべき人材像）を策定します。また、この計
画をもとにして、IT アーキテクトへのキャリアおよびキャリアパス（成長への職種を経験）も明確にしてお
く必要があります。
IT スキル標準には、これらの職種（11 種）および役割について定義されており、人材育成計画策定時のベ
ースとして活用することが出来ます。
(2) IT アーキテクト育成計画の策定
人材育成計画で策定した、IT アーキテクトに必要となるスキルを習得させるための教育体系（ロードマッ
プと育成プロセス）の策定と整備を行います。IT アーキテクトにはその職務の遂行のために、高度なテクニ
カルスキルとともに、マネージメントスキルおよびパーソナルスキルの習得が重要となります。
育成計画の策定に当たっては、Off-JT（研修受講、学会／コミュニティ活動）と O-JT（メンタリング／コ
ーチング、ジョブアサイン）を組み合わせ、実務に基づいた育成を基本とすることが重要です。Off-JT につ
いては、IT スキル標準の研修ロードマップを参考に、企業内における研修体系を整備して、それを活用する
のみならず、外部の研修教材業者および各種資格試験等も利用することが効果的です。また関連する学会／
コミュニティでの活動や、書籍およびプロフェッショナルの経験談を参照することも、有効な手段です。O-JT
については、上位 IT アーキテクトによるメンタリング／コーチングと、IT アーキテクトとしての実務経験
によりキャリアを積むことが重要となります。
12
図 3-1 IT アーキテクト育成体系
3-2. ITアーキテクト育成サイクル
(1) 柔軟性のある人材育成体系
IT アーキテクトの育成には長い期間が必要です。この間には、ビジネス環境また IT 技術も大きく変化し
ていきます。中長期事業計画に基づく人材育成計画および個人の研修計画の見直し、また IT 技術の変化に伴
う研修計画の見直しなど、柔軟にかつ迅速に対応できる人材育成のスキームが必要となります。
(2) 自律的キャリア開発体系
基礎からの体系的なスキルの習得を効率的にかつ着実に行っていくためには、個人のキャリア目標の設定、
キャリア開発、およびキャリア評価を支援し、「動機付け」「気付き」を与えるキャリア開発のスキームが
必要となります。
経営戦略 人材育成戦略
人材育成計画の策定
IT アーキテクト育成計画の策定
人材育成体系
IT スキル標準
研修ロードマップ
企業内研修
各社研修サービス
・職種・役割の定義
・階層・スキルの定義
・キャリアパスの定義
・職種・階層別の研修 ・パーソナルスキル研修 ・学会・コミュニティ活動 ・書籍・プロフェッショナル
の講演 など
・メンタリング ／コーチング
・実務経験
など
Off-ＪＴ O-ＪＴ
13
図 3-2 IT アーキテクト育成サイクル
3-3. 効率的 ITアーキテクトの育成手法
(1) 研修の体系化と実施
IT アーキテクトの育成には、まずキャリアパスに沿った体系的な教育が必要です。経済産業省では IT ス
キル標準と同時に「研修ロードマップ」を策定しています。企業としてもこれを参考に自社としての研修体
制を整備し、実務の中だけでは得にくいステップアップに必要なスキルを修得できる研修の体系化及び実施
が効果的です。
また研修以外にも、書籍等によるスキル開発も有効となります。
(2) メンタリング／コーチング
IT アーキテクトを目指す人材に対して、スキルアップ・キャリアアップの動機付けや気付きを与えるとと
もに、プロフェッショナルとしての行動様式を支援し、更なる目標に向けて挑戦させるため、また、限られ
た IT 指導者で人材を育成する手段として、メンタリング／コーチング手法は有効な手段です。これに加えて、
後進の育成を評価する仕組みも必要です。アーキテクトの業績の中で、メンタリング／コーチングを重要な
位置づけとしてとらえる必要があります。
(3) ジョブアサイン
より高度なスキルの習得、スキルの確認のためには、キャリアアップを目的としての経験（ジョブアサイ
ン）の場が必要となります。そのため計画的ジョブローテーション、社内人材公募制度なども有効な手段と
なります。また、このキャリアアップを目的とした成功経験は、本人の自信につながり、動機付け、および
経営戦略
人材育成戦略
経営戦略に基づく 人材育成計画の策定と
キャリアおよびキャリア
パスの明確化
人材育成施策評価戦略
キャリア目標 ／キャリアパス
キャリア開発
キャリア開発計画
キャリア評価
整合
・ コンピテンシー評価 ・ 保有スキル など
・
企業・組織 個人
14
高いモチベーションの維持に大きな効果があります。
(4) プロフェッショナル・コミュニティ
コミュニティとは、IT アーキテクト、また IT アーキテクトを目指す人材の交流の場であり、この相互交
流を通して更なるスキルアップを図ることができます。このコミュニティには、プロジェクトマネージャ等
の他の職種のメンバーや、他組織の IT アーキテクトが参加できればより効果的です。
(5) 認定制度
IT アーキテクトとしてのスキルを有する人材を、組織として公に認知する認定制度は、IT アーキテクトの
モチベーション維持や、IT アーキテクトを目指す人材への動機付けに有効です。
認定にあたっては、スキル習熟度、ビジネス貢献度、ビジネスコミットメントなどを評価項目とし、論文
審査・面接審査等により認定します。特に、IT アーキテクトは、IT スキル標準ではレベル４以上に位置づけ
られるハイレベルな職種であり、社内外において、テクノジやメソトロジ、さらにはビジネスをリードする
プロフェッショナルとしての認知度によって評価する必要があります。従って、IT アーキテクトの育成なら
びに論文審査・面接審査等による認定については、さらに上位の IT アーキテクトのプロフェッショナルでな
ければ対応できないものであることを、正しく認識して制度化することが重要です。
また、認定者に対しての報酬制度についての配慮も検討が必要です。
3-4. ITアーキテクト育成事例の紹介 ～ X社における事例 ～
【ＩＴアーキテクト育成の位置づけ】
Ⅹ社の人材育成戦略は、インダストリー領域を切り口とするビジネス戦略と IT 領域を切り口とする技術戦
略から、全社ビジネスを支えるに必要となる技術者像とそのボリュームを明らかにし、あるべき姿を策定す
ることから始まります。そして、定期的に行う全社リソースに対する人材スキル調査により、事業所毎の人
材ポートフォリオを作成し、人的リソースの現状を把握しています。
この現状を起点とし、あるべき姿に近づくことを目的として、人材育成戦略が企画・立案されます。
一連の人材育成活動の中で、技術系スキルレベルを測る「ものさし」として、IT スキル基準を参考にⅩ社
の人材育成計画を策定します。これは、IT スキル基準をベースとして、Ⅹ社独自の視点・切り口・レベル定
義を盛り込んだオリジナルの計画です。このⅩ社人材育成計画で定義する職種のひとつとして、IT アーキテ
クトがあり、これに従い、IT アーキテクト育成に取り組むことになります。
【ＩＴアーキテクト育成への取り組み】
Ⅹ社の IT アーキテクト育成への取り組みは、実現に向けて計画を進めている段階です。大きく以下の施策
を想定しています。
社内プロフェッショナル認定制度
Ⅹ社の人材育成計画に対する社内認定制度。認定基準と運用方法の明確化を目的とします。上位認
15
定カテゴリ（IT スキル基準レベル 5 以上）を対象とし、特定研修の受講・推薦などの応募資格、筆記・
論文・面接などの審査方法、適性や技術スキルの定量的・定性的な審査基準が定義されます。
キャリアパス定義
Ⅹ社の人材育成計画を基本とした、技術者のキャリアパスの定義。社内におけるキャリアパスのモ
デルを示すことで、技術者自身および育成者が迷うことなく進むべき道を理解・把握することを目的
とします。Ⅹ社の業務特性を反映して、アプリケーション開発技術者を起点とするパスが主流となり
ます。
教育コース
キャリアパスに則したスキルアップを実現するにあたり、必要となる教育コース。上位レベルへの
ステップアップに必要となる知識を、効果的に習得する教育カリキュラムを示し与えることで、技術
者自身、および育成者が悩むことなく、効率的な学習を実現することを目的とします。
IT 要素技術のみではなく、コミュニケーション・ネゴシエーション・コーチング・リーダシップ・
ロジカルシンキングなど、人間系教育も対象範囲とし、社内認定制度で求められる幅広い能力領域を
網羅しています。
また、前述の直接的な取り組みのほかに、以下に記すように、他施策との複合による副次的な効果を想定し
ています。
人事施策との融合によるジョブアサインの効率化
人事施策のひとつである「社内人材公募制度」との連携により、セクションの垣根を越えたジョブ
アサインが可能となり、専門性の高い技術者育成を促進します。
この制度は、プロジェクトを立ち上げる際、必要な人的リソースを社内に対して広く公募する制度
であり、応募条件として、社内プロフェッショナル認定制度を活用することができます。社内プロフ
ェッショナル認定制度により認定された技術者は、専門性を持った技術者であると全社的に認知され
るため、得意とする技術領域を活用できる案件を自ら選択することが可能となり、結果として専門性
が高い技術者の育成を促進することにつながります。
品質保証施策との融合によるコミュニティ活動
品質保証施策のひとつである「第三者レビュー制度」との連携により、セクションの垣根を越えた
技術者の交流を促進します。
この制度は、プロジェクトにおける見積もり・計画・局面・終了などの各フェーズにおいて、開発
規模など定められた条件に合致するプロジェクトは、認定レビューアによるレビューを受けることを
義務づける制度です。認定レビューアは、全社から適切なスキルを持つと認められた技術者であり、
認定技術者は優先的にアサインされます。結果として、第三者レビューの中で認定技術者同士のコミ
ュニケーションが促進されることになります。
16
4. 各社 IT アーキテクトへのインタビュー
ここでは、IT アーキテクトのキャリアパスやスキル習得などの観点から、IT 業界で活躍中の優れた IT アー
キテクトおよびオピニオンリーダーの方々へのインタビューを行い、各人のコンピテンシーを高めるに至った
経緯を垣間見ることを試みました。
なお、このインタビューにご協力いただいたのは、以下の方々です（インタビュー実施順）。
頁 御氏名 会社名 御所属・御役職
p.17 細川努氏 株式会社日本総合研究所 事業化技術センター 所長
技術士（情報工学部門）
p.19 柿木彰氏 株式会社野村総合研究所 システムコンサルティング事業本部
IT アーキテクチャーコンサルティング部
IT アーキテクト
p.21 羽生田栄一氏 株式会社豆蔵 取締役会長
技術士（情報工学部門）
p.23 菅原孝二氏 住商情報システム株式会社 技術グループ 技術部 副部長
p.25 藤澤秀浩氏 UFJIS 株式会社 ダイレクトチャネル開発部 部長
p.27 真野正氏 株式会社シーエーシー コンサルティングビジネスユニット
ビジネス戦略オフィス
ソリューションマネジャー
p.29 早瀬久雄氏 新日鉄ソリューションズ株式会社 基盤ソリューション事業部
マーケティング部
NW プラットフォームグループ
グループリーダー
17
ＩＴアーキテクト紹介① 株式会社日本総合研究所 細川努氏
私のＩＴアーキテクトしての歩み
今は IT アーキテクトとして仕事をしていますが、学生
時代の専門は実は法律でした。会社にも法律関係の仕事を
するつもりで入ったのですが、SE の仕事を始めたら意外
と面白くてやめられなくなり、今に至っています。
情報処理の知識が全くゼロの状態からSEとして働くこ
とになりましたので、会社の昼休みなどを利用して、幅広
い分野について勉強しました。知識面でのスキルアップに
は、資格試験に向けた勉強が非常に役立ちました。当時は
ちょうど、情報処理資格が次々と作られていた時期だった
ので、新しい試験が設置されるたびに、その資格試験を受
験するというサイクルを繰り返し、20 代のうちに、当時
あった情報処理資格のほとんどを取得しました。そのおか
げで、IT アーキテクトとして必要な幅広い知識を身に付
けることができたと思います。資格試験の試験範囲には、
必要な知識が体系的に示されていますので、それに向けて
勉強することで、必要な知識を効率的に習得することが可
能です。また、そういった試験勉強を通じて、新しい技術
について勉強する習慣がついたのは、非常に良いことであ
ったと感じています。
実際の仕事では、特定の業種ではなく、様々な業種の
プロジェクトに携わってきました。希望するプロジェクト
への配属はなかなか難しいものですが、私は、資格取得に
よって自分の実力をアピールすることで、希望するプロジ
ェクトにアサインしてもらえるように努めました。
30 代前半までは SE として働いていました。その頃まで
には、オープン系のシステム構築が主流になっていました
ので、これからは全ての分野についてある程度理解してお
かないと、システム構築はできないだろうということを感
じ始めていました。その後は、PM や PM へのアドバイザ
ー役を務め、業務設計なども行いました。ここ 2～3 年は、
全社的なレベルでの先端技術研究や標準化の企画・推進な
どに携わっています。
ＩＴアーキテクトの役割 － 「熊とワルツを」
先日、「熊とワルツを」という書籍が出版され、その著
者の意見に大いに共感しました。この書籍は、プロジェク
トマネジメントに関するものなのですが、その中で著者が
述べているのは、「プロジェクトは常にリスクを伴うもの
なので、積極的にリスクを管理し、克服することが重要で
ある」ということでした。
私は、プロジェクトにおける技術マネジメントに関し
ても、この著者の意見と同じことが言えるのではないかと
思っています。昔は、皆が知っている安定的な技術を使っ
て、システムの開発を行っていましたが、現在では、最先
端でリスクが不明確な技術を用いて、システム開発を行わ
なければならないこともあります。そのような場合におい
ても、確実な技術や方法論を選択し、可能な限り、技術面
でのリスクを克服することが、IT アーキテクトの重要な
役割です。 また、IT アーキテクトの役割として、顧客が求める品
質とコストとの最適なバランスを確立することも非常に
重要です。そのイメージをグラフ化すると、以下のように
なります。
細川氏プロフィール 株式会社日本総合研究所
事業化技術センター 所長／技術士（情報工学部門） IT アーキテクトとして多数のプロジェクトに参画し、PM と連携しながら活躍。
現在は、先端技術研究や標準化の推進に携わる傍ら、後進の育成にも力を注いでいる。
コスト
品質 最適解
顧客が求める品質
ここを曖昧にすると赤字要因
18
なお、ここで言うシステムの品質とは、バグがないこ
とだけなく、性能・耐久性・操作性等、多様な要求事項を
どれだけ満たしているかを、総合的な観点から評価したも
のです。一般的に、高い品質を求めるとコストが増加しま
すが、逆に、品質が低すぎても、トラブル対応や保守・運
用でのコストが増えることになります。従って、まずは少
なくとも、コストを最小化する経済的品質を実現するのが
合理的であると言えます。また、この経済的品質と顧客の
求める品質との間には、ギャップがあるのが常です。この
ギャップは、付加価値として把握されるべきものなのです
が、この点について、顧客と明確に合意していないと、様々
な問題を生じることになります。そのような事態を避ける
ためにも、顧客の求める品質や要求に対するコストの見積
もりを明確にしておく必要があるのです。
また、プロジェクト全体を見渡す IT アーキテクトの他
に、それぞれの現場を見渡す IT アーキテクトも必要です。
企業の規模にもよりますが、IT アーキテクトは、各企業
に 10 名以上は必要なのではないでしょうか。
ＩＴアーキテクトの必要性
IT 関連の技術は、ますます発展していくことが予想さ
れ、今後は、低価格でさらに高性能なシステムの提供が可
能になっていくでしょう。しかし、どんなシステムを構築
する場合でも、システムの設計を担う IT アーキテクトの
役割は極めて重要です。IT においても付加価値性の低い
業務は、将来的には、人件費の安い国外へ任されるように
なっていくと思いますが、少なくとも IT アーキテクトは、
今後も日本国内で重点的に人材を育成していく必要があ
ると言えます。IT アーキテクトの育成には、企業にとっ
てもかなりの投資が必要となりますが、その投資に値する
だけの重要性を、IT アーキテクトは持っていると言える
でしょう。
今後のＩＴアーキテクトに必要なもの
現在私が、IT アーキテクトにとっての課題として常々
感じているのが、IT アーキテクト間での知識の共有です。
最近では、システムのアーキテクチャやビジネスモデルを、
UML などの、世界的に標準化された表記方法で表現し、
共有化する例も増えています。これからの IT アーキテク
トには、標準化された方法で自らの知識を表現し、業界へ
貢献していくことが求められるようになってくるでしょ
う。私自身も、今後は、こうした知識の共有化に貢献して
いきたいと思っています。
ＩＴアーキテクトに必要な資質
IT アーキテクトとして最も重要な資質は、「さまざまな
分野に対して好奇心を持っていること」ではないでしょう
か。この「分野」とは、技術分野だけではなく、方法論な
ども含みます。技術に限らず、方法論などを含んだ広範な
分野に興味を持てるかどうかが、IT アーキテクトの資質
として、最も重要なものであると思います。
また、これらの物事を客観的かつ公平に見ることがで
きるかどうか、という点も重要です。例えば、ある特定の
ベンダーや技術に過度に固執していては、良い IT アーキ
テクトにはなれません。主観を捨て、客観的で公平な視点
を持っているということも、IT アーキテクトの重要な資
質です。
さらに、難しい内容を平易な言葉で説明できる、とい
う能力も、IT アーキテクトにとっては重要です。お客様
ともきちんとコミュニケーションを取ることができて初
めて、信頼される IT アーキテクトになることができます。
ＩＴアーキテクトのレベルアップについて
当社でも、IT スキル標準の研修ロードマップ上で、レ
ベル 4 以下に相当する IT アーキテクト向けの研修は整備
されています。しかし、問題は、ミドルレベルからハイレ
ベルへレベルアップするための研修の内容で、特に、レベ
ル 5 以上のコミュニティ活動に当たる部分の整備が悩み
どころとなっています。やはり、コミュニティのような場
における他の IT アーキテクトとの交流は、ハイレベルの
IT アーキテクトにとって必要不可欠です。
私自身は、仕事の場などにおいて、他社の IT アーキテ
クトの方々と出会う機会に恵まれました。また、海外の IT
アーキテクトと出会い、自分の目標にしてきました。
ＩＴアーキテクトを目指す方々へ
IT アーキテクトの仕事は、システムアーキテクチャを
大局的な観点からデザインするという難しいものではあ
りますが、同時に、非常に面白いものでもあると思います。
私自身、IT アーキテクトをやっていて一番幸福だと感じ
るのは、ユーザーから感謝の言葉をいただくことです。こ
れこそ、IT アーキテクトにとっての醍醐味と言えるので
はないでしょうか。若い人にも、ぜひ IT アーキテクトを
目指していただき、その達成感を味わってもらいたいと強
く思います。
※ 聞き手：榊原 彰 （IT スキル標準 プロフェッショナル・コミュニティ IT アーキテクト委員会委員）
19
ＩＴアーキテクト紹介② 株式会社野村総合研究所 柿木彰氏
私がこれまでに手掛けてきた仕事
まずは、私の業務経歴を簡単にご紹介します。
私が、当社の前身である野村コンピュータシステムに
入社したのは 1987 年です。入社してまず携わったのが、
勘定系アプリケーションプログラムのメンテナンス業務
でした。ここでは、プログラムドキュメントを夜遅くまで
読みあさる日々を通じて、細かい計算処理の重要性など、
プログラム構築の基本を学びました。
次に従事したのは、ミドルウェアのメンテナンス業務
でした。ここでも、方式設計書やプログラム仕様書を夜遅
くまで読みながら、技術的な基礎を深めました。また、こ
こでは、総合テストの実施を通じて、大規模プロジェクト
の管理手法を学び、プロジェクトマネジメントの経験も積
みました。
その後は、イギリスでの技術調査や適用研究を経て、
2001 年には、準大手証券の IT 化推進プロジェクトで、基
盤設計構築グループ（約 80 名）のリーダーに任命されま
した。このプロジェクトは 9 ヶ月の短期プロジェクトでし
たが、オーソドックスな開発手法と組織作りの徹底によっ
て、「要求仕様通り」「期限通り」にシステムを完成させ、
顧客からも大変感謝されました。このシステムは、2001
年度日経コンピュータ情報システム大賞（大規模システム
部門）を受賞しています。ここでは、昔ながらのオーソド
ックスな理論に間違いはないこと、そして、重要なのは、
そのオーソドックスな理論に示されている当たり前のこ
とを、現実にやり切ることができるかどうかなのだ、とい
うことを、自分の体験として実感しました。これはそのま
ま、現在の私の持論にもなっています。
2002 年には、4 つの証券会社の合併プロジェクトの統
合基盤グループ（約 160 名）のリーダーを務めました。企
業合併に伴うシステム統合とは、まったく異なるシステム
同士を結合させるということなので、通常のシステム開発
とは違った面での困難さを伴います。また、合併前の企業
は指揮命令系統も当然別々なので、意思決定もなかなかス
ムーズにはいきません。私は、企業合併に伴うシステム統
合には、“究極のプロジェクトマネジメント”が必要だと
思っているほどです。しかし、この大変なプロジェクトも、
これまでに培った技術や経験を活かし、着任後 6 ヶ月で無
事成功へと導くことができました。
ＩＴアーキテクトに求められるもの
IT アーキテクトにとって重要なのは、「現状」と「ある
べき姿」を顧客に明確に示すことと、そして、「現状」を
「あるべき姿」に変えることによって得られるメリットを、
分かり易く顧客に伝えることです。そのためには、EA の
モデリングの手法や、開発方法論などの習得も役立ちます。
「現状」や、「あるべき姿」を図に表すことで、何が足り
ないのか、また何が必要なのかが明確になります。また、
最近、企業合併が増えてきましたが、合併にともなうシス
テム統合では、企業全体を見る視点がどうしても必要にな
ってきます。さらに、異なったシステム同士を共通の枠組
みで議論するための方法論も必要です。最近注目を集めて
いる EA（Enterprise Architecture）などを、手法の一つと
して学んでおくと、そのような場合に役立ちます。
若いＩＴ技術者へのメッセージ
新技術や新製品が次々と生み出されている現代、シス
テム開発が「技術ありき」になってしまう傾向が見られま
す。つまり、「このような新しい製品を使いたいから、こ
れをやる」など、新技術や新製品を使うことがシステム開
発の目標になってしまって、「顧客に必要なものは何か」
という視点が欠けてしまっていることがあるのです。
「ビジネス」と「IT」では、「ビジネス」が先にくる ―
柿木氏プロフィール 株式会社野村総合研究所 システムコンサルティング事業本部
IT アーキテクチャーコンサルティング部 IT アーキテクト IT アーキテクトとして、数々の大規模プロジェクトを成功に導いた実績を持つ。現在は、
金融系システムのコンサルタントとして、企業のシステム構造改革の支援を行っている。
20
― これが大原則です。システム開発は、あるビジネス上
の目的を達成するために行うものなので、この原則を変え
ることはできません。「技術があるから使う」という発想
ではなく、「顧客の課題を解決する」という観点から、そ
のために必要な技術を考えなくてはいけません。大切なの
は、「顧客の課題を解決すること」なのです。
顧客の課題を解決することを基準に考えていけば、そ
のために必要な技術というのは、おのずと見えてきます。
そこで、自分にとって未知の技術があれば、それについて
の勉強が必要になるので、そこから新しい技術について学
んでいくこともできます。やみくもに技術の勉強をするよ
りも、今取り組んでいる業務の課題を明らかにし、その解
決法を考えることに力を注ぐべきです。
最近は、IT の分野における知識や技術の複雑・多様化
が進み、自分がスキルアップしていくために、何を学習す
ればよいのかが分からなくなっている若手 IT 技術者も多
いようです。また、IT 業界の動向や製品情報といった、
特定の分野の知識にばかり詳しく、実際に業務に必要な知
識が充分に身についていない若手技術者もよく目にしま
す。しかし、大切なのは、「目の前の課題に常に真剣に取
り組んでいくこと」です。そうすれば、顧客にとって、そ
して、自分にとって必要な技術、というのはおのずと見え
てくるものです。
私のレベルアップ法
私は、この仕事に就く前から情報処理の分野に興味を
持っていました。大学での専攻も情報処理です。学生時代
は、Basic やアセンブラによるプログラミングに熱中して
いました。
入社して仕事を始めても、ビジネスの分野にはあまり
興味はありませんでした。しかし、コンサルタントとして、
客先に赴き、顧客とじかに話をするようになって、ビジネ
スについても知らなければ、顧客と対等に話ができないこ
とを痛感し、幅広い分野について勉強するようになりまし
た。EA についての勉強を始めたのも、EA について造詣
の深い顧客と、対等に話し合う必要があったからです。
先ほど「目の前の課題に常に真剣に取り組んでいくこ
と」が大切と述べましたが、私がそれを重要だと思うのは、
誰よりも私自身がそうやって成長してきた、という事実が
あるからです。目の前の課題に常に真剣に取り組み、そこ
で必要なものが分かれば、ジャンルを問わず、それについ
て必死に勉強する。IT アーキテクトには、そのような柔
軟な姿勢と、何でも勉強してみせるという意欲が必要です。
ＩＴアーキテクトの育成のためには
私は、IT アーキテクトになるために、最も重要なもの
は、「組織的な育成」ではないか思っています。IT アーキ
テクトになるためには、それなりの経験を積む必要があり
ますので、IT アーキテクトとしてキャリアアップしたい
と考えている技術者には、組織として、そういった経験が
積めるような場を与えることが必要です。
当社の IT アーキテクトには、IT スペシャリストからプ
ロジェクトマネージャを経て、IT アーキテクトになった
という人が多いのですが、これも、組織的な判断があって
のことです。やはり、IT アーキテクトとしてキャリアア
ップしていくためには、個人の努力だけではなく、組織と
しての配慮、つまり「人財」育成戦略も重要です。
「ＩＴアーキテクト」という仕事
私は、実は、「アーキテクト」という言葉が日本で使わ
れるようになる前から、「アーキテクト」を自称していま
した。昔は、「アーキテクト」と言っても、誰も分からな
いので、「（設計士）」という言葉を付けていたんです。
昔と比べたら、今は「IT アーキテクト」という言葉も
登場し、その必要性も、業界内では徐々に認識されるよう
になってきました。しかし、まだユーザーの側では、「IT
アーキテクト」と言っても、分からない人がほとんどであ
るというのが実情です。
しかし、IT アーキテクトに対する認知度は低くても、
IT アーキテクトが担う仕事に対する需要は多い、と私は
感じています。グローバル競争の中で、企業が新規システ
ム投資に慎重になり、情報サービス業は、明らかに苦戦を
強いられています。しかし、私は、この情報サービス産業
の伸び悩みの原因は、企業に対して、新規システム投資の
メリットを分かり易く説明できる人材が少ないからでは
ないか、と考えています。企業も昔に比べて、暗黙の了解
での IT 投資を控えるようになっており、緊急性や必要性
が極めて高い投資案件にしか手を出さないようになりま
した。しかし、だからこそ、「現状」と「あるべき姿」を
明確に示し、「現状」を変えることによって得られるメリ
ットを企業側に分かり易く伝えるために、IT アーキテク
トが活躍すべきなのです。
「IT アーキテクト」を知らなかったお客様も、実際に
プロジェクトを進める中で、その仕事の重要性を充分理解
してくれます。まずは「結果をもって示す」こと。これが、
今の IT アーキテクトに必要なことなのです。
※ 聞き手：村上和正 （IT スキル標準 プロフェッショナル・コミュニティ IT アーキテクト委員会委員）
21
ＩＴアーキテクト紹介③ 株式会社豆蔵 羽生田栄一氏
ＩＴアーキテクトとしての私
この世の中のすべてを知りたい ―― そんな野望から、
学生時代は、情報科学科の枠にとらわれず、哲学から国際
関係論に至るまで、様々な分野を学びました。そして就職
先で Smalltalk という言語に出会い、そこで使われていた
「オブジェクト指向」という概念に魅せられました。世の
中のすべての事象をオブジェクトとして表現するこの概
念を使えば、世の中のすべてが表現できる ―― これぞ自
分がやりたかったことだと直感しました。そこから、オブ
ジェクト指向に基づくシステム設計を手掛けるようにな
り、小中規模のプロジェクトを数多く経験してきました。
現在は、オブジェクト指向コンサル・教育をビジネスとし
つつ、新たな開発方法論の作成に挑戦しています。
これまでに経験したプロジェクトの中でも、特に面白か
ったのは、「役割場」という新しい概念を使ったシステム
設計です。この「役割場」という概念は、今でこそ「アス
ペクト指向」をいう呼び方をされるようになりましたが、
ビジネス目的ごとに「役割場」を設定し、各場に登場する
「ロール」を串刺しにするとそれが「オブジェクト」にな
るという、当時はまだ目新しい概念でした。このプロジェ
クトでは、この概念をベースに、「メロン」と「レモン」
と名づけた独自方法論やツールも編み出し、欧米輸入でな
いオリジナルの手法を用いたシステム開発の経験として、
自分の中での大きな転機になりました。
私の考える「ＩＴアーキテクト」
私は、経営上のニーズと IT 技術を結びつけるのが「IT
アーキテクト」であると思っています。つまり、経営戦略
や経営上の課題についても理解した上で、それを実現した
り解決したりするための手段として、IT 技術を活用する
ことができる人材、それが、「IT アーキテクト」なのです。
そのため、IT アーキテクトには、複数の経営課題と複数
の有用な技術とを、適切なプロジェクト(群)を通して結び
付けるという、ゼネラリスト的なスキルとダイナミックな
役割が要求されます。
ＩＴアーキテクトにとって大切なもの
IT アーキテクトにとって大切なものとして、私は、次
の 3 つを挙げたいと思います。1 つめは、「知的・精神的
なスタミナ」です。幅広い知識を吸収し、自分のものとし
ていくためには、このスタミナが不可欠です。2 つめは、
「国語力」です。これは、「ものごとを論理的に理解し説
明する能力」ですが、さらに踏み込むと「相手の立場を理
解し、相手の立場に立って分かり易い言葉や視点で話す能
力」という意味も含まれます。3 つめは、「ユーモア」で
す。これは、「自分自身も含めた物事を、一歩引いて客観
的に見ることができる能力」と表現することができるでし
ょう。例えば、難問にぶつかった時に、ちょっと手を止め
て冗談を口にし、目の前の障害から一歩退いてみると、難
問の解決の糸口が見えてきたりするものです。またユーモ
アは、チームワークを高めたり困難な交渉を進めたりする
上でも欠かせない資質です。これらの 3 つの資質は、複合
設計で著名な元 IBM の G.J.マイヤーズが述べているもの
で、私は、これらをずっと自分の座右の銘にしています。
IT アーキテクトとして重要な資質をあと 1 点挙げると
すれば、あとは「全体観」でしょう。これは、適切な視点
から対象を抽象化・モデル化して理解し、全体を見渡すこ
とができる能力です。常に全体を俯瞰して、機能と制約、
リスクとコスト、この「全体観」は、チームワークとモチ
ベーションを意識しながら、組織やシステムをデザインす
ることを求められる IT アーキテクトには、必須の資質で
あると言えます。
羽生田氏プロフィール 株式会社豆蔵
取締役会長／技術士（情報工学部門） オブジェクト指向による開発方法論を日本に紹介し、その普及と実践に携わる。今回
は、自身の取り組みを「IT アーキテクト」という側面からとらえ、その思いを語った。
22
ＩＴアーキテクト向きの人材とは
私が、ある技術者が「IT アーキテクト」としての適性
を備えているかを判断する場合には、まず、その人が「技
術的な基礎をしっかり持っているかどうか」を見ます。こ
れは、しっかりとしたプログラミング・スキルとソフトウ
ェア・エンジニアリングの常識をカラダで身につけている
ということです。「カラダで身につけている」とは、単に
知識として知っているだけでなく、「そのモジュールはテ
ストしづらい」といったことなどが直感として分かること
を意味します。そして次に、「技術だけに留まらず、モデ
リング等の抽象化スキルから、ビジネスについての知識や、
コミュニケーションや組織論等も含めて、幅広い分野に興
味を持っているか」をチェックします。前にも述べたよう
に、IT アーキテクトには、懐の広い知識が必要とされま
すが、それを習得するための核となるのは、知的好奇心の
強さと人生に対する向上心をおいて他にありません。そし
てさらに、「『全体観』を持つことができるかどうか」を見
ます。この「全体観」は、例えば、面接の場において、場
の雰囲気や面接官の意図を察知できているか、自分に期待
されている話の方向性が理解できているか、といった点か
らチェックします。この能力は、顧客の意図や経営者の本
当のニーズを推し量るときに必要とされる重要な能力で
あり、さらに、IT アーキテクトとして、プロジェクトマ
ネージャの苦労は理解しつつ言うべきことは言う、という
ようなマネージメント能力＝バランス感覚＝デザインセ
ンスに繋がっていくものです。
ＩＴアーキテクトの育成のために
実績や経験をレベル基準の中に明示的に組み込んだ IT
スキル標準の「達成度指標」はよく工夫されたものですが、
その基準に沿ってスキルを伸ばしていくには、そのために
用意された環境が必要です。各企業で業務として行うプロ
ジェクトの中で、人材を育成することは可能ですし、その
ような厳しい環境の中から実践的な人材が育っていくの
は確かでしょう。しかし、今の日本の企業では、業務上は
どうしても、人材を育成することよりも、プロジェクトを
完成させることを優先せざるを得ません。実際のプロジェ
クトは、人材の育成という面から見ると、理想的な環境で
はないのです。本来、そのような育成環境は大学の専門教
育が用意すべきなのでしょうが、日本での実態はそのよう
にはなっていません。そこで私は、業界としてコンソーシ
アムのようなものを立ち上げ、そこで、IT アーキテクト
を育成するための環境を作るべきだと主張しています。そ
こでは実際に、スキルアップを目指すエンジニアがプロジ
ェクトに取り組みながら、ハイレベルな IT アーキテクト
の指導を直接受けられるようにしたいと考えています。こ
れは、IT スキル標準と併せて、業界全体で取り組んでい
くべき重要な課題です。
次世代のシステム開発 IT アーキテクトの育成のためのコミュニティの重要性
が指摘されていますが、私は今後、特にハイレベルの IT
アーキテクトを目指す人は、コミュニティにただ参加する
だけでなく、その企画や運営にも関わり、組織の中で必要
とされる能力を磨いていくことが重要になってくるだろ
うと思っています。次世代の IT アーキテクトには、ユー
ザーや複数のクライアントと関わり合いながら、さまざま
な人の考えをまとめて、収束させるプロセスに積極的に携
わっていく能力が必要です。これは、単なるコミュニケー
ション能力とは異なる“ファシリテーション能力”と言う
べきスキルですが、これからの IT アーキテクトにとって
は、こういった能力も重要になってくるでしょう。また、
このスキルは、XP（Extreme Programming）を含むアジ
ャイル開発プロセスにも通じるものです。
“日本発”のＩＴアーキテクト
インドや中国へのオフショア開発が普及する中で、今
後、日本がコア・コンピタンスとしていくべきなのは、“経
営のビジョンと IT 技術をつなぐ能力”ですが、これはま
さに、IT アーキテクトのスキルそのものです。そのよう
な意味で、今後の日本のソフトウェアを支えていくのは、
IT アーキテクトなのだと言えるでしょう。
IT スキル標準も、システム開発における専門化と役割
分担という欧米からの流れを受けて作られたものですが、
そこに日本独自の価値観を取り入れることはできないも
のかと私は考えています。産業界において日本は、専門化
志向よりもゼネラリストの目での摺り合わせ志向で成功
を収めてきましたが、それはこの業界にも充分当てはまる
のではないか、つまり、欧米発ではない日本的な緻密さや
身体感覚を生かした独自のスタイルがあるのではないか、
というのが、今の私の関心事です。特に、IT アーキテク
トは、技術とゼネラルな全体観の融合が求められる職種な
ので、日本的な良さをうまく取り入れることができるはず
です。日本独自のスタイルを持った IT アーキテクトの育
成 ―― これからの日本のソフトウェアの鍵はこれです。
※ 聞き手：吉田幸彦
（IT スキル標準 プロフェッショナル・コミュニティ IT アーキテクト委員会委員）
23
ＩＴアーキテクト紹介④ 住商情報システム株式会社 菅原孝二氏
私の今の仕事とプロフィール
当社は、IT 全般に関わる高品質なワンストップサービ
スを提供しています。中でもアプリケーション開発は、当
社の主要な事業分野であり、上流工程から下流工程までの
すべてをカバーしています。その中で私は、開発業務にお
けるトラブル対処などの社内サポートから、社内技術ガイ
ドの策定などの社内開発基盤の整備に至るまで、幅広い業
務に携わっていますが、社内開発基盤の整備などは、まさ
に社内の“IT アーキテクチャ”の整備とも言える仕事で
あり、そういった意味では、私の仕事も「IT アーキテク
ト」の仕事であると言えると思います。
現在、IT プロフェッショナルとして仕事をしている私
ですが、実は学生時代から、この分野の専門家としてさま
ざまな活動をしていました。当時、マイコンが世の中に出
回り始めた頃だったので、情報処理の世界に惹かれ、アセ
ンブラを習得して、ソフトウェアの作成などを行っていま
した。その後、情報処理資格も取得し、さらにスキルに磨
きをかけるうちに、学内の先生の間でも評判になり、学生
ながら、講師として企業へ呼ばれるまでになりました。
卒業後は、新卒社員として現在とは別会社に入社しまし
たが、入社して間もなく新入社員研修を減免されて、パー
ソナルコンピュータ事業部に早期に配属され、インストラ
クターの教育等を任されるようになりました。その会社で
は、講師指導の他にも、技術支援や市場調査など、さまざ
まな仕事に携わり、幅広い経験を積むことができました。
その後は、専門学校の設立準備局として、学校の立ち上
げにも参画し、学内で使う教育システムの選定からシステ
ムの構築に至るまで、すべてを担当しました。ここでは、
何でも一からすべて自力で行わなくてはならず、苦労の連
続だったのですが、今では、それもまた良い経験になった
と感じています。
現在の会社では、トラブルシューティングに長く携わっ
てきました。トラブルシューティングは、プロジェクトに
問題が発生してから、その解決を任される仕事なので、構
築中のシステムやそのプロジェクト体制の全貌を短期間
で把握し、最適な解決策を見つけ出さなくてはいけません。
その際、システムを作っている技術者や顧客を対象に話を
聞いたり、交渉や調整をしなければならないことも多いの
で、実際にトラブルを解決するためには、技術的なスキル
だけではなく、コミュニケーション能力やリーダーシップ
も含めた、非常に幅広い、高度な能力が必要とされます。
しかし、そういったトラブルシューティング業務に数多く
取り組んでいくうちに、そのシステムに何が欠けているの
か、どこが問題なのか、という点が、非常によく見えるよ
うになりました。つまり、数多くのシステムを第三者的な
目で見る訓練を積むことによって、私は「IT アーキテク
ト」として、自分をレベルアップさせることができたので
す。トラブルシューティングでスキルを磨いて IT アーキ
テクトになったという例は、それほど一般的ではないかも
しれませんが、それも、IT アーキテクトへのキャリアパ
スの一つとして考えられるものだと思います。
ＩＴアーキテクチャの進化 ～ 家から街へ
IT アーキテクチャは、時代と共に進化しています。メ
インフレームからクライアント／サーバ型システムへと
いう移り変わりは、一般には、“「集中」と「分散」”とい
う言葉で表現されることが多いのですが、私は、IT アー
キテクチャの進化は、より正確には、“「統合」と「拡大」
の繰り返し”と表現されるべきなのではないかと思ってい
ます。ネットワークや分散コンピューティングに関する技
術が進み、確かにシステムは分散化しているように見えま
す。しかし、一方では、グリッド・コンピューティングの
ような概念も登場し、大きな目から見たら結局は、分散化
したものを統合し、一つの大きなシステムとして利用する
菅原氏プロフィール 住商情報システム株式会社
技術グループ 技術部 副部長 現在は、トラブルシューティングや社内システム基盤の整備に携わる。多彩な業務経
験により培われた幅広い知識とスキルを持つ“マルチ型”の IT アーキテクト。
24
方向へ動いていると言えるのです。
単体で完結していた昔のシステム構築が「家」を建てる
ことに相当するとすれば、企業全体を視野に入れるように
なった現在のシステム構築は、「ビル」を建てるようなも
のだと言えるでしょう。今後のシステム構築は、さらに、
「街」を造るところまで発展していくはずです。つまり、
一つの企業の枠にとどまらない、多くの企業や学校などを
含んだシステムの開発が、今後の主流になってくると予想
されるのです。
そのようなシステム開発の変化に伴って、IT アーキテ
クトの仕事も変化しています。従来は、単体で完結するよ
うなシステムを設計することが IT アーキテクトの仕事で
したが、これからは、もっと大規模で複雑なシステムの設
計が主な仕事となってくるでしょう。そうすると、一人の
IT アーキテクトだけでは担いきれないので、IT アーキテ
クト以外の技術者も含めたエキスパートの力を結集させ
る必要が出てきます。そのような変化を考えると、これか
らの IT アーキテクトには、うまく技術者をまとめ、コー
ディネートしていく能力が、ますます必要とされるように
なってくるはずです。
さらに、上に述べた「拡大」と「統合」が一層進んでい
く中で、IT アーキテクトには、様々な分野について、充
分な知識を持っておくことが求められています。特に、最
近注目を集め始めた「ユビキタス」が現実化されていけば、
もはや「IT」=「コンピュータ」ではなくなってしまいま
す。情報家電や携帯電話などの小型情報端末を取り込む形
で、「IT」の基盤そのものが変わろうとしているのです。
そのような状況の中で、IT アーキテクトは、最新の技術
動向についても常にチェックし、次々と新しい知識を仕入
れて、「拡大」と「統合」のスピードに対応していかなく
てはならないのです。
ＩＴアーキテクトになるために
IT アーキテクトとして活躍するためには、まず、どん
な分野でもよいから、ある一つの分野のエキスパートとし
て、周囲に認められる必要があります。エキスパートとし
て認められるようになると、その他の分野についてもいろ
いろと情報が入ってくるようになるものです。一度、ある
分野のエキスパートとして認められれば、そこを軸として、
自分の領域を広げていくことができます。
また、日本の社会において重要な要素として、「ポジシ
ョンパワー（社会的地位）」を挙げることができます。交
渉ごとなどの際にモノを言うのは、やはりこのポジション
パワーです。先に述べたようなエキスパートして認められ
れば、それが、ある種のポジションパワーになることもあ
るでしょう。やはり、交渉の中でリーダーシップを発揮す
るためには、少なくとも周りから認められる存在であるこ
とが必要です。
あとはもちろん「コミュニケーション能力」です。交渉
ごとの他にも、顧客へ分かり易く説明や提案を行う際にも、
コミュニケーション能力が必要不可欠なものであること
は言うまでもありません。
「人」の観点からシステムを見よう
トラブルシューティングを行う際、トラブルが起こっ
ているプロジェクトで、その原因を調べてみると、顧客が
求めるものと、システムの志向が微妙にずれている、とい
うことがよくあります。つまり、根本的なシステムのアー
キテクチャに、顧客の要求をうまく反映できておらず、そ
れが発展してトラブルにつながっているというケースが
意外と多いのです。
その原因は、「顧客のニーズをきちんと把握できていな
いこと」にあることがほとんどです。特に技術者には、自
分が作りたいと思っているものに固執してしまい、顧客が
求めているものに対して鈍くなってしまう傾向がありま
す。これは、技術者の良くない一面ですが、そのような場
面で、顧客のニーズに合うように、技術者をうまくまとめ
ていくのも、IT アーキテクトの重要な仕事です。
技術的な責任者としてイメージされがちな IT アーキテ
クトですが、良いシステムを作るためには、技術者をまと
めたり、顧客と交渉したり、といった仕事にも、時には踏
み込まざるを得ません。システムは最終的には人が使うも
のなので、技術について考えるだけでは、良いシステムは
できないからです。技術的に良いというだけではなく、シ
ステムを使うユーザーやシステムを所有するオーナーな
ど、そのシステムに関わる様々な人たちが「役に立つ」と
認めて初めて、それが良いシステムであると言うことがで
きます。システムの価値は、そのシステムで使われている
技術によって決まるのではなく、そのシステムに関わって
いる「人」が決めるものなのです。
様々な技術を駆使して作るシステムも、結局は「人」が
使うものであり、「人」の役に立たなければ意味のないも
のになってしまいます。今後、IT アーキテクトを目指す
方々には、「人」の観点からシステムを見る姿勢、それを
ぜひ、忘れないでいただきたいと思います。
※ 聞き手：湯浦克彦
（IT スキル標準 プロフェッショナル・コミュニティ IT アーキテクト委員会委員）
25
ＩＴアーキテクト紹介⑤ ＵＦＪＩＳ株式会社 藤澤秀浩氏
新しい技術への挑戦
銀行へ入社した当初、私は、営業店で、店頭回りの事
務を手始めに、融資などの銀行業務に従事していました。
ところが、当時社内では、勘定系ホストシステムの大規模
な更改が行われていたため、やがて開発が本格化するとと
もに、私はシステム開発部署へ異動になりました。
1989 年からは、世界中に分散する海外支店のシステム
を大型の中枢センターにつなぐ、グローバルな「ディーラ
ー支援システム」の開発に参加しました。このプロジェク
トでは、UNIX ワークステーションを用いて、クライアン
ト／サーバ型のシステムを開発しましたが、UNIX ワーク
ステーションを使った基幹系システムは、まだ一般的では
なかったため、ミドルウェアや開発ツールなどもあまり揃
っておらず、このプロジェクトでは、そのほとんどを一か
ら自作しなくてはなりませんでした。
1996 年からは、振込発信の事務を効率化するシステム
の開発にプロジェクトリーダーとして参画しました。この
プロジェクトでは、分散系システムを勘定系ホストにつな
ぐという、当時としては社内初の試みでした。振込発信は
時限性がある上に、トランザクションも多く、最もミッシ
ョンクリティカルな業務の一つであるため、このシステム
開発は、非常に難度の高いものとなりましたが、それゆえ
に、カットオーバーの際には、非常に大きな達成感を得る
ことができました。
これまで私が取り組んできたプロジェクトは、すべて当
時としては非常に新しい技術や方法を使っており、この点
は、私の経歴の一つの特徴と言うことができると思います。
ちなみに、現在の部署で手掛けているのは、インターネッ
トや携帯電話などを使った新しい販売チャネル向けシス
テムの開発ですが、これも、新しい技術に大いに関係して
います。
私を支えてきたもの
私は、SE を大きく分けると、3 種類のタイプに分けら
れるのではないかと思っています。一つめは、常に新しい
プロジェクトに携わる SE です。二つめは、メンテナンス
の上手な SE です。三つめは、いわゆる“火消し”が得意
な人で、プロジェクトに問題が発生した時に、そのトラブ
ル対処を任される人です。この分類は、私がこれまで数多
くの SE に接する中で感じたものなのですが、私はこの分
類を使うと、一つめの「常に新しいプロジェクトに携わる
SE」に分類されると思います。
SE として、また、IT アーキテクトとして、これまで私
の原動力となってきたのは、「常に最先端の技術に触れ、
それを仕事に使ってみたい」という気持ちです。金融業界
におけるシステム開発は、これまでの日本の IT を常にリ
ードしてきました。そういった意味で、私はいつも、「自
分は常に日本の最先端を走っているのだ」という自負を持
っていました。また、そのような業界でシステム開発に携
わる者として、「ユーザーではあるけれども、ベンダーよ
りも豊富なスキルを持っていたい」と常に思ってきました。
ベンダーよりも豊富なスキルを持っていれば、ベンダーの
意見に振り回されず、ベンダー側と対等に交渉することも
できるようになります。このような私の考え方により、私
は「常に新しいプロジェクトに携わる SE（IT アーキテク
ト）」になっていったのでしょう。
新しい技術には未熟なものも多いので、それを使ってシ
ステム開発を行うと、ほとんどの場合、多くの問題が発生
します。そのような意味では、新しい技術を使ったシステ
ム開発には、常に大きなリスクが伴います。確かに、すで
に確立された方法や技術を用いてシステムを作った方が、
安全かつ確実です。しかし、誰もやったことのないことに
敢えて挑戦することによって、新しい技術を実用化し、日
本の IT の発展に寄与することができるのです。それは、
藤澤氏プロフィール UFJIS 株式会社
ダイレクトチャネル開発部 部長 現在まで 17 年以上、ユーザーとしての立場から、常に最先端の技術を用いたシステム
開発に携わる。本シリーズでは唯一の、ユーザー側 SE の立場に立つ IT アーキテクト。
26
次々と技術が移り変わるこの業界における、ある種の醍醐
味ではないかと、私は思っています。
ＩＴアーキテクトにとって大切な資質
IT アーキテクトにとって大切な資質として、まず始め
に挙げられるのは、やはり「コミュニケーション能力」で
しょう。このコミュニケーション能力は、「物事の本質を
見抜く力」と言い換えることもできます。システム開発を
行う際、さまざまな人の話を聞く機会があると思います。
しかし、誰かの話を聞く場合、「自分の質問に対して、相
手は常に 100%の回答を返してくれるわけではない」とい
うことをいつも意識しておかなくてはいけません。業務の
問題点などについて話してもらう場合でも、話している相
手が、常に問題を正しく把握しているとは限りません。ま
た、問題を大まかに把握している人でも、その問題の本質
まではつかみきれていないこともあります。しかし、その
ような場合でも常に、「問題の本質はどこにあるか」とい
う点に注意して人の話を聞き、100%ではない回答からも、
その核心部分を見抜かなくてはなりません。そのようにし
て、人の話から、その本質や核心を読み取ることができる
人が、“コミュニケーション能力の高い人”であると言え
るのです。
他にも、ITアーキテクトにとって重要な資質として、「ス
ピード感」が挙げられます。これは、「問題に対して、素
早く対処する能力」です。問題というのは、始めは些細な
ものであっても、対処しないで放置しておくと、大問題へ
と発展する可能性を持っています。しかし、そうなってし
まう前に、常に手を打っておかなくてはいけません。上流
工程で発生した問題を対処せずに放置し、それが下流工程
で大きな問題となった場合、その対処には上流工程で対応
した場合の何倍もの時間と体力がかかります。8 割の出来
でもよいから、スピード感を持って問題を片付け、常に影
響が拡大しないようにしておくことが大切です。
また、「とことん追求する姿勢」も重要です。私もこれ
まで、分からないことがあると、疑問点がなくなるまで調
べ、自分を納得させるという姿勢を貫いてきました。そう
することによって、新しい知識を次々と吸収していくこと
ができますし、問題解決の際に、真の原因を見つけたりす
ることもできます。この「とことん追求する姿勢」も、IT
アーキテクトにとって重要な資質の一つです。
さらに、「徹底して仕事に打ち込む姿勢」も大切です。
私は、入社 2 年目の頃、仕事の取り組み方について、上司
に非常にこっぴどく叱られたことがあります。負けん気が
強かった私は、叱られた当初は、悔しい気持ちでいっぱい
だったのですが、冷静になって自分を振り返ってみて、自
分自身に対して「やっぱり自分は甘かった」と思ったので
す。自分は徹底して仕事をしていない、そこがまだ甘いの
ではないか ―― そう思った私は、それを機に、「24 時間
365 日仕事のことを考えよう」と思うようになりました。
今思い返せば、私にとっては、あの時上司に叱られた体験
が、「徹底して仕事をする」姿勢を身につけるための一つ
の転機になっています。
システム開発の「温故知新」
メインフレームからクライアントサーバ型システム、
そして最近では J2EE へと、システム開発の際に使われる
言語や技術などは、どんどん移り変わっています。しかし、
そのような目まぐるしい変化の中にあっても、オンライン
トランザクションの処理の仕方など、システム構築におけ
る根本的な部分は全く変わっていません。技術は移り変わ
っても、やはりその元となる“基本”の部分は、そうそう
変わるものではないのです。また、トラブルの原因も、突
き詰めて考えると、結局は、昔から言われていることと同
じことが原因であったりします。古い技術がすぐに役に立
たなくなってしまうように思われがちなこの業界でも、
“基本”や“温故知新”が意外と大切なのです。
しかし、それを理解しているのは、昔からの技術を知っ
ているベテランの技術者たちであり、今の若い人たちにま
で、それが十分に伝わっているとは言えません。我々が大
切にしているこの“温故知新”を、どのように次の世代に
伝えていくかは、業界全体としての大きな課題であると言
えるでしょう。
若い方々へのメッセージ
私が、SE（IT アーキテクト）を目指す若い人へのメッ
セージとして、いつも言っていることがあります。それは、
この業界は、「無限に可能性がある世界」だということで
す。この業界では、努力して身に付けたスキルは必ず評価
されます。つまり、努力が自分の市場価値に直結する世界、
それが、この業界なのです。逆に言えば、努力しなければ
何も身につかず、まったく評価もされません。しかし、常
に努力を怠らない人にとっては、とても頑張り甲斐がある
世界だと言えるのではないでしょうか。
自分の腕一つでいくらでも可能性を拓いていけること。
それが、この世界の魅力であると、私は思っています。
※ 聞き手：五味利明 （IT スキル標準 プロフェッショナル・コミュニティ IT アーキテクト委員会委員）
27
ＩＴアーキテクト紹介⑥ 株式会社シーエーシー 真野 正氏
ＤＯＡとの出会い
システム開発において、そのシステムで扱うデータの
構造に着目してシステム設計を行う手法を「データ中心ア
プローチ（Data Oriented Approach = DOA）」と呼びます
が、私が、この DOA を用いて開発を行うプロジェクトに
初めて参画したのは、1980 年代の初めことでした。それ
まで私は、製薬会社の生産管理システムなどの、ビジネス
系の業務アプリケーションの開発に携わっていたのです
が、そこで、当時としては最新のアプローチであった DOA
に触れ、それがきっかけとなって、データベース設計やデ
ータモデリングの分野のスキルを深めていくことになり
ました。
データベース設計やデータモデリングを専門とする IT
アーキテクトは、「データアーキテクト」と呼ばれ、アメ
リカなどでは広く知られています。日本での認知度はそれ
ほど高くはありませんが、データ構造の設計は常にシステ
ム開発の根幹であるため、データアーキテクトは、システ
ムの開発において、常に重要な役割を担っています。デー
タ構造の定義を最初にきっちりと行うことによって、シス
テム開発の生産性やシステムの品質をより一層高めるこ
とができるのです。現在では、“データ”ではなく、“オブ
ジェクト”を中心にしたアプローチである「オブジェクト
指向」もよく使われるようになりましたが、オブジェクト
指向によるシステム開発においても、データ構造の設計は
不可欠であり、そこには必ず、データアーキテクトのスキ
ルが必要とされています。
DOA を専門にするようになってからずっと、顧客企業
の技術者を主なお客様として、データ設計の分野で仕事を
してきました。現在は、その経験を活かして、当社のコン
サルティングビジネスユニットに所属し、ビジネス戦略オ
フィスのソリューションマネジャーとして、モデリングア
プローチを使ったコンサルティング業務に取り組んでい
ます。
ＩＴアーキテクトに必要な知識とは
現在は、システム開発の技術も多様化し、技術者が習
得しなくてはならない知識やスキルも、昔と比べて膨大な
ものになっています。しかし、IT アーキテクトのように、
システムの基盤部分の設計に携わる技術者にとって、本当
に重要な知識というのは、実は昔とそれほど変わってはい
ないのです。
今の技術者が習得しなければならない知識の多くは、例
えば Oracle や各種言語など、個別の製品に関するもので
す。しかし、IT アーキテクトにとって本当に重要な知識
というのは、個別の製品についての知識よりも、もっと本
質的な知識であると思います。例えば、昔は、アルゴリズ
ムなど、情報処理の分野の基本を、若手の技術者にしっか
りと覚え込ませました。基本の習得には時間もかかります
が、そういった基本をしっかりと習得しておけば、新しい
知識を学ぶ際にも、すぐに応用がききます。基本をしっか
りと学ぶことのないまま、個別の製品についての知識ばか
りを身に付けても、その製品が使われなくなった時に、そ
の知識はまったく役に立たないものになってしまいます。
そういったことを避けるためには、やみくもに製品につい
ての知識を身に付けるのではなく、多少時間がかかっても
よいから、すべての製品の基盤となっている基本の部分に
ついて、しっかりと学習する必要があるのです。
最近は、システム開発と言っても、まったくゼロから開
発を行うのではなく、パッケージをベースにして行う開発
も増えており、 “基本”の部分であるシステムの中身や
構造について気にしなくても、システムを導入できる傾向
が進んでいます。また、最近になって、各所で、共有可能
な“リファレンス・モデル”などについての検討が行われ
ていますが、そういったものが普及していけば、さらにそ
真野氏プロフィール 株式会社シーエーシー コンサルティングビジネスユニット ビジネス戦略オフィス ソリューションマネジャー
データ設計・モデリングを専門とする IT アーキテクト。現在は、データアーキテクト／
コンサルタントとして活躍し、経営戦略へのモデリング活用の可能性を模索している。
28
の傾向に拍車がかかるのではないかと、私は思っています。
特に、若手の技術者に対して、基本知識の習得の大切さが、
今一度、見直されるべきなのかもしれません。
外部コミュニティへの参加
これまで私が、データアーキテクトとしての知識やス
キルを深める上で、最も大きな影響を受けてきたのが、会
社の業務とは直接的なつながりのない技術者同士のコミ
ュニティです。私はこれまで、多くの社外コミュニティに
参加し、自分自身のスキルアップや人脈づくりに役立てて
きました。
DOA を用いるプロジェクトに初めて参画した頃、当時
まだ新しかったDOAという手法についての理解を深める
ために、「IRM（Information Resource Management）研
究会」という研究会が発足したのですが、当社がその研究
会の事務局を務めていたことがきっかけとなって、私もそ
の研究会に参加することになりました。この研究会には、
さまざまなメーカーやベンダーから意欲的な技術者が参
加し、月に 1 回のペースで勉強会が開かれて、そこで、
DOA についての実践を含めたさまざまな学習を行ってい
ました。この研究会に参加することによって、DOA につ
いて知識を深めることができたばかりではなく、同じ分野
に興味を持つ仲間を見つけることもできて、それが、私に
とっては非常に励みにもなりましたし、さらなる勉強に向
けての刺激にもなりました。
上の研究会の他にも、IBM ユーザーが集まって様々な
研究部会を開催しているコミュニティ「日本ガイドシェ
ア」でデータベース「DB2」の研究会にも参加していまし
た。この研究会は、日本 IBM から、当時 DB2 の NO.1 と
言われた技術者が講師として呼ばれ、参加者に DB2 につ
いての講義をしてくれるというもので、私にとっては非常
に勉強になりました。
私は、そのように、これまでさまざまなコミュニティに
参加してきましたが、現在は、「DOA +プラス
」という研究会
を立ち上げ、そこで、DOA と OO（Object-oriented = オ
ブジェクト指向）の融合というテーマについての研究を行
っています。
私が外部コミュニティに積極的に参加していた背景に
は、私が興味を持っていた DOA などのテーマに対して、
社内で同じように興味を持っている技術者が少なかった
ので、より深く勉強するためには、社外で勉強した方が効
果的だったという事情もありました。また、社内で勉強す
るよりも、社外で勉強する方が気軽に勉強できるという、
私個人の性格も多少関係しているかもしれません。しかし、
いずれにせよ、社外の技術者が集まるコミュニティへの参
加は、実務上でのスキルアップの他に、私自身の成長に非
常に大きな影響を与えてきました。そういった意味では、
当時はまだ、社外コミュニティへ参加するということが珍
しかったにも関わらず、それを許可してくれた会社の寛容
さと先見性にも、感謝の気持ちを持っています。
私は、比較的恵まれた条件の中で、さまざまな外部コミ
ュニティに参加してきましたが、業務で忙しく、なかなか
社外の活動に参加することなどできない、という人も多い
ことでしょう。また、社外のコミュニティ活動に参加した
いと思っていても、会社の中まで、なかなかそういった情
報が回っていかないこともあります。しかし、会社の外に
出て勉強すると、自分が思っている以上に、いろいろなも
のを得ることができます。それは、人脈であったり、独学
では得られない知見であったり、勉強に対する刺激であっ
たりするわけですが、プロフェッショナルとしてスキルア
ップしていくためには、そのような外部のコミュニティで
しか得られないものが、非常に重要な意味を持ちます。社
内の実務経験からも、さまざまなものを得ることができま
すが、やはり、ハイレベルの技術者として成長していくた
めには、忙しい業務の合間を縫ってでも、積極的に社外の
コミュニティに参加し、社内で学べるもの以上のものを学
んでいく必要があるのではないでしょうか。
モデリングの可能性を求めて
前にも少し述べましたが、私は、これまでデータモデ
リングなどに長く携わってきた経験を活かして、現在、EA
のビジネスプロセスモデリングに見られるようなモデリ
ングアプローチを使った経営戦略のコンサルティング業
務に取り組んでいます。モデリングは、お客様の頭の中に
あるものを聞き出して形にする手法であり、お客様にとっ
ても自分にとっても、なんとなくモヤモヤしていたものを、
明確な形にして示すことができるという点に、私は面白さ
を感じています。このモデリングは、物事の姿を明確にす
ることが求められる、さまざまな場面で活用できる可能性
を持っていますが、私はこれを、経営戦略の立案に活用で
きないものかと考え、今、その方法について模索している
ところです。今後は、経営戦略立案の場面におけるモデリ
ング活用の可能性について、さらに追求していきたいと考
えています。
※ 聞き手：長坂 実 （IT スキル標準 プロフェッショナル・コミュニティ IT アーキテクト委員会委員）
29
ＩＴアーキテクト紹介⑦ 新日鉄ソリューションズ株式会社 早瀬久雄氏
新しいものをビジネスにする
私は、現在は、マーケティング部に所属していますが、
1 年前まではずっと、現場の技術者として活躍していまし
た。
技術者としての私の進路を決めるきっかけになったの
は、入社 3 年目に携わった UNIX 上でのミッションクリ
ティカルなシステムの開発でした。そこで、Sun にはそれ
までなかった HA（High Availability = 高可用性）ソリュ
ーションを考案したのですが、それが、ビジネスとして使
えそうだということで、それを基軸として、ストレージや
クラスタリングなども含めた基盤ソリューションの提案
を、ビジネスとして展開していくことになったのです。し
かし、ビジネスとして展開していくと言っても、始めのう
ちは、4、5 人の体制で行っていましたので、営業やコン
サルティングから、開発、メンテナンスまで、何でも自分
達で行っていました。
その後、基盤ソリューションの提案がビジネスとして軌
道に乗ってきたので、私はそこを離れ、コンサルティング
業務にシフトしてきました。2000 年頃からは、システム
研究開発センターという、研究開発とコンサルティングを
行う部署に移り、顧客のシステムの性能評価などを行って
いました。その後、再び現場の技術者として、UNIX を使
ったビジネス展開や、Linux のコンサルティング業務に携
わり、現在のネットワークやストレージ全般を対象とした
マーケティング部署に移りました。
マーケティングは、昔からやりたいと思っていました。
なぜなら、技術について理解するだけではビジネスにはな
らない、というのが私の持論だからです。その技術を組み
合わせるなどして、新しいものを作り出すことによって、
それがビジネスにつながっていくのだと私は思っていま
す。技術をビジネスにしていくためには、常に新しいもの
を生み出していくことが必要なのです。
お客様にとっての良い「先生」
仕事柄、私のお客様は、ベンダーや SI 企業が多いので
すが、そのようなお客様を相手にして仕事をする上で、私
がいつも心掛けていることがあります。それは、「IT アー
キテクトは、お客様にとって、良い先生であるべきだ」と
いうことです。やはり、技術的な専門家である IT アーキ
テクトは、技術者をお客様とする場合にも、お客様にとっ
て頼れる存在であるべきだ、というのが私の考えです。
お客様にとって良い先生であるためには、当然のことな
がらまず、高い技術力を持っていることが必要です。技術
力は、一朝一夕で身につけられるものではありませんが、
ハイレベルな IT アーキテクトとしては、少なくとも“こ
の分野であれば社内の第一人者”というくらいの、専門領
域を持つことができれば理想的です。技術力を身につける
ためにはどうしたらいいのか、という悩みをお持ちの方も
いると思いますが、私は、製品をきっかけにして、そこか
ら技術について深く学んでいくのがよいのではないかと
思っています。個別の製品についての知識は、その使い方
や機能を理解するだけに留まっていたら、その製品以外に
応用がききません。しかし、どんな製品も、ある程度汎用
的な技術や考え方などに基づいて作られていますので、個
別の製品の機能の奥にある、そのような本質的な部分につ
いても理解し、最終的には、その製品の設計が自分ででき
るくらい、その製品について理解することができれば、そ
の製品の理解を通じて、技術力を高めることができると思
います。
お客様にとって良い先生であるために、次に必要なのは、
お客様にとって必要な要件を見極める、ということです。
IT アーキテクトとして、高い技術力を持っていても、顧
客にとって必要な技術や解決策は何なのかを見極めるこ
とができなければ、その高い技術力をビジネスに結び付け
ることができません。お客様にとって必要な要件を見極め
早瀬氏プロフィール 新日鉄ソリューションズ株式会社 基盤ソリューション事業部
マーケティング部 NWプラットフォームグループ グループリーダー システム基盤設計を専門とする IT アーキテクトとして、ベンダーや SI 企業を対象とした基盤
ソリューションの提案を行う。その実績と経験を基に、現在ではマーケティングを担当。
30
る、ということは、自分の技術力を活かして仕事をしてい
くための条件でもあるのです。
また、お客様にとって分かり易く説明ができることも、
良い先生であるために必要なことです。技術に関する専門
用語などに日常的に接していると、お客様と話すような場
面でも、そういった専門用語を気軽に使ってしまいがちで
す。しかし、お客様に理解していただくことが目的である
場面で、お客様が理解できない言葉を使っても意味があり
ません。当たり前のことですが、お客様にとって良い先生
であるためには、お客様が分かり易いと思える言葉で話す
必要があります。私の大学時代の専攻は、土木工学だった
ので、私は、この業界に、まったく基本知識がない状態で
入ってきました。そのため、自分自身も難解な専門用語で
苦労した経験を持っています。でも、その苦労が今、お客
様に対して分かり易く話さなくてはならない場面で、非常
に役に立っていると感じています。
また、お客様にとって良い先生であるためには、良きア
ドバイザー役に徹することも必要です。私は、お客様の課
題の解決を依頼された場合でも、自分は解決に向けた選択
肢をいくつか提示する役に徹し、最終的にはその選択肢の
中から、お客様に解決策を選んでいただくようにしていま
す。解決策の決定をこちらに任せたいお客様もいらっしゃ
るので、ケース・バイ・ケースではありますが、原則とし
て、IT アーキテクトは先生役、つまりアドバイザーのよ
うな立場から、技術についての助言を行うのがよいのでは
ないかと、私は思っています。また、お客様に解決策とし
て選択肢をいくつか提示する場合には、極力、製品名を出
さないで、考え方を提示するように心掛けています。製品
名だけで話を進めると、その製品が持つ機能の本質が伝わ
りにくいことがあるからです。それを避け、本質的な情報
に基づいて、お客様に判断していただくために、具体的な
製品ではなく考え方を選択肢として提示するのです。
以上が、お客様にとって良い先生であるために、私が重
要だと考える条件です。私自身も、お客様にとって良い先
生になれたことが、自分が IT アーキテクトとして、ここ
まで実績を積むことができた一番の要因だと思っていま
す。
ＩＴアーキテクトの育成法
IT アーキテクトの育成は、PM やコンサルタントの育
成と並んで、当社においても大きな課題となっており、現
在、認定制度の検討など、さまざまな取り組みが行われて
いるところです。
ビジネスの現場では、タスクフォースが設置されたこと
があります。このタスクフォースでは、数人の技術者がチ
ームを組み、あるシステムの設計から実装までを、すべて
を自分たちの力で行いました。この取り組みは、非常に良
い成果を収めたので、現在では、このタスクフォースを組
織の中に組み込み、正式な組織の一部として運営していま
す。
特に若手の技術者には、ある程度の自由を与えて課題に
取り組ませ、上がそれを見守ることが必要だと私は考えて
います。上のタスクフォースも、ある程度の自由の中での
取り組みの一例として実施されたものです。IT アーキテ
クトの育成を考えるにあたっても、上のようなタスクフォ
ース型の実践環境は、一つの重要な参考例となり得るでし
ょう。
後進人材の育成も、ハイレベルの IT アーキテクトにと
っては、重要な仕事です。私自身が今あるのも、私を育て
てくれた上司がいたからだと私は思っています。この人材
育成については、これから私自身もしっかりと取り組んで
いかなくてはならない重要な課題であると考えています。
常にお客様の方を見て
IT アーキテクトとして仕事をする上で、最もやりがい
を感じるのは、「IT アーキテクトは、常に人の悩みを解決
する中心にいられる」という点です。技術的な知識を持ち、
解決策を考える際の要となる IT アーキテクトは、お客様
の課題を解決する際の中心的存在であると言えます。それ
ゆえに、自分が提示した解決策に対する責任も重くなりま
すが、それでもやはり、自分が中心となってお客様の悩み
や課題を解決できるというのは、非常にやりがいがあるも
のです。
しかし、ここで大切なのは、「常にお客様の方を見て仕
事をすること」だと思います。仕事を進める中では、社内
の人間関係や、自分自身の事情など、さまざまな問題が発
生します。しかし、最終的には、仕事はお客様のためにす
るものだということを、忘れずに仕事をするべきではない
でしょうか。自分の考えた案によって、お客様の課題を解
決することができ、お客様が自分を評価してくれると、そ
れがまた仕事に対するやりがいにもなります。今の若い
方々にも、社内の問題や自分の事情にとらわれず、「常に
お客様の方を見て」仕事をすることを心掛けていただきた
いと思います。
※ 聞き手：小池和雄 （IT スキル標準 プロフェッショナル・コミュニティ IT アーキテクト委員会委員）
31
5. プロフェッショナル・コミュニティ IT アーキテクト委員会の紹介
プロフェッショナル・コミュニティ
○ 設立趣旨
情報処理推進機構・IT スキル標準センターでは、IT スキル標準の改版や、企業等での活用事例の収集・
分析、及びプロフェッショナルの後進育成に有益な情報発信等を行うことを目的として、プロフェッショ
ナル人材や、IT スキル標準を活用した人事・教育訓練制度を先進的に実行している IT 企業などの知見の収
集、IT スキル標準を基盤とした人材育成の支援事業を進めています。
この一環として、情報処理推進機構・IT スキル標準センターは、ビジネスの第一線で活躍しているハイ
レベルのスキルを持つ者同士が、社内や組織の論理に捕らわれずに建設的に情報交換や議論が行えるよう
な場を通じて、IT スキル標準の改版、人材育成のあり方等、次世代 IT サービス・ビジネスを担う後進人材
のスキルアップに貢献するための諸活動を行う、「プロフェッショナル・コミュニティ」を創設しました。
○ 活動内容
コミュニティでは、その目的を達成するために次の活動を行い、その成果を資料等にまとめて情報発信
していく予定です。
· 後進人材育成のためのガイドライン作成
· IT スキル標準／研修ロードマップに対する改善事項の指摘
· ハイレベルな IT 人材の育成要素に関する助言等
· その他目的を達成するために必要な活動
○ ＩＴアーキテクト委員会の設置
IT スキル標準が定める職種の中、「IT アーキテクト」をリードする IT サービスの付加価値を創造する
ためのソリューション・デザイン力の強化、人材育成が急務となっていることから、「IT アーキテクト」
を対象とした IT スキル標準の改版、人材育成のあり方等、次世代 IT サービス・ビジネスを担う後進人材
のスキルアップに貢献するための諸活動を展開するため、プロフェッショナル・コミュニティ内に、「IT
アーキテクト委員会」を 2003 年 11 月に設置しました。
32
ＩＴアーキテクト委員会
○ 委員会の設置について
IT スキル標準 プロフェッショナル・コミュニティでは、コミュニティの具体的な活動を開始するにあ
たり、IT サービスの付加価値を創造するためのソリューション・デザイン力の強化等を担う IT アーキテク
トを対象とした人材育成が急務となっていることから、「IT アーキテクト委員会」を設置しています。
○ ＩＴアーキテクト委員
ハイレベルな IT アーキテクト人材を保有している企業数社にプロフェッショナル・コミュニティへ参加
頂き、その企業の代表を委員として、平成 15 年 11 月 26 日に IT アーキテクト委員会が発足しました。な
お、平成 16 年 5 月現在、本委員会の委員（◎は本委員会主査）は、以下の通りとなっています。（五十音
順）
• 荢津 昌三 氏 日本ユニシス株式会社
• 小池 和雄 氏 日本電気株式会社
• 五味 利明 氏 富士通株式会社
• 榊原 彰 氏 ◎ 日本アイ・ビー・エム株式会社
• 長坂 実 氏 株式会社 CSK
• 村上 和正 氏 株式会社アルゴ 21
• 湯浦 克彦 氏 株式会社日立製作所
• 吉田 幸彦 氏 日本アイ・ビー・エム システムズ・エンジニアリング株式会社
※ 参加企業とその代表である委員については、順次充実を図っていく予定です。
○ 平成１５年下期の活動概要
委員会を 6 回開催し、次のようなアウトプットの作成に向けた取り組みを行いました。
① IT アーキテクト育成ハンドブック
・ IT アーキテクトとは
・ IT アーキテクトを目指す方への提言
・ IT アーキテクトを育成する立場の方への提言
・ 各社 IT アーキテクトへのインタビュー
② IT アーキテクトに関する IT スキル標準および研修ロードマップの改善指摘事項
③ IT アーキテクト研修コースのレビュー など
33
ＩＴアーキテクト委員のプロフィール
// 主な活動内容 //
入社当初は汎用機のテクニカルSE として過ごし、コン
ピュータシステムを体系的に学びました。その後約 10
年は製造業におけるプロジェクト管理を経験し、システ
ム開発方法論やプロジェクト管理手法を学びました。
その後はプラットフォーム設計／構築の専門部隊とし
て、様々なシステムのプラットフォーム設計に携わって
います。
専門分野はプラットフォーム設計・構築であり、下記の
サポートを実施しています。
- システムアーキテクチャ見積もり及び提案
- システムアーキテクチャ設計
- ミドルウェア（DB 含む）の環境設計および構築
- チューニング及び信頼性テスト実施
ここ数年はシステム開発におけるアーキテクチャ設計
の重要性を痛感し、システム開発プロセスに合わせた設
計方法論の構築を目指しています。
小池 和雄
日本電気 （株） ニューソリューション開発事業部
プラットフォーム提案推進部 グループマネージャー
システムズアーキテクト
Kazuo KOIKE
// 主な活動内容 //
プロジェクトマネジャ、IT アーキテクトとして主に金融
業界向けのソリューション商品開発、システム構築サー
ビスに数多く携わってきました。
90 年代半ばにオブジェクト指向を全面採用して開発し
たオープン基盤上のソリューション商品の設計思想は
今でも受け継がれており、先見性を持ったモデルの有効
性を痛感しています。
その後、経営企画部でのサービスビジネス企画担当を経
て、現在は日本ユニシスグループのサービス戦略の推進
を担当しています。サービス戦略の一環として、IT サー
ビスリソース戦略も担当しており、現在は、特にプロジ
ェクトマネジャ、IT アーキテクト、コンサルタント育成
プログラムに取り組んでいます。
経営企画部での経験は IT アーキテクトとしての幅を広
げるのに大変重要だったと考えています。「IT アーキテ
クトはビジネスリーダ候補足りうる」というのが現在の
持論です。
PMI 会員
日本ユニシス （株） システムサービスマネジメント部
サービス戦略推進室長 プロジェクト･マネジメント認定技術者
Shozo OHTSU
荢津 昌三
34
// 主な活動内容 //
1986 年に日本アイ・ビー・エムに入社以来、都市銀行・
地方銀行・新聞社・電気部品メーカー・自動車メーカー
など多数のプロジェクトに参画してきました。
現在は、開発方法論や開発支援ツールの開発および社内
外への展開、アーキテクチャ設計技術など、ソフトウェ
ア・エンジニアリング全般の推進を手がけています。
専門分野は、コンポーネントベース開発、ソフトウェ
ア・パターン技術などです。
出版物には以下のようなものがあります。
・「アプリケーション開発技術」
（1997、共著、リックテレコム）
・「ソフトウェア基礎知識体系 － SWEBOK」
（2003、共訳、オーム社）
・「MDA モデル駆動アーキテクチャ」
（2003、共訳、エスアイビー・アクセス出版）
情報処理学会、プロジェクトマネジメント学会、IEEE、
ACM 各正会員。日科技連SPC 研究委員。
榊原 彰
日本アイ・ビー・エム （株） 技術ソフトウェア・エンジニアリング
ＩＣＰ シニア・コンサルティング ＩＴアーキテクト
Akira SAKAKIBARA
// 主な活動内容 //
富士通に入社以来、オペレーティングシステム、DC／
DB 制御製品の開発に従事した後、フィールド SE とし
て、主に大規模社会システムの基盤方式の設計・構築を
専門として多くのプロジェクトに参画してきました。
現在は、複雑化するオープンシステム基盤に対して、方
式モデルの標準化・パターン化による、お客様システム
の高品質・短期構築を実現するソリューションを企画・
開発しています。
富士通 IT アーキテクトコミュニティ（情報システム）
の主査として、コミュニティメンバーとともにシステム
インテグレーション技術の標準化、次世代を担うＩＴア
ーキテクトの育成に向けた活動などを推進しています。
多くの大規模社会システムの構築経験から、「基本を大
切に（原理原則）」をシステム構築のポリシーとして取
組んでいます。
富士通 （株） 共通技術本部
プロジェクトマネジメント室 主席部長
Ｓｅｎｉｏｒ Ｍａｎａｇｉｎｇ ＩＴ Ａｒｃｈｉｔｅｃｔ
Toshiaki GOMI
五味 利明
35
// 主な活動内容 //
これまでに担当した主な開発は次の通りです。
- デリバティブのリスク管理システムの開発。
- 日本でもトップクラスのハイボリュームトランザクション
を処理するテレコム系システムの開発（CORBA ベース）。
- EAIパッケージにより、メッセージングベースで分散システ
ムを連携させる基幹業務システム開発。
100 以上のシステムを開発してきましたが、本当にお客
様のためになっていたか省みるようにしています。
ここ1 年は経済産業省のEA プロジェクトに参加し、政
府、IT ユーザ企業、IT ベンダー企業に EA をしっかり
と定着させていきたいと考えています。
ここ10 年ぐらいの仕事の中では、オブジェクト指向（含
分散オブジェクト）、EAI（Enterprise Application
Integration）、EA（Enterprise Architecture）が得
意分野です。
「お客様のための IT でなければ意味がない」をポリシ
ーとしています。
（株） アルゴ２１ ＩＴコンサルティング事業部
チーフ テクニカル コンサルタント ＩＴコーディネータ／ＩＴＣインストラクタ
Kazumasa MURAKAMI
村上 和正
// 主な活動内容 //
これまで、UNIX を中心にしたC/S システムの構築を担
務してきました。特に、アプリケーション開発分野とデ
ータベース分野を中心に、サーバ・ストレージ装置・ネ
ットワークおよび運用構築というプラットフォーム全
体領域のスキルを積んできました。
システム構築におけるプラットフォーム（SW、HW、
NW、システム管理）領域の開発を担当（現在、ソフト
ウェアアーキテクチャは J2EEにフォーカス）しており、
（株）ＣＳＫの espf ソリューションの開発とこれを活
用したシステム構築に取り組んでいます。
システム開発におけるポリシーは、「動かしつづける」
運用を実現することです。これは、情報システムは動か
すことによって価値を産出するのであり、運用を重視し
てシステム構築をすすめるという考えです。
（株） ＣＳＫ ｅソリューション技術部
インフラ・アーキテクチャ設計課 Ｊ２ＥＥｅｓｐｆグループ
担当課長
長坂 実 Minoru NAGASAKA
36
// 主な活動内容 //
1980 年代より、オブジェクト指向の実用化に取り組ん
でおり、言語処理系、要求仕様視覚化、開発手順、ビジ
ネスモデリング、フレームワーク、生産性評価、EAI、
XML によるシステムインテグレーションなどを手がけ
てきました。
現在は、コンポ－ネント指向開発、エンタープライズ・
アーキテクチャ、ビジネス標準化、Web システムなど
を専門とし、IT 導入計画や技術開発のコンサルテーショ
ンを行っています。
過去に、情報処理学会記号処理研究会幹事、XBRL
Japan 副会長等を務めました。現在、日本規格協会XML
動向調査委員会委員。
主な著書：
・「EJB コンポーネントによる Web システム構築技法」
(SRC 出版、2002)
・「インターネット財務情報システム」
(SRC 出版、2004)
湯浦 克彦
（株） 日立製作所 ビジネスソリューション事業部
主管技師
Katsuhiko YUURA
// 主な活動内容 //
技術系プロフェッショナルとして、主に製造・金融業の
システム開発に関わってまいりました。
プロジェクトをフル・ライフ・サイクルで推進する経験
を早いうちから幾つも経験できたことや、価値観や文化
的背景の全く異なる国々のプロフェッショナルからな
るプロジェクトをいくつか経験できたことは、IT アーキ
テクトとして活動を続ける上でのバックボーンを築い
てくれたと思っています。
専門分野はエンタープライズ・アーキテクチャの構築お
よびe-business 系のソリューション・アーキテクチャ
の構築です。
IT アーキテクトを目指す中堅の技術系プロフェッショ
ナル育成のための活動(育成施策、研修開発・実施、メ
ンタリングなど)や、実践を重視した研究活動にも取り
組んでいます。
主な出版物：「ソフトウェア再利用ガイドブック」
(1999、共訳、エスアイビー・アクセス)
吉田 幸彦
日本アイ・ビー・エム システムズ・エンジニアリング （株）
システム・デザイン・センター ＩＣＰ シニア・コンサルティング
ＩＴアーキテクト
Yukihiko YOSHIDA
37
6. ＜付録＞ IT アーキテクト委員の心に残った一冊
委員名 推薦図書名 著者名（訳者等） 出版社 出版年 推薦文
苧津昌三
デザイン・ルール
― モジュール化パワー ―
『Design Rules － The Power of Modularity －』（原著）
カーリス Y. ボールドウィン、
キム B. クラーク 著
安藤晴彦 訳
東洋経済新報社 2004 年
本書は経済学の書ですが、アーキテクトを「ある設計・タスクの構造について異なるアプローチの方法を見出し、代替案を評価し、適
切にトレードオフを判断できる設計者」であると定義し、その働きの意味を理論的に追求しています。また、ENIAC、360 システム、
UNIX の歴史的考察の中で、その理論的な意味についても検証しています。現時点では二分冊の第 1 巻のみのため、内容的にはコンピ
ュータと OS についての考察に留まり、アプリケーション・システムのアーキテクチャについての考察は次巻に委ねられていますが、
第 1 巻それ自身も、十分に稀有な示唆を含んでいると言えます。
小池和雄
スーパーエンジニアへの道
－ 技術リーダーシップの人間学－
ザ・ゴール
－ 企業の究極の目的とは何か －
G.M.ワインバーグ 著
木村泉 訳
エリヤフ・ゴールドラット 著
三本木亮 訳
共立出版
ダイヤモンド社
1991 年
2001 年
設計したアーキテクチャを下流工程にスムーズに展開して行くためには、技術リーダーとして多くの人を動かして行く必要があります。
本書は、技術リーダーとして陥りやすい落とし穴を教えてくれると共に、リーダーのあるべき姿についての示唆を与えてくれます。 生産工程の改善を物語形式にて記述した書です。人の立場で書かれているため、無味乾燥な技術書とは趣が異なります。その改善の工
程を、人の視点から書いてあるので、ソフトウェアの生産とオーバーラップさせて読めば、得るところは多いのではないでしょうか。
対象とするシステムへの理解を深める上でも一読を勧めます。
五味利明 失敗学のすすめ 畑村洋太郎 著 講談社 2000 年
IT アーキテクトの活動環境に、ひとつとして同じものはなく、つねに新たな技術への挑戦です。この活動局面では、その影響の大小は
あるものの、失敗を切り離すことはできません。「失敗学」の趣旨、またそのめざすところを、本著書から引用させて頂くと『失敗の
特性を理解し、不必要な失敗を繰り返さないとともに、失敗からその人を成長させる新たな知識を学ぼう』『失敗を忌み嫌わずに直視
することで、失敗を新たな創造というプラス方向に転じさせて活用しよう』です。 失敗の定義、１０の失敗原因、良い失敗と悪い失敗、失敗の予兆、失敗の活かし方など、気軽に読みやすい著書です。「真の創造は、
起こって当たり前の失敗からスタートする」であるという本書の言葉は、IT アーキテクトへの励ましの言葉であると思います。著者の
ほかの著書「決定学の法則」「創造学のすすめ」「実際の設計こうして決めた」についても、あわせて推薦します。
榊原 彰
コードコンプリート
～ 完全なプログラミングを目指して
『Code Complete － A Practical Handbook of Software Construction －』（原著）
ソフトウェアアーキテクチャ ～
ソフトウェア開発のためのパターン体系
『Pattern-Oriented Software Architecture － A System of Patterns －』（原著）
Steve McConell 著
石川勝 訳
Frank Buschmann 他 著
金澤典子他 訳
アスキー Microsoft Press （原著）
近代科学社 Wiley & Sons （原著）
1994 年
2000 年
ソフトウェア開発のライフサイクル全体にわたって、実践的な開発技術・技法が体系的に解説されています。サンプルは Pascal と C を
使用していますが、基本的なテクニックは言語を問わず応用できます。プログラミング時のアルゴリズム適用法や、デバッグ方法、チ
ューニングなどなど、品質の面まで考慮したソフトウェア構築方法を、プログラミングを中心として解説した優良書籍です。 ソフトウェア・パターンの代表的な 3 つの抽象レベル「アーキテクチャ・パターン」「デザイン・パターン」「イディオム」について
解説している書籍です。中でも、アーキテクチャ・パターンに関しては、MVC や Layer など、システム構成における常套手段が極め
て洗練された設計内容にて解説されています。全アーキテクト必読の書です。
鈴木俊男
メンタリングの技術
メンタリングの奇跡
本多勝嗣 著
マーゴマリー他 著
オーエス出版
PHP 研究所
オーソドックスなメンタリングの本です。特に高成果（キャリア開発）を一定期間（６ヶ月～２年）で実現するための方法論、プロセ
スについて簡潔にまとめられています。メンターとして行動することの意義と心構えも含めて How-to ものとして役に立ちます。人事
部門以外で、プロセスを含めこれから人材育成に関わる人にはお勧めです。キャリア開発の指針であるキャリア開発という意味でのメ
ンタリングを実践する際の参考書として使えます。
長坂 実
ソフトウェア開発２０１の鉄則
意思決定の理論と技法
アラン M. デービス 著
松原友夫 訳
篭屋邦夫 著
日経 BP 社
ダイヤモンド社
1996 年
1997 年
情報システム開発に携わって 5 年目、ちょうど中堅社員となるころに出会った本です。非常によく効くツボを押さえており、はじめは
まさに目からうろこが落ちました。いまでも折につけ読み返しています。開発局面にスコープをあてた内容で、テクニカルスキルを中
心にコミュニケーションスキル・コンセプチュアルスキルの領域に関して「なるほど」と思わせる原理が数多く収められています。（フ
ァンである方、意外と多いのではないでしょうか？）
村上和正 Requirement Analysis － From Business View to Architecture －
David C. Hay 著 Printice Hall PTR 2003 年
本書は、IT アーキテクトが、お客様からの要求を踏まえて、どのように IT アーキテクチャーをデザインするかをかなり具体的なステッ
プを追って紹介したものです。フレームワークのベースは Zachman モデルを採用しています。
湯浦克彦 計算機プログラムの構造と解釈 サスマン他 著
和田 訳
MIT Press ピアソン
元来プログラミングに関して書かれた本ですが、ここで紹介されている手続きやデータの抽象化の考え方は、ビジネスモデリングにも
通ずるところがあります。とっつきはよくないのですが、何年かごとに紐解いてみると、そのときのアーキテクトとしての視点から新
しい発見のある、味わい深い名著です。
吉田幸彦
人月の神話
－ 狼人間を撃つ銀の弾はない －
『The Mythical Man-Month: Essays on Software Engineering』（原著）
Jr. フレデリック・
P.ブルックス 著
滝沢 徹、富沢 昇、牧野祐子 訳
ピアソンエデュ
ケーション 2002 年
進化の激しい IT の世界では既に古典に属しているにもかかわらず、ずっと本書が読み継がれているのは、著者自身が経験と失敗から学
んだ多くを語っていることと、改定時に再評価を加えていることにあると思われます。プロジェクトマネジメントに加えて、アーキテ
クチャおよびアーキテクトについて考えるきっかけを与えてくれた本です。