先週から原稿の締め切りが重なり、かつクライアント向けの書き物が多かったのでブログの更新が止まりました。「ヒトが一週間で書ける文字量は決まっている」と思っているのですが、他の人はどうなんだろう。なんか、ずっと同じリズムでブログを書けるヒトは本当にすごいと思う。
閑話休題。某雑誌の執筆者飲み会に行ったときのこと。雑誌の方を目の前に「ITアーキテクトが認知されないのはマスコミのせいもありますよ。PMばっかり持ち上げて。いま、現場で必要なのはテクノロジーとマネジメントのバランスですよ！」みたいなことを言ってみました。
「確かにそうかも」と同意していただいた後に"ITアーキテクトを流行らせにくい理由"を教えてもらいました。
PMの大切さを伝えるときに、ロジックだけではなくてストーリーで伝えることも大事だと思っています。その点、PMは危機的な状況に陥ったプロジェクトを救うストーリーがある。ITアーキテクトはね、ないんですよ。
なるほど！！みんな逆境に打ち勝つヒーローが好きだもんね、うんうん。...じゃなくて、そういうコトにならないように事前にアーキテクチャをきちんと考えるのがITアーキテクトの役目なのですよ！そもそも危機に陥らない方が良いわけであって(ry...まぁ、ただ、言われていることは分かります。
何でもそうなのですが、「これをやっておけば後から良いですよ」というものにコストをかけるのは非常に勇気のいることです。リスクマネジメントの基本でしょっとは言うモノの、対象がよく分からないものだと確かにたいへん。
ところがメソッドとして提供されいているモノに対しては、意味も分からずにコストをかけたりすることもあります。PMなんて、それの百花繚乱でPMP、PMBOKからXP、Scramまで、色々とあるわけです。本だけ読んでプラクティスを真似してみるなんて、まさにそれ。
ようはITアーキテクトがやるようなことがメソッドとして安定していないということですね。やっぱりITアーキテクトって、まだまだなのかな？と思っていたら、同席していた"Smater Planet"な某社のPMが、
ITアーキテクトがいないとプロジェクトが始まらないですよ。お客様の要件もビジネス環境も技術も複雑すぎて、最初にITアーキテクトが整理してくれないとPMなんか、仕事がないですよ。
だって。さすが"ITアーキテクト"という言葉を作った会社。体制としてITアーキテクト（ビジネスアーキテクトという言葉を推進していますが）だけを集めた部署を作って動いているとは聞いていたのですが、PMがそういう認識なんですか（もちろん、全員ではないでしょうが）。
この格差はでかいなぁ。かなりでかい。このブログで何度も「アーキテクチャなきプロジェクトマネジメントには意味がない」書いていますが、それがきちんと回っているわけですね。ということは、それんりそれなりにきちっとしたメソッドがあるんでしょうね。
一方で、"Smater Planet"な某社もレドモンドの某社も、ITアーキテクトの認定試験は「ITアーキテクトがITアーキテクトになれるかを審査する」という"ジェダイ評議会制"をとっています。ITアーキテクトのセンスは、ITアーキテクトにもにしか分からない、ということだそうです。メソッドがあったとしても、深いところになってくると、そういうものなのでしょうね。
では、どうやったらITアーキテクトが流行るんですかね？たとえば「技術が分かるPM」のITアーキテクト感観とか知りたいなぁ。なんとなくですが、年齢が高めの「技術が分かるPM」という方は多いとは思うのですが、どうしても安全策をとりがちというか、アーキテクチャのパターンまで踏み込んでこないという気がします。確かに技術をよく分かっているんだけど、フォーカスがマネジメント優先過ぎて、アーキテクチャ的な可能性をつぶしている（たとえば拡張性とかね）。
あとは「ITアーキテクト」というとビジネスコンサル的なニオイがしてイメージが悪いのも確か。EA的な事ばかりをノタマワってばかり実装まで落ちてこない、みたいな。そういうのはITアーキテクトじゃないんですよ。良くある話で、車が作れないカーデザイナーとか、HTML/CSS組めないグラフィックデザイナーというか、料理ができない料理評論家とか、表現が構造の上にあることを理解できないヒトはITアーキテクトを名乗ってはいけません。
ITアーキテクトがアーキテクチャの可能性を引き出しつつ、PMが高いレベルでマネジメントを展開するようなことがしたいですね。そうすればITアーキテクトも認められるのでしょうか。
まぁ、今年はITアーキテクトを、PMと同じぐらい大事な職種として認めてもらえるような努力をしていきたいと思います。それがないとノウハウも溜まらないしね。
09/02/28追記 誤字が多すぎたので、少し訂正（取り消し線部）
