情報システムには必ずアーキテクチャーがある。このことに異論のある人はいないだろう。では、そのアーキテクチャーは誰が決めているのか？
アーキテクチャーを決める人といえば、真っ先に「ITアーキテクト」が思い浮かぶ。でも、プロジェクトマネジャーと名乗る人は多くいるものの、ITアーキテクトと名乗る人に出会うことは少ない。少なくとも、ITアーキテクトと名乗る人が、世の中にある全てのシステムのアーキテクチャーを決めているとはとても思えない。
システム構築プロジェクトでは、（ITアーキテクトと呼ばれていない）誰かがITアーキテクトの役目を果たしていることになる。プロジェクトマネジャー、プロジェクトリーダー、技術に強いベテランエンジニアなど、さまざまなケースがある。
こうした状況からいえることは、「責任を持ってアーキテクチャーを決める人（＝ITアーキテクト）である」という自覚を持たないエンジニアによって、システムのアーキテクチャーが決まっているケースが少なくないということだ。
ここに大きな問題があるように思えてならない。
筆者が「アーキテクチャー」というフレーズを耳にするのは、システムにトラブルが起こったときだ。担当するエンジニアにトラブル原因を尋ねると、「この部分のアーキテクチャーがよくなかった」といった話になることがある。アーキテクチャーが悪ければ、システムはトラブルを起こすといっても言い過ぎではない。アーキテクチャーはシステムにとって極めて重要なものである。
一方で、知り合いのエンジニアにこんな話を聞いた。「ITアーキテクト役を任されたエンジニアは、何をどのようにすべきか分からないまま経験を頼りにアーキテクチャーを設計している」。そのエンジニアは続けてこうも指摘した。「そうしたプロジェクトでは、結果的に『レスポンスが遅い』『機能追加や変更が思ったようにできない』といったシステムを構築してしまう」。
ITアーキテクトとして必要な知識やスキルを身に付けていないのだから、仕方のない面はあるだろう。こうした状況を少しでも改善するには、ITアーキテクトとして体系的に学べる場が必要だ。幸いにしてITアーキテクトとして学ぶべき方法論などは整いつつある。
責任を持ってアーキテクチャーを決める人という意味での「ITアーキテクト」。この役割は、プロジェクトマネジャーと並ぶくらい重要だと思う。ぜひあなたも挑戦してほしい。
