リプレイス開発のススメ（２）コンバージョンツールの採用

リプレイス開発のススメ、続きです。

数年前からリプレイス＝マイグレーションツールに関するご相談を定期的にいただきます。

弊社はコンバージョンツールの採用をしたことはありませんし、推奨も否定もしておりません。

ただ、ご相談内容に一つの共通点があるように思うのでここで記事にしています。

 

●コンバージョンツール（Flex化）を採用する背景

既存システムがDelphiやJava/appletで作られたシステムを、延命する目的で今どきの技術で再構築するする際に選択される場合が多いようです。

 

●バッチでサクッとFlex化

できるらしいですね。多くは語らずにおきます。

コンバージョンツールによって生成されたソースは「それらしく」動くらしいですが、

細かなところで仕様通りではない。もしくはパフォーマンスに難が残る。

多くのお問い合わせは、その後生成されたソースコードを「パフォーマンスチューニングして欲しい。」「仕様と違うので追加実装してほしい」

というご相談が多いように思います。

 

●掛け違ったボタン

そういったコンバージョンツールを選択する場合、「その言語に詳しくなくてもバッチが作ってくれる」からという選択理由をお伺いしますが。

その生成されたソースコードを、誰が正しいと判断できるのでしょうか？

出来れば今コンバージョンツール採用を検討している方がいらっしゃったら、ここに気が付いて欲しくて書いています。

 

●Flexエンジニアがいればなんとかなるんじゃないのか？

いつもツールで生成されたソースコード拝見しますが「どうしてこうなった。。。」と言いたくなるソースコードが多く非常に解析に時間がかかります。

画面仕様を聞くと非常に簡単な動作なのですが、独自の解釈から複雑な手順を踏むコードが吐かれているようです。

Flexを分かる人間が見れば、さくっと修正して直してくれるのでないか？というご期待の元お問い合わせいただき、

大変ありがたい気持ちなのですがご要望に沿えることは非常に稀です。

 

●後戻りできない

弊社までたどり着いていただいたタイミングでは、多くの場合スケジュール的にも予算的にも大部分を消費した状態でご相談いただく場面が多いです。

既存システムが大規模案件であればあるほど、コンバージョンツールによる開発工数の削減案が輝いて見えるのですが。

その分すべての画面に適用できるのか？という見極めが甘く、気づいた時には調査調査調査に工数も日数も消費し成果物がない。けど、やめるわけにもいかない。という状況が多々あります。

 

●採用の前に相談を

走り出す前に相談して欲しいと思います。

多くの方にリッチクライアント・Flex・AIRといった選択をしていただき、受け入れていただける機会が増えることはとてもうれしく思います。

だからこそ「簡単じゃないよ」とお伝えしておきたいのです。

Adobe Flash/Flexに限らず、HTML5/Ajax , Microsoft Silverlight多くのリッチクライアント技術はイベント駆動です。

非同期処理によって操作性をコントロールできるように設計されています。

既存のシステムがそもそも、その設計思想に適用できるのか？じっくりと調査をしていただきたいと思います。

 

●コンバージョンツール＝悪ではない

誤解をしていただきたくないのですが、コンバージョンツールは使い方だと思います。

ツールの中にはMXMLはしっかり作ってくれる製品や、MVCにのっとったクラス設計まで行ってくれる優れた製品があります。

大事なのは「コンバージョンしておしまい」という計画を立てるのではなく、コンバージョンによってどの程度要求を満たし、追加で何を行う必要があるのか？まで調査を行い計画を立てて欲しいと思うのです。

 

ちょっと上から目線な文面ですが（苦笑）

長く使ってきたシステムを再利用する、延命するという考え方は個人的には非常に好きです。

今後もそういった案件の支援は積極的に行いたいと思っています。

 

どうぞ既存システムの再利用や、システム統合などを検討中の中この記事にたどり着いた担当者様がいらっしゃいましたらお気軽に弊社営業までお問い合わせくださいませ！