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

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

アーキテクチャの構成

　これらを踏まえた検討の結果、今回の連携はWebサービスで受けた情報を一度データベースにそのまま格納し、それを業務機能が読み出す形にしました。この方式は、外部に対してデータ連携の即答の必要がなく、一度ストアされた情報をのちほど担当者が画面から開き、検索し、業務機能で操作した後に返信を行う、いわば、電子メールのような仕組みだったため可能となりました。

　つまり、共通機能は「外部からのXMLを受け取り」「暗号化されたデータを復号し」「電子署名をチェックし」「DBのスキーマにあわせて保管する」までが仕事であり、一方の業務機能は、DBを検索し、処理しなければいけない一覧を表示し、選択して処理、送信を押すと共通機能に送信が依頼される、という役割にしたのです。

　送信は受信と逆の動きです。データベースから該当のデータを受け取り、XMLのスキーマに押し込み、電子署名を施します。暗号化した上で、相手サーバに送付し、結果を受け取り格納すれば機能は完結します。

　基本的なアーキテクチャは、以下の通りです。

共通機能

• ASPからVisualBasicのDLLを呼び出し、httpから受け取ったXMLファイルを引き渡す
• XMLファイルをXML-DOMで解析し、データベースの項目へとマッピングする

業務機能

• ASPを利用し、Viewを構成

図3 基本的なアーキテクチャ（クリックすると拡大）

　構成の主だった理由は、想定トランザクション数が多くなかったこと、技術者がVB中心だったこと、ほかのWeb系の機能がASPで構成されていたことなどです。

（4） チーム構成

個々の役割

　新技術の機能は「狭い仕様で深い実装」を求められ、従来の業務的な機能は「広い仕様で浅い実装」をすることになります。

図4 「狭い仕様で深い実装」と「広い仕様で浅い実装」

　どの案件にでも1名は存在する「とがった技術者」にはぜひともこの「狭い仕様で深い実装」を行わせるべきです。それは以下の理由によります。

• 機能数自体は小さいので少人数で行った方が効率がよいから
• 調査やプロトタイプ作成が要件定義や概要設計段階の主な作業であり、これは多人数で行う作業ではないから
• 技術的には非常にハイレベルだから

　その結果、チーム構成は、手数の必要な機能を実装をするための業務機能部隊と、XMLをパースしてデータベースに取り込んだり、暗号化や署名などを行ったりする共通機能としてのコアエンジンというべきものを作る共通機能部隊とに分かれました。

　業務的な機能を作成する部隊の主任務は、

• ヒアリング→顧客の業務要件の洗い出し→仕様のまとめ→仕様書作成→実装……

という従来どおりの手順を踏むことになります。画面やバッチなどを担当する業務機能部隊は、共通機能のWebサービス対応などの部分を意識せずにすむように「従来どおり」作ることを要求されました。

　これに対し、共通機能部隊が「ヒアリングする相手」はユーザーではなく、インターネットの技術サイトや最新技術の書籍などです。彼らの「要件定義」を甘くみてはいけません。業務要件を初期にまとめ損なうと案件全体が致命的な傷を負うように、新技術部隊の調査という要件定義はその後の実装リスクを大幅に左右することになります。こういう場合は、プロトタイプの作成までを含めた入念な調査が必要になります。初期に顧客との打ち合わせが少ないからといって彼らのタスクを軽くみるべきではありません。彼らは沈黙のまま、「要件定義」を行っているのです。

　また現在、多くの企業では、セキュリティなどの事情からインターネット接続、あるいはコンテンツを制限している場合が多々あります。しかし、接続を制限してしまった場合、技術者は最大の情報収集源を失います。そのことは調査にかかる作業コストを間違いなく押し上げるでしょう。

チーム構成

　結局このプロジェクトチームは以下のような構成になりました。新技術部分を担当する2名、マネージャー1名、業務機能の作業者5名（パートナー企業）です。

　このパートナー企業は何度も一緒に案件をしてきた部隊ですので、心配せず安心して作業を分担できました。そのパートナー企業に十分な技術力があるかどうかと同時に「何度かプロジェクトをこなしたことのある企業」というのは技術力以外の面でも非常にコストを下げていきます。

　例えば、手続きを後付けにできたり、仕様書の取り違いが少なかったり、用語の統一の容易さや連絡の早さなど。つまり、大きな意味でのチームとしてパートナー会社とよい関係を築いておくことは、技術的に著名な会社と泡をくって結んだパートナーシップより、多くの場合よい結果を生むでしょう。

（5） 実装から納品へ

実装

　共通部隊の実装はおおむね以下のとおりです。

• XMLを受け取ってDBに格納する
• Webサービスを利用している相手企業にステータスを返す
• 送信時の署名・受信時の署名の確認を行う
• メールで担当者にXML着信を通知する

　したがって、実装テストもいくつかのパターンのうち1パターンを用意し、そのXMLを受信して返信するまでに焦点を当て構築していきます。そして、その後、全パターンを通す形にしました。その際に型の問題や繰り返し形の非常に長い返信の問題などが発生しました。

　しかし、前述の疎な結合のアーキテクチャのおかげで業務機能とはまったく無関係にスケジューリングや実装が行われました。

• この部隊はデータベースに正しく書けているか
• XMLは正しく送出されているか

　 これだけが問題であり、顧客の業務要件のぶれなどには影響なく実装・テストを行っていけたのです。

　一方、業務部隊の実装は以下のとおりです。

• 格納されたデータベースを元に画面を作成し、CRUDを行う
• 着信したXMLを検索し、見積もり、発注、契約の各画面を作成する
• 若干の帳票（契約状況や未消化案件リストなど）を出力する

　 これは「よくあるWebの業務機能」の実装・テストになります。

納期前

　納期1カ月前になり、いよいよ共通と業務機能との結合が始まりました。その際も、もちろん、画面項目レベルでは無数のバグ修正があり、共通機能でもオブジェクトの取り回しに問題があり、あるXMLの情報をまったく別のXMLに渡してしまっていたり……といった「よくあるバグ」を取り出して修正していったのです。

そして納品後……

　納品後は「本番稼働」というものがありませんでした。このシステムはそのままお蔵入りすることになってしまったのです。

　一般にこういった企業間連携システムは、双方の開発スケジュールや実務担当者との擦り合わせなど、システム以外の部分でのユーザーの作業が非常に膨らみます。しかし、今回「相手企業の方針だから」とあわてて導入したWebサービスは、残念ながら実務担当者に利用されることはありませんでした。実は、今回急いでいた理由はもう1つ、「今期の予算にいれたい」という顧客の会計的な理由もありました。

　顧客との会議の席では、相手企業の対応の悪さなどが挙げられました。実際、世界規模の企業ですから、サービスを導入したばかりでは、とても個々の企業の対応にまでは手が回らない状況だったのでしょう。そのためにいくら待っても「サービスの開始」の御声はこのシステムに対してかかることはありませんでした。そして、高いコストをかけて先進的に導入したシステムは、結局一度も日の目をみることのないまま、Webサービスが急速に普及し、開発にかけたコストがそっくり無駄になっていったのです。

エピローグ

　今回は、結果として、「移行フェイズ」が最小で済んでしまったため、開発者個々人からみると、「天国プロジェクト」といえる案件となりました。もちろん、顧客のビジネスに結びつかなかったという意味では失敗であり、顧客からみれば「失敗プロジェクトの典型例」として挙げられてしまうでしょう。そして、本来これはベンダにとっても失敗プロジェクトとして数えられるべきだと思います。

教訓！！

• 「鳴り物入りで先駆けて」は「必須ではない」と同義語
• 接続システムは「両方が本気」でないと稼働しない
• 早すぎる技術は余計なコストを招く。ツールやコンポーネントの未整備。パターンの入手しにくさなど
• 新技術や変わった技術をいかにラッピングするかが重要
• 各機能の「役割」を考えて設計することは非常に重要である
• 顧客は最上流のビジネス部分を検討するコストをSIに与えない以上、見返りも期待できない
• 新技術を使う場合の「沈黙の要件定義」は非常に重要である
• チーム構成には広さと深さを考慮して行う。深い技術で狭い仕様と浅い技術で広い仕様

「開発現場の天国と地獄」バックナンバー

• 設計の落としどころ （後編）〜J2EE金融基幹システムの構築現場から〜
• 設計の落としどころ （前編）〜J2EE金融基幹システムの構築現場から〜
• 第4回 そして、システムはお蔵入りとなった
• ベテランならホントに安心なのか？
• 真のボトルネックは“顧客”なのか？
• “完璧な設計”がプロジェクトを失敗に導く！？