第4回 そして、システムはお蔵入りとなった：開発現場の天国と地獄（2/3 ページ）

[佐藤大輔，オープントーン]

（2） 企画段階

早すぎた先見の明

　この案件は、顧客の米国における大手の取引先が、当時先進的な技術（Webサービスですが）を先駆けて導入し、取引先にも利用を促したことから始まりました。EDIのように、先にデファクト・スタンダードを握ろうとするこの取引先の判断は戦略として十分に意味のあるものだったでしょう。問題は「早すぎた」ことです。

　当時、各ベンダはWebサービスに対応したIDEはおろか、コンポーネントも用意していませんでした。サーバサイドのツールや製品もなく、すべてが手作りとなってしまいました。稼働安定性は、きちんとしたテストときちんとした保守体制が確保できれば、新技術を使用してもあまり問題にはなりません。しかし、この案件の場合は「アーキテクチャそのもの」が「早すぎた」のです。

　Webサービスは、現在では広まり、非常に重要なシステムでも採用されるようになりましたが、明らかに先行しすぎたため、「普通ならサーバにある機能」を最初から作成する羽目に陥り、本来あるべきコストを大きく上回ったのです。そのコストを負担するのは顧客です。「なんでも自分たちで作成すること」を前提に見積もるので、ベンダには損失にはなりませんが、顧客にとっては明らかに割高につきます。わずか1年後。「今ならもっと安く早く安定したものが作れるのに」と多くの関係者が苦い思いをした案件でもありました。

ベンダSEの「悪習」

　この時点では、Webサービスが規格として決まりつつある程度で、実装する際に使える「既存の機能」はXML−DOM程度でした。 実装者はもちろん、1人もWebサービスの案件を実装したことはありません。この顧客のシステム基盤はWindowsでしたので、その基盤の上にWebサービスを構築していくことになりました。当時、BizTalkサーバもリリースされておらず、.NETフレームワークも整備前の段階です。そのため、製品としてWebサービスのサポートを謳（うた）っている言語、製品は事実上存在していませんでした。結果的に、「英語の仕様書をみながら手作り」するプロジェクトとなったわけです。

　本来であればここで、調査を終えたSEは「今がその時でないこと」を顧客に正直に伝えるべきでした。しかし、当時プロジェクトチームにはそのことを思いつく者さえもいなかったのです。これこそ、見積書と発注書に縛られているSEが先天的に持つ「悪習」といえるかもしれません。

（3） 要件定義

この案件の要件

　この案件の要件は、

• Webサービスで他社連携すること
• 連携したデータをRDBに格納し、Webの業務画面で操作可能なこと
• 電子署名と暗号化に対応すること

　図に表すと以下のようになります。

図2 この案件の要件

アーキテクチャの方向性

　新技術を用いて案件を遂行する場合、機能数からいうと新技術にまつわる部分は全体の3割以下に収まる場合がほとんどです。なにより、新技術によるリスクをプロジェクト全体に伝播（でんぱ）させてはいけません。なるべく個々の機能と役割を冷静に分析し、新技術を隠蔽（いんぺい）するコア機能と業務に面する従来の機能とに分けるべきです。

　可能であれば実装も内部的に子システムが複数あるような状態にし、新技術の機能と業務の機能の結合が疎になるように検討します。こうすることにより、一方のリスクや問題点が相手に伝播せず、開発者は「自分の領土」に対して、深く責任を持てることとなります。J2EEではファサードパターンのような実装になるわけですが、一方の仕様変更、バグやスケジュール遅延に関係なく、もう一方は作業することができます。

　この案件の場合は、Webサービスを担う外向けのいわば「共通機能」と、画面から業務を行う「業務機能」に分けることができました。

　この時の検討方法には重要な注意点があります。

• 必ず双方の役割を明確にすること
• その役割を決して犯さないこと

　そのことがのちに非常に強い可用性や安定性を引き出すこととなります。

　例えば、共通機能の役割は「Webサービスの窓口」です。この窓口に対して、「ここでやったほうが楽そうだから」と業務の仕様を盛り込みます（例：特定の項目だけここで計算する）。共通機能に盛り込んでも業務機能に盛り込んでも、修正量には大差ないようにみえます。しかし、ここには大きな問題が潜んでしまうのです。

　例えば、今後そのロジック周りの仕様が変わるときには、かならず共通機能の開発者にきちんと伝えねばなりません。いままで打ち合わせには業務機能担当者だけが参加すればよかったのに、今後は共通機能担当者も出席する必要があるでしょう。さらにはテストの際に、業務の仕様を双方で理解する羽目になってしまいます。また、その値がおかしい場合に、調査は両方からしなければなりません。

　そういった、「役割を壊すリスク」は少々コードの実装量が減りそうだからといっても絶対に犯してはいけないのです。きちんと役割分けされたシステムは、「役割分けされたコンポーネント」をほかでも利用できたりといった非常に優れた可用性を持ちます。例えばこのWebサービス機能は、別のメーカーから同じような接続の要件が出てきたときに非常にスムーズに応用がきくでしょう。うまくすればまったく手を入れずに振り分けだけ追加してやり、新しい業務機能を呼べば済むかもしれません。しかし、この機能に特定のメーカー向けの業務機能を載せてしまったら、そのような再展開は困難になります。

　以上のように「システムの役割」は非常に重要な位置を占めることになります。目的の違う機能群ごとにインターフェイスを設け、相互間の結合を疎にすることはとても大きなメリットを持ちます。