連載
» 2004年02月10日 12時00分 UPDATE

ITアーキテクト宣言! :ITアーキテクト宣言!

[谷古宇浩司(@IT編集部),@IT]

ソフトウェア開発現場を覆う憂うつ

 ソフトウェア開発の現場を分厚い暗雲のごとくさまざまな憂うつが覆っている。この暗雲とは、開発作業を遅延させ、あるいは失敗に陥れるたぐいの多種多様なボトルネックのことである。IT業界のキーマン、特に次世代の開発プロセスに対し、何らかの積極的なかかわりをみせる人々にインタビューを行えば行うほど、暗雲の厚さは増すばかりである。もちろん、彼らはこのような憂うつな状況を前に絶望し、手をこまねいているだけではない。それぞれの立場で解決策を模索し、時には具体的な方策を目に見える形で、もちろん、自分たちのビジネスに直接結び付く形で、提供しようとしている。

 彼らの意見はさまざまで、時には対立する場合もあるのだが、共通していえることは、ソフトウェア開発という複雑怪奇な作業について「すべての利害関係者を満足させるきちんとした“方法”があるはずだ」という認識を持っていることである。

 つまり、適切な“プロセス”が必要というわけだ。また“プロセス”の話か? このプロセスにかかわる議論については、これまで散々聞いてきて、耳にタコができるくらいだ、という人も多いかもしれない。だが、それにもかかわらず、このような議論が尽きないのはなぜなのか? アットマーク・アイティがソフトウェア開発の上流工程を起点に、プロジェクト管理やコミュニケーションといった広範な範囲のテーマを扱う「ITアーキテクト」を立ち上げたのは、そもそもこのような基本的な疑問をさまざまな角度から議論できる場が必要だと思ったからである。だが、ともあれ、まずは話を先に進めよう。

開発プロセスをめぐる堂々巡り

 豆蔵CEO 羽生田栄一氏が考える開発現場の憂うつとは、例えば、製品開発期間あるいはシステム・インテグレーション期間が著しく短期化されている点だという。

 ITシステムがクライアント/サーバベースからWebベースに移行し始めた2000年ごろからこの傾向は加速し始めた。そのころから、不特定多数の利用者を想定した、分散ネットワークを基盤としたシステム構築の需要が増えている。これも羽生田氏によれば、ソフトウェア開発現場に降りかかっている危機の一種である。

 メインフレームとWebシステムを連携させるという、いわゆるEAI需要も、社内システムの再構築化が進展するにつれて多くなってきた案件だが、ここで活用される技術には、オブジェクト指向的な発想、技術が導入されることが多い。すなわち「アーキテクチャをあらかじめUMLでしっかり記述し、設計上の穴をなくすこと」(羽生田氏)。インターフェイスを通じてラッピングを行うには、上流工程のボトルネックはできるだけ排除しておいた方が得策なアーキテクチャを採用する場合が多いというのである。

 さらにエンジニアにとっては憂うつな事態が降りかかる。インターネットが社会の一般的なインフラになるのと並行して、ITシステムに対する信頼性、堅牢性といったユーザーの“期待”は高まるばかりである。リリースの段階でバグが見つかることは論外である。都市銀行の合併劇に伴うシステム統合時の悲劇を思い出せばいい。

 このような、ソフトウェア開発エンジニアにとって憂うつな状況を、いかに改善していけばいいのか。羽生田氏が提案するのは、(1)リスクへの早期対処、(2)変化とスピードへの対応、(3)ピープルウェア(トム・デマルコ氏)と組織改善の3つであるという。

 (1)についてはつまり「(顧客側の)要求と実装の乖離(かいり)をいかにして回避するか」という命題を達成するための対策を考えること。ウォーターフォールモデルによる実装段階における“つじつま合わせ”を避け、反復型の開発プロセスを導入することで、開発の早期段階でできるだけリスクを洗い出し、全体としてリスクの低減を狙うものである。UP(Unified Process)はまさにこのようなプロセスの体現である。

 (2)についてはXP(eXtreme Programming)に代表されるアジャイルプロセスの出現に象徴される。開発の初期段階で仕様を確定させ、後はこの仕様どおりに粛々と開発作業を遂行していく、という開発の仕方に対するアンチテーゼとして登場したXPは、とにかく現場レベルの変化に対し柔軟に対処することこそが、ソフトウェア開発を成功に導くものだとする1つの解答でもあった。

 (3)ピープルウェアはトム・デマルコ氏が提唱する、エンジニア(人)の視点を重要視する考えである。確かに、開発プロセスという言葉、考え方には上から見る態度が見え隠れしており、現場のエンジニアの、プログラマとしての考え方を無視する場合があったといえよう。しかし、一方で組織全体の方向性を決めるためには、体系的な枠組みが必要なことも確かである。前者がXPに代表されるアジャイルプロセスの導入を肯定しているとすれば、後者はCMM(Capability Maturity Model for Software)の導入によるプロセスの標準化の肯定を指す。

 上述の議論が目新しいものではないことは承知のうえであるし、羽生田氏ももちろん承知しているはずである。しかし、ここには近年の開発プロセスにかかわる議論が集約されており、繰り返されなければならないものである。なぜなら、ここにこそソフトウェア開発をめぐるさまざまな問題の根があるかもしれないからだ。

 「ビジネス分析、要求分析(仕様定義)、システム設計・実装。これら3つの段階はシステム開発の基本中の基本である。つまり、それぞれWhy、What、Howに当たるものだ。しかし、うまく機能していない」と羽生田氏はつぶやく。このような一連の問題をさらに簡略化し、問題の核を絞っていくと、「要求」(ビジネス)と「設計」(IT)のリアルタイムの同期がどこまでうまく機能しているか、ということになるかもしれない。羽生田氏はこれを、経営とITをつなぐ技術通訳のような人材が求められると表現し、このような技術通訳者こそ、“アーキテクト”と呼ばれる役割を担う人材であるとする。

ITアーキテクトとは?

 建築の世界における著名な建築家はアーキテクトとも称される。では、ソフトウェア開発におけるアーキテクト、ITアーキテクトとはどのような役割を担う人材なのか。羽生田氏の定義によれば、要求と設計(実装も含む)の乖離をできるだけなくす役割の人材ということになるが、まだ漠然としている。要するに設計者なのか。

 ウルシステムズの代表取締役社長 漆原茂氏の定義は、必ずしも羽生田氏とは一致しない。すなわち、「プロジェクト管理を含め、開発工程全体を現場のスタッフより一段高い位置から見ることができる人材」ということになる。漆原氏によると、必ずしも“アーキテクト”という言葉は適切ではないのかもしれない、という。そもそも、漆原氏は、現在の“開発プロセスブーム”ともいえる現象に対し、非常に批判的な意見を持つ。「UML」「オブジェクト指向」「アジャイル」「XP」「テスト駆動」「MDA」……。最近の開発プロセスをめぐる言説を構成する数多くのキーワードが結局、どの程度ソフトウェア開発の問題点を緩和することに役立ったのかと。この問題に関する詳細については、漆原氏およびウルシステムズのスタッフが連載で解答を示す予定となっている。請うご期待。

 イーシー・ワンの取締役副社長 最首英裕氏もユニークな意見を持っている。最首氏は、厳密に“アーキテクト”の定義を示したわけではないが、現在のソフトウェア開発が抱える問題を解決するには、顧客企業のビジネスを定義し直し、ITシステムへと翻訳し直す人材が求められるという。この点で羽生田氏の意見と似通う部分がある。ただし、最首氏が属するイーシー・ワンは自社開発のコンポーネント・フレームワーク体系を有し、独自の開発理論も持っている。企業のITシステムを再利用可能なコンポーネントを組み合わせることで開発していくという極めて現代的な同社のビジネスモデルはしかし、単純にコンポーネントを組み合わせればシステムが構築されていくという単純なものではあり得ない。IT化を想定する企業の業務を理解し、モデルを構築し、実装作業にまで落とし込んでいくこと(もちろん、リスク回避の方策を盛り込んだプロセスを組み上げたうえで)を包括的に管理できる人材でなければ、コンポーネント開発の有効性を引き出すことはできない。イメージとしてはコンサルティング企業のコンサルタントに近いが、ITの実戦経験を備えているという点で、従来型のコンサルタントとは一味違う。最首氏のコンポーネント型開発に関する実践および理論面の話も連載として掲載する予定である。

 『職業としてのソフトウェアアーキテクト』(マーク・スウェル、ローラ・スウェル著/倉骨彰訳、ピアソン・エデュケーション)に次のような記述がある。「ソフトウェアアーキテクトは、ソフトウェアの設計を仕事とする、設計段階の総監である」「ソフトウェアアーキテクトはシステムのルック&フィール、機能、全体的な構成を考えるのを仕事とするが、ソフトウェアエンジニアは設計を検証したり、評価したり、アイデアを提供したりしながら、その設計が堅牢であることを確実にするのを仕事とする」。

 実際、アーキテクトという役割に対する定義はさまざまである。設計作業に携わる役割のエンジニアというのは基本的に存在しないといっていい。分析作業を行うアナリスト的な役割をも含め、アーキテクトと呼ぶ人もいれば、さらにプロジェクト管理も含めた役割をアーキテクトに含める人もいる。プログラマと同義である場合もあれば、プロジェクト・マネージャと同義である場合、コンサルタント、アナリストと同じ意味である場合もあるのである。アットマーク・アイティでは、アーキテクトの定義を固めることはあえてしない。プログラマよりアーキテクトが偉いなどという類型的な分け方をするつもりも毛頭ない。いまはただ、上流工程に関連するさまざまな作業を担当する役割を象徴的にアーキテクト(ITアーキテクト)と称するのみである。ソフトウェア開発に携わるすべての人々が安心してぐっすり眠れるような解決策を模索する場、議論する場、それが「ITアーキテクト」フォーラムになればよいと考えている。

Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ