ITアーキテクトの特性

この記事は、Peter Cripps氏による、「Attributes of an IT Architect」を、ご本人の許可を得て翻訳したものです。*1


私は最近、英国の成人教育機関におけるコース教材について、レビューを行った。生徒へIT業界へ入る準備をさせるために、その教材がどれだけ適切かを見るためにである。このレビュー作業は、私たちITアーキテクトが本当に持つべきスキルについて、考えるきっかけとなった。以下は、21世紀の次の10年(second decade)において、ビジネス/ITサービス企業で働くことの実態を、いくらか記述するものである。これらは、新しく(アーキテクトの世界に)参加する人たちが、彼らのスキル評価を行えるような、チェックリストとなることを意図したものである。私の経験上、これらは全て、有能なITアーキテクトがマスターすべき(少なくとも、認識すべき)スキルである。

1. ビジネス・ドライバーを理解する
コスト削減は、ビジネスにおけるNo.1のドライバーである。ITのためのITは、もはやIT部門におけるビジネスの選択肢ではない(過去はそうであったとしても)。ITはビジネスのニーズに答えられるものでなくてはならない。もしITがビジネスのコスト削減を行うと見なされないのであれば、理事会は投資対効果の検討書に決してサイン・オフしないだろう(そして、するべきでない)。結果として、これらのサービス・プロバイダーの市場における競争は猛烈なものとなる。入札案内(ITT:Invitations To Tender)へ応じる際に、サービス・プロバイダーはこのことを激しく認識するに違いない。入札はしばしば、純粋に金額だけで、勝ち取られることになる。
2. オフショアの開発者と働く
上記1.の結果として、可能な限りの作業が、低賃金なオフショア環境で行われる。これは多くのプログラミング、パッケージの統合、Web開発やテストに適用される。オブジェクト指向開発のテクニックや、Javaプログラミングなどは役立つとはいえ、サービス企業においては、ITプロフェッショナルの日々の仕事では、主要なものとはならないだろう。代わりに、我々は文化・社会的な差異を認識し、これらの人々と共に効果的に働かなくてはならない。
3. 複合システム統合を理解する
今日における、本当にたちの悪い問題は、複合システム統合に関する分野にある(CSI:Complex Systems Integration)。定期的に起こる多国籍大企業のM&Aや、コスト削減のための政府の組織/システムの統合に伴い、これは今後増加の一方となるトレンドである。その結果、システム間のインターフェース方法(技術的なレベルで)を理解することは、きわめて重要となる。私の同僚であるJeremy Caineは、この件について素晴らしい記事を書いている。彼の記事は、本記事の3.と5.に関連している。
4. 組織的な面に留意する
3の更なる結果は、技術的な統合のみならず、組織的な統合も必要であるということである。組織における人々の複数の観点、偏見、凝り固まった見方を扱うのは、しばしば技術的な面を扱うよりも難しいものである。
5. プロセスを実際的に適用する
プロジェクトの迅速な納入に対するプレッシャーは、しばしばソフトウェア納入のライフサイクル(SDLC:Software Delivery LifeCycle)に関するプロセスが迂回され、見落とされ、またはまったく行われないことを意味する。プロセスを実践的に、そして効果的なやり方で適用する方法を理解することは、プロジェクトの成功のキーである。
6. ステークホルダー(利害関係者)に効果的に対処する
ステークホルダーへの対処は、効果的な、そして成功するシステム開発に欠かせない。だれがステークホルダーであり、彼らの動機や興味が何か、そしてお互いにどのような相互作用があるかを理解することは、ITサービスのプロフェッショナルにとって、重要なスキルである。
7. 非機能要件を効果的に管理する
この業界では、機能要件の収集はまあまあ上手くやれているが、非機能要件(つまり、構築され、運用されるシステムの品質や制約)の定義については全く上手くいっていない。ITプロフェッショナルは非機能要件を収集し、分析する方法を理解する必要がある。
8. パッケージ統合を理解する
今日におけるシステム構築の大部分が、パッケージの組み合わせや、既存システムの統合、そして(比較的小さな)カスタム開発である。よって、(SAPやOracleなどの)パッケージや、(IBM WebSphere Message Brokerなどの)製品を理解することは、重要なスキルである。
9. システム・エンジニアリングのテクニックを適用する
システムは単にソフトウェアに関するものではない!システムに関する人々、プロセス、そして開発の観点を理解することは、(ソフトウェアと)同じくらい、もしかするとそれ以上に重要なのである。
10. アプリケーションとインフラストラクチャの管理に関する問題を理解する
一度構築された後は、システムは実行され、保守される必要がある。故に、なるべく早い段階から、インフラの提供者やアプリケーション保守の提供者と、どのようにやっていくかを理解することは重要である。
11. エンタープライズ・レベルでシステムを理解する
小さなシステムやプロジェクト・レベルにとどまらず、エンタープライス・レベルで行われるビジネス(つまり、ビジネス/ITエンタープライズ・アーキテクチャ)を理解することは、ITプロジェクトを成功させることのキーである。ITシステムは、単独で動作することはまれである。その代わりに、更にサイロ化されたような業務システムの繁殖を防ぐために、複数の相互作用からなる複雑な生態系で運用される必要がある。 
12. 人間とコンピュータのインターフェースを忘れるな
プロセスがしばしば見落とされるように、人間とコンピュータ間の効果的なインターフェース(HCI:Human-Computer Interface)もまた見落とされがちである。業務システムでは、インターフェースは一日中長時間にわたって使用されるため、効果的にデザインされたショートカットは、文字通り数百時間の作業を削減することができる。

今後、本blogでこれらのテーマについて、振り返るつもりである。


(翻訳者のコメント)

アーキテクトは技術スキルのみならず、コミュニケーション、ネゴシエーションといった幅広いスキルが要求されていることが、上の記事からわかると思います。厳しい道ですね…

ある本には、「アーキテクトはプログラマとしても一流でなければならない」と書かれていました。プログラミングができないアーキテクトが参画している悲惨なプロジェクトの状況を聞くと、このことの必要性を強く感じます。

*1:原文公開日:2010年1月7日。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です