割と身近なところで頻繁に「ITアーキテクト」という単語か飛び交っていて、もやもやしたので情報を整理しながら書く記事。オチはない予定。
photo by SantiMB.Photos
ITアーキテクトの定義
例えばIPAの共通キャリア・スキルフレームワークでの(システムアーキテクトの)定義はこんな感じ。
- 人材像の役割
- ビジネス戦略 に対して最適 なシステムを デザインする。
- IT戦略を受け、ソリューションを構成する、又は組込み製品開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計する。
情報処理技術者試験における(システムアーキテクトの)定義は次のとおり。
情報システム戦略を具体化するための情報システムの構造の設計や、開発に必要となる要件の定義、システム方式の設計及び情報システムを開発する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。
- 情報システム戦略を具体化するために、全体最適の観点から、対象とする情報システムの構造を設計する。
- 全体システム化計画及び個別システム化構想・計画を具体化するために、対象とする情報システムの開発に必要となる要件を分析、整理し、取りまとめる。
- 対象とする情報システムの要件を実現する最適なシステム方式を設計する。
- 要件及び設計されたシステム方式に基づいて、要求された品質を満足するソフトウェアの設計・開発、テスト、運用及び保守についての検討を行い、対象とする情報システムを開発する。 なお、ネットワーク、データベースなどの固有技術については、必要に応じて専門家の支援を受ける。
- 対象とする情報システム及びその効果を評価する。
システムアーキテクチャ構築の原理ではどうだろう(なお、第1版から引用。第2版は未読・・・)。
ソフトウェアアーキテクトの役割に関して、一般に認められた共通の定義はない。アーキテクトの役割は、要求の捕獲と高レベルでの設計の要素を含んでいるが、そのどちらよりも大きい。本章では、アーキテクトの4つの主要責務を定義した。すなわち、ステークホルダを特定して参加させること、その関心事を理解してとらえること、AD(アーキテクチャ定義)を作成して所有すること、それにアーキテクチャの実現で先導的役割を担うことである。
[asin:B00U3P1AFQ:title=システムアーキテクチャ構築の原理] P65
ほかにもいろいろな定義がありそうだけれども、共通するのは次のような点だと考えている。
- スコープ全体に関するアーキテクチャを設計する
- この作業には当然のことながら利害関係者からの調査、比較、検討が含まれる。
- またスコープ全体を取り扱うので、抽象化する能力も必要。
- 設計したアーキテクチャに基づき、システム開発を主導する。
- 品質その他の比機能要件を満たすソフトウェアを開発するための方式やプロセス検討、テスト計画も含む。
- 上記に関する利害関係者の調整と合意形成。
ちなみにアジャイルソフトウェア開発は一般的にITアーキテクトのようなロールは定義しない(その作業はチームで行う)はず。一応確認してみる。
多くのアジャイルチームは、アーキテクトという言葉が役職につく人々を含んでいない（アジャイルマニフェストの原則：最善のアーキテクチャ、要求、瀬系は、自己組織化されたチームから浮かび上がる）。しかし、アーキテクチャはアジャイルチームにとって非常に重要である。そのような場合、ローカルなアーキテクチャ（チームが責任を持つコンポーネント、サービス、機能）は、多くの場合ローカルのチームによって協調的に定義される。このケースの場合、チームの活動を通じて「アーキテクチャは出現する」のである。
しかし、システムレベルでは、アーキテクチャは、システム全体の構造（コンポーネントとサービス）を決定する責任を持つシステムアーキテクト、ビジネスアナリストによって調整されるものである。システム全体として強制しなければならない、システムレベルのユースケースや、パフォーマンスの基準も同様である。したがって、アジャイルチームはそのチームの外側に存在する複数のアーキテクトと話す単一窓口を持つことになるだろう。
アジャイル開発の本質とスケールアップ P106
「ITアーキテクト」を名乗りたがる問題
割とSIとか受託開発の世界で「ITアーキテクト」を名乗りたいとか、目指したいというフォースがあると思ってる。暗黒面。
- エンジニアカーストを上ってもらわないと、単価交渉しにくいという暗黒人月界の要請
- 要は品目を変えるため
- キャリアパスを考える際に、クラスチェンジ方式のほうが本人にも指導する方にもわかりやすいという、教育視点
そもそも、ユーザ企業やサービス提供会社からしてみたら、ITアーキテクトなんてそんなにたくさんはいらないはず(多くてプロダクトの数だけ。基盤を共通にしていたらもっと少なくていいはず)。というわけで、改めてSIとか受託開発方面での話題なんだなぁと再確認した次第。
「ITアーキテクト」の不足問題
あと、これもSIとか受託開発方面にありがちなこととして、プロジェクトが失敗した時に「ITアーキテクトがアサインできなかったから」という(不適切な)反省で締めくくられて、結果として「ITアーキテクトをもっと育成しなければ」という(不適切な)育成大方針が打ち立てられるという事もあるような気がする。
- 見積り失敗とか明らかにマネジメント不備があった場合は別。
- システムの非機能面(パフォーマンスとかユーザビリティ)がNGなシステム開発をしてしまうと、反省が「ITアーキテクトが不在/不足/能力不足だった」という事になりがち。原因を「人」に持っていくなよ、という気がするが。
- あと、割とチャレンジングな製品とかOSSを組み込んだプロジェクトも同様。
それは本当にアーキテクチャの問題なのか？ プロジェクト計画上の問題なんじゃないの？
「ITアーキテクト」は名乗るもの？
個人的には、「ITアーキテクト」は自ら名乗るというより、他者から名づけられるものだと思っている。自称はちょっと・・・。
そういえばこの本は好きだった(アーキテクトの定義などは、なし)。各ページにツッコミを入れながら読むのが楽しい本。
追記(2015/3/16)
IPA プロフェッショナル・コミュニティ ITアーキテクト委員会が取り纏めた「ITアーキテクト育成ハンドブック」というものがあると教えていただいたので紹介しておく。
- IPA ITアーキテクト育成ハンドブック(PDF注意)
内容も興味深いが、末尾に「ITアーキテクト育成のための図書リスト」というものも含まれていて参考になる(ちょっと古いけど)。
