ITアーキテクトを実践する：28歳から挑戦するITアーキテクト（7）〜実践編〜

ITアーキテクトという言葉が浸透し、『ITアーキテクトとは何か』という議論がさまざまなところで行われてきた。現在はその次の段階、すなわち『ITアーキテクトは実際に何をどうすべきなのか』という議論が戦わされる段階に入っている。

　2005年に始まった『28歳から挑戦するITアーキテクト』は、主にITアーキテクトとは何か、その問題とは何かという面から、人間的な問題を中心とし、汎用的な内容に特化した内容をお送りした。具体的な内容ではなく、目の前の技術が変革しようとも長期的に役に立つような基本となるものを中心にお話ししたつもりだ。

　しかし、そうした言説も目の前の課題を克服するきっかけとならなければ、ただのお説教となってしまう。なので、改めて、『実践篇』と銘打ち、ITアーキテクトを目指す若い方々の、目の前に立ち並ぶ無数の選択肢とその解決指針について、ITアーキテクトとしての視点で判断する指針をお伝えしたいと思う。

まず自らの延長上にある技術から始めよう

　ITスキルスタンダードにてITアーキテクトとして定義されている項目では、その活動領域として、主として戦略的情報化企画、従として開発が挙げられている（図1）。

図1 IT投資の局面と活動領域の関係（ITスキル標準概要から抜粋、クリックすると拡大）

　本連載の対象読者である20代後半から30代の方のほとんどは、本格的な戦略的情報化企画などやったことはないだろう。いきなりそうしたビジネス指向を基本とした高度な内容を中心に据えて説明を行ったところで、雲をつかむような話にしか聞こえないはずだ。またバリバリのプログラマの場合、内容によってはうさんくさくみえるところも多々あるだろう。

　実際、現在ITアーキテクトとして現役で活躍されているほとんどのシニア層の多くは、最初からITアーキテクトとしての業務を行っていたわけではない。最初は誰もが駆け出しのプログラマだったわけだ。彼らの成長とともに、市場の成熟が進み、偶然（と書いては語弊があるかもしれないが）現在「ITアーキテクト」としての分類ができているにすぎない。

　このように考えている筆者は、本連載で高度なビジネス分析手法やSOAなどの抽象度が高く新しい分野で、定量的な評価の定まらない変化の激しい個所をあえて避けた。高過ぎる理想を掲げ始める前から挫折するのではなく、まず身近なところからのステップアップこそが「千里の道も一歩から」となるだろう。本連載ではそうした方針で、難解な内容であるからこそまず読者の方に身近である内容から平易に進めていきたい。

アーキテクチャの選択眼を養え

　すでに何度も指摘していることだが、ITスキルスタンダードでのアプリケーション・スペシャリスト（一般でいわれるプログラマ）とITアーキテクトは異なる技術を要求されるものだ。前者の場合、どのようにプログラムを設計・構築するか、どうやって再利用性を上げるか、保守性はどうか、といったアプリケーション内部に特化したオペレーションが求められる（図2）。

図2 ITスキルフレームワーク（ITスキル標準概要から抜粋、クリックすると拡大）

　後者のITアーキテクトは、そうした入り組んだ局所的な個所のみならず、限られた予算内でそもそもどういった基盤上で、どのような選択を行い、発注者（大半の場合は顧客側の経営陣）が行ったIT投資へのリターンを支障なくもたらす（つまりプロジェクトを成功に導く）という、一段上の責務が生じる。

　さて、このとき、ITアーキテクトの最大のよりどころは、アーキテクチャを誤りなく選択できる眼（要するに総合的な「技術力」といい換えてもいいだろう）となる。一介のプログラマであれば、特に大きなプロジェクトであれば、とりわけ自分の知らないところで「決められた基盤と仕様で」プログラミングさせられるという極めて受動的な作業が大半を占める。ところが典型的なITアーキテクトの仕事となれば、そうした基盤や仕様に関する大半の事柄を、自らの責任において決めてゆかねばならない。

自らの「技術的都合」によらない選択を

　筆者のこれまでの経験では、こうしたアーキテクチャ、つまりハードウェアやOS、ネットワーク構成から、その上で動作するアプリケーションサーバ、データベース、その他ミドルウェアに関しては、作業者側の理屈が押し通されることが通常であった。要するに、自分の知らないことはやらない、知っていること一本やりで押し通す、といったものだ。さらにそこには基盤を提供する側のベンダのしがらみや販売計画など「大人の理屈」が入り込んでくる（こうした現象は、プロとしてビジネスを展開する以上、当たり前のことだ）。

　ただし、そうした政治的な動きはさておき、技術者ともなれば技術に対して誠実であり続けなければならない、という点もこれまでに指摘してきた。つまり、現状で適用できる技術にどれだけの選択肢があり、それぞれの長所・短所はどこで、目の前のプロジェクトに対して何を選択して構築すべきか、確固とした理論付けと確信を持たなければ、一般に数カ月から数年にわたるプロジェクトを完遂できないだろう。また発注者に対する説明責任も全うできない。

プロジェクト開始に当たって選択すべき項目

　さて、こうした点を踏まえ、いざプロジェクトを開始するに当たり決めるべきことだが、以下のように多岐にわたってくる。

• 実稼働機（および開発機）のハードウェア構成（CPU・メモリ・HDDなど）の選定
• 実稼働機（および開発機）のOSおよびそのバージョンの選定
• 実稼働機の機器構成およびネットワーク構成の設計
• ソフトウェアの稼働プラットフォームおよび開発言語の選定
• 開発に用いるIDE（またはそれに相当するソースコードエディタやツール）の選定
• 開発中・開発後に利用するソースコードリポジトリ（構成管理サーバ）の選定
• 実稼働機（および開発機）で用いるアプリケーションサーバの選定
• 実稼働機（および開発機）で用いるデータベースサーバの選定
• アプリケーション構築における層構成やアプリケーションフレームワークの選定
• 顧客からの要求やバグ・改善要望を管理する要求管理サーバの選定
• 自動ビルドや回帰テストを行うマスタービルドサーバの選定
• ソフトウェアリリース時のテスト計画および手順
• バックアップや縮退、ソフトウェア入れ替えや監視等の運用設計
• OSや基盤ソフトウェア更新時における対応方針の決定と普段からの調査

　ざっと挙げただけでも、これだけの内容がある。もちろん、これらはあくまで一般的な内容なので、実際のプロジェクトではさらに多くのさまつな対応が必要となってくるだろう。

ITは「特別なもの」から「ビジネスに組み込まれたもの」へ

　ここで挙げた選択肢の大きな基準として、ビジネスに直結して役立つかどうか、ということが近年特に重要となってきている。いまとなってはある意味当たり前の話だが、これまでは意外にIT側の理屈（こうあるべきだというような「べき論」や技術者側の嗜好）が選択に大きな影響を及ぼしてきた。これが、ITシステムを構築・運用するうえでの投資（つまりプロジェクト費用＋運用費用＋α）が、本業での稼ぎを「加速させる」かどうか、という観点で、その企業の経営層はおろか株主からも厳しくチェックを受ける形へと大きくその立場が変わってきたわけだ。

　これは近年話題となっていたEA（Enterprise Architecture）を見てみるとよく分かる（図3）。EAについて語るのは本題と大きくそれてしまうため割愛したいが、要するにITシステムを、ビジネスの観点を基に「あるべき姿へ」統治する体制を整える、というものだ（このような、ある種当たり前のものが重要視されるくらいビジネスの観点が軽視されてきた、という証しでもあるのだろう）。

図3 エンタープライズ・アーキテクチャ

　翻ってITのアーキテクチャ、つまり構造についての選択に戻れば、このようなビジネス側の要求を真正面から受け、真摯に選択と設計を行わなければならない、ということになってくる（こうした点もすでに本連載にて取り上げてきたため、未読の方はぜひ参照願いたい）。

リアルな現実を走破する方法

　こうした点を総合的にかんがみれば、ITシステムのアーキテクチャを選択・設計し、統治まで持ち込むのは、技術者が考えるよりもずっと大きな問題であることが漠然と理解できてくるのではないだろうか。またこれに加え、多くの利害関係者の要求やねたみなど実に人間的な問題も大きな要素として入り込んでくる。どう考えてもかなり難しい仕事となることだろう。

　だが、逆転の発想だが、だからといってこうした分野を避けたり、自分は向いてないからとあきらめたりするのは非常にもったいないのではないだろうか。

　特に近年のビジネス分野の傾向としては、誰でもできるような仕事は安く、意外に難しい分野の仕事は高く単価を取ることができる、という面が、以前にも増してはっきりと現れるようになってきた。それと連動して、人材市場についても、簡単な作業を行う分野よりはITアーキテクトのような難しい分野が大きく求められてきている。単純な作業を中心に海外へ作業を委託するオフショアリングが増えてきている傾向についても、これに対抗するには特に付加価値の高いITアーキテクトが有効だろう。

　ズバリいってしまえば、筆者の考えるところ、単純系の作業や管理者から割り振られた仕事を行う「作業員」から、自ら仕事をドライブできるITアーキテクトへ脱皮できた人が、「35歳限界説」に代表される、過酷な現実を走破できる確率を大幅に上げることができるだろう、ということだ。

　そのための方策として、次回から順番に必要な選択肢と必要な解決法について、過酷な現場をひた走る現役ITアーキテクトの1人でもある筆者の眼から判断を行い、それを読者の方の現実問題を解決するヒントとしていただきたいと考えている。

　次回はまず、根本となるソフトウェアの基盤について取り上げる予定だ。