アーキテクチャ選定のコツは「少し先を見ること」：超現場主義！ 失敗しないITプロジェクトマネジメント（3）

前回「ユーザー企業側プロジェクトマネージャの勘違い」は、「ヒト」に起因するプロジェクトのリスクファクターとその対処法について紹介した。今回は「モノ」に起因するプロジェクトのリスクファクターとして、システムのアーキテクチャとプロジェクトのリスクファクターの関係について紹介していきたい。

[玉木栄三郎, 須永啓太，イー・キャッシュ株式会社]

ITプロジェクトの現場でよくある風景

開発企業側プロジェクトマネージャ（以下PM）　「今回のシステム提案ですが、ぜひともLAMP（LinuxとApache、MySQL、PHP／Perl／Pythonを組み合わせたオープンソースのアプリケーション構築スタック）を採用したいと思います」

ユーザー企業側PM　「そのアーキテクチャのメリットって何？」

開発企業側PM　「まず、すべて無償なので低コストでシステムを導入できます。また開発の生産性も非常に高いです」

ユーザー企業側システム管理者　「でもうちのシステムってすべてWindowsベースのシステムが納入されていたけど。Linuxできるエンジニアがいないからメンテナンスできないよ」

ユーザー企業側PM　「じゃあシステムの運用保守は御社でやっていただけたりしませんかね？」

開発企業側PM　　「……」

プロジェクトリスクを減らすためのアーキテクチャ選定

　現在Webアプリケーションを中心にたくさんの技術がはんらんしている。

　データベースだけをとってもOracle、SQLServer、MySQL、Postgresなど数多くのデータベース製品がリリースされている。しかしそれらの性能を比較検討して採用しているプロジェクトはどのぐらいあるだろうか？ 商用データベースとオープンソースデータベースは機能において着実に差が広がってきており、ましてや商用データベースの違い、とりわけパフォーマンスなどという切り口ではシステムの体感レベルは、ほぼないに等しいといえる。

　Java、PHP、C#などオブジェクト指向言語だけでも数多くのプログラミング言語があるが、各言語の優位性など一長一短であるし、またどの言語がベストなどという議論はシステム構築のうえではあまり意味がない。このようなたくさんの技術がはんらんする中でプロジェクトのリスクファクターを摘み取るには、どのようなことに目を向けるべきであろうか？

アーキテクチャの採用

（1）人員の技術取得コストを考慮する

　前述の会話のとおり、いくらソフトウェアが無償でもそのソフトウェアに熟練したSEがいない場合、システム納入後にリスクが残る。特にWebシステムの場合、24時間稼働の対応や、セキュリティホールの対応など数多くのリスクを考慮しなくてはならない。このようなリスクは、システム導入コストとのトレードオフとして考えるのではなく、実際にメンテナンスをするSEの教育コストとシステム導入コストとを算出したうえで比較検討すべきなのである。

（2）自社で動いている現行システムのアーキテクチャを考慮する

　導入予定のシステムのアーキテクチャは、自社で稼働しているシステムのアーキテクチャとできるだけ統一するべきである。（1）の理由にも重なるが、使い慣れたアーキテクチャであれば、既存のSEがすぐに新システムに対応することができるため、よりリスクが低い。

　もう1つは将来的に起きるシステムの統合化や連携を見据えてアーキテクチャを考慮することが必要だからである。以下は、このポイントに関連した筆者の失敗談である。

　その企業ではハードウェアを何台も用意し、SQL Serverをクラスタリング対応させて全社の社内システムを管理していた。あるとき、同社内でイーコマースシステムを立ち上げることになった。筆者はオープンソースを使用したシステムを提案した。システムのサービスインはうまくいき、日々問題なくシステムは稼働していたのだが、冗長化と監視処理をしている社内システムのデータベースに統合したいという意見がシステム管理者側から提案された。つまり、さらなるシステム投資を筆者が担当している企業に強いらせる事態となってしまったのである。部署間でバラバラのアーキテクチャを採用していたために、高価なEAIツールの導入を検討する企業や、同様の理由でシステムを一から作り直す羽目になっている企業が少なくない。

　このような事態を避けるためには、あらかじめシステムの保守や将来的な方向性をユーザー側のプロジェクトマネージャが十分考慮しなければならない。そのうえで、システムのアーキテクチャを選択し、採用する必要がある。

（3）システムに最適なアーキテクチャを採用する

　IT業界では、常に新しい技術が紹介されているが、ユーザー側のプロジェクトマネージャはどの技術が採用に値するか、慎重に検討しなければならない。開発会社は自社の技術力の向上のためだけに積極的に新しい技術を用いた提案をする可能性がある。レスポンスの速度が求められる仕様に対して、HibernateやEJBのようなO/Rマッパーが提案されていたりしたことはないだろうか？ クローズドな社内システムなのにもかかわらず、BPEL対応アプリケーションサーバでの実装が検討されていたりしたことはないだろうか？

　開発側のプロジェクトマネージャは新しい技術に詳しく、積極的に新技術を採用したシステム提案をしてくれるかもしれない。しかし、彼らはユーザー企業側のシステムの情報を詳しく知っているわけではない。ユーザー企業側のプロジェクトマネージャは開発会社側の提案を、自分たちの利用するシステムに真に適合するかについて慎重に検討する必要があるといえる。

　「WindowsなのかLinuxなのか？」「Javaなのか.NETなのか？」「オープンソースDBなのか商用DBなのか？」などアーキテクチャの洗練度や優位性など雑誌で論じられていることは、プロジェクト内でのシステム検討事項においてあまり重要視すべきことではない。むしろプロジェクトマネジメントという観点からは、導入する予定のシステムの周辺を取り巻く環境こそが重要事項である。ユーザー企業側のプロジェクトマネージャがシステムの周辺を取り巻く環境に留意してシステムのアーキテクチャを決定することこそが、プロジェクトの「モノ」におけるリスクを減らす最高の特効薬なのである。

　次回は「カネ」に起因する失敗のリスクファクター（コスト）を紹介する予定である。最後までお付き合いいただきたい。

筆者プロフィール

玉木 栄三郎（たまき えいざぶろう）

イー・キャッシュ株式会社 代表取締役社長

1972年香川県生まれ。

麻布大学獣医学部卒業。

東京医科歯科大学医学部博士課程修了。

大学院在学中から、大手企業のCTOなどを歴任。

2005年5月より現職。

2006年 Microsoft Regional Director になる。

須永 啓太（すなが けいた）

イー・キャッシュ株式会社 取締役 ビジネスデザイン事業部

インターネットベンチャー企業などで大手ポータルサイトのEコマースサイト構築におけるプロジェクトマネージャーなどを歴任後、イー・キャッシュ株式会社に入社。主にRFIDシステムのコンサルティング業務を担当。実はモノ作りが大好きで、最近プログラミングをまったくできないのが悩み。

「“失敗しない”データセンター選定法」バックナンバー

• いまさら聞けない、データセンターの基礎知識