他にない、上質なITを

Column

システム再構築(リプレース)は新規開発より困難を極めることも


Pocket

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


おすすめ記事

最後までお読みいただきありがとうございました。
こちらの記事にご興味を持っていただいた方には、こちらの記事もおすすめです。

執筆者について

著者

(株) クオリティスタート 代表取締役

湯本堅隆(YUMOTO Michitaka)

略歴

1979年生まれ。ISPの電話サポートのアルバイトをきっかけにIT技術に興味を持ち、2003年にアイ・ティ・フロンティア(現タタ・コンサルタンシー・サービシズ)に新卒で入社。

SIer在籍期間からブログ「GoTheDistance」でSIerを巡るIT業界のあり方・エンジニアのキャリアについて記事を書き、累計はてなブックマーク数40,000を超えるブログになりました。

「ITを使いこなしたいなら、ユーザー企業は内製すべき」と主張しているうちに、2009年から雑貨卸の有限会社 エフ・ケーコーポレーションで内製化を1人で担当するはめに。メーカー送料ロットのない雑貨卸というビジネスモデルをITシステムを実装することで確立し、経済産業省が主催するIT経営実践認定企業に選ばれました。

「システムを作る人材や会社」はあっても「何が正しいITシステムなのか」を事業会社の立場で考え、デザインできる人材が枯渇している。

この課題を解決したいという思いから、会社を創業しました。

重度の野球好きで、東京ヤクルトスワローズのファンです。



IT企画の進め方

ITプロジェクトの進め方、公開中

事業を運営するために必要なITや業務システムの企画の作り方、プロジェクト担ってからの進め方をワークフローという形で完全無料公開しています。10000文字超えの力作です。是非御覧ください。

ITプロジェクトの進め方

IT戦略・IT企画の無料相談承ります。

ITプランナーが御社にお伺いして、御社のシステム企画のディスカッション・パートナーをさせて頂くサービスです。60分時間限定ですが、IT企画のモヤっとスッキリさせるお手伝いをさせて頂けたら。

ITプランナーへの無料相談

お問い合わせはこちらから