リプレイス開発のススメ

2011.12.04

どうも、すっかり寒くなりましたが。皆様いかがお過ごしでしょうか?

あなたの心のオアシス江刺家です。

 さて、久しぶりにBlogを書いてみました。文字ばかりですが、お許しくださいませ。

 

最近は数年前から業務基幹システムのリプレイスのご相談を受ける機会が非常に多いです。

もう何度もご説明・お話をしてきた内容を自分なりにまとめ、今後の皆様の参考になればと思います。

 

リプレイス開発への要求

数年前のIT(WEB)化に伴って一気に自社の業務基盤をクラサバ系のアプリからWEBアプリによる再構築 その時の開発対象からはずれ、クラサバのまま現役で運用されているアプリもそろそろハードウェアの耐用年数・開発言語のサポート切れなどによって 現行の技術への対応が急務な事案が非常に増えてきていると思います。

 

リプレイス開発時の課題

リプレイス(レガシーからのWEB化)を想定した場合の代表的な課題を例としています。

  • 業務仕様自体が年々変わり追加対応の重ね、開発当時のドキュメントがあってもメンテナンスされていない。
  • そもそもドキュメントが存在しない。
  • 「同じもの」を作るのに、当時同額の予算を納得できない。
  • 業務自体(ロジック)は変わっていないので、できれば再利用したい。
  • 使い勝手が悪いとの声が現場から上がっているが、業務フロー/操作性の変更は業務混乱を招く危険性がある。
  • 数年前に購入したH/Wと現行機種には明白な性能差があり、基準となるキャパシティプランニングができない。
  • どう手を付けたらいいかわからない。
  • 新しい技術、採用に対し情報・知識が不足している。

 

やらなきゃいけない、けど・・・・

昨今の経済状況も関係しますが、「同じもの作り直します。」では予算が取りずらいのが現実だと思います。

その為には「必要性」を作り出すことになると思います(言い方は悪いですが) 結果として、機能追加+リプレイスという選択になると思うのですが もともとドキュメントもない、業務整理がされていないところで機能追加対応というのは言わずもかなカオスな開発になります。

 

効果的なリプレイス開発

今までのお付き合いの中から伺った傾向として、リプレイス開発の場合いきなり機能追加を目的として既存の根幹設計に手をいれてしまうと あとあと想定外の影響が発生する確率が非常に高くなると思っています。 しかもその時には手遅れになって、今まで使えてたのに共倒れになる可能性も高くなります。

逆に、成功したリプレイス開発の方法として「同じ動きをするようにリプレイスする」ことを第一目的とし 無事同じ動きをする新システムができてから、追加機能を検討するほうが開発者の習熟も高いですしリバースエンジニアによって分析ドキュメントが作成されてたりもします。

急がばまわれ、短気は損気。の精神で。 可能であれば

一番効果的なリプレイスの手法としては、既存部分を新しい実装ですっぽり包み込んでしまうのが間違いが少ないと思います。

既存部分をブラックボックス化し、サービスレイヤーだけを追加実装する。といった具合です。 もちろん、既存部分の業務ロジック部分は仕様変更が必要ない。という分析結果は必須となります。 既存部分をすっぽり包み込んで、SOA(Service-Oriented Architecture)化することも可能です。

 

クライアントは選び放題

サーバー側がSOA化してくれていれば、クライアント側の技術は選び放題です。 IE専用の縛りから解放され、Flash/AIRの選択も可能ですし、HTML5/Ajaxの選択から スマートホン対応だって容易になります。

あわてて開発着手する前に既存をラッピングする形で設計するのは別段特別な設計ではありません、数年前から当たり前に提案している内容なので今回記事にしました。 この記事を読んで検討していただければうれしく思います。

もちろん一筋縄でいきません、結構ナレッジが重要な内容となりますので、お悩みの場合へ弊社営業までお問い合わせください(笑)

 

一番効果的な進め方(SOA化+リッチクライアント+クラウド=マルチクライアント)

上記課題にもありますが、リプレイスの場合。アプリ構築の見積だけでなくハードの購入手配も考慮にいれるといきなり数千万の見積もりとなり稟議の難易度が上がります。 すでにITブームから数年、開発原価の償却がすみ次バージョンの話が出てきているきている会社様も多いと思います。

そこでおすすめなのが、「ラッピング(SOA化)する」+「リッチクライアント化」を第一フェーズとして開発を開始。

第二フェーズは運用環境としてクラウドの導入を検討、ハード購入のイニシャルコストを最小にした場合の検討をします。

運用開始後、サーバーの負荷状況を見ながら最適な構成を検討する。 といった手順で進めることで、過剰な予算投入を抑えることが可能となります。 また既存システム・環境を傷つけることがないので平行運用しながら慎重に進める選択ができます。

第二フェーズで安定環境を手に入れたら、機能追加やスマホ対応など第三フェーズへ移行します。

 

まとめ

リプレイス案件を計画する際は、既存機能を再現しつつ最新のテクノロジーによる開発の効率化をし そこから生まれた余裕をUI部分の再検討など付加価値向上の検討を行うことでみんなが幸せになる選択をするのが一番だと考えます。 機能追加については、リプレイス方針をきちんと立ててから、影響範囲を考慮した追加設計を行うことで計画的な追加対応が可能となります。

 

おまけ

「社内システムをいきなりクラウドにするのも・・・・」と躊躇されるお客様もいらっしゃいます。 プライベートクラウドという選択により、社内LANの拡張という解釈できる設計も可能です。 どのような進め方・プランの選択がよいのかについても、ご相談をお受けすることは可能ですので遠慮なくお問い合わせくださいませ。