富士通で最近、「ビジネスアーキテクト」と呼ぶ職種ができた。どんな仕事だろうかと思い、富士通の人に聞いてみたら、なんだシステムコンサルタントの仕事と変わらないじゃないか。で、「なんでコンサルタントと呼ばないの」と聞いたら、「コンサルタントだと顧客に『言うだけの人』とイメージをもたれますから」との返事。なるほど・・・って納得していてはいけない。

　確かにユーザー企業にはそんなイメージがあり、システム部門なんかには「エラそうなことばかり言う評論家」と目の仇にする人もいる。だけど考えてみると、コンサルタントって本来「言うだけの人」でしょ。つまりコーチ。なぜ、それがいけないのだろう。確かにろくでもないコンサルタントもいるけれど、どうもその辺りにCIOやシステム部門の了見違いがあるような気がする。

　そもそもコンサルティングを依頼して意味があるのは、依頼した経営トップやCIOが自分の仕事に責任を持てる場合に限られる。そんなの当たり前じゃんと言うことなかれ。経営トップはともかく、CIOにはどうもその辺りが怪しい人が多い。システムコンサルタントの場合、顧客の経営トップなどから経営課題を聞き、そこからIT面でのニーズを抽出し、システム化計画に落とし込む“お手伝い”をするのが仕事だ。そして、この作業はCIOの本来の責務である。

　だからコンサルを受けても、システム化計画を作る責任主体はCIOやそのスタッフである。そのあたりの認識が希薄なCIOだと、システム化計画書作りまでをコンサルタントに完全丸投げ。普通、コンサルタントの仕事はシステム化計画のところまでだから、今度は具体的な要件定義を、システム開発を発注するSIerの丸投げする。その結果、よく話に聞くミゼラブルな事態が発生することになる。

　この手のCIO、というかシステム部長は、要件定義も自分たちの仕事であるという自覚があまりない。で、丸投げされたSIerのSEがユーザー部門などにヒアリングしてまとめた要件定義は、システム化計画の内容と似て非なるものになる。そりゃ当たり前で、業務改革のためのITなんぞ、ユーザー部門にとっては迷惑千万だから、“現場の実態に即したもの”に換骨奪胎しようとする。その結果、わけの分からないシステムが出来上がることになる。

　腕の良いコンサルタントなら、ユーザー部門のキーパーソンを巻き込みながらシステム化計画をまとめるだろうが、CIOやシステム部門の体制がこの体たらくでは、それも限界。CIOが責任主体としてプロジェクトを最初から最後まで強力に統制しない限り、どんなに優秀なコンサルタントや外部のSEの力を借りても、戦略的なシステムなんぞを構築することは不可能である。

　さて、そんなことを書いてきたら、システムコンサルタントと富士通の言うビジネスアーキテクトの差分が見えてきた。ビジネスアーキテクトはシステムコンサルタントの仕事に加え、要件の定義までを引き受けるという。要は本来、顧客の仕事であるシステム化計画の策定や要件定義を、顧客に成り代わって代行してあげましょうということらしい。なるほど、だから「言うだけの人」とは違うわけだ。

　こう考えると、ビジネスアーキテクトという職種は思いのほか、ユーザー企業の現状を反映しているのかもしれない。以前、自らの仕事をスポーツでのコーチの役割になぞらえたコンサルタントから、「どんな一流選手に対しても、コーチはアドバイスできる」という話を聞いたことがある。しかし、それは相手が“選手”であることが前提。ITの世界では、今や顧客に代わりにバッターボックスに立つことを要求されているようだ。