まとめ読み：ITアーキテクトは何をしているのか from ITPro

ITproから、ITアーキテクトは何をしているのか

ちょっとばかり気になる記事が出ていましたので追い掛けてみました。IT関係の仕事ではやる事が先にあって職種、それも大抵はカタカナ表記、が後追いで着いて来る感じがあります。ITアーキテクトとやらは私の感覚ではごく最近（でも結構経っている）出てきたカタカナ職種、で他のカタカナ職と何が違うのといわれても判りません。昔はなんでもかんでもプログラマのお仕事でした。大規模化、複雑化と伴に専門化、細分化されて来たと言えるのでしょう。でも、細分化によって一部しか判らない専門家ばかりになっては欲しく無いものです。ということでこの連載で言うところの（多分人によってやるべき仕事の対象が違っているとは思いますが）ITアーキテクトの担当すべき業務を見てみたいと思います。

第1回 要件定義工程のITアーキテクト　2012-10-01

こういう仕事だよ、といわれても訳が解らないIT系カタカナ職種、成果物で追い掛けて行くのは悪くないですね。ということで要件定義フェーズの成果物として上げられていたのか以下の五つです。

（1）Vision Document

（2）利害関係者マップ

（3）概念機能モデル図・概念データモデル図

（4）非機能要件定義書／品質特性シナリオ

（5）グランドデザイン

3-5はシステムを作るとなると普通に作成するもの、1-2が如何にもアーキテクトといった風情でしょうか。記事では Why What に目を向けて、と書かれていましたが、Why はともかく What は気にするものだと思います。3-5は What に相当するもの、まともなエンジニアなら当然、文書化まではしなくとも頭の中には入っているものだと思います。1-2 はWhy相当、雇われエンジニアには口の出し難い部分です。アーキテクトと名乗ることでこういう部分にまで口を出そうということでしょうかね。

第2回 基本設計工程のITアーキテクト　2012-10-02

基本設計での成果物として上げられているのは以下の五つ。

（1）論理データモデル図

（2）パッケージ図（永続化視点）

（3）パッケージ図（機能視点）

（4）アーキテクチャー設計ドキュメント

（5）アーキテクチャー評価ドキュメント

データベースを使うシステムに特化しているところが気になりますが、やっていることはデータ中心モデルでの分割統治と全体最適化。データベース云々に引き摺られ無ければ制御系のシステムでも通用する方法論でしょう。プロジェクトの数的にデータベースアプリに注目が集まるのは仕方のないところでしょうが、世の中にはDBを使わないアプリも存在していることを念頭に置いておいて欲しいものです。ですがこれらもまた普通に用意する代物、普通のエンジニアとアーキテクトってどこが違うのは解らないままです。逆にいままで未分化のエンジニアがやっていた仕事（仕事が先）のこの部分を担当するのをアーキテクトと呼びましょうという流れでしょうか。でも、4-5 は個人的には作成すべき文書だとは思いますが、作らないプロジェクトの方が多いかも知れません。こういうのは複数の実現方法がある中でこういう方針でという宣言みたいなところがあります。いつも思うのですが、エンジニアの大半には複数の実現方法というものが思い浮かんでいないのかも知れません。

第3回　詳細設計工程のITアーキテクト　2012-10-03

詳細設計で上げられていたのは下の五つ。

（1）機能パッケージをまたがる状態遷移図

（2）排他制御（ロック）仕様書

（3）コンポーネント図

（4）インピーダンスミスマッチの解決手順書

（5）物理データモデル図

まあ、全部が全部必要なものではないでしょうが、この中でアーキテクトっぽいというと４のインピーダンスミスマッチの解決手順。システム化というかプログラムは常に解決したい問題とそれを実現するツール（まあ、プログラム言語とかライブラリ）との間に粒度の差（インピーダンスミスマッチ）があり、両端にあるそれを繋ぎあわせていく作業だと聞いたことがあります（古典的なプログラミング本のどれかだったと思いますが）。そういう意味では重要な４の文書、なんですが明文化するのは珍しいかもしれません。オブジェクト指向での階層化されたクラス構成なんかはまるまるこのためのものなのですが、インピーダンスミスマッチを解決するための資料にはなっていない例が多いように思えます。

第4回 実装・テスト工程のITアーキテクト　2012-10-04

実装テストで上げられた成果物は以下の五つ。

（1）アプリケーションフレームワーク

（2）コーディング規約

（3）機能横断的テストシナリオ

（4）単体テスト完了基準

（5）性能評価レポート

昔はあまり見かけなかったのに最近よく見るようになったものがアプリケーションフレームワーク。フレームワークは危ない用語で、問題は人によって意味するものが全く違っていたりします。ここで解説されたアプリケーションフレームワークは抽象的ではありますがわりと納得できるレベルのもの。でも世間一般では.NETやTomcatをアプリケーションフレームワークと呼ぶ方が主力です。まあ、確かにフレームワークではありますが、両方共まだまだ範囲が広過ぎで、そこにもう一段個別アプリケーションへの限定を掛けてこそアプリケーションフレームワークと呼べるものになると思います。他の文書は普通に良く見かけるもの。ただ、コーディング規約はね、プロジェクト用にでっち上げたレベルのものが多すぎです。まあ会社単位（事業所単位）で経験を積み上げてきているところもあるようですが、そういうのは発注元、元請けレベルでないと構築できません。でもって日本の場合、そういうレベルの人間はだいたいプログラミング慣れしていないのですよね。そのあたりに変なコーディング規約が蔓延る原因がありそうです。最近ですとOSSプロジェクトなんかで適用しているコーディング規約がありますから、素直にそういうのを持ち込んで来ればいいのにと思います（実際にそうしている会社もありました）。

第5回 保守運用・移行工程のITアーキテクト　2012-10-05

雇われ下請けエンジニアとしてはあまり縁のない保守運用工程、成果物は以下の五つが上げられています。

（1）アプリケーション改修基準書

（2）モジュールの依存関係図

（3）システム稼働統計レポート

（4）改善アーキテクチャードキュメント

（5）実装に基づき最新化した文書

　　（コンポーネント図、状態遷移図、データモデル図）

キモは日々（というほど頻繁ではないでしょうか）変わっていくシステムの構造を表した文書を最新（実際のコード）にあったものに保守していくところでしょうか。予算、時間の製薬で疎かにされやすいところではあります。しかし初期設計のアーキテクチャ文書が確りしていると以外と原型を留めているものです。回収する時にアーキテクチャ文書だけでも保守しておいてくれれば結構追い掛けられるものです。

と、某社で某システムのアーキテクチャ設計をしながら読んでみたわけですが、いいチェックリストになりました。アーキテクチャ、アーキテクト、それほど担当部分が明確になっているとは思えませんので、こういう記事なんかでイメージが固まってくると色々とやりやすくなりそうです。