設計の落としどころ （後編）〜J2EE金融基幹システムの構築現場から〜：開発現場の天国と地獄（6）（3/3 ページ）

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

（4）テスト移行

実際のプロジェクトの流れ

　実際のプロジェクトの流れを話しておきます。

　今回のシステム開発では、開発期間が6カ月しかなく、また相手が金融機関であったため、テスト期間を短くすることも許されませんでした。あらかじめ定められたテスト期間が確保できないというのは、リリースの延期を意味します。従って、効率の良い確実なテストが求められたのです。

連結テスト

　基幹システム連携の場合、バラバラの開発場所から順番にテストが行われます。しかし、問題が出れば、そこでトライアンドエラーの状況になったり、互いのログを照合して不具合の原因を探らねばならなかったりします。お互いに何十人もいる開発者が数百の機能の何をテストして何を完了させたかが不明になってしまいます。

　この問題に対し、このプロジェクトでは極めて普通の手法を採用しました。壁に紙を張り、

• テスト中
• 修正中
• 完了

などに領域を分けて、機能カードを張り付けていきます。障害があれば障害番号をその上に張っていきました。事前にWeb上で用意しておいた方が良かったかもしれません。

　開発期間中、開発負荷が最も高かったのは、連結テストを行っていたときでした。実際には連結テストは「第2の開発」ともいえます。

テスト環境

　いままで構築をしてきた100人月以上のプロジェクトでは、必ずテスト環境が不足しました。今回の案件でも再三あらかじめ警告したにもかかわらず、やはり不足しました。

いつも、

• 環境（1）……開発環境
• 環境（2）……テスト環境1
• 環境（3）……テスト環境2
• 環境（4）……本番環境
• 環境（5）……ユーザー教育環境

図3 環境構成図（1）

を用意します。しかし、私は少なくとも、もう1つは絶対に必要だと考えています。

図4 環境構成図（2）

　毎回「テスト環境2って何ですか？」と聞かれ、常に「コストが……」という形で却下されてきました。しかし、当初テスト環境2を却下したプロジェクトはすべて、結局は用意することになっています。

　往々にして、プロジェクトはブランチ分けされていきます。具体的には、障害が発生した現在のバージョンと来月に機能を追加してUPされるバージョンは別のものです。「見積もり金額がおかしいのですぐ直してください!!」というケースを想定してみてください。見積もり金額が正しく出るようにしないといけないのは、現在お客さまが利用している本番環境のバージョンです。しかし、テスト環境が1つの場合、「その環境は来週のUPのためにいままさしく次バージョンのテスト中です」という状況だったときに非常に困ることになります。

　さらによくある話として、「テストをしているが障害が多い。顧客側でも並行して、業務的観点からテストを行います」という場合、どうしますか？

　厳密には、「テスト環境3」も欲しいというのが実情です。少なくとも、「テスト環境1」だけでは絶対に済まないことはお分かりいただけるでしょう。テスト環境に限らず、現場では「マシン1台で済むことがなぜ？」という疑問は常に取りざたされています。高価なDBなどは別インスタンスでも構いません。本番のような高価なマシンも要望しません。ただ、数十万円程度の性能の低いサーバが余計にあるだけで助かる場面が意外と多いのも事実なのです。

（5）エピローグ

　本案件は前述のとおり、無事稼働を迎えることができました。それは多くのプロジェクトメンバーと何より顧客の担当者の方々の献身によって達成されたことは間違いありません。我々は論理的にシステムを理解してくれる顧客に恵まれました。それでも、何点かの反省ポイントは挙げられるなと考えています。例えば、情報共有の仕方。もう少し効率を上げられないか、特に開発以外の部分の効率を上げられないものか、と考えずにはいられません。

　とはいえ、結局は、予算、納期、技術的ポイントも得られた形ですので、一応成功案件……天国案件といえます。不思議と飲みニュケーションの少ない案件で、ある意味、非常にドライな現場でした。しかし、きちんと目的を達成し、顧客の満足も得られて、開発者にも多くの経験を持って帰ってもらえたというポイントは非常に意味があったと思っています。いま、そのときの縁で別の案件に参加しています。私と会社にとっても良かった案件なのでしょう。最近、さまざまな議論を重ねて思うのは、顧客や一緒に開発に携わった会社から信頼を得られ、「次の案件」につなぐことができたプロジェクトが成功といえるのかなと思っています。

　今回の工期は6カ月。最近では、金融基幹システム連携のような大規模案件でも6カ月程度の納期しかないケースが非常に多くなりました。筆者の周りでは中小規模で3カ月、ある程度の規模でも6カ月くらいの納期の案件が非常に多くなった気がします。皆さんの周りではどうでしょうか？

今回のポイント！！

• デザインパターンに基づき、プロトタイプを作成して展開すればフレームワークに近い効果が得られる
• テスト環境は3つは必要。テスト環境とか数十万のハードを大規模案件でケチらない
• 顧客の実装現場参加は意外にメリットがある
• 製品のフレームワークを使わないで手作りした方が良い場面がある（今回のMQ連携）
• 汎用基幹連携は文字コードが大変。あらかじめサポートするコードを定めて、全テストを
• 連結は第2の開発
• 連携の場合インターフェイスは実装を無視した鶴の一声も意外に有効
• 情報共有はモチベーションにも好影響
• 実装者はコードを書くツールではない

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

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