アーキテクチャの採用理由を説明できるか？：28歳から挑戦するITアーキテクト（2）

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

「なぜこのアーキテクチャを採用したんですか？」

「いや、なぜって……。いま作るならこれがいま一番はやってるからなんですけど……」

「このシステム、5年はこのまま改修しながら使い続ける予定なんですけど、もちろんそれは考えてのことですよね!?」

「いや、ちゃんと現場を教育し続ければ可能だと思うんですよ、第一……」

「できる、できないの話じゃないんですよ。じゃあ一体その教育コストと時間は誰が払うんですか？ あなた、払ってくれるんですかね？」

「いや、それは……」

「あなたの趣味で作られたら、運用する側はたまったもんじゃないんですよ。私のいってること、理解できますよね？」

「いえ、そもそもソフトウェアというのはオブジェクト指向に基づいてこう作るべきというのが最近の考え方で……」

「あんたから大学の授業みたいなのを聞きたいんじゃないんだよ、もういい。帰って」

　冒頭から修羅場のシーンを書いてしまったが、（多少複数の事象を加え脚色は加えているが）これは筆者が現実に経験した事実だ。幸い、筆者はこのときITアーキテクトの立場ではなく、側面支援の役割だったためこのお客さまからの怒りを一身に受けることはなかったのだが、この怒りを買ったITアーキテクトは次の日から姿を消した。

「専門家」の理屈

　「ITのことは専門家に任せておけばいい。素人は口を出すな」。まるでそういわんばかりの「専門家」が幅を利かせて、実際の顧客の要望をないがしろにする例を筆者は幾度も目にしてきた。

　これまでIT分野、特にSI等での企業システム構築の場合、採用した技術やプラットフォームに対しての採用基準は、関係する個々人の「趣味」や「経験」など、実に合理性のない基準が幅を利かせてきたのではないだろうかと考えている。コンピュータという「玄人だけが理解できる難しそうな機械」に対して、「学者」である「博士」が作業を行う、まるで昭和のアニメーションのようなノリだ。

　しかし、そうした「古き良き時代」は過ぎ、ITシステムは企業成長の根幹を支える重要な基幹として、その位置付けはこれまでになく重要になってきている。また、構築を担当する人間も、理工学系の学者ではなく、専門家の助けを得ながらごく一般の業務を知る人間が、業務の延長でかかわることが非常に多くなってきた。もはや一般の社会人スキルの1つである、との視点も分野によっては可能だろう。つまり、もはや専門家の独壇場ではない、という事実をまずは受け入れるべきだ。

　また、企業がITシステムを発注する場合、莫大な金額が動くことになるが、われわれはそれ相当の合理性を持って作業に当たっているだろうか。学問の延長として、多額のお金をいただいて作るITシステムに対し、「博士」よろしくIT技術者の立場を利用してアカデミックな実験の場として「悪用」していないだろうか。われわれが自ら再チェックしなければならない項目は非常に多いのではないだろうか。

作り手側の傲慢

　これは筆者の自戒も込められているが、企業システム構築の提案時などにおいて、アーキテクチャの採用について説明する場合「生産効率の向上に寄与する」などという、作り手側の理屈を全面に押し出した文言を何度も使った経験がある。

　しかし、これは作り手側の傲慢でしかないのではないだろうか。

　このような文言に代表される言葉を使っていた当時の筆者の考えでは、「生産効率の向上＝プロジェクト失敗率の低下＝利益率の達成」、引いては「顧客の成功」という、ステレオタイプな図式が頭を占めていた（それに対して何の疑いも持っていなかった！）。

　賢明な読者なら理解できるとおり、この図式には大きな欠陥が潜んでいる。自らの利益達成から顧客の成功の間に飛躍があることだ。これは筆者の部下も含め、近年の20代後半の「腕に自信のある」プログラマが陥りがちなわなだが、自分の関心のある技術をむやみに採用し、その採用に際して「雑誌などで盛んに取り上げられているから」という、実はあまり根拠がない理由で「隣の人が採用しているから」「右に倣え」で主張する例が後を絶たない。横一列の大好きな日本文化ならではの事象かもしれないが（それはそれで有効に働く場合も多いが）、自らの頭で本気になり考えるプロセスを飛ばしていることが多いため、とても褒められたものではない。

　当然だが、顧客の成功のためには、利用者本人の要望に応じた、合理的な選択と正しい設計が欠かせない。ITアーキテクトはそのためにあるといっても過言ではないだろう。

迫られる「説明責任」

　他業種、特に医療分野などでは、処置に対する説明責任（アカウンタビリティ）を全うする必要がある、というのはすでに世の中で常識として根付きつつある。これが行われない場合、世の中から厳しいペナルティを負うことになる。それがIT分野であっても、そのルールから逃れられるはずがない。逆に、これまで特別扱いされてきた付けが回ってきており、市場からより厳しい目で見られつつあるのが近年の傾向である。

　こうした「IT業界包囲網」は、近年の不正取引発生が誘発した会計基準の厳格化［注］などの形で現実になりつつある。また、IT技術者の技術レベルの客観的基準であるITSS、システム構築能力の指標となるCMMI、運用に関するITILなどが持てはやされているのも、こうしたIT業界に対する自浄能力を求めたものであると見なすこともできるだろう。

　次世代ITアーキテクトとなるならば、ぜひこうした説明責任を全うし、よりフェアなシステム設計を行わない限り、生き残ることができないのではないかと、筆者は強い危機感を持っている。ぜひこうした点を第1に作業を行ってほしいと切に願う次第だ。

アーキテクチャ採用を合理的に説明できる、ということ

　ところで、筆者は日ごろの業務において、以下の観点でアーキテクチャ設計作業に当たっている。これは筆者が常に心掛けていることの一部である。

　・そのアーキテクチャは企業の長期保守・改善に耐えられるシンプルなものか？ 将来のマイグレーション時に発生する問題の可能性を、現状分かる範囲内で回避したものか？

　・そのフレームワークやライブラリは長期保守に耐えられるだけの体制を取ることができるものか？

　・採用する技術は、全体で最もコストを低くできる可能性が高いデファクト・スタンダードなものか？

　・運用中の改修に当たり、特別な作業者への技術面での追加教育等が必要でないものか？

　・その製品のサポート体制やライフサイクルは明確かつ納得できるものか？ 年間費用は合理的な範囲か？

　・その他、独善的かつ独り善がりな採用基準となっていないか

　こうした基準で採用した要素1つ1つには合理的な選定理由があるため、仮に発注担当者や発注側の取締役などから指摘を受けた場合でも、単なるののしり合いではなく高い次元での検討へと昇華させることができる。

　もちろん、自らが導き出した理由がいつもそのまま通るはずがないという現実も理解すべきだ。巨額の金が動き、多数の利害関係者が関与する場所には、当然、政治的な働きかけや、それに伴う理不尽な決定が付き物だ。そうした局面でも投げ出さず、根気よく自らの主張を働きかけ、合意を導き出すためにも、タフ・ネゴシエイターとして自らの思考を合理的に保ち、常に修正を掛けて関係者間の合意を導き出す力が必要となってくる。

　こうした合理的思考のスキルは何もITアーキテクトだけではなく、ごく一般的なプロフェッショナルとしてのスキルに相当する。IT系の仕事だから、ITと関係ないからと無関心を装わず、日々の自助努力が求められることにも可能な限り早めに気付くべきだ。このような継続的な鍛錬もまた、ITアーキテクトとして活躍するための心強い下地となってくれるだろう。