その設計はちゃんと動くのか？：28歳から挑戦するITアーキテクト（4）（2/2 ページ）

[岩崎浩文（株式会社 豆蔵 BS事業部 エンタープライズシステムグループ），＠IT]

意外に知らない具体的な製品知識

　ところが多くの若手プログラマーにおいては、プログラミング言語や開発方法論など比較的抽象的なことに多くの興味がいってしまい、肝心のそれらを動作させる基盤となるべきアプリケーションサーバやバーチャルマシン、OS、ハードウェア、ネットワークなどの「低レベル」技術（もちろん本質的な意味において、ではない）について、恐ろしく無知であることが多い。

図2 実は技術に恐ろしく無知……

　特に多いのが、自らの開発環境や作り上げたアプリケーションの動作環境を自分1人で組み立てることすらできない例だ。OSのインストール・設定作業ができない（やったことがない）というレベルから、実際に動作させる環境（最近ではアプリケーションサーバやデータベース）のインストールや設定ができないというレベルまでさまざまだが、とにかくそれをもってITアーキテクトとしてシステム全体のアーキテクチャを比較・決定するには、致命的に知識が不足している例が後を絶たない［※1］。

［※1］例えば2005年現在であれば、企業向けシステムのアプリケーションアーキテクチャを考えた場合、最低でもフルセットのJ2EE 1.4と.NET Framework 1.1の両者を設計・構築できる程度の技術力、およびそのうえでの製品の知識は欲しいところだ。

　こうした現象は、各作業が高度化・専門化し、それぞれの作業を行う機会が減ってきていることもあるだろう。しかし、IT技術者と名乗る者が自らの作業環境すら他人におぜん立てしてもらわなければ構築できない、というのでは情けない限りだ。また現実にも、数百人規模の開発プロジェクトであっても、高額な製品ベンダによるプロフェッショナルサービスが入っての手厚いサポートが付く場合は極めて少なく、結局ITアーキテクトは誰にも頼ることができず1人でさまざまな構成を決めなければならない場合がほとんどだ。

　一時代前であれば、製品特定契約者以外の情報提供が限られていたため、仕事で接する機会がない限り知ることすらできなかったのだが、最近では製品マニュアルからQ＆A、バグ情報までWeb上でいくらでも閲覧、検索できる。やろうと思えば休日を利用していくらでも読んだり試したりすることができるわけだ。それでも「知らない」というのは、技術者のサボタージュであると断罪されても致し方あるまい。特にオフショアリングにより、ライバルは海外の有能な技術者と広がった。われわれは彼らに勝てるだろうか。

その知識だけで設計から運用状態に持ち込めるのだろうか？

　ITアーキテクトとして顧客から、またはプロジェクト作業者から期待されることは、ソフトウェアやハードウェアの設計は当然として、その設計を基に実際の連続運用状態まで持ち込むことができる、ということになる。

　連続運用まで持ち込むというのは、例えばデータ構造が論理的に破たんせず設計でき、ソフトウェア構築が滞りなく行え、ハードウェア構成も予定どおり構築でき、その上でのソフトウェア配備・動作が完成し、致命的なシステム停止が発生せず、性能の劣化が発生した場合でも解決策があり、どうしても避けられないバグの修正や反映も速やかに行え、日々変化する顧客のビジネスにある程度追従して修正を繰り返すことができるシステムを構築するということだ。当然だが、顧客はそこまで求めている。

　あなたのいまの知識で、それが果たして可能だろうか。この中で、特定の個所のみに目がいっていないだろうか。

継続して新しい技術をキャッチアップし続けよ

　ところで、実際のITアーキテクトとしての仕事現場では、ITバブル最盛期に流行した、Webのシステムを全く新しく構築するという仕事は形を潜め、既存のシステムの修正や既存のシステムを参考に新しいプラットフォームや言語に乗り換える、という作業の方が圧倒的に多くなりつつある。

　こうした場合、ITアーキテクトが自分の好き勝手にアーキテクチャを決めるということなどできるはずもなく、必ず「既存システム」という呪縛から逃れられない状況となる［※2］。

［※2］多分若手の方が考えているほどスッキリしたバラ色の仕事ではなく、逆にドロドロとした人間関係や複雑怪奇なハウスルールがたんまりと待ち構えている難解な仕事であると認識した方が正確だろう。

　こうした作業を行ううえでは、過去のシステムを把握する作業からは逃れられない。過去に作られた多くのシステムには、仕様書のようなきれいな文書が残っていることは少なく、大半はソースコードのみが残っているだけ（ひどい場合だとバイナリのみ）、良くてもドキュメントはあるが、構築後の度重なる修正の結果、リリース当初の文書の内容とは絶望的に懸け離れた状態になっている、というものだ。

　こうしたうえでの作業で欠かせないのが、やはり古い技術の知識となる。もちろん完全に把握するのは不可能だとしても、理解するきっかけを持っているのといないのでは、天と地ほどの差が生じてしまう。これは紛れもなく、アーキテクトとしての「懐（ふところ）の深さ」となる。

　もちろん、若手の方に古い技術をいまから学習せよ、といっているわけではない（ハードウェアが現存しない、ソフトウェアもない、書籍もない、個人購入も無理など事実上不可能なことが多々ある）。いま学習した内容が、今後ITアーキテクトとしてどこで役に立つか分からない、という話だ。

　結局、こうした実力を養うためには、やはり継続した日々の情報の更新と成功体験の積み重ねが重要である、というごく当たり前の事実に突き当たってしまう。

　われわれには日々の鍛錬を怠る暇はないのだ。

「28歳から挑戦するITアーキテクト」バックナンバー

• 最低10年使える業務アプリケーション（後編）
• 最低10年使える業務アプリケーション（前編）
• アプリケーションサーバを自在に操れ！
• システム全体を連続稼働に持ち込め！
• 基盤技術にロック・オンされていないか？
• ITアーキテクトを実践する
• 誰のためにシステムをつくっているのか？
• その設計はちゃんと動くのか？
• その設計で運用は救われるのか
• アーキテクチャの採用理由を説明できるか？
• ITアーキテクトへの“脱皮”の覚悟