« 「"Readyの定義" を使う」当り前の話...ですよね? | トップページ | かんばんボードをバージョンアップ! »

データ移行について

6月の定例会の中で出し物の枠をとっていたJinさん(6月末で業務を終了して、産休&育児休暇に入る予定だった)が、ドクターストップで定例会にも出られなくなってしまいました~~!

さあ大変!、先ずはしっかりお休みして頂くのは当然としても、定例会で空いてしまった枠はどうしよう?
.....と、まあ、それはどうにかしました...。

で、後日、本人が当日の出し物での説明用に用意していた電子文書(GoogleDocs)を、社内専用サイト上に公開してくれました!

今回は、その内容をかいつまんでアップさせて戴きます。

お題は「データ移行に付いて」

「データ移行」とは、「システムの刷新や統合などに合わせて、旧システムで使っていたデータを新システムに移すこと」と定義しました。

データ移行の主たるところはRDBMS上のデータ、という前提になります。
(これからは、或いは既に?段々と変わっていくと思いますが。
クラウド上のままで契約構成の変更、クラウドのベンダー変更、NoSQL(KVS)上での別種のストアへの移行、等々...)

RDBMSで、同じプロダクトで同じOSで、かつデータ構造が変わらないならば、当然ながら簡単な話です(スケールアップを必要とする場合などを別として)。

ただ、現実問題としては、「データ移行までして運用を続けたい(相応に儲けのある)サービスだから移行する」のだから、アプリの寿命は短くはなく、様々な負の遺産(この話の中では、特にDB周りの中で)を受け継ぐ場合が多くなります。

「小さく立ち上げて、着実に稼ぎながら大きくしていく」パターンが多いかと思いますが、特に最近の場合ほど「低コストで早々にサービスを立ち上げる(当たるかどうか分からないので)」場合が多いと思います。

当たらなかったら、早々に捨てる

当たったら、バンバン拡張していく

拡張に耐えるように、アプリもDB構造も(&テスト駆動とかリファクタリング等も含めて)考慮してあれば良いのですが、「将来を見据えてキレイに作る」のには初期コストも時間もかかります

システム寿命が長くなるのであれば「小さい内にキレイに作った方が、トータルで安くて品質も担保し続けられる」はずなのですが、「当たってしまったら、ドンドン突っ走らないといけなくなる」。

他社に真似されたら先行メリットが活かせなくなりますから、ここでリファクタリングがどうのこうのとか言い出す&実行に移すのには、相当の信念と覚悟が必要です。

しかし、「当たりまくって、システムもひたすら巨大化の一途をたどった」場合には、不毛にメンテナンス工数は食うは、システムの様々なナレッジが担当技術者依存になってしまい、人の流動(様々な要因によるでしょうが...)に合わせて、どんどん品質担保が怪しくなっていきます。

作業効率もどんどん落ちて、小手先の改善ではとても追い付かなくなってしまいます。

「ドンドン売り上げが上がる!」んだけど、「メンテ工数で巨費を食いまくるので全然儲からないー!」というケースは、業界内で結構多いのでは??...という気もします。

移行時に負の遺産を捨てる」!
これにしっかり工数をかけるべきですね(←「このシステムで儲け続けよう!、と考えるのであれば」)。

そこでチェックすべきこと、として、
・旧データ定義で表現できていた事を、新データ定義でどう表現するのか?
・表現できなくなった情報は、本当にそれでいいのか?
・新データ定義で新たに現れた情報は、何を入れればいいのか?
・アプリとデータ、両方移行が終わった時点で、ユーザが違和感を感じる部分がないか?
・新アプリでトラブルがあった場合、旧アプリへの切り戻しはあり得るか?

つまりは、
アプリの仕様も知ってないとデータ変換できない!
.....当然と言えば当然のことなんですが、場合により意外と軽視されがちな部分です。

長く実務運用されたシステムほど「隠れ仕様」や「特例処理」がたんまり存在し、困ったことに、大抵の場合にそれらは全く(もしくは殆ど)文書化されていません

なので、「仕様を理解した上でのデータ変換」と言うのは(書くのは)簡単なんですが、実務上は意外と(非常に)大変な場合が多いです。

では、このような要求に対しての見積(工数)はどのようにして行うのか?
主なキーとなるのは下記の項目になると思われます。
・テーブル数
・テーブル定義の変更量
・不正データの量とバリエーション
・関連するアプリ機能数(新・旧)
・切り戻しを考慮するか

実際の社内的な例で見ると、オリジナルのアプリケーション開発の、大体2/3~同等くらいの工数を要しています!

ここで、少なからずのお客様から「何でそんなにかかるんだ!?」という反応が返って来ます。

そんなときは、相手の方の知識や立場・関心事に応じてではありますが、
上記を順を追って説明するか、過去の事例を挙げるか、可能ならば一部分に絞って移行作業を行ってみて(或いはテーブルデータの解析&関連機能の調査・確認を行ってみて)各種の数値化をした上で実工数を測定&総工数を推測してみる、という手を使うこともあります。

このような初動を行わずに安請合いしてしまうと、会社の経営にまで影響を与えかねない痛い目を見る場合も有り得ますので、怖い・怖い!

「データ移行」をなめて掛からずに、慎重に対応しましょう!
.....というお話がされる予定なのでした!

Jinさん!、資料の作成&社内公開、有難う御座いました!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

|

« 「"Readyの定義" を使う」当り前の話...ですよね? | トップページ | かんばんボードをバージョンアップ! »

定例会、勉強会など」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: データ移行について:

« 「"Readyの定義" を使う」当り前の話...ですよね? | トップページ | かんばんボードをバージョンアップ! »