この記事で対象にしているシステム再構築(リプレース)とは、今現在動いているシステムの仕様はそのままに、同じものを作り直すことを指します。

運用担当者の退職や開発会社が倒産するなどでメンテナンスを行える人材や体制が構築できず手を入れることが難しい場合や、パッケージソフトウェアと似たようなものを構築したいというケースで、リプレースの機運が高まります。

リプレースの難しい点はいくつかありますが、最も大きな問題点はそのシステムを使っている業務にお詳しい方でも、システムがどう動いているかを正確には把握していないのに、その動きに引きづられてしまうことです。

目次
  1. システムを構成する3つの要素
  2. ブラックボックスを解き明かすのは限界がある

システムを構成する3つの要素

画面を使って操作するシステムを構築するには、大きく分けて下記の3つを整理する必要があります。

  1. 画面(UI)
  2. データ
  3. 機能

画面については、どんな項目があって、どういう操作が可能で(クリック、キーイベント等)、どういう画面遷移が出来て、入力チェックとして何を実装しなければならないか、などを精査する必要があります。

データは、画面の操作を元にどういう情報が格納されているかを精査するものです。リレーショナル・データベースであれば、その接続情報さえ確認できれば問題ないですが、何かしらの事情でデータベースの中身が確認できない、リレーショナル・データベースではない物を利用していると、最初からデータベースの設計図を作り直す必要があります。ある程度画面の動きから類推することは出来ますが、限界は当然あります。

機能は、画面の操作からどういうデータを作成・更新・参照(検索)・削除を行わなければならないかを表したものです。この機能が曲者で、以下の2パターンに大別できます。

  1. 画面の入力値がそのまま反映されるもの
  2. 画面の入力値を元に、ユーザーから見えない所でデータを加工・登録・更新しているもの」

前者についてはイメージが湧くと思いますので、後者について補足します。

売上を月別に集計することを考えます。この場合、1件1件の売上データを月別に集約して合計を出すので、入力データを加工して表示していると言えます。集計や計算、区分値によって表示する内容が変わるなどのロジックの正体を画面の動きだけで掴むのはなかなか困難です。

登録更新で言いますと、わかりやすいのは在庫の更新です。注文明細ごとに、注文数の数を実棚から引き当てる必要があります。受注内容で在庫がないものは自動に発注データを作るなどもあるかもしれません。これらはユーザーからすれば当たり前にやっていることで、わざわざ意識することもないことであるから、要件から漏れやすくなってしまいます。

ブラックボックスを解き明かすのは限界がある

リプレースを成功させるには、ブラックボックスとなっている現行仕様を踏襲するのは限界があります。動いているソフトウェアのプログラムのソースコードから、どのようなデータの操作やロジックが組まれているかを解析することを「リバースエンジニアリング」等と表現しますが、この施策は全くおすすめできません。その理由は以下の通りです。

  1. ソースコードの文脈を汲み取るのは暗号解読に等しい。
  2. 解析結果が正しい仕様であるか判断できない。答えが元からないので。

「これと同じもの作って」というお話があったりしますが、今まで申し上げたように、画面・データ・機能がどう結びついているのかをドキュメントなしで判断するのは、ほとんど無理です。

これは私自身のTweetですが、本当にこういう話です。ラーメンのプロなら一度だけ食ったことがあるラーメンの味を再現できるかいえば、素材も調味料も工程もピタリで当てないといけないので、なかなかに無茶振りです。初めから作ったほうが速いケースです。レシピの再現は新規作成より難しいものです。

また、リバースエンジニアリングは「依頼者である御社」が正解を出せねばなりません。 技術者が解析した結果と想定知るのと違った結果が出た場合、その違いを解き明かすのではなく、あるべき仕様を御社が提示しないと、いつまで立っても先に進みません。

再構築をお考えになる際には、「どういう画面・データ・機能を持てば正解なのか」を用意するのはあくまでも御社であり、リバースエンジニアリングには限界があることをご留意下さい。ふらっと入ったラーメンの味を再現するのは、とても困難ですから。