Javaアーキテクトへの道
〜 Road to Java Architect 〜
Java アーキテクトのための Java Java アーキテクトのための分析・設計 Java アーキテクトのための Java 関連製品 Java アーキテクトのためのその他 Java アーキテクトへの道 Top

ITアーキテクトとは?

目指せ年収1000万円SE

「年収1000万円SEの作り方」

ある雑誌で、このような特集をしていました。非常に魅力的な特集です。 やっぱり、仕事人として頑張るからには年収1000万円ぐらいは目標に掲げて頑張りたいものです。 さっそく、この特集を読んでみたところ年収1000万円SEには以下のスキルをバランスよく持っていることが必要であると示してありました。

  • テクニカルスキル
  • ヒューマンスキル
  • ビジネススキル
日々、これらの 3 つの能力を高め年収1000万円SEを目指していくわけです。
そして、その 3 つの高い能力が要求され年収1000万円SEに近い IT職種として以下の 3 つが挙げられます。
  • ITアーキテクト
  • コンサルタント
  • プロジェクトマネージャ
このサイトのタイトル『Javaアーキテクトへの道』に現れているように、ここではこの年収1000万円を狙える IT職種の 1 つ ITアーキテクトを取り上げていきたいと思います。

ITアーキテクトとは、ITの建築家?

そもそも、ITアーキテクトってなんなのさ? というところをまず疑問に思われる方が、まだ多いのではないかと思います。 アーキテクトという単語を訳すと『建築家』とでてきます。(私の辞書はカスタマイズしてあるので、アーキテクトとでてしまいますが(笑)) なので、ITアーキテクト = ITの建築家 といった図式が簡単に思い浮かぶのではと思います。
ITの建築家といわれても、なにかわかったような今ひとつわからないような、システムデザイナとなにが違うのかといった気分だと思います。 先程の年収1000万円SEを狙える 3 つの IT職種を考えると、

  • ITアーキテクト = ITの建築家の人?
  • コンサルタント = 業務スペシャリストの人
  • プロジェクトマネージャ = プロジェクトを管理する人
といった形で他の 2 職種はわかりやすいものの、やっぱり ITアーキテクトだけが謎です。
しかし、この ITアーキテクトという IT職種は、経済産業省の ITスキル標準でも取り上げられ、 今後のシステム開発を考えても非常に重要な職種となってきます(なるといいな(笑))し、なにより年収1000万円を狙っていける IT職種ですので、 しっかりとどういった職種なのかということをここで取り上げていきたいと思います。
まずは、ITアーキテクトがいない世界と ITアーキテクトがいる世界をサンプルとしてみていきたいと思います。

ITアーキテクトのいない世界

X システムソリューションは、どこにでもある中堅ソフトウェア受託開発の会社です。
X システムソリューションでは、今回中堅小売店 S から Web 店舗のシステム開発を受注しました。 今回は Web システムということで、最近ちまたで流行っている Java を導入し Java 技術者を育成すると共に案件もこなしてしまおうと考えました。 そこで、早速プロジェクトチームを編成し中堅小売店 S に要件ヒアリングに向かわせました。 要件ヒアリングの結果得た情報の概略は、以下のようなものでした。

  • Web 店舗により現状の売上をさらに伸ばしたい。
  • 今後、店舗システムだけでなく既にある基幹系システムの在庫管理や受発注管理も統合して扱っていきたい。
  • Web 店舗の仕組みは、よくみかける Web ショップと同じでよいがデザインにこだわりたい。
  • S 小売店は業績がよく今後、他小売店を買収するかもしれない。

こういった内容でしたので、X システムソリューションはやはり Java を採用しようとしていて正解だったと思いました。 なぜなら、Java はオブジェクト指向でできているらしく、拡張性や再利用性が非常に高いとのことだからです。
プロジェクトチームのメンバーは、クライアント・サーバ型開発で 10 年分析・設計を行っている A さんを中心に COBOL 技術者が中心でしたので、 まずは Java の勉強から取り掛かり、今ひとつオブジェクト指向や Java がどういったものかわからなかったものの、その後ヒアリングした要件からいつものように分析を行っていきました。 そして、中堅小売店 S の担当者と打ち合わせをしながら開発は分析から設計、設計から製造へと流れていきました。

製造まで工程が流れると成果物として動くものができあがってきます。 さっそく、できたものを中堅小売店 S に持っていくと、よくあることですが「ここが思っていたのと違う」、「ここにこんな機能をつけてくれないか」といったような注文がついてしまいました。
今後のお付き合いも考えて、そうそう注文を断ることもできずプログラムの修正を続けていきます。 特に画面のデザインについてこだわりたいと言っていただけあり画面まわりの注文が多く、プログラムから画面生成、出力を行っていたため修正がたくさん発生してしまいました。 このように、多くの修正をその場の対応で行っていたためプロジェクトチームの誰も A さんすらも全体の構造が今ひとつつかめず、プログラムを見ないと仕様がどうなっているかもわからなくなっていました。 日々、修正。そして、提出。その繰り返しです。当然、バグも多くなり納期が近づくにつれ残業時間も増え、徹夜の日も増えました。
典型的な、みんなで仲良くデス・マーチといった展開です。

そんなある日、中堅小売店 S の担当者から A さんのもとへ一本の電話が入りました。
今度、P 小売店を買収することになり P 小売店の在庫管理システムが優秀なため今回のシステムに取り込んで欲しいといった内容でした。
期間は、1 ヶ月。

分析をしたところ、最初から取り込みを考えていれば難なくこなせる期間でした。しかし、今や修正に継ぐ修正でシステムの全体像を把握することも難しくなったシステムには、どこにどう取り込んでいくかも検討がつかなくなっています。
A さんは、もはや絶望的な気分でした・・・。

ITアーキテクトのいる世界

X システムソリューションは、どこにでもある中堅ソフトウェア受託開発の会社です。
X システムソリューションでは、今回中堅小売店 S から Web 店舗のシステム開発を受注しました。 今回は Web システムということで、最近ちまたで流行っている Java を導入し Java 技術者を育成すると共に案件もこなしてしまおうと考えました。 そこで、早速プロジェクトチームを編成し中堅小売店 S に要件ヒアリングに向かわせました。 要件ヒアリングの結果得た情報の概略は、以下のようなものでした。

  • Web 店舗により現状の売上をさらに伸ばしたい。
  • 今後、店舗システムだけでなく既にある基幹系システムの在庫管理や受発注管理も統合して扱っていきたい。
  • Web 店舗の仕組みは、よくみかける Web ショップと同じでよいが画面デザインにこだわりたい。
  • S 小売店は業績がよく今後、他小売店を買収するかもしれない。

こういった内容でしたので、X システムソリューションはやはり Java を採用しようとしていて正解だったと思いました。 なぜなら、Java はオブジェクト指向でできているらしく、拡張性や再利用性が非常に高いとのことだからです。
プロジェクトチームのメンバーは、クライアント・サーバ型開発で 10 年分析・設計を行っている A さんを中心に COBOL 技術者が中心でした。

そこで、A さんは Java やオブジェクト指向を理解し、プロジェクトを円滑に進められるようコンサルテーションをしてもらう為に、 ITアーキテクト・システムというコンサルテーション会社に依頼をしました。
ITアーキテクト・システムからは、ITアーキテクト U さんとその他 2 人が派遣されてきました。

ITアーキテクトの U さんは、アーキテクチャをしっかりと考えましょうと A さんに進言してきました。 「アーキテクチャとは?」と A さんが質問したところ、「システムの骨格となるものです」と U さん。 その後ヒアリングした要件から、U さんを中心にアーキテクチャを考えながら分析を行っていきました。

お客様の要件は、機能要求と機能外要求に分けられます。
機能要求とは、システム上で実際に実現していく機能に対する要求。例えば、注文処理や夜間バッチなどがこれにあたります。 機能外要求とは、システム上で実現するものではなく、お客様のビジネス的な要求など。例えば、早いレスポンスタイムや堅牢なセキュリティ、ビジネス的な拡張性などがこれにあたります。
アーキテクチャは、この機能外要求を中心に考えるとのことです。
今回、ITアーキテクトの U さんは機能外要求として、以下のものを考慮したほうがよいと言いました。

  • 今後、店舗システムだけでなく在庫管理や受発注管理も統合するため拡張しやすくする。
  • 画面デザインにこだわるとのことなので、変更時の影響範囲を減らすため画面生成ロジックとビジネスロジックを分離する。
  • 他小売店を買収することにより、システムの拡張や統合が考えられるので拡張しやすくする。
以上のようなことを考慮して、ITアーキテクトの U さんを中心としてシステムの骨格となるアーキテクチャを考えていきました。 そして、中堅小売店 S の担当者と打ち合わせをしながらアーキテクチャをより詳細なレベルにしていきました。
ITアーキテクト・システムの要員にオブジェクト指向や Java を習いながら、開発は分析から設計、設計から製造へと流れていきました。

製造まで工程が流れると成果物として動くものができあがってきます。 さっそく、できたものを中堅小売店 S に持っていくと、よくあることですが「ここが思っていたのと違う」、「ここにこんな機能をつけてくれないか」といったような注文がついてしまいました。
今後のお付き合いも考えて、そうそう注文を断ることもできず修正を受け入れざるをえません。
しかし、ITアーキテクトの U さんを中心として考えたアーキテクチャがしっかりとしていた為、修正範囲の切り出しがしやすくモジュールの置き換えだけでほとんど対応ができてしまいました。 特に画面のデザインについてこだわりたいと言っていただけあり画面まわりの注文が多かったですが、画面生成をするモジュールとプログラムが切り離されていたので簡単に修正を行うことができました。
このように、時間と共に顧客の要望が変わるなどし多くの修正が発生しましたので、さすがに納期が近づくにつれ残業時間も増え、徹夜の日も幾日か発生しました。

そんなある日、中堅小売店 S の担当者から A さんのもとへ一本の電話が入りました。
今度、P 小売店を買収することになり P 小売店の在庫管理システムが優秀なため今回のシステムに取り込んで欲しいといった内容でした。
期間は、1 ヶ月。

分析をしたところ、最初から取り込みを考えていれば難なくこなせる期間でした。
今回のシステムは機能外要求として、統合も考えられていましたので拡張性のあるアーキテクチャが ITアーキテクトの U さんにより構築されていました。 なので、この統合もモジュールの追加により難なくこなしていくことができました。
そして、システムは納期どおりにリリースされ A さんも、一安心でした。

ITアーキテクトの必要性

アーキテクチャとは、システムの骨格となるものをあらわす抽象化されたシステムになります。
ITアーキテクトは、このアーキテクチャを考えていく IT職種です。

従来の開発を考えた時に、社内システムや 1 社向けのシステムなど一つの限られた範囲の中で使用するスタンドアロンなシステム・アーキテクチャが多かったと思います。 そういった環境だと、特にシステム的に拡張などをすることはあまり考慮されていないシステムを作成していたことと思います。 拡張が発生した時には、その場対応といった形になることが多く当然システム的な品質は低下することになります。 品質に関する問題も社内システムや 1 社向けといった形でしたので許容されることが多かったと思います。

しかし、最近のシステムは Web システムなど多くのユーザを対象とする為、品質の問題は致命的になりかねません。 さらに、ビジネス的な変化も多様であり合併によるシステム統合やビジネス・モデルの変更による拡張などが急激なビジネスの変化があたりまえの時代になりました。 拡張性や柔軟性が高く、品質も高いシステムが求められるようになったのです。
そういったシステムを考えていきますと、やはり基盤がしっかりしている必要性があります。

そこで、ITアーキテクトの登場です。

ITアーキテクトが、システムの骨格となるアーキテクチャを考えることにより、しっかりとした基盤ができあがり拡張性や柔軟性があり品質の高いシステムになる訳です。

ITアーキテクトの必要性は、現実世界で考えるとよりわかりやすいと思います。 従来のシステムをログハウス、最近のシステムを高層ビルと考えてください。
ログハウスを作る建築手法で高層ビルが建ちますか?

答えは、いいえです。うまく建つはずがありません。ソフトウェアのシステムも同様です。
今後のシステム開発では、分散している環境や他システムとの統合や Web サービスなどの連携といったようなことが多くなってきます。 やはり、そうなるとしっかりとした基盤が不可欠になるはずです。

ITアーキテクトの業務範囲

ITアーキテクトは、アーキテクチャを考えていくために活躍するフィールドは以下の図のとおりです。


従来の ITアーキテクトがいない世界での開発の流れ

ITアーキテクトがいる世界での開発の流れ

以上のように ITアーキテクトの業務は多岐にわたります。
アーキテクトは、システムの骨格となるアーキテクチャを考えることになります。すなわち、システムとしての方向性を決めることになります。 ですので、顧客の要求を理解してビジネス上の課題を解決してアーキテクチャを設計しなければなりません。 ビジネス上の課題を解決するためのソリューションをアナリストと共に考え、機能外要求を中心としてアーキテクチャモデルを作成することが目的となります。
もちろんシステムの骨格となるものを作成しますので、コンポーネントとなるサーバ機器や開発に使用する言語などについても ITアーキテクトは知らなければなりません。 ITアーキテクトがアーキテクチャを作成し、../index.htmlコンポーネント設計について助言をしながらシステムはデザイナによって詳細化されていきます。
従来型の ITアーキテクトがいない開発ですとシステムデザイナが設計をすべて行うため作業量も膨大ですし、確固たるアーキテクチャができていないため 拡張性や保守性に優れていないシステムができあがることになります。
ITアーキテクトがアーキテクチャ設計をすることで拡張性や保守性に優れたシステムができます。

このように、ITアーキテクトは Java などの言語やデータベース、ネットワーク、セキュリティといったようなシステム的なことについてと、 ビジネス的な仕組みについて知っている必要があり、その修得しなければならないスキルは非常に多岐にわたります。
さすがにすべてのスキルを身に付けることは不可能に近い状態ですので、アナリストやシステムデザイナ、プログラマと相談をしながらアーキテクチャを構築していくのが普通でしょう。 そうなると ITアーキテクトには、コミュニケーション能力も求められるのです。 顧客の要求を引き出す、システムの方向性となるアーキテクチャをプロジェクト関係者達に伝えるといった面からもコミュニケーション能力は不可欠です。

ほら、年収1000万円SEの必要とされるスキルであるテクニカルスキル、ヒューマンスキル、ビジネススキルとすべて揃ってしまいましたね。

まとめ

ITアーキテクトは、システムの骨格となるアーキテクチャを考えていく。

その大切さ、そして ITアーキテクトの大変さがわかっていただけたのではと思います。 そこで、このサイトでは ITアーキテクトはたくさんの情報、たくさんの経験を必要としていますので、 一人でその情報や経験を集めることは不可能に近いので、みんなの情報を共有すべく立ち上げました。 その際、方向性がなくては情報を共有しにくいだろうということで Java という現在最も主たるオブジェクト指向開発環境を取り上げました。 みんなで情報を共有することで、コミュニケーション力を高め Javaアーキテクトを目指し、そして真の ITアーキテクトになれるその日まで頑張っていきたいと思います。

追記:そうそう、この間マトリックス リローデッドを見てきたのですが、その中でもアーキテクトが出てきました。 詳しい内容を記述すると、ネタばれになるので書きませんが、あの超人気映画マトリックスにまでアーキテクトという言葉が出てくるとはっ! と、 ちょっと感動しつつも、技術者ですら ITアーキテクトって微妙なのに一般人にはさっぱりわからんだろうなと思った今日この頃でした。

Written by 魁!! アーキテクト塾 塾長

Javaアーキテクトへの道 Top ページへ
Copyright 2003 魁!! アーキテクト塾 All rights reserved.